1Network Working Group P. Mockapetris
2Request for Comments: 1034 ISI
3Obsoletes: RFCs 882, 883, 973 November 1987
6 DOMAIN NAMES - CONCEPTS AND FACILITIES
12This RFC is an introduction to the Domain Name System (DNS), and omits
13many details which can be found in a companion RFC, "Domain Names -
14Implementation and Specification" [RFC-1035]. That RFC assumes that the
15reader is familiar with the concepts discussed in this memo.
17A subset of DNS functions and data types constitute an official
18protocol. The official protocol includes standard queries and their
19responses and most of the Internet class data formats (e.g., host
22However, the domain system is intentionally extensible. Researchers are
23continuously proposing, implementing and experimenting with new data
24types, query types, classes, functions, etc. Thus while the components
25of the official protocol are expected to stay essentially unchanged and
26operate as a production service, experimental behavior should always be
27expected in extensions beyond the official protocol. Experimental or
28obsolete features are clearly marked in these RFCs, and such information
29should be used with caution.
31The reader is especially cautioned not to depend on the values which
32appear in examples to be current or complete, since their purpose is
33primarily pedagogical. Distribution of this memo is unlimited.
37This RFC introduces domain style names, their use for Internet mail and
38host address support, and the protocols and servers used to implement
39domain name facilities.
412.1. The history of domain names
43The impetus for the development of the domain system was growth in the
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
54RFC 1034 Domain Concepts and Facilities November 1987
57 bandwidth consumed in distributing a new version by this
58 scheme is proportional to the square of the number of hosts in
59 the network, and even when multiple levels of FTP are used,
60 the outgoing FTP load on the NIC host is considerable.
61 Explosive growth in the number of hosts didn't bode well for
64 - The network population was also changing in character. The
65 timeshared hosts that made up the original ARPANET were being
66 replaced with local networks of workstations. Local
67 organizations were administering their own names and
68 addresses, but had to wait for the NIC to change HOSTS.TXT to
69 make changes visible to the Internet at large. Organizations
70 also wanted some local structure on the name space.
72 - The applications on the Internet were getting more
73 sophisticated and creating a need for general purpose name
77The result was several ideas about name spaces and their management
78[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
79common thread was the idea of a hierarchical name space, with the
80hierarchy roughly corresponding to organizational structure, and names
81using "." as the character to mark the boundary between hierarchy
82levels. A design using a distributed database and generalized resources
83was described in [RFC-882, RFC-883]. Based on experience with several
84implementations, the system evolved into the scheme described in this
87The terms "domain" or "domain name" are used in many contexts beyond the
88DNS described here. Very often, the term domain name is used to refer
89to a name with structure indicated by dots, but no relation to the DNS.
90This is particularly true in mail addressing [Quarterman 86].
94The design goals of the DNS influence its structure. They are:
96 - The primary goal is a consistent name space which will be used
97 for referring to resources. In order to avoid the problems
98 caused by ad hoc encodings, names should not be required to
99 contain network identifiers, addresses, routes, or similar
100 information as part of the name.
102 - The sheer size of the database and frequency of updates
103 suggest that it must be maintained in a distributed manner,
104 with local caching to improve performance. Approaches that
110RFC 1034 Domain Concepts and Facilities November 1987
113 attempt to collect a consistent copy of the entire database
114 will become more and more expensive and difficult, and hence
115 should be avoided. The same principle holds for the structure
116 of the name space, and in particular mechanisms for creating
117 and deleting names; these should also be distributed.
119 - Where there tradeoffs between the cost of acquiring data, the
120 speed of updates, and the accuracy of caches, the source of
121 the data should control the tradeoff.
123 - The costs of implementing such a facility dictate that it be
124 generally useful, and not restricted to a single application.
125 We should be able to use names to retrieve host addresses,
126 mailbox data, and other as yet undetermined information. All
127 data associated with a name is tagged with a type, and queries
128 can be limited to a single type.
130 - Because we want the name space to be useful in dissimilar
131 networks and applications, we provide the ability to use the
132 same name space with different protocol families or
133 management. For example, host address formats differ between
134 protocols, though all protocols have the notion of address.
135 The DNS tags all data with a class as well as the type, so
136 that we can allow parallel use of different formats for data
139 - We want name server transactions to be independent of the
140 communications system that carries them. Some systems may
141 wish to use datagrams for queries and responses, and only
142 establish virtual circuits for transactions that need the
143 reliability (e.g., database updates, long transactions); other
144 systems will use virtual circuits exclusively.
146 - The system should be useful across a wide spectrum of host
147 capabilities. Both personal computers and large timeshared
148 hosts should be able to use the system, though perhaps in
1512.3. Assumptions about usage
153The organization of the domain system derives from some assumptions
154about the needs and usage patterns of its user community and is designed
155to avoid many of the the complicated problems found in general purpose
160 - The size of the total database will initially be proportional
166RFC 1034 Domain Concepts and Facilities November 1987
169 to the number of hosts using the system, but will eventually
170 grow to be proportional to the number of users on those hosts
171 as mailboxes and other information are added to the domain
174 - Most of the data in the system will change very slowly (e.g.,
175 mailbox bindings, host addresses), but that the system should
176 be able to deal with subsets that change more rapidly (on the
177 order of seconds or minutes).
179 - The administrative boundaries used to distribute
180 responsibility for the database will usually correspond to
181 organizations that have one or more hosts. Each organization
182 that has responsibility for a particular set of domains will
183 provide redundant name servers, either on the organization's
184 own hosts or other hosts that the organization arranges to
187 - Clients of the domain system should be able to identify
188 trusted name servers they prefer to use before accepting
189 referrals to name servers outside of this "trusted" set.
191 - Access to information is more critical than instantaneous
192 updates or guarantees of consistency. Hence the update
193 process allows updates to percolate out through the users of
194 the domain system rather than guaranteeing that all copies are
195 simultaneously updated. When updates are unavailable due to
196 network or host failure, the usual course is to believe old
197 information while continuing efforts to update it. The
198 general model is that copies are distributed with timeouts for
199 refreshing. The distributor sets the timeout value and the
200 recipient of the distribution is responsible for performing
201 the refresh. In special situations, very short intervals can
202 be specified, or the owner can prohibit copies.
204 - In any system that has a distributed database, a particular
205 name server may be presented with a query that can only be
206 answered by some other server. The two general approaches to
207 dealing with this problem are "recursive", in which the first
208 server pursues the query for the client at another server, and
209 "iterative", in which the server refers the client to another
210 server and lets the client pursue the query. Both approaches
211 have advantages and disadvantages, but the iterative approach
212 is preferred for the datagram style of access. The domain
213 system requires implementation of the iterative approach, but
214 allows the recursive approach as an option.
222RFC 1034 Domain Concepts and Facilities November 1987
225The domain system assumes that all data originates in master files
226scattered through the hosts that use the domain system. These master
227files are updated by local system administrators. Master files are text
228files that are read by a local name server, and hence become available
229through the name servers to users of the domain system. The user
230programs access name servers through standard programs called resolvers.
232The standard format of master files allows them to be exchanged between
233hosts (via FTP, mail, or some other mechanism); this facility is useful
234when an organization wants a domain, but doesn't want to support a name
235server. The organization can maintain the master files locally using a
236text editor, transfer them to a foreign host which runs a name server,
237and then arrange with the system administrator of the name server to get
240Each host's name servers and resolvers are configured by a local system
241administrator [RFC-1033]. For a name server, this configuration data
242includes the identity of local master files and instructions on which
243non-local master files are to be loaded from foreign servers. The name
244server uses the master files or copies to load its zones. For
245resolvers, the configuration data identifies the name servers which
246should be the primary sources of information.
248The domain system defines procedures for accessing the data and for
249referrals to other name servers. The domain system also defines
250procedures for caching retrieved data and for periodic refreshing of
251data defined by the system administrator.
253The system administrators provide:
255 - The definition of zone boundaries.
257 - Master files of data.
259 - Updates to master files.
261 - Statements of the refresh policies desired.
263The domain system provides:
265 - Standard formats for resource data.
267 - Standard methods for querying the database.
269 - Standard methods for name servers to refresh local data from
270 foreign name servers.
278RFC 1034 Domain Concepts and Facilities November 1987
2812.4. Elements of the DNS
283The DNS has three major components:
285 - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
286 specifications for a tree structured name space and data
287 associated with the names. Conceptually, each node and leaf
288 of the domain name space tree names a set of information, and
289 query operations are attempts to extract specific types of
290 information from a particular set. A query names the domain
291 name of interest and describes the type of resource
292 information that is desired. For example, the Internet
293 uses some of its domain names to identify hosts; queries for
294 address resources return Internet host addresses.
296 - NAME SERVERS are server programs which hold information about
297 the domain tree's structure and set information. A name
298 server may cache structure or set information about any part
299 of the domain tree, but in general a particular name server
300 has complete information about a subset of the domain space,
301 and pointers to other name servers that can be used to lead to
302 information from any part of the domain tree. Name servers
303 know the parts of the domain tree for which they have complete
304 information; a name server is said to be an AUTHORITY for
305 these parts of the name space. Authoritative information is
306 organized into units called ZONEs, and these zones can be
307 automatically distributed to the name servers which provide
308 redundant service for the data in a zone.
310 - RESOLVERS are programs that extract information from name
311 servers in response to client requests. Resolvers must be
312 able to access at least one name server and use that name
313 server's information to answer a query directly, or pursue the
314 query using referrals to other name servers. A resolver will
315 typically be a system routine that is directly accessible to
316 user programs; hence no protocol is necessary between the
317 resolver and the user program.
319These three components roughly correspond to the three layers or views
322 - From the user's point of view, the domain system is accessed
323 through a simple procedure or OS call to a local resolver.
324 The domain space consists of a single tree and the user can
325 request information from any section of the tree.
327 - From the resolver's point of view, the domain system is
328 composed of an unknown number of name servers. Each name
334RFC 1034 Domain Concepts and Facilities November 1987
337 server has one or more pieces of the whole domain tree's data,
338 but the resolver views each of these databases as essentially
341 - From a name server's point of view, the domain system consists
342 of separate sets of local information called zones. The name
343 server has local copies of some of the zones. The name server
344 must periodically refresh its zones from master copies in
345 local files or foreign name servers. The name server must
346 concurrently process queries that arrive from resolvers.
348In the interests of performance, implementations may couple these
349functions. For example, a resolver on the same machine as a name server
350might share a database consisting of the the zones managed by the name
351server and the cache managed by the resolver.
3533. DOMAIN NAME SPACE and RESOURCE RECORDS
3553.1. Name space specifications and terminology
357The domain name space is a tree structure. Each node and leaf on the
358tree corresponds to a resource set (which may be empty). The domain
359system makes no distinctions between the uses of the interior nodes and
360leaves, and this memo uses the term "node" to refer to both.
362Each node has a label, which is zero to 63 octets in length. Brother
363nodes may not have the same label, although the same label can be used
364for nodes which are not brothers. One label is reserved, and that is
365the null (i.e., zero length) label used for the root.
367The domain name of a node is the list of the labels on the path from the
368node to the root of the tree. By convention, the labels that compose a
369domain name are printed or read left to right, from the most specific
370(lowest, farthest from the root) to the least specific (highest, closest
373Internally, programs that manipulate domain names should represent them
374as sequences of labels, where each label is a length octet followed by
375an octet string. Because all domain names end at the root, which has a
376null string for a label, these internal representations can use a length
377byte of zero to terminate a domain name.
379By convention, domain names can be stored with arbitrary case, but
380domain name comparisons for all present domain functions are done in a
381case-insensitive manner, assuming an ASCII character set, and a high
382order zero bit. This means that you are free to create a node with
383label "A" or a node with label "a", but not both as brothers; you could
384refer to either using "a" or "A". When you receive a domain name or
390RFC 1034 Domain Concepts and Facilities November 1987
393label, you should preserve its case. The rationale for this choice is
394that we may someday need to add full binary domain names for new
395services; existing services would not be changed.
397When a user needs to type a domain name, the length of each label is
398omitted and the labels are separated by dots ("."). Since a complete
399domain name ends with the root label, this leads to a printed form which
400ends in a dot. We use this property to distinguish between:
402 - a character string which represents a complete domain name
403 (often called "absolute"). For example, "poneria.ISI.EDU."
405 - a character string that represents the starting labels of a
406 domain name which is incomplete, and should be completed by
407 local software using knowledge of the local domain (often
408 called "relative"). For example, "poneria" used in the
411Relative names are either taken relative to a well known origin, or to a
412list of domains used as a search list. Relative names appear mostly at
413the user interface, where their interpretation varies from
414implementation to implementation, and in master files, where they are
415relative to a single origin domain name. The most common interpretation
416uses the root "." as either the single origin or as one of the members
417of the search list, so a multi-label relative name is often one where
418the trailing dot has been omitted to save typing.
420To simplify implementations, the total number of octets that represent a
421domain name (i.e., the sum of all label octets and label lengths) is
424A domain is identified by a domain name, and consists of that part of
425the domain name space that is at or below the domain name which
426specifies the domain. A domain is a subdomain of another domain if it
427is contained within that domain. This relationship can be tested by
428seeing if the subdomain's name ends with the containing domain's name.
429For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
4313.2. Administrative guidelines on use
433As a matter of policy, the DNS technical specifications do not mandate a
434particular tree structure or rules for selecting labels; its goal is to
435be as general as possible, so that it can be used to build arbitrary
436applications. In particular, the system was designed so that the name
437space did not have to be organized along the lines of network
438boundaries, name servers, etc. The rationale for this is not that the
439name space should have no implied semantics, but rather that the choice
440of implied semantics should be left open to be used for the problem at
446RFC 1034 Domain Concepts and Facilities November 1987
449hand, and that different parts of the tree can have different implied
450semantics. For example, the IN-ADDR.ARPA domain is organized and
451distributed by network and host address because its role is to translate
452from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
4531002] are flat because that is appropriate for that application.
455However, there are some guidelines that apply to the "normal" parts of
456the name space used for hosts, mailboxes, etc., that will make the name
457space more uniform, provide for growth, and minimize problems as
458software is converted from the older host table. The political
459decisions about the top levels of the tree originated in RFC-920.
460Current policy for the top levels is discussed in [RFC-1032]. MILNET
461conversion issues are covered in [RFC-1031].
463Lower domains which will eventually be broken into multiple zones should
464provide branching at the top of the domain so that the eventual
465decomposition can be done without renaming. Node labels which use
466special characters, leading digits, etc., are likely to break older
467software which depends on more restrictive choices.
4693.3. Technical guidelines on use
471Before the DNS can be used to hold naming information for some kind of
472object, two needs must be met:
474 - A convention for mapping between object names and domain
475 names. This describes how information about an object is
478 - RR types and data formats for describing the object.
480These rules can be quite simple or fairly complex. Very often, the
481designer must take into account existing formats and plan for upward
482compatibility for existing usage. Multiple mappings or levels of
483mapping may be required.
485For hosts, the mapping depends on the existing syntax for host names
486which is a subset of the usual text representation for domain names,
487together with RR formats for describing host addresses, etc. Because we
488need a reliable inverse mapping from address to host name, a special
489mapping for addresses into the IN-ADDR.ARPA domain is also defined.
491For mailboxes, the mapping is slightly more complex. The usual mail
492address <local-part>@<mail-domain> is mapped into a domain name by
493converting <local-part> into a single label (regardles of dots it
494contains), converting <mail-domain> into a domain name using the usual
495text format for domain names (dots denote label breaks), and
496concatenating the two to form a single domain name. Thus the mailbox
502RFC 1034 Domain Concepts and Facilities November 1987
505HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
506HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
507design also must take into account the scheme for mail exchanges [RFC-
510The typical user is not concerned with defining these rules, but should
511understand that they usually are the result of numerous compromises
512between desires for upward compatibility with old usage, interactions
513between different object definitions, and the inevitable urge to add new
514features when defining the rules. The way the DNS is used to support
515some object is often more crucial than the restrictions inherent in the
5183.4. Example name space
520The following figure shows a part of the current domain name space, and
521is used in many examples in this RFC. Note that the tree is a very
522small subset of the actual name space.
526 +---------------------+------------------+
531 +-----+-----+ | +------+-----+-----+
533 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
535 +--------+------------------+---------------+--------+
542 LCS ACHILLES +--+-----+-----+--------+
544 XX A C VAXA VENERA Mockapetris
546In this example, the root domain has three immediate subdomains: MIL,
547EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
548XX.LCS.MIT.EDU. All of the leaves are also domains.
5503.5. Preferred name syntax
552The DNS specifications attempt to be as general as possible in the rules
558RFC 1034 Domain Concepts and Facilities November 1987
561for constructing domain names. The idea is that the name of any
562existing object can be expressed as a domain name with minimal changes.
563However, when assigning a domain name for an object, the prudent user
564will select a name which satisfies both the rules of the domain system
565and any existing rules for the object, whether these rules are published
566or implied by existing programs.
568For example, when naming a mail domain, the user should satisfy both the
569rules of this memo and those in RFC-822. When creating a new host name,
570the old rules for HOSTS.TXT should be followed. This avoids problems
571when old software is converted to use domain names.
573The following syntax will result in fewer problems with many
574applications that use domain names (e.g., mail, TELNET).
576<domain> ::= <subdomain> | " "
578<subdomain> ::= <label> | <subdomain> "." <label>
580<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
582<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
584<let-dig-hyp> ::= <let-dig> | "-"
586<let-dig> ::= <letter> | <digit>
588<letter> ::= any one of the 52 alphabetic characters A through Z in
589upper case and a through z in lower case
591<digit> ::= any one of the ten digits 0 through 9
593Note that while upper and lower case letters are allowed in domain
594names, no significance is attached to the case. That is, two names with
595the same spelling but different case are to be treated as if identical.
597The labels must follow the rules for ARPANET host names. They must
598start with a letter, end with a letter or digit, and have as interior
599characters only letters, digits, and hyphen. There are also some
600restrictions on the length. Labels must be 63 characters or less.
602For example, the following strings identify hosts in the Internet:
604A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
608A domain name identifies a node. Each node has a set of resource
614RFC 1034 Domain Concepts and Facilities November 1987
617information, which may be empty. The set of resource information
618associated with a particular name is composed of separate resource
619records (RRs). The order of RRs in a set is not significant, and need
620not be preserved by name servers, resolvers, or other parts of the DNS.
622When we talk about a specific RR, we assume it has the following:
624owner which is the domain name where the RR is found.
626type which is an encoded 16 bit value that specifies the type
627 of the resource in this resource record. Types refer to
630 This memo uses the following types:
634 CNAME identifies the canonical name of an
637 HINFO identifies the CPU and OS used by a host
639 MX identifies a mail exchange for the
640 domain. See [RFC-974 for details.
643 the authoritative name server for the domain
646 a pointer to another part of the domain name space
649 identifies the start of a zone of authority]
651class which is an encoded 16 bit value which identifies a
652 protocol family or instance of a protocol.
654 This memo uses the following classes:
656 IN the Internet system
660TTL which is the time to live of the RR. This field is a 32
661 bit integer in units of seconds, an is primarily used by
662 resolvers when they cache RRs. The TTL describes how
663 long a RR can be cached before it should be discarded.
670RFC 1034 Domain Concepts and Facilities November 1987
673RDATA which is the type and sometimes class dependent data
674 which describes the resource:
676 A For the IN class, a 32 bit IP address
678 For the CH class, a domain name followed
679 by a 16 bit octal Chaos address.
683 MX a 16 bit preference value (lower is
684 better) followed by a host name willing
685 to act as a mail exchange for the owner
694The owner name is often implicit, rather than forming an integral part
695of the RR. For example, many name servers internally form tree or hash
696structures for the name space, and chain RRs off nodes. The remaining
697RR parts are the fixed header (type, class, TTL) which is consistent for
698all RRs, and a variable part (RDATA) that fits the needs of the resource
701The meaning of the TTL field is a time limit on how long an RR can be
702kept in a cache. This limit does not apply to authoritative data in
703zones; it is also timed out, but by the refreshing policies for the
704zone. The TTL is assigned by the administrator for the zone where the
705data originates. While short TTLs can be used to minimize caching, and
706a zero TTL prohibits caching, the realities of Internet performance
707suggest that these times should be on the order of days for the typical
708host. If a change can be anticipated, the TTL can be reduced prior to
709the change to minimize inconsistency during the change, and then
710increased back to its former value following the change.
712The data in the RDATA section of RRs is carried as a combination of
713binary strings and domain names. The domain names are frequently used
714as "pointers" to other data in the DNS.
7163.6.1. Textual expression of RRs
718RRs are represented in binary form in the packets of the DNS protocol,
719and are usually represented in highly encoded form when stored in a name
720server or resolver. In this memo, we adopt a style similar to that used
726RFC 1034 Domain Concepts and Facilities November 1987
729in master files in order to show the contents of RRs. In this format,
730most RRs are shown on a single line, although continuation lines are
731possible using parentheses.
733The start of the line gives the owner of the RR. If a line begins with
734a blank, then the owner is assumed to be the same as that of the
735previous RR. Blank lines are often included for readability.
737Following the owner, we list the TTL, type, and class of the RR. Class
738and type use the mnemonics defined above, and TTL is an integer before
739the type field. In order to avoid ambiguity in parsing, type and class
740mnemonics are disjoint, TTLs are integers, and the type mnemonic is
741always last. The IN class and TTL values are often omitted from examples
742in the interests of clarity.
744The resource data or RDATA section of the RR are given using knowledge
745of the typical representation for the data.
747For example, we might show the RRs carried in a message as:
749 ISI.EDU. MX 10 VENERA.ISI.EDU.
751 VENERA.ISI.EDU. A 128.9.0.32
753 VAXA.ISI.EDU. A 10.2.0.27
756The MX RRs have an RDATA section which consists of a 16 bit number
757followed by a domain name. The address RRs use a standard IP address
758format to contain a 32 bit internet address.
760This example shows six RRs, with two RRs at each of three domain names.
762Similarly we might see:
764 XX.LCS.MIT.EDU. IN A 10.0.0.44
767This example shows two addresses for XX.LCS.MIT.EDU, each of a different
7703.6.2. Aliases and canonical names
772In existing systems, hosts and other resources often have several names
773that identify the same resource. For example, the names C.ISI.EDU and
774USC-ISIC.ARPA both identify the same host. Similarly, in the case of
775mailboxes, many organizations provide many names that actually go to the
776same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
782RFC 1034 Domain Concepts and Facilities November 1987
785and PVM@ISI.EDU all go to the same mailbox (although the mechanism
786behind this is somewhat complicated).
788Most of these systems have a notion that one of the equivalent set of
789names is the canonical or primary name and all others are aliases.
791The domain system provides such a feature using the canonical name
792(CNAME) RR. A CNAME RR identifies its owner name as an alias, and
793specifies the corresponding canonical name in the RDATA section of the
794RR. If a CNAME RR is present at a node, no other data should be
795present; this ensures that the data for a canonical name and its aliases
796cannot be different. This rule also insures that a cached CNAME can be
797used without checking with an authoritative server for other RR types.
799CNAME RRs cause special action in DNS software. When a name server
800fails to find a desired RR in the resource set associated with the
801domain name, it checks to see if the resource set consists of a CNAME
802record with a matching class. If so, the name server includes the CNAME
803record in the response and restarts the query at the domain name
804specified in the data field of the CNAME record. The one exception to
805this rule is that queries which match the CNAME type are not restarted.
807For example, suppose a name server was processing a query with for USC-
808ISIC.ARPA, asking for type A information, and had the following resource
811 USC-ISIC.ARPA IN CNAME C.ISI.EDU
813 C.ISI.EDU IN A 10.0.0.52
815Both of these RRs would be returned in the response to the type A query,
816while a type CNAME or * query should return just the CNAME.
818Domain names in RRs which point at another name should always point at
819the primary name and not the alias. This avoids extra indirections in
820accessing information. For example, the address to name RR for the
823 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
825rather than pointing at USC-ISIC.ARPA. Of course, by the robustness
826principle, domain software should not fail when presented with CNAME
827chains or loops; CNAME chains should be followed and CNAME loops
828signalled as an error.
832Queries are messages which may be sent to a name server to provoke a
838RFC 1034 Domain Concepts and Facilities November 1987
841response. In the Internet, queries are carried in UDP datagrams or over
842TCP connections. The response by the name server either answers the
843question posed in the query, refers the requester to another set of name
844servers, or signals some error condition.
846In general, the user does not generate queries directly, but instead
847makes a request to a resolver which in turn sends one or more queries to
848name servers and deals with the error conditions and referrals that may
849result. Of course, the possible questions which can be asked in a query
850does shape the kind of service a resolver can provide.
852DNS queries and responses are carried in a standard message format. The
853message format has a header containing a number of fixed fields which
854are always present, and four sections which carry query parameters and
857The most important field in the header is a four bit field called an
858opcode which separates different queries. Of the possible 16 values,
859one (standard query) is part of the official protocol, two (inverse
860query and status query) are options, one (completion) is obsolete, and
861the rest are unassigned.
863The four sections are:
865Question Carries the query name and other query parameters.
867Answer Carries RRs which directly answer the query.
869Authority Carries RRs which describe other authoritative servers.
870 May optionally carry the SOA RR for the authoritative
871 data in the answer section.
873Additional Carries RRs which may be helpful in using the RRs in the
876Note that the content, but not the format, of these sections varies with
8793.7.1. Standard queries
881A standard query specifies a target domain name (QNAME), query type
882(QTYPE), and query class (QCLASS) and asks for RRs which match. This
883type of query makes up such a vast majority of DNS queries that we use
884the term "query" to mean standard query unless otherwise specified. The
885QTYPE and QCLASS fields are each 16 bits long, and are a superset of
886defined types and classes.
894RFC 1034 Domain Concepts and Facilities November 1987
897The QTYPE field may contain:
899<any type> matches just that type. (e.g., A, PTR).
901AXFR special zone transfer QTYPE.
903MAILB matches all mail box related RRs (e.g. MB and MG).
905* matches all RR types.
907The QCLASS field may contain:
909<any class> matches just that class (e.g., IN, CH).
911* matches aLL RR classes.
913Using the query domain name, QTYPE, and QCLASS, the name server looks
914for matching RRs. In addition to relevant records, the name server may
915return RRs that point toward a name server that has the desired
916information or RRs that are expected to be useful in interpreting the
917relevant RRs. For example, a name server that doesn't have the
918requested information may know a name server that does; a name server
919that returns a domain name in a relevant RR may also return the RR that
920binds that domain name to an address.
922For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
923ask the resolver for mail information about ISI.EDU, resulting in a
924query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer
927 ISI.EDU. MX 10 VENERA.ISI.EDU.
930while the additional section might be:
932 VAXA.ISI.EDU. A 10.2.0.27
934 VENERA.ISI.EDU. A 10.1.0.52
937Because the server assumes that if the requester wants mail exchange
938information, it will probably want the addresses of the mail exchanges
941Note that the QCLASS=* construct requires special interpretation
942regarding authority. Since a particular name server may not know all of
943the classes available in the domain system, it can never know if it is
944authoritative for all classes. Hence responses to QCLASS=* queries can
950RFC 1034 Domain Concepts and Facilities November 1987
953never be authoritative.
9553.7.2. Inverse queries (Optional)
957Name servers may also support inverse queries that map a particular
958resource to a domain name or domain names that have that resource. For
959example, while a standard query might map a domain name to a SOA RR, the
960corresponding inverse query might map the SOA RR back to the domain
963Implementation of this service is optional in a name server, but all
964name servers must at least be able to understand an inverse query
965message and return a not-implemented error response.
967The domain system cannot guarantee the completeness or uniqueness of
968inverse queries because the domain system is organized by domain name
969rather than by host address or any other resource type. Inverse queries
970are primarily useful for debugging and database maintenance activities.
972Inverse queries may not return the proper TTL, and do not indicate cases
973where the identified RR is one of a set (for example, one address for a
974host having multiple addresses). Therefore, the RRs returned in inverse
975queries should never be cached.
977Inverse queries are NOT an acceptable method for mapping host addresses
978to host names; use the IN-ADDR.ARPA domain instead.
980A detailed discussion of inverse queries is contained in [RFC-1035].
9823.8. Status queries (Experimental)
9863.9. Completion queries (Obsolete)
988The optional completion services described in RFCs 882 and 883 have been
989deleted. Redesigned services may become available in the future, or the
990opcodes may be reclaimed for other use.
996Name servers are the repositories of information that make up the domain
997database. The database is divided up into sections called zones, which
998are distributed among the name servers. While name servers can have
999several optional functions and sources of data, the essential task of a
1000name server is to answer queries using data in its zones. By design,
1004Mockapetris [Page 18]
1006RFC 1034 Domain Concepts and Facilities November 1987
1009name servers can answer queries in a simple manner; the response can
1010always be generated using only local data, and either contains the
1011answer to the question or a referral to other name servers "closer" to
1012the desired information.
1014A given zone will be available from several name servers to insure its
1015availability in spite of host or communication link failure. By
1016administrative fiat, we require every zone to be available on at least
1017two servers, and many zones have more redundancy than that.
1019A given name server will typically support one or more zones, but this
1020gives it authoritative information about only a small section of the
1021domain tree. It may also have some cached non-authoritative data about
1022other parts of the tree. The name server marks its responses to queries
1023so that the requester can tell whether the response comes from
1024authoritative data or not.
10264.2. How the database is divided into zones
1028The domain database is partitioned in two ways: by class, and by "cuts"
1029made in the name space between nodes.
1031The class partition is simple. The database for any class is organized,
1032delegated, and maintained separately from all other classes. Since, by
1033convention, the name spaces are the same for all classes, the separate
1034classes can be thought of as an array of parallel namespace trees. Note
1035that the data attached to nodes will be different for these different
1036parallel classes. The most common reasons for creating a new class are
1037the necessity for a new data format for existing types or a desire for a
1038separately managed version of the existing name space.
1040Within a class, "cuts" in the name space can be made between any two
1041adjacent nodes. After all cuts are made, each group of connected name
1042space is a separate zone. The zone is said to be authoritative for all
1043names in the connected region. Note that the "cuts" in the name space
1044may be in different places for different classes, the name servers may
1047These rules mean that every zone has at least one node, and hence domain
1048name, for which it is authoritative, and all of the nodes in a
1049particular zone are connected. Given, the tree structure, every zone
1050has a highest node which is closer to the root than any other node in
1051the zone. The name of this node is often used to identify the zone.
1053It would be possible, though not particularly useful, to partition the
1054name space so that each domain name was in a separate zone or so that
1055all nodes were in a single zone. Instead, the database is partitioned
1056at points where a particular organization wants to take over control of
1060Mockapetris [Page 19]
1062RFC 1034 Domain Concepts and Facilities November 1987
1065a subtree. Once an organization controls its own zone it can
1066unilaterally change the data in the zone, grow new tree sections
1067connected to the zone, delete existing nodes, or delegate new subzones
1070If the organization has substructure, it may want to make further
1071internal partitions to achieve nested delegations of name space control.
1072In some cases, such divisions are made purely to make database
1073maintenance more convenient.
10754.2.1. Technical considerations
1077The data that describes a zone has four major parts:
1079 - Authoritative data for all nodes within the zone.
1081 - Data that defines the top node of the zone (can be thought of
1082 as part of the authoritative data).
1084 - Data that describes delegated subzones, i.e., cuts around the
1087 - Data that allows access to name servers for subzones
1088 (sometimes called "glue" data).
1090All of this data is expressed in the form of RRs, so a zone can be
1091completely described in terms of a set of RRs. Whole zones can be
1092transferred between name servers by transferring the RRs, either carried
1093in a series of messages or by FTPing a master file which is a textual
1096The authoritative data for a zone is simply all of the RRs attached to
1097all of the nodes from the top node of the zone down to leaf nodes or
1098nodes above cuts around the bottom edge of the zone.
1100Though logically part of the authoritative data, the RRs that describe
1101the top node of the zone are especially important to the zone's
1102management. These RRs are of two types: name server RRs that list, one
1103per RR, all of the servers for the zone, and a single SOA RR that
1104describes zone management parameters.
1106The RRs that describe cuts around the bottom of the zone are NS RRs that
1107name the servers for the subzones. Since the cuts are between nodes,
1108these RRs are NOT part of the authoritative data of the zone, and should
1109be exactly the same as the corresponding RRs in the top node of the
1110subzone. Since name servers are always associated with zone boundaries,
1111NS RRs are only found at nodes which are the top node of some zone. In
1112the data that makes up a zone, NS RRs are found at the top node of the
1116Mockapetris [Page 20]
1118RFC 1034 Domain Concepts and Facilities November 1987
1121zone (and are authoritative) and at cuts around the bottom of the zone
1122(where they are not authoritative), but never in between.
1124One of the goals of the zone structure is that any zone have all the
1125data required to set up communications with the name servers for any
1126subzones. That is, parent zones have all the information needed to
1127access servers for their children zones. The NS RRs that name the
1128servers for subzones are often not enough for this task since they name
1129the servers, but do not give their addresses. In particular, if the
1130name of the name server is itself in the subzone, we could be faced with
1131the situation where the NS RRs tell us that in order to learn a name
1132server's address, we should contact the server using the address we wish
1133to learn. To fix this problem, a zone contains "glue" RRs which are not
1134part of the authoritative data, and are address RRs for the servers.
1135These RRs are only necessary if the name server's name is "below" the
1136cut, and are only used as part of a referral response.
11384.2.2. Administrative considerations
1140When some organization wants to control its own domain, the first step
1141is to identify the proper parent zone, and get the parent zone's owners
1142to agree to the delegation of control. While there are no particular
1143technical constraints dealing with where in the tree this can be done,
1144there are some administrative groupings discussed in [RFC-1032] which
1145deal with top level organization, and middle level zones are free to
1146create their own rules. For example, one university might choose to use
1147a single zone, while another might choose to organize by subzones
1148dedicated to individual departments or schools. [RFC-1033] catalogs
1149available DNS software an discusses administration procedures.
1151Once the proper name for the new subzone is selected, the new owners
1152should be required to demonstrate redundant name server support. Note
1153that there is no requirement that the servers for a zone reside in a
1154host which has a name in that domain. In many cases, a zone will be
1155more accessible to the internet at large if its servers are widely
1156distributed rather than being within the physical facilities controlled
1157by the same organization that manages the zone. For example, in the
1158current DNS, one of the name servers for the United Kingdom, or UK
1159domain, is found in the US. This allows US hosts to get UK data without
1160using limited transatlantic bandwidth.
1162As the last installation step, the delegation NS RRs and glue RRs
1163necessary to make the delegation effective should be added to the parent
1164zone. The administrators of both zones should insure that the NS and
1165glue RRs which mark both sides of the cut are consistent and remain so.
11674.3. Name server internals
1172Mockapetris [Page 21]
1174RFC 1034 Domain Concepts and Facilities November 1987
11774.3.1. Queries and responses
1179The principal activity of name servers is to answer standard queries.
1180Both the query and its response are carried in a standard message format
1181which is described in [RFC-1035]. The query contains a QTYPE, QCLASS,
1182and QNAME, which describe the types and classes of desired information
1183and the name of interest.
1185The way that the name server answers the query depends upon whether it
1186is operating in recursive mode or not:
1188 - The simplest mode for the server is non-recursive, since it
1189 can answer queries using only local information: the response
1190 contains an error, the answer, or a referral to some other
1191 server "closer" to the answer. All name servers must
1192 implement non-recursive queries.
1194 - The simplest mode for the client is recursive, since in this
1195 mode the name server acts in the role of a resolver and
1196 returns either an error or the answer, but never referrals.
1197 This service is optional in a name server, and the name server
1198 may also choose to restrict the clients which can use
1201Recursive service is helpful in several situations:
1203 - a relatively simple requester that lacks the ability to use
1204 anything other than a direct answer to the question.
1206 - a request that needs to cross protocol or other boundaries and
1207 can be sent to a server which can act as intermediary.
1209 - a network where we want to concentrate the cache rather than
1210 having a separate cache for each client.
1212Non-recursive service is appropriate if the requester is capable of
1213pursuing referrals and interested in information which will aid future
1216The use of recursive mode is limited to cases where both the client and
1217the name server agree to its use. The agreement is negotiated through
1218the use of two bits in query and response messages:
1220 - The recursion available, or RA bit, is set or cleared by a
1221 name server in all responses. The bit is true if the name
1222 server is willing to provide recursive service for the client,
1223 regardless of whether the client requested recursive service.
1224 That is, RA signals availability rather than use.
1228Mockapetris [Page 22]
1230RFC 1034 Domain Concepts and Facilities November 1987
1233 - Queries contain a bit called recursion desired or RD. This
1234 bit specifies specifies whether the requester wants recursive
1235 service for this query. Clients may request recursive service
1236 from any name server, though they should depend upon receiving
1237 it only from servers which have previously sent an RA, or
1238 servers which have agreed to provide service through private
1239 agreement or some other means outside of the DNS protocol.
1241The recursive mode occurs when a query with RD set arrives at a server
1242which is willing to provide recursive service; the client can verify
1243that recursive mode was used by checking that both RA and RD are set in
1244the reply. Note that the name server should never perform recursive
1245service unless asked via RD, since this interferes with trouble shooting
1246of name servers and their databases.
1248If recursive service is requested and available, the recursive response
1249to a query will be one of the following:
1251 - The answer to the query, possibly preface by one or more CNAME
1252 RRs that specify aliases encountered on the way to an answer.
1254 - A name error indicating that the name does not exist. This
1255 may include CNAME RRs that indicate that the original query
1256 name was an alias for a name which does not exist.
1258 - A temporary error indication.
1260If recursive service is not requested or is not available, the non-
1261recursive response will be one of the following:
1263 - An authoritative name error indicating that the name does not
1266 - A temporary error indication.
1268 - Some combination of:
1270 RRs that answer the question, together with an indication
1271 whether the data comes from a zone or is cached.
1273 A referral to name servers which have zones which are closer
1274 ancestors to the name than the server sending the reply.
1276 - RRs that the name server thinks will prove useful to the
1284Mockapetris [Page 23]
1286RFC 1034 Domain Concepts and Facilities November 1987
1291The actual algorithm used by the name server will depend on the local OS
1292and data structures used to store RRs. The following algorithm assumes
1293that the RRs are organized in several tree structures, one for each
1294zone, and another for the cache:
1296 1. Set or clear the value of recursion available in the response
1297 depending on whether the name server is willing to provide
1298 recursive service. If recursive service is available and
1299 requested via the RD bit in the query, go to step 5,
1302 2. Search the available zones for the zone which is the nearest
1303 ancestor to QNAME. If such a zone is found, go to step 3,
1306 3. Start matching down, label by label, in the zone. The
1307 matching process can terminate several ways:
1309 a. If the whole of QNAME is matched, we have found the
1312 If the data at the node is a CNAME, and QTYPE doesn't
1313 match CNAME, copy the CNAME RR into the answer section
1314 of the response, change QNAME to the canonical name in
1315 the CNAME RR, and go back to step 1.
1317 Otherwise, copy all RRs which match QTYPE into the
1318 answer section and go to step 6.
1320 b. If a match would take us out of the authoritative data,
1321 we have a referral. This happens when we encounter a
1322 node with NS RRs marking cuts along the bottom of a
1325 Copy the NS RRs for the subzone into the authority
1326 section of the reply. Put whatever addresses are
1327 available into the additional section, using glue RRs
1328 if the addresses are not available from authoritative
1329 data or the cache. Go to step 4.
1331 c. If at some label, a match is impossible (i.e., the
1332 corresponding label does not exist), look to see if a
1333 the "*" label exists.
1335 If the "*" label does not exist, check whether the name
1336 we are looking for is the original QNAME in the query
1340Mockapetris [Page 24]
1342RFC 1034 Domain Concepts and Facilities November 1987
1345 or a name we have followed due to a CNAME. If the name
1346 is original, set an authoritative name error in the
1347 response and exit. Otherwise just exit.
1349 If the "*" label does exist, match RRs at that node
1350 against QTYPE. If any match, copy them into the answer
1351 section, but set the owner of the RR to be QNAME, and
1352 not the node with the "*" label. Go to step 6.
1354 4. Start matching down in the cache. If QNAME is found in the
1355 cache, copy all RRs attached to it that match QTYPE into the
1356 answer section. If there was no delegation from
1357 authoritative data, look for the best one from the cache, and
1358 put it in the authority section. Go to step 6.
1360 5. Using the local resolver or a copy of its algorithm (see
1361 resolver section of this memo) to answer the query. Store
1362 the results, including any intermediate CNAMEs, in the answer
1363 section of the response.
1365 6. Using local data only, attempt to add other RRs which may be
1366 useful to the additional section of the query. Exit.
1370In the previous algorithm, special treatment was given to RRs with owner
1371names starting with the label "*". Such RRs are called wildcards.
1372Wildcard RRs can be thought of as instructions for synthesizing RRs.
1373When the appropriate conditions are met, the name server creates RRs
1374with an owner name equal to the query name and contents taken from the
1377This facility is most often used to create a zone which will be used to
1378forward mail from the Internet to some other mail system. The general
1379idea is that any name in that zone which is presented to server in a
1380query will be assumed to exist, with certain properties, unless explicit
1381evidence exists to the contrary. Note that the use of the term zone
1382here, instead of domain, is intentional; such defaults do not propagate
1383across zone boundaries, although a subzone may choose to achieve that
1384appearance by setting up similar defaults.
1386The contents of the wildcard RRs follows the usual rules and formats for
1387RRs. The wildcards in the zone have an owner name that controls the
1388query names they will match. The owner name of the wildcard RRs is of
1389the form "*.<anydomain>", where <anydomain> is any domain name.
1390<anydomain> should not contain other * labels, and should be in the
1391authoritative data of the zone. The wildcards potentially apply to
1392descendants of <anydomain>, but not to <anydomain> itself. Another way
1396Mockapetris [Page 25]
1398RFC 1034 Domain Concepts and Facilities November 1987
1401to look at this is that the "*" label always matches at least one whole
1402label and sometimes more, but always whole labels.
1404Wildcard RRs do not apply:
1406 - When the query is in another zone. That is, delegation cancels
1407 the wildcard defaults.
1409 - When the query name or a name between the wildcard domain and
1410 the query name is know to exist. For example, if a wildcard
1411 RR has an owner name of "*.X", and the zone also contains RRs
1412 attached to B.X, the wildcards would apply to queries for name
1413 Z.X (presuming there is no explicit information for Z.X), but
1414 not to B.X, A.B.X, or X.
1416A * label appearing in a query name has no special effect, but can be
1417used to test for wildcards in an authoritative zone; such a query is the
1418only way to get a response containing RRs with an owner name with * in
1419it. The result of such a query should not be cached.
1421Note that the contents of the wildcard RRs are not modified when used to
1424To illustrate the use of wildcard RRs, suppose a large company with a
1425large, non-IP/TCP, network wanted to create a mail gateway. If the
1426company was called X.COM, and IP/TCP capable gateway machine was called
1427A.X.COM, the following RRs might be entered into the COM zone:
1431 *.X.COM MX 10 A.X.COM
1434 A.X.COM MX 10 A.X.COM
1436 *.A.X.COM MX 10 A.X.COM
1438This would cause any MX query for any domain name ending in X.COM to
1439return an MX RR pointing at A.X.COM. Two wildcard RRs are required
1440since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
1441subtree by the explicit data for A.X.COM. Note also that the explicit
1442MX data at X.COM and A.X.COM is required, and that none of the RRs above
1443would match a query name of XX.COM.
14454.3.4. Negative response caching (Optional)
1447The DNS provides an optional service which allows name servers to
1448distribute, and resolvers to cache, negative results with TTLs. For
1452Mockapetris [Page 26]
1454RFC 1034 Domain Concepts and Facilities November 1987
1457example, a name server can distribute a TTL along with a name error
1458indication, and a resolver receiving such information is allowed to
1459assume that the name does not exist during the TTL period without
1460consulting authoritative data. Similarly, a resolver can make a query
1461with a QTYPE which matches multiple types, and cache the fact that some
1462of the types are not present.
1464This feature can be particularly important in a system which implements
1465naming shorthands that use search lists beacuse a popular shorthand,
1466which happens to require a suffix toward the end of the search list,
1467will generate multiple name errors whenever it is used.
1469The method is that a name server may add an SOA RR to the additional
1470section of a response when that response is authoritative. The SOA must
1471be that of the zone which was the source of the authoritative data in
1472the answer section, or name error if applicable. The MINIMUM field of
1473the SOA controls the length of time that the negative result may be
1476Note that in some circumstances, the answer section may contain multiple
1477owner names. In this case, the SOA mechanism should only be used for
1478the data which matches QNAME, which is the only authoritative data in
1481Name servers and resolvers should never attempt to add SOAs to the
1482additional section of a non-authoritative response, or attempt to infer
1483results which are not directly stated in an authoritative response.
1484There are several reasons for this, including: cached information isn't
1485usually enough to match up RRs and their zone names, SOA RRs may be
1486cached due to direct SOA queries, and name servers are not required to
1487output the SOAs in the authority section.
1489This feature is optional, although a refined version is expected to
1490become part of the standard protocol in the future. Name servers are
1491not required to add the SOA RRs in all authoritative responses, nor are
1492resolvers required to cache negative results. Both are recommended.
1493All resolvers and recursive name servers are required to at least be
1494able to ignore the SOA RR when it is present in a response.
1496Some experiments have also been proposed which will use this feature.
1497The idea is that if cached data is known to come from a particular zone,
1498and if an authoritative copy of the zone's SOA is obtained, and if the
1499zone's SERIAL has not changed since the data was cached, then the TTL of
1500the cached data can be reset to the zone MINIMUM value if it is smaller.
1501This usage is mentioned for planning purposes only, and is not
1508Mockapetris [Page 27]
1510RFC 1034 Domain Concepts and Facilities November 1987
15134.3.5. Zone maintenance and transfers
1515Part of the job of a zone administrator is to maintain the zones at all
1516of the name servers which are authoritative for the zone. When the
1517inevitable changes are made, they must be distributed to all of the name
1518servers. While this distribution can be accomplished using FTP or some
1519other ad hoc procedure, the preferred method is the zone transfer part
1522The general model of automatic zone transfer or refreshing is that one
1523of the name servers is the master or primary for the zone. Changes are
1524coordinated at the primary, typically by editing a master file for the
1525zone. After editing, the administrator signals the master server to
1526load the new zone. The other non-master or secondary servers for the
1527zone periodically check for changes (at a selectable interval) and
1528obtain new zone copies when changes have been made.
1530To detect changes, secondaries just check the SERIAL field of the SOA
1531for the zone. In addition to whatever other changes are made, the
1532SERIAL field in the SOA of the zone is always advanced whenever any
1533change is made to the zone. The advancing can be a simple increment, or
1534could be based on the write date and time of the master file, etc. The
1535purpose is to make it possible to determine which of two copies of a
1536zone is more recent by comparing serial numbers. Serial number advances
1537and comparisons use sequence space arithmetic, so there is a theoretic
1538limit on how fast a zone can be updated, basically that old copies must
1539die out before the serial number covers half of its 32 bit range. In
1540practice, the only concern is that the compare operation deals properly
1541with comparisons around the boundary between the most positive and most
1542negative 32 bit numbers.
1544The periodic polling of the secondary servers is controlled by
1545parameters in the SOA RR for the zone, which set the minimum acceptable
1546polling intervals. The parameters are called REFRESH, RETRY, and
1547EXPIRE. Whenever a new zone is loaded in a secondary, the secondary
1548waits REFRESH seconds before checking with the primary for a new serial.
1549If this check cannot be completed, new checks are started every RETRY
1550seconds. The check is a simple query to the primary for the SOA RR of
1551the zone. If the serial field in the secondary's zone copy is equal to
1552the serial returned by the primary, then no changes have occurred, and
1553the REFRESH interval wait is restarted. If the secondary finds it
1554impossible to perform a serial check for the EXPIRE interval, it must
1555assume that its copy of the zone is obsolete an discard it.
1557When the poll shows that the zone has changed, then the secondary server
1558must request a zone transfer via an AXFR request for the zone. The AXFR
1559may cause an error, such as refused, but normally is answered by a
1560sequence of response messages. The first and last messages must contain
1564Mockapetris [Page 28]
1566RFC 1034 Domain Concepts and Facilities November 1987
1569the data for the top authoritative node of the zone. Intermediate
1570messages carry all of the other RRs from the zone, including both
1571authoritative and non-authoritative RRs. The stream of messages allows
1572the secondary to construct a copy of the zone. Because accuracy is
1573essential, TCP or some other reliable protocol must be used for AXFR
1576Each secondary server is required to perform the following operations
1577against the master, but may also optionally perform these operations
1578against other secondary servers. This strategy can improve the transfer
1579process when the primary is unavailable due to host downtime or network
1580problems, or when a secondary server has better network access to an
1581"intermediate" secondary than to the primary.
1587Resolvers are programs that interface user programs to domain name
1588servers. In the simplest case, a resolver receives a request from a
1589user program (e.g., mail programs, TELNET, FTP) in the form of a
1590subroutine call, system call etc., and returns the desired information
1591in a form compatible with the local host's data formats.
1593The resolver is located on the same machine as the program that requests
1594the resolver's services, but it may need to consult name servers on
1595other hosts. Because a resolver may need to consult several name
1596servers, or may have the requested information in a local cache, the
1597amount of time that a resolver will take to complete can vary quite a
1598bit, from milliseconds to several seconds.
1600A very important goal of the resolver is to eliminate network delay and
1601name server load from most requests by answering them from its cache of
1602prior results. It follows that caches which are shared by multiple
1603processes, users, machines, etc., are more efficient than non-shared
16065.2. Client-resolver interface
16085.2.1. Typical functions
1610The client interface to the resolver is influenced by the local host's
1611conventions, but the typical resolver-client interface has three
1614 1. Host name to host address translation.
1616 This function is often defined to mimic a previous HOSTS.TXT
1620Mockapetris [Page 29]
1622RFC 1034 Domain Concepts and Facilities November 1987
1625 based function. Given a character string, the caller wants
1626 one or more 32 bit IP addresses. Under the DNS, it
1627 translates into a request for type A RRs. Since the DNS does
1628 not preserve the order of RRs, this function may choose to
1629 sort the returned addresses or select the "best" address if
1630 the service returns only one choice to the client. Note that
1631 a multiple address return is recommended, but a single
1632 address may be the only way to emulate prior HOSTS.TXT
1635 2. Host address to host name translation
1637 This function will often follow the form of previous
1638 functions. Given a 32 bit IP address, the caller wants a
1639 character string. The octets of the IP address are reversed,
1640 used as name components, and suffixed with "IN-ADDR.ARPA". A
1641 type PTR query is used to get the RR with the primary name of
1642 the host. For example, a request for the host name
1643 corresponding to IP address 1.2.3.4 looks for PTR RRs for
1644 domain name "4.3.2.1.IN-ADDR.ARPA".
1646 3. General lookup function
1648 This function retrieves arbitrary information from the DNS,
1649 and has no counterpart in previous systems. The caller
1650 supplies a QNAME, QTYPE, and QCLASS, and wants all of the
1651 matching RRs. This function will often use the DNS format
1652 for all RR data instead of the local host's, and returns all
1653 RR content (e.g., TTL) instead of a processed form with local
1654 quoting conventions.
1656When the resolver performs the indicated function, it usually has one of
1657the following results to pass back to the client:
1659 - One or more RRs giving the requested data.
1661 In this case the resolver returns the answer in the
1664 - A name error (NE).
1666 This happens when the referenced name does not exist. For
1667 example, a user may have mistyped a host name.
1669 - A data not found error.
1671 This happens when the referenced name exists, but data of the
1672 appropriate type does not. For example, a host address
1676Mockapetris [Page 30]
1678RFC 1034 Domain Concepts and Facilities November 1987
1681 function applied to a mailbox name would return this error
1682 since the name exists, but no address RR is present.
1684It is important to note that the functions for translating between host
1685names and addresses may combine the "name error" and "data not found"
1686error conditions into a single type of error return, but the general
1687function should not. One reason for this is that applications may ask
1688first for one type of information about a name followed by a second
1689request to the same name for some other type of information; if the two
1690errors are combined, then useless queries may slow the application.
1694While attempting to resolve a particular request, the resolver may find
1695that the name in question is an alias. For example, the resolver might
1696find that the name given for host name to address translation is an
1697alias when it finds the CNAME RR. If possible, the alias condition
1698should be signalled back from the resolver to the client.
1700In most cases a resolver simply restarts the query at the new name when
1701it encounters a CNAME. However, when performing the general function,
1702the resolver should not pursue aliases when the CNAME RR matches the
1703query type. This allows queries which ask whether an alias is present.
1704For example, if the query type is CNAME, the user is interested in the
1705CNAME RR itself, and not the RRs at the name it points to.
1707Several special conditions can occur with aliases. Multiple levels of
1708aliases should be avoided due to their lack of efficiency, but should
1709not be signalled as an error. Alias loops and aliases which point to
1710non-existent names should be caught and an error condition passed back
17135.2.3. Temporary failures
1715In a less than perfect world, all resolvers will occasionally be unable
1716to resolve a particular request. This condition can be caused by a
1717resolver which becomes separated from the rest of the network due to a
1718link failure or gateway problem, or less often by coincident failure or
1719unavailability of all servers for a particular domain.
1721It is essential that this sort of condition should not be signalled as a
1722name or data not present error to applications. This sort of behavior
1723is annoying to humans, and can wreak havoc when mail systems use the
1726While in some cases it is possible to deal with such a temporary problem
1727by blocking the request indefinitely, this is usually not a good choice,
1728particularly when the client is a server process that could move on to
1732Mockapetris [Page 31]
1734RFC 1034 Domain Concepts and Facilities November 1987
1737other tasks. The recommended solution is to always have temporary
1738failure as one of the possible results of a resolver function, even
1739though this may make emulation of existing HOSTS.TXT functions more
17425.3. Resolver internals
1744Every resolver implementation uses slightly different algorithms, and
1745typically spends much more logic dealing with errors of various sorts
1746than typical occurances. This section outlines a recommended basic
1747strategy for resolver operation, but leaves details to [RFC-1035].
17495.3.1. Stub resolvers
1751One option for implementing a resolver is to move the resolution
1752function out of the local machine and into a name server which supports
1753recursive queries. This can provide an easy method of providing domain
1754service in a PC which lacks the resources to perform the resolver
1755function, or can centralize the cache for a whole local network or
1758All that the remaining stub needs is a list of name server addresses
1759that will perform the recursive requests. This type of resolver
1760presumably needs the information in a configuration file, since it
1761probably lacks the sophistication to locate it in the domain database.
1762The user also needs to verify that the listed servers will perform the
1763recursive service; a name server is free to refuse to perform recursive
1764services for any or all clients. The user should consult the local
1765system administrator to find name servers willing to perform the
1768This type of service suffers from some drawbacks. Since the recursive
1769requests may take an arbitrary amount of time to perform, the stub may
1770have difficulty optimizing retransmission intervals to deal with both
1771lost UDP packets and dead servers; the name server can be easily
1772overloaded by too zealous a stub if it interprets retransmissions as new
1773requests. Use of TCP may be an answer, but TCP may well place burdens
1774on the host's capabilities which are similar to those of a real
1779In addition to its own resources, the resolver may also have shared
1780access to zones maintained by a local name server. This gives the
1781resolver the advantage of more rapid access, but the resolver must be
1782careful to never let cached information override zone data. In this
1783discussion the term "local information" is meant to mean the union of
1784the cache and such shared zones, with the understanding that
1788Mockapetris [Page 32]
1790RFC 1034 Domain Concepts and Facilities November 1987
1793authoritative data is always used in preference to cached data when both
1796The following resolver algorithm assumes that all functions have been
1797converted to a general lookup function, and uses the following data
1798structures to represent the state of a request in progress in the
1801SNAME the domain name we are searching for.
1803STYPE the QTYPE of the search request.
1805SCLASS the QCLASS of the search request.
1807SLIST a structure which describes the name servers and the
1808 zone which the resolver is currently trying to query.
1809 This structure keeps track of the resolver's current
1810 best guess about which name servers hold the desired
1811 information; it is updated when arriving information
1812 changes the guess. This structure includes the
1813 equivalent of a zone name, the known name servers for
1814 the zone, the known addresses for the name servers, and
1815 history information which can be used to suggest which
1816 server is likely to be the best one to try next. The
1817 zone name equivalent is a match count of the number of
1818 labels from the root down which SNAME has in common with
1819 the zone being queried; this is used as a measure of how
1820 "close" the resolver is to SNAME.
1822SBELT a "safety belt" structure of the same form as SLIST,
1823 which is initialized from a configuration file, and
1824 lists servers which should be used when the resolver
1825 doesn't have any local information to guide name server
1826 selection. The match count will be -1 to indicate that
1827 no labels are known to match.
1829CACHE A structure which stores the results from previous
1830 responses. Since resolvers are responsible for
1831 discarding old RRs whose TTL has expired, most
1832 implementations convert the interval specified in
1833 arriving RRs to some sort of absolute time when the RR
1834 is stored in the cache. Instead of counting the TTLs
1835 down individually, the resolver just ignores or discards
1836 old RRs when it runs across them in the course of a
1837 search, or discards them during periodic sweeps to
1838 reclaim the memory consumed by old RRs.
1844Mockapetris [Page 33]
1846RFC 1034 Domain Concepts and Facilities November 1987
1851The top level algorithm has four steps:
1853 1. See if the answer is in local information, and if so return
1856 2. Find the best servers to ask.
1858 3. Send them queries until one returns a response.
1860 4. Analyze the response, either:
1862 a. if the response answers the question or contains a name
1863 error, cache the data as well as returning it back to
1866 b. if the response contains a better delegation to other
1867 servers, cache the delegation information, and go to
1870 c. if the response shows a CNAME and that is not the
1871 answer itself, cache the CNAME, change the SNAME to the
1872 canonical name in the CNAME RR and go to step 1.
1874 d. if the response shows a servers failure or other
1875 bizarre contents, delete the server from the SLIST and
1878Step 1 searches the cache for the desired data. If the data is in the
1879cache, it is assumed to be good enough for normal use. Some resolvers
1880have an option at the user interface which will force the resolver to
1881ignore the cached data and consult with an authoritative server. This
1882is not recommended as the default. If the resolver has direct access to
1883a name server's zones, it should check to see if the desired data is
1884present in authoritative form, and if so, use the authoritative data in
1885preference to cached data.
1887Step 2 looks for a name server to ask for the required data. The
1888general strategy is to look for locally-available name server RRs,
1889starting at SNAME, then the parent domain name of SNAME, the
1890grandparent, and so on toward the root. Thus if SNAME were
1891Mockapetris.ISI.EDU, this step would look for NS RRs for
1892Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
1893These NS RRs list the names of hosts for a zone at or above SNAME. Copy
1894the names into SLIST. Set up their addresses using local data. It may
1895be the case that the addresses are not available. The resolver has many
1896choices here; the best is to start parallel resolver processes looking
1900Mockapetris [Page 34]
1902RFC 1034 Domain Concepts and Facilities November 1987
1905for the addresses while continuing onward with the addresses which are
1906available. Obviously, the design choices and options are complicated
1907and a function of the local host's capabilities. The recommended
1908priorities for the resolver designer are:
1910 1. Bound the amount of work (packets sent, parallel processes
1911 started) so that a request can't get into an infinite loop or
1912 start off a chain reaction of requests or queries with other
1913 implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
1916 2. Get back an answer if at all possible.
1918 3. Avoid unnecessary transmissions.
1920 4. Get the answer as quickly as possible.
1922If the search for NS RRs fails, then the resolver initializes SLIST from
1923the safety belt SBELT. The basic idea is that when the resolver has no
1924idea what servers to ask, it should use information from a configuration
1925file that lists several servers which are expected to be helpful.
1926Although there are special situations, the usual choice is two of the
1927root servers and two of the servers for the host's domain. The reason
1928for two of each is for redundancy. The root servers will provide
1929eventual access to all of the domain space. The two local servers will
1930allow the resolver to continue to resolve local names if the local
1931network becomes isolated from the internet due to gateway or link
1934In addition to the names and addresses of the servers, the SLIST data
1935structure can be sorted to use the best servers first, and to insure
1936that all addresses of all servers are used in a round-robin manner. The
1937sorting can be a simple function of preferring addresses on the local
1938network over others, or may involve statistics from past events, such as
1939previous response times and batting averages.
1941Step 3 sends out queries until a response is received. The strategy is
1942to cycle around all of the addresses for all of the servers with a
1943timeout between each transmission. In practice it is important to use
1944all addresses of a multihomed host, and too aggressive a retransmission
1945policy actually slows response when used by multiple resolvers
1946contending for the same name server and even occasionally for a single
1947resolver. SLIST typically contains data values to control the timeouts
1948and keep track of previous transmissions.
1950Step 4 involves analyzing responses. The resolver should be highly
1951paranoid in its parsing of responses. It should also check that the
1952response matches the query it sent using the ID field in the response.
1956Mockapetris [Page 35]
1958RFC 1034 Domain Concepts and Facilities November 1987
1961The ideal answer is one from a server authoritative for the query which
1962either gives the required data or a name error. The data is passed back
1963to the user and entered in the cache for future use if its TTL is
1966If the response shows a delegation, the resolver should check to see
1967that the delegation is "closer" to the answer than the servers in SLIST
1968are. This can be done by comparing the match count in SLIST with that
1969computed from SNAME and the NS RRs in the delegation. If not, the reply
1970is bogus and should be ignored. If the delegation is valid the NS
1971delegation RRs and any address RRs for the servers should be cached.
1972The name servers are entered in the SLIST, and the search is restarted.
1974If the response contains a CNAME, the search is restarted at the CNAME
1975unless the response has the data for the canonical name or if the CNAME
1976is the answer itself.
1978Details and implementation hints can be found in [RFC-1035].
1982In our sample domain space, suppose we wanted separate administrative
1983control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
1984allocate name servers as follows:
1987 |(C.ISI.EDU,SRI-NIC.ARPA
1989 +---------------------+------------------+
1992 |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, |
1993 | A.ISI.EDU | C.ISI.EDU) |
1994 +-----+-----+ | +------+-----+-----+
1996 BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
1998 +--------+------------------+---------------+--------+
2001 |(XX.LCS.MIT.EDU, ISI
2002 |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
2003 +---+---+ | A.ISI.EDU)
2005 LCS ACHILLES +--+-----+-----+--------+
2007 XX A C VAXA VENERA Mockapetris
2012Mockapetris [Page 36]
2014RFC 1034 Domain Concepts and Facilities November 1987
2017In this example, the authoritative name server is shown in parentheses
2018at the point in the domain tree at which is assumes control.
2020Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
2021A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The
2022EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers
2023may have zones which are contiguous or disjoint. In this scenario,
2024C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
2025has contiguous zones at the root and MIL domains, but also has a non-
2026contiguous zone at ISI.EDU.
20286.1. C.ISI.EDU name server
2030C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
2031class, and would have zones for these domains. The zone data for the
2032root domain might be:
2034 . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
2036 1800 ;refresh every 30 min
2037 300 ;retry every 5 min
2038 604800 ;expire after a week
2039 86400) ;minimum of a day
2044 MIL. 86400 NS SRI-NIC.ARPA.
2047 EDU. 86400 NS SRI-NIC.ARPA.
2050 SRI-NIC.ARPA. A 26.0.0.73
2053 HINFO DEC-2060 TOPS20
2055 ACC.ARPA. A 26.6.0.65
2056 HINFO PDP-11/70 UNIX
2059 USC-ISIC.ARPA. CNAME C.ISI.EDU.
2061 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2062 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
2063 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
2064 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
2068Mockapetris [Page 37]
2070RFC 1034 Domain Concepts and Facilities November 1987
2073 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
2075 A.ISI.EDU. 86400 A 26.3.0.103
2076 C.ISI.EDU. 86400 A 10.0.0.52
2078This data is represented as it would be in a master file. Most RRs are
2079single line entries; the sole exception here is the SOA RR, which uses
2080"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
2081Since the class of all RRs in a zone must be the same, only the first RR
2082in a zone need specify the class. When a name server loads a zone, it
2083forces the TTL of all authoritative RRs to be at least the MINIMUM field
2084of the SOA, here 86400 seconds, or one day. The NS RRs marking
2085delegation of the MIL and EDU domains, together with the glue RRs for
2086the servers host addresses, are not part of the authoritative data in
2087the zone, and hence have explicit TTLs.
2089Four RRs are attached to the root node: the SOA which describes the root
2090zone and the 3 NS RRs which list the name servers for the root. The
2091data in the SOA RR describes the management of the zone. The zone data
2092is maintained on host SRI-NIC.ARPA, and the responsible party for the
2093zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400
2094second minimum TTL, which means that all authoritative data in the zone
2095has at least that TTL, although higher values may be explicitly
2098The NS RRs for the MIL and EDU domains mark the boundary between the
2099root zone and the MIL and EDU zones. Note that in this example, the
2100lower zones happen to be supported by name servers which also support
2103The master file for the EDU zone might be stated relative to the origin
2104EDU. The zone data for the EDU domain might be:
2106 EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
2108 1800 ;refresh every 30 minutes
2109 300 ;retry every 5 minutes
2110 604800 ;expire after a week
2111 86400 ;minimum of a day
2116 UCI 172800 NS ICS.UCI
2118 ICS.UCI 172800 A 192.5.19.1
2119 ROME.UCI 172800 A 192.5.19.31
2124Mockapetris [Page 38]
2126RFC 1034 Domain Concepts and Facilities November 1987
2129 ISI 172800 NS VAXA.ISI
2131 172800 NS VENERA.ISI.EDU.
2132 VAXA.ISI 172800 A 10.2.0.27
2134 VENERA.ISI.EDU. 172800 A 10.1.0.52
2136 A.ISI 172800 A 26.3.0.103
2138 UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
2139 172800 NS UMN-REI-UC.ARPA.
2140 LOUIE.UDEL.EDU. 172800 A 10.0.0.96
2143 YALE.EDU. 172800 NS YALE.ARPA.
2144 YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
2146 MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
2147 43200 NS ACHILLES.MIT.EDU.
2148 XX.LCS.MIT.EDU. 43200 A 10.0.0.44
2149 ACHILLES.MIT.EDU. 43200 A 18.72.0.8
2151Note the use of relative names here. The owner name for the ISI.EDU. is
2152stated using a relative name, as are two of the name server RR contents.
2153Relative and absolute domain names may be freely intermixed in a master
21556.2. Example standard queries
2157The following queries and responses illustrate name server behavior.
2158Unless otherwise noted, the queries do not have recursion desired (RD)
2159in the header. Note that the answers to non-recursive queries do depend
2160on the server being asked, but do not depend on the identity of the
2180Mockapetris [Page 39]
2182RFC 1034 Domain Concepts and Facilities November 1987
21856.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
2187The query would look like:
2189 +---------------------------------------------------+
2190 Header | OPCODE=SQUERY |
2191 +---------------------------------------------------+
2192 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2193 +---------------------------------------------------+
2195 +---------------------------------------------------+
2196 Authority | <empty> |
2197 +---------------------------------------------------+
2198 Additional | <empty> |
2199 +---------------------------------------------------+
2201The response from C.ISI.EDU would be:
2203 +---------------------------------------------------+
2204 Header | OPCODE=SQUERY, RESPONSE, AA |
2205 +---------------------------------------------------+
2206 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2207 +---------------------------------------------------+
2208 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2209 | 86400 IN A 10.0.0.51 |
2210 +---------------------------------------------------+
2211 Authority | <empty> |
2212 +---------------------------------------------------+
2213 Additional | <empty> |
2214 +---------------------------------------------------+
2216The header of the response looks like the header of the query, except
2217that the RESPONSE bit is set, indicating that this message is a
2218response, not a query, and the Authoritative Answer (AA) bit is set
2219indicating that the address RRs in the answer section are from
2220authoritative data. The question section of the response matches the
2221question section of the query.
2236Mockapetris [Page 40]
2238RFC 1034 Domain Concepts and Facilities November 1987
2241If the same query was sent to some other server which was not
2242authoritative for SRI-NIC.ARPA, the response might be:
2244 +---------------------------------------------------+
2245 Header | OPCODE=SQUERY,RESPONSE |
2246 +---------------------------------------------------+
2247 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A |
2248 +---------------------------------------------------+
2249 Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 |
2250 | 1777 IN A 26.0.0.73 |
2251 +---------------------------------------------------+
2252 Authority | <empty> |
2253 +---------------------------------------------------+
2254 Additional | <empty> |
2255 +---------------------------------------------------+
2257This response is different from the previous one in two ways: the header
2258does not have AA set, and the TTLs are different. The inference is that
2259the data did not come from a zone, but from a cache. The difference
2260between the authoritative TTL and the TTL here is due to aging of the
2261data in a cache. The difference in ordering of the RRs in the answer
2262section is not significant.
22646.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
2266A query similar to the previous one, but using a QTYPE of *, would
2267receive the following response from C.ISI.EDU:
2269 +---------------------------------------------------+
2270 Header | OPCODE=SQUERY, RESPONSE, AA |
2271 +---------------------------------------------------+
2272 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2273 +---------------------------------------------------+
2274 Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2276 | MX 0 SRI-NIC.ARPA. |
2277 | HINFO DEC-2060 TOPS20 |
2278 +---------------------------------------------------+
2279 Authority | <empty> |
2280 +---------------------------------------------------+
2281 Additional | <empty> |
2282 +---------------------------------------------------+
2292Mockapetris [Page 41]
2294RFC 1034 Domain Concepts and Facilities November 1987
2297If a similar query was directed to two name servers which are not
2298authoritative for SRI-NIC.ARPA, the responses might be:
2300 +---------------------------------------------------+
2301 Header | OPCODE=SQUERY, RESPONSE |
2302 +---------------------------------------------------+
2303 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2304 +---------------------------------------------------+
2305 Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 |
2307 +---------------------------------------------------+
2308 Authority | <empty> |
2309 +---------------------------------------------------+
2310 Additional | <empty> |
2311 +---------------------------------------------------+
2315 +---------------------------------------------------+
2316 Header | OPCODE=SQUERY, RESPONSE |
2317 +---------------------------------------------------+
2318 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* |
2319 +---------------------------------------------------+
2320 Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 |
2321 +---------------------------------------------------+
2322 Authority | <empty> |
2323 +---------------------------------------------------+
2324 Additional | <empty> |
2325 +---------------------------------------------------+
2327Neither of these answers have AA set, so neither response comes from
2328authoritative data. The different contents and different TTLs suggest
2329that the two servers cached data at different times, and that the first
2330server cached the response to a QTYPE=A query and the second cached the
2331response to a HINFO query.
2348Mockapetris [Page 42]
2350RFC 1034 Domain Concepts and Facilities November 1987
23536.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
2355This type of query might be result from a mailer trying to look up
2356routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
2357The response from C.ISI.EDU would be:
2359 +---------------------------------------------------+
2360 Header | OPCODE=SQUERY, RESPONSE, AA |
2361 +---------------------------------------------------+
2362 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX |
2363 +---------------------------------------------------+
2364 Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.|
2365 +---------------------------------------------------+
2366 Authority | <empty> |
2367 +---------------------------------------------------+
2368 Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 |
2370 +---------------------------------------------------+
2372This response contains the MX RR in the answer section of the response.
2373The additional section contains the address RRs because the name server
2374at C.ISI.EDU guesses that the requester will need the addresses in order
2375to properly use the information carried by the MX.
23776.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
2379C.ISI.EDU would reply to this query with:
2381 +---------------------------------------------------+
2382 Header | OPCODE=SQUERY, RESPONSE, AA |
2383 +---------------------------------------------------+
2384 Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS |
2385 +---------------------------------------------------+
2387 +---------------------------------------------------+
2388 Authority | <empty> |
2389 +---------------------------------------------------+
2390 Additional | <empty> |
2391 +---------------------------------------------------+
2393The only difference between the response and the query is the AA and
2394RESPONSE bits in the header. The interpretation of this response is
2395that the server is authoritative for the name, and the name exists, but
2396no RRs of type NS are present there.
23986.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
2400If a user mistyped a host name, we might see this type of query.
2404Mockapetris [Page 43]
2406RFC 1034 Domain Concepts and Facilities November 1987
2409C.ISI.EDU would answer it with:
2411 +---------------------------------------------------+
2412 Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE |
2413 +---------------------------------------------------+
2414 Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A |
2415 +---------------------------------------------------+
2417 +---------------------------------------------------+
2418 Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. |
2419 | 870611 1800 300 604800 86400 |
2420 +---------------------------------------------------+
2421 Additional | <empty> |
2422 +---------------------------------------------------+
2424This response states that the name does not exist. This condition is
2425signalled in the response code (RCODE) section of the header.
2427The SOA RR in the authority section is the optional negative caching
2428information which allows the resolver using this response to assume that
2429the name will not exist for the SOA MINIMUM (86400) seconds.
24316.2.6. QNAME=BRL.MIL, QTYPE=A
2433If this query is sent to C.ISI.EDU, the reply would be:
2435 +---------------------------------------------------+
2436 Header | OPCODE=SQUERY, RESPONSE |
2437 +---------------------------------------------------+
2438 Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A |
2439 +---------------------------------------------------+
2441 +---------------------------------------------------+
2442 Authority | MIL. 86400 IN NS SRI-NIC.ARPA. |
2443 | 86400 NS A.ISI.EDU. |
2444 +---------------------------------------------------+
2445 Additional | A.ISI.EDU. A 26.3.0.103 |
2446 | SRI-NIC.ARPA. A 26.0.0.73 |
2448 +---------------------------------------------------+
2450This response has an empty answer section, but is not authoritative, so
2451it is a referral. The name server on C.ISI.EDU, realizing that it is
2452not authoritative for the MIL domain, has referred the requester to
2453servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
2460Mockapetris [Page 44]
2462RFC 1034 Domain Concepts and Facilities November 1987
24656.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
2467The response to this query from A.ISI.EDU would be:
2469 +---------------------------------------------------+
2470 Header | OPCODE=SQUERY, RESPONSE, AA |
2471 +---------------------------------------------------+
2472 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2473 +---------------------------------------------------+
2474 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2475 | C.ISI.EDU. 86400 IN A 10.0.0.52 |
2476 +---------------------------------------------------+
2477 Authority | <empty> |
2478 +---------------------------------------------------+
2479 Additional | <empty> |
2480 +---------------------------------------------------+
2482Note that the AA bit in the header guarantees that the data matching
2483QNAME is authoritative, but does not say anything about whether the data
2484for C.ISI.EDU is authoritative. This complete reply is possible because
2485A.ISI.EDU happens to be authoritative for both the ARPA domain where
2486USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
2489If the same query was sent to C.ISI.EDU, its response might be the same
2490as shown above if it had its own address in its cache, but might also
2516Mockapetris [Page 45]
2518RFC 1034 Domain Concepts and Facilities November 1987
2521 +---------------------------------------------------+
2522 Header | OPCODE=SQUERY, RESPONSE, AA |
2523 +---------------------------------------------------+
2524 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2525 +---------------------------------------------------+
2526 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2527 +---------------------------------------------------+
2528 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2530 | NS VENERA.ISI.EDU. |
2531 +---------------------------------------------------+
2532 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2533 | 172800 A 128.9.0.33 |
2534 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2535 | 172800 A 128.9.0.32 |
2536 | A.ISI.EDU. 172800 A 26.3.0.103 |
2537 +---------------------------------------------------+
2539This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
2540plus a referral to the name servers for ISI.EDU. This sort of reply
2541isn't very likely given that the query is for the host name of the name
2542server being asked, but would be common for other aliases.
25446.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
2546If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
2549 +---------------------------------------------------+
2550 Header | OPCODE=SQUERY, RESPONSE, AA |
2551 +---------------------------------------------------+
2552 Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A |
2553 +---------------------------------------------------+
2554 Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. |
2555 +---------------------------------------------------+
2556 Authority | <empty> |
2557 +---------------------------------------------------+
2558 Additional | <empty> |
2559 +---------------------------------------------------+
2561Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
2562server doesn't attempt to look up anything for C.ISI.EDU. (Except
2563possibly for the additional section.)
25656.3. Example resolution
2567The following examples illustrate the operations a resolver must perform
2568for its client. We assume that the resolver is starting without a
2572Mockapetris [Page 46]
2574RFC 1034 Domain Concepts and Facilities November 1987
2577cache, as might be the case after system boot. We further assume that
2578the system is not one of the hosts in the data and that the host is
2579located somewhere on net 26, and that its safety belt (SBELT) data
2580structure has the following information:
2583 SRI-NIC.ARPA. 26.0.0.73 10.0.0.51
2584 A.ISI.EDU. 26.3.0.103
2586This information specifies servers to try, their addresses, and a match
2587count of -1, which says that the servers aren't very close to the
2588target. Note that the -1 isn't supposed to be an accurate closeness
2589measure, just a value so that later stages of the algorithm will work.
2591The following examples illustrate the use of a cache, so each example
2592assumes that previous requests have completed.
25946.3.1. Resolve MX for ISI.EDU.
2596Suppose the first request to the resolver comes from the local mailer,
2597which has mail for PVM@ISI.EDU. The mailer might then ask for type MX
2598RRs for the domain name ISI.EDU.
2600The resolver would look in its cache for MX RRs at ISI.EDU, but the
2601empty cache wouldn't be helpful. The resolver would recognize that it
2602needed to query foreign servers and try to determine the best servers to
2603query. This search would look for NS RRs for the domains ISI.EDU, EDU,
2604and the root. These searches of the cache would also fail. As a last
2605resort, the resolver would use the information from the SBELT, copying
2606it into its SLIST structure.
2608At this point the resolver would need to pick one of the three available
2609addresses to try. Given that the resolver is on net 26, it should
2610choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would
2611then send off a query of the form:
2628Mockapetris [Page 47]
2630RFC 1034 Domain Concepts and Facilities November 1987
2633 +---------------------------------------------------+
2634 Header | OPCODE=SQUERY |
2635 +---------------------------------------------------+
2636 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2637 +---------------------------------------------------+
2639 +---------------------------------------------------+
2640 Authority | <empty> |
2641 +---------------------------------------------------+
2642 Additional | <empty> |
2643 +---------------------------------------------------+
2645The resolver would then wait for a response to its query or a timeout.
2646If the timeout occurs, it would try different servers, then different
2647addresses of the same servers, lastly retrying addresses already tried.
2648It might eventually receive a reply from SRI-NIC.ARPA:
2650 +---------------------------------------------------+
2651 Header | OPCODE=SQUERY, RESPONSE |
2652 +---------------------------------------------------+
2653 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2654 +---------------------------------------------------+
2656 +---------------------------------------------------+
2657 Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. |
2659 | NS VENERA.ISI.EDU.|
2660 +---------------------------------------------------+
2661 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2662 | 172800 A 128.9.0.33 |
2663 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2664 | 172800 A 128.9.0.32 |
2665 | A.ISI.EDU. 172800 A 26.3.0.103 |
2666 +---------------------------------------------------+
2668The resolver would notice that the information in the response gave a
2669closer delegation to ISI.EDU than its existing SLIST (since it matches
2670three labels). The resolver would then cache the information in this
2671response and use it to set up a new SLIST:
2674 A.ISI.EDU. 26.3.0.103
2675 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2676 VENERA.ISI.EDU. 10.1.0.52 128.9.0.32
2678A.ISI.EDU appears on this list as well as the previous one, but that is
2679purely coincidental. The resolver would again start transmitting and
2680waiting for responses. Eventually it would get an answer:
2684Mockapetris [Page 48]
2686RFC 1034 Domain Concepts and Facilities November 1987
2689 +---------------------------------------------------+
2690 Header | OPCODE=SQUERY, RESPONSE, AA |
2691 +---------------------------------------------------+
2692 Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX |
2693 +---------------------------------------------------+
2694 Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. |
2695 | MX 20 VAXA.ISI.EDU. |
2696 +---------------------------------------------------+
2697 Authority | <empty> |
2698 +---------------------------------------------------+
2699 Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 |
2700 | 172800 A 128.9.0.33 |
2701 | VENERA.ISI.EDU. 172800 A 10.1.0.52 |
2702 | 172800 A 128.9.0.32 |
2703 +---------------------------------------------------+
2705The resolver would add this information to its cache, and return the MX
27086.3.2. Get the host name for address 26.6.0.65
2710The resolver would translate this into a request for PTR RRs for
271165.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the
2712resolver would look for foreign servers to ask. No servers would match,
2713so it would use SBELT again. (Note that the servers for the ISI.EDU
2714domain are in the cache, but ISI.EDU is not an ancestor of
271565.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
2717Since this request is within the authoritative data of both servers in
2718SBELT, eventually one would return:
2740Mockapetris [Page 49]
2742RFC 1034 Domain Concepts and Facilities November 1987
2745 +---------------------------------------------------+
2746 Header | OPCODE=SQUERY, RESPONSE, AA |
2747 +---------------------------------------------------+
2748 Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
2749 +---------------------------------------------------+
2750 Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. |
2751 +---------------------------------------------------+
2752 Authority | <empty> |
2753 +---------------------------------------------------+
2754 Additional | <empty> |
2755 +---------------------------------------------------+
27576.3.3. Get the host address of poneria.ISI.EDU
2759This request would translate into a type A request for poneria.ISI.EDU.
2760The resolver would not find any cached data for this name, but would
2761find the NS RRs in the cache for ISI.EDU when it looks for foreign
2762servers to ask. Using this data, it would construct a SLIST of the
2767 A.ISI.EDU. 26.3.0.103
2768 VAXA.ISI.EDU. 10.2.0.27 128.9.0.33
2769 VENERA.ISI.EDU. 10.1.0.52
2771A.ISI.EDU is listed first on the assumption that the resolver orders its
2772choices by preference, and A.ISI.EDU is on the same network.
2774One of these servers would answer the query.
27767. REFERENCES and BIBLIOGRAPHY
2778[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena
2779 Technical Plan - Name Service, April 1987, version 1.9.
2781 Describes the fundamentals of the Hesiod name service.
2783[IEN-116] J. Postel, "Internet Name Server", IEN-116,
2784 USC/Information Sciences Institute, August 1979.
2786 A name service obsoleted by the Domain Name System, but
2796Mockapetris [Page 50]
2798RFC 1034 Domain Concepts and Facilities November 1987
2801[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
2802 Networks",Communications of the ACM, October 1986,
2803 volume 29, number 10.
2805[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2806 Information Center, SRI International, December 1977.
2808[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2809 USC/Information Sciences Institute, August 1980.
2811[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2812 USC/Information Sciences Institute, September 1981.
2814[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2817 Suggests introduction of a hierarchy in place of a flat
2818 name space for the Internet.
2820[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2821 USC/Information Sciences Institute, February 1982.
2823[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
2824 Internet Host Table Specification", RFC-810, Network
2825 Information Center, SRI International, March 1982.
2827 Obsolete. See RFC-952.
2829[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2830 Server", RFC-811, Network Information Center, SRI
2831 International, March 1982.
2833 Obsolete. See RFC-953.
2835[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2836 Network Information Center, SRI International, March
2839[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
2840 Internet User Applications", RFC-819, Network
2841 Information Center, SRI International, August 1982.
2843 Early thoughts on the design of the domain system.
2844 Current implementation is completely different.
2846[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2847 USC/Information Sciences Institute, August 1980.
2852Mockapetris [Page 51]
2854RFC 1034 Domain Concepts and Facilities November 1987
2857[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2858 RFC-830, Network Information Center, SRI International,
2861 Early thoughts on the design of the domain system.
2862 Current implementation is completely different.
2864[RFC-882] P. Mockapetris, "Domain names - Concepts and
2865 Facilities," RFC-882, USC/Information Sciences
2866 Institute, November 1983.
2868 Superceeded by this memo.
2870[RFC-883] P. Mockapetris, "Domain names - Implementation and
2871 Specification," RFC-883, USC/Information Sciences
2872 Institute, November 1983.
2874 Superceeded by this memo.
2876[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2877 RFC-920, USC/Information Sciences Institute
2880 Explains the naming scheme for top level domains.
2882[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2883 Table Specification", RFC-952, SRI, October 1985.
2885 Specifies the format of HOSTS.TXT, the host/address
2886 table replaced by the DNS.
2888[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2889 RFC-953, SRI, October 1985.
2891 This RFC contains the official specification of the
2892 hostname server protocol, which is obsoleted by the DNS.
2893 This TCP based protocol accesses information stored in
2894 the RFC-952 format, and is used to obtain copies of the
2897[RFC-973] P. Mockapetris, "Domain System Changes and
2898 Observations", RFC-973, USC/Information Sciences
2899 Institute, January 1986.
2901 Describes changes to RFC-882 and RFC-883 and reasons for
2908Mockapetris [Page 52]
2910RFC 1034 Domain Concepts and Facilities November 1987
2913[RFC-974] C. Partridge, "Mail routing and the domain system",
2914 RFC-974, CSNET CIC BBN Labs, January 1986.
2916 Describes the transition from HOSTS.TXT based mail
2917 addressing to the more powerful MX system used with the
2920[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
2921 service on a TCP/UDP transport: Concepts and Methods",
2922 RFC-1001, March 1987.
2924 This RFC and RFC-1002 are a preliminary design for
2925 NETBIOS on top of TCP/IP which proposes to base NetBIOS
2926 name service on top of the DNS.
2928[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2929 service on a TCP/UDP transport: Detailed
2930 Specifications", RFC-1002, March 1987.
2932[RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
2933 USC/Information Sciences Institute, May 1987
2935 Contains socket numbers and mnemonics for host names,
2936 operating systems, etc.
2938[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2941 Describes a plan for converting the MILNET to the DNS.
2943[RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for
2944 Administrators", RFC-1032, November 1987.
2946 Describes the registration policies used by the NIC to
2947 administer the top level domains and delegate subzones.
2949[RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide",
2950 RFC-1033, November 1987.
2952 A cookbook for domain administrators.
2954[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2955 Name Server", Computer Networks, vol 6, nr 3, July 1982.
2957 Describes a name service for CSNET which is independent
2958 from the DNS and DNS use in the CSNET.
2964Mockapetris [Page 53]
2966RFC 1034 Domain Concepts and Facilities November 1987
2977 Case of characters 7
2980 Completion queries 18
3012 Recursive service 22
3020Mockapetris [Page 54]
3022RFC 1034 Domain Concepts and Facilities November 1987
3076Mockapetris [Page 55]