![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc882.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / etc / named / doc|
Return to rfc882.lpr CVS log | Up to [CSRG BSD Unix] / 43BSD / etc / named / doc |
1.1 root 1:
2: Network Working Group P. Mockapetris
3: Request for Comments: 882 ISI
4: November 1983
5:
6: DOMAIN NAMES - CONCEPTS and FACILITIES
7:
8: +-----------------------------------------------------+
9: | |
10: | This RFC introduces domain style names, their use |
11: | for ARPA Internet mail and host address support, |
12: | and the protocols and servers used to implement |
13: | domain name facilities. |
14: | |
15: | This memo describes the conceptual framework of the |
16: | domain system and some uses, but it omits many |
17: | uses, fields, and implementation details. A |
18: | complete specification of formats, timeouts, etc. |
19: | is presented in RFC 883, "Domain Names - |
20: | Implementation and Specification". That RFC |
21: | assumes that the reader is familiar with the |
22: | concepts discussed in this memo. |
23: | |
24: +-----------------------------------------------------+
25:
26: INTRODUCTION
27:
28: The need for domain names
29:
30: As applications grow to span multiple hosts, then networks, and
31: finally internets, these applications must also span multiple
32: administrative boundaries and related methods of operation
33: (protocols, data formats, etc). The number of resources (for
34: example mailboxes), the number of locations for resources, and the
35: diversity of such an environment cause formidable problems when we
36: wish to create consistent methods for referencing particular
37: resources that are similar but scattered throughout the
38: environment.
39:
40: The ARPA Internet illustrates the size-related problems; it is a
41: large system and is likely to grow much larger. The need to have
42: a mapping between host names (e.g., USC-ISIF) and ARPA Internet
43: addresses (e.g., 10.2.0.52) is beginning to stress the existing
44: mechanisms. Currently hosts in the ARPA Internet are registered
45: with the Network Information Center (NIC) and listed in a global
46: table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC
47: host) [1]. The size of this table, and especially the frequency
48: of updates to the table are near the limit of manageability. What
49: is needed is a distributed database that performs the same
50: function, and hence avoids the problems caused by a centralized
51: database.
52:
53: The problem for computer mail is more severe. While mail system
54: implementers long ago recognized the impossibility of centralizing
55:
56:
57: Mockapetris [Page 1]
58:
59:
60: RFC 882 November 1983
61: Domain Names - Concepts and Facilities
62:
63:
64: mailbox names, they have also created an increasingly large and
65: irregular set of methods for identifying the location of a
66: mailbox. Some of these methods involve the use of routes and
67: forwarding hosts as part of the mail destination address, and
68: consequently force the mail user to know multiple address formats,
69: the capabilities of various forwarders, and ad hoc tricks for
70: passing address specifications through intermediaries.
71:
72: These problems have common characteristics that suggest the nature
73: of any solution:
74:
75: The basic need is for a consistent name space which will be
76: used for referring to resources. In order to avoid the
77: problems caused by ad hoc encodings, names should not contain
78: addresses, routes, or similar information as part of the name.
79:
80: The sheer size of the database and frequency of updates suggest
81: that it must be maintained in a distributed manner, with local
82: caching to improve performance. Approaches that attempt to
83: collect a consistent copy of the entire database will become
84: more and more expensive and difficult, and hence should be
85: avoided. The same principle holds for the structure of the
86: name space, and in particular mechanisms for creating and
87: deleting names; these should also be distributed.
88:
89: The costs of implementing such a facility dictate that it be
90: generally useful, and not restricted to a single application.
91: We should be able to use names to retrieve host addresses,
92: mailbox data, and other as yet undetermined information.
93:
94: Because we want the name space to be useful in dissimilar
95: networks, it is unlikely that all users of domain names will be
96: able to agree on the set of resources or resource information
97: that names will be used to retrieve. Hence names refer to a
98: set of resources, and queries contain resource identifiers.
99: The only standard types of information that we expect to see
100: throughout the name space is structuring information for the
101: name space itself, and resources that are described using
102: domain names and no nonstandard data.
103:
104: We also want the name server transactions to be independent of
105: the communications system that carries them. Some systems may
106: wish to use datagrams for simple queries and responses, and
107: only establish virtual circuits for transactions that need the
108: reliability (e.g. database updates, long transactions); other
109: systems will use virtual circuits exclusively.
110:
111:
112:
113:
114:
115: Mockapetris [Page 2]
116:
117:
118: RFC 882 November 1983
119: Domain Names - Concepts and Facilities
120:
121:
122: Elements of the solution
123:
124: The proposed solution has three major components:
125:
126: The DOMAIN NAME SPACE, which is a specification for a tree
127: structured name space. Conceptually, each node and leaf of the
128: domain name space tree names a set of information, and query
129: operations are attempts to extract specific types of
130: information from a particular set. A query names the domain
131: name of interest and describes the type of resource information
132: that is desired. For example, the ARPA Internet uses some of
133: its domain names to identify hosts; queries for address
134: resources return ARPA Internet host addresses. However, to
135: preserve the generality of the domain mechanism, domain names
136: are not required to have a one-to-one correspondence with host
137: names, host addresses, or any other type of information.
138:
139: NAME SERVERS are server programs which hold information about
140: the domain tree's structure and set information. A name server
141: may cache structure or set information about any part of the
142: domain tree, but in general a particular name server has
143: complete information about a subset of the domain space, and
144: pointers to other name servers that can be used to lead to
145: information from any part of the domain tree. Name servers
146: know the parts of the domain tree for which they have complete
147: information; these parts are called ZONEs; a name server is an
148: AUTHORITY for these parts of the name space.
149:
150: RESOLVERS are programs that extract information from name
151: servers in response to user requests. Resolvers must be able
152: to access at least one name server and use that name server's
153: information to answer a query directly, or pursue the query
154: using referrals to other name servers. A resolver will
155: typically be a system routine that is directly accessible to
156: user programs; hence no protocol is necessary between the
157: resolver and the user program.
158:
159: These three components roughly correspond to the three layers or
160: views of the domain system:
161:
162: From the user's point of view, the domain system is accessed
163: through simple procedure or OS calls to resolvers. The domain
164: space consists of a single tree and the user can request
165: information from any section of the tree.
166:
167: From the resolver's point of view, the domain system is
168: composed of an unknown number of name servers. Each name
169: server has one or more pieces of the whole domain tree's data,
170:
171:
172:
173: Mockapetris [Page 3]
174:
175:
176: RFC 882 November 1983
177: Domain Names - Concepts and Facilities
178:
179:
180: but the resolver views each of these databases as essentially
181: static.
182:
183: From a name server's point of view, the domain system consists
184: of separate sets of local information called zones. The name
185: server has local copies of some of the zones. The name server
186: must periodically refresh its zones from master copies in local
187: files or foreign name servers. The name server must
188: concurrently process queries that arrive from resolvers using
189: the local zones.
190:
191: In the interests of performance, these layers blur a bit. For
192: example, resolvers on the same machine as a name server may share
193: a database and may also introduce foreign information for use in
194: later queries. This cached information is treated differently
195: from the authoritative data in zones.
196:
197: Database model
198:
199: The organization of the domain system derives from some
200: assumptions about the needs and usage patterns of its user
201: community and is designed to avoid many of the the complicated
202: problems found in general purpose database systems.
203:
204: The assumptions are:
205:
206: The size of the total database will initially be proportional
207: to the number of hosts using the system, but will eventually
208: grow to be proportional to the number of users on those hosts
209: as mailboxes and other information are added to the domain
210: system.
211:
212: Most of the data in the system will change very slowly (e.g.,
213: mailbox bindings, host addresses), but that the system should
214: be able to deal with subsets that change more rapidly (on the
215: order of minutes).
216:
217: The administrative boundaries used to distribute responsibility
218: for the database will usually correspond to organizations that
219: have one or more hosts. Each organization that has
220: responsibility for a particular set of domains will provide
221: redundant name servers, either on the organization's own hosts
222: or other hosts that the organization arranges to use.
223:
224: Clients of the domain system should be able to identify trusted
225: name servers they prefer to use before accepting referrals to
226: name servers outside of this "trusted" set.
227:
228: Access to information is more critical than instantaneous
229:
230:
231: Mockapetris [Page 4]
232:
233:
234: RFC 882 November 1983
235: Domain Names - Concepts and Facilities
236:
237:
238: updates or guarantees of consistency. Hence the update process
239: allows updates to percolate out though the users of the domain
240: system rather than guaranteeing that all copies are
241: simultaneously updated. When updates are unavailable due to
242: network or host failure, the usual course is to believe old
243: information while continuing efforts to update it. The general
244: model is that copies are distributed with timeouts for
245: refreshing. The distributor sets the timeout value and the
246: recipient of the distribution is responsible for performing the
247: refresh. In special situations, very short intervals can be
248: specified, or the owner can prohibit copies.
249:
250: Some users will wish to access the database via datagrams;
251: others will prefer virtual circuits. The domain system is
252: designed so that simple queries and responses can use either
253: style, although refreshing operations need the reliability of
254: virtual circuits. The same overall message format is used for
255: all communication. The domain system does not assume any
256: special properties of the communications system, and hence
257: could be used with any datagram or virtual circuit protocol.
258:
259: In any system that has a distributed database, a particular
260: name server may be presented with a query that can only be
261: answered by some other server. The two general approaches to
262: dealing with this problem are "recursive", in which the first
263: server pursues the query for the client at another server, and
264: "iterative", in which the server refers the client to another
265: server and lets the client pursue the query. Both approaches
266: have advantages and disadvantages, but the iterative approach
267: is preferred for the datagram style of access. The domain
268: system requires implementation of the iterative approach, but
269: allows the recursive approach as an option. The optional
270: recursive style is discussed in [14], and omitted from further
271: discussion in this memo.
272:
273: The domain system assumes that all data originates in master files
274: scattered through the hosts that use the domain system. These
275: master files are updated by local system administrators. Master
276: files are text files that are read by a local name server, and
277: hence become available to users of the domain system. A standard
278: format for these files is given in [14].
279:
280: The standard format allows these files to be exchanged between
281: hosts (via FTP, mail, or some other mechanism); this facility is
282: useful when an organization wants a domain, but doesn't want to
283: support a name server. The organization can maintain the master
284: files locally using a text editor, transfer them to a foreign host
285: which runs a name server, and then arrange with the system
286: administrator of the name server to get the files loaded.
287:
288:
289: Mockapetris [Page 5]
290:
291:
292: RFC 882 November 1983
293: Domain Names - Concepts and Facilities
294:
295:
296: Each host's name servers and resolvers are configured by a local
297: system administrator. For a name server, this configuration data
298: includes the identity of local master files and instructions on
299: which non-local master files are to be loaded from foreign
300: servers. The name server uses the master files or copies to load
301: its zones. For resolvers, the configuration data identifies the
302: name servers which should be the primary sources of information.
303:
304: The domain system defines procedures for accessing the data and
305: for referrals to other name servers. The domain system also
306: defines procedures for caching retrieved data and for periodic
307: refreshing of data defined by the system administrator.
308:
309: The system administrators provide:
310:
311: The definition of zone boundaries
312:
313: Master files of data
314:
315: Updates to master files
316:
317: Statements of the refresh policies desired
318:
319: The domain system provides:
320:
321: Standard formats for resource data
322:
323: Standard methods for querying the database
324:
325: Standard methods for name servers to refresh local data from
326: foreign name servers
327:
328: DOMAIN NAME SPACE
329:
330: Name space specifications and terminology
331:
332: The domain name space is a tree structure. Each node and leaf on
333: the tree corresponds to a resource set (which may be empty). Each
334: node and leaf has an associated label. Labels are NOT guaranteed
335: to be unique, with the exception of the root node, which has a
336: null label. The domain name of a node or leaf is the path from
337: the root of the tree to the node or leaf. By convention, the
338: labels that compose a domain name are read left to right, from the
339: most specific (lowest) to the least specific (highest).
340:
341: Internally, programs that manipulate domain names represent them
342: as sequences of labels, where each label is a length octet
343: followed by an octet string. Because all domain names end at the
344: root, which has a null string for a label, these internal
345:
346:
347: Mockapetris [Page 6]
348:
349:
350: RFC 882 November 1983
351: Domain Names - Concepts and Facilities
352:
353:
354: representations can use a length byte of zero to terminate a
355: domain name. When domain names are printed, labels in a path are
356: separated by dots ("."). The root label and its associated dot
357: are omitted from printed domain names, but the root can be named
358: by a null domain name (" " in this memo).
359:
360: To simplify implementations, the total number of octets that
361: represent label octets and label lengths is limited to 255. Thus
362: a printed domain name can be up to 254 characters.
363:
364: A special label is defined that matches any other label. This
365: label is the asterisk or "*". An asterisk matches a single label.
366: Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA.
367: The asterisk is mainly used to create default resource records at
368: the boundary between protocol families, and requires prudence in
369: its use.
370:
371: A domain is identified by a domain name, and consists of that part
372: of the domain name space that is at or below the domain name which
373: specifies the domain. A domain is a subdomain of another domain
374: if it is contained within that domain. This relationship can be
375: tested by seeing if the subdomain's name has the containing
376: domain's name as the right part of its name. For example, A.B.C.D
377: is a subdomain of B.C.D, C.D, D, and " ".
378:
379: This tree structure is intended to parallel the administrative
380: organization and delegation of authority. Potentially, each node
381: or leaf on the tree can create new subdomains ad infinitum. In
382: practice, this delegation can be limited by the administrator of
383: the name servers that manage the domain space and resource data.
384:
385: The following figure shows an example of a domain name space.
386:
387: |
388: +------------------+------------------+
389: | | |
390: COLORS FLAVORS TRUTH
391: | |
392: +-----+-----+ |
393: | | | NATURAL
394: RED BLUE GREEN |
395: |
396: +---------------+---------------+
397: | | |
398: CHOCOLATE VANILLA STRAWBERRY
399:
400: In this example, the root domain has three immediate subdomains:
401: COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate
402: subdomain named NATURAL.FLAVORS. All of the leaves are also
403:
404:
405: Mockapetris [Page 7]
406:
407:
408: RFC 882 November 1983
409: Domain Names - Concepts and Facilities
410:
411:
412: domains. This domain tree has the names " "(the root), COLORS,
413: RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS,
414: CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS,
415: STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new
416: domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the
417: administrative entity that would decide; if we wished to create
418: CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS
419: would typically be the appropriate administrative entity.
420:
421: Resource set information
422:
423: A domain name identifies a set of resource information. The set
424: of resource information associated with a particular name is
425: composed of separate resource records (RRs).
426:
427: Each resource record has the following major components:
428:
429: The domain name which identifies resource set that holds this
430: record, and hence the "owner" of the information. For example,
431: a RR that specifies a host address has a domain name the
432: specifies the host having that address. Thus F.ISI.ARPA might
433: be the owner of a RR which specified an address field of
434: 10.2.0.52. Since name servers typically store their resource
435: information in tree structures paralleling the organization of
436: the domain space, this information can usually be stored
437: implicitly in the database; however it is always included in
438: each resource record carried in a message.
439:
440: Other information used to manage the RR, such as length fields,
441: timeouts, etc. This information is omitted in much of this
442: memo, but is discussed in [14].
443:
444: A resource type field that specifies the type of the resource
445: in this resource record. Types refer to abstract resources
446: such as host addresses or mail delivery agents. The type field
447: is two octets long and uses an encoding that is standard
448: throughout the domain name system.
449:
450: A class field identifies the format of the resource data, such
451: as the ARPA Internet format (IN) or the Computer Science
452: Network format (CSNET), for certain RR types (such as address
453: data). Note that while the class may separate different
454: protocol families, networks, etc. it does not do so in all
455: cases. For example, the IN class uses 32 bit IP addresses
456: exclusively, but the CSNET class uses 32 bit IP addresses, X.25
457: addresses, and phone numbers. Thus the class field should be
458: used as a guide for interpreting the resource data. The class
459: field is two octets long and uses an encoding that is standard
460: throughout the domain name system.
461:
462:
463: Mockapetris [Page 8]
464:
465:
466: RFC 882 November 1983
467: Domain Names - Concepts and Facilities
468:
469:
470: Resource data that describes the resource. The format of this
471: data can be determined given the type and class fields, but
472: always starts with a two octet length field that allows a name
473: server or resolver to determine the boundaries of the resource
474: data in any transaction, even if it cannot "understand" the
475: resource data itself. Thus name servers and resolvers can hold
476: and pass on records which they cannot interpret. The format of
477: the internal data is restricted only by the maximum length of
478: 65535 octets; for example the host address record might specify
479: a fixed 32 bit number for one class, and a variable length list
480: of addresses in another class.
481:
482: While the class field in effect partitions the resource data in
483: the domain name system into separate parallel sections according
484: to class, services can span class boundaries if they use
485: compatible resource data formats. For example, the domain name
486: system uses compatible formats for structure information, and the
487: mail data decouples mail agent identification from details of how
488: to contact the agent (e.g. host addresses).
489:
490: This memo uses the following types in its examples:
491:
492: A - the host address associated with the domain name
493:
494: MF - identifies a mail forwarder for the domain
495:
496: MD - identifies a mail destination for the domain
497:
498: NS - the authoritative name server for the domain
499:
500: SOA - identifies the start of a zone of authority
501:
502: CNAME - identifies the canonical name of an alias
503:
504: This memo uses the following classes in its examples:
505:
506: IN - the ARPA Internet system
507:
508: CS - the CSNET system
509:
510: The first type of resource record holds a host name to host
511: address binding. Its fields are:
512:
513: +--------+--------+--------+--------------//----------------------+
514: |<owner> | A | <class>| <class specific address>information |
515: +--------+--------+--------+--------------//----------------------+
516:
517:
518:
519:
520:
521: Mockapetris [Page 9]
522:
523:
524: RFC 882 November 1983
525: Domain Names - Concepts and Facilities
526:
527:
528: The content of the class specific information varies according to
529: the value in the CLASS field; for the ARPA Internet, it is the 32
530: bit ARPA Internet address of the host, for the CSNET it might be
531: the phone number of the host. For example, F.ISI.ARPA might have
532: two A records of the form:
533:
534: +----------+--------+--------+----------------------------+
535: |F.ISI.ARPA| A | IN | 10.2.0.52 |
536: +----------+--------+--------+----------------------------+
537: and
538: +----------+--------+--------+----------------------------+
539: |F.ISI.ARPA| A | CS | 213-822-2112 |
540: +----------+--------+--------+----------------------------+
541:
542: Note that the data formats for the A type are class dependent, and
543: the Internet address and phone number formats shown above are for
544: purposes of illustration only. The actual data formats are
545: specified in [14]. For example, CS class data for type A records
546: might actually be a list of Internet addresses, phone numbers and
547: TELENET addresses.
548:
549: The mail forwarder (MF) and mail delivery (MD) records have the
550: following format:
551:
552: +--------+--------+--------+----------------------------+
553: |<owner> | MD/MF | <class>| <domain name> |
554: +--------+--------+--------+----------------------------+
555:
556: The <domain name> field is a domain name of the host that will
557: handle mail; note that this domain name may be completely
558: different from the domain name which names the resource record.
559: For example, F.ISI.ARPA might have two records of the form:
560:
561: +----------+--------+--------+----------------------------+
562: |F.ISI.ARPA| MD | IN | F.ISI.ARPA |
563: +----------+--------+--------+----------------------------+
564: and
565: +----------+--------+--------+----------------------------+
566: |F.ISI.ARPA| MF | IN | B.ISI.ARPA |
567: +----------+--------+--------+----------------------------+
568:
569: These records mean that mail for F.ISI.ARPA can either be
570: delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
571: will accept responsibility for its eventual delivery. In
572: principle, an additional name lookup is required to map the domain
573: name of the host to the appropriate address, in practice this
574: information is usually returned in the response to the mail query.
575:
576: The SOA and NS types of resource records are used to define limits
577:
578:
579: Mockapetris [Page 10]
580:
581:
582: RFC 882 November 1983
583: Domain Names - Concepts and Facilities
584:
585:
586: of authority. The domain name given by the owner field of a SOA
587: record is the start of a zone; the domain name given by the owner
588: field of a NS record identifies a point in the name space where
589: authority has been delegated, and hence marks the zone boundary.
590: Except in the case where a name server delegates authority to
591: itself, the SOA identifies the top limit of authority, and NS
592: records define the first name outside of a zone. These resource
593: records have a standard format for all of the name space:
594:
595: +----------+--------+--------+-----------------------------+
596: | <owner> | SOA | <class>| <domain name, etc> |
597: +----------+--------+--------+-----------------------------+
598:
599: +----------+--------+--------+-----------------------------+
600: | <owner> | NS | <class>| <domain name> |
601: +----------+--------+--------+-----------------------------+
602:
603: The SOA record marks the start of a zone when it is present in a
604: database; the NS record both marks the end of a zone started by an
605: SOA (if a higher SOA is present) and also points to a name server
606: that has a copy of the zone specified by the <owner. field of the
607: NS record.
608:
609: The <domain name, etc> in the SOA record specifies the original
610: source of the information in the zone and other information used
611: by name servers to organize their activities. SOA records are
612: never cached (otherwise they would create false zones); they can
613: only be created in special name server maintenance operations.
614:
615: The NS record says that a name server which is authoritative for
616: records of the given CLASS can be found at <domain name>.
617:
618: Queries
619:
620: Queries to a name server must include a domain name which
621: identifies the target resource set (QNAME), and the type and class
622: of desired resource records. The type and class fields in a query
623: can include any of the corresponding type and class fields that
624: are defined for resource records; in addition, the query type
625: (QTYPE) and query class (QCLASS) fields may contain special values
626: that match more than one of the corresponding fields in RRs.
627:
628: For example, the QTYPE field may contain:
629:
630: MAILA - matches all mail agent RRs (e.g. MD and MF).
631:
632: * - matches any RR type.
633:
634:
635:
636:
637: Mockapetris [Page 11]
638:
639:
640: RFC 882 November 1983
641: Domain Names - Concepts and Facilities
642:
643:
644: The QCLASS field may contain:
645:
646: * - matches any RR class.
647:
648: Using the query domain name, QTYPE, and QCLASS, the name server
649: looks for matching RRs. In addition to relevant records, the name
650: server may return RRs that point toward a name server that has the
651: desired information or RRs that are expected to be useful in
652: interpreting the relevant RRs. For example a name server that
653: doesn't have the requested information may know a name server that
654: does; a name server that returns a domain name in a relevant RR
655: may also return the RR that binds that domain name to an address.
656:
657: Note that the QCLASS=* construct requires special interpretation
658: regarding authority. Since a name server may not know all of the
659: classes available in the domain system, it can never know if it is
660: authoritative for all classes. Hence responses to QCLASS=*
661: queries can never be authoritative.
662:
663: Example space
664:
665: For purposes of exposition, the following name space is used for
666: the remainder of this memo:
667:
668: |
669: +------------------+------------------+
670: | | |
671: DDN ARPA CSNET
672: | | |
673: +-----+-----+ | +-----+-----+
674: | | | | | |
675: JCS ARMY NAVY | UDEL UCI
676: |
677: +--------+---------------+---------------+--------+
678: | | | | |
679: DTI MIT ISI UDEL NBS
680: | |
681: +---+---+ +---+---+
682: | | | | |
683: DMS AI A B F
684:
685:
686:
687:
688:
689:
690:
691:
692:
693:
694:
695: Mockapetris [Page 12]
696:
697:
698: RFC 882 November 1983
699: Domain Names - Concepts and Facilities
700:
701:
702: NAME SERVERS
703:
704: Introduction
705:
706: Name servers store a distributed database consisting of the
707: structure of the domain name space, the resource sets associated
708: with domain names, and other information used to coordinate
709: actions between name servers.
710:
711: In general, a name server will be an authority for all or part of
712: a particular domain. The region covered by this authority is
713: called a zone. Name servers may be responsible for no
714: authoritative data, and hence have no zones, or may have several
715: zones. When a name server has multiple zones, the zones may have
716: no common borders or zones may be contiguous.
717:
718: While administrators should not construct overlapping zones, and
719: name servers must defend against overlapping zones, overlapping is
720: regarded as a non-fatal flaw in the database. Hence the measures
721: taken to protect against it are omitted for the remainder of this
722: memo. A detailed discussion can be found in [14].
723:
724: When presented with a query for a domain name over which it has
725: authority, a name server returns the desired resource information
726: or an indication that the query refers to a domain name or
727: resource that does not exist. If a name server is presented with
728: a query for a domain name that is not within its authority, it may
729: have the desired information, but it will also return a response
730: that points toward an authoritative name server. If a name server
731: is not an authority for a query, it can never return a negative
732: response.
733:
734: There is no requirement that a name server for a domain reside in
735: a host which has a name in the same domain, although this will
736: usually be the case. There is also no restriction on the number
737: of name servers that can have authority over a particular domain;
738: most domains will have redundant authoritative name servers. The
739: assumption is that different authoritative copies are identical,
740: even though inconsistencies are possible as updates are made.
741:
742: Name server functions are designed to allow for very simple
743: implementations of name servers. The simplest name server has a
744: static set of information and uses datagrams to receive queries
745: and return responses.
746:
747: More sophisticated name server implementations can improve the
748: performance of their clients by caching information from other
749: domains. Although this information can be acquired in a number of
750: ways, the normal method is to store the information acquired by a
751:
752:
753: Mockapetris [Page 13]
754:
755:
756: RFC 882 November 1983
757: Domain Names - Concepts and Facilities
758:
759:
760: resolver when the resolver consults other name servers. In a
761: sophisticated host, the resolver and name server will coordinate
762: their actions and use a shared database. This cooperation
763: requires the incorporation of a time-to-live (TTL) field in all
764: cached resource records. Caching is discussed in the resolver
765: section of this memo; this section is devoted to the actions of a
766: name servers that don't cache.
767:
768: In order to free simple name servers of the requirement of
769: managing these timeouts, simple name servers should only contain
770: resource records that are expected to remain constant over very
771: long periods or resource records for which the name server is an
772: authority. In the following discussion, the TTL field is assumed
773: to be stored in the resource record but is omitted in descriptions
774: of databases and responses in the interest of clarity.
775:
776: Authority and administrative control of domains
777:
778: Although we want to have the potential of delegating the
779: privileges of name space management at every node, we don't want
780: such delegation to be required.
781:
782: Hence we introduce the concept of authority. Authority is vested
783: in name servers. A name server has authority over all of its
784: domain until it delegates authority for a subdomain to some other
785: name server.
786:
787: Any administrative entity that wishes to establish its own domain
788: must provide a name server, and have that server accepted by the
789: parent name server (i.e. the name server that has authority over
790: the place in the domain name space that will hold the new domain).
791: While the principles of authority allow acceptance to be at the
792: discretion of parent name servers, the following criteria are used
793: by the root, and are recommended to all name servers because they
794: are responsible for their children's actions:
795:
796: 1. It must register with the parent administrator of domains.
797:
798: 2. It must identify a responsible person.
799:
800: 3. In must provide redundant name servers.
801:
802: The domain name must be registered with the administrator to avoid
803: name conflicts and to make the domain related information
804: available to other domains. The central administrator may have
805: further requirements, and a domain is not registered until the
806: central administrator agrees that all requirements are met.
807:
808: There must be a responsible person associated with each domain to
809:
810:
811: Mockapetris [Page 14]
812:
813:
814: RFC 882 November 1983
815: Domain Names - Concepts and Facilities
816:
817:
818: be a contact point for questions about the domain, to verify and
819: update the domain related information, and to resolve any problems
820: (e.g., protocol violations) with hosts in the domain.
821:
822: The domain must provide redundant (i.e., two or more) name servers
823: to provide the name to address resolution service. These name
824: servers must be accessible from outside the domain (as well as
825: inside) and must resolve names for at least all the hosts in the
826: domain.
827:
828: Once the central administrator is satisfied, he will communicate
829: the existence to the appropriate administrators of other domains
830: so that they can incorporate NS records for the new name server
831: into their databases.
832:
833: Name server logic
834:
835: The processing steps that a name server performs in responding to
836: a query are conceptually simple, although implementations may have
837: internal databases that are quite complex.
838:
839: For purposes of explanation, we assume that the query consists of
840: a type QTYPE, a class QCLASS, and a domain name QNAME; we assume
841: that the name server stores its RRs in sets where each set has all
842: of the RRs for a particular domain. Note that this database
843: structure and the following algorithms are meant to illustrate one
844: possible implementation, rather than a specification of how all
845: servers must be implemented.
846:
847: The following notation is used:
848:
849: ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME.
850:
851: findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
852: for DOMAIN-NAME, or NULL if there is no such
853: information.
854:
855: set(POINTER) refers to a set located previously by
856: findset, where POINTER is the value returned
857: by findset.
858:
859: relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
860: relevant to the specified QTYPE. For
861: example, relevant(MAILA,MF) is true and
862: relevant(MAILA,NS) is false.
863:
864: right(NAME,NUMBER) returns a domain name that is the rightmost
865: NUMBER labels in the string NAME.
866:
867:
868:
869: Mockapetris [Page 15]
870:
871:
872: RFC 882 November 1983
873: Domain Names - Concepts and Facilities
874:
875:
876: copy(RR) copies the resource record specified by RR
877: into the response.
878:
879: The name server code could be represented as the following
880: sequence of steps:
881:
882: { find out whether the database makes this server
883: authoritative for the domain name specified by QNAME }
884:
885: for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
886: do begin
887: ptr:=findset(right(QNAME,i));
888: if ptr<>NULL
889: then { there is domain data for this domain name }
890: begin
891: for all RRs in set(ptr)
892: do if type(RR)=NS and class(RR)=QCLASS
893: then begin
894: auth=false;
895: NSptr:=ptr
896: end;
897: for all RRs in set(ptr)
898: do if type(RR)=SOA and class(RR)=QCLASS
899: then auth:=true
900: end
901: end;
902: end;
903:
904: { copy out authority search results }
905:
906: if auth
907: then { if authority check for domain found }
908: if ptr=null
909: then return(Name error)
910: else
911: else { if not authority, copy NS RRs }
912: for all RRs in set(nsptr)
913: do if (type(RR)=NS and class(RR)=QCLASS)
914: or
915: (QCLASS=*)
916: then copy(RR);
917:
918: { Copy all RRs that answer the question }
919:
920: for all RRs in set(ptr)
921: do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
922: then copy(RR);
923:
924: The first section of the code (delimited by the for loop over all
925:
926:
927: Mockapetris [Page 16]
928:
929:
930: RFC 882 November 1983
931: Domain Names - Concepts and Facilities
932:
933:
934: of the subnodes of QNAME) discovers whether the name server is
935: authoritative for the domain specified by QNAME. It sequences
936: through all containing domains of QNAME, starting at the root. If
937: it encounters a SOA it knows that the name server is authoritative
938: unless it finds a lower NS RR which delegates authority. If the
939: name server is authoritative, it sets auth=true; if the name
940: server is not authoritative, it sets NSptr to point to the set
941: which contains the NS RR closest to the domain specified by QNAME.
942:
943: The second section of the code reflects the result of the
944: authority search into the response. If the name server is
945: authoritative, the code checks to see that the domain specified by
946: QNAME exists; if not, a name error is returned. If the name
947: server is not authoritative, the code copies the RRs for a closer
948: name server into the response.
949:
950: The last section of the code copies all relevant RRs into the
951: response.
952:
953: Note that this code is not meant as an actual implementation and
954: is incomplete in several aspects. For example, it doesn't deal
955: with providing additional information, wildcards, QCLASS=*, or
956: with overlapping zones. The first two of these issues are dealt
957: with in the following discussions, the remaining issues are
958: discussed in [14].
959:
960: Additional information
961:
962: When a resolver returns information to a user program, the
963: returned information will often lead to a second query. For
964: example, if a mailer asks a resolver for the appropriate mail
965: agent for a particular domain name, the name server queried by the
966: resolver returns a domain name that identifies the agent. In
967: general, we would expect that the mailer would then request the
968: domain name to address binding for the mail agent, and a new name
969: server query would result.
970:
971: To avoid this duplication of effort, name servers return
972: additional information with a response which satisfies the
973: anticipated query. This information is kept in a separate section
974: of the response. Name servers are required to complete the
975: appropriate additional information if such information is
976: available, but the requestor should not depend on the presence of
977: the information since the name server may not have it. If the
978: resolver caches the additional information, it can respond to the
979: second query without an additional network transaction.
980:
981: The appropriate information is defined in [14], but generally
982:
983:
984:
985: Mockapetris [Page 17]
986:
987:
988: RFC 882 November 1983
989: Domain Names - Concepts and Facilities
990:
991:
992: consists of host to address bindings for domain names in returned
993: RRs.
994:
995: Aliases and canonical names
996:
997: In existing systems, hosts and other resources often have several
998: names that identify the same resource. For example, under current
999: ARPA Internet naming support, USC-ISIF and ISIF both identify the
1000: same host. Similarly, in the case of mailboxes, many
1001: organizations provide many names that actually go to the same
1002: mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all
1003: go to the same mailbox (although the mechanism behind this is
1004: somewhat complicated).
1005:
1006: Most of these systems have a notion that one of the equivalent set
1007: of names is the canonical name and all others are aliases.
1008:
1009: The domain system provides a similar feature using the canonical
1010: name (CNAME) RR. When a name server fails to find a desired RR in
1011: a set associated with some domain name, it checks to see if the
1012: resource set contains a CNAME record with a matching class. If
1013: so, the name server includes the CNAME record in the response, and
1014: continues the query at the domain name specified in the data field
1015: of the CNAME record.
1016:
1017: Suppose a name server was processing a query with QNAME=ISIF.ARPA,
1018: QTYPE=A, and QCLASS=IN, and had the following resource records:
1019:
1020: ISIF.ARPA CNAME IN F.ISI.ARPA
1021: F.ISI.ARPA A IN 10.2.0.52
1022:
1023: Both of these RRs would be returned in the response.
1024:
1025: In the above example, because ISIF.ARPA has no RRs other than the
1026: CNAME RR, the resources associated with ISIF.ARPA will appear to
1027: be exactly those associated with F.ISI.ARPA for the IN CLASS.
1028: Since the CNAME is effective only when the search fails, a CNAME
1029: can also be used to construct defaults. For example, suppose the
1030: name server had the following set of RRs:
1031:
1032: F.ISI.ARPA A IN 10.2.0.52
1033: F.ISI.ARPA MD IN F.ISI.ARPA
1034: XXXX.ARPA CNAME IN F.ISI.ARPA
1035: XXXX.ARPA MF IN A.ISI.ARPA
1036:
1037: Using this database, type A queries for XXXX.ARPA would return the
1038: XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF
1039: queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any
1040: information from F.ISI.ARPA. This structure might be used to send
1041:
1042:
1043: Mockapetris [Page 18]
1044:
1045:
1046: RFC 882 November 1983
1047: Domain Names - Concepts and Facilities
1048:
1049:
1050: mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for
1051: XXXX.ARPA to F.ISI.ARPA.
1052:
1053: Wildcards
1054:
1055: In certain cases, an administrator may wish to associate default
1056: resource information for all or part of a domain. For example,
1057: the CSNET domain administrator may wish to establish IN class mail
1058: forwarding for all hosts in the CSNET domain without IN
1059: capability. In such a case, the domain system provides a special
1060: label "*" that matches any other label. Note that "*" matches
1061: only a single label, and not zero or more than one label. Note
1062: also that the "*" is distinct from the "*" values for QCLASS and
1063: QTYPE.
1064:
1065: The semantics of "*" depend upon whether it appears in a query
1066: domain name (QNAME) or in a RR in a database.
1067:
1068: When an "*" is used in a QNAME, it can only match a "*" in a
1069: resource record.
1070:
1071: When "*" appears in a RR in a database, it can never override
1072: an existing exact match. For example, if a name server
1073: received a query for the domain UDEL.CSNET, and had appropriate
1074: RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would
1075: be used and the *.CSNET RRs would be ignored. If a query to
1076: the same database specified FOO.CSNET, the *.CSNET RR would be
1077: used, but the corresponding labels from the QNAME would replace
1078: the "*". Thus the FOO.CSNET query would match the *.CSNET RR
1079: and return a RR for FOO.CSNET rather than *.CSNET.
1080:
1081: RRs containing "*" labels are copied exactly when zones are
1082: transfered via name server maintenance operations.
1083:
1084: These semantics are easily implemented by having the name server
1085: first search for an exact match for a query, and then replacing
1086: the leftmost label with a "*" and trying again, repeating the
1087: process until all labels became "*" or the search succeeded.
1088:
1089: TYPE=* in RRs is prohibited. If it were to be allowed, the
1090: requestor would have no way of interpreting the data in the RR
1091: because this data is type dependent.
1092:
1093: CLASS=* is also prohibited. Similar effects can be achieved using
1094: QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
1095: complexities without apparent benefit.
1096:
1097:
1098:
1099:
1100:
1101: Mockapetris [Page 19]
1102:
1103:
1104: RFC 882 November 1983
1105: Domain Names - Concepts and Facilities
1106:
1107:
1108: A scenario
1109:
1110: In our sample domain space, suppose we wanted separate
1111: administrative control for the root, DDN, ARPA, CSNET, MIT and ISI
1112: domains. We might allocate name servers as follows:
1113:
1114: |(B.ISI.ARPA)
1115: |(UDEL.CSNET)
1116: +------------------+------------------+
1117: | | |
1118: DDN ARPA CSNET
1119: |(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA)
1120: +-----+-----+ |(A.ISI.ARPA)+-----+-----+
1121: | | | | | |
1122: JCS ARMY NAVY | UDEL UCI
1123: |
1124: +--------+---------------+---------------+--------+
1125: | | | | |
1126: DTI MIT ISI UDEL NBS
1127: |(AI.MIT.ARPA) |(F.ISI.ARPA)
1128: +---+---+ +---+---+
1129: | | | | |
1130: DMS AI A B F
1131:
1132: In this example the authoritative name server is shown in
1133: parentheses at the point in the domain tree at which is assumes
1134: control.
1135:
1136: Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the
1137: DDN name server is on JCS.DDN, the CSNET domain server is on
1138: UDEL.ARPA, etc.
1139:
1140: In an actual system, all domains should have redundant name
1141: servers, but in this example only the ARPA domain has redundant
1142: servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET
1143: name servers happen to be not redundant because they handle
1144: different classes.) The F.ISI.ARPA name server has authority over
1145: the ARPA domain, but delegates authority over the MIT.ARPA domain
1146: to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server
1147: also has authority over the ARPA domain, but delegates both the
1148: ISI.ARPA and MIT.ARPA domains to other name servers.
1149:
1150:
1151:
1152:
1153:
1154:
1155:
1156:
1157:
1158:
1159: Mockapetris [Page 20]
1160:
1161:
1162: RFC 882 November 1983
1163: Domain Names - Concepts and Facilities
1164:
1165:
1166: B.ISI.ARPA Name server for " "
1167:
1168: B.ISI.ARPA has the root name server for the IN class. Its
1169: database might contain:
1170:
1171: Domain Resource Record
1172:
1173: " " SOA IN A.ISI.ARPA
1174: DDN NS IN JCS.DDN
1175: ARPA NS IN F.ISI.ARPA
1176: CSNET NS IN UDEL.ARPA
1177: " " NS IN B.ISI.ARPA
1178: " " NS CS UDEL.CSNET
1179:
1180: JCS.DDN A IN 9.0.0.1
1181: F.ISI.ARPA A IN 10.2.0.52
1182: UDEL.CSNET A CS 302-555-0000
1183: UDEL.ARPA A IN 10.0.0.96
1184:
1185: The SOA record for the root is necessary so that the name server
1186: knows that it is authoritative for the root domain for class IN.
1187: The contents of the SOA resource record point back to A.ISI.ARPA
1188: and denote that the master data for the zone of authority is
1189: originally from this host. The first three NS records denote
1190: delegation of authority. The NS root entry for the B.ISI.ARPA
1191: name server is necessary so that this name server knows about
1192: itself, and can respond correctly to a query for NS information
1193: about the root (for which it is an authority). The root entry for
1194: class CS denotes that UDEL.CSNET is the authoritative name server
1195: for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not
1196: refer to the same name server; from this information it is
1197: impossible to tell.
1198:
1199: If this name server was sent a query specifying QTYPE=MAILA,
1200: QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the
1201: previous algorithm) by determining that it was not an authority
1202: for F.ISI.ARPA. The test would note that it had authority at " ",
1203: but would also note that the authority was delegated at ARPA and
1204: never reestablished via another SOA. Thus the response would
1205: return the NS record for the domain ARPA.
1206:
1207: Any queries presented to this server with QCLASS=CS would result
1208: in the UDEL.CSNET NS record being returned in the response.
1209:
1210:
1211:
1212:
1213:
1214:
1215:
1216:
1217: Mockapetris [Page 21]
1218:
1219:
1220: RFC 882 November 1983
1221: Domain Names - Concepts and Facilities
1222:
1223:
1224: F.ISI.ARPA Name server for ARPA and ISI.ARPA
1225:
1226: In the same domain space, the F.ISI.ARPA database for the domains
1227: ARPA and ISI.ARPA might be:
1228:
1229: Domain Resource Record
1230:
1231: " " NS IN B.ISI.ARPA
1232: " " NS CS CSNET.UDEL
1233: ARPA SOA IN B.ISI.ARPA
1234: ARPA NS IN A.ISI.ARPA
1235: ARPA NS IN F.ISI.ARPA
1236: MIT.ARPA NS IN AI.MIT.ARPA
1237: ISI.ARPA SOA IN F.ISI.ARPA
1238: ISI.ARPA NS IN F.ISI.ARPA
1239:
1240: A.ISI.ARPA MD IN A.ISI.ARPA
1241: ISI.ARPA MD IN F.ISI.ARPA
1242: A.ISI.ARPA MF IN F.ISI.ARPA
1243: B.ISI.ARPA MD IN B.ISI.ARPA
1244: B.ISI.ARPA MF IN F.ISI.ARPA
1245: F.ISI.ARPA MD IN F.ISI.ARPA
1246: F.ISI.ARPA MF IN A.ISI.ARPA
1247: DTI.ARPA MD IN DTI.ARPA
1248: NBS.ARPA MD IN NBS.ARPA
1249: UDEL.ARPA MD IN UDEL.ARPA
1250:
1251: A.ISI.ARPA A IN 10.1.0.32
1252: F.ISI.ARPA A IN 10.2.0.52
1253: B.ISI.ARPA A IN 10.3.0.52
1254: DTI.ARPA A IN 10.0.0.12
1255: AI.MIT.ARPA A IN 10.2.0.6
1256: DMS.MIT.ARPA A IN 10.1.0.6
1257: NBS.ARPA A IN 10.0.0.19
1258: UDEL.ARPA A IN 10.0.0.96
1259:
1260: For the IN class, the SOA RR for ARPA denotes that this name
1261: server is authoritative for the domain ARPA, and that the master
1262: file for this authority is stored on B.ISI.ARPA. This zone
1263: extends to ISI.ARPA, where the database delegates authority back
1264: to this name server in another zone, and doesn't include the
1265: domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA.
1266:
1267: This name server is not authoritative for any data in the CS
1268: class. It has a pointer to the root server for CS data which
1269: could be use to resolve CS class queries.
1270:
1271: Suppose this name server received a query of the form
1272: QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search
1273:
1274:
1275: Mockapetris [Page 22]
1276:
1277:
1278: RFC 882 November 1983
1279: Domain Names - Concepts and Facilities
1280:
1281:
1282: would notice the NS record for " ", its SOA at ARPA, a delegation
1283: at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence
1284: it would know that it was an authority for this query. It would
1285: then find the A record for A.ISI.ARPA, and return a datagram
1286: containing this record.
1287:
1288: Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*.
1289: In this case the name server would know that it cannot be
1290: authoritative because of the "*" value of QCLASS, and would look
1291: for records for domain B.ISI.ARPA that match. Assuming that the
1292: name server performs the additional record inclusion mentioned in
1293: the name server algorithm, the returned datagram would include:
1294:
1295: ISI.ARPA NS IN F.ISI.ARPA
1296: " " NS CS UDEL.CSNET
1297: B.ISI.ARPA MD IN B.ISI.ARPA
1298: B.ISI.ARPA MF IN F.ISI.ARPA
1299: B.ISI.ARPA A IN 10.3.0.52
1300: F.ISI.ARPA A IN 10.2.0.52
1301:
1302: If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the
1303: name server would discover that AI.MIT.ARPA was the authoritative
1304: name server and return the following:
1305:
1306: MIT.ARPA NS IN AI.MIT.ARPA
1307: AI.MIT.ARPA A IN 10.2.0.6
1308:
1309: In this case, the requestor is directed to seek information from
1310: the MIT.ARPA domain name server residing on AI.MIT.ARPA.
1311:
1312:
1313:
1314:
1315:
1316:
1317:
1318:
1319:
1320:
1321:
1322:
1323:
1324:
1325:
1326:
1327:
1328:
1329:
1330:
1331:
1332:
1333: Mockapetris [Page 23]
1334:
1335:
1336: RFC 882 November 1983
1337: Domain Names - Concepts and Facilities
1338:
1339:
1340: UDEL.ARPA and UDEL.CSNET name server
1341:
1342: In the previous discussion of the sample domain, we stated that
1343: UDEL.CSNET and UDEL.ARPA might be the same name server. In this
1344: example, we assume that this is the case. As such, the name
1345: server is an authority for the root for class CS, and an authority
1346: for the CSNET domain for class IN.
1347:
1348: This name server deals with mail forwarding between the ARPA
1349: Internet and CSNET systems. Its RRs illustrate one approach to
1350: solving this problem. The name server has the following resource
1351: records:
1352:
1353: " " SOA CS UDEL.CSNET
1354: " " NS CS UDEL.CSNET
1355: " " NS IN B.ISI.ARPA
1356: CSNET SOA IN UDEL.ARPA
1357: CSNET NS IN UDEL.ARPA
1358: ARPA NS IN A.ISI.ARPA
1359:
1360: *.CSNET MF IN UDEL.ARPA
1361: UDEL.CSNET MD CS UDEL.CSNET
1362: UCI.CSNET MD CS UCI.CSNET
1363: UDEL.ARPA MD IN UDEL.ARPA
1364:
1365: B.ISI.ARPA A IN 10.3.0.52
1366: UDEL.ARPA A IN 10.0.0.96
1367: UDEL.CSNET A CS 302-555-0000
1368: UCI.CSNET A CS 714-555-0000
1369:
1370: Suppose this name server received a query of the form
1371: QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server
1372: would discover it was authoritative for the CSNET domain under
1373: class IN, but would find no explicit mail data for UCI.CSNET.
1374: However, using the *.CSNET record, it would construct a reply:
1375:
1376: UCI.CSNET MF IN UDEL.ARPA
1377: UDEL.ARPA A IN 10.0.0.96
1378:
1379: If this name server received a query of the form QNAME=UCI.CSNET,
1380: QTYPE=MAILA, and QCLASS=CS, the name server would return:
1381:
1382: UCI.CSNET MD CS UCI.CSNET
1383: UCI.CSNET A CS 714-555-0000
1384:
1385: Note that although this scheme allows for forwarding of all mail
1386: addressed as <anything>.CSNET, it doesn't help with names that
1387: have more than two components, e.g. A.B.CSNET. Although this
1388: problem could be "fixed" by a series of MF entries for *.*.CSNET,
1389:
1390:
1391: Mockapetris [Page 24]
1392:
1393:
1394: RFC 882 November 1983
1395: Domain Names - Concepts and Facilities
1396:
1397:
1398: *.*.*.CSNET, etc, a more tasteful solution would be to introduce a
1399: cleverer pattern matching algorithm in the CSNET name server.
1400:
1401: Summary of requirements for name servers
1402:
1403: The requirements for a name server are as follows:
1404:
1405: 1. It must be recognized by its parent.
1406:
1407: 2. It must have complete resource information for all domain
1408: names for which it is the authority.
1409:
1410: 3. It must periodically refresh authoritative information from
1411: a master file or name server which holds the master.
1412:
1413: 4. If it caches information it must also handle TTL management
1414: for that information.
1415:
1416: 5. It must answer simple queries.
1417:
1418: Inverse queries
1419:
1420: Name servers may also support inverse queries that map a
1421: particular resource to a domain name or domain names that have
1422: that resource. For example, while a query might map a domain name
1423: to a host address, the corresponding inverse query might map the
1424: address back to the domain name.
1425:
1426: Implementation of this service is optional in a name server, but
1427: all name servers must at least be able to understand an inverse
1428: query message and return an error response.
1429:
1430: The domain system cannot guarantee the completeness or uniqueness
1431: of inverse queries because the domain system is organized by
1432: domain name rather than by host address or any other resource
1433: type. In general, a resolver or other program that wishes to
1434: guarantee that an inverse query will work must use a name server
1435: that is known to have the appropriate data, or ask all name
1436: servers in a domain of interest.
1437:
1438: For example, if a resolver wishes to perform an inverse query for
1439: an arbitrary host on the ARPA Internet, it must consult a set of
1440: name servers sufficient to know that all IN data was considered.
1441: In practice, a single inverse query to a name server that has a
1442: fairly comprehensive database should satisfy the vast majority of
1443: inverse queries.
1444:
1445: A detailed discussion of inverse queries is contained in [14].
1446:
1447:
1448:
1449: Mockapetris [Page 25]
1450:
1451:
1452: RFC 882 November 1983
1453: Domain Names - Concepts and Facilities
1454:
1455:
1456: Completion services
1457:
1458: Some existing systems provide the ability to complete partial
1459: specifications of arguments. The general principle is that the
1460: user types the first few characters of the argument and then hits
1461: an escape character to prompt the system to complete the rest.
1462: Some completion systems require that the user type enough of the
1463: argument to be unique; others do not.
1464:
1465: Other systems allow the user to specify one argument and ask the
1466: system to fill in other arguments. For example, many mail systems
1467: allow the user to specify a username without a host for local mail
1468: delivery.
1469:
1470: The domain system defines name server completion transactions that
1471: perform the analogous service for the domain system.
1472: Implementation of this service is optional in a name server, but
1473: all name servers must at least be able to understand a completion
1474: request and return an error response.
1475:
1476: When a resolver wishes to request a completion, it sends a name
1477: server a message that sets QNAME to the partial string, QTYPE to
1478: the type of resource desired, and QCLASS to the desired class.
1479: The completion request also includes a RR for the target domain.
1480: The target domain RR identifies the preferred location of the
1481: resource. In completion requests, QNAME must still have a null
1482: label to terminate the name, but its presence is ignored. Note
1483: that a completion request is not a query, but shares some of the
1484: same field formats.
1485:
1486: For example, a completion request might contain QTYPE=A, QNAME=B,
1487: QCLASS=IN and a RR for ISI.ARPA. This request asks for completion
1488: for a resource whose name begins with "B" and is "close" to
1489: ISI.ARPA. This might be a typical shorthand used in the ISI
1490: community which uses "B" as a way of referring to B.ISI.ARPA.
1491:
1492: The first step in processing a completion request is to look for a
1493: "whole label" match. When the name server receives the request
1494: mentioned above, it looks at all records that are of type A, class
1495: IN, and whose domain name starts (on the left) with the labels of
1496: QNAME, in this case, "B". If multiple records match, the name
1497: server selects those whose domain names match (from the right) the
1498: most labels of the preferred domain name. If there are still
1499: multiple candidates, the name server selects the records that have
1500: the shortest (in terms of octets in the name) domain name. If
1501: several records remain, then the name server returns them all.
1502:
1503: If no records are found in the previous algorithm, the name server
1504: assumes that the rightmost label in QNAME is not complete, and
1505:
1506:
1507: Mockapetris [Page 26]
1508:
1509:
1510: RFC 882 November 1983
1511: Domain Names - Concepts and Facilities
1512:
1513:
1514: looks for records that match but require addition of characters to
1515: the rightmost label of QNAME. For example, the previous search
1516: would not match BB.ARPA to B, but this search would. If multiple
1517: hits are found, the same discarding strategy is followed.
1518:
1519: A detailed discussion of completion can be found in [14].
1520:
1521: RESOLVERS
1522:
1523: Introduction
1524:
1525: Resolvers are programs that interface user programs to domain name
1526: servers. In the simplest case, a resolver receives a request from
1527: a user program (e.g. mail programs, TELNET, FTP) in the form of a
1528: subroutine call, system call etc., and returns the desired
1529: information in a form compatible with the local host's data
1530: formats.
1531:
1532: Because a resolver may need to consult several name servers, the
1533: amount of time that a resolver will take to complete can vary.
1534: This variance is part of the justification for the split between
1535: name servers and resolvers; name servers may use datagrams and
1536: have a response time that is essentially equal to network delay
1537: plus a short service time, while resolvers may take an essentially
1538: indeterminate amount of time.
1539:
1540: We expect to see two types of resolvers: simple resolvers that can
1541: chain through multiple name servers when required, and more
1542: complicated resolvers that cache resource records for use in
1543: future queries.
1544:
1545: Simple resolvers
1546:
1547: A simple resolver needs the following capabilities:
1548:
1549: 1. It must know how to access a name server, and should know the
1550: authoritative name server for the host that it services.
1551:
1552: 2. It must know the protocol capabilities for its clients so that
1553: it can set the class fields of the queries it sends to return
1554: information that is useful to its clients. If the resolver
1555: serves a client that has multiple protocol capabilities, it
1556: should be able to support the preferences of the client.
1557:
1558: The resolver for a multiple protocol client can either collect
1559: information for all classes using the * class value, or iterate
1560: on the classes supported by the client. Note that in either
1561: case, the resolver must understand the preferences of the host.
1562: For example, the host that supports both CSNET and ARPA
1563:
1564:
1565: Mockapetris [Page 27]
1566:
1567:
1568: RFC 882 November 1983
1569: Domain Names - Concepts and Facilities
1570:
1571:
1572: Internet protocols might prefer mail delivery (MD) to mail
1573: forwarding (MF), regardless of protocol, or might prefer one
1574: protocol regardless of whether MD or MF is required. Care is
1575: required to prevent loops.
1576:
1577: 3. The resolver must be capable of chaining through multiple name
1578: servers to get to an authoritative name server for any query.
1579: The resolver should guard against loops in referrals; a simple
1580: policy is to discard referrals that don't match more of the
1581: query name than the referring name server, and also to avoid
1582: querying the same name server twice (This test should be done
1583: using addresses of name servers instead of domain names to
1584: avoid problems when a name server has multiple domain names or
1585: errors are present in aliases).
1586:
1587: 4. The resolver must be able to try alternate name servers when a
1588: name server doesn't respond.
1589:
1590: 5. The resolver must be able to communicate different failure
1591: conditions to its client. These failure conditions include
1592: unknown domain name, unknown resource for a know domain name,
1593: and inability to access any of the authoritative name servers
1594: for a domain.
1595:
1596: 6. If the resolver uses datagrams for queries, it must recover
1597: from lost and duplicate datagrams.
1598:
1599: Resolvers with cache management
1600:
1601: Caching provides a tool for improving the performance of name
1602: service, but also is a potential source of incorrect results. For
1603: example, a database might cache information that is later changed
1604: in the authoritative name servers. While this problem can't be
1605: eliminated without eliminating caching, it can be reduced to an
1606: infrequent problem through the use of timeouts.
1607:
1608: When name servers return resource records, each record has an
1609: associated time-to-live (TTL) field. This field is expressed in
1610: seconds, and has 16 bits of significance.
1611:
1612: When a resolver caches a returned resource record it must also
1613: remember the TTL field. The resolver must discard the record when
1614: the equivalent amount of time has passed. If the resolver shares
1615: a database with a name server, it must decrement the TTL field of
1616: imported records periodically rather than simply deleting the
1617: record. This strategy is necessary to avoid exporting a resource
1618: record whose TTL field doesn't reflect the amount of time that the
1619: resource record has been cached. Of course, the resolver should
1620:
1621:
1622:
1623: Mockapetris [Page 28]
1624:
1625:
1626: RFC 882 November 1983
1627: Domain Names - Concepts and Facilities
1628:
1629:
1630: not decrement the TTL fields of records for which the associated
1631: name server is an authority.
1632:
1633:
1634:
1635:
1636:
1637:
1638:
1639:
1640:
1641:
1642:
1643:
1644:
1645:
1646:
1647:
1648:
1649:
1650:
1651:
1652:
1653:
1654:
1655:
1656:
1657:
1658:
1659:
1660:
1661:
1662:
1663:
1664:
1665:
1666:
1667:
1668:
1669:
1670:
1671:
1672:
1673:
1674:
1675:
1676:
1677:
1678:
1679:
1680:
1681: Mockapetris [Page 29]
1682:
1683:
1684: RFC 882 November 1983
1685: Domain Names - Concepts and Facilities
1686:
1687:
1688: Appendix 1 - Domain Name Syntax Specification
1689:
1690: The preferred syntax of domain names is given by the following BNF
1691: rules. Adherence to this syntax will result in fewer problems with
1692: many applications that use domain names (e.g., mail, TELNET). Note
1693: that some applications described in [14] use domain names containing
1694: binary information and hence do not follow this syntax.
1695:
1696: <domain> ::= <subdomain> | " "
1697:
1698: <subdomain> ::= <label> | <subdomain> "." <label>
1699:
1700: <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
1701:
1702: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
1703:
1704: <let-dig-hyp> ::= <let-dig> | "-"
1705:
1706: <let-dig> ::= <letter> | <digit>
1707:
1708: <letter> ::= any one of the 52 alphabetic characters A through Z
1709: in upper case and a through z in lower case
1710:
1711: <digit> ::= any one of the ten digits 0 through 9
1712:
1713: Note that while upper and lower case letters are allowed in domain
1714: names no significance is attached to the case. That is, two names
1715: with the same spelling but different case are to be treated as if
1716: identical.
1717:
1718: The labels must follow the rules for ARPANET host names. They must
1719: start with a letter, end with a letter or digit, and have as interior
1720: characters only letters, digits, and hyphen. There are also some
1721: restrictions on the length. Labels must be 63 characters or less.
1722:
1723: For example, the following strings identify hosts in the ARPA
1724: Internet:
1725:
1726: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
1727:
1728:
1729:
1730:
1731:
1732:
1733:
1734:
1735:
1736:
1737:
1738:
1739: Mockapetris [Page 30]
1740:
1741:
1742: RFC 882 November 1983
1743: Domain Names - Concepts and Facilities
1744:
1745:
1746: REFERENCES and BIBLIOGRAPHY
1747:
1748: [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
1749: Host Table Specification", RFC 810, Network Information Center,
1750: SRI International, March 1982.
1751:
1752: [2] J. Postel, "Computer Mail Meeting Notes", RFC 805,
1753: USC/Information Sciences Institute, February 1982.
1754:
1755: [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet
1756: User Applications", RFC 819, Network Information Center, SRI
1757: International, August 1982.
1758:
1759: [4] Z. Su, "A Distributed System for Internet Name Service",
1760: RFC 830, Network Information Center, SRI International,
1761: October 1982.
1762:
1763: [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
1764: Information Center, SRI International, March 1982.
1765:
1766: [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
1767: Server", Computer Networks, vol 6, nr 3, July 1982.
1768:
1769: [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
1770: Center, SRI International, December 1977.
1771:
1772: [8] J. Postel, "Internet Name Server", IEN 116, USC/Information
1773: Sciences Institute, August 1979.
1774:
1775: [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
1776: RFC 811, Network Information Center, SRI International,
1777: March 1982.
1778:
1779: [10] J. Postel, "Transmission Control Protocol", RFC 793,
1780: USC/Information Sciences Institute, September 1981.
1781:
1782: [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
1783: Sciences Institute, August 1980.
1784:
1785: [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
1786: USC/Information Sciences Institute, August 1980.
1787:
1788: [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
1789: USC/Information Sciences Institute, October 1983.
1790:
1791: [14] P. Mockapetris, "Domain Names - Implementation and
1792: Specification", RFC 883, USC/Information Sciences Institute,
1793: November 1983.
1794:
1795:
1796:
1797: Mockapetris [Page 31]
1798:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.