1 Network Working Group P. Mockapetris
2 Request for Comments: 1035 ISI
4 Obsoletes: RFCs 882, 883, 973
6 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
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].
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.
24 Experimental or obsolete features are clearly marked in these RFCs, and
25 such information should be used with caution.
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.
33 1. STATUS OF THIS MEMO 1
36 2.2. Common configurations 4
38 2.3.1. Preferred name syntax 7
39 2.3.2. Data Transmission Order 8
40 2.3.3. Character Case 9
42 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
43 3.1. Name space definitions 10
44 3.2. RR definitions 11
47 3.2.3. QTYPE values 12
48 3.2.4. CLASS values 13
54 RFC 1035 Domain Implementation and Specification November 1987
57 3.2.5. QCLASS values 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
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
89 5.2. Use of master files to define zones 35
90 5.3. Master file example 36
91 6. NAME SERVER IMPLEMENTATION 37
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
110 RFC 1035 Domain Implementation and Specification November 1987
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
120 8.1. Mail exchange binding 48
121 8.2. Mailbox binding (Experimental) 48
122 9. REFERENCES and BIBLIOGRAPHY 50
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.
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
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.
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
166 RFC 1035 Domain Implementation and Specification November 1987
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.
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.
179 2.2. Common configurations
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:
189 +---------+ +----------+ | +--------+
190 | | user queries | |queries | | |
191 | User |-------------->| |---------|->|Foreign |
192 | Program | | Resolver | | | Name |
193 | |<--------------| |<--------|--| Server |
194 | | user responses| |responses| | |
195 +---------+ +----------+ | +--------+
197 cache additions | | references |
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.
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
222 RFC 1035 Domain Implementation and Specification November 1987
225 in this memo, and may be datagrams.
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:
235 +---------+ | +----------+ | +--------+
236 | | | | |responses| | |
237 | | | | Name |---------|->|Foreign |
238 | Master |-------------->| Server | | |Resolver|
239 | files | | | |<--------|--| |
240 | |/ | | queries | +--------+
241 +---------+ +----------+ |
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.
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:
256 +---------+ | +----------+ | +--------+
257 | | | | |responses| | |
258 | | | | Name |---------|->|Foreign |
259 | Master |-------------->| Server | | |Resolver|
260 | files | | | |<--------|--| |
261 | |/ | | queries | +--------+
262 +---------+ +----------+ |
263 A |maintenance | +--------+
264 | +------------|->| |
265 | queries | |Foreign |
267 +------------------|--| Server |
268 maintenance responses | +--------+
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
278 RFC 1035 Domain Implementation and Specification November 1987
281 these maintenance activities follow the same form as queries and
282 responses, but the message sequences are somewhat different.
284 The information flow in a host that supports all aspects of the domain
285 name system is shown below:
289 +---------+ +----------+ | +--------+
290 | | user queries | |queries | | |
291 | User |-------------->| |---------|->|Foreign |
292 | Program | | Resolver | | | Name |
293 | |<--------------| |<--------|--| Server |
294 | | user responses| |responses| | |
295 +---------+ +----------+ | +--------+
297 cache additions | | references |
304 +---------+ refreshes | | references |
306 +---------+ | +----------+ | +--------+
307 | | | | |responses| | |
308 | | | | Name |---------|->|Foreign |
309 | Master |-------------->| Server | | |Resolver|
310 | files | | | |<--------|--| |
311 | |/ | | queries | +--------+
312 +---------+ +----------+ |
313 A |maintenance | +--------+
314 | +------------|->| |
315 | queries | |Foreign |
317 +------------------|--| Server |
318 maintenance responses | +--------+
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
334 RFC 1035 Domain Implementation and Specification November 1987
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:
349 Local Hosts | Foreign
353 | Stub |<--------------------+ |
355 | |----------------+ | |
356 +---------+ recursive | | |
359 +---------+ recursive +----------+ | +--------+
360 | | queries | |queries | | |
361 | Stub |-------------->| Recursive|---------|->|Foreign |
362 | Resolver| | Server | | | Name |
363 | |<--------------| |<--------|--| Server |
364 +---------+ responses | |responses| | |
365 +----------+ | +--------+
370 In any case, note that domain components are always replicated for
371 reliability whenever possible.
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.
380 2.3.1. Preferred name syntax
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.
390 RFC 1035 Domain Implementation and Specification November 1987
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.
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.
403 The following syntax will result in fewer problems with many
405 applications that use domain names (e.g., mail, TELNET).
407 <domain> ::= <subdomain> | " "
409 <subdomain> ::= <label> | <subdomain> "." <label>
411 <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
413 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
415 <let-dig-hyp> ::= <let-dig> | "-"
417 <let-dig> ::= <letter> | <digit>
419 <letter> ::= any one of the 52 alphabetic characters A through Z in
420 upper case and a through z in lower case
422 <digit> ::= any one of the ten digits 0 through 9
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.
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.
433 For example, the following strings identify hosts in the Internet:
435 A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
437 2.3.2. Data Transmission Order
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
446 RFC 1035 Domain Implementation and Specification November 1987
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.
454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
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
478 2.3.3. Character Case
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.
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
502 RFC 1035 Domain Implementation and Specification November 1987
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.
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.
519 Various objects and parameters in the DNS have size limits. They are
520 listed below. Some could be easily changed, others are more
523 labels 63 octets or less
525 names 255 octets or less
527 TTL positive values of a signed 32 bit number.
529 UDP messages 512 octets or less
531 3. DOMAIN NAME SPACE AND RR DEFINITIONS
533 3.1. Name space definitions
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
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
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.
556 Mockapetris [Page 10]
558 RFC 1035 Domain Implementation and Specification November 1987
565 All RRs have the same top level format shown below:
568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
569 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
574 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
576 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
578 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
581 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
583 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
586 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
591 NAME an owner name, i.e., the name of the node to which this
592 resource record pertains.
594 TYPE two octets containing one of the RR TYPE codes.
596 CLASS two octets containing one of the RR CLASS codes.
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.
607 RDLENGTH an unsigned 16 bit integer that specifies the length in
608 octets of the RDATA field.
612 Mockapetris [Page 11]
614 RFC 1035 Domain Implementation and Specification November 1987
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.
623 TYPE fields are used in resource records. Note that these types are a
626 TYPE value and meaning
630 NS 2 an authoritative name server
632 MD 3 a mail destination (Obsolete - use MX)
634 MF 4 a mail forwarder (Obsolete - use MX)
636 CNAME 5 the canonical name for an alias
638 SOA 6 marks the start of a zone of authority
640 MB 7 a mailbox domain name (EXPERIMENTAL)
642 MG 8 a mail group member (EXPERIMENTAL)
644 MR 9 a mail rename domain name (EXPERIMENTAL)
646 NULL 10 a null RR (EXPERIMENTAL)
648 WKS 11 a well known service description
650 PTR 12 a domain name pointer
652 HINFO 13 host information
654 MINFO 14 mailbox or mail list information
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:
668 Mockapetris [Page 12]
670 RFC 1035 Domain Implementation and Specification November 1987
673 AXFR 252 A request for a transfer of an entire zone
675 MAILB 253 A request for mailbox-related records (MB, MG or MR)
677 MAILA 254 A request for mail agent RRs (Obsolete - see MX)
679 * 255 A request for all records
683 CLASS fields appear in resource records. The following CLASS mnemonics
684 and values are defined:
688 CS 2 the CSNET class (Obsolete - used only for examples in
693 HS 4 Hesiod [Dyer 87]
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:
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.
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).
724 Mockapetris [Page 13]
726 RFC 1035 Domain Implementation and Specification November 1987
729 3.3.1. CNAME RDATA format
731 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
734 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
738 CNAME A <domain-name> which specifies the canonical or primary
739 name for the owner. The owner name is an alias.
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.
745 3.3.2. HINFO RDATA format
747 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
749 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
751 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
755 CPU A <character-string> which specifies the CPU type.
757 OS A <character-string> which specifies the operating
760 Standard values for CPU and OS can be found in [RFC-1010].
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.
766 3.3.3. MB RDATA format (EXPERIMENTAL)
768 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
771 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
775 MADNAME A <domain-name> which specifies a host which has the
780 Mockapetris [Page 14]
782 RFC 1035 Domain Implementation and Specification November 1987
785 MB records cause additional section processing which looks up an A type
786 RRs corresponding to MADNAME.
788 3.3.4. MD RDATA format (Obsolete)
790 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
793 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
797 MADNAME A <domain-name> which specifies a host which has a mail
798 agent for the domain which should be able to deliver
801 MD records cause additional section processing which looks up an A type
802 record corresponding to MADNAME.
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
809 3.3.5. MF RDATA format (Obsolete)
811 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
814 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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.
822 MF records cause additional section processing which looks up an A type
823 record corresponding to MADNAME.
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
836 Mockapetris [Page 15]
838 RFC 1035 Domain Implementation and Specification November 1987
841 3.3.6. MG RDATA format (EXPERIMENTAL)
843 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
846 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
850 MGMNAME A <domain-name> which specifies a mailbox which is a
851 member of the mail group specified by the domain name.
853 MG records cause no additional section processing.
855 3.3.7. MINFO RDATA format (EXPERIMENTAL)
857 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
859 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
861 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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.
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.
881 MINFO records cause no additional section processing. Although these
882 records can be associated with a simple mailbox, they are usually used
892 Mockapetris [Page 16]
894 RFC 1035 Domain Implementation and Specification November 1987
897 3.3.8. MR RDATA format (EXPERIMENTAL)
899 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
902 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
906 NEWNAME A <domain-name> which specifies a mailbox which is the
907 proper rename of the specified mailbox.
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
913 3.3.9. MX RDATA format
915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
917 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
920 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
924 PREFERENCE A 16 bit integer which specifies the preference given to
925 this RR among others at the same owner. Lower values
928 EXCHANGE A <domain-name> which specifies a host willing to act as
929 a mail exchange for the owner name.
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
935 3.3.10. NULL RDATA format (EXPERIMENTAL)
937 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
940 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
942 Anything at all may be in the RDATA field so long as it is 65535 octets
948 Mockapetris [Page 17]
950 RFC 1035 Domain Implementation and Specification November 1987
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.
957 3.3.11. NS RDATA format
959 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
962 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
966 NSDNAME A <domain-name> which specifies a host which should be
967 authoritative for the specified class and domain.
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.
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.
980 3.3.12. PTR RDATA format
982 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
984 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
988 PTRDNAME A <domain-name> which points to some location in the
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.
1004 Mockapetris [Page 18]
1006 RFC 1035 Domain Implementation and Specification November 1987
1009 3.3.13. SOA RDATA format
1011 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1014 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1016 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1019 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1022 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1025 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1028 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1031 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1035 MNAME The <domain-name> of the name server that was the
1036 original or primary source of data for this zone.
1038 RNAME A <domain-name> which specifies the mailbox of the
1039 person responsible for this zone.
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
1046 REFRESH A 32 bit time interval before the zone should be
1049 RETRY A 32 bit time interval that should elapse before a
1050 failed refresh should be retried.
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.
1060 Mockapetris [Page 19]
1062 RFC 1035 Domain Implementation and Specification November 1987
1065 MINIMUM The unsigned 32 bit minimum TTL field that should be
1066 exported with any RR from this zone.
1068 SOA records cause no additional section processing.
1070 All times are in units of seconds.
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.
1084 3.3.14. TXT RDATA format
1086 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1088 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1092 TXT-DATA One or more <character-string>s.
1094 TXT RRs are used to hold descriptive text. The semantics of the text
1095 depends on the domain where it is found.
1097 3.4. Internet specific RRs
1099 3.4.1. A RDATA format
1101 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1103 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1107 ADDRESS A 32 bit Internet address.
1109 Hosts that have multiple Internet addresses will have multiple A
1116 Mockapetris [Page 20]
1118 RFC 1035 Domain Implementation and Specification November 1987
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").
1126 3.4.2. WKS RDATA format
1128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1132 +--+--+--+--+--+--+--+--+ |
1136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1140 ADDRESS An 32 bit Internet address
1142 PROTOCOL An 8 bit IP protocol number
1144 <BIT MAP> A variable length bit map. The bit map must be a
1145 multiple of 8 bits long.
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].
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
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.
1164 WKS RRs cause no additional section processing.
1166 In master files, both ports and protocols are expressed using mnemonics
1172 Mockapetris [Page 21]
1174 RFC 1035 Domain Implementation and Specification November 1987
1177 3.5. IN-ADDR.ARPA domain
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
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.
1192 The domain begins at IN-ADDR.ARPA and has a substructure which follows
1193 the Internet addressing structure.
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
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.
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.
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.
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
1228 Mockapetris [Page 22]
1230 RFC 1035 Domain Implementation and Specification November 1987
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:
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.
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:
1253 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1254 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
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
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:
1264 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
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.
1271 - Gateways will often have two names in separate domains, only
1272 one of which can be primary.
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.
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.
1284 Mockapetris [Page 23]
1286 RFC 1035 Domain Implementation and Specification November 1987
1289 3.6. Defining new types, classes, and special namespaces
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 NAMEDROPPERS@SRI-NIC.ARPA is the
1295 forum where general discussion of design issues takes place.
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.
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.
1309 TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
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.
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.
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.
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
1340 Mockapetris [Page 24]
1342 RFC 1035 Domain Implementation and Specification November 1987
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.
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:
1357 +---------------------+
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 +---------------------+
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
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
1396 Mockapetris [Page 25]
1398 RFC 1035 Domain Implementation and Specification November 1987
1401 4.1.1. Header section format
1403 The header contains the following fields:
1406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1410 |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
1411 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1417 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1419 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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.
1428 QR A one bit field that specifies whether this message is a
1429 query (0), or a response (1).
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:
1435 0 a standard query (QUERY)
1437 1 an inverse query (IQUERY)
1439 2 a server status request (STATUS)
1441 3-15 reserved for future use
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.
1447 Note that the contents of the answer section may have
1448 multiple owner names because of aliases. The AA bit
1452 Mockapetris [Page 26]
1454 RFC 1035 Domain Implementation and Specification November 1987
1457 corresponds to the name which matches the query name, or
1458 the first owner name in the answer section.
1460 TC TrunCation - specifies that this message was truncated
1461 due to length greater than that permitted on the
1462 transmission channel.
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.
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.
1473 Z Reserved for future use. Must be zero in all queries
1476 RCODE Response code - this 4 bit field is set as part of
1477 responses. The values have the following
1480 0 No error condition
1482 1 Format error - The name server was
1483 unable to interpret the query.
1485 2 Server failure - The name server was
1486 unable to process this query due to a
1487 problem with the name server.
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
1495 4 Not Implemented - The name server does
1496 not support the requested kind of query.
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
1508 Mockapetris [Page 27]
1510 RFC 1035 Domain Implementation and Specification November 1987
1513 transfer) for particular data.
1515 6-15 Reserved for future use.
1517 QDCOUNT an unsigned 16 bit integer specifying the number of
1518 entries in the question section.
1520 ANCOUNT an unsigned 16 bit integer specifying the number of
1521 resource records in the answer section.
1523 NSCOUNT an unsigned 16 bit integer specifying the number of name
1524 server resource records in the authority records
1527 ARCOUNT an unsigned 16 bit integer specifying the number of
1528 resource records in the additional records section.
1530 4.1.2. Question section format
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:
1537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1538 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1542 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1544 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1546 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
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.
1564 Mockapetris [Page 28]
1566 RFC 1035 Domain Implementation and Specification November 1987
1569 QCLASS a two octet code that specifies the class of the query.
1570 For example, the QCLASS field is IN for the Internet.
1572 4.1.3. Resource record format
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:
1579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1580 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1585 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1587 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1589 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1592 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1594 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
1597 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1601 NAME a domain name to which this resource record pertains.
1603 TYPE two octets containing one of the RR type codes. This
1604 field specifies the meaning of the data in the RDATA
1607 CLASS two octets which specify the class of the data in the
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.
1620 Mockapetris [Page 29]
1622 RFC 1035 Domain Implementation and Specification November 1987
1625 RDLENGTH an unsigned 16 bit integer that specifies the length in
1626 octets of the RDATA field.
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.
1634 4.1.4. Message compression
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
1642 The pointer takes the form of a two octet sequence:
1644 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1646 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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,
1656 The compression scheme allows a domain name in a message to be
1657 represented as either:
1659 - a sequence of labels ending in a zero octet
1663 - a sequence of labels ending with a pointer
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
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
1676 Mockapetris [Page 30]
1678 RFC 1035 Domain Implementation and Specification November 1987
1681 used, the length of the compressed name is used in the length
1682 calculation, rather than the length of the expanded name.
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
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:
1693 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1695 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1697 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1699 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1701 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1703 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1705 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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
1732 Mockapetris [Page 31]
1734 RFC 1035 Domain Implementation and Specification November 1987
1737 defined by a single octet of zeros at 92; the root domain name has no
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.
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
1754 Messages sent using UDP user server port 53 (decimal).
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
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.
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:
1769 - The client should try other servers and server addresses
1770 before repeating a query to a specific address of a server.
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.
1778 More suggestions on server selection and retransmission policy can be
1779 found in the resolver section of this memo.
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
1788 Mockapetris [Page 32]
1790 RFC 1035 Domain Implementation and Specification November 1987
1793 length, excluding the two byte length field. This length field allows
1794 the low-level processing to assemble a complete message before beginning
1797 Several connection management policies are recommended:
1799 - The server should not block other activities waiting for TCP
1802 - The server should support multiple connections.
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
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
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.
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).
1837 The following entries are defined:
1844 Mockapetris [Page 33]
1846 RFC 1035 Domain Implementation and Specification November 1987
1849 $ORIGIN <domain-name> [<comment>]
1851 $INCLUDE <file-name> [<domain-name>] [<comment>]
1853 <domain-name><rr> [<comment>]
1855 <blank><rr> [<comment>]
1857 Blank lines, with or without comments, are allowed anywhere in the file.
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.
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.
1872 <rr> contents take one of the following forms:
1874 [<TTL>] [<class>] <type> <RDATA>
1876 [<class>] [<TTL>] <type> <RDATA>
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.)
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.
1900 Mockapetris [Page 34]
1902 RFC 1035 Domain Implementation and Specification November 1987
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).
1910 Because these files are text files several special encodings are
1911 necessary to allow arbitrary data to be loaded. In particular:
1915 @ A free standing @ is used to denote the current origin.
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.
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
1927 ( ) Parentheses are used to group data that crosses a line
1928 boundary. In effect, line terminations are not
1929 recognized within parentheses.
1931 ; Semicolon is used to start a comment; the remainder of
1932 the line is ignored.
1934 5.2. Use of master files to define zones
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).
1944 Several other validity checks that should be performed in addition to
1945 insuring that the file is syntactically correct:
1947 1. All RRs in the file should have the same class.
1949 2. Exactly one SOA RR should be present at the top of the zone.
1951 3. If delegations are present and glue information is required,
1952 it should be present.
1956 Mockapetris [Page 35]
1958 RFC 1035 Domain Implementation and Specification November 1987
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.
1965 5.3. Master file example
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:
1970 @ IN SOA VENERA Action\.domains (
1992 $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
1994 Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
1998 CURLEY MB A.ISI.EDU.
2003 Note the use of the \ character in the SOA RR to specify the responsible
2004 person mailbox "Action.domains@E.ISI.EDU".
2012 Mockapetris [Page 36]
2014 RFC 1035 Domain Implementation and Specification November 1987
2017 6. NAME SERVER IMPLEMENTATION
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.
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.
2044 While name server implementations are free to use any internal data
2045 structures they choose, the suggested structure consists of three major
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.
2053 - Separate data structures for each of the zones held by the
2056 - A data structure for cached data. (or perhaps separate caches
2057 for different classes)
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
2068 Mockapetris [Page 37]
2070 RFC 1035 Domain Implementation and Specification November 1987
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).
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
2087 The use of separate structures for the different parts of the database
2088 is motivated by several factors:
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
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
2104 - With the proper search procedures, authoritative data in zones
2105 will always "hide", and hence take precedence over, cached
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.
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.
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
2124 Mockapetris [Page 38]
2126 RFC 1035 Domain Implementation and Specification November 1987
2129 includes the catalog structure (including the state of refreshing for
2130 each zone) and the zone data itself.
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.
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.
2148 6.2. Standard query processing
2150 The major algorithm for standard query processing is presented in
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.
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.
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.
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
2172 6.3. Zone refresh and reload processing
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
2180 Mockapetris [Page 39]
2182 RFC 1035 Domain Implementation and Specification November 1987
2185 should answer queries as if it were not supposed to possess the zone.
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.
2193 6.4. Inverse queries (Optional)
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.
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.
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.
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
2229 When a name server processes an inverse query, it either returns:
2231 1. zero, one, or multiple domain names for the specified
2232 resource as QNAMEs in the question section
2236 Mockapetris [Page 40]
2238 RFC 1035 Domain Implementation and Specification November 1987
2241 2. an error code indicating that the name server doesn't support
2242 inverse mapping of the specified resource type.
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
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.
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:
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 +-----------------------------------------+
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:
2292 Mockapetris [Page 41]
2294 RFC 1035 Domain Implementation and Specification November 1987
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 +-----------------------------------------+
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.
2316 6.4.3. Inverse query processing
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.
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
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.
2331 6.5. Completion queries and responses
2333 The optional completion services described in RFC-882 and RFC-883 have
2334 been deleted. Redesigned services may become available in the future.
2348 Mockapetris [Page 42]
2350 RFC 1035 Domain Implementation and Specification November 1987
2353 7. RESOLVER IMPLEMENTATION
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
2360 7.1. Transforming a user request into a query
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
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
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.
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.
2394 - Some sort of parameters to limit the amount of work which will
2395 be performed for this request.
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
2404 Mockapetris [Page 43]
2406 RFC 1035 Domain Implementation and Specification November 1987
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.
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
2427 - The SLIST data structure discussed in [RFC-1034].
2429 This structure keeps track of the state of a request if it
2430 must wait for answers from foreign name servers.
2432 7.2. Sending the queries
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
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
2460 Mockapetris [Page 44]
2462 RFC 1035 Domain Implementation and Specification November 1987
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.
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.
2491 Note that whenever a delegation is followed, the resolver algorithm
2492 reinitializes SLIST.
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.
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.
2516 Mockapetris [Page 45]
2518 RFC 1035 Domain Implementation and Specification November 1987
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.
2526 7.3. Processing responses
2528 The first step in processing arriving response datagrams is to parse the
2529 response. This procedure should include:
2531 - Check the header for reasonableness. Discard datagrams which
2532 are queries when responses are expected.
2534 - Parse the sections of the message, and insure that all RRs are
2535 correctly formatted.
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
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:
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.
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.
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.
2572 Mockapetris [Page 46]
2574 RFC 1035 Domain Implementation and Specification November 1987
2577 7.4. Using the cache
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:
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.
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.
2593 - The results of an inverse query should not be cached.
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.
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.
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.
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
2628 Mockapetris [Page 47]
2630 RFC 1035 Domain Implementation and Specification November 1987
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].
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 Action.domains@ISI.EDU would be represented as
2647 Action\.domains.ISI.EDU.
2649 8.1. Mail exchange binding
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.
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>.
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>.
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 Mockapetris@ISI.EDU, 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
2674 8.2. Mailbox binding (Experimental)
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.
2680 Several outcomes are possible for this query:
2684 Mockapetris [Page 48]
2686 RFC 1035 Domain Implementation and Specification November 1987
2689 1. The query can return a name error indicating that the mailbox
2690 does not exist as a domain name.
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
2700 2. The query can return a Mail Rename (MR) RR.
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.
2706 3. The query can return a MB RR.
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.
2712 4. The query can return one or more Mail Group (MG) RRs.
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.
2720 5. The query can return a MB RR as well as one or more MG RRs.
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
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.
2740 Mockapetris [Page 49]
2742 RFC 1035 Domain Implementation and Specification November 1987
2745 New fields may be added to this RR in the future.
2748 9. REFERENCES and BIBLIOGRAPHY
2750 [Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
2751 Technical Plan - Name Service, April 1987, version 1.9.
2753 Describes the fundamentals of the Hesiod name service.
2755 [IEN-116] J. Postel, "Internet Name Server", IEN-116,
2756 USC/Information Sciences Institute, August 1979.
2758 A name service obsoleted by the Domain Name System, but
2761 [Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
2762 Communications of the ACM, October 1986, volume 29, number
2765 [RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2766 Information Center, SRI International, December 1977.
2768 [RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2769 USC/Information Sciences Institute, August 1980.
2771 [RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2772 USC/Information Sciences Institute, September 1981.
2774 [RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2777 Suggests introduction of a hierarchy in place of a flat
2778 name space for the Internet.
2780 [RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2781 USC/Information Sciences Institute, February 1982.
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.
2787 Obsolete. See RFC-952.
2789 [RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2790 Server", RFC-811, Network Information Center, SRI
2791 International, March 1982.
2796 Mockapetris [Page 50]
2798 RFC 1035 Domain Implementation and Specification November 1987
2801 Obsolete. See RFC-953.
2803 [RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2804 Network Information Center, SRI International, March
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.
2811 Early thoughts on the design of the domain system.
2812 Current implementation is completely different.
2814 [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2815 USC/Information Sciences Institute, August 1980.
2817 [RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2818 RFC-830, Network Information Center, SRI International,
2821 Early thoughts on the design of the domain system.
2822 Current implementation is completely different.
2824 [RFC-882] P. Mockapetris, "Domain names - Concepts and
2825 Facilities," RFC-882, USC/Information Sciences
2826 Institute, November 1983.
2828 Superceeded by this memo.
2830 [RFC-883] P. Mockapetris, "Domain names - Implementation and
2831 Specification," RFC-883, USC/Information Sciences
2832 Institute, November 1983.
2834 Superceeded by this memo.
2836 [RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2837 RFC-920, USC/Information Sciences Institute,
2840 Explains the naming scheme for top level domains.
2842 [RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2843 Table Specification", RFC-952, SRI, October 1985.
2845 Specifies the format of HOSTS.TXT, the host/address
2846 table replaced by the DNS.
2852 Mockapetris [Page 51]
2854 RFC 1035 Domain Implementation and Specification November 1987
2857 [RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2858 RFC-953, SRI, October 1985.
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
2866 [RFC-973] P. Mockapetris, "Domain System Changes and
2867 Observations", RFC-973, USC/Information Sciences
2868 Institute, January 1986.
2870 Describes changes to RFC-882 and RFC-883 and reasons for
2873 [RFC-974] C. Partridge, "Mail routing and the domain system",
2874 RFC-974, CSNET CIC BBN Labs, January 1986.
2876 Describes the transition from HOSTS.TXT based mail
2877 addressing to the more powerful MX system used with the
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.
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.
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.
2892 [RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
2893 USC/Information Sciences Institute, May 1987.
2895 Contains socket numbers and mnemonics for host names,
2896 operating systems, etc.
2898 [RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2901 Describes a plan for converting the MILNET to the DNS.
2903 [RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
2904 Administrators", RFC-1032, November 1987.
2908 Mockapetris [Page 52]
2910 RFC 1035 Domain Implementation and Specification November 1987
2913 Describes the registration policies used by the NIC to
2914 administer the top level domains and delegate subzones.
2916 [RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
2917 RFC-1033, November 1987.
2919 A cookbook for domain administrators.
2921 [Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2922 Name Server", Computer Networks, vol 6, nr 3, July 1982.
2924 Describes a name service for CSNET which is independent
2925 from the DNS and DNS use in the CSNET.
2964 Mockapetris [Page 53]
2966 RFC 1035 Domain Implementation and Specification November 1987
2975 <character-string> 35
2998 IN-ADDR.ARPA domain 22
3020 Mockapetris [Page 54]
3022 RFC 1035 Domain Implementation and Specification November 1987
3076 Mockapetris [Page 55]
projects / connman / blob