1 Network Working Group P. Mockapetris
2 Request for Comments: 1034 ISI
3 Obsoletes: RFCs 882, 883, 973 November 1987
4
5
6 DOMAIN NAMES - CONCEPTS AND FACILITIES
7
8
9
10 1. STATUS OF THIS MEMO
11
12 This RFC is an introduction to the Domain Name System (DNS), and omits
13 many details which can be found in a companion RFC, "Domain Names -
14 Implementation and Specification" [RFC-1035]. That RFC assumes that the
15 reader is familiar with the concepts discussed in this memo.
16
17 A subset of DNS functions and data types constitute an official
18 protocol. The official protocol includes standard queries and their
19 responses and most of the Internet class data formats (e.g., host
20 addresses).
21
22 However, the domain system is intentionally extensible. Researchers are
23 continuously proposing, implementing and experimenting with new data
24 types, query types, classes, functions, etc. Thus while the components
25 of the official protocol are expected to stay essentially unchanged and
26 operate as a production service, experimental behavior should always be
27 expected in extensions beyond the official protocol. Experimental or
28 obsolete features are clearly marked in these RFCs, and such information
29 should be used with caution.
30
31 The reader is especially cautioned not to depend on the values which
32 appear in examples to be current or complete, since their purpose is
33 primarily pedagogical. Distribution of this memo is unlimited.
34
35 2. INTRODUCTION
36
37 This RFC introduces domain style names, their use for Internet mail and
38 host address support, and the protocols and servers used to implement
39 domain name facilities.
40
41 2.1. The history of domain names
42
43 The impetus for the development of the domain system was growth in the
44 Internet:
45
46 - Host name to address mappings were maintained by the Network
47 Information Center (NIC) in a single file (HOSTS.TXT) which
48 was FTPed by all hosts [RFC-952, RFC-953]. The total network
49
50
51
52 Mockapetris [Page 1]
53 RFC 1034 Domain Concepts and Facilities November 1987
54
55
56 bandwidth consumed in distributing a new version by this
57 scheme is proportional to the square of the number of hosts in
58 the network, and even when multiple levels of FTP are used,
59 the outgoing FTP load on the NIC host is considerable.
60 Explosive growth in the number of hosts didn't bode well for
61 the future.
62
63 - The network population was also changing in character. The
64 timeshared hosts that made up the original ARPANET were being
65 replaced with local networks of workstations. Local
66 organizations were administering their own names and
67 addresses, but had to wait for the NIC to change HOSTS.TXT to
68 make changes visible to the Internet at large. Organizations
69 also wanted some local structure on the name space.
70
71 - The applications on the Internet were getting more
72 sophisticated and creating a need for general purpose name
73 service.
74
75
76 The result was several ideas about name spaces and their management
77 [IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
78 common thread was the idea of a hierarchical name space, with the
79 hierarchy roughly corresponding to organizational structure, and names
80 using "." as the character to mark the boundary between hierarchy
81 levels. A design using a distributed database and generalized resources
82 was described in [RFC-882, RFC-883]. Based on experience with several
83 implementations, the system evolved into the scheme described in this
84 memo.
85
86 The terms "domain" or "domain name" are used in many contexts beyond the
87 DNS described here. Very often, the term domain name is used to refer
88 to a name with structure indicated by dots, but no relation to the DNS.
89 This is particularly true in mail addressing [Quarterman 86].
90
91 2.2. DNS design goals
92
93 The design goals of the DNS influence its structure. They are:
94
95 - The primary goal is a consistent name space which will be used
96 for referring to resources. In order to avoid the problems
97 caused by ad hoc encodings, names should not be required to
98 contain network identifiers, addresses, routes, or similar
99 information as part of the name.
100
101 - The sheer size of the database and frequency of updates
102 suggest that it must be maintained in a distributed manner,
103 with local caching to improve performance. Approaches that
104
105
106
107 Mockapetris [Page 2]
108 RFC 1034 Domain Concepts and Facilities November 1987
109
110
111 attempt to collect a consistent copy of the entire database
112 will become more and more expensive and difficult, and hence
113 should be avoided. The same principle holds for the structure
114 of the name space, and in particular mechanisms for creating
115 and deleting names; these should also be distributed.
116
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
insure
ensure
Section 3.6.2 uses both ensure and insure to mean the same thing, which is to guarantee or make certain. Sections 4.1, 4.2.2, and 5.3.3 all use the insure form. Generally, insure is used in the financial sense, with making certain being a secondary definition. At the very least, consistency in the same paragraph of 3.6.2 would be cleaner.
This RFC is implemented in BIND 9.18 (all versions).
Many of the RFCs that are listed as updating RFC 1034 actually just mention it, but don't actually update anything here. For example, many of them simply define new RRtypes, which is not really an update to RFC 1034, just to the IANA registry it created. The RFCs that do update RFC 1034 are listed throughout this document.
117 - Where there tradeoffs between the cost of acquiring data, the
118 speed of updates, and the accuracy of caches, the source of
119 the data should control the tradeoff.
120
121 - The costs of implementing such a facility dictate that it be
122 generally useful, and not restricted to a single application.
123 We should be able to use names to retrieve host addresses,
124 mailbox data, and other as yet undetermined information. All
125 data associated with a name is tagged with a type, and queries
126 can be limited to a single type.
127
128 - Because we want the name space to be useful in dissimilar
129 networks and applications, we provide the ability to use the
130 same name space with different protocol families or
131 management. For example, host address formats differ between
132 protocols, though all protocols have the notion of address.
133 The DNS tags all data with a class as well as the type, so
134 that we can allow parallel use of different formats for data
135 of type address.
136
137 - We want name server transactions to be independent of the
138 communications system that carries them. Some systems may
139 wish to use datagrams for queries and responses, and only
140 establish virtual circuits for transactions that need the
141 reliability (e.g., database updates, long transactions); other
142 systems will use virtual circuits exclusively.
143
144 - The system should be useful across a wide spectrum of host
145 capabilities. Both personal computers and large timeshared
146 hosts should be able to use the system, though perhaps in
147 different ways.
148
149 2.3. Assumptions about usage
150
151 The organization of the domain system derives from some assumptions
152 about the needs and usage patterns of its user community and is designed
153 to avoid many of the the complicated problems found in general purpose
154 database systems.
155
156 The assumptions are:
157
158 - The size of the total database will initially be proportional
159
160
161
162 Mockapetris [Page 3]
163 RFC 1034 Domain Concepts and Facilities November 1987
164
165
166 to the number of hosts using the system, but will eventually
167 grow to be proportional to the number of users on those hosts
168 as mailboxes and other information are added to the domain
169 system.
170
171 - Most of the data in the system will change very slowly (e.g.,
172 mailbox bindings, host addresses), but that the system should
173 be able to deal with subsets that change more rapidly (on the
174 order of seconds or minutes).
175
176 - The administrative boundaries used to distribute
177 responsibility for the database will usually correspond to
178 organizations that have one or more hosts. Each organization
179 that has responsibility for a particular set of domains will
180 provide redundant name servers, either on the organization's
181 own hosts or other hosts that the organization arranges to
182 use.
183
184 - Clients of the domain system should be able to identify
185 trusted name servers they prefer to use before accepting
186 referrals to name servers outside of this "trusted" set.
187
188 - Access to information is more critical than instantaneous
189 updates or guarantees of consistency. Hence the update
190 process allows updates to percolate out through the users of
191 the domain system rather than guaranteeing that all copies are
192 simultaneously updated. When updates are unavailable due to
193 network or host failure, the usual course is to believe old
194 information while continuing efforts to update it. The
195 general model is that copies are distributed with timeouts for
196 refreshing. The distributor sets the timeout value and the
197 recipient of the distribution is responsible for performing
198 the refresh. In special situations, very short intervals can
199 be specified, or the owner can prohibit copies.
200
201 - In any system that has a distributed database, a particular
202 name server may be presented with a query that can only be
203 answered by some other server. The two general approaches to
204 dealing with this problem are "recursive", in which the first
205 server pursues the query for the client at another server, and
206 "iterative", in which the server refers the client to another
207 server and lets the client pursue the query. Both approaches
208 have advantages and disadvantages, but the iterative approach
209 is preferred for the datagram style of access. The domain
210 system requires implementation of the iterative approach, but
211 allows the recursive approach as an option.
212
213
214
215
216
217 Mockapetris [Page 4]
218 RFC 1034 Domain Concepts and Facilities November 1987
219
220
221 The domain system assumes that all data originates in master files
222 scattered through the hosts that use the domain system. These master
223 files are updated by local system administrators. Master files are text
224 files that are read by a local name server, and hence become available
225 through the name servers to users of the domain system. The user
226 programs access name servers through standard programs called resolvers.
227
228 The standard format of master files allows them to be exchanged between
229 hosts (via FTP, mail, or some other mechanism); this facility is useful
230 when an organization wants a domain, but doesn't want to support a name
231 server. The organization can maintain the master files locally using a
232 text editor, transfer them to a foreign host which runs a name server,
233 and then arrange with the system administrator of the name server to get
234 the files loaded.
235
236 Each host's name servers and resolvers are configured by a local system
237 administrator [RFC-1033]. For a name server, this configuration data
238 includes the identity of local master files and instructions on which
239 non-local master files are to be loaded from foreign servers. The name
240 server uses the master files or copies to load its zones. For
241 resolvers, the configuration data identifies the name servers which
242 should be the primary sources of information.
243
244 The domain system defines procedures for accessing the data and for
245 referrals to other name servers. The domain system also defines
246 procedures for caching retrieved data and for periodic refreshing of
247 data defined by the system administrator.
248
249 The system administrators provide:
250
251 - The definition of zone boundaries.
252
253 - Master files of data.
254
255 - Updates to master files.
256
257 - Statements of the refresh policies desired.
258
259 The domain system provides:
260
261 - Standard formats for resource data.
262
263 - Standard methods for querying the database.
264
265 - Standard methods for name servers to refresh local data from
266 foreign name servers.
267
268
269
270
271
272 Mockapetris [Page 5]
273 RFC 1034 Domain Concepts and Facilities November 1987
274
275
276 2.4. Elements of the DNS
277
278 The DNS has three major components:
279
280 - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
281 specifications for a tree structured name space and data
282 associated with the names. Conceptually, each node and leaf
283 of the domain name space tree names a set of information, and
284 query operations are attempts to extract specific types of
285 information from a particular set. A query names the domain
286 name of interest and describes the type of resource
287 information that is desired. For example, the Internet
288 uses some of its domain names to identify hosts; queries for
289 address resources return Internet host addresses.
290
291 - NAME SERVERS are server programs which hold information about
292 the domain tree's structure and set information. A name
293 server may cache structure or set information about any part
294 of the domain tree, but in general a particular name server
295 has complete information about a subset of the domain space,
296 and pointers to other name servers that can be used to lead to
297 information from any part of the domain tree. Name servers
298 know the parts of the domain tree for which they have complete
299 information; a name server is said to be an AUTHORITY for
300 these parts of the name space. Authoritative information is
301 organized into units called ZONEs, and these zones can be
302 automatically distributed to the name servers which provide
303 redundant service for the data in a zone.
304
305 - RESOLVERS are programs that extract information from name
306 servers in response to client requests. Resolvers must be
307 able to access at least one name server and use that name
308 server's information to answer a query directly, or pursue the
309 query using referrals to other name servers. A resolver will
310 typically be a system routine that is directly accessible to
311 user programs; hence no protocol is necessary between the
312 resolver and the user program.
313
314 These three components roughly correspond to the three layers or views
315 of the domain system:
316
317 - From the user's point of view, the domain system is accessed
318 through a simple procedure or OS call to a local resolver.
319 The domain space consists of a single tree and the user can
320 request information from any section of the tree.
321
322 - From the resolver's point of view, the domain system is
323 composed of an unknown number of name servers. Each name
324
325
326
327 Mockapetris [Page 6]
328 RFC 1034 Domain Concepts and Facilities November 1987
329
330
331 server has one or more pieces of the whole domain tree's data,
332 but the resolver views each of these databases as essentially
333 static.
334
335 - From a name server's point of view, the domain system consists
336 of separate sets of local information called zones. The name
337 server has local copies of some of the zones. The name server
338 must periodically refresh its zones from master copies in
339 local files or foreign name servers. The name server must
340 concurrently process queries that arrive from resolvers.
341
The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the the complicated problems found in general purpose database systems.
The organization of the domain system derives from some assumptions about the needs and usage patterns of its user community and is designed to avoid many of the complicated problems found in general purpose database systems.
Just a duplicate "the".
342 In the interests of performance, implementations may couple these
343 functions. For example, a resolver on the same machine as a name server
344 might share a database consisting of the the zones managed by the name
345 server and the cache managed by the resolver.
346
347 3. DOMAIN NAME SPACE and RESOURCE RECORDS
348
In the interests of performance, implementations may couple these functions. For example, a resolver on the same machine as a name server might share a database consisting of the the zones managed by the name server and the cache managed by the resolver.
In the interests of performance, implementations may couple these functions. For example, a resolver on the same machine as a name server might share a database consisting ofthethe zones managed by the name server and the cache managed by the resolver.
349 3.1. Name space specifications and terminology
350
351 The domain name space is a tree structure. Each node and leaf on the
352 tree corresponds to a resource set (which may be empty). The domain
353 system makes no distinctions between the uses of the interior nodes and
354 leaves, and this memo uses the term "node" to refer to both.
355
356 Each node has a label, which is zero to 63 octets in length. Brother
357 nodes may not have the same label, although the same label can be used
358 for nodes which are not brothers. One label is reserved, and that is
359 the null (i.e., zero length) label used for the root.
360
361 The domain name of a node is the list of the labels on the path from the
362 node to the root of the tree. By convention, the labels that compose a
363 domain name are printed or read left to right, from the most specific
364 (lowest, farthest from the root) to the least specific (highest, closest
365 to the root).
366
367 Internally, programs that manipulate domain names should represent them
368 as sequences of labels, where each label is a length octet followed by
369 an octet string. Because all domain names end at the root, which has a
370 null string for a label, these internal representations can use a length
371 byte of zero to terminate a domain name.
372
RFC8020 extensively describes how zone cuts are determined, particularly in the presence of empty non-terminals. It says "This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist."
Section 3.1 of RFC 8020 says:
This document clarifies possible ambiguities in [RFC1034] that did not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names, and it refers to subsequent documents that do. ENTs are nodes in the DNS that do not have resource record sets associated with them but have descendant nodes that do. The correct response to ENTs is NODATA (i.e., a response code of NOERROR and an empty answer section). Additional clarifying language on these points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2 and 2.2.3 of [RFC4592].
373 By convention, domain names can be stored with arbitrary case, but
374 domain name comparisons for all present domain functions are done in a
375 case-insensitive manner, assuming an ASCII character set, and a high
376 order zero bit. This means that you are free to create a node with
377 label "A" or a node with label "a", but not both as brothers; you could
378 refer to either using "a" or "A". When you receive a domain name or
379
380
381
382 Mockapetris [Page 7]
383 RFC 1034 Domain Concepts and Facilities November 1987
384
385
386 label, you should preserve its case. The rationale for this choice is
387 that we may someday need to add full binary domain names for new
388 services; existing services would not be changed.
389
390 When a user needs to type a domain name, the length of each label is
391 omitted and the labels are separated by dots ("."). Since a complete
392 domain name ends with the root label, this leads to a printed form which
393 ends in a dot. We use this property to distinguish between:
394
395 - a character string which represents a complete domain name
396 (often called "absolute"). For example, "poneria.ISI.EDU."
397
398 - a character string that represents the starting labels of a
399 domain name which is incomplete, and should be completed by
400 local software using knowledge of the local domain (often
401 called "relative"). For example, "poneria" used in the
402 ISI.EDU domain.
403
404 Relative names are either taken relative to a well known origin, or to a
405 list of domains used as a search list. Relative names appear mostly at
406 the user interface, where their interpretation varies from
407 implementation to implementation, and in master files, where they are
408 relative to a single origin domain name. The most common interpretation
409 uses the root "." as either the single origin or as one of the members
410 of the search list, so a multi-label relative name is often one where
411 the trailing dot has been omitted to save typing.
412
413 To simplify implementations, the total number of octets that represent a
414 domain name (i.e., the sum of all label octets and label lengths) is
415 limited to 255.
416
417 A domain is identified by a domain name, and consists of that part of
418 the domain name space that is at or below the domain name which
419 specifies the domain. A domain is a subdomain of another domain if it
420 is contained within that domain. This relationship can be tested by
421 seeing if the subdomain's name ends with the containing domain's name.
422 For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
423
424 3.2. Administrative guidelines on use
425
426 As a matter of policy, the DNS technical specifications do not mandate a
427 particular tree structure or rules for selecting labels; its goal is to
428 be as general as possible, so that it can be used to build arbitrary
429 applications. In particular, the system was designed so that the name
430 space did not have to be organized along the lines of network
431 boundaries, name servers, etc. The rationale for this is not that the
432 name space should have no implied semantics, but rather that the choice
433 of implied semantics should be left open to be used for the problem at
434
435
436
437 Mockapetris [Page 8]
438 RFC 1034 Domain Concepts and Facilities November 1987
439
440
441 hand, and that different parts of the tree can have different implied
442 semantics. For example, the IN-ADDR.ARPA domain is organized and
443 distributed by network and host address because its role is to translate
444 from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
445 1002] are flat because that is appropriate for that application.
446
447 However, there are some guidelines that apply to the "normal" parts of
448 the name space used for hosts, mailboxes, etc., that will make the name
449 space more uniform, provide for growth, and minimize problems as
450 software is converted from the older host table. The political
451 decisions about the top levels of the tree originated in RFC-920.
452 Current policy for the top levels is discussed in [RFC-1032]. MILNET
453 conversion issues are covered in [RFC-1031].
454
455 Lower domains which will eventually be broken into multiple zones should
456 provide branching at the top of the domain so that the eventual
457 decomposition can be done without renaming. Node labels which use
458 special characters, leading digits, etc., are likely to break older
459 software which depends on more restrictive choices.
460
461 3.3. Technical guidelines on use
462
463 Before the DNS can be used to hold naming information for some kind of
464 object, two needs must be met:
465
466 - A convention for mapping between object names and domain
467 names. This describes how information about an object is
468 accessed.
469
470 - RR types and data formats for describing the object.
471
472 These rules can be quite simple or fairly complex. Very often, the
473 designer must take into account existing formats and plan for upward
474 compatibility for existing usage. Multiple mappings or levels of
475 mapping may be required.
476
477 For hosts, the mapping depends on the existing syntax for host names
478 which is a subset of the usual text representation for domain names,
479 together with RR formats for describing host addresses, etc. Because we
480 need a reliable inverse mapping from address to host name, a special
481 mapping for addresses into the IN-ADDR.ARPA domain is also defined.
482
All of RFC4343 is relevant to any discussion of the case of characters.
483 For mailboxes, the mapping is slightly more complex. The usual mail
484 address <local-part>@<mail-domain> is mapped into a domain name by
485 converting <local-part> into a single label (regardles of dots it
486 contains), converting <mail-domain> into a domain name using the usual
487 text format for domain names (dots denote label breaks), and
488 concatenating the two to form a single domain name. Thus the mailbox
489
490
491
492 Mockapetris [Page 9]
493 RFC 1034 Domain Concepts and Facilities November 1987
494
495
496 HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
497 HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
498 design also must take into account the scheme for mail exchanges [RFC-
499 974].
500
501 The typical user is not concerned with defining these rules, but should
502 understand that they usually are the result of numerous compromises
503 between desires for upward compatibility with old usage, interactions
504 between different object definitions, and the inevitable urge to add new
505 features when defining the rules. The way the DNS is used to support
506 some object is often more crucial than the restrictions inherent in the
507 DNS.
508
509 3.4. Example name space
510
511 The following figure shows a part of the current domain name space, and
512 is used in many examples in this RFC. Note that the tree is a very
513 small subset of the actual name space.
514
515 |
516 |
517 +---------------------+------------------+
518 | | |
519 MIL EDU ARPA
520 | | |
521 | | |
522 +-----+-----+ | +------+-----+-----+
523 | | | | | | |
524 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
525 |
526 +--------+------------------+---------------+--------+
527 | | | | |
528 UCI MIT | UDEL YALE
529 | ISI
530 | |
531 +---+---+ |
532 | | |
533 LCS ACHILLES +--+-----+-----+--------+
534 | | | | | |
535 XX A C VAXA VENERA Mockapetris
536
537 In this example, the root domain has three immediate subdomains: MIL,
538 EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
539 XX.LCS.MIT.EDU. All of the leaves are also domains.
540
541 3.5. Preferred name syntax
542
543 The DNS specifications attempt to be as general as possible in the rules
544
545
546
547 Mockapetris [Page 10]
548 RFC 1034 Domain Concepts and Facilities November 1987
549
550
551 for constructing domain names. The idea is that the name of any
552 existing object can be expressed as a domain name with minimal changes.
553 However, when assigning a domain name for an object, the prudent user
554 will select a name which satisfies both the rules of the domain system
555 and any existing rules for the object, whether these rules are published
556 or implied by existing programs.
557
558 For example, when naming a mail domain, the user should satisfy both the
559 rules of this memo and those in RFC-822. When creating a new host name,
560 the old rules for HOSTS.TXT should be followed. This avoids problems
561 when old software is converted to use domain names.
562
563 The following syntax will result in fewer problems with many
564 applications that use domain names (e.g., mail, TELNET).
565
566 <domain> ::= <subdomain> | " "
567
568 <subdomain> ::= <label> | <subdomain> "." <label>
569
570 <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
571
572 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
573
574 <let-dig-hyp> ::= <let-dig> | "-"
575
576 <let-dig> ::= <letter> | <digit>
577
578 <letter> ::= any one of the 52 alphabetic characters A through Z in
579 upper case and a through z in lower case
580
581 <digit> ::= any one of the ten digits 0 through 9
582
The usual mail address <local-part>@<mail-domain> is mapped into a domain name by converting <local-part> into a single label (regardles of dots it contains), converting <mail-domain> into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name.
The usual mail address <local-part>@<mail-domain> is mapped into a domain name by converting <local-part> into a single label (regardless of dots it contains), converting <mail-domain> into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name.
583 Note that while upper and lower case letters are allowed in domain
584 names, no significance is attached to the case. That is, two names with
585 the same spelling but different case are to be treated as if identical.
586
587 The labels must follow the rules for ARPANET host names. They must
588 start with a letter, end with a letter or digit, and have as interior
589 characters only letters, digits, and hyphen. There are also some
590 restrictions on the length. Labels must be 63 characters or less.
591
592 For example, the following strings identify hosts in the Internet:
593
594 A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
595
596 3.6. Resource Records
597
598 A domain name identifies a node. Each node has a set of resource
599
600
601
602 Mockapetris [Page 11]
603 RFC 1034 Domain Concepts and Facilities November 1987
604
605
606 information, which may be empty. The set of resource information
607 associated with a particular name is composed of separate resource
608 records (RRs). The order of RRs in a set is not significant, and need
609 not be preserved by name servers, resolvers, or other parts of the DNS.
610
611 When we talk about a specific RR, we assume it has the following:
612
613 owner which is the domain name where the RR is found.
614
615 type which is an encoded 16 bit value that specifies the type
616 of the resource in this resource record. Types refer to
617 abstract resources.
618
619 This memo uses the following types:
620
621 A a host address
622
623 CNAME identifies the canonical name of an
624 alias
625
626 HINFO identifies the CPU and OS used by a host
627
All of RFC4343 is relevant to any discussion of the case of characters.
628 MX identifies a mail exchange for the
629 domain. See [RFC-974 for details.
630
631 NS
632 the authoritative name server for the domain
633
634 PTR
635 a pointer to another part of the domain name space
636
637 SOA
638 identifies the start of a zone of authority]
639
640 class which is an encoded 16 bit value which identifies a
641 protocol family or instance of a protocol.
642
643 This memo uses the following classes:
644
645 IN the Internet system
646
647 CH the Chaos system
648
649 TTL which is the time to live of the RR. This field is a 32
650 bit integer in units of seconds, an is primarily used by
651 resolvers when they cache RRs. The TTL describes how
652 long a RR can be cached before it should be discarded.
653
654
655
656
657 Mockapetris [Page 12]
658 RFC 1034 Domain Concepts and Facilities November 1987
659
660
661 RDATA which is the type and sometimes class dependent data
662 which describes the resource:
663
664 A For the IN class, a 32 bit IP address
665
666 For the CH class, a domain name followed
667 by a 16 bit octal Chaos address.
668
669 CNAME a domain name.
670
671 MX a 16 bit preference value (lower is
672 better) followed by a host name willing
673 to act as a mail exchange for the owner
674 domain.
675
676 NS a host name.
677
678 PTR a domain name.
679
680 SOA several fields.
681
682 The owner name is often implicit, rather than forming an integral part
683 of the RR. For example, many name servers internally form tree or hash
684 structures for the name space, and chain RRs off nodes. The remaining
685 RR parts are the fixed header (type, class, TTL) which is consistent for
686 all RRs, and a variable part (RDATA) that fits the needs of the resource
687 being described.
688
689 The meaning of the TTL field is a time limit on how long an RR can be
690 kept in a cache. This limit does not apply to authoritative data in
691 zones; it is also timed out, but by the refreshing policies for the
692 zone. The TTL is assigned by the administrator for the zone where the
693 data originates. While short TTLs can be used to minimize caching, and
694 a zero TTL prohibits caching, the realities of Internet performance
695 suggest that these times should be on the order of days for the typical
696 host. If a change can be anticipated, the TTL can be reduced prior to
697 the change to minimize inconsistency during the change, and then
698 increased back to its former value following the change.
699
700 The data in the RDATA section of RRs is carried as a combination of
701 binary strings and domain names. The domain names are frequently used
702 as "pointers" to other data in the DNS.
703
704 3.6.1. Textual expression of RRs
705
706 RRs are represented in binary form in the packets of the DNS protocol,
707 and are usually represented in highly encoded form when stored in a name
708 server or resolver. In this memo, we adopt a style similar to that used
709
710
711
712 Mockapetris [Page 13]
713 RFC 1034 Domain Concepts and Facilities November 1987
714
715
716 in master files in order to show the contents of RRs. In this format,
717 most RRs are shown on a single line, although continuation lines are
718 possible using parentheses.
719
720 The start of the line gives the owner of the RR. If a line begins with
721 a blank, then the owner is assumed to be the same as that of the
722 previous RR. Blank lines are often included for readability.
723
724 Following the owner, we list the TTL, type, and class of the RR. Class
725 and type use the mnemonics defined above, and TTL is an integer before
726 the type field. In order to avoid ambiguity in parsing, type and class
727 mnemonics are disjoint, TTLs are integers, and the type mnemonic is
728 always last. The IN class and TTL values are often omitted from examples
729 in the interests of clarity.
730
731 The resource data or RDATA section of the RR are given using knowledge
732 of the typical representation for the data.
733
734 For example, we might show the RRs carried in a message as:
735
736 ISI.EDU. MX 10 VENERA.ISI.EDU.
737 MX 10 VAXA.ISI.EDU.
738 VENERA.ISI.EDU. A 128.9.0.32
739 A 10.1.0.52
740 VAXA.ISI.EDU. A 10.2.0.27
741 A 128.9.0.33
742
743 The MX RRs have an RDATA section which consists of a 16 bit number
744 followed by a domain name. The address RRs use a standard IP address
745 format to contain a 32 bit internet address.
746
747 This example shows six RRs, with two RRs at each of three domain names.
748
749 Similarly we might see:
750
751 XX.LCS.MIT.EDU. IN A 10.0.0.44
752 CH A MIT.EDU. 2420
753
754 This example shows two addresses for XX.LCS.MIT.EDU, each of a different
755 class.
756
757 3.6.2. Aliases and canonical names
758
759 In existing systems, hosts and other resources often have several names
760 that identify the same resource. For example, the names C.ISI.EDU and
761 USC-ISIC.ARPA both identify the same host. Similarly, in the case of
762 mailboxes, many organizations provide many names that actually go to the
763 same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
764
765
766
767 Mockapetris [Page 14]
768 RFC 1034 Domain Concepts and Facilities November 1987
769
770
771 and PVM@ISI.EDU all go to the same mailbox (although the mechanism
772 behind this is somewhat complicated).
773
774 Most of these systems have a notion that one of the equivalent set of
775 names is the canonical or primary name and all others are aliases.
776
777 The domain system provides such a feature using the canonical name
778 (CNAME) RR. A CNAME RR identifies its owner name as an alias, and
779 specifies the corresponding canonical name in the RDATA section of the
The abstract of RFC8767 says: "This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data." The reason this updates RFC 1034 is that the definition of TTL in RFC 1034 says "The TTL describes how long a RR can be cached before it should be discarded." RFC 8767 softens that "should" and describes various scenarios when it is acceptable to serve stale data.
780 RR. If a CNAME RR is present at a node, no other data should be
781 present; this ensures that the data for a canonical name and its aliases
782 cannot be different. This rule also insures that a cached CNAME can be
783 used without checking with an authoritative server for other RR types.
784
785 CNAME RRs cause special action in DNS software. When a name server
786 fails to find a desired RR in the resource set associated with the
787 domain name, it checks to see if the resource set consists of a CNAME
788 record with a matching class. If so, the name server includes the CNAME
789 record in the response and restarts the query at the domain name
790 specified in the data field of the CNAME record. The one exception to
791 this rule is that queries which match the CNAME type are not restarted.
792
Section 3 of RFC4034 says:
Because every authoritative RRset in a zone must be protected by a digital signature, RRSIG RRs must be present for names containing a CNAME RR. This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC (see Section 4) MUST exist for the same name as a CNAME resource record in a signed zone.
Similar wording is found in Section 2.5 of RFC4035.
793 For example, suppose a name server was processing a query with for USC-
794 ISIC.ARPA, asking for type A information, and had the following resource
795 records:
796
797 USC-ISIC.ARPA IN CNAME C.ISI.EDU
798
799 C.ISI.EDU IN A 10.0.0.52
800
801 Both of these RRs would be returned in the response to the type A query,
802 while a type CNAME or * query should return just the CNAME.
803
804 Domain names in RRs which point at another name should always point at
805 the primary name and not the alias. This avoids extra indirections in
806 accessing information. For example, the address to name RR for the
807 above host should be:
808
809 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
810
811 rather than pointing at USC-ISIC.ARPA. Of course, by the robustness
812 principle, domain software should not fail when presented with CNAME
813 chains or loops; CNAME chains should be followed and CNAME loops
814 signalled as an error.
815
816 3.7. Queries
817
818 Queries are messages which may be sent to a name server to provoke a
819
820
821
822 Mockapetris [Page 15]
823 RFC 1034 Domain Concepts and Facilities November 1987
824
825
826 response. In the Internet, queries are carried in UDP datagrams or over
827 TCP connections. The response by the name server either answers the
828 question posed in the query, refers the requester to another set of name
829 servers, or signals some error condition.
830
831 In general, the user does not generate queries directly, but instead
832 makes a request to a resolver which in turn sends one or more queries to
833 name servers and deals with the error conditions and referrals that may
834 result. Of course, the possible questions which can be asked in a query
835 does shape the kind of service a resolver can provide.
836
837 DNS queries and responses are carried in a standard message format. The
838 message format has a header containing a number of fixed fields which
839 are always present, and four sections which carry query parameters and
840 RRs.
841
842 The most important field in the header is a four bit field called an
843 opcode which separates different queries. Of the possible 16 values,
844 one (standard query) is part of the official protocol, two (inverse
845 query and status query) are options, one (completion) is obsolete, and
846 the rest are unassigned.
847
848 The four sections are:
849
850 Question Carries the query name and other query parameters.
851
852 Answer Carries RRs which directly answer the query.
853
854 Authority Carries RRs which describe other authoritative servers.
855 May optionally carry the SOA RR for the authoritative
856 data in the answer section.
857
858 Additional Carries RRs which may be helpful in using the RRs in the
859 other sections.
860
861 Note that the content, but not the format, of these sections varies with
862 header opcode.
863
Section 7.1 of RFC2181 says:
RFC1034, in section 3.7, indicates that the authority section of an authoritative answer may contain the SOA record for the zone from which the answer was obtained. When discussing negative caching, RFC1034 section 4.3.4 refers to this technique but mentions the additional section of the response. The former is correct, as is implied by the example shown in section 6.2.5 of RFC1034. SOA records, if added, are to be placed in the authority section.
864 3.7.1. Standard queries
865
866 A standard query specifies a target domain name (QNAME), query type
867 (QTYPE), and query class (QCLASS) and asks for RRs which match. This
868 type of query makes up such a vast majority of DNS queries that we use
869 the term "query" to mean standard query unless otherwise specified. The
870 QTYPE and QCLASS fields are each 16 bits long, and are a superset of
871 defined types and classes.
872
873
874
875
876
877 Mockapetris [Page 16]
878 RFC 1034 Domain Concepts and Facilities November 1987
879
880
881 The QTYPE field may contain:
882
883 <any type> matches just that type. (e.g., A, PTR).
884
885 AXFR special zone transfer QTYPE.
886
887 MAILB matches all mail box related RRs (e.g. MB and MG).
888
889 * matches all RR types.
890
891 The QCLASS field may contain:
892
893 <any class> matches just that class (e.g., IN, CH).
894
895 * matches aLL RR classes.
896
897 Using the query domain name, QTYPE, and QCLASS, the name server looks
898 for matching RRs. In addition to relevant records, the name server may
899 return RRs that point toward a name server that has the desired
900 information or RRs that are expected to be useful in interpreting the
901 relevant RRs. For example, a name server that doesn't have the
902 requested information may know a name server that does; a name server
903 that returns a domain name in a relevant RR may also return the RR that
904 binds that domain name to an address.
905
The QCLASS field may contain: <any class> matches just that class (e.g., IN, CH). * matches aLL RR classes.
The QCLASS field may contain: <any class> matches just that class (e.g., IN, CH). * matches all RR classes.
Manual inspection of each use of the terms RR and RRs did not reveal any additional incorrectly capitalized adjacent words. aLL > all
906 For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
907 ask the resolver for mail information about ISI.EDU, resulting in a
908 query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
909 section would be:
910
911 ISI.EDU. MX 10 VENERA.ISI.EDU.
912 MX 10 VAXA.ISI.EDU.
913
914 while the additional section might be:
915
916 VAXA.ISI.EDU. A 10.2.0.27
917 A 128.9.0.33
918 VENERA.ISI.EDU. A 10.1.0.52
919 A 128.9.0.32
920
921 Because the server assumes that if the requester wants mail exchange
922 information, it will probably want the addresses of the mail exchanges
923 soon afterward.
924
925 Note that the QCLASS=* construct requires special interpretation
926 regarding authority. Since a particular name server may not know all of
927 the classes available in the domain system, it can never know if it is
928 authoritative for all classes. Hence responses to QCLASS=* queries can
929
930
931
932 Mockapetris [Page 17]
933 RFC 1034 Domain Concepts and Facilities November 1987
934
935
936 never be authoritative.
937
938 3.7.2. Inverse queries (Optional)
939
940 Name servers may also support inverse queries that map a particular
941 resource to a domain name or domain names that have that resource. For
942 example, while a standard query might map a domain name to a SOA RR, the
943 corresponding inverse query might map the SOA RR back to the domain
944 name.
945
946 Implementation of this service is optional in a name server, but all
947 name servers must at least be able to understand an inverse query
948 message and return a not-implemented error response.
949
950 The domain system cannot guarantee the completeness or uniqueness of
951 inverse queries because the domain system is organized by domain name
952 rather than by host address or any other resource type. Inverse queries
953 are primarily useful for debugging and database maintenance activities.
954
955 Inverse queries may not return the proper TTL, and do not indicate cases
956 where the identified RR is one of a set (for example, one address for a
957 host having multiple addresses). Therefore, the RRs returned in inverse
958 queries should never be cached.
959
960 Inverse queries are NOT an acceptable method for mapping host addresses
961 to host names; use the IN-ADDR.ARPA domain instead.
962
963 A detailed discussion of inverse queries is contained in [RFC-1035].
964
965 3.8. Status queries (Experimental)
966
967 To be defined.
968
969 3.9. Completion queries (Obsolete)
970
971 The optional completion services described in RFCs 882 and 883 have been
972 deleted. Redesigned services may become available in the future, or the
973 opcodes may be reclaimed for other use.
974
975 4. NAME SERVERS
976
977 4.1. Introduction
978
979 Name servers are the repositories of information that make up the domain
980 database. The database is divided up into sections called zones, which
981 are distributed among the name servers. While name servers can have
982 several optional functions and sources of data, the essential task of a
983 name server is to answer queries using data in its zones. By design,
984
985
986
987 Mockapetris [Page 18]
988 RFC 1034 Domain Concepts and Facilities November 1987
989
990
991 name servers can answer queries in a simple manner; the response can
992 always be generated using only local data, and either contains the
993 answer to the question or a referral to other name servers "closer" to
994 the desired information.
995
996 A given zone will be available from several name servers to insure its
997 availability in spite of host or communication link failure. By
998 administrative fiat, we require every zone to be available on at least
999 two servers, and many zones have more redundancy than that.
1000
1001 A given name server will typically support one or more zones, but this
1002 gives it authoritative information about only a small section of the
1003 domain tree. It may also have some cached non-authoritative data about
1004 other parts of the tree. The name server marks its responses to queries
1005 so that the requester can tell whether the response comes from
1006 authoritative data or not.
1007
1008 4.2. How the database is divided into zones
1009
1010 The domain database is partitioned in two ways: by class, and by "cuts"
1011 made in the name space between nodes.
1012
1013 The class partition is simple. The database for any class is organized,
1014 delegated, and maintained separately from all other classes. Since, by
1015 convention, the name spaces are the same for all classes, the separate
1016 classes can be thought of as an array of parallel namespace trees. Note
1017 that the data attached to nodes will be different for these different
1018 parallel classes. The most common reasons for creating a new class are
1019 the necessity for a new data format for existing types or a desire for a
1020 separately managed version of the existing name space.
1021
1022 Within a class, "cuts" in the name space can be made between any two
1023 adjacent nodes. After all cuts are made, each group of connected name
1024 space is a separate zone. The zone is said to be authoritative for all
1025 names in the connected region. Note that the "cuts" in the name space
1026 may be in different places for different classes, the name servers may
1027 be different, etc.
1028
1029 These rules mean that every zone has at least one node, and hence domain
1030 name, for which it is authoritative, and all of the nodes in a
1031 particular zone are connected. Given, the tree structure, every zone
1032 has a highest node which is closer to the root than any other node in
1033 the zone. The name of this node is often used to identify the zone.
1034
1035 It would be possible, though not particularly useful, to partition the
1036 name space so that each domain name was in a separate zone or so that
1037 all nodes were in a single zone. Instead, the database is partitioned
1038 at points where a particular organization wants to take over control of
1039
1040
1041
1042 Mockapetris [Page 19]
1043 RFC 1034 Domain Concepts and Facilities November 1987
1044
1045
1046 a subtree. Once an organization controls its own zone it can
1047 unilaterally change the data in the zone, grow new tree sections
1048 connected to the zone, delete existing nodes, or delegate new subzones
1049 under its zone.
1050
1051 If the organization has substructure, it may want to make further
1052 internal partitions to achieve nested delegations of name space control.
1053 In some cases, such divisions are made purely to make database
1054 maintenance more convenient.
1055
1056 4.2.1. Technical considerations
1057
1058 The data that describes a zone has four major parts:
1059
1060 - Authoritative data for all nodes within the zone.
1061
1062 - Data that defines the top node of the zone (can be thought of
1063 as part of the authoritative data).
1064
1065 - Data that describes delegated subzones, i.e., cuts around the
1066 bottom of the zone.
1067
1068 - Data that allows access to name servers for subzones
1069 (sometimes called "glue" data).
1070
1071 All of this data is expressed in the form of RRs, so a zone can be
1072 completely described in terms of a set of RRs. Whole zones can be
1073 transferred between name servers by transferring the RRs, either carried
1074 in a series of messages or by FTPing a master file which is a textual
1075 representation.
1076
1077 The authoritative data for a zone is simply all of the RRs attached to
1078 all of the nodes from the top node of the zone down to leaf nodes or
1079 nodes above cuts around the bottom edge of the zone.
1080
1081 Though logically part of the authoritative data, the RRs that describe
1082 the top node of the zone are especially important to the zone's
1083 management. These RRs are of two types: name server RRs that list, one
1084 per RR, all of the servers for the zone, and a single SOA RR that
1085 describes zone management parameters.
1086
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might ask the resolver for mail information about ISI.EDU, resulting in a query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.
For example, a mailer trying to send mail to Mockapetris@ISI.EDU might ask the resolver for mail information about ISI.EDU, resulting in a query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.
1087 The RRs that describe cuts around the bottom of the zone are NS RRs that
1088 name the servers for the subzones. Since the cuts are between nodes,
1089 these RRs are NOT part of the authoritative data of the zone, and should
1090 be exactly the same as the corresponding RRs in the top node of the
1091 subzone. Since name servers are always associated with zone boundaries,
1092 NS RRs are only found at nodes which are the top node of some zone. In
1093 the data that makes up a zone, NS RRs are found at the top node of the
1094
1095
1096
1097 Mockapetris [Page 20]
1098 RFC 1034 Domain Concepts and Facilities November 1987
1099
1100
1101 zone (and are authoritative) and at cuts around the bottom of the zone
1102 (where they are not authoritative), but never in between.
1103
1104 One of the goals of the zone structure is that any zone have all the
1105 data required to set up communications with the name servers for any
1106 subzones. That is, parent zones have all the information needed to
1107 access servers for their children zones. The NS RRs that name the
1108 servers for subzones are often not enough for this task since they name
1109 the servers, but do not give their addresses. In particular, if the
1110 name of the name server is itself in the subzone, we could be faced with
1111 the situation where the NS RRs tell us that in order to learn a name
1112 server's address, we should contact the server using the address we wish
1113 to learn. To fix this problem, a zone contains "glue" RRs which are not
1114 part of the authoritative data, and are address RRs for the servers.
1115 These RRs are only necessary if the name server's name is "below" the
1116 cut, and are only used as part of a referral response.
1117
1118 4.2.2. Administrative considerations
1119
1120 When some organization wants to control its own domain, the first step
1121 is to identify the proper parent zone, and get the parent zone's owners
1122 to agree to the delegation of control. While there are no particular
1123 technical constraints dealing with where in the tree this can be done,
1124 there are some administrative groupings discussed in [RFC-1032] which
1125 deal with top level organization, and middle level zones are free to
1126 create their own rules. For example, one university might choose to use
1127 a single zone, while another might choose to organize by subzones
Section 2.6 of RFC4035 says:
DNSSEC introduced two new RR types that are unusual in that they can appear at the parental side of a zone cut. At the parental side of a zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at the owner name. A DS RR could also be present if the zone being delegated is signed and seeks to have a chain of authentication to the parent zone. This is an exception to the original DNS specification ([RFC1034]), which states that only NS RRsets could appear at the parental side of a zone cut. This specification updates the original DNS specification to allow NSEC and DS RR types at the parent side of a zone cut. These RRsets are authoritative for the parent when they appear at the parent side of a zone cut.
1128 dedicated to individual departments or schools. [RFC-1033] catalogs
1129 available DNS software an discusses administration procedures.
1130
1131 Once the proper name for the new subzone is selected, the new owners
1132 should be required to demonstrate redundant name server support. Note
1133 that there is no requirement that the servers for a zone reside in a
1134 host which has a name in that domain. In many cases, a zone will be
1135 more accessible to the internet at large if its servers are widely
1136 distributed rather than being within the physical facilities controlled
1137 by the same organization that manages the zone. For example, in the
1138 current DNS, one of the name servers for the United Kingdom, or UK
1139 domain, is found in the US. This allows US hosts to get UK data without
1140 using limited transatlantic bandwidth.
1141
1142 As the last installation step, the delegation NS RRs and glue RRs
1143 necessary to make the delegation effective should be added to the parent
1144 zone. The administrators of both zones should insure that the NS and
1145 glue RRs which mark both sides of the cut are consistent and remain so.
1146
1147 4.3. Name server internals
1148
1149
1150
1151
1152 Mockapetris [Page 21]
1153 RFC 1034 Domain Concepts and Facilities November 1987
1154
1155
1156 4.3.1. Queries and responses
1157
1158 The principal activity of name servers is to answer standard queries.
1159 Both the query and its response are carried in a standard message format
1160 which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
1161 and QNAME, which describe the types and classes of desired information
1162 and the name of interest.
1163
1164 The way that the name server answers the query depends upon whether it
1165 is operating in recursive mode or not:
1166
1167 - The simplest mode for the server is non-recursive, since it
1168 can answer queries using only local information: the response
1169 contains an error, the answer, or a referral to some other
1170 server "closer" to the answer. All name servers must
1171 implement non-recursive queries.
1172
1173 - The simplest mode for the client is recursive, since in this
1174 mode the name server acts in the role of a resolver and
1175 returns either an error or the answer, but never referrals.
1176 This service is optional in a name server, and the name server
1177 may also choose to restrict the clients which can use
1178 recursive mode.
1179
1180 Recursive service is helpful in several situations:
1181
1182 - a relatively simple requester that lacks the ability to use
1183 anything other than a direct answer to the question.
1184
1185 - a request that needs to cross protocol or other boundaries and
1186 can be sent to a server which can act as intermediary.
1187
1188 - a network where we want to concentrate the cache rather than
1189 having a separate cache for each client.
1190
1191 Non-recursive service is appropriate if the requester is capable of
1192 pursuing referrals and interested in information which will aid future
1193 requests.
1194
1195 The use of recursive mode is limited to cases where both the client and
1196 the name server agree to its use. The agreement is negotiated through
1197 the use of two bits in query and response messages:
1198
1199 - The recursion available, or RA bit, is set or cleared by a
1200 name server in all responses. The bit is true if the name
1201 server is willing to provide recursive service for the client,
1202 regardless of whether the client requested recursive service.
1203 That is, RA signals availability rather than use.
1204
1205
1206
1207 Mockapetris [Page 22]
1208 RFC 1034 Domain Concepts and Facilities November 1987
1209
1210
1211 - Queries contain a bit called recursion desired or RD. This
1212 bit specifies specifies whether the requester wants recursive
1213 service for this query. Clients may request recursive service
1214 from any name server, though they should depend upon receiving
1215 it only from servers which have previously sent an RA, or
1216 servers which have agreed to provide service through private
1217 agreement or some other means outside of the DNS protocol.
1218
1219 The recursive mode occurs when a query with RD set arrives at a server
1220 which is willing to provide recursive service; the client can verify
1221 that recursive mode was used by checking that both RA and RD are set in
1222 the reply. Note that the name server should never perform recursive
1223 service unless asked via RD, since this interferes with trouble shooting
1224 of name servers and their databases.
1225
1226 If recursive service is requested and available, the recursive response
1227 to a query will be one of the following:
1228
1229 - The answer to the query, possibly preface by one or more CNAME
1230 RRs that specify aliases encountered on the way to an answer.
1231
1232 - A name error indicating that the name does not exist. This
1233 may include CNAME RRs that indicate that the original query
1234 name was an alias for a name which does not exist.
1235
1236 - A temporary error indication.
1237
1238 If recursive service is not requested or is not available, the non-
1239 recursive response will be one of the following:
1240
1241 - An authoritative name error indicating that the name does not
1242 exist.
1243
1244 - A temporary error indication.
1245
1246 - Some combination of:
1247
1248 RRs that answer the question, together with an indication
1249 whether the data comes from a zone or is cached.
1250
1251 A referral to name servers which have zones which are closer
1252 ancestors to the name than the server sending the reply.
1253
1254 - RRs that the name server thinks will prove useful to the
1255 requester.
1256
1257
1258
1259
1260
1261
1262 Mockapetris [Page 23]
1263 RFC 1034 Domain Concepts and Facilities November 1987
1264
1265
1266 4.3.2. Algorithm
1267
1268 The actual algorithm used by the name server will depend on the local OS
1269 and data structures used to store RRs. The following algorithm assumes
1270 that the RRs are organized in several tree structures, one for each
1271 zone, and another for the cache:
1272
1273 1. Set or clear the value of recursion available in the response
1274 depending on whether the name server is willing to provide
1275 recursive service. If recursive service is available and
1276 requested via the RD bit in the query, go to step 5,
1277 otherwise step 2.
1278
1279 2. Search the available zones for the zone which is the nearest
1280 ancestor to QNAME. If such a zone is found, go to step 3,
1281 otherwise step 4.
1282
1283 3. Start matching down, label by label, in the zone. The
1284 matching process can terminate several ways:
1285
1286 a. If the whole of QNAME is matched, we have found the
1287 node.
1288
1289 If the data at the node is a CNAME, and QTYPE doesn't
1290 match CNAME, copy the CNAME RR into the answer section
1291 of the response, change QNAME to the canonical name in
1292 the CNAME RR, and go back to step 1.
1293
1294 Otherwise, copy all RRs which match QTYPE into the
1295 answer section and go to step 6.
1296
1297 b. If a match would take us out of the authoritative data,
1298 we have a referral. This happens when we encounter a
1299 node with NS RRs marking cuts along the bottom of a
1300 zone.
1301
1302 Copy the NS RRs for the subzone into the authority
1303 section of the reply. Put whatever addresses are
1304 available into the additional section, using glue RRs
1305 if the addresses are not available from authoritative
1306 data or the cache. Go to step 4.
1307
1308 c. If at some label, a match is impossible (i.e., the
1309 corresponding label does not exist), look to see if a
1310 the "*" label exists.
1311
1312 If the "*" label does not exist, check whether the name
1313 we are looking for is the original QNAME in the query
1314
1315
1316
1317 Mockapetris [Page 24]
1318 RFC 1034 Domain Concepts and Facilities November 1987
1319
1320
1321 or a name we have followed due to a CNAME. If the name
1322 is original, set an authoritative name error in the
1323 response and exit. Otherwise just exit.
1324
1325 If the "*" label does exist, match RRs at that node
1326 against QTYPE. If any match, copy them into the answer
1327 section, but set the owner of the RR to be QNAME, and
1328 not the node with the "*" label. Go to step 6.
1329
1330 4. Start matching down in the cache. If QNAME is found in the
1331 cache, copy all RRs attached to it that match QTYPE into the
1332 answer section. If there was no delegation from
1333 authoritative data, look for the best one from the cache, and
1334 put it in the authority section. Go to step 6.
1335
1336 5. Using the local resolver or a copy of its algorithm (see
1337 resolver section of this memo) to answer the query. Store
1338 the results, including any intermediate CNAMEs, in the answer
1339 section of the response.
1340
RFC8482 gives guidance on what the proper response to and query for type ANY would be. In particular, Section 7 of RFC 8482 updates the processing instructions in RFC 1034 for ANY queries.
1341 6. Using local data only, attempt to add other RRs which may be
1342 useful to the additional section of the query. Exit.
1343
1344 4.3.3. Wildcards
1345
1346 In the previous algorithm, special treatment was given to RRs with owner
1347 names starting with the label "*". Such RRs are called wildcards.
1348 Wildcard RRs can be thought of as instructions for synthesizing RRs.
1349 When the appropriate conditions are met, the name server creates RRs
1350 with an owner name equal to the query name and contents taken from the
1351 wildcard RRs.
1352
1353 This facility is most often used to create a zone which will be used to
1354 forward mail from the Internet to some other mail system. The general
1355 idea is that any name in that zone which is presented to server in a
1356 query will be assumed to exist, with certain properties, unless explicit
1357 evidence exists to the contrary. Note that the use of the term zone
1358 here, instead of domain, is intentional; such defaults do not propagate
1359 across zone boundaries, although a subzone may choose to achieve that
1360 appearance by setting up similar defaults.
1361
1362 The contents of the wildcard RRs follows the usual rules and formats for
1363 RRs. The wildcards in the zone have an owner name that controls the
1364 query names they will match. The owner name of the wildcard RRs is of
1365 the form "*.<anydomain>", where <anydomain> is any domain name.
1366 <anydomain> should not contain other * labels, and should be in the
1367 authoritative data of the zone. The wildcards potentially apply to
1368 descendants of <anydomain>, but not to <anydomain> itself. Another way
1369
1370
1371
1372 Mockapetris [Page 25]
1373 RFC 1034 Domain Concepts and Facilities November 1987
1374
1375
1376 to look at this is that the "*" label always matches at least one whole
1377 label and sometimes more, but always whole labels.
1378
1379 Wildcard RRs do not apply:
1380
1381 - When the query is in another zone. That is, delegation cancels
1382 the wildcard defaults.
1383
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the queryresponse. Exit.
1384 - When the query name or a name between the wildcard domain and
1385 the query name is know to exist. For example, if a wildcard
1386 RR has an owner name of "*.X", and the zone also contains RRs
1387 attached to B.X, the wildcards would apply to queries for name
1388 Z.X (presuming there is no explicit information for Z.X), but
1389 not to B.X, A.B.X, or X.
1390
- When the query name or a name between the wildcard domain and
the query name is know to exist.
- When the query name or a name between the wildcard domain and
the query name is known to exist.
1391 A * label appearing in a query name has no special effect, but can be
1392 used to test for wildcards in an authoritative zone; such a query is the
1393 only way to get a response containing RRs with an owner name with * in
1394 it. The result of such a query should not be cached.
1395
1396 Note that the contents of the wildcard RRs are not modified when used to
1397 synthesize RRs.
1398
1399 To illustrate the use of wildcard RRs, suppose a large company with a
1400 large, non-IP/TCP, network wanted to create a mail gateway. If the
1401 company was called X.COM, and IP/TCP capable gateway machine was called
1402 A.X.COM, the following RRs might be entered into the COM zone:
1403
1404 X.COM MX 10 A.X.COM
1405
1406 *.X.COM MX 10 A.X.COM
1407
1408 A.X.COM A 1.2.3.4
1409 A.X.COM MX 10 A.X.COM
1410
1411 *.A.X.COM MX 10 A.X.COM
1412
1413 This would cause any MX query for any domain name ending in X.COM to
1414 return an MX RR pointing at A.X.COM. Two wildcard RRs are required
1415 since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
1416 subtree by the explicit data for A.X.COM. Note also that the explicit
1417 MX data at X.COM and A.X.COM is required, and that none of the RRs above
1418 would match a query name of XX.COM.
1419
A * label appearing in a query name has no special effect, but can be used to test for wildcards in an authoritative zone; such a query is the only way to get a response containing RRs with an owner name with * in it. The result of such a query should not be cached.
A * label appearing in a query name has no special effect, but can be used to test for wildcards in an authoritative zone; such a query is the only way to get a response containing RRs with an owner name with * in it. The result of such a query should not becachedused to synthesize RRs.
1420 4.3.4. Negative response caching (Optional)
1421
1422 The DNS provides an optional service which allows name servers to
1423 distribute, and resolvers to cache, negative results with TTLs. For
1424
1425
1426
1427 Mockapetris [Page 26]
1428 RFC 1034 Domain Concepts and Facilities November 1987
1429
1430
1431 example, a name server can distribute a TTL along with a name error
1432 indication, and a resolver receiving such information is allowed to
1433 assume that the name does not exist during the TTL period without
1434 consulting authoritative data. Similarly, a resolver can make a query
1435 with a QTYPE which matches multiple types, and cache the fact that some
1436 of the types are not present.
1437
Section 7.1 of RFC2181 says:
RFC1034, in section 3.7, indicates that the authority section of an authoritative answer may contain the SOA record for the zone from which the answer was obtained. When discussing negative caching, RFC1034 section 4.3.4 refers to this technique but mentions the additional section of the response. The former is correct, as is implied by the example shown in section 6.2.5 of RFC1034. SOA records, if added, are to be placed in the authority section.
RFC2308 is a major restatement and update to how negative caching should
be implemented. Its abstract begins:
[RFC1034] provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section 4.3.4].
1438 This feature can be particularly important in a system which implements
1439 naming shorthands that use search lists beacuse a popular shorthand,
1440 which happens to require a suffix toward the end of the search list,
1441 will generate multiple name errors whenever it is used.
1442
1443 The method is that a name server may add an SOA RR to the additional
1444 section of a response when that response is authoritative. The SOA must
1445 be that of the zone which was the source of the authoritative data in
1446 the answer section, or name error if applicable. The MINIMUM field of
1447 the SOA controls the length of time that the negative result may be
1448 cached.
1449
1450 Note that in some circumstances, the answer section may contain multiple
1451 owner names. In this case, the SOA mechanism should only be used for
1452 the data which matches QNAME, which is the only authoritative data in
1453 this section.
1454
1455 Name servers and resolvers should never attempt to add SOAs to the
1456 additional section of a non-authoritative response, or attempt to infer
1457 results which are not directly stated in an authoritative response.
1458 There are several reasons for this, including: cached information isn't
1459 usually enough to match up RRs and their zone names, SOA RRs may be
1460 cached due to direct SOA queries, and name servers are not required to
1461 output the SOAs in the authority section.
1462
1463 This feature is optional, although a refined version is expected to
1464 become part of the standard protocol in the future. Name servers are
1465 not required to add the SOA RRs in all authoritative responses, nor are
1466 resolvers required to cache negative results. Both are recommended.
1467 All resolvers and recursive name servers are required to at least be
1468 able to ignore the SOA RR when it is present in a response.
1469
1470 Some experiments have also been proposed which will use this feature.
1471 The idea is that if cached data is known to come from a particular zone,
1472 and if an authoritative copy of the zone's SOA is obtained, and if the
1473 zone's SERIAL has not changed since the data was cached, then the TTL of
1474 the cached data can be reset to the zone MINIMUM value if it is smaller.
1475 This usage is mentioned for planning purposes only, and is not
1476 recommended as yet.
1477
1478
1479
1480
1481
1482 Mockapetris [Page 27]
1483 RFC 1034 Domain Concepts and Facilities November 1987
1484
1485
1486 4.3.5. Zone maintenance and transfers
1487
1488 Part of the job of a zone administrator is to maintain the zones at all
1489 of the name servers which are authoritative for the zone. When the
1490 inevitable changes are made, they must be distributed to all of the name
1491 servers. While this distribution can be accomplished using FTP or some
1492 other ad hoc procedure, the preferred method is the zone transfer part
1493 of the DNS protocol.
1494
1495 The general model of automatic zone transfer or refreshing is that one
1496 of the name servers is the master or primary for the zone. Changes are
1497 coordinated at the primary, typically by editing a master file for the
1498 zone. After editing, the administrator signals the master server to
1499 load the new zone. The other non-master or secondary servers for the
1500 zone periodically check for changes (at a selectable interval) and
1501 obtain new zone copies when changes have been made.
1502
This feature can be particularly important in a system which implements naming short shorts that use search lists beacuse a popular shorthand,
This feature can be particularly important in a system which implements naming short shorts that use search listsbeacusebecause a popular shorthand,
1503 To detect changes, secondaries just check the SERIAL field of the SOA
1504 for the zone. In addition to whatever other changes are made, the
1505 SERIAL field in the SOA of the zone is always advanced whenever any
1506 change is made to the zone. The advancing can be a simple increment, or
1507 could be based on the write date and time of the master file, etc. The
1508 purpose is to make it possible to determine which of two copies of a
1509 zone is more recent by comparing serial numbers. Serial number advances
1510 and comparisons use sequence space arithmetic, so there is a theoretic
1511 limit on how fast a zone can be updated, basically that old copies must
1512 die out before the serial number covers half of its 32 bit range. In
1513 practice, the only concern is that the compare operation deals properly
1514 with comparisons around the boundary between the most positive and most
1515 negative 32 bit numbers.
1516
1517 The periodic polling of the secondary servers is controlled by
1518 parameters in the SOA RR for the zone, which set the minimum acceptable
1519 polling intervals. The parameters are called REFRESH, RETRY, and
1520 EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
1521 waits REFRESH seconds before checking with the primary for a new serial.
1522 If this check cannot be completed, new checks are started every RETRY
1523 seconds. The check is a simple query to the primary for the SOA RR of
1524 the zone. If the serial field in the secondary's zone copy is equal to
1525 the serial returned by the primary, then no changes have occurred, and
1526 the REFRESH interval wait is restarted. If the secondary finds it
RFC1982 clarifies how serial number arithmetic should be performed. The abstract says "The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition."
1527 impossible to perform a serial check for the EXPIRE interval, it must
1528 assume that its copy of the zone is obsolete an discard it.
1529
1530 When the poll shows that the zone has changed, then the secondary server
1531 must request a zone transfer via an AXFR request for the zone. The AXFR
1532 may cause an error, such as refused, but normally is answered by a
1533 sequence of response messages. The first and last messages must contain
1534
1535
1536
1537 Mockapetris [Page 28]
1538 RFC 1034 Domain Concepts and Facilities November 1987
1539
1540
1541 the data for the top authoritative node of the zone. Intermediate
1542 messages carry all of the other RRs from the zone, including both
1543 authoritative and non-authoritative RRs. The stream of messages allows
1544 the secondary to construct a copy of the zone. Because accuracy is
1545 essential, TCP or some other reliable protocol must be used for AXFR
1546 requests.
1547
1548 Each secondary server is required to perform the following operations
1549 against the master, but may also optionally perform these operations
1550 against other secondary servers. This strategy can improve the transfer
1551 process when the primary is unavailable due to host downtime or network
1552 problems, or when a secondary server has better network access to an
1553 "intermediate" secondary than to the primary.
1554
1555 5. RESOLVERS
1556
1557 5.1. Introduction
1558
1559 Resolvers are programs that interface user programs to domain name
1560 servers. In the simplest case, a resolver receives a request from a
1561 user program (e.g., mail programs, TELNET, FTP) in the form of a
1562 subroutine call, system call etc., and returns the desired information
1563 in a form compatible with the local host's data formats.
1564
1565 The resolver is located on the same machine as the program that requests
1566 the resolver's services, but it may need to consult name servers on
1567 other hosts. Because a resolver may need to consult several name
1568 servers, or may have the requested information in a local cache, the
1569 amount of time that a resolver will take to complete can vary quite a
1570 bit, from milliseconds to several seconds.
1571
1572 A very important goal of the resolver is to eliminate network delay and
1573 name server load from most requests by answering them from its cache of
1574 prior results. It follows that caches which are shared by multiple
1575 processes, users, machines, etc., are more efficient than non-shared
1576 caches.
1577
1578 5.2. Client-resolver interface
1579
1580 5.2.1. Typical functions
1581
1582 The client interface to the resolver is influenced by the local host's
1583 conventions, but the typical resolver-client interface has three
1584 functions:
1585
1586 1. Host name to host address translation.
1587
1588 This function is often defined to mimic a previous HOSTS.TXT
1589
1590
1591
1592 Mockapetris [Page 29]
1593 RFC 1034 Domain Concepts and Facilities November 1987
1594
1595
1596 based function. Given a character string, the caller wants
1597 one or more 32 bit IP addresses. Under the DNS, it
1598 translates into a request for type A RRs. Since the DNS does
1599 not preserve the order of RRs, this function may choose to
1600 sort the returned addresses or select the "best" address if
1601 the service returns only one choice to the client. Note that
1602 a multiple address return is recommended, but a single
1603 address may be the only way to emulate prior HOSTS.TXT
1604 services.
1605
1606 2. Host address to host name translation
1607
1608 This function will often follow the form of previous
1609 functions. Given a 32 bit IP address, the caller wants a
1610 character string. The octets of the IP address are reversed,
1611 used as name components, and suffixed with "IN-ADDR.ARPA". A
1612 type PTR query is used to get the RR with the primary name of
1613 the host. For example, a request for the host name
1614 corresponding to IP address 1.2.3.4 looks for PTR RRs for
1615 domain name "4.3.2.1.IN-ADDR.ARPA".
1616
1617 3. General lookup function
1618
1619 This function retrieves arbitrary information from the DNS,
1620 and has no counterpart in previous systems. The caller
1621 supplies a QNAME, QTYPE, and QCLASS, and wants all of the
1622 matching RRs. This function will often use the DNS format
1623 for all RR data instead of the local host's, and returns all
1624 RR content (e.g., TTL) instead of a processed form with local
1625 quoting conventions.
1626
1627 When the resolver performs the indicated function, it usually has one of
1628 the following results to pass back to the client:
1629
1630 - One or more RRs giving the requested data.
1631
1632 In this case the resolver returns the answer in the
1633 appropriate format.
1634
1635 - A name error (NE).
1636
1637 This happens when the referenced name does not exist. For
1638 example, a user may have mistyped a host name.
1639
1640 - A data not found error.
1641
1642 This happens when the referenced name exists, but data of the
1643 appropriate type does not. For example, a host address
1644
1645
1646
1647 Mockapetris [Page 30]
1648 RFC 1034 Domain Concepts and Facilities November 1987
1649
1650
1651 function applied to a mailbox name would return this error
1652 since the name exists, but no address RR is present.
1653
1654 It is important to note that the functions for translating between host
1655 names and addresses may combine the "name error" and "data not found"
1656 error conditions into a single type of error return, but the general
1657 function should not. One reason for this is that applications may ask
1658 first for one type of information about a name followed by a second
1659 request to the same name for some other type of information; if the two
1660 errors are combined, then useless queries may slow the application.
1661
1662 5.2.2. Aliases
1663
1664 While attempting to resolve a particular request, the resolver may find
1665 that the name in question is an alias. For example, the resolver might
1666 find that the name given for host name to address translation is an
1667 alias when it finds the CNAME RR. If possible, the alias condition
1668 should be signalled back from the resolver to the client.
1669
1670 In most cases a resolver simply restarts the query at the new name when
1671 it encounters a CNAME. However, when performing the general function,
1672 the resolver should not pursue aliases when the CNAME RR matches the
1673 query type. This allows queries which ask whether an alias is present.
1674 For example, if the query type is CNAME, the user is interested in the
1675 CNAME RR itself, and not the RRs at the name it points to.
1676
1677 Several special conditions can occur with aliases. Multiple levels of
1678 aliases should be avoided due to their lack of efficiency, but should
1679 not be signalled as an error. Alias loops and aliases which point to
1680 non-existent names should be caught and an error condition passed back
1681 to the client.
1682
1683 5.2.3. Temporary failures
1684
1685 In a less than perfect world, all resolvers will occasionally be unable
1686 to resolve a particular request. This condition can be caused by a
1687 resolver which becomes separated from the rest of the network due to a
1688 link failure or gateway problem, or less often by coincident failure or
1689 unavailability of all servers for a particular domain.
1690
1691 It is essential that this sort of condition should not be signalled as a
1692 name or data not present error to applications. This sort of behavior
1693 is annoying to humans, and can wreak havoc when mail systems use the
1694 DNS.
1695
1696 While in some cases it is possible to deal with such a temporary problem
1697 by blocking the request indefinitely, this is usually not a good choice,
1698 particularly when the client is a server process that could move on to
1699
1700
1701
1702 Mockapetris [Page 31]
1703 RFC 1034 Domain Concepts and Facilities November 1987
1704
1705
1706 other tasks. The recommended solution is to always have temporary
1707 failure as one of the possible results of a resolver function, even
1708 though this may make emulation of existing HOSTS.TXT functions more
1709 difficult.
1710
1711 5.3. Resolver internals
1712
1713 Every resolver implementation uses slightly different algorithms, and
1714 typically spends much more logic dealing with errors of various sorts
RFC5936 is a complete re-definition of AXFR. Its abstract says: "The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism."
1715 than typical occurances. This section outlines a recommended basic
1716 strategy for resolver operation, but leaves details to [RFC-1035].
1717
1718 5.3.1. Stub resolvers
1719
1720 One option for implementing a resolver is to move the resolution
1721 function out of the local machine and into a name server which supports
1722 recursive queries. This can provide an easy method of providing domain
1723 service in a PC which lacks the resources to perform the resolver
1724 function, or can centralize the cache for a whole local network or
1725 organization.
1726
1727 All that the remaining stub needs is a list of name server addresses
1728 that will perform the recursive requests. This type of resolver
1729 presumably needs the information in a configuration file, since it
1730 probably lacks the sophistication to locate it in the domain database.
1731 The user also needs to verify that the listed servers will perform the
1732 recursive service; a name server is free to refuse to perform recursive
1733 services for any or all clients. The user should consult the local
1734 system administrator to find name servers willing to perform the
1735 service.
1736
1737 This type of service suffers from some drawbacks. Since the recursive
1738 requests may take an arbitrary amount of time to perform, the stub may
1739 have difficulty optimizing retransmission intervals to deal with both
1740 lost UDP packets and dead servers; the name server can be easily
1741 overloaded by too zealous a stub if it interprets retransmissions as new
1742 requests. Use of TCP may be an answer, but TCP may well place burdens
1743 on the host's capabilities which are similar to those of a real
1744 resolver.
1745
1746 5.3.2. Resources
1747
1748 In addition to its own resources, the resolver may also have shared
1749 access to zones maintained by a local name server. This gives the
1750 resolver the advantage of more rapid access, but the resolver must be
1751 careful to never let cached information override zone data. In this
1752 discussion the term "local information" is meant to mean the union of
1753 the cache and such shared zones, with the understanding that
1754
1755
1756
1757 Mockapetris [Page 32]
1758 RFC 1034 Domain Concepts and Facilities November 1987
1759
1760
1761 authoritative data is always used in preference to cached data when both
1762 are present.
1763
1764 The following resolver algorithm assumes that all functions have been
1765 converted to a general lookup function, and uses the following data
1766 structures to represent the state of a request in progress in the
1767 resolver:
1768
1769 SNAME the domain name we are searching for.
1770
1771 STYPE the QTYPE of the search request.
1772
1773 SCLASS the QCLASS of the search request.
1774
1775 SLIST a structure which describes the name servers and the
1776 zone which the resolver is currently trying to query.
1777 This structure keeps track of the resolver's current
1778 best guess about which name servers hold the desired
1779 information; it is updated when arriving information
1780 changes the guess. This structure includes the
1781 equivalent of a zone name, the known name servers for
1782 the zone, the known addresses for the name servers, and
1783 history information which can be used to suggest which
1784 server is likely to be the best one to try next. The
1785 zone name equivalent is a match count of the number of
1786 labels from the root down which SNAME has in common with
1787 the zone being queried; this is used as a measure of how
1788 "close" the resolver is to SNAME.
1789
1790 SBELT a "safety belt" structure of the same form as SLIST,
1791 which is initialized from a configuration file, and
1792 lists servers which should be used when the resolver
1793 doesn't have any local information to guide name server
1794 selection. The match count will be -1 to indicate that
1795 no labels are known to match.
1796
1797 CACHE A structure which stores the results from previous
1798 responses. Since resolvers are responsible for
1799 discarding old RRs whose TTL has expired, most
1800 implementations convert the interval specified in
1801 arriving RRs to some sort of absolute time when the RR
1802 is stored in the cache. Instead of counting the TTLs
1803 down individually, the resolver just ignores or discards
1804 old RRs when it runs across them in the course of a
1805 search, or discards them during periodic sweeps to
1806 reclaim the memory consumed by old RRs.
1807
1808
1809
1810
1811
1812 Mockapetris [Page 33]
1813 RFC 1034 Domain Concepts and Facilities November 1987
1814
1815
1816 5.3.3. Algorithm
1817
1818 The top level algorithm has four steps:
1819
1820 1. See if the answer is in local information, and if so return
1821 it to the client.
1822
1823 2. Find the best servers to ask.
1824
1825 3. Send them queries until one returns a response.
1826
1827 4. Analyze the response, either:
1828
1829 a. if the response answers the question or contains a name
1830 error, cache the data as well as returning it back to
1831 the client.
1832
1833 b. if the response contains a better delegation to other
1834 servers, cache the delegation information, and go to
1835 step 2.
1836
1837 c. if the response shows a CNAME and that is not the
1838 answer itself, cache the CNAME, change the SNAME to the
1839 canonical name in the CNAME RR and go to step 1.
1840
1841 d. if the response shows a servers failure or other
1842 bizarre contents, delete the server from the SLIST and
1843 go back to step 3.
1844
1845 Step 1 searches the cache for the desired data. If the data is in the
1846 cache, it is assumed to be good enough for normal use. Some resolvers
1847 have an option at the user interface which will force the resolver to
1848 ignore the cached data and consult with an authoritative server. This
1849 is not recommended as the default. If the resolver has direct access to
1850 a name server's zones, it should check to see if the desired data is
1851 present in authoritative form, and if so, use the authoritative data in
1852 preference to cached data.
1853
1854 Step 2 looks for a name server to ask for the required data. The
1855 general strategy is to look for locally-available name server RRs,
1856 starting at SNAME, then the parent domain name of SNAME, the
1857 grandparent, and so on toward the root. Thus if SNAME were
1858 Mockapetris.ISI.EDU, this step would look for NS RRs for
1859 Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
1860 These NS RRs list the names of hosts for a zone at or above SNAME. Copy
1861 the names into SLIST. Set up their addresses using local data. It may
1862 be the case that the addresses are not available. The resolver has many
1863 choices here; the best is to start parallel resolver processes looking
1864
1865
1866
1867 Mockapetris [Page 34]
1868 RFC 1034 Domain Concepts and Facilities November 1987
1869
1870
1871 for the addresses while continuing onward with the addresses which are
1872 available. Obviously, the design choices and options are complicated
1873 and a function of the local host's capabilities. The recommended
1874 priorities for the resolver designer are:
1875
1876 1. Bound the amount of work (packets sent, parallel processes
1877 started) so that a request can't get into an infinite loop or
1878 start off a chain reaction of requests or queries with other
1879 implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
1880 SOME DATA.
1881
1882 2. Get back an answer if at all possible.
1883
1884 3. Avoid unnecessary transmissions.
1885
1886 4. Get the answer as quickly as possible.
1887
1888 If the search for NS RRs fails, then the resolver initializes SLIST from
1889 the safety belt SBELT. The basic idea is that when the resolver has no
1890 idea what servers to ask, it should use information from a configuration
1891 file that lists several servers which are expected to be helpful.
1892 Although there are special situations, the usual choice is two of the
1893 root servers and two of the servers for the host's domain. The reason
1894 for two of each is for redundancy. The root servers will provide
1895 eventual access to all of the domain space. The two local servers will
1896 allow the resolver to continue to resolve local names if the local
1897 network becomes isolated from the internet due to gateway or link
1898 failure.
1899
1900 In addition to the names and addresses of the servers, the SLIST data
1901 structure can be sorted to use the best servers first, and to insure
1902 that all addresses of all servers are used in a round-robin manner. The
1903 sorting can be a simple function of preferring addresses on the local
1904 network over others, or may involve statistics from past events, such as
1905 previous response times and batting averages.
1906
1907 Step 3 sends out queries until a response is received. The strategy is
1908 to cycle around all of the addresses for all of the servers with a
1909 timeout between each transmission. In practice it is important to use
1910 all addresses of a multihomed host, and too aggressive a retransmission
1911 policy actually slows response when used by multiple resolvers
1912 contending for the same name server and even occasionally for a single
1913 resolver. SLIST typically contains data values to control the timeouts
1914 and keep track of previous transmissions.
1915
1916 Step 4 involves analyzing responses. The resolver should be highly
1917 paranoid in its parsing of responses. It should also check that the
1918 response matches the query it sent using the ID field in the response.
1919
1920
1921
1922 Mockapetris [Page 35]
1923 RFC 1034 Domain Concepts and Facilities November 1987
1924
1925
1926 The ideal answer is one from a server authoritative for the query which
1927 either gives the required data or a name error. The data is passed back
1928 to the user and entered in the cache for future use if its TTL is
1929 greater than zero.
1930
1931 If the response shows a delegation, the resolver should check to see
1932 that the delegation is "closer" to the answer than the servers in SLIST
1933 are. This can be done by comparing the match count in SLIST with that
1934 computed from SNAME and the NS RRs in the delegation. If not, the reply
1935 is bogus and should be ignored. If the delegation is valid the NS
1936 delegation RRs and any address RRs for the servers should be cached.
1937 The name servers are entered in the SLIST, and the search is restarted.
1938
1939 If the response contains a CNAME, the search is restarted at the CNAME
1940 unless the response has the data for the canonical name or if the CNAME
1941 is the answer itself.
1942
1943 Details and implementation hints can be found in [RFC-1035].
1944
1945 6. A SCENARIO
1946
1947 In our sample domain space, suppose we wanted separate administrative
1948 control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
1949 allocate name servers as follows:
1950
1951
1952 |(C.ISI.EDU,SRI-NIC.ARPA
1953 | A.ISI.EDU)
1954 +---------------------+------------------+
1955 | | |
1956 MIL EDU ARPA
1957 |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
1958 | A.ISI.EDU | C.ISI.EDU) |
1959 +-----+-----+ | +------+-----+-----+
1960 | | | | | | |
1961 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
1962 |
1963 +--------+------------------+---------------+--------+
1964 | | | | |
1965 UCI MIT | UDEL YALE
1966 |(XX.LCS.MIT.EDU, ISI
1967 |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
1968 +---+---+ | A.ISI.EDU)
1969 | | |
1970 LCS ACHILLES +--+-----+-----+--------+
1971 | | | | | |
1972 XX A C VAXA VENERA Mockapetris
1973
1974
1975
1976
1977 Mockapetris [Page 36]
1978 RFC 1034 Domain Concepts and Facilities November 1987
1979
1980
1981 In this example, the authoritative name server is shown in parentheses
1982 at the point in the domain tree at which is assumes control.
1983
1984 Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
1985 A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
1986 EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
1987 may have zones which are contiguous or disjoint. In this scenario,
1988 C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
1989 has contiguous zones at the root and MIL domains, but also has a non-
1990 contiguous zone at ISI.EDU.
1991
1992 6.1. C.ISI.EDU name server
1993
1994 C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
1995 class, and would have zones for these domains. The zone data for the
1996 root domain might be:
1997
1998 . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
1999 870611 ;serial
2000 1800 ;refresh every 30 min
2001 300 ;retry every 5 min
2002 604800 ;expire after a week
2003 86400) ;minimum of a day
2004 NS A.ISI.EDU.
2005 NS C.ISI.EDU.
2006 NS SRI-NIC.ARPA.
2007
2008 MIL. 86400 NS SRI-NIC.ARPA.
2009 86400 NS A.ISI.EDU.
2010
2011 EDU. 86400 NS SRI-NIC.ARPA.
2012 86400 NS C.ISI.EDU.
2013
2014 SRI-NIC.ARPA. A 26.0.0.73
2015 A 10.0.0.51
2016 MX 0 SRI-NIC.ARPA.
2017 HINFO DEC-2060 TOPS20
2018
2019 ACC.ARPA. A 26.6.0.65
2020 HINFO PDP-11/70 UNIX
2021 MX 10 ACC.ARPA.
2022
2023 USC-ISIC.ARPA. CNAME C.ISI.EDU.
2024
2025 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2026 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
2027 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2028 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
2029
2030
2031
2032 Mockapetris [Page 37]
2033 RFC 1034 Domain Concepts and Facilities November 1987
2034
2035
2036 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
2037
2038 A.ISI.EDU. 86400 A 26.3.0.103
2039 C.ISI.EDU. 86400 A 10.0.0.52
2040
2041 This data is represented as it would be in a master file. Most RRs are
2042 single line entries; the sole exception here is the SOA RR, which uses
2043 "(" to start a multi-line RR and ")" to show the end of a multi-line RR.
2044 Since the class of all RRs in a zone must be the same, only the first RR
2045 in a zone need specify the class. When a name server loads a zone, it
2046 forces the TTL of all authoritative RRs to be at least the MINIMUM field
2047 of the SOA, here 86400 seconds, or one day. The NS RRs marking
2048 delegation of the MIL and EDU domains, together with the glue RRs for
2049 the servers host addresses, are not part of the authoritative data in
2050 the zone, and hence have explicit TTLs.
2051
2052 Four RRs are attached to the root node: the SOA which describes the root
2053 zone and the 3 NS RRs which list the name servers for the root. The
2054 data in the SOA RR describes the management of the zone. The zone data
2055 is maintained on host SRI-NIC.ARPA, and the responsible party for the
2056 zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
2057 second minimum TTL, which means that all authoritative data in the zone
2058 has at least that TTL, although higher values may be explicitly
2059 specified.
2060
2061 The NS RRs for the MIL and EDU domains mark the boundary between the
2062 root zone and the MIL and EDU zones. Note that in this example, the
2063 lower zones happen to be supported by name servers which also support
2064 the root zone.
2065
2066 The master file for the EDU zone might be stated relative to the origin
2067 EDU. The zone data for the EDU domain might be:
2068
2069 EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
2070 870729 ;serial
2071 1800 ;refresh every 30 minutes
2072 300 ;retry every 5 minutes
2073 604800 ;expire after a week
2074 86400 ;minimum of a day
2075 )
2076 NS SRI-NIC.ARPA.
2077 NS C.ISI.EDU.
2078
2079 UCI 172800 NS ICS.UCI
2080 172800 NS ROME.UCI
2081 ICS.UCI 172800 A 192.5.19.1
2082 ROME.UCI 172800 A 192.5.19.31
2083
2084
2085
2086
2087 Mockapetris [Page 38]
2088 RFC 1034 Domain Concepts and Facilities November 1987
2089
2090
2091 ISI 172800 NS VAXA.ISI
2092 172800 NS A.ISI
2093 172800 NS VENERA.ISI.EDU.
2094 VAXA.ISI 172800 A 10.2.0.27
2095 172800 A 128.9.0.33
2096 VENERA.ISI.EDU. 172800 A 10.1.0.52
2097 172800 A 128.9.0.32
2098 A.ISI 172800 A 26.3.0.103
2099
2100 UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
2101 172800 NS UMN-REI-UC.ARPA.
2102 LOUIE.UDEL.EDU. 172800 A 10.0.0.96
2103 172800 A 192.5.39.3
2104
2105 YALE.EDU. 172800 NS YALE.ARPA.
2106 YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
2107
2108 MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
2109 43200 NS ACHILLES.MIT.EDU.
2110 XX.LCS.MIT.EDU. 43200 A 10.0.0.44
2111 ACHILLES.MIT.EDU. 43200 A 18.72.0.8
2112
2113 Note the use of relative names here. The owner name for the ISI.EDU. is
2114 stated using a relative name, as are two of the name server RR contents.
2115 Relative and absolute domain names may be freely intermixed in a master
2116
2117 6.2. Example standard queries
2118
2119 The following queries and responses illustrate name server behavior.
2120 Unless otherwise noted, the queries do not have recursion desired (RD)
2121 in the header. Note that the answers to non-recursive queries do depend
2122 on the server being asked, but do not depend on the identity of the
2123 requester.
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142 Mockapetris [Page 39]
2143 RFC 1034 Domain Concepts and Facilities November 1987
2144
2145
2146 6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
2147
2148 The query would look like:
2149
2150 +---------------------------------------------------+
2151 Header | OPCODE=SQUERY |
2152 +---------------------------------------------------+
2153 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2154 +---------------------------------------------------+
2155 Answer | <empty> |
2156 +---------------------------------------------------+
2157 Authority | <empty> |
2158 +---------------------------------------------------+
2159 Additional | <empty> |
2160 +---------------------------------------------------+
2161
2162 The response from C.ISI.EDU would be:
2163
2164 +---------------------------------------------------+
2165 Header | OPCODE=SQUERY, RESPONSE, AA |
2166 +---------------------------------------------------+
2167 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2168 +---------------------------------------------------+
2169 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2170 | 86400 IN A 10.0.0.51 |
2171 +---------------------------------------------------+
2172 Authority | <empty> |
2173 +---------------------------------------------------+
2174 Additional | <empty> |
2175 +---------------------------------------------------+
2176
2177 The header of the response looks like the header of the query, except
2178 that the RESPONSE bit is set, indicating that this message is a
2179 response, not a query, and the Authoritative Answer (AA) bit is set
2180 indicating that the address RRs in the answer section are from
2181 authoritative data. The question section of the response matches the
2182 question section of the query.
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197 Mockapetris [Page 40]
2198 RFC 1034 Domain Concepts and Facilities November 1987
2199
2200
2201 If the same query was sent to some other server which was not
2202 authoritative for SRI-NIC.ARPA, the response might be:
2203
2204 +---------------------------------------------------+
2205 Header | OPCODE=SQUERY,RESPONSE |
2206 +---------------------------------------------------+
2207 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2208 +---------------------------------------------------+
2209 Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
2210 | 1777 IN A 26.0.0.73 |
2211 +---------------------------------------------------+
2212 Authority | <empty> |
2213 +---------------------------------------------------+
2214 Additional | <empty> |
2215 +---------------------------------------------------+
2216
2217 This response is different from the previous one in two ways: the header
2218 does not have AA set, and the TTLs are different. The inference is that
2219 the data did not come from a zone, but from a cache. The difference
2220 between the authoritative TTL and the TTL here is due to aging of the
2221 data in a cache. The difference in ordering of the RRs in the answer
2222 section is not significant.
2223
2224 6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
2225
2226 A query similar to the previous one, but using a QTYPE of *, would
2227 receive the following response from C.ISI.EDU:
2228
2229 +---------------------------------------------------+
2230 Header | OPCODE=SQUERY, RESPONSE, AA |
2231 +---------------------------------------------------+
2232 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2233 +---------------------------------------------------+
2234 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2235 | A 10.0.0.51 |
2236 | MX 0 SRI-NIC.ARPA. |
2237 | HINFO DEC-2060 TOPS20 |
2238 +---------------------------------------------------+
2239 Authority | <empty> |
2240 +---------------------------------------------------+
2241 Additional | <empty> |
2242 +---------------------------------------------------+
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252 Mockapetris [Page 41]
2253 RFC 1034 Domain Concepts and Facilities November 1987
2254
2255
2256 If a similar query was directed to two name servers which are not
2257 authoritative for SRI-NIC.ARPA, the responses might be:
2258
2259 +---------------------------------------------------+
2260 Header | OPCODE=SQUERY, RESPONSE |
2261 +---------------------------------------------------+
2262 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2263 +---------------------------------------------------+
2264 Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
2265 | A 10.0.0.51 |
2266 +---------------------------------------------------+
2267 Authority | <empty> |
2268 +---------------------------------------------------+
2269 Additional | <empty> |
2270 +---------------------------------------------------+
2271
2272 and
2273
2274 +---------------------------------------------------+
2275 Header | OPCODE=SQUERY, RESPONSE |
2276 +---------------------------------------------------+
2277 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2278 +---------------------------------------------------+
2279 Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
2280 +---------------------------------------------------+
2281 Authority | <empty> |
2282 +---------------------------------------------------+
2283 Additional | <empty> |
2284 +---------------------------------------------------+
2285
2286 Neither of these answers have AA set, so neither response comes from
2287 authoritative data. The different contents and different TTLs suggest
2288 that the two servers cached data at different times, and that the first
2289 server cached the response to a QTYPE=A query and the second cached the
2290 response to a HINFO query.
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307 Mockapetris [Page 42]
2308 RFC 1034 Domain Concepts and Facilities November 1987
2309
2310
2311 6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
2312
2313 This type of query might be result from a mailer trying to look up
2314 routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
2315 The response from C.ISI.EDU would be:
2316
2317 +---------------------------------------------------+
2318 Header | OPCODE=SQUERY, RESPONSE, AA |
2319 +---------------------------------------------------+
2320 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
2321 +---------------------------------------------------+
2322 Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
2323 +---------------------------------------------------+
2324 Authority | <empty> |
2325 +---------------------------------------------------+
2326 Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2327 | A 10.0.0.51 |
2328 +---------------------------------------------------+
2329
2330 This response contains the MX RR in the answer section of the response.
2331 The additional section contains the address RRs because the name server
2332 at C.ISI.EDU guesses that the requester will need the addresses in order
2333 to properly use the information carried by the MX.
2334
2335 6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
2336
2337 C.ISI.EDU would reply to this query with:
2338
2339 +---------------------------------------------------+
2340 Header | OPCODE=SQUERY, RESPONSE, AA |
2341 +---------------------------------------------------+
2342 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
2343 +---------------------------------------------------+
2344 Answer | <empty> |
2345 +---------------------------------------------------+
2346 Authority | <empty> |
2347 +---------------------------------------------------+
2348 Additional | <empty> |
2349 +---------------------------------------------------+
2350
2351 The only difference between the response and the query is the AA and
2352 RESPONSE bits in the header. The interpretation of this response is
2353 that the server is authoritative for the name, and the name exists, but
2354 no RRs of type NS are present there.
2355
2356 6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
2357
2358 If a user mistyped a host name, we might see this type of query.
2359
2360
2361
2362 Mockapetris [Page 43]
2363 RFC 1034 Domain Concepts and Facilities November 1987
2364
2365
2366 C.ISI.EDU would answer it with:
2367
2368 +---------------------------------------------------+
2369 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
2370 +---------------------------------------------------+
2371 Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
2372 +---------------------------------------------------+
2373 Answer | <empty> |
2374 +---------------------------------------------------+
2375 Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
2376 | 870611 1800 300 604800 86400 |
2377 +---------------------------------------------------+
2378 Additional | <empty> |
2379 +---------------------------------------------------+
2380
2381 This response states that the name does not exist. This condition is
2382 signalled in the response code (RCODE) section of the header.
2383
2384 The SOA RR in the authority section is the optional negative caching
2385 information which allows the resolver using this response to assume that
2386 the name will not exist for the SOA MINIMUM (86400) seconds.
2387
2388 6.2.6. QNAME=BRL.MIL, QTYPE=A
2389
2390 If this query is sent to C.ISI.EDU, the reply would be:
2391
2392 +---------------------------------------------------+
2393 Header | OPCODE=SQUERY, RESPONSE |
2394 +---------------------------------------------------+
2395 Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
2396 +---------------------------------------------------+
2397 Answer | <empty> |
2398 +---------------------------------------------------+
2399 Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
2400 | 86400 NS A.ISI.EDU. |
2401 +---------------------------------------------------+
2402 Additional | A.ISI.EDU. A 26.3.0.103 |
2403 | SRI-NIC.ARPA. A 26.0.0.73 |
2404 | A 10.0.0.51 |
2405 +---------------------------------------------------+
2406
2407 This response has an empty answer section, but is not authoritative, so
2408 it is a referral. The name server on C.ISI.EDU, realizing that it is
2409 not authoritative for the MIL domain, has referred the requester to
2410 servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
2411 for the MIL domain.
2412
2413
2414
2415
2416
2417 Mockapetris [Page 44]
2418 RFC 1034 Domain Concepts and Facilities November 1987
2419
2420
2421 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
2422
2423 The response to this query from A.ISI.EDU would be:
2424
2425 +---------------------------------------------------+
2426 Header | OPCODE=SQUERY, RESPONSE, AA |
2427 +---------------------------------------------------+
2428 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2429 +---------------------------------------------------+
2430 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2431 | C.ISI.EDU. 86400 IN A 10.0.0.52 |
2432 +---------------------------------------------------+
2433 Authority | <empty> |
2434 +---------------------------------------------------+
2435 Additional | <empty> |
2436 +---------------------------------------------------+
2437
2438 Note that the AA bit in the header guarantees that the data matching
2439 QNAME is authoritative, but does not say anything about whether the data
2440 for C.ISI.EDU is authoritative. This complete reply is possible because
2441 A.ISI.EDU happens to be authoritative for both the ARPA domain where
2442 USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
2443 found.
2444
2445 If the same query was sent to C.ISI.EDU, its response might be the same
2446 as shown above if it had its own address in its cache, but might also
2447 be:
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472 Mockapetris [Page 45]
2473 RFC 1034 Domain Concepts and Facilities November 1987
2474
2475
2476 +---------------------------------------------------+
2477 Header | OPCODE=SQUERY, RESPONSE, AA |
2478 +---------------------------------------------------+
2479 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2480 +---------------------------------------------------+
2481 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2482 +---------------------------------------------------+
2483 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2484 | NS A.ISI.EDU. |
2485 | NS VENERA.ISI.EDU. |
2486 +---------------------------------------------------+
2487 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2488 | 172800 A 128.9.0.33 |
2489 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2490 | 172800 A 128.9.0.32 |
2491 | A.ISI.EDU. 172800 A 26.3.0.103 |
2492 +---------------------------------------------------+
2493
2494 This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
2495 plus a referral to the name servers for ISI.EDU. This sort of reply
2496 isn't very likely given that the query is for the host name of the name
2497 server being asked, but would be common for other aliases.
2498
2499 6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
2500
2501 If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
2502 be:
2503
2504 +---------------------------------------------------+
2505 Header | OPCODE=SQUERY, RESPONSE, AA |
2506 +---------------------------------------------------+
Section 6.1. ends this way: Relative and absolute domain names may be freely intermixed in a master which is incomplete. It's unclear exactly how that sentence may have been intended to end, but minimally I would suggeste it at least terminated with 'file.'.
2507 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2508 +---------------------------------------------------+
2509 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2510 +---------------------------------------------------+
2511 Authority | <empty> |
2512 +---------------------------------------------------+
2513 Additional | <empty> |
2514 +---------------------------------------------------+
2515
2516 Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
2517 server doesn't attempt to look up anything for C.ISI.EDU. (Except
2518 possibly for the additional section.)
2519
2520 6.3. Example resolution
2521
2522 The following examples illustrate the operations a resolver must perform
2523 for its client. We assume that the resolver is starting without a
2524
2525
2526
2527 Mockapetris [Page 46]
2528 RFC 1034 Domain Concepts and Facilities November 1987
2529
2530
2531 cache, as might be the case after system boot. We further assume that
2532 the system is not one of the hosts in the data and that the host is
2533 located somewhere on net 26, and that its safety belt (SBELT) data
2534 structure has the following information:
2535
2536 Match count = -1
2537 SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
2538 A.ISI.EDU. 26.3.0.103
2539
2540 This information specifies servers to try, their addresses, and a match
2541 count of -1, which says that the servers aren't very close to the
2542 target. Note that the -1 isn't supposed to be an accurate closeness
2543 measure, just a value so that later stages of the algorithm will work.
2544
2545 The following examples illustrate the use of a cache, so each example
2546 assumes that previous requests have completed.
2547
2548 6.3.1. Resolve MX for ISI.EDU.
2549
2550 Suppose the first request to the resolver comes from the local mailer,
2551 which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
2552 RRs for the domain name ISI.EDU.
2553
2554 The resolver would look in its cache for MX RRs at ISI.EDU, but the
2555 empty cache wouldn't be helpful. The resolver would recognize that it
2556 needed to query foreign servers and try to determine the best servers to
2557 query. This search would look for NS RRs for the domains ISI.EDU, EDU,
2558 and the root. These searches of the cache would also fail. As a last
2559 resort, the resolver would use the information from the SBELT, copying
2560 it into its SLIST structure.
2561
2562 At this point the resolver would need to pick one of the three available
2563 addresses to try. Given that the resolver is on net 26, it should
2564 choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would
2565 then send off a query of the form:
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582 Mockapetris [Page 47]
2583 RFC 1034 Domain Concepts and Facilities November 1987
2584
2585
2586 +---------------------------------------------------+
2587 Header | OPCODE=SQUERY |
2588 +---------------------------------------------------+
2589 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2590 +---------------------------------------------------+
2591 Answer | <empty> |
2592 +---------------------------------------------------+
2593 Authority | <empty> |
2594 +---------------------------------------------------+
2595 Additional | <empty> |
2596 +---------------------------------------------------+
2597
2598 The resolver would then wait for a response to its query or a timeout.
2599 If the timeout occurs, it would try different servers, then different
2600 addresses of the same servers, lastly retrying addresses already tried.
2601 It might eventually receive a reply from SRI-NIC.ARPA:
2602
2603 +---------------------------------------------------+
2604 Header | OPCODE=SQUERY, RESPONSE |
2605 +---------------------------------------------------+
2606 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2607 +---------------------------------------------------+
2608 Answer | <empty> |
2609 +---------------------------------------------------+
2610 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2611 | NS A.ISI.EDU. |
2612 | NS VENERA.ISI.EDU.|
2613 +---------------------------------------------------+
2614 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2615 | 172800 A 128.9.0.33 |
2616 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2617 | 172800 A 128.9.0.32 |
2618 | A.ISI.EDU. 172800 A 26.3.0.103 |
2619 +---------------------------------------------------+
2620
2621 The resolver would notice that the information in the response gave a
2622 closer delegation to ISI.EDU than its existing SLIST (since it matches
2623 three labels). The resolver would then cache the information in this
2624 response and use it to set up a new SLIST:
2625
2626 Match count = 3
2627 A.ISI.EDU. 26.3.0.103
2628 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2629 VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
2630
2631 A.ISI.EDU appears on this list as well as the previous one, but that is
2632 purely coincidental. The resolver would again start transmitting and
2633 waiting for responses. Eventually it would get an answer:
2634
2635
2636
2637 Mockapetris [Page 48]
2638 RFC 1034 Domain Concepts and Facilities November 1987
2639
2640
2641 +---------------------------------------------------+
2642 Header | OPCODE=SQUERY, RESPONSE, AA |
2643 +---------------------------------------------------+
2644 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2645 +---------------------------------------------------+
2646 Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. |
2647 | MX 20 VAXA.ISI.EDU. |
2648 +---------------------------------------------------+
2649 Authority | <empty> |
2650 +---------------------------------------------------+
2651 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2652 | 172800 A 128.9.0.33 |
2653 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2654 | 172800 A 128.9.0.32 |
2655 +---------------------------------------------------+
2656
2657 The resolver would add this information to its cache, and return the MX
2658 RRs to its client.
2659
2660 6.3.2. Get the host name for address 26.6.0.65
2661
2662 The resolver would translate this into a request for PTR RRs for
2663 65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the
2664 resolver would look for foreign servers to ask. No servers would match,
2665 so it would use SBELT again. (Note that the servers for the ISI.EDU
2666 domain are in the cache, but ISI.EDU is not an ancestor of
2667 65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
2668
2669 Since this request is within the authoritative data of both servers in
2670 SBELT, eventually one would return:
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692 Mockapetris [Page 49]
2693 RFC 1034 Domain Concepts and Facilities November 1987
2694
2695
2696 +---------------------------------------------------+
2697 Header | OPCODE=SQUERY, RESPONSE, AA |
2698 +---------------------------------------------------+
2699 Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
2700 +---------------------------------------------------+
2701 Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
2702 +---------------------------------------------------+
2703 Authority | <empty> |
2704 +---------------------------------------------------+
2705 Additional | <empty> |
2706 +---------------------------------------------------+
2707
2708 6.3.3. Get the host address of poneria.ISI.EDU
2709
2710 This request would translate into a type A request for poneria.ISI.EDU.
2711 The resolver would not find any cached data for this name, but would
2712 find the NS RRs in the cache for ISI.EDU when it looks for foreign
2713 servers to ask. Using this data, it would construct a SLIST of the
2714 form:
2715
2716 Match count = 3
2717
2718 A.ISI.EDU. 26.3.0.103
2719 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2720 VENERA.ISI.EDU. 10.1.0.52
2721
2722 A.ISI.EDU is listed first on the assumption that the resolver orders its
2723 choices by preference, and A.ISI.EDU is on the same network.
2724
2725 One of these servers would answer the query.
2726
2727 7. REFERENCES and BIBLIOGRAPHY
2728
2729 [Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena
2730 Technical Plan - Name Service, April 1987, version 1.9.
2731
2732 Describes the fundamentals of the Hesiod name service.
2733
2734 [IEN-116] J. Postel, "Internet Name Server", IEN-116,
2735 USC/Information Sciences Institute, August 1979.
2736
2737 A name service obsoleted by the Domain Name System, but
2738 still in use.
2739
2740
2741
2742
2743
2744
2745
2746
2747 Mockapetris [Page 50]
2748 RFC 1034 Domain Concepts and Facilities November 1987
2749
2750
2751 [Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
2752 Networks",Communications of the ACM, October 1986,
2753 volume 29, number 10.
2754
2755 [RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2756 Information Center, SRI International, December 1977.
2757
2758 [RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2759 USC/Information Sciences Institute, August 1980.
2760
2761 [RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2762 USC/Information Sciences Institute, September 1981.
2763
2764 [RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2765 September 1981.
2766
2767 Suggests introduction of a hierarchy in place of a flat
2768 name space for the Internet.
2769
2770 [RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2771 USC/Information Sciences Institute, February 1982.
2772
2773 [RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
2774 Internet Host Table Specification", RFC-810, Network
2775 Information Center, SRI International, March 1982.
2776
2777 Obsolete. See RFC-952.
2778
2779 [RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2780 Server", RFC-811, Network Information Center, SRI
2781 International, March 1982.
2782
2783 Obsolete. See RFC-953.
2784
2785 [RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2786 Network Information Center, SRI International, March
2787 1982.
2788
2789 [RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
2790 Internet User Applications", RFC-819, Network
2791 Information Center, SRI International, August 1982.
2792
2793 Early thoughts on the design of the domain system.
2794 Current implementation is completely different.
2795
2796 [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2797 USC/Information Sciences Institute, August 1980.
2798
2799
2800
2801
2802 Mockapetris [Page 51]
2803 RFC 1034 Domain Concepts and Facilities November 1987
2804
2805
2806 [RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2807 RFC-830, Network Information Center, SRI International,
2808 October 1982.
2809
2810 Early thoughts on the design of the domain system.
2811 Current implementation is completely different.
2812
2813 [RFC-882] P. Mockapetris, "Domain names - Concepts and
2814 Facilities," RFC-882, USC/Information Sciences
2815 Institute, November 1983.
2816
2817 Superceeded by this memo.
2818
2819 [RFC-883] P. Mockapetris, "Domain names - Implementation and
2820 Specification," RFC-883, USC/Information Sciences
2821 Institute, November 1983.
2822
2823 Superceeded by this memo.
2824
2825 [RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2826 RFC-920, USC/Information Sciences Institute
2827 October 1984.
2828
2829 Explains the naming scheme for top level domains.
2830
2831 [RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2832 Table Specification", RFC-952, SRI, October 1985.
2833
2834 Specifies the format of HOSTS.TXT, the host/address
2835 table replaced by the DNS.
2836
2837 [RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2838 RFC-953, SRI, October 1985.
2839
2840 This RFC contains the official specification of the
2841 hostname server protocol, which is obsoleted by the DNS.
2842 This TCP based protocol accesses information stored in
2843 the RFC-952 format, and is used to obtain copies of the
2844 host table.
2845
2846 [RFC-973] P. Mockapetris, "Domain System Changes and
2847 Observations", RFC-973, USC/Information Sciences
2848 Institute, January 1986.
2849
2850 Describes changes to RFC-882 and RFC-883 and reasons for
2851 them. Now obsolete.
2852
2853
2854
2855
2856
2857 Mockapetris [Page 52]
2858 RFC 1034 Domain Concepts and Facilities November 1987
2859
2860
2861 [RFC-974] C. Partridge, "Mail routing and the domain system",
2862 RFC-974, CSNET CIC BBN Labs, January 1986.
2863
2864 Describes the transition from HOSTS.TXT based mail
2865 addressing to the more powerful MX system used with the
2866 domain system.
2867
2868 [RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
2869 service on a TCP/UDP transport: Concepts and Methods",
2870 RFC-1001, March 1987.
2871
2872 This RFC and RFC-1002 are a preliminary design for
2873 NETBIOS on top of TCP/IP which proposes to base NetBIOS
2874 name service on top of the DNS.
2875
2876 [RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2877 service on a TCP/UDP transport: Detailed
2878 Specifications", RFC-1002, March 1987.
2879
2880 [RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
2881 USC/Information Sciences Institute, May 1987
2882
2883 Contains socket numbers and mnemonics for host names,
2884 operating systems, etc.
2885
2886 [RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2887 November 1987.
2888
2889 Describes a plan for converting the MILNET to the DNS.
2890
2891 [RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for
2892 Administrators", RFC-1032, November 1987.
2893
2894 Describes the registration policies used by the NIC to
2895 administer the top level domains and delegate subzones.
2896
2897 [RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide",
2898 RFC-1033, November 1987.
2899
2900 A cookbook for domain administrators.
2901
2902 [Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2903 Name Server", Computer Networks, vol 6, nr 3, July 1982.
2904
2905 Describes a name service for CSNET which is independent
2906 from the DNS and DNS use in the CSNET.
2907
2908
2909
2910
2911
2912 Mockapetris [Page 53]
2913 RFC 1034 Domain Concepts and Facilities November 1987
2914
2915
2916 Index
2917
2918 A 12
2919 Absolute names 8
2920 Aliases 14, 31
2921 Authority 6
2922 AXFR 17
2923
2924 Case of characters 7
2925 CH 12
2926 CNAME 12, 13, 31
2927 Completion queries 18
2928
2929 Domain name 6, 7
2930
2931 Glue RRs 20
2932
2933 HINFO 12
2934
2935 IN 12
2936 Inverse queries 16
2937 Iterative 4
2938
2939 Label 7
2940
2941 Mailbox names 9
2942 MX 12
2943
2944 Name error 27, 36
2945 Name servers 5, 17
2946 NE 30
2947 Negative caching 44
2948 NS 12
2949
2950 Opcode 16
2951
2952 PTR 12
2953
2954 QCLASS 16
2955 QTYPE 16
2956
2957 RDATA 13
2958 Recursive 4
2959 Recursive service 22
2960 Relative names 7
2961 Resolvers 6
2962 RR 12
2963
2964
2965
2966
2967 Mockapetris [Page 54]
2968 RFC 1034 Domain Concepts and Facilities November 1987
2969
2970
2971 Safety belt 33
2972 Sections 16
2973 SOA 12
2974 Standard queries 22
2975
2976 Status queries 18
2977 Stub resolvers 32
2978
2979 TTL 12, 13
2980
2981 Wildcards 25
2982
2983 Zone transfers 28
2984 Zones 19
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022 Mockapetris [Page 55]
3023