![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc883.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 rfc883.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: 883 ISI
4: November 1983
5:
6: DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION
7:
8: +-----------------------------------------------------+
9: | |
10: | This memo discusses the implementation of domain |
11: | name servers and resolvers, specifies the format of |
12: | transactions, and discusses the use of domain names |
13: | in the context of existing mail systems and other |
14: | network software. |
15: | |
16: | This memo assumes that the reader is familiar with |
17: | RFC 882, "Domain Names - Concepts and Facilities" |
18: | which discusses the basic principles of domain |
19: | names and their use. |
20: | |
21: | The algorithms and internal data structures used in |
22: | this memo are offered as suggestions rather than |
23: | requirements; implementers are free to design their |
24: | own structures so long as the same external |
25: | behavior is achieved. |
26: | |
27: +-----------------------------------------------------+
28:
29:
30:
31:
32: +-----------------------------------------------+
33: | |
34: | ***** WARNING ***** |
35: | |
36: | This RFC contains format specifications which |
37: | are preliminary and are included for purposes |
38: | of explanation only. Do not attempt to use |
39: | this information for actual implementations. |
40: | |
41: +-----------------------------------------------+
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57: Mockapetris [Page i]
58:
59:
60: RFC 883 November 1983
61: Domain Names - Implementation and Specification
62:
63:
64: TABLE OF CONTENTS
65: INTRODUCTION........................................................3
66: Overview.........................................................3
67: Implementation components........................................2
68: Conventions......................................................6
69: Design philosophy................................................8
70: NAME SERVER TRANSACTIONS...........................................11
71: Introduction....................................................11
72: Query and response transport....................................11
73: Overall message format..........................................13
74: The contents of standard queries and responses..................15
75: Standard query and response example.............................15
76: The contents of inverse queries and responses...................17
77: Inverse query and response example..............................18
78: Completion queries and responses................................19
79: Completion query and response example...........................22
80: Recursive Name Service..........................................24
81: Header section format...........................................26
82: Question section format.........................................29
83: Resource record format..........................................30
84: Domain name representation and compression......................31
85: Organization of the Shared database.............................33
86: Query processing................................................36
87: Inverse query processing........................................37
88: Completion query processing.....................................38
89: NAME SERVER MAINTENANCE............................................39
90: Introduction....................................................39
91: Conceptual model of maintenance operations......................39
92: Name server data structures and top level logic.................41
93: Name server file loading........................................43
94: Name server file loading example................................45
95: Name server remote zone transfer................................47
96: RESOLVER ALGORITHMS................................................50
97: Operations......................................................50
98: DOMAIN SUPPORT FOR MAIL............................................52
99: Introduction....................................................52
100: Agent binding...................................................53
101: Mailbox binding.................................................54
102: Appendix 1 - Domain Name Syntax Specification......................56
103: Appendix 2 - Field formats and encodings...........................57
104: TYPE values.....................................................57
105: QTYPE values....................................................57
106: CLASS values....................................................58
107: QCLASS values...................................................58
108: Standard resource record formats................................59
109: Appendix 3 - Internet specific field formats and operations........67
110: REFERENCES and BIBLIOGRAPHY........................................72
111: INDEX..............................................................73
112:
113:
114:
115: Mockapetris [Page ii]
116:
117:
118: RFC 883 November 1983
119: Domain Names - Implementation and Specification
120:
121:
122: INTRODUCTION
123:
124: Overview
125:
126: The goal of domain names is to provide a mechanism for naming
127: resources in such a way that the names are usable in different
128: hosts, networks, protocol families, internets, and administrative
129: organizations.
130:
131: From the user's point of view, domain names are useful as
132: arguments to a local agent, called a resolver, which retrieves
133: information associated with the domain name. Thus a user might
134: ask for the host address or mail information associated with a
135: particular domain name. To enable the user to request a
136: particular type of information, an appropriate query type is
137: passed to the resolver with the domain name. To the user, the
138: domain tree is a single information space.
139:
140: From the resolver's point of view, the database that makes up the
141: domain space is distributed among various name servers. Different
142: parts of the domain space are stored in different name servers,
143: although a particular data item will usually be stored redundantly
144: in two or more name servers. The resolver starts with knowledge
145: of at least one name server. When the resolver processes a user
146: query it asks a known name server for the information; in return,
147: the resolver either receives the desired information or a referral
148: to another name server. Using these referrals, resolvers learn
149: the identities and contents of other name servers. Resolvers are
150: responsible for dealing with the distribution of the domain space
151: and dealing with the effects of name server failure by consulting
152: redundant databases in other servers.
153:
154: Name servers manage two kinds of data. The first kind of data
155: held in sets called zones; each zone is the complete database for
156: a particular subtree of the domain space. This data is called
157: authoritative. A name server periodically checks to make sure
158: that its zones are up to date, and if not obtains a new copy of
159: updated zones from master files stored locally or in another name
160: server. The second kind of data is cached data which was acquired
161: by a local resolver. This data may be incomplete but improves the
162: performance of the retrieval process when non-local data is
163: repeatedly accessed. Cached data is eventually discarded by a
164: timeout mechanism.
165:
166: This functional structure isolates the problems of user interface,
167: failure recovery, and distribution in the resolvers and isolates
168: the database update and refresh problems in the name servers.
169:
170:
171:
172:
173: Mockapetris [Page 1]
174:
175:
176: RFC 883 November 1983
177: Domain Names - Implementation and Specification
178:
179:
180: Implementation components
181:
182: A host can participate in the domain name system in a number of
183: ways, depending on whether the host runs programs that retrieve
184: information from the domain system, name servers that answer
185: queries from other hosts, or various combinations of both
186: functions. The simplest, and perhaps most typical, configuration
187: is shown below:
188:
189: Local Host | Foreign
190: |
191: +---------+ +----------+ | +--------+
192: | | user queries | |queries | | |
193: | User |-------------->| |---------|->|Foreign |
194: | Program | | Resolver | | | Name |
195: | |<--------------| |<--------|--| Server |
196: | | user responses| |responses| | |
197: +---------+ +----------+ | +--------+
198: | A |
199: cache additions | | references |
200: V | |
201: +----------+ |
202: | database | |
203: +----------+ |
204:
205: User programs interact with the domain name space through
206: resolvers; the format of user queries and user responses is
207: specific to the host and its operating system. User queries will
208: typically be operating system calls, and the resolver and its
209: database will be part of the host operating system. Less capable
210: hosts may choose to implement the resolver as a subroutine to be
211: linked in with every program that needs its services.
212:
213: Resolvers answer user queries with information they acquire via
214: queries to foreign name servers, and may also cache or reference
215: domain information in the local database.
216:
217: Note that the resolver may have to make several queries to several
218: different foreign name servers to answer a particular user query,
219: and hence the resolution of a user query may involve several
220: network accesses and an arbitrary amount of time. The queries to
221: foreign name servers and the corresponding responses have a
222: standard format described in this memo, and may be datagrams.
223:
224:
225:
226:
227:
228:
229:
230:
231: Mockapetris [Page 2]
232:
233:
234: RFC 883 November 1983
235: Domain Names - Implementation and Specification
236:
237:
238: Depending on its capabilities, a name server could be a stand
239: alone program on a dedicated machine or a process or processes on
240: a large timeshared host. A simple configuration might be:
241:
242: Local Host | Foreign
243: |
244: +---------+ |
245: / /| |
246: +---------+ | +----------+ | +--------+
247: | | | | |responses| | |
248: | | | | Name |---------|->|Foreign |
249: | Master |-------------->| Server | | |Resolver|
250: | files | | | |<--------|--| |
251: | |/ | | queries | +--------+
252: +---------+ +----------+ |
253:
254: Here the name server acquires information about one or more zones
255: by reading master files from its local file system, and answers
256: queries about those zones that arrive from foreign resolvers.
257:
258: A more sophisticated name server might acquire zones from foreign
259: name servers as well as local master files. This configuration is
260: shown below:
261:
262: Local Host | Foreign
263: |
264: +---------+ |
265: / /| |
266: +---------+ | +----------+ | +--------+
267: | | | | |responses| | |
268: | | | | Name |---------|->|Foreign |
269: | Master |-------------->| Server | | |Resolver|
270: | files | | | |<--------|--| |
271: | |/ | | queries | +--------+
272: +---------+ +----------+ |
273: A |maintenance | +--------+
274: | \------------|->| |
275: | queries | |Foreign |
276: | | | Name |
277: \------------------|--| Server |
278: maintenance responses | +--------+
279:
280: In this configuration, the name server periodically establishes a
281: virtual circuit to a foreign name server to acquire a copy of a
282: zone or to check that an existing copy has not changed. The
283: messages sent for these maintenance activities follow the same
284: form as queries and responses, but the message sequences are
285: somewhat different.
286:
287:
288:
289: Mockapetris [Page 3]
290:
291:
292: RFC 883 November 1983
293: Domain Names - Implementation and Specification
294:
295:
296: The information flow in a host that supports all aspects of the
297: domain name system is shown below:
298:
299: Local Host | Foreign
300: |
301: +---------+ +----------+ | +--------+
302: | | user queries | |queries | | |
303: | User |-------------->| |---------|->|Foreign |
304: | Program | | Resolver | | | Name |
305: | |<--------------| |<--------|--| Server |
306: | | user responses| |responses| | |
307: +---------+ +----------+ | +--------+
308: | A |
309: cache additions | | references |
310: V | |
311: +----------+ |
312: | Shared | |
313: | database | |
314: +----------+ |
315: A | |
316: +---------+ refreshes | | references |
317: / /| | V |
318: +---------+ | +----------+ | +--------+
319: | | | | |responses| | |
320: | | | | Name |---------|->|Foreign |
321: | Master |-------------->| Server | | |Resolver|
322: | files | | | |<--------|--| |
323: | |/ | | queries | +--------+
324: +---------+ +----------+ |
325: A |maintenance | +--------+
326: | \------------|->| |
327: | queries | |Foreign |
328: | | | Name |
329: \------------------|--| Server |
330: maintenance responses | +--------+
331:
332: The shared database holds domain space data for the local name
333: server and resolver. The contents of the shared database will
334: typically be a mixture of authoritative data maintained by the
335: periodic refresh operations of the name server and cached data
336: from previous resolver requests. The structure of the domain data
337: and the necessity for synchronization between name servers and
338: resolvers imply the general characteristics of this database, but
339: the actual format is up to the local implementer. This memo
340: suggests a multiple tree format.
341:
342:
343:
344:
345:
346:
347: Mockapetris [Page 4]
348:
349:
350: RFC 883 November 1983
351: Domain Names - Implementation and Specification
352:
353:
354: This memo divides the implementation discussion into sections:
355:
356: NAME SERVER TRANSACTIONS, which discusses the formats for name
357: servers queries and the corresponding responses.
358:
359: NAME SERVER MAINTENANCE, which discusses strategies,
360: algorithms, and formats for maintaining the data residing in
361: name servers. These services periodically refresh the local
362: copies of zones that originate in other hosts.
363:
364: RESOLVER ALGORITHMS, which discusses the internal structure of
365: resolvers. This section also discusses data base sharing
366: between a name server and a resolver on the same host.
367:
368: DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain
369: system to support mail transfer.
370:
371:
372:
373:
374:
375:
376:
377:
378:
379:
380:
381:
382:
383:
384:
385:
386:
387:
388:
389:
390:
391:
392:
393:
394:
395:
396:
397:
398:
399:
400:
401:
402:
403:
404:
405: Mockapetris [Page 5]
406:
407:
408: RFC 883 November 1983
409: Domain Names - Implementation and Specification
410:
411:
412: Conventions
413:
414: The domain system has several conventions dealing with low-level,
415: but fundamental, issues. While the implementer is free to violate
416: these conventions WITHIN HIS OWN SYSTEM, he must observe these
417: conventions in ALL behavior observed from other hosts.
418:
419: ********** Data Transmission Order **********
420:
421: The order of transmission of the header and data described in this
422: document is resolved to the octet level. Whenever a diagram shows
423: a group of octets, the order of transmission of those octets is
424: the normal order in which they are read in English. For example,
425: in the following diagram the octets are transmitted in the order
426: they are numbered.
427:
428:
429: 0 1
430: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
431: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
432: | 1 | 2 |
433: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
434: | 3 | 4 |
435: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
436: | 5 | 6 |
437: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
438:
439: Transmission Order of Bytes
440:
441: Whenever an octet represents a numeric quantity the left most bit
442: in the diagram is the high order or most significant bit. That
443: is, the bit labeled 0 is the most significant bit. For example,
444: the following diagram represents the value 170 (decimal).
445:
446:
447: 0 1 2 3 4 5 6 7
448: +-+-+-+-+-+-+-+-+
449: |1 0 1 0 1 0 1 0|
450: +-+-+-+-+-+-+-+-+
451:
452: Significance of Bits
453:
454: Similarly, whenever a multi-octet field represents a numeric
455: quantity the left most bit of the whole field is the most
456: significant bit. When a multi-octet quantity is transmitted the
457: most significant octet is transmitted first.
458:
459:
460:
461:
462:
463: Mockapetris [Page 6]
464:
465:
466: RFC 883 November 1983
467: Domain Names - Implementation and Specification
468:
469:
470: ********** Character Case **********
471:
472: All comparisons between character strings (e.g. labels, domain
473: names, etc.) are done in a case-insensitive manner.
474:
475: When data enters the domain system, its original case should be
476: preserved whenever possible. In certain circumstances this cannot
477: be done. For example, if two domain names x.y and X.Y are entered
478: into the domain database, they are interpreted as the same name,
479: and hence may have a single representation. The basic rule is
480: that case can be discarded only when data is used to define
481: structure in a database, and two names are identical when compared
482: in a case insensitive manner.
483:
484: Loss of case sensitive data must be minimized. Thus while data
485: for x.y and X.Y may both be stored under x.y, data for a.x and B.X
486: can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In
487: general, this prevents the first component of a domain name from
488: loss of case information.
489:
490: Systems administrators who enter data into the domain database
491: should take care to represent the data they supply to the domain
492: system in a case-consistent manner if their system is
493: case-sensitive. The data distribution system in the domain system
494: will ensure that consistent representations are preserved.
495:
496:
497:
498:
499:
500:
501:
502:
503:
504:
505:
506:
507:
508:
509:
510:
511:
512:
513:
514:
515:
516:
517:
518:
519:
520:
521: Mockapetris [Page 7]
522:
523:
524: RFC 883 November 1983
525: Domain Names - Implementation and Specification
526:
527:
528: Design philosophy
529:
530: The design presented in this memo attempts to provide a base which
531: will be suitable for several existing networks. An equally
532: important goal is to provide these services within a framework
533: that is capable of adjustment to fit the evolution of services in
534: early clients as well as to accommodate new networks.
535:
536: Since it is impossible to predict the course of these
537: developments, the domain system attempts to provide for evolution
538: in the form of an extensible framework. This section describes
539: the areas in which we expect to see immediate evolution.
540:
541: DEFINING THE DATABASE
542:
543: This memo defines methods for partitioning the database and data
544: for host names, host addresses, gateway information, and mail
545: support. Experience with this system will provide guidance for
546: future additions.
547:
548: While the present system allows for many new RR types, classes,
549: etc., we feel that it is more important to get the basic services
550: in operation than to cover an exhaustive set of information.
551: Hence we have limited the data types to those we felt were
552: essential, and would caution designers to avoid implementations
553: which are based on the number of existing types and classes.
554: Extensibility in this area is very important.
555:
556: While the domain system provides techniques for partitioning the
557: database, policies for administrating the orderly connection of
558: separate domains and guidelines for constructing the data that
559: makes up a particular domain will be equally important to the
560: success of the system. Unfortunately, we feel that experience
561: with prototype systems will be necessary before this question can
562: be properly addressed. Thus while this memo has minimal
563: discussion of these issues, it is a critical area for development.
564:
565: TYING TOGETHER INTERNETS
566:
567: Although it is very difficult to characterize the types of
568: networks, protocols, and applications that will be clients of the
569: domain system, it is very obvious that some of these applications
570: will cross the boundaries of network and protocol. At the very
571: least, mail is such a service.
572:
573: Attempts to unify two such systems must deal with two major
574: problems:
575:
576: 1. Differing formats for environment sensitive data. For example,
577:
578:
579: Mockapetris [Page 8]
580:
581:
582: RFC 883 November 1983
583: Domain Names - Implementation and Specification
584:
585:
586: network addresses vary in format, and it is unreasonable to
587: expect to enforce consistent conventions.
588:
589: 2. Connectivity may require intermediaries. For example, it is a
590: frequent occurence that mail is sent between hosts that share
591: no common protocol.
592:
593: The domain system acknowledges that these are very difficult
594: problems, and attempts to deal with both problems through its
595: CLASS mechanism:
596:
597: 1. The CLASS field in RRs allows data to be tagged so that all
598: programs in the domain system can identify the format in use.
599:
600: 2. The CLASS field allows the requestor to identify the format of
601: data which can be understood by the requestor.
602:
603: 3. The CLASS field guides the search for the requested data.
604:
605: The last point is central to our approach. When a query crosses
606: protocol boundaries, it must be guided though agents capable of
607: performing whatever translation is required. For example, when a
608: mailer wants to identify the location of a mailbox in a portion of
609: the domain system that doesn't have a compatible protocol, the
610: query must be guided to a name server that can cross the boundary
611: itself or form one link in a chain that can span the differences.
612:
613: If query and response transport were the only problem, then this
614: sort of problem could be dealt with in the name servers
615: themselves. However, the applications that will use domain
616: service have similar problems. For example, mail may need to be
617: directed through mail gateways, and the characteristics of one of
618: the environments may not permit frequent connectivity between name
619: servers in all environments.
620:
621: These problems suggest that connectivity will be achieved through
622: a variety of measures:
623:
624: Translation name servers that act as relays between different
625: protocols.
626:
627: Translation application servers that translate application
628: level transactions.
629:
630: Default database entries that route traffic through application
631: level forwarders in ways that depend on the class of the
632: requestor.
633:
634: While this approach seems best given our current understanding of
635:
636:
637: Mockapetris [Page 9]
638:
639:
640: RFC 883 November 1983
641: Domain Names - Implementation and Specification
642:
643:
644: the problem, we realize that the approach of using resource data
645: that transcends class may be appropriate in future designs or
646: applications. By not defining class to be directly related to
647: protocol, network, etc., we feel that such services could be added
648: by defining a new "universal" class, while the present use of
649: class will provide immediate service.
650:
651: This problem requires more thought and experience before solutions
652: can be discovered. The concepts of CLASS, recursive servers and
653: other mechanisms are intended as tools for acquiring experience
654: and not as final solutions.
655:
656:
657:
658:
659:
660:
661:
662:
663:
664:
665:
666:
667:
668:
669:
670:
671:
672:
673:
674:
675:
676:
677:
678:
679:
680:
681:
682:
683:
684:
685:
686:
687:
688:
689:
690:
691:
692:
693:
694:
695: Mockapetris [Page 10]
696:
697:
698: RFC 883 November 1983
699: Domain Names - Implementation and Specification
700:
701:
702: NAME SERVER TRANSACTIONS
703:
704: Introduction
705:
706: The primary purpose of name servers is to receive queries from
707: resolvers and return responses. The overall model of this service
708: is that a program (typically a resolver) asks the name server
709: questions (queries) and gets responses that either answer the
710: question or refer the questioner to another name server. Other
711: functions related to name server database maintenance use similar
712: procedures and formats and are discussed in a section later in
713: this memo.
714:
715: There are three kinds of queries presently defined:
716:
717: 1. Standard queries that ask for a specified resource attached
718: to a given domain name.
719:
720: 2. Inverse queries that specify a resource and ask for a domain
721: name that possesses that resource.
722:
723: 3. Completion queries that specify a partial domain name and a
724: target domain and ask that the partial domain name be
725: completed with a domain name close to the target domain.
726:
727: This memo uses an unqualified reference to queries to refer to
728: either all queries or standard queries when the context is clear.
729:
730: Query and response transport
731:
732: Name servers and resolvers use a single message format for all
733: communications. The message format consists of a variable-length
734: octet string which includes binary values.
735:
736: The messages used in the domain system are designed so that they
737: can be carried using either datagrams or virtual circuits. To
738: accommodate the datagram style, all responses carry the query as
739: part of the response.
740:
741: While the specification allows datagrams to be used in any
742: context, some activities are ill suited to datagram use. For
743: example, maintenance transactions and recursive queries typically
744: require the error control of virtual circuits. Thus datagram use
745: should be restricted to simple queries.
746:
747: The domain system assumes that a datagram service provides:
748:
749: 1. A non-reliable (i.e. best effort) method of transporting a
750: message of up to 512 octets.
751:
752:
753: Mockapetris [Page 11]
754:
755:
756: RFC 883 November 1983
757: Domain Names - Implementation and Specification
758:
759:
760: Hence datagram messages are limited to 512 octets. If a
761: datagram message would exceed 512 octets, it is truncated
762: and a truncation flag is set in its header.
763:
764: 2. A message size that gives the number of octets in the
765: datagram.
766:
767: The main implications for programs accessing name servers via
768: datagrams are:
769:
770: 1. Datagrams should not be used for maintenance transactions
771: and recursive queries.
772:
773: 2. Since datagrams may be lost, the originator of a query must
774: perform error recovery (such as retransmissions) as
775: appropriate.
776:
777: 3. Since network or host delay may cause retransmission when a
778: datagram has not been lost, the originator of a query must
779: be ready to deal with duplicate responses.
780:
781: The domain system assumes that a virtual circuit service provides:
782:
783: 1. A reliable method of transmitting a message of up to 65535
784: octets.
785:
786: 2. A message size that gives the number of octets in the
787: message.
788:
789: If the virtual circuit service does not provide for message
790: boundary detection or limits transmission size to less than
791: 65535 octets, then messages are prefaced with an unsigned 16
792: bit length field and broken up into separate transmissions
793: as required. The length field is only prefaced on the first
794: message. This technique is used for TCP virtual circuits.
795:
796: 3. Multiple messages may be sent over a virtual circuit.
797:
798: 4. A method for closing a virtual circuit.
799:
800: 5. A method for detecting that the other party has requested
801: that the virtual circuit be closed.
802:
803: The main implications for programs accessing name servers via
804: virtual circuits are:
805:
806: 1. Either end of a virtual circuit may initiate a close when
807: there is no activity in progress. The other end should
808: comply.
809:
810:
811: Mockapetris [Page 12]
812:
813:
814: RFC 883 November 1983
815: Domain Names - Implementation and Specification
816:
817:
818: The decision to initiate a close is a matter of individual
819: site policy; some name servers may leave a virtual circuit
820: open for an indeterminate period following a query to allow
821: for subsequent queries; other name servers may choose to
822: initiate a close following the completion of the first query
823: on a virtual circuit. Of course, name servers should not
824: close the virtual circuit in the midst of a multiple message
825: stream used for zone transfer.
826:
827: 2. Since network delay may cause one end to erroneously believe
828: that no activity is in progress, a program which receives a
829: virtual circuit close while a query is in progress should
830: close the virtual circuit and resubmit the query on a new
831: virtual circuit.
832:
833: All messages may use a compression scheme to reduce the space
834: consumed by repetitive domain names. The use of the compression
835: scheme is optional for the sender of a message, but all receivers
836: must be capable of decoding compressed domain names.
837:
838: Overall message format
839:
840: All messages sent by the domain system are divided into 5 sections
841: (some of which are empty in certain cases) shown below:
842:
843: +---------------------+
844: | Header |
845: +---------------------+
846: | Question | the question for the name server
847: +---------------------+
848: | Answer | answering resource records (RRs)
849: +---------------------+
850: | Authority | RRs pointing toward an authority
851: +---------------------+
852: | Additional | RRs holding pertinent information
853: +---------------------+
854:
855: The header section is always present. The header includes fields
856: that specify which of the remaining sections are present, and also
857: specify whether the message is a query, inverse query, completion
858: query, or response.
859:
860: The question section contains fields that describe a question to a
861: name server. These fields are a query type (QTYPE), a query class
862: (QCLASS), and a query domain name (QNAME).
863:
864: The last three sections have the same format: a possibly empty
865: list of concatenated resource records (RRs). The answer section
866: contains RRs that answer the question; the authority section
867:
868:
869: Mockapetris [Page 13]
870:
871:
872: RFC 883 November 1983
873: Domain Names - Implementation and Specification
874:
875:
876: contains RRs that point toward an authoritative name server; the
877: additional records section contains RRs which relate to the query,
878: but are not strictly answers for the question.
879:
880: The next two sections of this memo illustrate the use of these
881: message sections through examples; a detailed discussion of data
882: formats follows the examples.
883:
884:
885:
886:
887:
888:
889:
890:
891:
892:
893:
894:
895:
896:
897:
898:
899:
900:
901:
902:
903:
904:
905:
906:
907:
908:
909:
910:
911:
912:
913:
914:
915:
916:
917:
918:
919:
920:
921:
922:
923:
924:
925:
926:
927: Mockapetris [Page 14]
928:
929:
930: RFC 883 November 1983
931: Domain Names - Implementation and Specification
932:
933:
934: The contents of standard queries and responses
935:
936: When a name server processes a standard query, it first determines
937: whether it is an authority for the domain name specified in the
938: query.
939:
940: If the name server is an authority, it returns either:
941:
942: 1. the specified resource information
943:
944: 2. an indication that the specified name does not exist
945:
946: 3. an indication that the requested resource information does
947: not exist
948:
949: If the name server is not an authority for the specified name, it
950: returns whatever relevant resource information it has along with
951: resource records that the requesting resolver can use to locate an
952: authoritative name server.
953:
954: Standard query and response example
955:
956: The overall structure of a query for retrieving information for
957: Internet mail for domain F.ISI.ARPA is shown below:
958:
959: +-----------------------------------------+
960: Header | OPCODE=QUERY, ID=2304 |
961: +-----------------------------------------+
962: Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
963: +-----------------------------------------+
964: Answer | <empty> |
965: +-----------------------------------------+
966: Authority | <empty> |
967: +-----------------------------------------+
968: Additional | <empty> |
969: +-----------------------------------------+
970:
971: The header includes an opcode field that specifies that this
972: datagram is a query, and an ID field that will be used to
973: associate replies with the original query. (Some additional
974: header fields have been omitted for clarity.) The question
975: section specifies that the type of the query is for mail agent
976: information, that only ARPA Internet information is to be
977: considered, and that the domain name of interest is F.ISI.ARPA.
978: The remaining sections are empty, and would not use any octets in
979: a real query.
980:
981:
982:
983:
984:
985: Mockapetris [Page 15]
986:
987:
988: RFC 883 November 1983
989: Domain Names - Implementation and Specification
990:
991:
992: One possible response to this query might be:
993:
994: +-----------------------------------------+
995: Header | OPCODE=RESPONSE, ID=2304 |
996: +-----------------------------------------+
997: Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
998: +-----------------------------------------+
999: Answer | <empty> |
1000: +-----------------------------------------+
1001: Authority | ARPA NS IN A.ISI.ARPA |
1002: | ------- |
1003: | ARPA NS IN F.ISI.ARPA |
1004: +-----------------------------------------+
1005: Additional | F.ISI.ARPA A IN 10.2.0.52 |
1006: | ------- |
1007: | A.ISI.ARPA A IN 10.1.0.22 |
1008: +-----------------------------------------+
1009:
1010: This type of response would be returned by a name server that was
1011: not an authority for the domain name F.ISI.ARPA. The header field
1012: specifies that the datagram is a response to a query with an ID of
1013: 2304. The question section is copied from the question section in
1014: the query datagram.
1015:
1016: The answer section is empty because the name server did not have
1017: any information that would answer the query. (Name servers may
1018: happen to have cached information even if they are not
1019: authoritative for the query.)
1020:
1021: The best that this name server could do was to pass back
1022: information for the domain ARPA. The authority section specifies
1023: two name servers for the domain ARPA using the Internet family:
1024: A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence
1025: that F.ISI.ARPA is a name server for ARPA as well as the subject
1026: of the query.
1027:
1028: In this case, the name server included in the additional records
1029: section the Internet addresses for the two hosts specified in the
1030: authority section. Such additional data is almost always
1031: available.
1032:
1033: Given this response, the process that originally sent the query
1034: might resend the query to the name server on A.ISI.ARPA, with a
1035: new ID of 2305.
1036:
1037:
1038:
1039:
1040:
1041:
1042:
1043: Mockapetris [Page 16]
1044:
1045:
1046: RFC 883 November 1983
1047: Domain Names - Implementation and Specification
1048:
1049:
1050: The name server on A.ISI.ARPA might return a response:
1051:
1052: +-----------------------------------------+
1053: Header | OPCODE=RESPONSE, ID=2305 |
1054: +-----------------------------------------+
1055: Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA |
1056: +-----------------------------------------+
1057: Answer | F.ISI.ARPA MD IN F.ISI.ARPA |
1058: | ------- |
1059: | F.ISI.ARPA MF IN A.ISI.ARPA |
1060: +-----------------------------------------+
1061: Authority | <empty> |
1062: +-----------------------------------------+
1063: Additional | F.ISI.ARPA A IN 10.2.0.52 |
1064: | ------- |
1065: | A.ISI.ARPA A IN 10.1.0.22 |
1066: +-----------------------------------------+
1067:
1068: This query was directed to an authoritative name server, and hence
1069: the response includes an answer but no authority records. In this
1070: case, the answer section specifies that mail for F.ISI.ARPA can
1071: either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The
1072: additional records section specifies the Internet addresses of
1073: these hosts.
1074:
1075: The contents of inverse queries and responses
1076:
1077: Inverse queries reverse the mappings performed by standard query
1078: operations; while a standard query maps a domain name to a
1079: resource, an inverse query maps a resource to a domain name. For
1080: example, a standard query might bind a domain name to a host
1081: address; the corresponding inverse query binds the host address to
1082: a domain name.
1083:
1084: Inverse query mappings are not guaranteed to be unique or complete
1085: because the domain system does not have any internal mechanism for
1086: determining authority from resource records that parallels the
1087: capability for determining authority as a function of domain name.
1088: In general, resolvers will be configured to direct inverse queries
1089: to a name server which is known to have the desired information.
1090:
1091: Name servers are not required to support any form of inverse
1092: queries; it is anticipated that most name servers will support
1093: address to domain name conversions, but no other inverse mappings.
1094: If a name server receives an inverse query that it does not
1095: support, it returns an error response with the "Not Implemented"
1096: error set in the header. While inverse query support is optional,
1097: all name servers must be at least able to return the error
1098: response.
1099:
1100:
1101: Mockapetris [Page 17]
1102:
1103:
1104: RFC 883 November 1983
1105: Domain Names - Implementation and Specification
1106:
1107:
1108: When a name server processes an inverse query, it either returns:
1109:
1110: 1. zero, one, or multiple domain names for the specified
1111: resource
1112:
1113: 2. an error code indicating that the name server doesn't
1114: support inverse mapping of the specified resource type.
1115:
1116: Inverse query and response example
1117:
1118: The overall structure of an inverse query for retrieving the
1119: domain name that corresponds to Internet address 10.2.0.52 is
1120: shown below:
1121:
1122: +-----------------------------------------+
1123: Header | OPCODE=IQUERY, ID=997 |
1124: +-----------------------------------------+
1125: Question | <empty> |
1126: +-----------------------------------------+
1127: Answer | <anyname> A IN 10.2.0.52 |
1128: +-----------------------------------------+
1129: Authority | <empty> |
1130: +-----------------------------------------+
1131: Additional | <empty> |
1132: +-----------------------------------------+
1133:
1134: This query asks for a question whose answer is the Internet style
1135: address 10.2.0.52. Since the owner name is not known, any domain
1136: name can be used as a placeholder (and is ignored). The response
1137: to this query might be:
1138:
1139: +-----------------------------------------+
1140: Header | OPCODE=RESPONSE, ID=997 |
1141: +-----------------------------------------+
1142: Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA |
1143: +-----------------------------------------+
1144: Answer | F.ISI.ARPA A IN 10.2.0.52 |
1145: +-----------------------------------------+
1146: Authority | <empty> |
1147: +-----------------------------------------+
1148: Additional | <empty> |
1149: +-----------------------------------------+
1150:
1151: Note that the QTYPE in a response to an inverse query is the same
1152: as the TYPE field in the answer section of the inverse query.
1153: Responses to inverse queries may contain multiple questions when
1154: the inverse is not unique.
1155:
1156:
1157:
1158:
1159: Mockapetris [Page 18]
1160:
1161:
1162: RFC 883 November 1983
1163: Domain Names - Implementation and Specification
1164:
1165:
1166: Completion queries and responses
1167:
1168: Completion queries ask a name server to complete a partial domain
1169: name and return a set of RRs whose domain names meet a specified
1170: set of criteria for "closeness" to the partial input. This type
1171: of query can provide a local shorthand for domain names or command
1172: completion similar to that in TOPS-20.
1173:
1174: Implementation of completion query processing is optional in a
1175: name server. However, a name server must return a "Not
1176: Implemented" (NI) error response if it does not support
1177: completion.
1178:
1179: The arguments in a completion query specify:
1180:
1181: 1. A type in QTYPE that specifies the type of the desired name.
1182: The type is used to restrict the type of RRs which will match
1183: the partial input so that completion queries can be used for
1184: mailbox names, host names, or any other type of RR in the
1185: domain system without concern for matches to the wrong type of
1186: resource.
1187:
1188: 2. A class in QCLASS which specifies the desired class of the RR.
1189:
1190: 3. A partial domain name that gives the input to be completed.
1191: All returned RRs will begin with the partial string. The
1192: search process first looks for names which qualify under the
1193: assumption that the partial string ends with a full label
1194: ("whole label match"); if this search fails, the search
1195: continues under the assumption that the last label in the
1196: partial sting may be an incomplete label ("partial label
1197: match"). For example, if the partial string "Smith" was used
1198: in a mailbox completion, it would match [email protected] in
1199: preference to [email protected].
1200:
1201: The partial name is supplied by the user through the user
1202: program that is using domain services. For example, if the
1203: user program is a mail handler, the string might be "Mockap"
1204: which the user intends as a shorthand for the mailbox
1205: [email protected]; if the user program is TELNET, the user
1206: might specify "F" for F.ISI.ARPA.
1207:
1208: In order to make parsing of messages consistent, the partial
1209: name is supplied in domain name format (i.e. a sequence of
1210: labels terminated with a zero length octet). However, the
1211: trailing root label is ignored during matching.
1212:
1213: 4. A target domain name which specifies the domain which is to be
1214: examined for matches. This name is specified in the additional
1215:
1216:
1217: Mockapetris [Page 19]
1218:
1219:
1220: RFC 883 November 1983
1221: Domain Names - Implementation and Specification
1222:
1223:
1224: section using a NULL RR. All returned names will end with the
1225: target name.
1226:
1227: The user program which constructs the query uses the target
1228: name to restrict the search. For example, user programs
1229: running at ISI might restrict completion to names that end in
1230: ISI.ARPA; user programs running at MIT might restrict
1231: completion to the domain MIT.ARPA.
1232:
1233: The target domain name is also used by the resolver to
1234: determine the name server which should be used to process the
1235: query. In general, queries should be directed to a name server
1236: that is authoritative for the target domain name. User
1237: programs which wish to provide completion for a more than one
1238: target can issue multiple completion queries, each directed at
1239: a different target. Selection of the target name and the
1240: number of searches will depend on the goals of the user
1241: program.
1242:
1243: 5. An opcode for the query. The two types of completion queries
1244: are "Completion Query - Multiple", or CQUERYM, which asks for
1245: all RRs which could complete the specified input, and
1246: "Completion Query - Unique", or CQUERYU, which asks for the
1247: "best" completion.
1248:
1249: CQUERYM is used by user programs which want to know if
1250: ambiguities exist or wants to do its own determinations as to
1251: the best choice of the available candidates.
1252:
1253: CQUERYU is used by user programs which either do not wish to
1254: deal with multiple choices or are willing to use the closeness
1255: criteria used by CQUERYU to select the best match.
1256:
1257: When a name server receives either completion query, it first
1258: looks for RRs that begin (on the left) with the same labels as are
1259: found in QNAME (with the root deleted), and which match the QTYPE
1260: and QCLASS. This search is called "whole label" matching. If one
1261: or more hits are found the name server either returns all of the
1262: hits (CQUERYM) or uses the closeness criteria described below to
1263: eliminate all but one of the matches (CQUERYU).
1264:
1265: If the whole label match fails to find any candidates, then the
1266: name server assumes that the rightmost label of QNAME (after root
1267: deletion) is not a complete label, and looks for candidates that
1268: would match if characters were added (on the right) to the
1269: rightmost label of QNAME. If one or more hits are found the name
1270: server either returns all of the hits (CQUERYM) or uses the
1271: closeness criteria described below to eliminate all but one of the
1272: matches (CQUERYU).
1273:
1274:
1275: Mockapetris [Page 20]
1276:
1277:
1278: RFC 883 November 1983
1279: Domain Names - Implementation and Specification
1280:
1281:
1282: If a CQUERYU query encounters multiple hits, it uses the following
1283: sequence of rules to discard multiple hits:
1284:
1285: 1. Discard candidates that have more labels than others. Since
1286: all candidates start with the partial name and end with the
1287: target name, this means that we select those entries that
1288: require the fewest number of added labels. For example, a host
1289: search with a target of "ISI.ARPA" and a partial name of "A"
1290: will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA.
1291:
1292: 2. If partial label matching was used, discard those labels which
1293: required more characters to be added. For example, a mailbox
1294: search for partial "X" and target "ISI.ARPA" would prefer
1295: [email protected] to [email protected].
1296:
1297: If multiple hits are still present, return all hits.
1298:
1299: Completion query mappings are not guaranteed to be unique or
1300: complete because the domain system does not have any internal
1301: mechanism for determining authority from a partial domain name
1302: that parallels the capability for determining authority as a
1303: function of a complete domain name. In general, resolvers will be
1304: configured to direct completion queries to a name server which is
1305: known to have the desired information.
1306:
1307: When a name server processes a completion query, it either
1308: returns:
1309:
1310: 1. An answer giving zero, one, or more possible completions.
1311:
1312: 2. an error response with Not Implemented (NI) set.
1313:
1314:
1315:
1316:
1317:
1318:
1319:
1320:
1321:
1322:
1323:
1324:
1325:
1326:
1327:
1328:
1329:
1330:
1331:
1332:
1333: Mockapetris [Page 21]
1334:
1335:
1336: RFC 883 November 1983
1337: Domain Names - Implementation and Specification
1338:
1339:
1340: Completion query and response example
1341:
1342: Suppose that the completion service was used by a TELNET program
1343: to allow a user to specify a partial domain name for the desired
1344: host. Thus a user might ask to be connected to "B". Assuming
1345: that the query originated from an ISI machine, the query might
1346: look like:
1347:
1348: +-----------------------------------------+
1349: Header | OPCODE=CQUERYU, ID=409 |
1350: +-----------------------------------------+
1351: Question | QTYPE=A, QCLASS=IN, QNAME=B |
1352: +-----------------------------------------+
1353: Answer | <empty> |
1354: +-----------------------------------------+
1355: Authority | <empty> |
1356: +-----------------------------------------+
1357: Additional | ISI.ARPA NULL IN |
1358: +-----------------------------------------+
1359:
1360: The partial name in the query is "B", the mappings of interest are
1361: ARPA Internet address records, and the target domain is ISI.ARPA.
1362: Note that NULL is a special type of NULL resource record that is
1363: used as a placeholder and has no significance; NULL RRs obey the
1364: standard format but have no other function.
1365:
1366: The response to this completion query might be:
1367:
1368: +-----------------------------------------+
1369: Header | OPCODE=RESPONSE, ID=409 |
1370: +-----------------------------------------+
1371: Question | QTYPE=A, QCLASS=IN, QNAME=B |
1372: +-----------------------------------------+
1373: Answer | B.ISI.ARPA A IN 10.3.0.52 |
1374: +-----------------------------------------+
1375: Authority | <empty> |
1376: +-----------------------------------------+
1377: Additional | ISI.ARPA NULL IN |
1378: +-----------------------------------------+
1379:
1380: This response has completed B to mean B.ISI.ARPA.
1381:
1382:
1383:
1384:
1385:
1386:
1387:
1388:
1389:
1390:
1391: Mockapetris [Page 22]
1392:
1393:
1394: RFC 883 November 1983
1395: Domain Names - Implementation and Specification
1396:
1397:
1398: Another query might be:
1399:
1400: +-----------------------------------------+
1401: Header | OPCODE=CQUERYM, ID=410 |
1402: +-----------------------------------------+
1403: Question | QTYPE=A, QCLASS=IN, QNAME=B |
1404: +-----------------------------------------+
1405: Answer | <empty> |
1406: +-----------------------------------------+
1407: Authority | <empty> |
1408: +-----------------------------------------+
1409: Additional | ARPA NULL IN |
1410: +-----------------------------------------+
1411:
1412: This query is similar to the previous one, but specifies a target
1413: of ARPA rather than ISI.ARPA. It also allows multiple matches.
1414: In this case the same name server might return:
1415:
1416: +-----------------------------------------+
1417: Header | OPCODE=RESPONSE, ID=410 |
1418: +-----------------------------------------+
1419: Question | QTYPE=A, QCLASS=IN, QNAME=B |
1420: +-----------------------------------------+
1421: Answer | B.ISI.ARPA A IN 10.3.0.52 |
1422: | - |
1423: | B.BBN.ARPA A IN 10.0.0.49 |
1424: | - |
1425: | B.BBNCC.ARPA A IN 8.1.0.2 |
1426: +-----------------------------------------+
1427: Authority | <empty> |
1428: +-----------------------------------------+
1429: Additional | ARPA NULL IN |
1430: +-----------------------------------------+
1431:
1432: This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and
1433: B.BBNCC.ARPA.
1434:
1435:
1436:
1437:
1438:
1439:
1440:
1441:
1442:
1443:
1444:
1445:
1446:
1447:
1448:
1449: Mockapetris [Page 23]
1450:
1451:
1452: RFC 883 November 1983
1453: Domain Names - Implementation and Specification
1454:
1455:
1456: Recursive Name Service
1457:
1458: Recursive service is an optional feature of name servers.
1459:
1460: When a name server receives a query regarding a part of the name
1461: space which is not in one of the name server's zones, the standard
1462: response is a message that refers the requestor to another name
1463: server. By iterating on these referrals, the requestor eventually
1464: is directed to a name server that has the required information.
1465:
1466: Name servers may also implement recursive service. In this type
1467: of service, a name server either answers immediately based on
1468: local zone information, or pursues the query for the requestor and
1469: returns the eventual result back to the original requestor.
1470:
1471: A name server that supports recursive service sets the Recursion
1472: Available (RA) bit in all responses it generates. A requestor
1473: asks for recursive service by setting the Recursion Desired (RD)
1474: bit in queries. In some situations where recursive service is the
1475: only path to the desired information (see below), the name server
1476: may go recursive even if RD is zero.
1477:
1478: If a query requests recursion (RD set), but the name server does
1479: not support recursion, and the query needs recursive service for
1480: an answer, the name server returns a "Not Implemented" (NI) error
1481: code. If the query can be answered without recursion since the
1482: name server is authoritative for the query, it ignores the RD bit.
1483:
1484: Because of the difficulty in selecting appropriate timeouts and
1485: error handling, recursive service is best suited to virtual
1486: circuits, although it is allowed for datagrams.
1487:
1488: Recursive service is valuable in several special situations:
1489:
1490: In a system of small personal computers clustered around one or
1491: more large hosts supporting name servers, the recursive
1492: approach minimizes the amount of code in the resolvers in the
1493: personal computers. Such a design moves complexity out of the
1494: resolver into the name server, and may be appropriate for such
1495: systems.
1496:
1497: Name servers on the boundaries of different networks may wish
1498: to offer recursive service to create connectivity between
1499: different networks. Such name servers may wish to provide
1500: recursive service regardless of the setting of RD.
1501:
1502: Name servers that translate between domain name service and
1503: some other name service may wish to adopt the recursive style.
1504: Implicit recursion may be valuable here as well.
1505:
1506:
1507: Mockapetris [Page 24]
1508:
1509:
1510: RFC 883 November 1983
1511: Domain Names - Implementation and Specification
1512:
1513:
1514: These concepts are still under development.
1515:
1516:
1517:
1518:
1519:
1520:
1521:
1522:
1523:
1524:
1525:
1526:
1527:
1528:
1529:
1530:
1531:
1532:
1533:
1534:
1535:
1536:
1537:
1538:
1539:
1540:
1541:
1542:
1543:
1544:
1545:
1546:
1547:
1548:
1549:
1550:
1551:
1552:
1553:
1554:
1555:
1556:
1557:
1558:
1559:
1560:
1561:
1562:
1563:
1564:
1565: Mockapetris [Page 25]
1566:
1567:
1568: RFC 883 November 1983
1569: Domain Names - Implementation and Specification
1570:
1571:
1572: Header section format
1573:
1574: +-----------------------------------------------+
1575: | |
1576: | ***** WARNING ***** |
1577: | |
1578: | The following format is preliminary and is |
1579: | included for purposes of explanation only. In |
1580: | particular, the size and position of the |
1581: | OPCODE, RCODE fields and the number and |
1582: | meaning of the single bit fields are subject |
1583: | to change. |
1584: | |
1585: +-----------------------------------------------+
1586:
1587: The header contains the following fields:
1588:
1589: 1 1 1 1 1 1
1590: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1591: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1592: | ID |
1593: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1594: |QR| Opcode |AA|TC|RD|RA| | RCODE |
1595: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1596: | QDCOUNT |
1597: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1598: | ANCOUNT |
1599: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1600: | NSCOUNT |
1601: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1602: | ARCOUNT |
1603: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1604:
1605: where:
1606:
1607: ID - A 16 bit identifier assigned by the program that
1608: generates any kind of query. This identifier is copied
1609: into all replies and can be used by the requestor to
1610: relate replies to outstanding questions.
1611:
1612: QR - A one bit field that specifies whether this message is a
1613: query (0), or a response (1).
1614:
1615: OPCODE - A four bit field that specifies kind of query in this
1616: message. This value is set by the originator of a query
1617: and copied into the response. The values are:
1618:
1619: 0 a standard query (QUERY)
1620:
1621:
1622:
1623: Mockapetris [Page 26]
1624:
1625:
1626: RFC 883 November 1983
1627: Domain Names - Implementation and Specification
1628:
1629:
1630: 1 an inverse query (IQUERY)
1631:
1632: 2 an completion query allowing multiple
1633: answers (CQUERYM)
1634:
1635: 2 an completion query requesting a single
1636: answer (CQUERYU)
1637:
1638: 4-15 reserved for future use
1639:
1640: AA - Authoritative Answer - this bit is valid in responses,
1641: and specifies that the responding name server
1642: is an authority for the domain name in the
1643: corresponding query.
1644:
1645: TC - TrunCation - specifies that this message was truncated
1646: due to length greater than 512 characters.
1647: This bit is valid in datagram messages but not
1648: in messages sent over virtual circuits.
1649:
1650: RD - Recursion Desired - this bit may be set in a query and
1651: is copied into the response. If RD is set, it
1652: directs the name server to pursue the query
1653: recursively. Recursive query support is
1654: optional.
1655:
1656: RA - Recursion Available - this be is set or cleared in a
1657: response, and denotes whether recursive query
1658: support is available in the name server.
1659:
1660: RCODE - Response code - this 4 bit field is set as part of
1661: responses. The values have the following
1662: interpretation:
1663:
1664: 0 No error condition
1665:
1666: 1 Format error - The name server was unable
1667: to interpret the query.
1668:
1669: 2 Server failure - The name server was unable
1670: to process this query due to a problem with
1671: the name server.
1672:
1673: 3 Name Error - Meaningful only for responses
1674: from an authoritative name server, this
1675: code signifies that the domain name
1676: referenced in the query does not exist.
1677:
1678:
1679:
1680:
1681: Mockapetris [Page 27]
1682:
1683:
1684: RFC 883 November 1983
1685: Domain Names - Implementation and Specification
1686:
1687:
1688: 4 Not Implemented - The name server does not
1689: support the requested kind of query.
1690:
1691: 5 Refused - The name server refuses to
1692: perform the specified operation for policy
1693: reasons. For example, a name server may
1694: not wish to provide the information to the
1695: particular requestor, or a name server may
1696: not wish to perform a particular operation
1697: (e.g. zone transfer) for particular data.
1698:
1699: 6-15 Reserved for future use.
1700:
1701: QDCOUNT - an unsigned 16 bit integer specifying the number of
1702: entries in the question section.
1703:
1704: ANCOUNT - an unsigned 16 bit integer specifying the number of
1705: resource records in the answer section.
1706:
1707: NSCOUNT - an unsigned 16 bit integer specifying the number of name
1708: server resource records in the authority records
1709: section.
1710:
1711: ARCOUNT - an unsigned 16 bit integer specifying the number of
1712: resource records in the additional records section.
1713:
1714:
1715:
1716:
1717:
1718:
1719:
1720:
1721:
1722:
1723:
1724:
1725:
1726:
1727:
1728:
1729:
1730:
1731:
1732:
1733:
1734:
1735:
1736:
1737:
1738:
1739: Mockapetris [Page 28]
1740:
1741:
1742: RFC 883 November 1983
1743: Domain Names - Implementation and Specification
1744:
1745:
1746: Question section format
1747:
1748: The question section is used in all kinds of queries other than
1749: inverse queries. In responses to inverse queries, this section
1750: may contain multiple entries; for all other responses it contains
1751: a single entry. Each entry has the following format:
1752:
1753: 1 1 1 1 1 1
1754: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1755: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1756: | |
1757: / QNAME /
1758: / /
1759: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1760: | QTYPE |
1761: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1762: | QCLASS |
1763: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1764:
1765: where:
1766:
1767: QNAME - a variable number of octets that specify a domain name.
1768: This field uses the compressed domain name format
1769: described in the next section of this memo. This field
1770: can be used to derive a text string for the domain name.
1771: Note that this field may be an odd number of octets; no
1772: padding is used.
1773:
1774: QTYPE - a two octet code which specifies the type of the query.
1775: The values for this field include all codes valid for a
1776: TYPE field, together with some more general codes which
1777: can match more than one type of RR. For example, QTYPE
1778: might be A and only match type A RRs, or might be MAILA,
1779: which matches MF and MD type RRs. The values for this
1780: field are listed in Appendix 2.
1781:
1782: QCLASS - a two octet code that specifies the class of the query.
1783: For example, the QCLASS field is IN for the ARPA
1784: Internet, CS for the CSNET, etc. The numerical values
1785: are defined in Appendix 2.
1786:
1787:
1788:
1789:
1790:
1791:
1792:
1793:
1794:
1795:
1796:
1797: Mockapetris [Page 29]
1798:
1799:
1800: RFC 883 November 1983
1801: Domain Names - Implementation and Specification
1802:
1803:
1804: Resource record format
1805:
1806: The answer, authority, and additional sections all share the same
1807: format: a variable number of resource records, where the number of
1808: records is specified in the corresponding count field in the
1809: header. Each resource record has the following format:
1810:
1811: 1 1 1 1 1 1
1812: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1813: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1814: | |
1815: / /
1816: / NAME /
1817: | |
1818: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1819: | TYPE |
1820: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1821: | CLASS |
1822: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1823: | TTL |
1824: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1825: | RDLENGTH |
1826: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
1827: / RDATA /
1828: / /
1829: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1830:
1831: where:
1832:
1833: NAME - a compressed domain name to which this resource record
1834: pertains.
1835:
1836: TYPE - two octets containing one of the RR type codes defined
1837: in Appendix 2. This field specifies the meaning of the
1838: data in the RDATA field.
1839:
1840: CLASS - two octets which specify the class of the data in the
1841: RDATA field.
1842:
1843: TTL - a 16 bit unsigned integer that specifies the time
1844: interval (in seconds) that the resource record may be
1845: cached before it should be discarded. Zero values are
1846: interpreted to mean that the RR can only be used for the
1847: transaction in progress, and should not be cached. For
1848: example, SOA records are always distributed with a zero
1849: TTL to prohibit caching. Zero values can also be used
1850: for extremely volatile data.
1851:
1852:
1853:
1854:
1855: Mockapetris [Page 30]
1856:
1857:
1858: RFC 883 November 1983
1859: Domain Names - Implementation and Specification
1860:
1861:
1862: RDLENGTH- an unsigned 16 bit integer that specifies the length in
1863: octets of the RDATA field.
1864:
1865: RDATA - a variable length string of octets that describes the
1866: resource. The format of this information varies
1867: according to the TYPE and CLASS of the resource record.
1868: For example, the if the TYPE is A and the CLASS is IN,
1869: the RDATA field is a 4 octet ARPA Internet address.
1870:
1871: Formats for particular resource records are shown in Appendicies 2
1872: and 3.
1873:
1874: Domain name representation and compression
1875:
1876: Domain names messages are expressed in terms of a sequence of
1877: labels. Each label is represented as a one octet length field
1878: followed by that number of octets. Since every domain name ends
1879: with the null label of the root, a compressed domain name is
1880: terminated by a length byte of zero. The high order two bits of
1881: the length field must be zero, and the remaining six bits of the
1882: length field limit the label to 63 octets or less.
1883:
1884: To simplify implementations, the total length of label octets and
1885: label length octets that make up a domain name is restricted to
1886: 255 octets or less. Since the trailing root label and its dot are
1887: not printed, printed domain names are 254 octets or less.
1888:
1889: Although labels can contain any 8 bit values in octets that make
1890: up a label, it is strongly recommended that labels follow the
1891: syntax described in Appendix 1 of this memo, which is compatible
1892: with existing host naming conventions. Name servers and resolvers
1893: must compare labels in a case-insensitive manner, i.e. A=a, and
1894: hence all character strings must be ASCII with zero parity.
1895: Non-alphabetic codes must match exactly.
1896:
1897: Whenever possible, name servers and resolvers must preserve all 8
1898: bits of domain names they process. When a name server is given
1899: data for the same name under two different case usages, this
1900: preservation is not always possible. For example, if a name
1901: server is given data for ISI.ARPA and isi.arpa, it should create a
1902: single node, not two, and hence will preserve a single casing of
1903: the label. Systems with case sensitivity should take special
1904: precautions to insure that the domain data for the system is
1905: created with consistent case.
1906:
1907: In order to reduce the amount of space used by repetitive domain
1908: names, the sequence of octets that defines a domain name may be
1909: terminated by a pointer to the length octet of a previously
1910: specified label string. The label string that the pointer
1911:
1912:
1913: Mockapetris [Page 31]
1914:
1915:
1916: RFC 883 November 1983
1917: Domain Names - Implementation and Specification
1918:
1919:
1920: specifies is appended to the already specified label string.
1921: Exact duplication of a previous label string can be done with a
1922: single pointer. Multiple levels are allowed.
1923:
1924: Pointers can only be used in positions in the message where the
1925: format is not class specific. If this were not the case, a name
1926: server that was handling a RR for another class could make
1927: erroneous copies of RRs. As yet, there are no such cases, but
1928: they may occur in future RDATA formats.
1929:
1930: If a domain name is contained in a part of the message subject to
1931: a length field (such as the RDATA section of an RR), and
1932: compression is used, the length of the compressed name is used in
1933: the length calculation, rather than the length of the expanded
1934: name.
1935:
1936: Pointers are represented as a two octet field in which the high
1937: order 2 bits are ones, and the low order 14 bits specify an offset
1938: from the start of the message. The 01 and 10 values of the high
1939: order bits are reserved for future use and should not be used.
1940:
1941: Programs are free to avoid using pointers in datagrams they
1942: generate, although this will reduce datagram capacity. However
1943: all programs are required to understand arriving messages that
1944: contain pointers.
1945:
1946: For example, a datagram might need to use the domain names
1947: F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the
1948: other fields of the message, these domain names might be
1949: represented as:
1950:
1951:
1952:
1953:
1954:
1955:
1956:
1957:
1958:
1959:
1960:
1961:
1962:
1963:
1964:
1965:
1966:
1967:
1968:
1969:
1970:
1971: Mockapetris [Page 32]
1972:
1973:
1974: RFC 883 November 1983
1975: Domain Names - Implementation and Specification
1976:
1977:
1978: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1979: 20 | 1 | F |
1980: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1981: 22 | 3 | I |
1982: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1983: 24 | S | I |
1984: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1985: 26 | 4 | A |
1986: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1987: 28 | R | P |
1988: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1989: 30 | A | 0 |
1990: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1991:
1992: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1993: 40 | 3 | F |
1994: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1995: 42 | O | O |
1996: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1997: 44 | 1 1| 20 |
1998: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1999:
2000: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2001: 64 | 1 1| 26 |
2002: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2003:
2004: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2005: 92 | 0 | |
2006: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2007:
2008: The domain name for F.ISI.ARPA is shown at offset 20. The domain
2009: name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a
2010: pointer to concatenate a label for FOO to the previously defined
2011: F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a
2012: pointer to the ARPA component of the name F.ISI.ARPA at 20; note
2013: that this reference relies on ARPA being the last label in the
2014: string at 20. The root domain name is defined by a single octet
2015: of zeros at 92; the root domain name has no labels.
2016:
2017: Organization of the Shared database
2018:
2019: While name server implementations are free to use any internal
2020: data structures they choose, the suggested structure consists of
2021: several separate trees. Each tree has structure corresponding to
2022: the domain name space, with RRs attached to nodes and leaves.
2023: Each zone of authoritative data has a separate tree, and one tree
2024: holds all non-authoritative data. All of the trees corresponding
2025: to zones are managed identically, but the non-authoritative or
2026: cache tree has different management procedures.
2027:
2028:
2029: Mockapetris [Page 33]
2030:
2031:
2032: RFC 883 November 1983
2033: Domain Names - Implementation and Specification
2034:
2035:
2036: Data stored in the database can be kept in whatever form is
2037: convenient for the name server, so long as it can be transformed
2038: back into the format needed for messages. In particular, the
2039: database will probably use structure in place of expanded domain
2040: names, and will also convert many of the time intervals used in
2041: the domain systems to absolute local times.
2042:
2043: Each tree corresponding to a zone has complete information for a
2044: "pruned" subtree of the domain space. The top node of a zone has
2045: a SOA record that marks the start of the zone. The bottom edge of
2046: the zone is delimited by nodes containing NS records signifying
2047: delegation of authority to other zones, or by leaves of the domain
2048: tree. When a name server contains abutting zones, one tree will
2049: have a bottom node containing a NS record, and the other tree will
2050: begin with a tree location containing a SOA record.
2051:
2052: Note that there is one special case that requires consideration
2053: when a name server is implemented. A node that contains a SOA RR
2054: denoting a start of zone will also have NS records that identify
2055: the name servers that are expected to have a copy of the zone.
2056: Thus a name server will usually find itself (and possibly other
2057: redundant name servers) referred to in NS records occupying the
2058: same position in the tree as SOA records. The solution to this
2059: problem is to never interpret a NS record as delimiting a zone
2060: started by a SOA at the same point in the tree. (The sample
2061: programs in this memo deal with this problem by processing SOA
2062: records only after NS records have been processed.)
2063:
2064: Zones may also overlap a particular part of the name space when
2065: they are of different classes.
2066:
2067: Other than the abutting and separate class cases, trees are always
2068: expected to be disjoint. Overlapping zones are regarded as a
2069: non-fatal error. The scheme described in this memo avoids the
2070: overlap issue by maintaining separate trees; other designs must
2071: take the appropriate measures to defend against possible overlap.
2072:
2073: Non-authoritative data is maintained in a separate tree. This
2074: tree is unlike the zone trees in that it may have "holes". Each
2075: RR in the cache tree has its own TTL that is separately managed.
2076: The data in this tree is never used if authoritative data is
2077: available from a zone tree; this avoids potential problems due to
2078: cached data that conflicts with authoritative data.
2079:
2080: The shared database will also contain data structures to support
2081: the processing of inverse queries and completion queries if the
2082: local system supports these optional features. Although many
2083: schemes are possible, this memo describes a scheme that is based
2084: on tables of pointers that invert the database according to key.
2085:
2086:
2087: Mockapetris [Page 34]
2088:
2089:
2090: RFC 883 November 1983
2091: Domain Names - Implementation and Specification
2092:
2093:
2094: Each kind of retrieval has a separate set of tables, with one
2095: table per zone. When a zone is updated, these tables must also be
2096: updated. The contents of these tables are discussed in the
2097: "Inverse query processing" and "Completion query processing"
2098: sections of this memo.
2099:
2100: The database implementation described here includes two locks that
2101: are used to control concurrent access and modification of the
2102: database by name server query processing, name server maintenance
2103: operations, and resolver access:
2104:
2105: The first lock ("main lock") controls access to all of the
2106: trees. Multiple concurrent reads are allowed, but write access
2107: can only be acquired by a single process. Read and write
2108: access are mutually exclusive. Resolvers and name server
2109: processes that answer queries acquire this lock in read mode,
2110: and unlock upon completion of the current message. This lock
2111: is acquired in write mode by a name server maintenance process
2112: when it is about to change data in the shared database. The
2113: actual update procedures are described under "NAME SERVER
2114: MAINTENANCE" but are designed to be brief.
2115:
2116: The second lock ("cache queue lock") controls access to the
2117: cache queue. This queue is used by a resolver that wishes to
2118: add information to the cache tree. The resolver acquires this
2119: lock, then places the RRs to be cached into the queue. The
2120: name server maintenance procedure periodically acquires this
2121: lock and adds the queue information to the cache. The
2122: rationale for this procedure is that it allows the resolver to
2123: operate with read-only access to the shared database, and
2124: allows the update process to batch cache additions and the
2125: associated costs for inversion calculations. The name server
2126: maintenance procedure must take appropriate precautions to
2127: avoid problems with data already in the cache, inversions, etc.
2128:
2129: This organization solves several difficulties:
2130:
2131: When searching the domain space for the answer to a query, a
2132: name server can restrict its search for authoritative data to
2133: that tree that matches the most labels on the right side of the
2134: domain name of interest.
2135:
2136: Since updates to a zone must be atomic with respect to
2137: searches, maintenance operations can simply acquire the main
2138: lock, insert a new copy of a particular zone without disturbing
2139: other zones, and then release the storage used by the old copy.
2140: Assuming a central table pointing to valid zone trees, this
2141: operation can be a simple pointer swap.
2142:
2143:
2144:
2145: Mockapetris [Page 35]
2146:
2147:
2148: RFC 883 November 1983
2149: Domain Names - Implementation and Specification
2150:
2151:
2152: TTL management of zones can be performed using the SOA record
2153: for the zone. This avoids potential difficulties if individual
2154: RRs in a zone could be timed out separately. This issue is
2155: discussed further in the maintenance section.
2156:
2157: Query processing
2158:
2159: The following algorithm outlines processing that takes place at a
2160: name server when a query arrives:
2161:
2162: 1. Search the list of zones to find zones which have the same
2163: class as the QCLASS field in the query and have a top domain
2164: name that matches the right end of the QNAME field. If there
2165: are none, go to step 2. If there are more than one, pick the
2166: zone that has the longest match and go to step 3.
2167:
2168: 2. Since the zone search failed, the only possible RRs are
2169: contained in the non-authoritative tree. Search the cache tree
2170: for the NS record that has the same class as the QCLASS field
2171: and the largest right end match for domain name. Add the NS
2172: record or records to the authority section of the response. If
2173: the cache tree has RRs that are pertinent to the question
2174: (domain names match, classes agree, not timed-out, and the type
2175: field is relevant to the QTYPE), copy these RRs into the answer
2176: section of the response. The name server may also search the
2177: cache queue. Go to step 4.
2178:
2179: 3. Since this zone is the best match, the zone in which QNAME
2180: resides is either this zone or a zone to which this zone will
2181: directly or indirectly delegate authority. Search down the
2182: tree looking for a NS RR or the node specified by QNAME.
2183:
2184: If the node exists and has no NS record, copy the relevant
2185: RRs to the answer section of the response and go to step 4.
2186:
2187: If a NS RR is found, either matching a part or all of QNAME,
2188: then QNAME is in a delegated zone outside of this zone. If
2189: so, copy the NS record or records into the authority section
2190: of the response, and search the remainder of the zone for an
2191: A type record corresponding to the NS reference. If the A
2192: record is found, add it to the additional section. Go to
2193: step 2.
2194:
2195: If the node is not found and a NS is not found, there is no
2196: such name; set the Name error bit in the response and exit.
2197:
2198: 4. When this step is reached, the answer and authority sections
2199: are complete. What remains is to complete the additional
2200: section. This procedure is only possible if the name server
2201:
2202:
2203: Mockapetris [Page 36]
2204:
2205:
2206: RFC 883 November 1983
2207: Domain Names - Implementation and Specification
2208:
2209:
2210: knows the data formats implied by the class of records in the
2211: answer and authority sections. Hence this procedure is class
2212: dependent. Appendix 3 discusses this procedure for Internet
2213: class data.
2214:
2215: While this algorithm deals with typical queries and databases,
2216: several additions are required that will depend on the database
2217: supported by the name server:
2218:
2219: QCLASS=*
2220:
2221: Special procedures are required when the QCLASS of the query is
2222: "*". If the database contains several classes of data, the
2223: query processing steps above are performed separately for each
2224: CLASS, and the results are merged into a single response. The
2225: name error condition is not meaningful for a QCLASS=* query.
2226: If the requestor wants this information, it must test each
2227: class independently.
2228:
2229: If the database is limited to data of a particular class, this
2230: operation can be performed by simply reseting the authoritative
2231: bit in the response, and performing the query as if QCLASS was
2232: the class used in the database.
2233:
2234: * labels in database RRs
2235:
2236: Some zones will contain default RRs that use * to match in
2237: cases where the search fails for a particular domain name. If
2238: the database contains these records then a failure must be
2239: retried using * in place of one or more labels of the search
2240: key. The procedure is to replace labels from the left with
2241: "*"s looking for a match until either all labels have been
2242: replaced, or a match is found. Note that these records can
2243: never be the result of caching, so a name server can omit this
2244: processing for zones that don't contain RRs with * in labels,
2245: or can omit this processing entirely if * never appears in
2246: local authoritative data.
2247:
2248: Inverse query processing
2249:
2250: Name servers that support inverse queries can support these
2251: operations through exhaustive searches of their databases, but
2252: this becomes impractical as the size of the database increases.
2253: An alternative approach is to invert the database according to the
2254: search key.
2255:
2256: For name servers that support multiple zones and a large amount of
2257: data, the recommended approach is separate inversions for each
2258:
2259:
2260:
2261: Mockapetris [Page 37]
2262:
2263:
2264: RFC 883 November 1983
2265: Domain Names - Implementation and Specification
2266:
2267:
2268: zone. When a particular zone is changed during a refresh, only
2269: its inversions need to be redone.
2270:
2271: Support for transfer of this type of inversion may be included in
2272: future versions of the domain system, but is not supported in this
2273: version.
2274:
2275: Completion query processing
2276:
2277: Completion query processing shares many of the same problems in
2278: data structure design as are found in inverse queries, but is
2279: different due to the expected high rate of use of top level labels
2280: (ie., ARPA, CSNET). A name server that wishes to be efficient in
2281: its use of memory may well choose to invert only occurrences of
2282: ARPA, etc. that are below the top level, and use a search for the
2283: rare case that top level labels are used to constrain a
2284: completion.
2285:
2286:
2287:
2288:
2289:
2290:
2291:
2292:
2293:
2294:
2295:
2296:
2297:
2298:
2299:
2300:
2301:
2302:
2303:
2304:
2305:
2306:
2307:
2308:
2309:
2310:
2311:
2312:
2313:
2314:
2315:
2316:
2317:
2318:
2319: Mockapetris [Page 38]
2320:
2321:
2322: RFC 883 November 1983
2323: Domain Names - Implementation and Specification
2324:
2325:
2326: NAME SERVER MAINTENANCE
2327:
2328: Introduction
2329:
2330: Name servers perform maintenance operations on their databases to
2331: insure that the data they distribute is accurate and timely. The
2332: amount and complexity of the maintenance operations that a name
2333: server must perform are related to the size, change rate, and
2334: complexity of the database that the name server manages.
2335:
2336: Maintenance operations are fundamentally different for
2337: authoritative and non-authoritative data. A name server actively
2338: attempts to insure the accuracy and timeliness of authoritative
2339: data by refreshing the data from master copies. Non-authoritative
2340: data is merely purged when its time-to-live expires; the name
2341: server does not attempt to refresh it.
2342:
2343: Although the refreshing scheme is fairly simple to implement, it
2344: is somewhat less powerful than schemes used in other distributed
2345: database systems. In particular, an update to the master does not
2346: immediately update copies, and should be viewed as gradually
2347: percolating though the distributed database. This is adequate for
2348: the vast majority of applications. In situations where timliness
2349: is critical, the master name server can prohibit caching of copies
2350: or assign short timeouts to copies.
2351:
2352: Conceptual model of maintenance operations
2353:
2354: The vast majority of information in the domain system is derived
2355: from master files scattered among hosts that implement name
2356: servers; some name servers will have no master files, other name
2357: servers will have one or more master files. Each master file
2358: contains the master data for a single zone of authority rather
2359: than data for the whole domain name space. The administrator of a
2360: particular zone controls that zone by updating its master file.
2361:
2362: Master files and zone copies from remote servers may include RRs
2363: that are outside of the zone of authority when a NS record
2364: delegates authority to a domain name that is a descendant of the
2365: domain name at which authority is delegated. These forward
2366: references are a problem because there is no reasonable method to
2367: guarantee that the A type records for the delegatee are available
2368: unless they can somehow be attached to the NS records.
2369:
2370: For example, suppose the ARPA zone delegates authority at
2371: MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a
2372: resolver gets the NS record but not the A type record for
2373: AI.MIT.ARPA, it might try to ask the MIT name server for the
2374: address of AI.MIT.ARPA.
2375:
2376:
2377: Mockapetris [Page 39]
2378:
2379:
2380: RFC 883 November 1983
2381: Domain Names - Implementation and Specification
2382:
2383:
2384: The solution is to allow type A records that are outside of the
2385: zone of authority to be copied with the zone. While these records
2386: won't be found in a search for the A type record itself, they can
2387: be protected by the zone refreshing system, and will be passed
2388: back whenever the name server passes back a referral to the
2389: corresponding NS record. If a query is received for the A record,
2390: the name server will pass back a referral to the name server with
2391: the A record in the additional section, rather than answer
2392: section.
2393:
2394: The only exception to the use of master files is a small amount of
2395: data stored in boot files. Boot file data is used by name servers
2396: to provide enough resource records to allow zones to be imported
2397: from foreign servers (e.g. the address of the server), and to
2398: establish the name and address of root servers. Boot file records
2399: establish the initial contents of the cache tree, and hence can be
2400: overridden by later loads of authoritative data.
2401:
2402: The data in a master file first becomes available to users of the
2403: domain name system when it is loaded by the corresponding name
2404: server. By definition, data from a master file is authoritative.
2405:
2406: Other name servers which wish to be authoritative for a particular
2407: zone do so by transferring a copy of the zone from the name server
2408: which holds the master copy using a virtual circuit. These copies
2409: include parameters which specify the conditions under which the
2410: data in the copy is authoritative. In the most common case, the
2411: conditions specify a refresh interval and policies to be followed
2412: when the refresh operation cannot be performed.
2413:
2414: A name server may acquire multiple zones from different name
2415: servers and master files, but the name server must maintain each
2416: zone separately from others and from non-authoritative data.
2417:
2418: When the refresh interval for a particular zone copy expires, the
2419: name server holding the copy must consult the name server that
2420: holds the master copy. If the data in the zone has not changed,
2421: the master name server instructs the copy name server to reset the
2422: refresh interval. If the data has changed, the master passes a
2423: new copy of the zone and its associated conditions to the copy
2424: name server. Following either of these transactions, the copy
2425: name server begins a new refresh interval.
2426:
2427: Copy name servers must also deal with error conditions under which
2428: they are unable to communicate with the name server that holds the
2429: master copy of a particular zone. The policies that a copy name
2430: server uses are determined by other parameters in the conditions
2431: distributed with every copy. The conditions include a retry
2432: interval and a maximum holding time. When a copy name server is
2433:
2434:
2435: Mockapetris [Page 40]
2436:
2437:
2438: RFC 883 November 1983
2439: Domain Names - Implementation and Specification
2440:
2441:
2442: unable to establish communications with a master or is unable to
2443: complete the refresh transaction, it must retry the refresh
2444: operation at the rate specified by the retry interval. This retry
2445: interval will usually be substantially shorter than the refresh
2446: interval. Retries continue until the maximum holding time is
2447: reached. At that time the copy name server must assume that its
2448: copy of the data for the zone in question is no longer
2449: authoritative.
2450:
2451: Queries must be processed while maintenance operations are in
2452: progress because a zone transfer can take a long time. However,
2453: to avoid problems caused by access to partial databases, the
2454: maintenance operations create new copies of data rather than
2455: directly modifying the old copies. When the new copy is complete,
2456: the maintenance process locks out queries for a short time using
2457: the main lock, and switches pointers to replace the old data with
2458: the new. After the pointers are swapped, the maintenance process
2459: unlocks the main lock and reclaims the storage used by the old
2460: copy.
2461:
2462: Name server data structures and top level logic
2463:
2464: The name server must multiplex its attention between multiple
2465: activities. For example, a name server should be able to answer
2466: queries while it is also performing refresh activities for a
2467: particular zone. While it is possible to design a name server
2468: that devotes a separate process to each query and refresh activity
2469: in progress, the model described in this memo is based on the
2470: assumption that there is a single process performing all
2471: maintenance operations, and one or more processes devoted to
2472: handling queries. The model also assumes the existence of shared
2473: memory for several control structures, the domain database, locks,
2474: etc.
2475:
2476: The model name server uses the following files and shared data
2477: structures:
2478:
2479: 1. A configuration file that describes the master and boot
2480: files which the name server should load and the zones that
2481: the name server should attempt to load from foreign name
2482: servers. This file establishes the initial contents of the
2483: status table.
2484:
2485: 2. Domain data files that contain master and boot data to be
2486: loaded.
2487:
2488: 3. A status table that is derived from the configuration file.
2489: Each entry in this table describes a source of data. Each
2490: entry has a zone number. The zone number is zero for
2491:
2492:
2493: Mockapetris [Page 41]
2494:
2495:
2496: RFC 883 November 1983
2497: Domain Names - Implementation and Specification
2498:
2499:
2500: non-authoritative sources; authoritative sources are
2501: assigned separate non-zero numbers.
2502:
2503: 4. The shared database that holds the domain data. This
2504: database is assumed to be organized in some sort of tree
2505: structure paralleling the domain name space, with a list of
2506: resource records attached to each node and leaf in the tree.
2507: The elements of the resource record list need not contain
2508: the exact data present in the corresponding output format,
2509: but must contain data sufficient to create the output
2510: format; for example, these records need not contain the
2511: domain name that is associated with the resource because
2512: that name can be derived from the tree structure. Each
2513: resource record also internal data that the name server uses
2514: to organize its data.
2515:
2516: 5. Inversion data structures that allow the name server to
2517: process inverse queries and completion queries. Although
2518: many structures could be used, the implementation described
2519: in this memo supposes that there is one array for every
2520: inversion that the name server can handle. Each array
2521: contains a list of pointers to resource records such that
2522: the order of the inverted quantities is sorted.
2523:
2524: 6. The main and cache queue locks
2525:
2526: 7. The cache queue
2527:
2528: The maintenance process begins by loading the status table from
2529: the configuration file. It then periodically checks each entry,
2530: to see if its refresh interval has elapsed. If not, it goes on to
2531: the next entry. If so, it performs different operations depending
2532: on the entry:
2533:
2534: If the entry is for zone 0, or the cache tree, the maintenance
2535: process checks to see if additions or deletions are required.
2536: Additions are acquired from the cache queue using the cache
2537: queue lock. Deletions are detected using TTL checks. If any
2538: changes are required, the maintenance process recalculates
2539: inversion data structures and then alters the cache tree under
2540: the protection of the main lock. Whenever the maintenance
2541: process modifies the cache tree, it resets the refresh interval
2542: to the minimum of the contained TTLs and the desired time
2543: interval for cache additions.
2544:
2545: If the entry is not zone 0, and the entry refers to a local
2546: file, the maintenance process checks to see if the file has
2547: been modified since its last load. If so the file is reloaded
2548: using the procedures specified under "Name server file
2549:
2550:
2551: Mockapetris [Page 42]
2552:
2553:
2554: RFC 883 November 1983
2555: Domain Names - Implementation and Specification
2556:
2557:
2558: loading". The refresh interval is reset to that specified in
2559: the SOA record if the file is a master file.
2560:
2561: If the entry is for a remote master file, the maintenance
2562: process checks for a new version using the procedure described
2563: in "Names server remote zone transfer".
2564:
2565: Name server file loading
2566:
2567: Master files are kept in text form for ease of editing by system
2568: maintainers. These files are not exchanged by name servers; name
2569: servers use the standard message format when transferring zones.
2570:
2571: Organizations that want to have a domain, but do not want to run a
2572: name server, can use these files to supply a domain definition to
2573: another organization that will run a name server for them. For
2574: example, if organization X wants a domain but not a name server,
2575: it can find another organization, Y, that has a name server and is
2576: willing to provide service for X. Organization X defines domain X
2577: via the master file format and ships a copy of the master file to
2578: organization Y via mail, FTP, or some other method. A system
2579: administrator at Y configures Y's name server to read in X's file
2580: and hence support the X domain. X can maintain the master file
2581: using a text editor and send new versions to Y for installation.
2582:
2583: These files have a simple line-oriented format, with one RR per
2584: line. Fields are separated by any combination of blanks and tab
2585: characters. Tabs are treated the same as spaces; in the following
2586: discussion the term "blank" means either a tab or a blank. A line
2587: can be either blank (and ignored), a RR, or a $INCLUDE line.
2588:
2589: If a RR line starts with a domain name, that domain name is used
2590: to specify the location in the domain space for the record, i.e.
2591: the owner. If a RR line starts with a blank, it is loaded into
2592: the location specified by the most recent location specifier.
2593:
2594: The location specifiers are assumed to be relative to some origin
2595: that is provided by the user of a file unless the location
2596: specifier contains the root label. This provides a convenient
2597: shorthand notation, and can also be used to prevent errors in
2598: master files from propagating into other zones. This feature is
2599: particularly useful for master files imported from other sites.
2600:
2601: An include line begins with $INCLUDE, starting at the first line
2602: position, and is followed by a local file name and an optional
2603: offset modifier. The filename follows the appropriate local
2604: conventions. The offset is one or more labels that are added to
2605: the offset in use for the file that contained the $INCLUDE. If
2606: the offset is omitted, the included file is loaded using the
2607:
2608:
2609: Mockapetris [Page 43]
2610:
2611:
2612: RFC 883 November 1983
2613: Domain Names - Implementation and Specification
2614:
2615:
2616: offset of the file that contained the $INCLUDE command. For
2617: example, a file being loaded at offset ARPA might contain the
2618: following lines:
2619:
2620: $INCLUDE <subsys>isi.data ISI
2621: $INCLUDE <subsys>addresses.data
2622:
2623: The first line would be interpreted to direct loading of the file
2624: <subsys>isi.data at offset ISI.ARPA. The second line would be
2625: interpreted as a request to load data at offset ARPA.
2626:
2627: Note that $INCLUDE commands do not cause data to be loaded into a
2628: different zone or tree; they are simply ways to allow data for a
2629: given zone to be organized in separate files. For example,
2630: mailbox data might be kept separately from host data using this
2631: mechanism.
2632:
2633: Resource records are entered as a sequence of fields corresponding
2634: to the owner name, TTL, CLASS, TYPE and RDATA components. (Note
2635: that this order is different from the order used in examples and
2636: the order used in the actual RRs; the given order allows easier
2637: parsing and defaulting.)
2638:
2639: The owner name is derived from the location specifier.
2640:
2641: The TTL field is optional, and is expressed as a decimal
2642: number. If omitted TTL defaults to zero.
2643:
2644: The CLASS field is also optional; if omitted the CLASS defaults
2645: to the most recent value of the CLASS field in a previous RR.
2646:
2647: The RDATA fields depend on the CLASS and TYPE of the RR. In
2648: general, the fields that make up RDATA are expressed as decimal
2649: numbers or as domain names. Some exceptions exist, and are
2650: documented in the RDATA definitions in Appendicies 2 and 3 of
2651: this memo.
2652:
2653: Because CLASS and TYPE fields don't contain any common
2654: identifiers, and because CLASS and TYPE fields are never decimal
2655: numbers, the parse is always unique.
2656:
2657: Because these files are text files several special encodings are
2658: necessary to allow arbitrary data to be loaded. In particular:
2659:
2660: . A free standing dot is used to refer to the current domain
2661: name.
2662:
2663: @ A free standing @ is used to denote the current origin.
2664:
2665:
2666:
2667: Mockapetris [Page 44]
2668:
2669:
2670: RFC 883 November 1983
2671: Domain Names - Implementation and Specification
2672:
2673:
2674: .. Two free standing dots represent the null domain name of
2675: the root.
2676:
2677: \X where X is any character other than a digit (0-9), is used
2678: to quote that character so that its special meaning does
2679: not apply. For example, "\." can be used to place a dot
2680: character in a label.
2681:
2682: \DDD where each D is a digit is the octet corresponding to the
2683: decimal number described by DDD. The resulting octet is
2684: assumed to be text and is not checked for special meaning.
2685:
2686: ( ) Parentheses are used to group data that crosses a line
2687: boundary. In effect, line terminations are not recognized
2688: within parentheses.
2689:
2690: ; Semicolon is used to start a comment; the remainder of the
2691: line is ignored.
2692:
2693: Name server file loading example
2694:
2695: A name server for F.ISI.ARPA , serving as an authority for the
2696: ARPA and ISI.ARPA domains, might use a boot file and two master
2697: files. The boot file initializes some non-authoritative data, and
2698: would be loaded without an origin:
2699:
2700: .. 9999999 IN NS B.ISI.ARPA
2701: 9999999 CS NS UDEL.CSNET
2702: B.ISI.ARPA 9999999 IN A 10.3.0.52
2703: UDEL.CSNET 9999999 CS A 302-555-0000
2704:
2705: This file loads non-authoritative data which provides the
2706: identities and addresses of root name servers. The first line
2707: contains a NS RR which is loaded at the root; the second line
2708: starts with a blank, and is loaded at the most recent location
2709: specifier, in this case the root; the third and fourth lines load
2710: RRs at B.ISI.ARPA and UDEL.CSNET, respectively. The timeouts are
2711: set to high values (9999999) to prevent this data from being
2712: discarded due to timeout.
2713:
2714: The first master file loads authoritative data for the ARPA
2715: domain. This file is designed to be loaded with an origin of
2716: ARPA, which allows the location specifiers to omit the trailing
2717: .ARPA labels.
2718:
2719:
2720:
2721:
2722:
2723:
2724:
2725: Mockapetris [Page 45]
2726:
2727:
2728: RFC 883 November 1983
2729: Domain Names - Implementation and Specification
2730:
2731:
2732: @ IN SOA F.ISI.ARPA Action.E.ISI.ARPA (
2733: 20 ; SERIAL
2734: 3600 ; REFRESH
2735: 600 ; RETRY
2736: 3600000; EXPIRE
2737: 60) ; MINIMUM
2738: NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA
2739: NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA
2740: MIT NS AI.MIT.ARPA; delegation to MIT name server
2741: ISI NS F.ISI.ARPA ; delegation to ISI name server
2742:
2743: UDEL MD UDEL.ARPA
2744: A 10.0.0.96
2745: NBS MD NBS.ARPA
2746: A 10.0.0.19
2747: DTI MD DTI.ARPA
2748: A 10.0.0.12
2749:
2750: AI.MIT A 10.2.0.6
2751: F.ISI A 10.2.0.52
2752:
2753: The first group of lines contains the SOA record and its
2754: parameters, and identifies name servers for this zone and for
2755: delegated zones. The Action.E.ISI.ARPA field is a mailbox
2756: specification for the responsible person for the zone, and is the
2757: domain name encoding of the mail destination [email protected].
2758: The second group specifies data for domain names within this zone.
2759: The last group has forward references for name server address
2760: resolution for AI.MIT.ARPA and F.ISI.ARPA. This data is not
2761: technically within the zone, and will only be used for additional
2762: record resolution for NS records used in referrals. However, this
2763: data is protected by the zone timeouts in the SOA, so it will
2764: persist as long as the NS references persist.
2765:
2766: The second master file defines the ISI.ARPA environment, and is
2767: loaded with an origin of ISI.ARPA:
2768:
2769: @ IN SOA F.ISI.ARPA Action\.ISI.E.ISI.ARPA (
2770: 20 ; SERIAL
2771: 7200 ; REFRESH
2772: 600 ; RETRY
2773: 3600000; EXPIRE
2774: 60) ; MINIMUM
2775: NS F.ISI.ARPA ; F.ISI.ARPA is a name server
2776: A A 10.1.0.32
2777: MD A.ISI.ARPA
2778: MF F.ISI.ARPA
2779: B A 10.3.0.52
2780: MD B.ISI.ARPA
2781:
2782:
2783: Mockapetris [Page 46]
2784:
2785:
2786: RFC 883 November 1983
2787: Domain Names - Implementation and Specification
2788:
2789:
2790: MF F.ISI.ARPA
2791: F A 10.2.0.52
2792: MD F.ISI.ARPA
2793: MF A.ISI.ARPA
2794: $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
2795:
2796: Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
2797:
2798: MOE MB F.ISI.ARPA
2799: LARRY MB A.ISI.ARPA
2800: CURLEY MB B.ISI.ARPA
2801: STOOGES MB B.ISI.ARPA
2802: MG MOE.ISI.ARPA
2803: MG LARRY.ISI.ARPA
2804: MG CURLEY.ISI.ARPA
2805:
2806: Note the use of the \ character in the SOA RR to specify the
2807: responsible person mailbox "[email protected]".
2808:
2809: Name server remote zone transfer
2810:
2811: When a name server needs to make an initial copy of a zone or test
2812: to see if a existing zone copy should be refreshed, it begins by
2813: attempting to open a virtual circuit to the foreign name server.
2814:
2815: If this open attempt fails, and this was an initial load attempt,
2816: it schedules a retry and exits. If this was a refresh operation,
2817: the name server tests the status table to see if the maximum
2818: holding time derived from the SOA EXPIRE field has elapsed. If
2819: not, the name server schedules a retry. If the maximum holding
2820: time has expired, the name server invalidates the zone in the
2821: status table, and scans all resource records tagged with this zone
2822: number. For each record it decrements TTL fields by the length of
2823: time since the data was last refreshed. If the new TTL value is
2824: negative, the record is deleted. If the TTL value is still
2825: positive, it moves the RR to the cache tree and schedules a retry.
2826:
2827: If the open attempt succeeds, the name server sends a query to the
2828: foreign name server in which QTYPE=SOA, QCLASS is set according to
2829: the status table information from the configuration file, and
2830: QNAME is set to the domain name of the zone of interest.
2831:
2832: The foreign name server will return either a SOA record indicating
2833: that it has the zone or an error. If an error is detected, the
2834: virtual circuit is closed, and the failure is treated in the same
2835: way as if the open attempt failed.
2836:
2837: If the SOA record is returned and this was a refresh, rather than
2838: an initial load of the zone, the name server compares the SERIAL
2839:
2840:
2841: Mockapetris [Page 47]
2842:
2843:
2844: RFC 883 November 1983
2845: Domain Names - Implementation and Specification
2846:
2847:
2848: field in the new SOA record with the SERIAL field in the SOA
2849: record of the existing zone copy. If these values match, the zone
2850: has not been updated since the last copy and hence there is no
2851: reason to recopy the zone. In this case the name server resets
2852: the times in the existing SOA record and closes the virtual
2853: circuit to complete the operation.
2854:
2855: If this is initial load, or the SERIAL fields were different, the
2856: name server requests a copy of the zone by sending the foreign
2857: name server an AXFR query which specifies the zone by its QCLASS
2858: and QNAME fields.
2859:
2860: When the foreign name server receives the AXFR request, it sends
2861: each node from the zone to the requestor in a separate message.
2862: It begins with the node that contains the SOA record, walks the
2863: tree in breadth-first order, and completes the transfer by
2864: resending the node containing the SOA record.
2865:
2866: Several error conditions are possible:
2867:
2868: If the AXFR request cannot be matched to a SOA, the foreign
2869: name server will return a single message in response that does
2870: not contain the AXFR request. (The normal SOA query preceding
2871: the AXFR is designed to avoid this condition, but it is still
2872: possible.)
2873:
2874: The foreign name server can detect an internal error or detect
2875: some other condition (e.g. system going down, out of resources,
2876: etc.) that forces the transfer to be aborted. If so, it sends
2877: a message with the "Server failure" condition set. If the AXFR
2878: can be immediately retried with some chance of success, it
2879: leaves the virtual open; otherwise it initiates a close.
2880:
2881: If the foreign name server doesn't wish to perform the
2882: operation for policy reasons (i.e. the system administrator
2883: wishes to forbid zone copies), the foreign server returns a
2884: "Refused" condition.
2885:
2886: The requestor receives these records and builds a new tree. This
2887: tree is not yet in the status table, so its data are not used to
2888: process queries. The old copy of the zone, if any, may be used to
2889: satisfy request while the transfer is in progress.
2890:
2891: When the requestor receives the second copy of the SOA node, it
2892: compares the SERIAL field in the first copy of the SOA against the
2893: SERIAL field in the last copy of the SOA record. If these don't
2894: match, the foreign server updated its zone while the transfer was
2895: in progress. In this case the requestor repeats the AXFR request
2896: to acquire the newer version.
2897:
2898:
2899: Mockapetris [Page 48]
2900:
2901:
2902: RFC 883 November 1983
2903: Domain Names - Implementation and Specification
2904:
2905:
2906: If the AXFR transfer eventually succeeds, the name server closes
2907: the virtual circuit and and creates new versions of inversion data
2908: structures for this zone. When this operation is complete, the
2909: name server acquires the main lock in write mode and then replaces
2910: any old copy of the zone and inversion data structures with new
2911: ones. The name server then releases the main lock, and can
2912: reclaim the storage used by the old copy.
2913:
2914: If an error occurs during the AXFR transfer, the name server can
2915: copy any partial information into its cache tree if it wishes,
2916: although it will not normally do so if the zone transfer was a
2917: refresh rather than an initial load.
2918:
2919:
2920:
2921:
2922:
2923:
2924:
2925:
2926:
2927:
2928:
2929:
2930:
2931:
2932:
2933:
2934:
2935:
2936:
2937:
2938:
2939:
2940:
2941:
2942:
2943:
2944:
2945:
2946:
2947:
2948:
2949:
2950:
2951:
2952:
2953:
2954:
2955:
2956:
2957: Mockapetris [Page 49]
2958:
2959:
2960: RFC 883 November 1983
2961: Domain Names - Implementation and Specification
2962:
2963:
2964: RESOLVER ALGORITHMS
2965:
2966: Operations
2967:
2968: Resolvers have a great deal of latitude in the semantics they
2969: allow in user calls. For example, a resolver might support
2970: different user calls that specify whether the returned information
2971: must be from and authoritative name server or not. Resolvers are
2972: also responsible for enforcement of any local restrictions on
2973: access, etc.
2974:
2975: In any case, the resolver will transform the user query into a
2976: number of shared database accesses and queries to remote name
2977: servers. When a user requests a resource associated with a
2978: particular domain name, the resolver will execute the following
2979: steps:
2980:
2981: 1. The resolver first checks the local shared database, if any,
2982: for the desired information. If found, it checks the
2983: applicable timeout. If the timeout check succeeds, the
2984: information is used to satisfy the user request. If not, the
2985: resolver goes to step 2.
2986:
2987: 2. In this step, the resolver consults the shared database for the
2988: name server that most closely matches the domain name in the
2989: user query. Multiple redundant name servers may be found. The
2990: resolver goes to step 3.
2991:
2992: 3. In this step the resolver chooses one of the available name
2993: servers and sends off a query. If the query fails, it tries
2994: another name server. If all fail, an error indication is
2995: returned to the user. If a reply is received the resolver adds
2996: the returned RRs to its database and goes to step 4.
2997:
2998: 4. In this step, the resolver interprets the reply. If the reply
2999: contains the desired information, the resolver returns the
3000: information to the user. The the reply indicates that the
3001: domain name in the user query doesn't exist, then the resolver
3002: returns an error to the user. If the reply contains a
3003: transient name server failure, the resolver can either wait and
3004: retry the query or go back to step 3 and try a different name
3005: server. If the reply doesn't contain the desired information,
3006: but does contain a pointer to a closer name server, the
3007: resolver returns to step 2, where the closer name servers will
3008: be queried.
3009:
3010: Several modifications to this algorithm are possible. A resolver
3011: may not support a local cache and instead only cache information
3012: during the course of a single user request, discarding it upon
3013:
3014:
3015: Mockapetris [Page 50]
3016:
3017:
3018: RFC 883 November 1983
3019: Domain Names - Implementation and Specification
3020:
3021:
3022: completion. The resolver may also find that a datagram reply was
3023: truncated, and open a virtual circuit so that the complete reply
3024: can be recovered.
3025:
3026: Inverse and completion queries must be treated in an
3027: environment-sensitive manner, because the domain system doesn't
3028: provide a method for guaranteeing that it can locate the correct
3029: information. The typical choice will be to configure a resolver
3030: to use a particular set of known name servers for inverse queries.
3031:
3032:
3033:
3034:
3035:
3036:
3037:
3038:
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: Mockapetris [Page 51]
3074:
3075:
3076: RFC 883 November 1983
3077: Domain Names - Implementation and Specification
3078:
3079:
3080: DOMAIN SUPPORT FOR MAIL
3081:
3082: Introduction
3083:
3084: Mail service is a particularly sensitive issue for users of the
3085: domain system because of the lack of a consistent system for
3086: naming mailboxes and even hosts, and the need to support continued
3087: operation of existing services. This section discusses an
3088: evolutionary approach for adding consistent domain name support
3089: for mail.
3090:
3091: The crucial issue is deciding on the types of binding to be
3092: supported. Most mail systems specify a mail destination with a
3093: two part construct such as X@Y. The left hand side, X, is an
3094: string, often a user or account, and Y is a string, often a host.
3095: This section refers to the part on the left, i.e. X, as the local
3096: part, and refers to the part on the right, i.e. Y, as the global
3097: part.
3098:
3099: Most existing mail systems route mail based on the global part; a
3100: mailer with mail to deliver to X@Y will decide on the host to be
3101: contacted using only Y. We refer to this type of binding as
3102: "agent binding".
3103:
3104: For example, mail addressed to Mockapetris@ISIF is delivered to
3105: host USC-ISIF (USC-ISIF is the official name for the host
3106: specified by nickname ISIF).
3107:
3108: More sophisticated mail systems use both the local and global
3109: parts, i.e. both X and Y to determine which host should receive
3110: the mail. These more sophisticated systems usually separate the
3111: binding of the destination to the host from the actual delivery.
3112: This allows the global part to be a generic name rather than
3113: constraining it to a single host. We refer to this type of
3114: binding as "mailbox binding".
3115:
3116: For example, mail addressed to Mockapetris@ISI might be bound
3117: to host F.ISI.ARPA, and subsequently delivered to that host,
3118: while mail for Cohen@ISI might be bound to host B.ISI.ARPA.
3119:
3120: The domain support for mail consists of two levels of support,
3121: corresponding to these two binding models.
3122:
3123: The first level, agent binding, is compatible with existing
3124: ARPA Internet mail procedures and uses maps a global part onto
3125: one or more hosts that will accept the mail. This type of
3126: binding uses the MAILA QTYPE.
3127:
3128: The second level, mailbox binding, offers extended services
3129:
3130:
3131: Mockapetris [Page 52]
3132:
3133:
3134: RFC 883 November 1983
3135: Domain Names - Implementation and Specification
3136:
3137:
3138: that map a local part and a global part onto one or more sets
3139: of data via the MAILB QTYPE. The sets of data include hosts
3140: that will accept the mail, mailing list members (mail groups),
3141: and mailboxes for reporting errors or requests to change a mail
3142: group.
3143:
3144: The domain system encodes the global part of a mail destination as
3145: a domain name and uses dots in the global part to separate labels
3146: in the encoded domain name. The domain system encodes the local
3147: part of a mail destination as a single label, and any dots in this
3148: part are simply copied into the label. The domain system forms a
3149: complete mail destination as the local label concatenated to the
3150: domain string for the global part. We call this a mailbox.
3151:
3152: For example, the mailbox [email protected] has a global
3153: domain name of three labels, F.ISI.ARPA. The domain name
3154: encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The
3155: mailbox [email protected] has the same domain name for
3156: the global part and a 4 label domain name for the mailbox of
3157: Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label,
3158: its merely used to denote the "quoted" dot).
3159:
3160: It is anticipated that the Internet system will adopt agent
3161: binding as part of the initial implementation of the domain
3162: system, and that mailbox binding will eventually become the
3163: preferred style as organizations convert their mail systems to the
3164: new style. To facilitate this approach, the domain information
3165: for these two binding styles is organized to allow a requestor to
3166: determine which types of support are available, and the
3167: information is kept in two disjoint classes.
3168:
3169: Agent binding
3170:
3171: In agent binding, a mail system uses the global part of the mail
3172: destination as a domain name, with dots denoting structure. The
3173: domain name is resolved using a MAILA query which return MF and MD
3174: RRs to specify the domain name of the appropriate host to receive
3175: the mail. MD (Mail delivery) RRs specify hosts that are expected
3176: to have the mailbox in question; MF (Mail forwarding) RRs specify
3177: hosts that are expected to be intermediaries willing to accept the
3178: mail for eventual forwarding. The hosts are hints, rather than
3179: definite answers, since the query is made without the full mail
3180: destination specification.
3181:
3182: For example, mail for [email protected] would result in a
3183: query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return
3184: two RRs:
3185:
3186:
3187:
3188:
3189: Mockapetris [Page 53]
3190:
3191:
3192: RFC 883 November 1983
3193: Domain Names - Implementation and Specification
3194:
3195:
3196: F.ISI.ARPA MD IN F.ISI.ARPA
3197: F.ISI.ARPA MF IN A.ISI.ARPA
3198:
3199: The mailer would interpret these to mean that the mail agent on
3200: F.ISI.ARPA should be able to deliver the mail directly, but that
3201: A.ISI.ARPA is willing to accept the mail for probable forwarding.
3202:
3203: Using this system, an organization could implement a system that
3204: uses organization names for global parts, rather than the usual
3205: host names, but all mail for the organization would be routed the
3206: same, regardless of its local part. Hence and organization with
3207: many hosts would expect to see many forwarding operations.
3208:
3209: Mailbox binding
3210:
3211: In mailbox binding, the mailer uses the entire mail destination
3212: specification to construct a domain name. The encoded domain name
3213: for the mailbox is used as the QNAME field in a QTYPE=MAILB query.
3214:
3215: Several outcomes are possible for this query:
3216:
3217: 1. The query can return a name error indicating that the mailbox
3218: does not exist as a domain name.
3219:
3220: In the long term this would indicate that the specified mailbox
3221: doesn't exist. However, until the use of mailbox binding is
3222: universal, this error condition should be interpreted to mean
3223: that the organization identified by the global part does not
3224: support mailbox binding. The appropriate procedure is to
3225: revert to agent binding at this point.
3226:
3227: 2. The query can return a Mail Rename (MR) RR.
3228:
3229: The MR RR carries new mailbox specification in its RDATA field.
3230: The mailer should replace the old mailbox with the new one and
3231: retry the operation.
3232:
3233: 3. The query can return a MB RR.
3234:
3235: The MB RR carries a domain name for a host in its RDATA field.
3236: The mailer should deliver the message to that host via whatever
3237: protocol is applicable, e.g. SMTP.
3238:
3239: 4. The query can return one or more Mail Group (MG) RRs.
3240:
3241: This condition means that the mailbox was actually a mailing
3242: list or mail group, rather than a single mailbox. Each MG RR
3243: has a RDATA field that identifies a mailbox that is a member of
3244:
3245:
3246:
3247: Mockapetris [Page 54]
3248:
3249:
3250: RFC 883 November 1983
3251: Domain Names - Implementation and Specification
3252:
3253:
3254: the group. The mailer should deliver a copy of the message to
3255: each member.
3256:
3257: 5. The query can return a MB RR as well as one or more MG RRs.
3258:
3259: This condition means the the mailbox was actually a mailing
3260: list. The mailer can either deliver the message to the host
3261: specified by the MB RR, which will in turn do the delivery to
3262: all members, or the mailer can use the MG RRs to do the
3263: expansion itself.
3264:
3265: In any of these cases, the response may include a Mail Information
3266: (MINFO) RR. This RR is usually associated with a mail group, but
3267: is legal with a MB. The MINFO RR identifies two mailboxes. One
3268: of these identifies a responsible person for the original mailbox
3269: name. This mailbox should be used for requests to be added to a
3270: mail group, etc. The second mailbox name in the MINFO RR
3271: identifies a mailbox that should receive error messages for mail
3272: failures. This is particularly appropriate for mailing lists when
3273: errors in member names should be reported to a person other than
3274: the one who sends a message to the list. New fields may be added
3275: to this RR in the future.
3276:
3277:
3278:
3279:
3280:
3281:
3282:
3283:
3284:
3285:
3286:
3287:
3288:
3289:
3290:
3291:
3292:
3293:
3294:
3295:
3296:
3297:
3298:
3299:
3300:
3301:
3302:
3303:
3304:
3305: Mockapetris [Page 55]
3306:
3307:
3308: RFC 883 November 1983
3309: Domain Names - Implementation and Specification
3310:
3311:
3312: Appendix 1 - Domain Name Syntax Specification
3313:
3314: The preferred syntax of domain names is given by the following BNF
3315: rules. Adherence to this syntax will result in fewer problems with
3316: many applications that use domain names (e.g., mail, TELNET). Note
3317: that some applications use domain names containing binary information
3318: and hence do not follow this syntax.
3319:
3320: <domain> ::= <subdomain> | " "
3321:
3322: <subdomain> ::= <label> | <subdomain> "." <label>
3323:
3324: <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
3325:
3326: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
3327:
3328: <let-dig-hyp> ::= <let-dig> | "-"
3329:
3330: <let-dig> ::= <letter> | <digit>
3331:
3332: <letter> ::= any one of the 52 alphabetic characters A through Z
3333: in upper case and a through z in lower case
3334:
3335: <digit> ::= any one of the ten digits 0 through 9
3336:
3337: Note that while upper and lower case letters are allowed in domain
3338: names no significance is attached to the case. That is, two names
3339: with the same spelling but different case are to be treated as if
3340: identical.
3341:
3342: The labels must follow the rules for ARPANET host names. They must
3343: start with a letter, end with a letter or digit, and have as interior
3344: characters only letters, digits, and hyphen. There are also some
3345: restrictions on the length. Labels must be 63 characters or less.
3346:
3347: For example, the following strings identify hosts in the ARPA
3348: Internet:
3349:
3350: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
3351:
3352:
3353:
3354:
3355:
3356:
3357:
3358:
3359:
3360:
3361:
3362:
3363: Mockapetris [Page 56]
3364:
3365:
3366: RFC 883 November 1983
3367: Domain Names - Implementation and Specification
3368:
3369:
3370: Appendix 2 - Field formats and encodings
3371:
3372: +-----------------------------------------------+
3373: | |
3374: | ***** WARNING ***** |
3375: | |
3376: | The following formats are preliminary and |
3377: | are included for purposes of explanation only.|
3378: | In particular, new RR types will be added, |
3379: | and the size, position, and encoding of |
3380: | fields are subject to change. |
3381: | |
3382: +-----------------------------------------------+
3383:
3384: TYPE values
3385:
3386: TYPE fields are used in resource records. Note that these types
3387: are not the same as the QTYPE fields used in queries, although the
3388: functions are often similar.
3389:
3390: TYPE value meaning
3391:
3392: A 1 a host address
3393:
3394: NS 2 an authoritative name server
3395:
3396: MD 3 a mail destination
3397:
3398: MF 4 a mail forwarder
3399:
3400: CNAME 5 the canonical name for an alias
3401:
3402: SOA 6 marks the start of a zone of authority
3403:
3404: MB 7 a mailbox domain name
3405:
3406: MG 8 a mail group member
3407:
3408: MR 9 a mail rename domain name
3409:
3410: NULL 10 a null RR
3411:
3412: WKS 11 a well known service description
3413:
3414: PTR 12 a domain name pointer
3415:
3416: HINFO 13 host information
3417:
3418: MINFO 14 mailbox or mail list information
3419:
3420:
3421: Mockapetris [Page 57]
3422:
3423:
3424: RFC 883 November 1983
3425: Domain Names - Implementation and Specification
3426:
3427:
3428: QTYPE values
3429:
3430: QTYPE fields appear in the question part of a query. They include
3431: the values of TYPE with the following additions:
3432:
3433: AXFR 252 A request for a transfer of an entire zone of authority
3434:
3435: MAILB 253 A request for mailbox-related records (MB, MG or MR)
3436:
3437: MAILA 254 A request for mail agent RRs (MD and MF)
3438:
3439: * 255 A request for all records
3440:
3441: CLASS values
3442:
3443: CLASS fields appear in resource records
3444:
3445: CLASS value meaning
3446:
3447: IN 1 the ARPA Internet
3448:
3449: CS 2 the computer science network (CSNET)
3450:
3451: QCLASS values
3452:
3453: QCLASS fields appear in the question section of a query. They
3454: include the values of CLASS with the following additions:
3455:
3456: * 255 any class
3457:
3458:
3459:
3460:
3461:
3462:
3463:
3464:
3465:
3466:
3467:
3468:
3469:
3470:
3471:
3472:
3473:
3474:
3475:
3476:
3477:
3478:
3479: Mockapetris [Page 58]
3480:
3481:
3482: RFC 883 November 1983
3483: Domain Names - Implementation and Specification
3484:
3485:
3486: Standard resource record formats
3487:
3488: All RRs have the same top level format shown below:
3489:
3490: 1 1 1 1 1 1
3491: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
3492: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3493: | |
3494: / /
3495: / NAME /
3496: | |
3497: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3498: | TYPE |
3499: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3500: | CLASS |
3501: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3502: | TTL |
3503: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3504: | RDLENGTH |
3505: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
3506: / RDATA /
3507: / /
3508: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3509:
3510: where:
3511:
3512: NAME - a compressed domain name to which this resource
3513: record pertains.
3514:
3515: TYPE - two octets containing one of the RR type codes
3516: defined in Appendix 2. This field specifies the
3517: meaning of the data in the RDATA field.
3518:
3519: CLASS - two octets which specifies the class of the data in
3520: the RDATA field.
3521:
3522: TTL - a 16 bit signed integer that specifies the time
3523: interval that the resource record may be cached
3524: before the source of the information should again be
3525: consulted. Zero values are interpreted to mean that
3526: the RR can only be used for the transaction in
3527: progress, and should not be cached. For example, SOA
3528: records are always distributed with a zero TTL to
3529: prohibit caching. Zero values can also be used for
3530: extremely volatile data.
3531:
3532: RDLENGTH- an unsigned 16 bit integer that specifies the length
3533: in octets of the RDATA field.
3534:
3535:
3536:
3537: Mockapetris [Page 59]
3538:
3539:
3540: RFC 883 November 1983
3541: Domain Names - Implementation and Specification
3542:
3543:
3544: RDATA - a variable length string of octets that describes the
3545: resource. The format of this information varies
3546: according to the TYPE and CLASS of the resource
3547: record.
3548:
3549: The format of the RDATA field is standard for all classes for the
3550: RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and
3551: NULL. These formats are shown below together with the appropriate
3552: additional section RR processing.
3553:
3554: CNAME RDATA format
3555:
3556: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3557: / CNAME /
3558: / /
3559: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3560:
3561: where:
3562:
3563: CNAME - A compressed domain name which specifies that the
3564: domain name of the RR is an alias for a canonical
3565: name specified by CNAME.
3566:
3567: CNAME records cause no additional section processing. The
3568: RDATA section of a CNAME line in a master file is a standard
3569: printed domain name.
3570:
3571: HINFO RDATA format
3572:
3573: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3574: / CPU /
3575: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3576: / OS /
3577: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3578:
3579: where:
3580:
3581: CPU - A character string which specifies the CPU type. The
3582: character string is represented as a single octet
3583: length followed by that number of characters. The
3584: following standard strings are defined:.
3585:
3586: PDP-11/70 C/30 C/70 VAX-11/780
3587: H-316 H-516 DEC-2060 DEC-1090T
3588: ALTO IBM-PC IBM-PC/XT PERQ
3589: IBM-360/67 IBM-370/145
3590:
3591: OS - A character string which specifies the operating system
3592: type. The character string is represented as a single octet
3593:
3594:
3595: Mockapetris [Page 60]
3596:
3597:
3598: RFC 883 November 1983
3599: Domain Names - Implementation and Specification
3600:
3601:
3602: length followed by that number of characters. The following
3603: standard types are defined:.
3604:
3605: ASP AUGUST BKY CCP
3606: DOS/360 ELF EPOS EXEC-8
3607: GCOS GPOS ITS INTERCOM
3608: KRONOS MCP MOS MPX-RT
3609: MULTICS MVT NOS NOS/BE
3610: OS/MVS OS/MVT RIG RSX11
3611: RSX11M RT11 SCOPE SIGNAL
3612: SINTRAN TENEX TOPS10 TOPS20
3613: TSS UNIX VM/370 VM/CMS
3614: VMS WAITS
3615:
3616: HINFO records cause no additional section processing.
3617:
3618: HINFO records are used to acquire general information about a
3619: host. The main use is for protocols such as FTP that can use
3620: special procedures when talking between machines or operating
3621: systems of the same type.
3622:
3623: MB RDATA format
3624:
3625: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3626: / MADNAME /
3627: / /
3628: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3629:
3630: where:
3631:
3632: MADNAME - A compressed domain name which specifies a host which
3633: has the specified mailbox.
3634:
3635: MB records cause additional section processing which looks up
3636: an A type record corresponding to MADNAME. The RDATA section
3637: of a MB line in a master file is a standard printed domain
3638: name.
3639:
3640: MD RDATA format
3641:
3642: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3643: / MADNAME /
3644: / /
3645: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3646:
3647: where:
3648:
3649: MADNAME - A compressed domain name which specifies a host which
3650:
3651:
3652:
3653: Mockapetris [Page 61]
3654:
3655:
3656: RFC 883 November 1983
3657: Domain Names - Implementation and Specification
3658:
3659:
3660: has a mail agent for the domain which should be able
3661: to deliver mail for the domain.
3662:
3663: MD records cause additional section processing which looks up
3664: an A type record corresponding to MADNAME. The RDATA section
3665: of a MD line in a master file is a standard printed domain
3666: name.
3667:
3668: MF RDATA format
3669:
3670: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3671: / MADNAME /
3672: / /
3673: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3674:
3675: where:
3676:
3677: MADNAME - A compressed domain name which specifies a host which
3678: has a mail agent for the domain which will accept
3679: mail for forwarding to the domain.
3680:
3681: MF records cause additional section processing which looks up
3682: an A type record corresponding to MADNAME. The RDATA section
3683: of a MF line in a master file is a standard printed domain
3684: name.
3685:
3686: MG RDATA format
3687:
3688: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3689: / MGMNAME /
3690: / /
3691: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3692:
3693: where:
3694:
3695: MGMNAME - A compressed domain name which specifies a mailbox
3696: which is a member of the mail group specified by the
3697: domain name.
3698:
3699: MF records cause no additional section processing. The RDATA
3700: section of a MF line in a master file is a standard printed
3701: domain name.
3702:
3703:
3704:
3705:
3706:
3707:
3708:
3709:
3710:
3711: Mockapetris [Page 62]
3712:
3713:
3714: RFC 883 November 1983
3715: Domain Names - Implementation and Specification
3716:
3717:
3718: MINFO RDATA format
3719:
3720: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3721: / RMAILBX /
3722: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3723: / EMAILBX /
3724: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3725:
3726: where:
3727:
3728: RMAILBX - A compressed domain name which specifies a mailbox
3729: which is responsible for the mailing list or mailbox.
3730: If this domain name names the root, the owner of the
3731: MINFO RR is responsible for itself. Note that many
3732: existing mailing lists use a mailbox X-request for
3733: the RMAILBX field of mailing list X, e.g.
3734: Msgroup-request for Msgroup. This field provides a
3735: more general mechanism.
3736:
3737: EMAILBX - A compressed domain name which specifies a mailbox
3738: which is to receive error messages related to the
3739: mailing list or mailbox specified by the owner of the
3740: MINFO RR (similar to the ERRORS-TO: field which has
3741: been proposed). If this domain name names the root,
3742: errors should be returned to the sender of the
3743: message.
3744:
3745: MINFO records cause no additional section processing. Although
3746: these records can be associated with a simple mailbox, they are
3747: usually used with a mailing list. The MINFO section of a MF
3748: line in a master file is a standard printed domain name.
3749:
3750: MR RDATA format
3751:
3752: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3753: / NEWNAME /
3754: / /
3755: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3756:
3757: where:
3758:
3759: NEWNAME - A compressed domain name which specifies a mailbox
3760: which is the proper rename of the specified mailbox.
3761:
3762: MR records cause no additional section processing. The RDATA
3763: section of a MR line in a master file is a standard printed
3764: domain name.
3765:
3766:
3767:
3768:
3769: Mockapetris [Page 63]
3770:
3771:
3772: RFC 883 November 1983
3773: Domain Names - Implementation and Specification
3774:
3775:
3776: NULL RDATA format
3777:
3778: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3779: / <anything> /
3780: / /
3781: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3782:
3783: Anything at all may be in the RDATA field so long as it is
3784: 65535 octets or less.
3785:
3786: NULL records cause no additional section processing. NULL RRs
3787: are not allowed in master files.
3788:
3789: NS RDATA format
3790:
3791: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3792: / NSDNAME /
3793: / /
3794: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3795:
3796: where:
3797:
3798: NSDNAME - A compressed domain name which specifies a host which
3799: has a name server for the domain.
3800:
3801: NS records cause both the usual additional section processing
3802: to locate a type A record, and a special search of the zone in
3803: which they reside. The RDATA section of a NS line in a master
3804: file is a standard printed domain name.
3805:
3806: PTR RDATA format
3807:
3808: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3809: / PTRDNAME /
3810: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3811:
3812: where:
3813:
3814: PTRDNAME - A compressed domain name which points to some
3815: location in the domain name space.
3816:
3817: PTR records cause no additional section processing. These RRs
3818: are used in special domains to point to some other location in
3819: the domain space. These records are simple data, and don't
3820: imply any special processing similar to that performed by
3821: CNAME, which identifies aliases. Appendix 3 discusses the use
3822: of these records in the ARPA Internet address domain.
3823:
3824:
3825:
3826:
3827: Mockapetris [Page 64]
3828:
3829:
3830: RFC 883 November 1983
3831: Domain Names - Implementation and Specification
3832:
3833:
3834: SOA RDATA format
3835:
3836: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3837: / MNAME /
3838: / /
3839: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3840: / RNAME /
3841: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3842: | SERIAL |
3843: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3844: | REFRESH |
3845: | |
3846: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3847: | RETRY |
3848: | |
3849: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3850: | EXPIRE |
3851: | |
3852: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3853: | MINIMUM |
3854: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3855:
3856: where:
3857:
3858: MNAME - The domain name of the name server that was the
3859: original source of data for this zone.
3860:
3861: RNAME - A domain name which specifies the mailbox of the
3862: person responsible for this zone.
3863:
3864: SERIAL - The unsigned 16 bit version number of the of the
3865: original copy of the zone. This value wraps and
3866: should be compared using sequence space arithmetic.
3867:
3868: REFRESH - The unsigned 32 bit time interval before the zone
3869: should be refreshed.
3870:
3871: RETRY - The unsigned 32 bit time interval that should elapse
3872: before a failed refresh should be retried.
3873:
3874: EXPIRE - A 32 bit time value that specifies the upper limit on
3875: the time interval that can elapse before the zone is
3876: no longer authoritative.
3877:
3878: MINIMUM - The unsigned 16 bit minimum TTL field that should be
3879: exported with any RR from this zone (other than the
3880: SOA itself).
3881:
3882: SOA records cause no additional section processing. The RDATA
3883:
3884:
3885: Mockapetris [Page 65]
3886:
3887:
3888: RFC 883 November 1983
3889: Domain Names - Implementation and Specification
3890:
3891:
3892: section of a SOA line in a master file is a standard printed
3893: domain name for MNAME, a standard X@Y mailbox specification for
3894: RNAME, and decimal numbers for the remaining parameters.
3895:
3896: All times are in units of seconds.
3897:
3898: Most of these fields are pertinent only for name server
3899: maintenance operations. However, MINIMUM is used in all query
3900: operations that retrieve RRs from a zone. Whenever a RR is
3901: sent in a response to a query, the TTL field is set to the
3902: maximum of the TTL field from the RR and the MINIMUM field in
3903: the appropriate SOA. Thus MINIMUM is a lower bound on the TTL
3904: field for all RRs in a zone. RRs in a zone are never discarded
3905: due to timeout unless the whole zone is deleted. This prevents
3906: partial copies of zones.
3907:
3908:
3909:
3910:
3911:
3912:
3913:
3914:
3915:
3916:
3917:
3918:
3919:
3920:
3921:
3922:
3923:
3924:
3925:
3926:
3927:
3928:
3929:
3930:
3931:
3932:
3933:
3934:
3935:
3936:
3937:
3938:
3939:
3940:
3941:
3942:
3943: Mockapetris [Page 66]
3944:
3945:
3946: RFC 883 November 1983
3947: Domain Names - Implementation and Specification
3948:
3949:
3950: Appendix 3 - Internet specific field formats and operations
3951:
3952: Message transport
3953:
3954: The Internet supports name server access using TCP [10] on server
3955: port 53 (decimal) as well as datagram access using UDP [11] on UDP
3956: port 53 (decimal). Messages sent over TCP virtual circuits are
3957: preceded by an unsigned 16 bit length field which describes the
3958: length of the message, excluding the length field itself.
3959:
3960: +-----------------------------------------------+
3961: | |
3962: | ***** WARNING ***** |
3963: | |
3964: | The following formats are preliminary and |
3965: | are included for purposes of explanation only.|
3966: | In particular, new RR types will be added, |
3967: | and the size, position, and encoding of |
3968: | fields are subject to change. |
3969: | |
3970: +-----------------------------------------------+
3971:
3972: A RDATA format
3973:
3974: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3975: | ADDRESS |
3976: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3977:
3978: where:
3979:
3980: ADDRESS - A 32 bit ARPA internet address
3981:
3982: Hosts that have multiple ARPA Internet addresses will have
3983: multiple A records.
3984:
3985: A records cause no additional section processing. The RDATA
3986: section of an A line in a master file is an Internet address
3987: expressed as four decimal numbers separated by dots without any
3988: imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
3989:
3990:
3991:
3992:
3993:
3994:
3995:
3996:
3997:
3998:
3999:
4000:
4001: Mockapetris [Page 67]
4002:
4003:
4004: RFC 883 November 1983
4005: Domain Names - Implementation and Specification
4006:
4007:
4008: WKS RDATA format
4009:
4010: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4011: | ADDRESS |
4012: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4013: | PROTOCOL | |
4014: +--+--+--+--+--+--+--+--+ |
4015: | |
4016: / <BIT MAP> /
4017: / /
4018: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4019:
4020: where:
4021:
4022: ADDRESS - An 32 bit ARPA Internet address
4023:
4024: PROTOCOL - An 8 bit IP protocol number
4025:
4026: <BIT MAP> - A variable length bit map. The bit map must be a
4027: multiple of 8 bits long.
4028:
4029: The WKS record is used to describe the well known services
4030: supported by a particular protocol on a particular internet
4031: address. The PROTOCOL field specifies an IP protocol number, and
4032: the bit map has one bit per port of the specified protocol. The
4033: first bit corresponds to port 0, the second to port 1, etc. If
4034: less than 256 bits are present, the remainder are assumed to be
4035: zero. The appropriate values for ports and protocols are
4036: specified in [13].
4037:
4038: For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
4039: port 25 (SMTP). If this bit is set, a SMTP server should be
4040: listening on TCP port 25; if zero, SMTP service is not supported
4041: on the specified address.
4042:
4043: The anticipated use of WKS RRs is to provide availability
4044: information for servers for TCP and UDP. If a server supports
4045: both TCP and UDP, or has multiple Internet addresses, then
4046: multiple WKS RRs are used.
4047:
4048: WKS RRs cause no additional section processing. The RDATA section
4049: of a WKS record consists of a decimal protocol number followed by
4050: mnemonic identifiers which specify bits to be set to 1.
4051:
4052: IN-ADDR special domain
4053:
4054: The ARPA internet uses a special domain to support gateway
4055: location and ARPA Internet address to host mapping. The intent of
4056: this domain is to allow queries to locate all gateways on a
4057:
4058:
4059: Mockapetris [Page 68]
4060:
4061:
4062: RFC 883 November 1983
4063: Domain Names - Implementation and Specification
4064:
4065:
4066: particular network in the ARPA Internet, and also to provide a
4067: guaranteed method to perform host address to host name mapping.
4068:
4069: Note that both of these services are similar to functions that
4070: could be performed by inverse queries; the difference is that this
4071: part of the domain name space is structured according to address,
4072: and hence can guarantee that the appropriate data can be located
4073: without an exhaustive search of the domain space. It is
4074: anticipated that the special tree will be used by ARPA Internet
4075: resolvers for all gateway location services, but that address to
4076: name resolution will be performed by first trying the inverse
4077: query on the local name server database followed by a query in the
4078: special space if the inverse query fails.
4079:
4080: The domain is a top level domain called IN-ADDR whose substructure
4081: follows the ARPA Internet addressing structure.
4082:
4083: Domain names in the IN-ADDR domain are defined to have up to four
4084: labels in addition to the IN-ADDR label. Each label is a
4085: character string which expresses a decimal value in the range
4086: 0-255 (with leading zeros omitted except in the case of a zero
4087: octet which is represented by a single zero). These labels
4088: correspond to the 4 octets of an ARPA Internet address.
4089:
4090: Host addresses are represented by domain names that have all four
4091: labels specified. Thus data for ARPA Internet address 10.2.0.52
4092: is located at domain name 52.0.2.10.IN-ADDR. The reversal, though
4093: awkward to read, allows zones to follow the natural grouping of
4094: hosts within networks. For example, 10.IN-ADDR can be a zone
4095: containing data for the ARPANET, while 26.IN-ADDR can be a
4096: separate zone for MILNET. Address nodes are used to hold pointers
4097: to primary host names in the normal domain space.
4098:
4099: Network addresses correspond to some of the non-terminal nodes in
4100: the IN-ADDR tree, since ARPA Internet network numbers are either
4101: 1, 2, or 3 octets. Network nodes are used to hold pointers to
4102: primary host names (which happen to be gateways) in the normal
4103: domain space. Since a gateway is, by definition, on more than one
4104: network, it will typically have two or more network nodes that
4105: point at the gateway. Gateways will also have host level pointers
4106: at their fully qualified addresses.
4107:
4108: Both the gateway pointers at network nodes and the normal host
4109: pointers at full address nodes use the PTR RR to point back to the
4110: primary domain names of the corresponding hosts.
4111:
4112: For example, part of the IN-ADDR domain will contain information
4113: about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and
4114: MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses
4115:
4116:
4117: Mockapetris [Page 69]
4118:
4119:
4120: RFC 883 November 1983
4121: Domain Names - Implementation and Specification
4122:
4123:
4124: 10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the
4125: MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name
4126: GW.MIT.ARPA, the domain database would contain:
4127:
4128: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
4129: 10.IN-ADDR PTR IN GW.MIT.ARPA
4130: 18.IN-ADDR PTR IN GW.MIT.ARPA
4131: 26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
4132: 22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
4133: 103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
4134: 77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA
4135: 4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA
4136: 52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA
4137: 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
4138:
4139: Thus a program which wanted to locate gateways on net 10 would
4140: originate a query of the form QTYPE=PTR, QCLASS=IN,
4141: QNAME=10.IN-ADDR. It would receive two RRs in response:
4142:
4143: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA
4144: 10.IN-ADDR PTR IN GW.MIT.ARPA
4145:
4146: The program could then originate QTYPE=A, QCLASS=IN queries for
4147: MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet
4148: addresses of these gateways.
4149:
4150: A resolver which wanted to find the host name corresponding to
4151: ARPA Internet host address 10.0.0.6 might first try an inverse
4152: query on the local name server, but find that this information
4153: wasn't available. It could then try a query of the form
4154: QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive:
4155:
4156: 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA
4157:
4158: Several cautions apply to the use of these services:
4159:
4160: Since the IN-ADDR special domain and the normal domain for a
4161: particular host or gateway will be in different zones, the
4162: possibility exists that that the data may be inconsistent.
4163:
4164: Gateways will often have two names in separate domains, only
4165: one of which can be primary.
4166:
4167: Systems that use the domain database to initialize their
4168: routing tables must start with enough gateway information to
4169: guarantee that they can access the appropriate name server.
4170:
4171: The gateway data only reflects the existence of a gateway in a
4172:
4173:
4174:
4175: Mockapetris [Page 70]
4176:
4177:
4178: RFC 883 November 1983
4179: Domain Names - Implementation and Specification
4180:
4181:
4182: manner equivalent to the current HOSTS.TXT file. It doesn't
4183: replace the dynamic availability information from GGP or EGP.
4184:
4185:
4186:
4187:
4188:
4189:
4190:
4191:
4192:
4193:
4194:
4195:
4196:
4197:
4198:
4199:
4200:
4201:
4202:
4203:
4204:
4205:
4206:
4207:
4208:
4209:
4210:
4211:
4212:
4213:
4214:
4215:
4216:
4217:
4218:
4219:
4220:
4221:
4222:
4223:
4224:
4225:
4226:
4227:
4228:
4229:
4230:
4231:
4232:
4233: Mockapetris [Page 71]
4234:
4235:
4236: RFC 883 November 1983
4237: Domain Names - Implementation and Specification
4238:
4239:
4240: REFERENCES and BIBLIOGRAPHY
4241:
4242: [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
4243: Host Table Specification", RFC 810, Network Information Center,
4244: SRI International, March 1982.
4245:
4246: [2] J. Postel, "Computer Mail Meeting Notes", RFC 805,
4247: USC/Information Sciences Institute, February 1982.
4248:
4249: [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet
4250: User Applications", RFC 819, Network Information Center, SRI
4251: International, August 1982.
4252:
4253: [4] Z. Su, "A Distributed System for Internet Name Service",
4254: RFC 830, Network Information Center, SRI International,
4255: October 1982.
4256:
4257: [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
4258: Information Center, SRI International, March 1982.
4259:
4260: [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
4261: Server", Computer Networks, vol 6, nr 3, July 1982.
4262:
4263: [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
4264: Center, SRI International, December 1977.
4265:
4266: [8] J. Postel, "Internet Name Server", IEN 116, USC/Information
4267: Sciences Institute, August 1979.
4268:
4269: [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
4270: RFC 811, Network Information Center, SRI International,
4271: March 1982.
4272:
4273: [10] J. Postel, "Transmission Control Protocol", RFC 793,
4274: USC/Information Sciences Institute, September 1981.
4275:
4276: [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
4277: Sciences Institute, August 1980.
4278:
4279: [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
4280: USC/Information Sciences Institute, August 1980.
4281:
4282: [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
4283: USC/Information Sciences Institute, October 1983.
4284:
4285: [14] P. Mockapetris, "Domain names - Concepts and Facilities,"
4286: RFC 882, USC/Information Sciences Institute, November 1983.
4287:
4288:
4289:
4290:
4291: Mockapetris [Page 72]
4292:
4293:
4294: RFC 883 November 1983
4295: Domain Names - Implementation and Specification
4296:
4297:
4298: INDEX
4299:
4300: * usage........................................................37, 57
4301:
4302: A RDATA format.....................................................67
4303:
4304: byte order..........................................................6
4305:
4306: cache queue....................................................35, 42
4307: character case..................................................7, 31
4308: CLASS...........................................................9, 58
4309: completion.........................................................19
4310: compression........................................................31
4311: CNAME RR...........................................................60
4312:
4313: header format......................................................26
4314: HINFO RR...........................................................60
4315:
4316: include files......................................................43
4317: inverse queries....................................................17
4318:
4319: mailbox names......................................................53
4320: master files.......................................................43
4321: MB RR..............................................................61
4322: MD RR..............................................................61
4323: message format.....................................................13
4324: MF RR..............................................................62
4325: MG RR..............................................................62
4326: MINFO RR...........................................................63
4327: MR RR..............................................................63
4328:
4329: NULL RR............................................................64
4330: NS RR..............................................................64
4331:
4332: PTR RR.........................................................64, 69
4333:
4334: QCLASS.............................................................58
4335: QTYPE..............................................................57
4336: queries (standard).................................................15
4337:
4338: recursive service..................................................24
4339: RR format..........................................................59
4340:
4341: SOA RR.............................................................65
4342: Special domains....................................................68
4343:
4344: TYPE...............................................................57
4345:
4346: WKS type RR........................................................68
4347:
4348:
4349: Mockapetris [Page 73]
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.