![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1035.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc|
Return to rfc1035.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1: Network Working Group P. Mockapetris
2: Request for Comments: 1035 ISI
3: November 1987
4: Obsoletes: RFCs 882, 883, 973
5:
6: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
7:
8:
9: 1. STATUS OF THIS MEMO
10:
11: This RFC describes the details of the domain system and protocol, and
12: assumes that the reader is familiar with the concepts discussed in a
13: companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
14:
15: The domain system is a mixture of functions and data types which are an
16: official protocol and functions and data types which are still
17: experimental. Since the domain system is intentionally extensible, new
18: data types and experimental behavior should always be expected in parts
19: of the system beyond the official protocol. The official protocol parts
20: include standard queries, responses and the Internet class RR data
21: formats (e.g., host addresses). Since the previous RFC set, several
22: definitions have changed, so some previous definitions are obsolete.
23:
24: Experimental or obsolete features are clearly marked in these RFCs, and
25: such information should be used with caution.
26:
27: The reader is especially cautioned not to depend on the values which
28: appear in examples to be current or complete, since their purpose is
29: primarily pedagogical. Distribution of this memo is unlimited.
30:
31: Table of Contents
32:
33: 1. STATUS OF THIS MEMO 1
34: 2. INTRODUCTION 3
35: 2.1. Overview 3
36: 2.2. Common configurations 4
37: 2.3. Conventions 7
38: 2.3.1. Preferred name syntax 7
39: 2.3.2. Data Transmission Order 8
40: 2.3.3. Character Case 9
41: 2.3.4. Size limits 10
42: 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
43: 3.1. Name space definitions 10
44: 3.2. RR definitions 11
45: 3.2.1. Format 11
46: 3.2.2. TYPE values 12
47: 3.2.3. QTYPE values 12
48: 3.2.4. CLASS values 13
49:
50:
51:
52: Mockapetris [Page 1]
53:
54: RFC 1035 Domain Implementation and Specification November 1987
55:
56:
57: 3.2.5. QCLASS values 13
58: 3.3. Standard RRs 13
59: 3.3.1. CNAME RDATA format 14
60: 3.3.2. HINFO RDATA format 14
61: 3.3.3. MB RDATA format (EXPERIMENTAL) 14
62: 3.3.4. MD RDATA format (Obsolete) 15
63: 3.3.5. MF RDATA format (Obsolete) 15
64: 3.3.6. MG RDATA format (EXPERIMENTAL) 16
65: 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
66: 3.3.8. MR RDATA format (EXPERIMENTAL) 17
67: 3.3.9. MX RDATA format 17
68: 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
69: 3.3.11. NS RDATA format 18
70: 3.3.12. PTR RDATA format 18
71: 3.3.13. SOA RDATA format 19
72: 3.3.14. TXT RDATA format 20
73: 3.4. ARPA Internet specific RRs 20
74: 3.4.1. A RDATA format 20
75: 3.4.2. WKS RDATA format 21
76: 3.5. IN-ADDR.ARPA domain 22
77: 3.6. Defining new types, classes, and special namespaces 24
78: 4. MESSAGES 25
79: 4.1. Format 25
80: 4.1.1. Header section format 26
81: 4.1.2. Question section format 28
82: 4.1.3. Resource record format 29
83: 4.1.4. Message compression 30
84: 4.2. Transport 32
85: 4.2.1. UDP usage 32
86: 4.2.2. TCP usage 32
87: 5. MASTER FILES 33
88: 5.1. Format 33
89: 5.2. Use of master files to define zones 35
90: 5.3. Master file example 36
91: 6. NAME SERVER IMPLEMENTATION 37
92: 6.1. Architecture 37
93: 6.1.1. Control 37
94: 6.1.2. Database 37
95: 6.1.3. Time 39
96: 6.2. Standard query processing 39
97: 6.3. Zone refresh and reload processing 39
98: 6.4. Inverse queries (Optional) 40
99: 6.4.1. The contents of inverse queries and responses 40
100: 6.4.2. Inverse query and response example 41
101: 6.4.3. Inverse query processing 42
102:
103:
104:
105:
106:
107:
108: Mockapetris [Page 2]
109:
110: RFC 1035 Domain Implementation and Specification November 1987
111:
112:
113: 6.5. Completion queries and responses 42
114: 7. RESOLVER IMPLEMENTATION 43
115: 7.1. Transforming a user request into a query 43
116: 7.2. Sending the queries 44
117: 7.3. Processing responses 46
118: 7.4. Using the cache 47
119: 8. MAIL SUPPORT 47
120: 8.1. Mail exchange binding 48
121: 8.2. Mailbox binding (Experimental) 48
122: 9. REFERENCES and BIBLIOGRAPHY 50
123: Index 54
124:
125: 2. INTRODUCTION
126:
127: 2.1. Overview
128:
129: The goal of domain names is to provide a mechanism for naming resources
130: in such a way that the names are usable in different hosts, networks,
131: protocol families, internets, and administrative organizations.
132:
133: From the user's point of view, domain names are useful as arguments to a
134: local agent, called a resolver, which retrieves information associated
135: with the domain name. Thus a user might ask for the host address or
136: mail information associated with a particular domain name. To enable
137: the user to request a particular type of information, an appropriate
138: query type is passed to the resolver with the domain name. To the user,
139: the domain tree is a single information space; the resolver is
140: responsible for hiding the distribution of data among name servers from
141: the user.
142:
143: From the resolver's point of view, the database that makes up the domain
144: space is distributed among various name servers. Different parts of the
145: domain space are stored in different name servers, although a particular
146: data item will be stored redundantly in two or more name servers. The
147: resolver starts with knowledge of at least one name server. When the
148: resolver processes a user query it asks a known name server for the
149: information; in return, the resolver either receives the desired
150: information or a referral to another name server. Using these
151: referrals, resolvers learn the identities and contents of other name
152: servers. Resolvers are responsible for dealing with the distribution of
153: the domain space and dealing with the effects of name server failure by
154: consulting redundant databases in other servers.
155:
156: Name servers manage two kinds of data. The first kind of data held in
157: sets called zones; each zone is the complete database for a particular
158: "pruned" subtree of the domain space. This data is called
159: authoritative. A name server periodically checks to make sure that its
160: zones are up to date, and if not, obtains a new copy of updated zones
161:
162:
163:
164: Mockapetris [Page 3]
165:
166: RFC 1035 Domain Implementation and Specification November 1987
167:
168:
169: from master files stored locally or in another name server. The second
170: kind of data is cached data which was acquired by a local resolver.
171: This data may be incomplete, but improves the performance of the
172: retrieval process when non-local data is repeatedly accessed. Cached
173: data is eventually discarded by a timeout mechanism.
174:
175: This functional structure isolates the problems of user interface,
176: failure recovery, and distribution in the resolvers and isolates the
177: database update and refresh problems in the name servers.
178:
179: 2.2. Common configurations
180:
181: A host can participate in the domain name system in a number of ways,
182: depending on whether the host runs programs that retrieve information
183: from the domain system, name servers that answer queries from other
184: hosts, or various combinations of both functions. The simplest, and
185: perhaps most typical, configuration is shown below:
186:
187: Local Host | Foreign
188: |
189: +---------+ +----------+ | +--------+
190: | | user queries | |queries | | |
191: | User |-------------->| |---------|->|Foreign |
192: | Program | | Resolver | | | Name |
193: | |<--------------| |<--------|--| Server |
194: | | user responses| |responses| | |
195: +---------+ +----------+ | +--------+
196: | A |
197: cache additions | | references |
198: V | |
199: +----------+ |
200: | cache | |
201: +----------+ |
202:
203: User programs interact with the domain name space through resolvers; the
204: format of user queries and user responses is specific to the host and
205: its operating system. User queries will typically be operating system
206: calls, and the resolver and its cache will be part of the host operating
207: system. Less capable hosts may choose to implement the resolver as a
208: subroutine to be linked in with every program that needs its services.
209: Resolvers answer user queries with information they acquire via queries
210: to foreign name servers and the local cache.
211:
212: Note that the resolver may have to make several queries to several
213: different foreign name servers to answer a particular user query, and
214: hence the resolution of a user query may involve several network
215: accesses and an arbitrary amount of time. The queries to foreign name
216: servers and the corresponding responses have a standard format described
217:
218:
219:
220: Mockapetris [Page 4]
221:
222: RFC 1035 Domain Implementation and Specification November 1987
223:
224:
225: in this memo, and may be datagrams.
226:
227: Depending on its capabilities, a name server could be a stand alone
228: program on a dedicated machine or a process or processes on a large
229: timeshared host. A simple configuration might be:
230:
231: Local Host | Foreign
232: |
233: +---------+ |
234: / /| |
235: +---------+ | +----------+ | +--------+
236: | | | | |responses| | |
237: | | | | Name |---------|->|Foreign |
238: | Master |-------------->| Server | | |Resolver|
239: | files | | | |<--------|--| |
240: | |/ | | queries | +--------+
241: +---------+ +----------+ |
242:
243: Here a primary name server acquires information about one or more zones
244: by reading master files from its local file system, and answers queries
245: about those zones that arrive from foreign resolvers.
246:
247: The DNS requires that all zones be redundantly supported by more than
248: one name server. Designated secondary servers can acquire zones and
249: check for updates from the primary server using the zone transfer
250: protocol of the DNS. This configuration is shown below:
251:
252: Local Host | Foreign
253: |
254: +---------+ |
255: / /| |
256: +---------+ | +----------+ | +--------+
257: | | | | |responses| | |
258: | | | | Name |---------|->|Foreign |
259: | Master |-------------->| Server | | |Resolver|
260: | files | | | |<--------|--| |
261: | |/ | | queries | +--------+
262: +---------+ +----------+ |
263: A |maintenance | +--------+
264: | +------------|->| |
265: | queries | |Foreign |
266: | | | Name |
267: +------------------|--| Server |
268: maintenance responses | +--------+
269:
270: In this configuration, the name server periodically establishes a
271: virtual circuit to a foreign name server to acquire a copy of a zone or
272: to check that an existing copy has not changed. The messages sent for
273:
274:
275:
276: Mockapetris [Page 5]
277:
278: RFC 1035 Domain Implementation and Specification November 1987
279:
280:
281: these maintenance activities follow the same form as queries and
282: responses, but the message sequences are somewhat different.
283:
284: The information flow in a host that supports all aspects of the domain
285: name system is shown below:
286:
287: Local Host | Foreign
288: |
289: +---------+ +----------+ | +--------+
290: | | user queries | |queries | | |
291: | User |-------------->| |---------|->|Foreign |
292: | Program | | Resolver | | | Name |
293: | |<--------------| |<--------|--| Server |
294: | | user responses| |responses| | |
295: +---------+ +----------+ | +--------+
296: | A |
297: cache additions | | references |
298: V | |
299: +----------+ |
300: | Shared | |
301: | database | |
302: +----------+ |
303: A | |
304: +---------+ refreshes | | references |
305: / /| | V |
306: +---------+ | +----------+ | +--------+
307: | | | | |responses| | |
308: | | | | Name |---------|->|Foreign |
309: | Master |-------------->| Server | | |Resolver|
310: | files | | | |<--------|--| |
311: | |/ | | queries | +--------+
312: +---------+ +----------+ |
313: A |maintenance | +--------+
314: | +------------|->| |
315: | queries | |Foreign |
316: | | | Name |
317: +------------------|--| Server |
318: maintenance responses | +--------+
319:
320: The shared database holds domain space data for the local name server
321: and resolver. The contents of the shared database will typically be a
322: mixture of authoritative data maintained by the periodic refresh
323: operations of the name server and cached data from previous resolver
324: requests. The structure of the domain data and the necessity for
325: synchronization between name servers and resolvers imply the general
326: characteristics of this database, but the actual format is up to the
327: local implementor.
328:
329:
330:
331:
332: Mockapetris [Page 6]
333:
334: RFC 1035 Domain Implementation and Specification November 1987
335:
336:
337: Information flow can also be tailored so that a group of hosts act
338: together to optimize activities. Sometimes this is done to offload less
339: capable hosts so that they do not have to implement a full resolver.
340: This can be appropriate for PCs or hosts which want to minimize the
341: amount of new network code which is required. This scheme can also
342: allow a group of hosts can share a small number of caches rather than
343: maintaining a large number of separate caches, on the premise that the
344: centralized caches will have a higher hit ratio. In either case,
345: resolvers are replaced with stub resolvers which act as front ends to
346: resolvers located in a recursive server in one or more name servers
347: known to perform that service:
348:
349: Local Hosts | Foreign
350: |
351: +---------+ |
352: | | responses |
353: | Stub |<--------------------+ |
354: | Resolver| | |
355: | |----------------+ | |
356: +---------+ recursive | | |
357: queries | | |
358: V | |
359: +---------+ recursive +----------+ | +--------+
360: | | queries | |queries | | |
361: | Stub |-------------->| Recursive|---------|->|Foreign |
362: | Resolver| | Server | | | Name |
363: | |<--------------| |<--------|--| Server |
364: +---------+ responses | |responses| | |
365: +----------+ | +--------+
366: | Central | |
367: | cache | |
368: +----------+ |
369:
370: In any case, note that domain components are always replicated for
371: reliability whenever possible.
372:
373: 2.3. Conventions
374:
375: The domain system has several conventions dealing with low-level, but
376: fundamental, issues. While the implementor is free to violate these
377: conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
378: ALL behavior observed from other hosts.
379:
380: 2.3.1. Preferred name syntax
381:
382: The DNS specifications attempt to be as general as possible in the rules
383: for constructing domain names. The idea is that the name of any
384: existing object can be expressed as a domain name with minimal changes.
385:
386:
387:
388: Mockapetris [Page 7]
389:
390: RFC 1035 Domain Implementation and Specification November 1987
391:
392:
393: However, when assigning a domain name for an object, the prudent user
394: will select a name which satisfies both the rules of the domain system
395: and any existing rules for the object, whether these rules are published
396: or implied by existing programs.
397:
398: For example, when naming a mail domain, the user should satisfy both the
399: rules of this memo and those in RFC-822. When creating a new host name,
400: the old rules for HOSTS.TXT should be followed. This avoids problems
401: when old software is converted to use domain names.
402:
403: The following syntax will result in fewer problems with many
404:
405: applications that use domain names (e.g., mail, TELNET).
406:
407: <domain> ::= <subdomain> | " "
408:
409: <subdomain> ::= <label> | <subdomain> "." <label>
410:
411: <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
412:
413: <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
414:
415: <let-dig-hyp> ::= <let-dig> | "-"
416:
417: <let-dig> ::= <letter> | <digit>
418:
419: <letter> ::= any one of the 52 alphabetic characters A through Z in
420: upper case and a through z in lower case
421:
422: <digit> ::= any one of the ten digits 0 through 9
423:
424: Note that while upper and lower case letters are allowed in domain
425: names, no significance is attached to the case. That is, two names with
426: the same spelling but different case are to be treated as if identical.
427:
428: The labels must follow the rules for ARPANET host names. They must
429: start with a letter, end with a letter or digit, and have as interior
430: characters only letters, digits, and hyphen. There are also some
431: restrictions on the length. Labels must be 63 characters or less.
432:
433: For example, the following strings identify hosts in the Internet:
434:
435: A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
436:
437: 2.3.2. Data Transmission Order
438:
439: The order of transmission of the header and data described in this
440: document is resolved to the octet level. Whenever a diagram shows a
441:
442:
443:
444: Mockapetris [Page 8]
445:
446: RFC 1035 Domain Implementation and Specification November 1987
447:
448:
449: group of octets, the order of transmission of those octets is the normal
450: order in which they are read in English. For example, in the following
451: diagram, the octets are transmitted in the order they are numbered.
452:
453: 0 1
454: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
455: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
456: | 1 | 2 |
457: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
458: | 3 | 4 |
459: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
460: | 5 | 6 |
461: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
462:
463: Whenever an octet represents a numeric quantity, the left most bit in
464: the diagram is the high order or most significant bit. That is, the bit
465: labeled 0 is the most significant bit. For example, the following
466: diagram represents the value 170 (decimal).
467:
468: 0 1 2 3 4 5 6 7
469: +-+-+-+-+-+-+-+-+
470: |1 0 1 0 1 0 1 0|
471: +-+-+-+-+-+-+-+-+
472:
473: Similarly, whenever a multi-octet field represents a numeric quantity
474: the left most bit of the whole field is the most significant bit. When
475: a multi-octet quantity is transmitted the most significant octet is
476: transmitted first.
477:
478: 2.3.3. Character Case
479:
480: For all parts of the DNS that are part of the official protocol, all
481: comparisons between character strings (e.g., labels, domain names, etc.)
482: are done in a case-insensitive manner. At present, this rule is in
483: force throughout the domain system without exception. However, future
484: additions beyond current usage may need to use the full binary octet
485: capabilities in names, so attempts to store domain names in 7-bit ASCII
486: or use of special bytes to terminate labels, etc., should be avoided.
487:
488: When data enters the domain system, its original case should be
489: preserved whenever possible. In certain circumstances this cannot be
490: done. For example, if two RRs are stored in a database, one at x.y and
491: one at X.Y, they are actually stored at the same place in the database,
492: and hence only one casing would be preserved. The basic rule is that
493: case can be discarded only when data is used to define structure in a
494: database, and two names are identical when compared in a case
495: insensitive manner.
496:
497:
498:
499:
500: Mockapetris [Page 9]
501:
502: RFC 1035 Domain Implementation and Specification November 1987
503:
504:
505: Loss of case sensitive data must be minimized. Thus while data for x.y
506: and X.Y may both be stored under a single location x.y or X.Y, data for
507: a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
508: general, this preserves the case of the first label of a domain name,
509: but forces standardization of interior node labels.
510:
511: Systems administrators who enter data into the domain database should
512: take care to represent the data they supply to the domain system in a
513: case-consistent manner if their system is case-sensitive. The data
514: distribution system in the domain system will ensure that consistent
515: representations are preserved.
516:
517: 2.3.4. Size limits
518:
519: Various objects and parameters in the DNS have size limits. They are
520: listed below. Some could be easily changed, others are more
521: fundamental.
522:
523: labels 63 octets or less
524:
525: names 255 octets or less
526:
527: TTL positive values of a signed 32 bit number.
528:
529: UDP messages 512 octets or less
530:
531: 3. DOMAIN NAME SPACE AND RR DEFINITIONS
532:
533: 3.1. Name space definitions
534:
535: Domain names in messages are expressed in terms of a sequence of labels.
536: Each label is represented as a one octet length field followed by that
537: number of octets. Since every domain name ends with the null label of
538: the root, a domain name is terminated by a length byte of zero. The
539: high order two bits of every length octet must be zero, and the
540: remaining six bits of the length field limit the label to 63 octets or
541: less.
542:
543: To simplify implementations, the total length of a domain name (i.e.,
544: label octets and label length octets) is restricted to 255 octets or
545: less.
546:
547: Although labels can contain any 8 bit values in octets that make up a
548: label, it is strongly recommended that labels follow the preferred
549: syntax described elsewhere in this memo, which is compatible with
550: existing host naming conventions. Name servers and resolvers must
551: compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
552: with zero parity. Non-alphabetic codes must match exactly.
553:
554:
555:
556: Mockapetris [Page 10]
557:
558: RFC 1035 Domain Implementation and Specification November 1987
559:
560:
561: 3.2. RR definitions
562:
563: 3.2.1. Format
564:
565: All RRs have the same top level format shown below:
566:
567: 1 1 1 1 1 1
568: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
569: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
570: | |
571: / /
572: / NAME /
573: | |
574: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
575: | TYPE |
576: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
577: | CLASS |
578: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
579: | TTL |
580: | |
581: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
582: | RDLENGTH |
583: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
584: / RDATA /
585: / /
586: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
587:
588:
589: where:
590:
591: NAME an owner name, i.e., the name of the node to which this
592: resource record pertains.
593:
594: TYPE two octets containing one of the RR TYPE codes.
595:
596: CLASS two octets containing one of the RR CLASS codes.
597:
598: TTL a 32 bit signed integer that specifies the time interval
599: that the resource record may be cached before the source
600: of the information should again be consulted. Zero
601: values are interpreted to mean that the RR can only be
602: used for the transaction in progress, and should not be
603: cached. For example, SOA records are always distributed
604: with a zero TTL to prohibit caching. Zero values can
605: also be used for extremely volatile data.
606:
607: RDLENGTH an unsigned 16 bit integer that specifies the length in
608: octets of the RDATA field.
609:
610:
611:
612: Mockapetris [Page 11]
613:
614: RFC 1035 Domain Implementation and Specification November 1987
615:
616:
617: RDATA a variable length string of octets that describes the
618: resource. The format of this information varies
619: according to the TYPE and CLASS of the resource record.
620:
621: 3.2.2. TYPE values
622:
623: TYPE fields are used in resource records. Note that these types are a
624: subset of QTYPEs.
625:
626: TYPE value and meaning
627:
628: A 1 a host address
629:
630: NS 2 an authoritative name server
631:
632: MD 3 a mail destination (Obsolete - use MX)
633:
634: MF 4 a mail forwarder (Obsolete - use MX)
635:
636: CNAME 5 the canonical name for an alias
637:
638: SOA 6 marks the start of a zone of authority
639:
640: MB 7 a mailbox domain name (EXPERIMENTAL)
641:
642: MG 8 a mail group member (EXPERIMENTAL)
643:
644: MR 9 a mail rename domain name (EXPERIMENTAL)
645:
646: NULL 10 a null RR (EXPERIMENTAL)
647:
648: WKS 11 a well known service description
649:
650: PTR 12 a domain name pointer
651:
652: HINFO 13 host information
653:
654: MINFO 14 mailbox or mail list information
655:
656: MX 15 mail exchange
657:
658: TXT 16 text strings
659:
660: 3.2.3. QTYPE values
661:
662: QTYPE fields appear in the question part of a query. QTYPES are a
663: superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
664: following QTYPEs are defined:
665:
666:
667:
668: Mockapetris [Page 12]
669:
670: RFC 1035 Domain Implementation and Specification November 1987
671:
672:
673: AXFR 252 A request for a transfer of an entire zone
674:
675: MAILB 253 A request for mailbox-related records (MB, MG or MR)
676:
677: MAILA 254 A request for mail agent RRs (Obsolete - see MX)
678:
679: * 255 A request for all records
680:
681: 3.2.4. CLASS values
682:
683: CLASS fields appear in resource records. The following CLASS mnemonics
684: and values are defined:
685:
686: IN 1 the Internet
687:
688: CS 2 the CSNET class (Obsolete - used only for examples in
689: some obsolete RFCs)
690:
691: CH 3 the CHAOS class
692:
693: HS 4 Hesiod [Dyer 87]
694:
695: 3.2.5. QCLASS values
696:
697: QCLASS fields appear in the question section of a query. QCLASS values
698: are a superset of CLASS values; every CLASS is a valid QCLASS. In
699: addition to CLASS values, the following QCLASSes are defined:
700:
701: * 255 any class
702:
703: 3.3. Standard RRs
704:
705: The following RR definitions are expected to occur, at least
706: potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
707: will be used in all classes, and have the same format in all classes.
708: Because their RDATA format is known, all domain names in the RDATA
709: section of these RRs may be compressed.
710:
711: <domain-name> is a domain name represented as a series of labels, and
712: terminated by a label with zero length. <character-string> is a single
713: length octet followed by that number of characters. <character-string>
714: is treated as binary information, and can be up to 256 characters in
715: length (including the length octet).
716:
717:
718:
719:
720:
721:
722:
723:
724: Mockapetris [Page 13]
725:
726: RFC 1035 Domain Implementation and Specification November 1987
727:
728:
729: 3.3.1. CNAME RDATA format
730:
731: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
732: / CNAME /
733: / /
734: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
735:
736: where:
737:
738: CNAME A <domain-name> which specifies the canonical or primary
739: name for the owner. The owner name is an alias.
740:
741: CNAME RRs cause no additional section processing, but name servers may
742: choose to restart the query at the canonical name in certain cases. See
743: the description of name server logic in [RFC-1034] for details.
744:
745: 3.3.2. HINFO RDATA format
746:
747: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
748: / CPU /
749: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
750: / OS /
751: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
752:
753: where:
754:
755: CPU A <character-string> which specifies the CPU type.
756:
757: OS A <character-string> which specifies the operating
758: system type.
759:
760: Standard values for CPU and OS can be found in [RFC-1010].
761:
762: HINFO records are used to acquire general information about a host. The
763: main use is for protocols such as FTP that can use special procedures
764: when talking between machines or operating systems of the same type.
765:
766: 3.3.3. MB RDATA format (EXPERIMENTAL)
767:
768: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
769: / MADNAME /
770: / /
771: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
772:
773: where:
774:
775: MADNAME A <domain-name> which specifies a host which has the
776: specified mailbox.
777:
778:
779:
780: Mockapetris [Page 14]
781:
782: RFC 1035 Domain Implementation and Specification November 1987
783:
784:
785: MB records cause additional section processing which looks up an A type
786: RRs corresponding to MADNAME.
787:
788: 3.3.4. MD RDATA format (Obsolete)
789:
790: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
791: / MADNAME /
792: / /
793: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
794:
795: where:
796:
797: MADNAME A <domain-name> which specifies a host which has a mail
798: agent for the domain which should be able to deliver
799: mail for the domain.
800:
801: MD records cause additional section processing which looks up an A type
802: record corresponding to MADNAME.
803:
804: MD is obsolete. See the definition of MX and [RFC-974] for details of
805: the new scheme. The recommended policy for dealing with MD RRs found in
806: a master file is to reject them, or to convert them to MX RRs with a
807: preference of 0.
808:
809: 3.3.5. MF RDATA format (Obsolete)
810:
811: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
812: / MADNAME /
813: / /
814: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
815:
816: where:
817:
818: MADNAME A <domain-name> which specifies a host which has a mail
819: agent for the domain which will accept mail for
820: forwarding to the domain.
821:
822: MF records cause additional section processing which looks up an A type
823: record corresponding to MADNAME.
824:
825: MF is obsolete. See the definition of MX and [RFC-974] for details ofw
826: the new scheme. The recommended policy for dealing with MD RRs found in
827: a master file is to reject them, or to convert them to MX RRs with a
828: preference of 10.
829:
830:
831:
832:
833:
834:
835:
836: Mockapetris [Page 15]
837:
838: RFC 1035 Domain Implementation and Specification November 1987
839:
840:
841: 3.3.6. MG RDATA format (EXPERIMENTAL)
842:
843: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
844: / MGMNAME /
845: / /
846: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
847:
848: where:
849:
850: MGMNAME A <domain-name> which specifies a mailbox which is a
851: member of the mail group specified by the domain name.
852:
853: MG records cause no additional section processing.
854:
855: 3.3.7. MINFO RDATA format (EXPERIMENTAL)
856:
857: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
858: / RMAILBX /
859: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
860: / EMAILBX /
861: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
862:
863: where:
864:
865: RMAILBX A <domain-name> which specifies a mailbox which is
866: responsible for the mailing list or mailbox. If this
867: domain name names the root, the owner of the MINFO RR is
868: responsible for itself. Note that many existing mailing
869: lists use a mailbox X-request for the RMAILBX field of
870: mailing list X, e.g., Msgroup-request for Msgroup. This
871: field provides a more general mechanism.
872:
873:
874: EMAILBX A <domain-name> which specifies a mailbox which is to
875: receive error messages related to the mailing list or
876: mailbox specified by the owner of the MINFO RR (similar
877: to the ERRORS-TO: field which has been proposed). If
878: this domain name names the root, errors should be
879: returned to the sender of the message.
880:
881: MINFO records cause no additional section processing. Although these
882: records can be associated with a simple mailbox, they are usually used
883: with a mailing list.
884:
885:
886:
887:
888:
889:
890:
891:
892: Mockapetris [Page 16]
893:
894: RFC 1035 Domain Implementation and Specification November 1987
895:
896:
897: 3.3.8. MR RDATA format (EXPERIMENTAL)
898:
899: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
900: / NEWNAME /
901: / /
902: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
903:
904: where:
905:
906: NEWNAME A <domain-name> which specifies a mailbox which is the
907: proper rename of the specified mailbox.
908:
909: MR records cause no additional section processing. The main use for MR
910: is as a forwarding entry for a user who has moved to a different
911: mailbox.
912:
913: 3.3.9. MX RDATA format
914:
915: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
916: | PREFERENCE |
917: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
918: / EXCHANGE /
919: / /
920: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
921:
922: where:
923:
924: PREFERENCE A 16 bit integer which specifies the preference given to
925: this RR among others at the same owner. Lower values
926: are preferred.
927:
928: EXCHANGE A <domain-name> which specifies a host willing to act as
929: a mail exchange for the owner name.
930:
931: MX records cause type A additional section processing for the host
932: specified by EXCHANGE. The use of MX RRs is explained in detail in
933: [RFC-974].
934:
935: 3.3.10. NULL RDATA format (EXPERIMENTAL)
936:
937: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
938: / <anything> /
939: / /
940: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
941:
942: Anything at all may be in the RDATA field so long as it is 65535 octets
943: or less.
944:
945:
946:
947:
948: Mockapetris [Page 17]
949:
950: RFC 1035 Domain Implementation and Specification November 1987
951:
952:
953: NULL records cause no additional section processing. NULL RRs are not
954: allowed in master files. NULLs are used as placeholders in some
955: experimental extensions of the DNS.
956:
957: 3.3.11. NS RDATA format
958:
959: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
960: / NSDNAME /
961: / /
962: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
963:
964: where:
965:
966: NSDNAME A <domain-name> which specifies a host which should be
967: authoritative for the specified class and domain.
968:
969: NS records cause both the usual additional section processing to locate
970: a type A record, and, when used in a referral, a special search of the
971: zone in which they reside for glue information.
972:
973: The NS RR states that the named host should be expected to have a zone
974: starting at owner name of the specified class. Note that the class may
975: not indicate the protocol family which should be used to communicate
976: with the host, although it is typically a strong hint. For example,
977: hosts which are name servers for either Internet (IN) or Hesiod (HS)
978: class information are normally queried using IN class protocols.
979:
980: 3.3.12. PTR RDATA format
981:
982: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
983: / PTRDNAME /
984: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
985:
986: where:
987:
988: PTRDNAME A <domain-name> which points to some location in the
989: domain name space.
990:
991: PTR records cause no additional section processing. These RRs are used
992: in special domains to point to some other location in the domain space.
993: These records are simple data, and don't imply any special processing
994: similar to that performed by CNAME, which identifies aliases. See the
995: description of the IN-ADDR.ARPA domain for an example.
996:
997:
998:
999:
1000:
1001:
1002:
1003:
1004: Mockapetris [Page 18]
1005:
1006: RFC 1035 Domain Implementation and Specification November 1987
1007:
1008:
1009: 3.3.13. SOA RDATA format
1010:
1011: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1012: / MNAME /
1013: / /
1014: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1015: / RNAME /
1016: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1017: | SERIAL |
1018: | |
1019: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1020: | REFRESH |
1021: | |
1022: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1023: | RETRY |
1024: | |
1025: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1026: | EXPIRE |
1027: | |
1028: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1029: | MINIMUM |
1030: | |
1031: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1032:
1033: where:
1034:
1035: MNAME The <domain-name> of the name server that was the
1036: original or primary source of data for this zone.
1037:
1038: RNAME A <domain-name> which specifies the mailbox of the
1039: person responsible for this zone.
1040:
1041: SERIAL The unsigned 32 bit version number of the original copy
1042: of the zone. Zone transfers preserve this value. This
1043: value wraps and should be compared using sequence space
1044: arithmetic.
1045:
1046: REFRESH A 32 bit time interval before the zone should be
1047: refreshed.
1048:
1049: RETRY A 32 bit time interval that should elapse before a
1050: failed refresh should be retried.
1051:
1052: EXPIRE A 32 bit time value that specifies the upper limit on
1053: the time interval that can elapse before the zone is no
1054: longer authoritative.
1055:
1056:
1057:
1058:
1059:
1060: Mockapetris [Page 19]
1061:
1062: RFC 1035 Domain Implementation and Specification November 1987
1063:
1064:
1065: MINIMUM The unsigned 32 bit minimum TTL field that should be
1066: exported with any RR from this zone.
1067:
1068: SOA records cause no additional section processing.
1069:
1070: All times are in units of seconds.
1071:
1072: Most of these fields are pertinent only for name server maintenance
1073: operations. However, MINIMUM is used in all query operations that
1074: retrieve RRs from a zone. Whenever a RR is sent in a response to a
1075: query, the TTL field is set to the maximum of the TTL field from the RR
1076: and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
1077: bound on the TTL field for all RRs in a zone. Note that this use of
1078: MINIMUM should occur when the RRs are copied into the response and not
1079: when the zone is loaded from a master file or via a zone transfer. The
1080: reason for this provison is to allow future dynamic update facilities to
1081: change the SOA RR with known semantics.
1082:
1083:
1084: 3.3.14. TXT RDATA format
1085:
1086: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1087: / TXT-DATA /
1088: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1089:
1090: where:
1091:
1092: TXT-DATA One or more <character-string>s.
1093:
1094: TXT RRs are used to hold descriptive text. The semantics of the text
1095: depends on the domain where it is found.
1096:
1097: 3.4. Internet specific RRs
1098:
1099: 3.4.1. A RDATA format
1100:
1101: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1102: | ADDRESS |
1103: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1104:
1105: where:
1106:
1107: ADDRESS A 32 bit Internet address.
1108:
1109: Hosts that have multiple Internet addresses will have multiple A
1110: records.
1111:
1112:
1113:
1114:
1115:
1116: Mockapetris [Page 20]
1117:
1118: RFC 1035 Domain Implementation and Specification November 1987
1119:
1120:
1121: A records cause no additional section processing. The RDATA section of
1122: an A line in a master file is an Internet address expressed as four
1123: decimal numbers separated by dots without any imbedded spaces (e.g.,
1124: "10.2.0.52" or "192.0.5.6").
1125:
1126: 3.4.2. WKS RDATA format
1127:
1128: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1129: | ADDRESS |
1130: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1131: | PROTOCOL | |
1132: +--+--+--+--+--+--+--+--+ |
1133: | |
1134: / <BIT MAP> /
1135: / /
1136: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1137:
1138: where:
1139:
1140: ADDRESS An 32 bit Internet address
1141:
1142: PROTOCOL An 8 bit IP protocol number
1143:
1144: <BIT MAP> A variable length bit map. The bit map must be a
1145: multiple of 8 bits long.
1146:
1147: The WKS record is used to describe the well known services supported by
1148: a particular protocol on a particular internet address. The PROTOCOL
1149: field specifies an IP protocol number, and the bit map has one bit per
1150: port of the specified protocol. The first bit corresponds to port 0,
1151: the second to port 1, etc. If the bit map does not include a bit for a
1152: protocol of interest, that bit is assumed zero. The appropriate values
1153: and mnemonics for ports and protocols are specified in [RFC-1010].
1154:
1155: For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
1156: 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
1157: port 25; if zero, SMTP service is not supported on the specified
1158: address.
1159:
1160: The purpose of WKS RRs is to provide availability information for
1161: servers for TCP and UDP. If a server supports both TCP and UDP, or has
1162: multiple Internet addresses, then multiple WKS RRs are used.
1163:
1164: WKS RRs cause no additional section processing.
1165:
1166: In master files, both ports and protocols are expressed using mnemonics
1167: or decimal numbers.
1168:
1169:
1170:
1171:
1172: Mockapetris [Page 21]
1173:
1174: RFC 1035 Domain Implementation and Specification November 1987
1175:
1176:
1177: 3.5. IN-ADDR.ARPA domain
1178:
1179: The Internet uses a special domain to support gateway location and
1180: Internet address to host mapping. Other classes may employ a similar
1181: strategy in other domains. The intent of this domain is to provide a
1182: guaranteed method to perform host address to host name mapping, and to
1183: facilitate queries to locate all gateways on a particular network in the
1184: Internet.
1185:
1186: Note that both of these services are similar to functions that could be
1187: performed by inverse queries; the difference is that this part of the
1188: domain name space is structured according to address, and hence can
1189: guarantee that the appropriate data can be located without an exhaustive
1190: search of the domain space.
1191:
1192: The domain begins at IN-ADDR.ARPA and has a substructure which follows
1193: the Internet addressing structure.
1194:
1195: Domain names in the IN-ADDR.ARPA domain are defined to have up to four
1196: labels in addition to the IN-ADDR.ARPA suffix. Each label represents
1197: one octet of an Internet address, and is expressed as a character string
1198: for a decimal value in the range 0-255 (with leading zeros omitted
1199: except in the case of a zero octet which is represented by a single
1200: zero).
1201:
1202: Host addresses are represented by domain names that have all four labels
1203: specified. Thus data for Internet address 10.2.0.52 is located at
1204: domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
1205: read, allows zones to be delegated which are exactly one network of
1206: address space. For example, 10.IN-ADDR.ARPA can be a zone containing
1207: data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
1208: MILNET. Address nodes are used to hold pointers to primary host names
1209: in the normal domain space.
1210:
1211: Network numbers correspond to some non-terminal nodes at various depths
1212: in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
1213: 2, or 3 octets. Network nodes are used to hold pointers to the primary
1214: host names of gateways attached to that network. Since a gateway is, by
1215: definition, on more than one network, it will typically have two or more
1216: network nodes which point at it. Gateways will also have host level
1217: pointers at their fully qualified addresses.
1218:
1219: Both the gateway pointers at network nodes and the normal host pointers
1220: at full address nodes use the PTR RR to point back to the primary domain
1221: names of the corresponding hosts.
1222:
1223: For example, the IN-ADDR.ARPA domain will contain information about the
1224: ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
1225:
1226:
1227:
1228: Mockapetris [Page 22]
1229:
1230: RFC 1035 Domain Implementation and Specification November 1987
1231:
1232:
1233: net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
1234: gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
1235: GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
1236: and a name GW.LCS.MIT.EDU, the domain database would contain:
1237:
1238: 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1239: 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1240: 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1241: 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1242: 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1243: 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1244: 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1245: 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1246: 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
1247: 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
1248:
1249: Thus a program which wanted to locate gateways on net 10 would originate
1250: a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
1251: would receive two RRs in response:
1252:
1253: 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1254: 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1255:
1256: The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
1257: GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
1258: these gateways.
1259:
1260: A resolver which wanted to find the host name corresponding to Internet
1261: host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
1262: QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
1263:
1264: 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
1265:
1266: Several cautions apply to the use of these services:
1267: - Since the IN-ADDR.ARPA special domain and the normal domain
1268: for a particular host or gateway will be in different zones,
1269: the possibility exists that that the data may be inconsistent.
1270:
1271: - Gateways will often have two names in separate domains, only
1272: one of which can be primary.
1273:
1274: - Systems that use the domain database to initialize their
1275: routing tables must start with enough gateway information to
1276: guarantee that they can access the appropriate name server.
1277:
1278: - The gateway data only reflects the existence of a gateway in a
1279: manner equivalent to the current HOSTS.TXT file. It doesn't
1280: replace the dynamic availability information from GGP or EGP.
1281:
1282:
1283:
1284: Mockapetris [Page 23]
1285:
1286: RFC 1035 Domain Implementation and Specification November 1987
1287:
1288:
1289: 3.6. Defining new types, classes, and special namespaces
1290:
1291: The previously defined types and classes are the ones in use as of the
1292: date of this memo. New definitions should be expected. This section
1293: makes some recommendations to designers considering additions to the
1294: existing facilities. The mailing list [email protected] is the
1295: forum where general discussion of design issues takes place.
1296:
1297: In general, a new type is appropriate when new information is to be
1298: added to the database about an existing object, or we need new data
1299: formats for some totally new object. Designers should attempt to define
1300: types and their RDATA formats that are generally applicable to all
1301: classes, and which avoid duplication of information. New classes are
1302: appropriate when the DNS is to be used for a new protocol, etc which
1303: requires new class-specific data formats, or when a copy of the existing
1304: name space is desired, but a separate management domain is necessary.
1305:
1306: New types and classes need mnemonics for master files; the format of the
1307: master files requires that the mnemonics for type and class be disjoint.
1308:
1309: TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
1310: respectively.
1311:
1312: The present system uses multiple RRs to represent multiple values of a
1313: type rather than storing multiple values in the RDATA section of a
1314: single RR. This is less efficient for most applications, but does keep
1315: RRs shorter. The multiple RRs assumption is incorporated in some
1316: experimental work on dynamic update methods.
1317:
1318: The present system attempts to minimize the duplication of data in the
1319: database in order to insure consistency. Thus, in order to find the
1320: address of the host for a mail exchange, you map the mail domain name to
1321: a host name, then the host name to addresses, rather than a direct
1322: mapping to host address. This approach is preferred because it avoids
1323: the opportunity for inconsistency.
1324:
1325: In defining a new type of data, multiple RR types should not be used to
1326: create an ordering between entries or express different formats for
1327: equivalent bindings, instead this information should be carried in the
1328: body of the RR and a single type used. This policy avoids problems with
1329: caching multiple types and defining QTYPEs to match multiple types.
1330:
1331: For example, the original form of mail exchange binding used two RR
1332: types one to represent a "closer" exchange (MD) and one to represent a
1333: "less close" exchange (MF). The difficulty is that the presence of one
1334: RR type in a cache doesn't convey any information about the other
1335: because the query which acquired the cached information might have used
1336: a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
1337:
1338:
1339:
1340: Mockapetris [Page 24]
1341:
1342: RFC 1035 Domain Implementation and Specification November 1987
1343:
1344:
1345: service used a single type (MX) with a "preference" value in the RDATA
1346: section which can order different RRs. However, if any MX RRs are found
1347: in the cache, then all should be there.
1348:
1349: 4. MESSAGES
1350:
1351: 4.1. Format
1352:
1353: All communications inside of the domain protocol are carried in a single
1354: format called a message. The top level format of message is divided
1355: into 5 sections (some of which are empty in certain cases) shown below:
1356:
1357: +---------------------+
1358: | Header |
1359: +---------------------+
1360: | Question | the question for the name server
1361: +---------------------+
1362: | Answer | RRs answering the question
1363: +---------------------+
1364: | Authority | RRs pointing toward an authority
1365: +---------------------+
1366: | Additional | RRs holding additional information
1367: +---------------------+
1368:
1369: The header section is always present. The header includes fields that
1370: specify which of the remaining sections are present, and also specify
1371: whether the message is a query or a response, a standard query or some
1372: other opcode, etc.
1373:
1374: The names of the sections after the header are derived from their use in
1375: standard queries. The question section contains fields that describe a
1376: question to a name server. These fields are a query type (QTYPE), a
1377: query class (QCLASS), and a query domain name (QNAME). The last three
1378: sections have the same format: a possibly empty list of concatenated
1379: resource records (RRs). The answer section contains RRs that answer the
1380: question; the authority section contains RRs that point toward an
1381: authoritative name server; the additional records section contains RRs
1382: which relate to the query, but are not strictly answers for the
1383: question.
1384:
1385:
1386:
1387:
1388:
1389:
1390:
1391:
1392:
1393:
1394:
1395:
1396: Mockapetris [Page 25]
1397:
1398: RFC 1035 Domain Implementation and Specification November 1987
1399:
1400:
1401: 4.1.1. Header section format
1402:
1403: The header contains the following fields:
1404:
1405: 1 1 1 1 1 1
1406: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1407: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1408: | ID |
1409: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1410: |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
1411: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1412: | QDCOUNT |
1413: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1414: | ANCOUNT |
1415: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1416: | NSCOUNT |
1417: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1418: | ARCOUNT |
1419: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1420:
1421: where:
1422:
1423: ID A 16 bit identifier assigned by the program that
1424: generates any kind of query. This identifier is copied
1425: the corresponding reply and can be used by the requester
1426: to match up replies to outstanding queries.
1427:
1428: QR A one bit field that specifies whether this message is a
1429: query (0), or a response (1).
1430:
1431: OPCODE A four bit field that specifies kind of query in this
1432: message. This value is set by the originator of a query
1433: and copied into the response. The values are:
1434:
1435: 0 a standard query (QUERY)
1436:
1437: 1 an inverse query (IQUERY)
1438:
1439: 2 a server status request (STATUS)
1440:
1441: 3-15 reserved for future use
1442:
1443: AA Authoritative Answer - this bit is valid in responses,
1444: and specifies that the responding name server is an
1445: authority for the domain name in question section.
1446:
1447: Note that the contents of the answer section may have
1448: multiple owner names because of aliases. The AA bit
1449:
1450:
1451:
1452: Mockapetris [Page 26]
1453:
1454: RFC 1035 Domain Implementation and Specification November 1987
1455:
1456:
1457: corresponds to the name which matches the query name, or
1458: the first owner name in the answer section.
1459:
1460: TC TrunCation - specifies that this message was truncated
1461: due to length greater than that permitted on the
1462: transmission channel.
1463:
1464: RD Recursion Desired - this bit may be set in a query and
1465: is copied into the response. If RD is set, it directs
1466: the name server to pursue the query recursively.
1467: Recursive query support is optional.
1468:
1469: RA Recursion Available - this be is set or cleared in a
1470: response, and denotes whether recursive query support is
1471: available in the name server.
1472:
1473: Z Reserved for future use. Must be zero in all queries
1474: and responses.
1475:
1476: RCODE Response code - this 4 bit field is set as part of
1477: responses. The values have the following
1478: interpretation:
1479:
1480: 0 No error condition
1481:
1482: 1 Format error - The name server was
1483: unable to interpret the query.
1484:
1485: 2 Server failure - The name server was
1486: unable to process this query due to a
1487: problem with the name server.
1488:
1489: 3 Name Error - Meaningful only for
1490: responses from an authoritative name
1491: server, this code signifies that the
1492: domain name referenced in the query does
1493: not exist.
1494:
1495: 4 Not Implemented - The name server does
1496: not support the requested kind of query.
1497:
1498: 5 Refused - The name server refuses to
1499: perform the specified operation for
1500: policy reasons. For example, a name
1501: server may not wish to provide the
1502: information to the particular requester,
1503: or a name server may not wish to perform
1504: a particular operation (e.g., zone
1505:
1506:
1507:
1508: Mockapetris [Page 27]
1509:
1510: RFC 1035 Domain Implementation and Specification November 1987
1511:
1512:
1513: transfer) for particular data.
1514:
1515: 6-15 Reserved for future use.
1516:
1517: QDCOUNT an unsigned 16 bit integer specifying the number of
1518: entries in the question section.
1519:
1520: ANCOUNT an unsigned 16 bit integer specifying the number of
1521: resource records in the answer section.
1522:
1523: NSCOUNT an unsigned 16 bit integer specifying the number of name
1524: server resource records in the authority records
1525: section.
1526:
1527: ARCOUNT an unsigned 16 bit integer specifying the number of
1528: resource records in the additional records section.
1529:
1530: 4.1.2. Question section format
1531:
1532: The question section is used to carry the "question" in most queries,
1533: i.e., the parameters that define what is being asked. The section
1534: contains QDCOUNT (usually 1) entries, each of the following format:
1535:
1536: 1 1 1 1 1 1
1537: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1538: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1539: | |
1540: / QNAME /
1541: / /
1542: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1543: | QTYPE |
1544: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1545: | QCLASS |
1546: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1547:
1548: where:
1549:
1550: QNAME a domain name represented as a sequence of labels, where
1551: each label consists of a length octet followed by that
1552: number of octets. The domain name terminates with the
1553: zero length octet for the null label of the root. Note
1554: that this field may be an odd number of octets; no
1555: padding is used.
1556:
1557: QTYPE a two octet code which specifies the type of the query.
1558: The values for this field include all codes valid for a
1559: TYPE field, together with some more general codes which
1560: can match more than one type of RR.
1561:
1562:
1563:
1564: Mockapetris [Page 28]
1565:
1566: RFC 1035 Domain Implementation and Specification November 1987
1567:
1568:
1569: QCLASS a two octet code that specifies the class of the query.
1570: For example, the QCLASS field is IN for the Internet.
1571:
1572: 4.1.3. Resource record format
1573:
1574: The answer, authority, and additional sections all share the same
1575: format: a variable number of resource records, where the number of
1576: records is specified in the corresponding count field in the header.
1577: Each resource record has the following format:
1578: 1 1 1 1 1 1
1579: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1580: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1581: | |
1582: / /
1583: / NAME /
1584: | |
1585: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1586: | TYPE |
1587: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1588: | CLASS |
1589: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1590: | TTL |
1591: | |
1592: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1593: | RDLENGTH |
1594: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
1595: / RDATA /
1596: / /
1597: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1598:
1599: where:
1600:
1601: NAME a domain name to which this resource record pertains.
1602:
1603: TYPE two octets containing one of the RR type codes. This
1604: field specifies the meaning of the data in the RDATA
1605: field.
1606:
1607: CLASS two octets which specify the class of the data in the
1608: RDATA field.
1609:
1610: TTL a 32 bit unsigned integer that specifies the time
1611: interval (in seconds) that the resource record may be
1612: cached before it should be discarded. Zero values are
1613: interpreted to mean that the RR can only be used for the
1614: transaction in progress, and should not be cached.
1615:
1616:
1617:
1618:
1619:
1620: Mockapetris [Page 29]
1621:
1622: RFC 1035 Domain Implementation and Specification November 1987
1623:
1624:
1625: RDLENGTH an unsigned 16 bit integer that specifies the length in
1626: octets of the RDATA field.
1627:
1628: RDATA a variable length string of octets that describes the
1629: resource. The format of this information varies
1630: according to the TYPE and CLASS of the resource record.
1631: For example, the if the TYPE is A and the CLASS is IN,
1632: the RDATA field is a 4 octet ARPA Internet address.
1633:
1634: 4.1.4. Message compression
1635:
1636: In order to reduce the size of messages, the domain system utilizes a
1637: compression scheme which eliminates the repetition of domain names in a
1638: message. In this scheme, an entire domain name or a list of labels at
1639: the end of a domain name is replaced with a pointer to a prior occurance
1640: of the same name.
1641:
1642: The pointer takes the form of a two octet sequence:
1643:
1644: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1645: | 1 1| OFFSET |
1646: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1647:
1648: The first two bits are ones. This allows a pointer to be distinguished
1649: from a label, since the label must begin with two zero bits because
1650: labels are restricted to 63 octets or less. (The 10 and 01 combinations
1651: are reserved for future use.) The OFFSET field specifies an offset from
1652: the start of the message (i.e., the first octet of the ID field in the
1653: domain header). A zero offset specifies the first byte of the ID field,
1654: etc.
1655:
1656: The compression scheme allows a domain name in a message to be
1657: represented as either:
1658:
1659: - a sequence of labels ending in a zero octet
1660:
1661: - a pointer
1662:
1663: - a sequence of labels ending with a pointer
1664:
1665: Pointers can only be used for occurances of a domain name where the
1666: format is not class specific. If this were not the case, a name server
1667: or resolver would be required to know the format of all RRs it handled.
1668: As yet, there are no such cases, but they may occur in future RDATA
1669: formats.
1670:
1671: If a domain name is contained in a part of the message subject to a
1672: length field (such as the RDATA section of an RR), and compression is
1673:
1674:
1675:
1676: Mockapetris [Page 30]
1677:
1678: RFC 1035 Domain Implementation and Specification November 1987
1679:
1680:
1681: used, the length of the compressed name is used in the length
1682: calculation, rather than the length of the expanded name.
1683:
1684: Programs are free to avoid using pointers in messages they generate,
1685: although this will reduce datagram capacity, and may cause truncation.
1686: However all programs are required to understand arriving messages that
1687: contain pointers.
1688:
1689: For example, a datagram might need to use the domain names F.ISI.ARPA,
1690: FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
1691: message, these domain names might be represented as:
1692:
1693: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1694: 20 | 1 | F |
1695: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1696: 22 | 3 | I |
1697: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1698: 24 | S | I |
1699: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1700: 26 | 4 | A |
1701: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1702: 28 | R | P |
1703: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1704: 30 | A | 0 |
1705: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1706:
1707: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1708: 40 | 3 | F |
1709: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1710: 42 | O | O |
1711: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1712: 44 | 1 1| 20 |
1713: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1714:
1715: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1716: 64 | 1 1| 26 |
1717: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1718:
1719: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1720: 92 | 0 | |
1721: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1722:
1723: The domain name for F.ISI.ARPA is shown at offset 20. The domain name
1724: FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
1725: concatenate a label for FOO to the previously defined F.ISI.ARPA. The
1726: domain name ARPA is defined at offset 64 using a pointer to the ARPA
1727: component of the name F.ISI.ARPA at 20; note that this pointer relies on
1728: ARPA being the last label in the string at 20. The root domain name is
1729:
1730:
1731:
1732: Mockapetris [Page 31]
1733:
1734: RFC 1035 Domain Implementation and Specification November 1987
1735:
1736:
1737: defined by a single octet of zeros at 92; the root domain name has no
1738: labels.
1739:
1740: 4.2. Transport
1741:
1742: The DNS assumes that messages will be transmitted as datagrams or in a
1743: byte stream carried by a virtual circuit. While virtual circuits can be
1744: used for any DNS activity, datagrams are preferred for queries due to
1745: their lower overhead and better performance. Zone refresh activities
1746: must use virtual circuits because of the need for reliable transfer.
1747:
1748: The Internet supports name server access using TCP [RFC-793] on server
1749: port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
1750: port 53 (decimal).
1751:
1752: 4.2.1. UDP usage
1753:
1754: Messages sent using UDP user server port 53 (decimal).
1755:
1756: Messages carried by UDP are restricted to 512 bytes (not counting the IP
1757: or UDP headers). Longer messages are truncated and the TC bit is set in
1758: the header.
1759:
1760: UDP is not acceptable for zone transfers, but is the recommended method
1761: for standard queries in the Internet. Queries sent using UDP may be
1762: lost, and hence a retransmission strategy is required. Queries or their
1763: responses may be reordered by the network, or by processing in name
1764: servers, so resolvers should not depend on them being returned in order.
1765:
1766: The optimal UDP retransmission policy will vary with performance of the
1767: Internet and the needs of the client, but the following are recommended:
1768:
1769: - The client should try other servers and server addresses
1770: before repeating a query to a specific address of a server.
1771:
1772: - The retransmission interval should be based on prior
1773: statistics if possible. Too aggressive retransmission can
1774: easily slow responses for the community at large. Depending
1775: on how well connected the client is to its expected servers,
1776: the minimum retransmission interval should be 2-5 seconds.
1777:
1778: More suggestions on server selection and retransmission policy can be
1779: found in the resolver section of this memo.
1780:
1781: 4.2.2. TCP usage
1782:
1783: Messages sent over TCP connections use server port 53 (decimal). The
1784: message is prefixed with a two byte length field which gives the message
1785:
1786:
1787:
1788: Mockapetris [Page 32]
1789:
1790: RFC 1035 Domain Implementation and Specification November 1987
1791:
1792:
1793: length, excluding the two byte length field. This length field allows
1794: the low-level processing to assemble a complete message before beginning
1795: to parse it.
1796:
1797: Several connection management policies are recommended:
1798:
1799: - The server should not block other activities waiting for TCP
1800: data.
1801:
1802: - The server should support multiple connections.
1803:
1804: - The server should assume that the client will initiate
1805: connection closing, and should delay closing its end of the
1806: connection until all outstanding client requests have been
1807: satisfied.
1808:
1809: - If the server needs to close a dormant connection to reclaim
1810: resources, it should wait until the connection has been idle
1811: for a period on the order of two minutes. In particular, the
1812: server should allow the SOA and AXFR request sequence (which
1813: begins a refresh operation) to be made on a single connection.
1814: Since the server would be unable to answer queries anyway, a
1815: unilateral close or reset may be used instead of a graceful
1816: close.
1817:
1818: 5. MASTER FILES
1819:
1820: Master files are text files that contain RRs in text form. Since the
1821: contents of a zone can be expressed in the form of a list of RRs a
1822: master file is most often used to define a zone, though it can be used
1823: to list a cache's contents. Hence, this section first discusses the
1824: format of RRs in a master file, and then the special considerations when
1825: a master file is used to create a zone in some name server.
1826:
1827: 5.1. Format
1828:
1829: The format of these files is a sequence of entries. Entries are
1830: predominantly line-oriented, though parentheses can be used to continue
1831: a list of items across a line boundary, and text literals can contain
1832: CRLF within the text. Any combination of tabs and spaces act as a
1833: delimiter between the separate items that make up an entry. The end of
1834: any line in the master file can end with a comment. The comment starts
1835: with a ";" (semicolon).
1836:
1837: The following entries are defined:
1838:
1839: <blank>[<comment>]
1840:
1841:
1842:
1843:
1844: Mockapetris [Page 33]
1845:
1846: RFC 1035 Domain Implementation and Specification November 1987
1847:
1848:
1849: $ORIGIN <domain-name> [<comment>]
1850:
1851: $INCLUDE <file-name> [<domain-name>] [<comment>]
1852:
1853: <domain-name><rr> [<comment>]
1854:
1855: <blank><rr> [<comment>]
1856:
1857: Blank lines, with or without comments, are allowed anywhere in the file.
1858:
1859: Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
1860: followed by a domain name, and resets the current origin for relative
1861: domain names to the stated name. $INCLUDE inserts the named file into
1862: the current file, and may optionally specify a domain name that sets the
1863: relative domain name origin for the included file. $INCLUDE may also
1864: have a comment. Note that a $INCLUDE entry never changes the relative
1865: origin of the parent file, regardless of changes to the relative origin
1866: made within the included file.
1867:
1868: The last two forms represent RRs. If an entry for an RR begins with a
1869: blank, then the RR is assumed to be owned by the last stated owner. If
1870: an RR entry begins with a <domain-name>, then the owner name is reset.
1871:
1872: <rr> contents take one of the following forms:
1873:
1874: [<TTL>] [<class>] <type> <RDATA>
1875:
1876: [<class>] [<TTL>] <type> <RDATA>
1877:
1878: The RR begins with optional TTL and class fields, followed by a type and
1879: RDATA field appropriate to the type and class. Class and type use the
1880: standard mnemonics, TTL is a decimal integer. Omitted class and TTL
1881: values are default to the last explicitly stated values. Since type and
1882: class mnemonics are disjoint, the parse is unique. (Note that this
1883: order is different from the order used in examples and the order used in
1884: the actual RRs; the given order allows easier parsing and defaulting.)
1885:
1886: <domain-name>s make up a large share of the data in the master file.
1887: The labels in the domain name are expressed as character strings and
1888: separated by dots. Quoting conventions allow arbitrary characters to be
1889: stored in domain names. Domain names that end in a dot are called
1890: absolute, and are taken as complete. Domain names which do not end in a
1891: dot are called relative; the actual domain name is the concatenation of
1892: the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
1893: an argument to the master file loading routine. A relative name is an
1894: error when no origin is available.
1895:
1896:
1897:
1898:
1899:
1900: Mockapetris [Page 34]
1901:
1902: RFC 1035 Domain Implementation and Specification November 1987
1903:
1904:
1905: <character-string> is expressed in one or two ways: as a contiguous set
1906: of characters without interior spaces, or as a string beginning with a "
1907: and ending with a ". Inside a " delimited string any character can
1908: occur, except for a " itself, which must be quoted using \ (back slash).
1909:
1910: Because these files are text files several special encodings are
1911: necessary to allow arbitrary data to be loaded. In particular:
1912:
1913: of the root.
1914:
1915: @ A free standing @ is used to denote the current origin.
1916:
1917: \X where X is any character other than a digit (0-9), is
1918: used to quote that character so that its special meaning
1919: does not apply. For example, "\." can be used to place
1920: a dot character in a label.
1921:
1922: \DDD where each D is a digit is the octet corresponding to
1923: the decimal number described by DDD. The resulting
1924: octet is assumed to be text and is not checked for
1925: special meaning.
1926:
1927: ( ) Parentheses are used to group data that crosses a line
1928: boundary. In effect, line terminations are not
1929: recognized within parentheses.
1930:
1931: ; Semicolon is used to start a comment; the remainder of
1932: the line is ignored.
1933:
1934: 5.2. Use of master files to define zones
1935:
1936: When a master file is used to load a zone, the operation should be
1937: suppressed if any errors are encountered in the master file. The
1938: rationale for this is that a single error can have widespread
1939: consequences. For example, suppose that the RRs defining a delegation
1940: have syntax errors; then the server will return authoritative name
1941: errors for all names in the subzone (except in the case where the
1942: subzone is also present on the server).
1943:
1944: Several other validity checks that should be performed in addition to
1945: insuring that the file is syntactically correct:
1946:
1947: 1. All RRs in the file should have the same class.
1948:
1949: 2. Exactly one SOA RR should be present at the top of the zone.
1950:
1951: 3. If delegations are present and glue information is required,
1952: it should be present.
1953:
1954:
1955:
1956: Mockapetris [Page 35]
1957:
1958: RFC 1035 Domain Implementation and Specification November 1987
1959:
1960:
1961: 4. Information present outside of the authoritative nodes in the
1962: zone should be glue information, rather than the result of an
1963: origin or similar error.
1964:
1965: 5.3. Master file example
1966:
1967: The following is an example file which might be used to define the
1968: ISI.EDU zone.and is loaded with an origin of ISI.EDU:
1969:
1970: @ IN SOA VENERA Action\.domains (
1971: 20 ; SERIAL
1972: 7200 ; REFRESH
1973: 600 ; RETRY
1974: 3600000; EXPIRE
1975: 60) ; MINIMUM
1976:
1977: NS A.ISI.EDU.
1978: NS VENERA
1979: NS VAXA
1980: MX 10 VENERA
1981: MX 20 VAXA
1982:
1983: A A 26.3.0.103
1984:
1985: VENERA A 10.1.0.52
1986: A 128.9.0.32
1987:
1988: VAXA A 10.2.0.27
1989: A 128.9.0.33
1990:
1991:
1992: $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
1993:
1994: Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
1995:
1996: MOE MB A.ISI.EDU.
1997: LARRY MB A.ISI.EDU.
1998: CURLEY MB A.ISI.EDU.
1999: STOOGES MG MOE
2000: MG LARRY
2001: MG CURLEY
2002:
2003: Note the use of the \ character in the SOA RR to specify the responsible
2004: person mailbox "[email protected]".
2005:
2006:
2007:
2008:
2009:
2010:
2011:
2012: Mockapetris [Page 36]
2013:
2014: RFC 1035 Domain Implementation and Specification November 1987
2015:
2016:
2017: 6. NAME SERVER IMPLEMENTATION
2018:
2019: 6.1. Architecture
2020:
2021: The optimal structure for the name server will depend on the host
2022: operating system and whether the name server is integrated with resolver
2023: operations, either by supporting recursive service, or by sharing its
2024: database with a resolver. This section discusses implementation
2025: considerations for a name server which shares a database with a
2026: resolver, but most of these concerns are present in any name server.
2027:
2028: 6.1.1. Control
2029:
2030: A name server must employ multiple concurrent activities, whether they
2031: are implemented as separate tasks in the host's OS or multiplexing
2032: inside a single name server program. It is simply not acceptable for a
2033: name server to block the service of UDP requests while it waits for TCP
2034: data for refreshing or query activities. Similarly, a name server
2035: should not attempt to provide recursive service without processing such
2036: requests in parallel, though it may choose to serialize requests from a
2037: single client, or to regard identical requests from the same client as
2038: duplicates. A name server should not substantially delay requests while
2039: it reloads a zone from master files or while it incorporates a newly
2040: refreshed zone into its database.
2041:
2042: 6.1.2. Database
2043:
2044: While name server implementations are free to use any internal data
2045: structures they choose, the suggested structure consists of three major
2046: parts:
2047:
2048: - A "catalog" data structure which lists the zones available to
2049: this server, and a "pointer" to the zone data structure. The
2050: main purpose of this structure is to find the nearest ancestor
2051: zone, if any, for arriving standard queries.
2052:
2053: - Separate data structures for each of the zones held by the
2054: name server.
2055:
2056: - A data structure for cached data. (or perhaps separate caches
2057: for different classes)
2058:
2059: All of these data structures can be implemented an identical tree
2060: structure format, with different data chained off the nodes in different
2061: parts: in the catalog the data is pointers to zones, while in the zone
2062: and cache data structures, the data will be RRs. In designing the tree
2063: framework the designer should recognize that query processing will need
2064: to traverse the tree using case-insensitive label comparisons; and that
2065:
2066:
2067:
2068: Mockapetris [Page 37]
2069:
2070: RFC 1035 Domain Implementation and Specification November 1987
2071:
2072:
2073: in real data, a few nodes have a very high branching factor (100-1000 or
2074: more), but the vast majority have a very low branching factor (0-1).
2075:
2076: One way to solve the case problem is to store the labels for each node
2077: in two pieces: a standardized-case representation of the label where all
2078: ASCII characters are in a single case, together with a bit mask that
2079: denotes which characters are actually of a different case. The
2080: branching factor diversity can be handled using a simple linked list for
2081: a node until the branching factor exceeds some threshold, and
2082: transitioning to a hash structure after the threshold is exceeded. In
2083: any case, hash structures used to store tree sections must insure that
2084: hash functions and procedures preserve the casing conventions of the
2085: DNS.
2086:
2087: The use of separate structures for the different parts of the database
2088: is motivated by several factors:
2089:
2090: - The catalog structure can be an almost static structure that
2091: need change only when the system administrator changes the
2092: zones supported by the server. This structure can also be
2093: used to store parameters used to control refreshing
2094: activities.
2095:
2096: - The individual data structures for zones allow a zone to be
2097: replaced simply by changing a pointer in the catalog. Zone
2098: refresh operations can build a new structure and, when
2099: complete, splice it into the database via a simple pointer
2100: replacement. It is very important that when a zone is
2101: refreshed, queries should not use old and new data
2102: simultaneously.
2103:
2104: - With the proper search procedures, authoritative data in zones
2105: will always "hide", and hence take precedence over, cached
2106: data.
2107:
2108: - Errors in zone definitions that cause overlapping zones, etc.,
2109: may cause erroneous responses to queries, but problem
2110: determination is simplified, and the contents of one "bad"
2111: zone can't corrupt another.
2112:
2113: - Since the cache is most frequently updated, it is most
2114: vulnerable to corruption during system restarts. It can also
2115: become full of expired RR data. In either case, it can easily
2116: be discarded without disturbing zone data.
2117:
2118: A major aspect of database design is selecting a structure which allows
2119: the name server to deal with crashes of the name server's host. State
2120: information which a name server should save across system crashes
2121:
2122:
2123:
2124: Mockapetris [Page 38]
2125:
2126: RFC 1035 Domain Implementation and Specification November 1987
2127:
2128:
2129: includes the catalog structure (including the state of refreshing for
2130: each zone) and the zone data itself.
2131:
2132: 6.1.3. Time
2133:
2134: Both the TTL data for RRs and the timing data for refreshing activities
2135: depends on 32 bit timers in units of seconds. Inside the database,
2136: refresh timers and TTLs for cached data conceptually "count down", while
2137: data in the zone stays with constant TTLs.
2138:
2139: A recommended implementation strategy is to store time in two ways: as
2140: a relative increment and as an absolute time. One way to do this is to
2141: use positive 32 bit numbers for one type and negative numbers for the
2142: other. The RRs in zones use relative times; the refresh timers and
2143: cache data use absolute times. Absolute numbers are taken with respect
2144: to some known origin and converted to relative values when placed in the
2145: response to a query. When an absolute TTL is negative after conversion
2146: to relative, then the data is expired and should be ignored.
2147:
2148: 6.2. Standard query processing
2149:
2150: The major algorithm for standard query processing is presented in
2151: [RFC-1034].
2152:
2153: When processing queries with QCLASS=*, or some other QCLASS which
2154: matches multiple classes, the response should never be authoritative
2155: unless the server can guarantee that the response covers all classes.
2156:
2157: When composing a response, RRs which are to be inserted in the
2158: additional section, but duplicate RRs in the answer or authority
2159: sections, may be omitted from the additional section.
2160:
2161: When a response is so long that truncation is required, the truncation
2162: should start at the end of the response and work forward in the
2163: datagram. Thus if there is any data for the authority section, the
2164: answer section is guaranteed to be unique.
2165:
2166: The MINIMUM value in the SOA should be used to set a floor on the TTL of
2167: data distributed from a zone. This floor function should be done when
2168: the data is copied into a response. This will allow future dynamic
2169: update protocols to change the SOA MINIMUM field without ambiguous
2170: semantics.
2171:
2172: 6.3. Zone refresh and reload processing
2173:
2174: In spite of a server's best efforts, it may be unable to load zone data
2175: from a master file due to syntax errors, etc., or be unable to refresh a
2176: zone within the its expiration parameter. In this case, the name server
2177:
2178:
2179:
2180: Mockapetris [Page 39]
2181:
2182: RFC 1035 Domain Implementation and Specification November 1987
2183:
2184:
2185: should answer queries as if it were not supposed to possess the zone.
2186:
2187: If a master is sending a zone out via AXFR, and a new version is created
2188: during the transfer, the master should continue to send the old version
2189: if possible. In any case, it should never send part of one version and
2190: part of another. If completion is not possible, the master should reset
2191: the connection on which the zone transfer is taking place.
2192:
2193: 6.4. Inverse queries (Optional)
2194:
2195: Inverse queries are an optional part of the DNS. Name servers are not
2196: required to support any form of inverse queries. If a name server
2197: receives an inverse query that it does not support, it returns an error
2198: response with the "Not Implemented" error set in the header. While
2199: inverse query support is optional, all name servers must be at least
2200: able to return the error response.
2201:
2202: 6.4.1. The contents of inverse queries and responses Inverse
2203: queries reverse the mappings performed by standard query operations;
2204: while a standard query maps a domain name to a resource, an inverse
2205: query maps a resource to a domain name. For example, a standard query
2206: might bind a domain name to a host address; the corresponding inverse
2207: query binds the host address to a domain name.
2208:
2209: Inverse queries take the form of a single RR in the answer section of
2210: the message, with an empty question section. The owner name of the
2211: query RR and its TTL are not significant. The response carries
2212: questions in the question section which identify all names possessing
2213: the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
2214: about all of the domain name space, the response can never be assumed to
2215: be complete. Thus inverse queries are primarily useful for database
2216: management and debugging activities. Inverse queries are NOT an
2217: acceptable method of mapping host addresses to host names; use the IN-
2218: ADDR.ARPA domain instead.
2219:
2220: Where possible, name servers should provide case-insensitive comparisons
2221: for inverse queries. Thus an inverse query asking for an MX RR of
2222: "Venera.isi.edu" should get the same response as a query for
2223: "VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
2224: produce the same result as an inverse query for "IBM-pc unix". However,
2225: this cannot be guaranteed because name servers may possess RRs that
2226: contain character strings but the name server does not know that the
2227: data is character.
2228:
2229: When a name server processes an inverse query, it either returns:
2230:
2231: 1. zero, one, or multiple domain names for the specified
2232: resource as QNAMEs in the question section
2233:
2234:
2235:
2236: Mockapetris [Page 40]
2237:
2238: RFC 1035 Domain Implementation and Specification November 1987
2239:
2240:
2241: 2. an error code indicating that the name server doesn't support
2242: inverse mapping of the specified resource type.
2243:
2244: When the response to an inverse query contains one or more QNAMEs, the
2245: owner name and TTL of the RR in the answer section which defines the
2246: inverse query is modified to exactly match an RR found at the first
2247: QNAME.
2248:
2249: RRs returned in the inverse queries cannot be cached using the same
2250: mechanism as is used for the replies to standard queries. One reason
2251: for this is that a name might have multiple RRs of the same type, and
2252: only one would appear. For example, an inverse query for a single
2253: address of a multiply homed host might create the impression that only
2254: one address existed.
2255:
2256: 6.4.2. Inverse query and response example The overall structure
2257: of an inverse query for retrieving the domain name that corresponds to
2258: Internet address 10.1.0.52 is shown below:
2259:
2260: +-----------------------------------------+
2261: Header | OPCODE=IQUERY, ID=997 |
2262: +-----------------------------------------+
2263: Question | <empty> |
2264: +-----------------------------------------+
2265: Answer | <anyname> A IN 10.1.0.52 |
2266: +-----------------------------------------+
2267: Authority | <empty> |
2268: +-----------------------------------------+
2269: Additional | <empty> |
2270: +-----------------------------------------+
2271:
2272: This query asks for a question whose answer is the Internet style
2273: address 10.1.0.52. Since the owner name is not known, any domain name
2274: can be used as a placeholder (and is ignored). A single octet of zero,
2275: signifying the root, is usually used because it minimizes the length of
2276: the message. The TTL of the RR is not significant. The response to
2277: this query might be:
2278:
2279:
2280:
2281:
2282:
2283:
2284:
2285:
2286:
2287:
2288:
2289:
2290:
2291:
2292: Mockapetris [Page 41]
2293:
2294: RFC 1035 Domain Implementation and Specification November 1987
2295:
2296:
2297: +-----------------------------------------+
2298: Header | OPCODE=RESPONSE, ID=997 |
2299: +-----------------------------------------+
2300: Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
2301: +-----------------------------------------+
2302: Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
2303: +-----------------------------------------+
2304: Authority | <empty> |
2305: +-----------------------------------------+
2306: Additional | <empty> |
2307: +-----------------------------------------+
2308:
2309: Note that the QTYPE in a response to an inverse query is the same as the
2310: TYPE field in the answer section of the inverse query. Responses to
2311: inverse queries may contain multiple questions when the inverse is not
2312: unique. If the question section in the response is not empty, then the
2313: RR in the answer section is modified to correspond to be an exact copy
2314: of an RR at the first QNAME.
2315:
2316: 6.4.3. Inverse query processing
2317:
2318: Name servers that support inverse queries can support these operations
2319: through exhaustive searches of their databases, but this becomes
2320: impractical as the size of the database increases. An alternative
2321: approach is to invert the database according to the search key.
2322:
2323: For name servers that support multiple zones and a large amount of data,
2324: the recommended approach is separate inversions for each zone. When a
2325: particular zone is changed during a refresh, only its inversions need to
2326: be redone.
2327:
2328: Support for transfer of this type of inversion may be included in future
2329: versions of the domain system, but is not supported in this version.
2330:
2331: 6.5. Completion queries and responses
2332:
2333: The optional completion services described in RFC-882 and RFC-883 have
2334: been deleted. Redesigned services may become available in the future.
2335:
2336:
2337:
2338:
2339:
2340:
2341:
2342:
2343:
2344:
2345:
2346:
2347:
2348: Mockapetris [Page 42]
2349:
2350: RFC 1035 Domain Implementation and Specification November 1987
2351:
2352:
2353: 7. RESOLVER IMPLEMENTATION
2354:
2355: The top levels of the recommended resolver algorithm are discussed in
2356: [RFC-1034]. This section discusses implementation details assuming the
2357: database structure suggested in the name server implementation section
2358: of this memo.
2359:
2360: 7.1. Transforming a user request into a query
2361:
2362: The first step a resolver takes is to transform the client's request,
2363: stated in a format suitable to the local OS, into a search specification
2364: for RRs at a specific name which match a specific QTYPE and QCLASS.
2365: Where possible, the QTYPE and QCLASS should correspond to a single type
2366: and a single class, because this makes the use of cached data much
2367: simpler. The reason for this is that the presence of data of one type
2368: in a cache doesn't confirm the existence or non-existence of data of
2369: other types, hence the only way to be sure is to consult an
2370: authoritative source. If QCLASS=* is used, then authoritative answers
2371: won't be available.
2372:
2373: Since a resolver must be able to multiplex multiple requests if it is to
2374: perform its function efficiently, each pending request is usually
2375: represented in some block of state information. This state block will
2376: typically contain:
2377:
2378: - A timestamp indicating the time the request began.
2379: The timestamp is used to decide whether RRs in the database
2380: can be used or are out of date. This timestamp uses the
2381: absolute time format previously discussed for RR storage in
2382: zones and caches. Note that when an RRs TTL indicates a
2383: relative time, the RR must be timely, since it is part of a
2384: zone. When the RR has an absolute time, it is part of a
2385: cache, and the TTL of the RR is compared against the timestamp
2386: for the start of the request.
2387:
2388: Note that using the timestamp is superior to using a current
2389: time, since it allows RRs with TTLs of zero to be entered in
2390: the cache in the usual manner, but still used by the current
2391: request, even after intervals of many seconds due to system
2392: load, query retransmission timeouts, etc.
2393:
2394: - Some sort of parameters to limit the amount of work which will
2395: be performed for this request.
2396:
2397: The amount of work which a resolver will do in response to a
2398: client request must be limited to guard against errors in the
2399: database, such as circular CNAME references, and operational
2400: problems, such as network partition which prevents the
2401:
2402:
2403:
2404: Mockapetris [Page 43]
2405:
2406: RFC 1035 Domain Implementation and Specification November 1987
2407:
2408:
2409: resolver from accessing the name servers it needs. While
2410: local limits on the number of times a resolver will retransmit
2411: a particular query to a particular name server address are
2412: essential, the resolver should have a global per-request
2413: counter to limit work on a single request. The counter should
2414: be set to some initial value and decremented whenever the
2415: resolver performs any action (retransmission timeout,
2416: retransmission, etc.) If the counter passes zero, the request
2417: is terminated with a temporary error.
2418:
2419: Note that if the resolver structure allows one request to
2420: start others in parallel, such as when the need to access a
2421: name server for one request causes a parallel resolve for the
2422: name server's addresses, the spawned request should be started
2423: with a lower counter. This prevents circular references in
2424: the database from starting a chain reaction of resolver
2425: activity.
2426:
2427: - The SLIST data structure discussed in [RFC-1034].
2428:
2429: This structure keeps track of the state of a request if it
2430: must wait for answers from foreign name servers.
2431:
2432: 7.2. Sending the queries
2433:
2434: As described in [RFC-1034], the basic task of the resolver is to
2435: formulate a query which will answer the client's request and direct that
2436: query to name servers which can provide the information. The resolver
2437: will usually only have very strong hints about which servers to ask, in
2438: the form of NS RRs, and may have to revise the query, in response to
2439: CNAMEs, or revise the set of name servers the resolver is asking, in
2440: response to delegation responses which point the resolver to name
2441: servers closer to the desired information. In addition to the
2442: information requested by the client, the resolver may have to call upon
2443: its own services to determine the address of name servers it wishes to
2444: contact.
2445:
2446: In any case, the model used in this memo assumes that the resolver is
2447: multiplexing attention between multiple requests, some from the client,
2448: and some internally generated. Each request is represented by some
2449: state information, and the desired behavior is that the resolver
2450: transmit queries to name servers in a way that maximizes the probability
2451: that the request is answered, minimizes the time that the request takes,
2452: and avoids excessive transmissions. The key algorithm uses the state
2453: information of the request to select the next name server address to
2454: query, and also computes a timeout which will cause the next action
2455: should a response not arrive. The next action will usually be a
2456: transmission to some other server, but may be a temporary error to the
2457:
2458:
2459:
2460: Mockapetris [Page 44]
2461:
2462: RFC 1035 Domain Implementation and Specification November 1987
2463:
2464:
2465: client.
2466:
2467: The resolver always starts with a list of server names to query (SLIST).
2468: This list will be all NS RRs which correspond to the nearest ancestor
2469: zone that the resolver knows about. To avoid startup problems, the
2470: resolver should have a set of default servers which it will ask should
2471: it have no current NS RRs which are appropriate. The resolver then adds
2472: to SLIST all of the known addresses for the name servers, and may start
2473: parallel requests to acquire the addresses of the servers when the
2474: resolver has the name, but no addresses, for the name servers.
2475:
2476: To complete initialization of SLIST, the resolver attaches whatever
2477: history information it has to the each address in SLIST. This will
2478: usually consist of some sort of weighted averages for the response time
2479: of the address, and the batting average of the address (i.e., how often
2480: the address responded at all to the request). Note that this
2481: information should be kept on a per address basis, rather than on a per
2482: name server basis, because the response time and batting average of a
2483: particular server may vary considerably from address to address. Note
2484: also that this information is actually specific to a resolver address /
2485: server address pair, so a resolver with multiple addresses may wish to
2486: keep separate histories for each of its addresses. Part of this step
2487: must deal with addresses which have no such history; in this case an
2488: expected round trip time of 5-10 seconds should be the worst case, with
2489: lower estimates for the same local network, etc.
2490:
2491: Note that whenever a delegation is followed, the resolver algorithm
2492: reinitializes SLIST.
2493:
2494: The information establishes a partial ranking of the available name
2495: server addresses. Each time an address is chosen and the state should
2496: be altered to prevent its selection again until all other addresses have
2497: been tried. The timeout for each transmission should be 50-100% greater
2498: than the average predicted value to allow for variance in response.
2499:
2500: Some fine points:
2501:
2502: - The resolver may encounter a situation where no addresses are
2503: available for any of the name servers named in SLIST, and
2504: where the servers in the list are precisely those which would
2505: normally be used to look up their own addresses. This
2506: situation typically occurs when the glue address RRs have a
2507: smaller TTL than the NS RRs marking delegation, or when the
2508: resolver caches the result of a NS search. The resolver
2509: should detect this condition and restart the search at the
2510: next ancestor zone, or alternatively at the root.
2511:
2512:
2513:
2514:
2515:
2516: Mockapetris [Page 45]
2517:
2518: RFC 1035 Domain Implementation and Specification November 1987
2519:
2520:
2521: - If a resolver gets a server error or other bizarre response
2522: from a name server, it should remove it from SLIST, and may
2523: wish to schedule an immediate transmission to the next
2524: candidate server address.
2525:
2526: 7.3. Processing responses
2527:
2528: The first step in processing arriving response datagrams is to parse the
2529: response. This procedure should include:
2530:
2531: - Check the header for reasonableness. Discard datagrams which
2532: are queries when responses are expected.
2533:
2534: - Parse the sections of the message, and insure that all RRs are
2535: correctly formatted.
2536:
2537: - As an optional step, check the TTLs of arriving data looking
2538: for RRs with excessively long TTLs. If a RR has an
2539: excessively long TTL, say greater than 1 week, either discard
2540: the whole response, or limit all TTLs in the response to 1
2541: week.
2542:
2543: The next step is to match the response to a current resolver request.
2544: The recommended strategy is to do a preliminary matching using the ID
2545: field in the domain header, and then to verify that the question section
2546: corresponds to the information currently desired. This requires that
2547: the transmission algorithm devote several bits of the domain ID field to
2548: a request identifier of some sort. This step has several fine points:
2549:
2550: - Some name servers send their responses from different
2551: addresses than the one used to receive the query. That is, a
2552: resolver cannot rely that a response will come from the same
2553: address which it sent the corresponding query to. This name
2554: server bug is typically encountered in UNIX systems.
2555:
2556: - If the resolver retransmits a particular request to a name
2557: server it should be able to use a response from any of the
2558: transmissions. However, if it is using the response to sample
2559: the round trip time to access the name server, it must be able
2560: to determine which transmission matches the response (and keep
2561: transmission times for each outgoing message), or only
2562: calculate round trip times based on initial transmissions.
2563:
2564: - A name server will occasionally not have a current copy of a
2565: zone which it should have according to some NS RRs. The
2566: resolver should simply remove the name server from the current
2567: SLIST, and continue.
2568:
2569:
2570:
2571:
2572: Mockapetris [Page 46]
2573:
2574: RFC 1035 Domain Implementation and Specification November 1987
2575:
2576:
2577: 7.4. Using the cache
2578:
2579: In general, we expect a resolver to cache all data which it receives in
2580: responses since it may be useful in answering future client requests.
2581: However, there are several types of data which should not be cached:
2582:
2583: - When several RRs of the same type are available for a
2584: particular owner name, the resolver should either cache them
2585: all or none at all. When a response is truncated, and a
2586: resolver doesn't know whether it has a complete set, it should
2587: not cache a possibly partial set of RRs.
2588:
2589: - Cached data should never be used in preference to
2590: authoritative data, so if caching would cause this to happen
2591: the data should not be cached.
2592:
2593: - The results of an inverse query should not be cached.
2594:
2595: - The results of standard queries where the QNAME contains "*"
2596: labels if the data might be used to construct wildcards. The
2597: reason is that the cache does not necessarily contain existing
2598: RRs or zone boundary information which is necessary to
2599: restrict the application of the wildcard RRs.
2600:
2601: - RR data in responses of dubious reliability. When a resolver
2602: receives unsolicited responses or RR data other than that
2603: requested, it should discard it without caching it. The basic
2604: implication is that all sanity checks on a packet should be
2605: performed before any of it is cached.
2606:
2607: In a similar vein, when a resolver has a set of RRs for some name in a
2608: response, and wants to cache the RRs, it should check its cache for
2609: already existing RRs. Depending on the circumstances, either the data
2610: in the response or the cache is preferred, but the two should never be
2611: combined. If the data in the response is from authoritative data in the
2612: answer section, it is always preferred.
2613:
2614: 8. MAIL SUPPORT
2615:
2616: The domain system defines a standard for mapping mailboxes into domain
2617: names, and two methods for using the mailbox information to derive mail
2618: routing information. The first method is called mail exchange binding
2619: and the other method is mailbox binding. The mailbox encoding standard
2620: and mail exchange binding are part of the DNS official protocol, and are
2621: the recommended method for mail routing in the Internet. Mailbox
2622: binding is an experimental feature which is still under development and
2623: subject to change.
2624:
2625:
2626:
2627:
2628: Mockapetris [Page 47]
2629:
2630: RFC 1035 Domain Implementation and Specification November 1987
2631:
2632:
2633: The mailbox encoding standard assumes a mailbox name of the form
2634: "<local-part>@<mail-domain>". While the syntax allowed in each of these
2635: sections varies substantially between the various mail internets, the
2636: preferred syntax for the ARPA Internet is given in [RFC-822].
2637:
2638: The DNS encodes the <local-part> as a single label, and encodes the
2639: <mail-domain> as a domain name. The single label from the <local-part>
2640: is prefaced to the domain name from <mail-domain> to form the domain
2641: name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
2642: NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
2643: <local-part> contains dots or other special characters, its
2644: representation in a master file will require the use of backslash
2645: quoting to ensure that the domain name is properly encoded. For
2646: example, the mailbox [email protected] would be represented as
2647: Action\.domains.ISI.EDU.
2648:
2649: 8.1. Mail exchange binding
2650:
2651: Mail exchange binding uses the <mail-domain> part of a mailbox
2652: specification to determine where mail should be sent. The <local-part>
2653: is not even consulted. [RFC-974] specifies this method in detail, and
2654: should be consulted before attempting to use mail exchange support.
2655:
2656: One of the advantages of this method is that it decouples mail
2657: destination naming from the hosts used to support mail service, at the
2658: cost of another layer of indirection in the lookup function. However,
2659: the addition layer should eliminate the need for complicated "%", "!",
2660: etc encodings in <local-part>.
2661:
2662: The essence of the method is that the <mail-domain> is used as a domain
2663: name to locate type MX RRs which list hosts willing to accept mail for
2664: <mail-domain>, together with preference values which rank the hosts
2665: according to an order specified by the administrators for <mail-domain>.
2666:
2667: In this memo, the <mail-domain> ISI.EDU is used in examples, together
2668: with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
2669: ISI.EDU. If a mailer had a message for [email protected], it would
2670: route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
2671: VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
2672: addresses.
2673:
2674: 8.2. Mailbox binding (Experimental)
2675:
2676: In mailbox binding, the mailer uses the entire mail destination
2677: specification to construct a domain name. The encoded domain name for
2678: the mailbox is used as the QNAME field in a QTYPE=MAILB query.
2679:
2680: Several outcomes are possible for this query:
2681:
2682:
2683:
2684: Mockapetris [Page 48]
2685:
2686: RFC 1035 Domain Implementation and Specification November 1987
2687:
2688:
2689: 1. The query can return a name error indicating that the mailbox
2690: does not exist as a domain name.
2691:
2692: In the long term, this would indicate that the specified
2693: mailbox doesn't exist. However, until the use of mailbox
2694: binding is universal, this error condition should be
2695: interpreted to mean that the organization identified by the
2696: global part does not support mailbox binding. The
2697: appropriate procedure is to revert to exchange binding at
2698: this point.
2699:
2700: 2. The query can return a Mail Rename (MR) RR.
2701:
2702: The MR RR carries new mailbox specification in its RDATA
2703: field. The mailer should replace the old mailbox with the
2704: new one and retry the operation.
2705:
2706: 3. The query can return a MB RR.
2707:
2708: The MB RR carries a domain name for a host in its RDATA
2709: field. The mailer should deliver the message to that host
2710: via whatever protocol is applicable, e.g., b,SMTP.
2711:
2712: 4. The query can return one or more Mail Group (MG) RRs.
2713:
2714: This condition means that the mailbox was actually a mailing
2715: list or mail group, rather than a single mailbox. Each MG RR
2716: has a RDATA field that identifies a mailbox that is a member
2717: of the group. The mailer should deliver a copy of the
2718: message to each member.
2719:
2720: 5. The query can return a MB RR as well as one or more MG RRs.
2721:
2722: This condition means the the mailbox was actually a mailing
2723: list. The mailer can either deliver the message to the host
2724: specified by the MB RR, which will in turn do the delivery to
2725: all members, or the mailer can use the MG RRs to do the
2726: expansion itself.
2727:
2728: In any of these cases, the response may include a Mail Information
2729: (MINFO) RR. This RR is usually associated with a mail group, but is
2730: legal with a MB. The MINFO RR identifies two mailboxes. One of these
2731: identifies a responsible person for the original mailbox name. This
2732: mailbox should be used for requests to be added to a mail group, etc.
2733: The second mailbox name in the MINFO RR identifies a mailbox that should
2734: receive error messages for mail failures. This is particularly
2735: appropriate for mailing lists when errors in member names should be
2736: reported to a person other than the one who sends a message to the list.
2737:
2738:
2739:
2740: Mockapetris [Page 49]
2741:
2742: RFC 1035 Domain Implementation and Specification November 1987
2743:
2744:
2745: New fields may be added to this RR in the future.
2746:
2747:
2748: 9. REFERENCES and BIBLIOGRAPHY
2749:
2750: [Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
2751: Technical Plan - Name Service, April 1987, version 1.9.
2752:
2753: Describes the fundamentals of the Hesiod name service.
2754:
2755: [IEN-116] J. Postel, "Internet Name Server", IEN-116,
2756: USC/Information Sciences Institute, August 1979.
2757:
2758: A name service obsoleted by the Domain Name System, but
2759: still in use.
2760:
2761: [Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
2762: Communications of the ACM, October 1986, volume 29, number
2763: 10.
2764:
2765: [RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2766: Information Center, SRI International, December 1977.
2767:
2768: [RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2769: USC/Information Sciences Institute, August 1980.
2770:
2771: [RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2772: USC/Information Sciences Institute, September 1981.
2773:
2774: [RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2775: September 1981.
2776:
2777: Suggests introduction of a hierarchy in place of a flat
2778: name space for the Internet.
2779:
2780: [RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2781: USC/Information Sciences Institute, February 1982.
2782:
2783: [RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
2784: Internet Host Table Specification", RFC-810, Network
2785: Information Center, SRI International, March 1982.
2786:
2787: Obsolete. See RFC-952.
2788:
2789: [RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2790: Server", RFC-811, Network Information Center, SRI
2791: International, March 1982.
2792:
2793:
2794:
2795:
2796: Mockapetris [Page 50]
2797:
2798: RFC 1035 Domain Implementation and Specification November 1987
2799:
2800:
2801: Obsolete. See RFC-953.
2802:
2803: [RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2804: Network Information Center, SRI International, March
2805: 1982.
2806:
2807: [RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
2808: Internet User Applications", RFC-819, Network
2809: Information Center, SRI International, August 1982.
2810:
2811: Early thoughts on the design of the domain system.
2812: Current implementation is completely different.
2813:
2814: [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2815: USC/Information Sciences Institute, August 1980.
2816:
2817: [RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2818: RFC-830, Network Information Center, SRI International,
2819: October 1982.
2820:
2821: Early thoughts on the design of the domain system.
2822: Current implementation is completely different.
2823:
2824: [RFC-882] P. Mockapetris, "Domain names - Concepts and
2825: Facilities," RFC-882, USC/Information Sciences
2826: Institute, November 1983.
2827:
2828: Superceeded by this memo.
2829:
2830: [RFC-883] P. Mockapetris, "Domain names - Implementation and
2831: Specification," RFC-883, USC/Information Sciences
2832: Institute, November 1983.
2833:
2834: Superceeded by this memo.
2835:
2836: [RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2837: RFC-920, USC/Information Sciences Institute,
2838: October 1984.
2839:
2840: Explains the naming scheme for top level domains.
2841:
2842: [RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2843: Table Specification", RFC-952, SRI, October 1985.
2844:
2845: Specifies the format of HOSTS.TXT, the host/address
2846: table replaced by the DNS.
2847:
2848:
2849:
2850:
2851:
2852: Mockapetris [Page 51]
2853:
2854: RFC 1035 Domain Implementation and Specification November 1987
2855:
2856:
2857: [RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2858: RFC-953, SRI, October 1985.
2859:
2860: This RFC contains the official specification of the
2861: hostname server protocol, which is obsoleted by the DNS.
2862: This TCP based protocol accesses information stored in
2863: the RFC-952 format, and is used to obtain copies of the
2864: host table.
2865:
2866: [RFC-973] P. Mockapetris, "Domain System Changes and
2867: Observations", RFC-973, USC/Information Sciences
2868: Institute, January 1986.
2869:
2870: Describes changes to RFC-882 and RFC-883 and reasons for
2871: them.
2872:
2873: [RFC-974] C. Partridge, "Mail routing and the domain system",
2874: RFC-974, CSNET CIC BBN Labs, January 1986.
2875:
2876: Describes the transition from HOSTS.TXT based mail
2877: addressing to the more powerful MX system used with the
2878: domain system.
2879:
2880: [RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
2881: service on a TCP/UDP transport: Concepts and Methods",
2882: RFC-1001, March 1987.
2883:
2884: This RFC and RFC-1002 are a preliminary design for
2885: NETBIOS on top of TCP/IP which proposes to base NetBIOS
2886: name service on top of the DNS.
2887:
2888: [RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2889: service on a TCP/UDP transport: Detailed
2890: Specifications", RFC-1002, March 1987.
2891:
2892: [RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
2893: USC/Information Sciences Institute, May 1987.
2894:
2895: Contains socket numbers and mnemonics for host names,
2896: operating systems, etc.
2897:
2898: [RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2899: November 1987.
2900:
2901: Describes a plan for converting the MILNET to the DNS.
2902:
2903: [RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
2904: Administrators", RFC-1032, November 1987.
2905:
2906:
2907:
2908: Mockapetris [Page 52]
2909:
2910: RFC 1035 Domain Implementation and Specification November 1987
2911:
2912:
2913: Describes the registration policies used by the NIC to
2914: administer the top level domains and delegate subzones.
2915:
2916: [RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
2917: RFC-1033, November 1987.
2918:
2919: A cookbook for domain administrators.
2920:
2921: [Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2922: Name Server", Computer Networks, vol 6, nr 3, July 1982.
2923:
2924: Describes a name service for CSNET which is independent
2925: from the DNS and DNS use in the CSNET.
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:
2958:
2959:
2960:
2961:
2962:
2963:
2964: Mockapetris [Page 53]
2965:
2966: RFC 1035 Domain Implementation and Specification November 1987
2967:
2968:
2969: Index
2970:
2971: * 13
2972:
2973: ; 33, 35
2974:
2975: <character-string> 35
2976: <domain-name> 34
2977:
2978: @ 35
2979:
2980: \ 35
2981:
2982: A 12
2983:
2984: Byte order 8
2985:
2986: CH 13
2987: Character case 9
2988: CLASS 11
2989: CNAME 12
2990: Completion 42
2991: CS 13
2992:
2993: Hesiod 13
2994: HINFO 12
2995: HS 13
2996:
2997: IN 13
2998: IN-ADDR.ARPA domain 22
2999: Inverse queries 40
3000:
3001: Mailbox names 47
3002: MB 12
3003: MD 12
3004: MF 12
3005: MG 12
3006: MINFO 12
3007: MINIMUM 20
3008: MR 12
3009: MX 12
3010:
3011: NS 12
3012: NULL 12
3013:
3014: Port numbers 32
3015: Primary server 5
3016: PTR 12, 18
3017:
3018:
3019:
3020: Mockapetris [Page 54]
3021:
3022: RFC 1035 Domain Implementation and Specification November 1987
3023:
3024:
3025: QCLASS 13
3026: QTYPE 12
3027:
3028: RDATA 12
3029: RDLENGTH 11
3030:
3031: Secondary server 5
3032: SOA 12
3033: Stub resolvers 7
3034:
3035: TCP 32
3036: TXT 12
3037: TYPE 11
3038:
3039: UDP 32
3040:
3041: WKS 12
3042:
3043:
3044:
3045:
3046:
3047:
3048:
3049:
3050:
3051:
3052:
3053:
3054:
3055:
3056:
3057:
3058:
3059:
3060:
3061:
3062:
3063:
3064:
3065:
3066:
3067:
3068:
3069:
3070:
3071:
3072:
3073:
3074:
3075:
3076: Mockapetris [Page 55]
3077:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.