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