1Network Working Group P. Mockapetris
2Request for Comments: 1035 ISI
4Obsoletes: RFCs 882, 883, 973
6 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
11This RFC describes the details of the domain system and protocol, and
12assumes that the reader is familiar with the concepts discussed in a
13companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
15The domain system is a mixture of functions and data types which are an
16official protocol and functions and data types which are still
17experimental. Since the domain system is intentionally extensible, new
18data types and experimental behavior should always be expected in parts
19of the system beyond the official protocol. The official protocol parts
20include standard queries, responses and the Internet class RR data
21formats (e.g., host addresses). Since the previous RFC set, several
22definitions have changed, so some previous definitions are obsolete.
24Experimental or obsolete features are clearly marked in these RFCs, and
25such information should be used with caution.
27The reader is especially cautioned not to depend on the values which
28appear in examples to be current or complete, since their purpose is
29primarily 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
54RFC 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
110RFC 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
129The goal of domain names is to provide a mechanism for naming resources
130in such a way that the names are usable in different hosts, networks,
131protocol families, internets, and administrative organizations.
133From the user's point of view, domain names are useful as arguments to a
134local agent, called a resolver, which retrieves information associated
135with the domain name. Thus a user might ask for the host address or
136mail information associated with a particular domain name. To enable
137the user to request a particular type of information, an appropriate
138query type is passed to the resolver with the domain name. To the user,
139the domain tree is a single information space; the resolver is
140responsible for hiding the distribution of data among name servers from
143From the resolver's point of view, the database that makes up the domain
144space is distributed among various name servers. Different parts of the
145domain space are stored in different name servers, although a particular
146data item will be stored redundantly in two or more name servers. The
147resolver starts with knowledge of at least one name server. When the
148resolver processes a user query it asks a known name server for the
149information; in return, the resolver either receives the desired
150information or a referral to another name server. Using these
151referrals, resolvers learn the identities and contents of other name
152servers. Resolvers are responsible for dealing with the distribution of
153the domain space and dealing with the effects of name server failure by
154consulting redundant databases in other servers.
156Name servers manage two kinds of data. The first kind of data held in
157sets called zones; each zone is the complete database for a particular
158"pruned" subtree of the domain space. This data is called
159authoritative. A name server periodically checks to make sure that its
160zones are up to date, and if not, obtains a new copy of updated zones
166RFC 1035 Domain Implementation and Specification November 1987
169from master files stored locally or in another name server. The second
170kind of data is cached data which was acquired by a local resolver.
171This data may be incomplete, but improves the performance of the
172retrieval process when non-local data is repeatedly accessed. Cached
173data is eventually discarded by a timeout mechanism.
175This functional structure isolates the problems of user interface,
176failure recovery, and distribution in the resolvers and isolates the
177database update and refresh problems in the name servers.
1792.2. Common configurations
181A host can participate in the domain name system in a number of ways,
182depending on whether the host runs programs that retrieve information
183from the domain system, name servers that answer queries from other
184hosts, or various combinations of both functions. The simplest, and
185perhaps 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 |
203User programs interact with the domain name space through resolvers; the
204format of user queries and user responses is specific to the host and
205its operating system. User queries will typically be operating system
206calls, and the resolver and its cache will be part of the host operating
207system. Less capable hosts may choose to implement the resolver as a
208subroutine to be linked in with every program that needs its services.
209Resolvers answer user queries with information they acquire via queries
210to foreign name servers and the local cache.
212Note that the resolver may have to make several queries to several
213different foreign name servers to answer a particular user query, and
214hence the resolution of a user query may involve several network
215accesses and an arbitrary amount of time. The queries to foreign name
216servers and the corresponding responses have a standard format described
222RFC 1035 Domain Implementation and Specification November 1987
225in this memo, and may be datagrams.
227Depending on its capabilities, a name server could be a stand alone
228program on a dedicated machine or a process or processes on a large
229timeshared host. A simple configuration might be:
235 +---------+ | +----------+ | +--------+
236 | | | | |responses| | |
237 | | | | Name |---------|->|Foreign |
238 | Master |-------------->| Server | | |Resolver|
239 | files | | | |<--------|--| |
240 | |/ | | queries | +--------+
241 +---------+ +----------+ |
243Here a primary name server acquires information about one or more zones
244by reading master files from its local file system, and answers queries
245about those zones that arrive from foreign resolvers.
247The DNS requires that all zones be redundantly supported by more than
248one name server. Designated secondary servers can acquire zones and
249check for updates from the primary server using the zone transfer
250protocol 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 | +--------+
270In this configuration, the name server periodically establishes a
271virtual circuit to a foreign name server to acquire a copy of a zone or
272to check that an existing copy has not changed. The messages sent for
278RFC 1035 Domain Implementation and Specification November 1987
281these maintenance activities follow the same form as queries and
282responses, but the message sequences are somewhat different.
284The information flow in a host that supports all aspects of the domain
285name 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 | +--------+
320The shared database holds domain space data for the local name server
321and resolver. The contents of the shared database will typically be a
322mixture of authoritative data maintained by the periodic refresh
323operations of the name server and cached data from previous resolver
324requests. The structure of the domain data and the necessity for
325synchronization between name servers and resolvers imply the general
326characteristics of this database, but the actual format is up to the
334RFC 1035 Domain Implementation and Specification November 1987
337Information flow can also be tailored so that a group of hosts act
338together to optimize activities. Sometimes this is done to offload less
339capable hosts so that they do not have to implement a full resolver.
340This can be appropriate for PCs or hosts which want to minimize the
341amount of new network code which is required. This scheme can also
342allow a group of hosts can share a small number of caches rather than
343maintaining a large number of separate caches, on the premise that the
344centralized caches will have a higher hit ratio. In either case,
345resolvers are replaced with stub resolvers which act as front ends to
346resolvers located in a recursive server in one or more name servers
347known 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 +----------+ | +--------+
370In any case, note that domain components are always replicated for
371reliability whenever possible.
375The domain system has several conventions dealing with low-level, but
376fundamental, issues. While the implementor is free to violate these
377conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
378ALL behavior observed from other hosts.
3802.3.1. Preferred name syntax
382The DNS specifications attempt to be as general as possible in the rules
383for constructing domain names. The idea is that the name of any
384existing object can be expressed as a domain name with minimal changes.
390RFC 1035 Domain Implementation and Specification November 1987
393However, when assigning a domain name for an object, the prudent user
394will select a name which satisfies both the rules of the domain system
395and any existing rules for the object, whether these rules are published
396or implied by existing programs.
398For example, when naming a mail domain, the user should satisfy both the
399rules of this memo and those in RFC-822. When creating a new host name,
400the old rules for HOSTS.TXT should be followed. This avoids problems
401when old software is converted to use domain names.
403The following syntax will result in fewer problems with many
405applications 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
420upper case and a through z in lower case
422<digit> ::= any one of the ten digits 0 through 9
424Note that while upper and lower case letters are allowed in domain
425names, no significance is attached to the case. That is, two names with
426the same spelling but different case are to be treated as if identical.
428The labels must follow the rules for ARPANET host names. They must
429start with a letter, end with a letter or digit, and have as interior
430characters only letters, digits, and hyphen. There are also some
431restrictions on the length. Labels must be 63 characters or less.
433For example, the following strings identify hosts in the Internet:
435A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
4372.3.2. Data Transmission Order
439The order of transmission of the header and data described in this
440document is resolved to the octet level. Whenever a diagram shows a
446RFC 1035 Domain Implementation and Specification November 1987
449group of octets, the order of transmission of those octets is the normal
450order in which they are read in English. For example, in the following
451diagram, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
463Whenever an octet represents a numeric quantity, the left most bit in
464the diagram is the high order or most significant bit. That is, the bit
465labeled 0 is the most significant bit. For example, the following
466diagram represents the value 170 (decimal).
473Similarly, whenever a multi-octet field represents a numeric quantity
474the left most bit of the whole field is the most significant bit. When
475a multi-octet quantity is transmitted the most significant octet is
480For all parts of the DNS that are part of the official protocol, all
481comparisons between character strings (e.g., labels, domain names, etc.)
482are done in a case-insensitive manner. At present, this rule is in
483force throughout the domain system without exception. However, future
484additions beyond current usage may need to use the full binary octet
485capabilities in names, so attempts to store domain names in 7-bit ASCII
486or use of special bytes to terminate labels, etc., should be avoided.
488When data enters the domain system, its original case should be
489preserved whenever possible. In certain circumstances this cannot be
490done. For example, if two RRs are stored in a database, one at x.y and
491one at X.Y, they are actually stored at the same place in the database,
492and hence only one casing would be preserved. The basic rule is that
493case can be discarded only when data is used to define structure in a
494database, and two names are identical when compared in a case
502RFC 1035 Domain Implementation and Specification November 1987
505Loss of case sensitive data must be minimized. Thus while data for x.y
506and X.Y may both be stored under a single location x.y or X.Y, data for
507a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
508general, this preserves the case of the first label of a domain name,
509but forces standardization of interior node labels.
511Systems administrators who enter data into the domain database should
512take care to represent the data they supply to the domain system in a
513case-consistent manner if their system is case-sensitive. The data
514distribution system in the domain system will ensure that consistent
515representations are preserved.
519Various objects and parameters in the DNS have size limits. They are
520listed below. Some could be easily changed, others are more
523labels 63 octets or less
525names 255 octets or less
527TTL positive values of a signed 32 bit number.
529UDP messages 512 octets or less
5313. DOMAIN NAME SPACE AND RR DEFINITIONS
5333.1. Name space definitions
535Domain names in messages are expressed in terms of a sequence of labels.
536Each label is represented as a one octet length field followed by that
537number of octets. Since every domain name ends with the null label of
538the root, a domain name is terminated by a length byte of zero. The
539high order two bits of every length octet must be zero, and the
540remaining six bits of the length field limit the label to 63 octets or
543To simplify implementations, the total length of a domain name (i.e.,
544label octets and label length octets) is restricted to 255 octets or
547Although labels can contain any 8 bit values in octets that make up a
548label, it is strongly recommended that labels follow the preferred
549syntax described elsewhere in this memo, which is compatible with
550existing host naming conventions. Name servers and resolvers must
551compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
552with zero parity. Non-alphabetic codes must match exactly.
558RFC 1035 Domain Implementation and Specification November 1987
565All 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
591NAME an owner name, i.e., the name of the node to which this
592 resource record pertains.
594TYPE two octets containing one of the RR TYPE codes.
596CLASS two octets containing one of the RR CLASS codes.
598TTL 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.
607RDLENGTH an unsigned 16 bit integer that specifies the length in
608 octets of the RDATA field.
614RFC 1035 Domain Implementation and Specification November 1987
617RDATA 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.
623TYPE fields are used in resource records. Note that these types are a
626TYPE value and meaning
630NS 2 an authoritative name server
632MD 3 a mail destination (Obsolete - use MX)
634MF 4 a mail forwarder (Obsolete - use MX)
636CNAME 5 the canonical name for an alias
638SOA 6 marks the start of a zone of authority
640MB 7 a mailbox domain name (EXPERIMENTAL)
642MG 8 a mail group member (EXPERIMENTAL)
644MR 9 a mail rename domain name (EXPERIMENTAL)
646NULL 10 a null RR (EXPERIMENTAL)
648WKS 11 a well known service description
650PTR 12 a domain name pointer
652HINFO 13 host information
654MINFO 14 mailbox or mail list information
662QTYPE fields appear in the question part of a query. QTYPES are a
663superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
664following QTYPEs are defined:
670RFC 1035 Domain Implementation and Specification November 1987
673AXFR 252 A request for a transfer of an entire zone
675MAILB 253 A request for mailbox-related records (MB, MG or MR)
677MAILA 254 A request for mail agent RRs (Obsolete - see MX)
679* 255 A request for all records
683CLASS fields appear in resource records. The following CLASS mnemonics
684and values are defined:
688CS 2 the CSNET class (Obsolete - used only for examples in
697QCLASS fields appear in the question section of a query. QCLASS values
698are a superset of CLASS values; every CLASS is a valid QCLASS. In
699addition to CLASS values, the following QCLASSes are defined:
705The following RR definitions are expected to occur, at least
706potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
707will be used in all classes, and have the same format in all classes.
708Because their RDATA format is known, all domain names in the RDATA
709section of these RRs may be compressed.
711<domain-name> is a domain name represented as a series of labels, and
712terminated by a label with zero length. <character-string> is a single
713length octet followed by that number of characters. <character-string>
714is treated as binary information, and can be up to 256 characters in
715length (including the length octet).
726RFC 1035 Domain Implementation and Specification November 1987
7293.3.1. CNAME RDATA format
731 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
734 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
738CNAME A <domain-name> which specifies the canonical or primary
739 name for the owner. The owner name is an alias.
741CNAME RRs cause no additional section processing, but name servers may
742choose to restart the query at the canonical name in certain cases. See
743the description of name server logic in [RFC-1034] for details.
7453.3.2. HINFO RDATA format
747 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
749 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
751 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
755CPU A <character-string> which specifies the CPU type.
757OS A <character-string> which specifies the operating
760Standard values for CPU and OS can be found in [RFC-1010].
762HINFO records are used to acquire general information about a host. The
763main use is for protocols such as FTP that can use special procedures
764when talking between machines or operating systems of the same type.
7663.3.3. MB RDATA format (EXPERIMENTAL)
768 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
771 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
775MADNAME A <domain-name> which specifies a host which has the
782RFC 1035 Domain Implementation and Specification November 1987
785MB records cause additional section processing which looks up an A type
786RRs corresponding to MADNAME.
7883.3.4. MD RDATA format (Obsolete)
790 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
793 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
797MADNAME A <domain-name> which specifies a host which has a mail
798 agent for the domain which should be able to deliver
801MD records cause additional section processing which looks up an A type
802record corresponding to MADNAME.
804MD is obsolete. See the definition of MX and [RFC-974] for details of
805the new scheme. The recommended policy for dealing with MD RRs found in
806a master file is to reject them, or to convert them to MX RRs with a
8093.3.5. MF RDATA format (Obsolete)
811 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
814 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
818MADNAME 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.
822MF records cause additional section processing which looks up an A type
823record corresponding to MADNAME.
825MF is obsolete. See the definition of MX and [RFC-974] for details ofw
826the new scheme. The recommended policy for dealing with MD RRs found in
827a master file is to reject them, or to convert them to MX RRs with a
838RFC 1035 Domain Implementation and Specification November 1987
8413.3.6. MG RDATA format (EXPERIMENTAL)
843 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
846 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
850MGMNAME A <domain-name> which specifies a mailbox which is a
851 member of the mail group specified by the domain name.
853MG records cause no additional section processing.
8553.3.7. MINFO RDATA format (EXPERIMENTAL)
857 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
859 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
861 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
865RMAILBX 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.
874EMAILBX 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.
881MINFO records cause no additional section processing. Although these
882records can be associated with a simple mailbox, they are usually used
894RFC 1035 Domain Implementation and Specification November 1987
8973.3.8. MR RDATA format (EXPERIMENTAL)
899 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
902 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
906NEWNAME A <domain-name> which specifies a mailbox which is the
907 proper rename of the specified mailbox.
909MR records cause no additional section processing. The main use for MR
910is as a forwarding entry for a user who has moved to a different
9133.3.9. MX RDATA format
915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
917 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
920 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
924PREFERENCE A 16 bit integer which specifies the preference given to
925 this RR among others at the same owner. Lower values
928EXCHANGE A <domain-name> which specifies a host willing to act as
929 a mail exchange for the owner name.
931MX records cause type A additional section processing for the host
932specified by EXCHANGE. The use of MX RRs is explained in detail in
9353.3.10. NULL RDATA format (EXPERIMENTAL)
937 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
940 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
942Anything at all may be in the RDATA field so long as it is 65535 octets
950RFC 1035 Domain Implementation and Specification November 1987
953NULL records cause no additional section processing. NULL RRs are not
954allowed in master files. NULLs are used as placeholders in some
955experimental extensions of the DNS.
9573.3.11. NS RDATA format
959 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
962 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
966NSDNAME A <domain-name> which specifies a host which should be
967 authoritative for the specified class and domain.
969NS records cause both the usual additional section processing to locate
970a type A record, and, when used in a referral, a special search of the
971zone in which they reside for glue information.
973The NS RR states that the named host should be expected to have a zone
974starting at owner name of the specified class. Note that the class may
975not indicate the protocol family which should be used to communicate
976with the host, although it is typically a strong hint. For example,
977hosts which are name servers for either Internet (IN) or Hesiod (HS)
978class information are normally queried using IN class protocols.
9803.3.12. PTR RDATA format
982 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
984 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
988PTRDNAME A <domain-name> which points to some location in the
991PTR records cause no additional section processing. These RRs are used
992in special domains to point to some other location in the domain space.
993These records are simple data, and don't imply any special processing
994similar to that performed by CNAME, which identifies aliases. See the
995description of the IN-ADDR.ARPA domain for an example.
1004Mockapetris [Page 18]
1006RFC 1035 Domain Implementation and Specification November 1987
10093.3.13. SOA RDATA format
1011 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1014 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1016 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1019 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1022 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1025 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1028 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1031 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1035MNAME The <domain-name> of the name server that was the
1036 original or primary source of data for this zone.
1038RNAME A <domain-name> which specifies the mailbox of the
1039 person responsible for this zone.
1041SERIAL 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
1046REFRESH A 32 bit time interval before the zone should be
1049RETRY A 32 bit time interval that should elapse before a
1050 failed refresh should be retried.
1052EXPIRE 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.
1060Mockapetris [Page 19]
1062RFC 1035 Domain Implementation and Specification November 1987
1065MINIMUM The unsigned 32 bit minimum TTL field that should be
1066 exported with any RR from this zone.
1068SOA records cause no additional section processing.
1070All times are in units of seconds.
1072Most of these fields are pertinent only for name server maintenance
1073operations. However, MINIMUM is used in all query operations that
1074retrieve RRs from a zone. Whenever a RR is sent in a response to a
1075query, the TTL field is set to the maximum of the TTL field from the RR
1076and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
1077bound on the TTL field for all RRs in a zone. Note that this use of
1078MINIMUM should occur when the RRs are copied into the response and not
1079when the zone is loaded from a master file or via a zone transfer. The
1080reason for this provison is to allow future dynamic update facilities to
1081change the SOA RR with known semantics.
10843.3.14. TXT RDATA format
1086 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1088 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1092TXT-DATA One or more <character-string>s.
1094TXT RRs are used to hold descriptive text. The semantics of the text
1095depends on the domain where it is found.
10973.4. Internet specific RRs
10993.4.1. A RDATA format
1101 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1103 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1107ADDRESS A 32 bit Internet address.
1109Hosts that have multiple Internet addresses will have multiple A
1116Mockapetris [Page 20]
1118RFC 1035 Domain Implementation and Specification November 1987
1121A records cause no additional section processing. The RDATA section of
1122an A line in a master file is an Internet address expressed as four
1123decimal numbers separated by dots without any imbedded spaces (e.g.,
1124"10.2.0.52" or "192.0.5.6").
11263.4.2. WKS RDATA format
1128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1132 +--+--+--+--+--+--+--+--+ |
1136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1140ADDRESS An 32 bit Internet address
1142PROTOCOL 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.
1147The WKS record is used to describe the well known services supported by
1148a particular protocol on a particular internet address. The PROTOCOL
1149field specifies an IP protocol number, and the bit map has one bit per
1150port of the specified protocol. The first bit corresponds to port 0,
1151the second to port 1, etc. If the bit map does not include a bit for a
1152protocol of interest, that bit is assumed zero. The appropriate values
1153and mnemonics for ports and protocols are specified in [RFC-1010].
1155For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
115625 (SMTP). If this bit is set, a SMTP server should be listening on TCP
1157port 25; if zero, SMTP service is not supported on the specified
1160The purpose of WKS RRs is to provide availability information for
1161servers for TCP and UDP. If a server supports both TCP and UDP, or has
1162multiple Internet addresses, then multiple WKS RRs are used.
1164WKS RRs cause no additional section processing.
1166In master files, both ports and protocols are expressed using mnemonics
1172Mockapetris [Page 21]
1174RFC 1035 Domain Implementation and Specification November 1987
11773.5. IN-ADDR.ARPA domain
1179The Internet uses a special domain to support gateway location and
1180Internet address to host mapping. Other classes may employ a similar
1181strategy in other domains. The intent of this domain is to provide a
1182guaranteed method to perform host address to host name mapping, and to
1183facilitate queries to locate all gateways on a particular network in the
1186Note that both of these services are similar to functions that could be
1187performed by inverse queries; the difference is that this part of the
1188domain name space is structured according to address, and hence can
1189guarantee that the appropriate data can be located without an exhaustive
1190search of the domain space.
1192The domain begins at IN-ADDR.ARPA and has a substructure which follows
1193the Internet addressing structure.
1195Domain names in the IN-ADDR.ARPA domain are defined to have up to four
1196labels in addition to the IN-ADDR.ARPA suffix. Each label represents
1197one octet of an Internet address, and is expressed as a character string
1198for a decimal value in the range 0-255 (with leading zeros omitted
1199except in the case of a zero octet which is represented by a single
1202Host addresses are represented by domain names that have all four labels
1203specified. Thus data for Internet address 10.2.0.52 is located at
1204domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
1205read, allows zones to be delegated which are exactly one network of
1206address space. For example, 10.IN-ADDR.ARPA can be a zone containing
1207data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
1208MILNET. Address nodes are used to hold pointers to primary host names
1209in the normal domain space.
1211Network numbers correspond to some non-terminal nodes at various depths
1212in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
12132, or 3 octets. Network nodes are used to hold pointers to the primary
1214host names of gateways attached to that network. Since a gateway is, by
1215definition, on more than one network, it will typically have two or more
1216network nodes which point at it. Gateways will also have host level
1217pointers at their fully qualified addresses.
1219Both the gateway pointers at network nodes and the normal host pointers
1220at full address nodes use the PTR RR to point back to the primary domain
1221names of the corresponding hosts.
1223For example, the IN-ADDR.ARPA domain will contain information about the
1224ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
1228Mockapetris [Page 22]
1230RFC 1035 Domain Implementation and Specification November 1987
1233net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
1234gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
1235GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
1236and 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.
1249Thus a program which wanted to locate gateways on net 10 would originate
1250a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
1251would 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.
1256The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
1257GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
1260A resolver which wanted to find the host name corresponding to Internet
1261host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
1262QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
1264 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
1266Several 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.
1284Mockapetris [Page 23]
1286RFC 1035 Domain Implementation and Specification November 1987
12893.6. Defining new types, classes, and special namespaces
1291The previously defined types and classes are the ones in use as of the
1292date of this memo. New definitions should be expected. This section
1293makes some recommendations to designers considering additions to the
1294existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
1295forum where general discussion of design issues takes place.
1297In general, a new type is appropriate when new information is to be
1298added to the database about an existing object, or we need new data
1299formats for some totally new object. Designers should attempt to define
1300types and their RDATA formats that are generally applicable to all
1301classes, and which avoid duplication of information. New classes are
1302appropriate when the DNS is to be used for a new protocol, etc which
1303requires new class-specific data formats, or when a copy of the existing
1304name space is desired, but a separate management domain is necessary.
1306New types and classes need mnemonics for master files; the format of the
1307master files requires that the mnemonics for type and class be disjoint.
1309TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
1312The present system uses multiple RRs to represent multiple values of a
1313type rather than storing multiple values in the RDATA section of a
1314single RR. This is less efficient for most applications, but does keep
1315RRs shorter. The multiple RRs assumption is incorporated in some
1316experimental work on dynamic update methods.
1318The present system attempts to minimize the duplication of data in the
1319database in order to insure consistency. Thus, in order to find the
1320address of the host for a mail exchange, you map the mail domain name to
1321a host name, then the host name to addresses, rather than a direct
1322mapping to host address. This approach is preferred because it avoids
1323the opportunity for inconsistency.
1325In defining a new type of data, multiple RR types should not be used to
1326create an ordering between entries or express different formats for
1327equivalent bindings, instead this information should be carried in the
1328body of the RR and a single type used. This policy avoids problems with
1329caching multiple types and defining QTYPEs to match multiple types.
1331For example, the original form of mail exchange binding used two RR
1332types 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
1334RR type in a cache doesn't convey any information about the other
1335because the query which acquired the cached information might have used
1336a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
1340Mockapetris [Page 24]
1342RFC 1035 Domain Implementation and Specification November 1987
1345service used a single type (MX) with a "preference" value in the RDATA
1346section which can order different RRs. However, if any MX RRs are found
1347in the cache, then all should be there.
1353All communications inside of the domain protocol are carried in a single
1354format called a message. The top level format of message is divided
1355into 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 +---------------------+
1369The header section is always present. The header includes fields that
1370specify which of the remaining sections are present, and also specify
1371whether the message is a query or a response, a standard query or some
1374The names of the sections after the header are derived from their use in
1375standard queries. The question section contains fields that describe a
1376question to a name server. These fields are a query type (QTYPE), a
1377query class (QCLASS), and a query domain name (QNAME). The last three
1378sections have the same format: a possibly empty list of concatenated
1379resource records (RRs). The answer section contains RRs that answer the
1380question; the authority section contains RRs that point toward an
1381authoritative name server; the additional records section contains RRs
1382which relate to the query, but are not strictly answers for the
1396Mockapetris [Page 25]
1398RFC 1035 Domain Implementation and Specification November 1987
14014.1.1. Header section format
1403The 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1423ID 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.
1428QR A one bit field that specifies whether this message is a
1429 query (0), or a response (1).
1431OPCODE 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
1443AA 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
1452Mockapetris [Page 26]
1454RFC 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.
1460TC TrunCation - specifies that this message was truncated
1461 due to length greater than that permitted on the
1462 transmission channel.
1464RD 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.
1469RA 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.
1473Z Reserved for future use. Must be zero in all queries
1476RCODE 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
1508Mockapetris [Page 27]
1510RFC 1035 Domain Implementation and Specification November 1987
1513 transfer) for particular data.
1515 6-15 Reserved for future use.
1517QDCOUNT an unsigned 16 bit integer specifying the number of
1518 entries in the question section.
1520ANCOUNT an unsigned 16 bit integer specifying the number of
1521 resource records in the answer section.
1523NSCOUNT an unsigned 16 bit integer specifying the number of name
1524 server resource records in the authority records
1527ARCOUNT an unsigned 16 bit integer specifying the number of
1528 resource records in the additional records section.
15304.1.2. Question section format
1532The question section is used to carry the "question" in most queries,
1533i.e., the parameters that define what is being asked. The section
1534contains 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1550QNAME 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
1557QTYPE 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.
1564Mockapetris [Page 28]
1566RFC 1035 Domain Implementation and Specification November 1987
1569QCLASS a two octet code that specifies the class of the query.
1570 For example, the QCLASS field is IN for the Internet.
15724.1.3. Resource record format
1574The answer, authority, and additional sections all share the same
1575format: a variable number of resource records, where the number of
1576records is specified in the corresponding count field in the header.
1577Each 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1601NAME a domain name to which this resource record pertains.
1603TYPE two octets containing one of the RR type codes. This
1604 field specifies the meaning of the data in the RDATA
1607CLASS two octets which specify the class of the data in the
1610TTL 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.
1620Mockapetris [Page 29]
1622RFC 1035 Domain Implementation and Specification November 1987
1625RDLENGTH an unsigned 16 bit integer that specifies the length in
1626 octets of the RDATA field.
1628RDATA 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.
16344.1.4. Message compression
1636In order to reduce the size of messages, the domain system utilizes a
1637compression scheme which eliminates the repetition of domain names in a
1638message. In this scheme, an entire domain name or a list of labels at
1639the end of a domain name is replaced with a pointer to a prior occurance
1642The pointer takes the form of a two octet sequence:
1644 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1646 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1648The first two bits are ones. This allows a pointer to be distinguished
1649from a label, since the label must begin with two zero bits because
1650labels are restricted to 63 octets or less. (The 10 and 01 combinations
1651are reserved for future use.) The OFFSET field specifies an offset from
1652the start of the message (i.e., the first octet of the ID field in the
1653domain header). A zero offset specifies the first byte of the ID field,
1656The compression scheme allows a domain name in a message to be
1657represented as either:
1659 - a sequence of labels ending in a zero octet
1663 - a sequence of labels ending with a pointer
1665Pointers can only be used for occurances of a domain name where the
1666format is not class specific. If this were not the case, a name server
1667or resolver would be required to know the format of all RRs it handled.
1668As yet, there are no such cases, but they may occur in future RDATA
1671If a domain name is contained in a part of the message subject to a
1672length field (such as the RDATA section of an RR), and compression is
1676Mockapetris [Page 30]
1678RFC 1035 Domain Implementation and Specification November 1987
1681used, the length of the compressed name is used in the length
1682calculation, rather than the length of the expanded name.
1684Programs are free to avoid using pointers in messages they generate,
1685although this will reduce datagram capacity, and may cause truncation.
1686However all programs are required to understand arriving messages that
1689For example, a datagram might need to use the domain names F.ISI.ARPA,
1690FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
1691message, these domain names might be represented as:
1693 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1695 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1697 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1699 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1701 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1703 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1705 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1723The domain name for F.ISI.ARPA is shown at offset 20. The domain name
1724FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
1725concatenate a label for FOO to the previously defined F.ISI.ARPA. The
1726domain name ARPA is defined at offset 64 using a pointer to the ARPA
1727component of the name F.ISI.ARPA at 20; note that this pointer relies on
1728ARPA being the last label in the string at 20. The root domain name is
1732Mockapetris [Page 31]
1734RFC 1035 Domain Implementation and Specification November 1987
1737defined by a single octet of zeros at 92; the root domain name has no
1742The DNS assumes that messages will be transmitted as datagrams or in a
1743byte stream carried by a virtual circuit. While virtual circuits can be
1744used for any DNS activity, datagrams are preferred for queries due to
1745their lower overhead and better performance. Zone refresh activities
1746must use virtual circuits because of the need for reliable transfer.
1748The Internet supports name server access using TCP [RFC-793] on server
1749port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
1754Messages sent using UDP user server port 53 (decimal).
1756Messages carried by UDP are restricted to 512 bytes (not counting the IP
1757or UDP headers). Longer messages are truncated and the TC bit is set in
1760UDP is not acceptable for zone transfers, but is the recommended method
1761for standard queries in the Internet. Queries sent using UDP may be
1762lost, and hence a retransmission strategy is required. Queries or their
1763responses may be reordered by the network, or by processing in name
1764servers, so resolvers should not depend on them being returned in order.
1766The optimal UDP retransmission policy will vary with performance of the
1767Internet 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.
1778More suggestions on server selection and retransmission policy can be
1779found in the resolver section of this memo.
1783Messages sent over TCP connections use server port 53 (decimal). The
1784message is prefixed with a two byte length field which gives the message
1788Mockapetris [Page 32]
1790RFC 1035 Domain Implementation and Specification November 1987
1793length, excluding the two byte length field. This length field allows
1794the low-level processing to assemble a complete message before beginning
1797Several 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
1820Master files are text files that contain RRs in text form. Since the
1821contents of a zone can be expressed in the form of a list of RRs a
1822master file is most often used to define a zone, though it can be used
1823to list a cache's contents. Hence, this section first discusses the
1824format of RRs in a master file, and then the special considerations when
1825a master file is used to create a zone in some name server.
1829The format of these files is a sequence of entries. Entries are
1830predominantly line-oriented, though parentheses can be used to continue
1831a list of items across a line boundary, and text literals can contain
1832CRLF within the text. Any combination of tabs and spaces act as a
1833delimiter between the separate items that make up an entry. The end of
1834any line in the master file can end with a comment. The comment starts
1835with a ";" (semicolon).
1837The following entries are defined:
1844Mockapetris [Page 33]
1846RFC 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>]
1857Blank lines, with or without comments, are allowed anywhere in the file.
1859Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
1860followed by a domain name, and resets the current origin for relative
1861domain names to the stated name. $INCLUDE inserts the named file into
1862the current file, and may optionally specify a domain name that sets the
1863relative domain name origin for the included file. $INCLUDE may also
1864have a comment. Note that a $INCLUDE entry never changes the relative
1865origin of the parent file, regardless of changes to the relative origin
1866made within the included file.
1868The last two forms represent RRs. If an entry for an RR begins with a
1869blank, then the RR is assumed to be owned by the last stated owner. If
1870an 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>
1878The RR begins with optional TTL and class fields, followed by a type and
1879RDATA field appropriate to the type and class. Class and type use the
1880standard mnemonics, TTL is a decimal integer. Omitted class and TTL
1881values are default to the last explicitly stated values. Since type and
1882class mnemonics are disjoint, the parse is unique. (Note that this
1883order is different from the order used in examples and the order used in
1884the 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.
1887The labels in the domain name are expressed as character strings and
1888separated by dots. Quoting conventions allow arbitrary characters to be
1889stored in domain names. Domain names that end in a dot are called
1890absolute, and are taken as complete. Domain names which do not end in a
1891dot are called relative; the actual domain name is the concatenation of
1892the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
1893an argument to the master file loading routine. A relative name is an
1894error when no origin is available.
1900Mockapetris [Page 34]
1902RFC 1035 Domain Implementation and Specification November 1987
1905<character-string> is expressed in one or two ways: as a contiguous set
1906of characters without interior spaces, or as a string beginning with a "
1907and ending with a ". Inside a " delimited string any character can
1908occur, except for a " itself, which must be quoted using \ (back slash).
1910Because these files are text files several special encodings are
1911necessary 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.
19345.2. Use of master files to define zones
1936When a master file is used to load a zone, the operation should be
1937suppressed if any errors are encountered in the master file. The
1938rationale for this is that a single error can have widespread
1939consequences. For example, suppose that the RRs defining a delegation
1940have syntax errors; then the server will return authoritative name
1941errors for all names in the subzone (except in the case where the
1942subzone is also present on the server).
1944Several other validity checks that should be performed in addition to
1945insuring 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.
1956Mockapetris [Page 35]
1958RFC 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.
19655.3. Master file example
1967The following is an example file which might be used to define the
1968ISI.EDU zone.and is loaded with an origin of ISI.EDU:
1970@ IN SOA VENERA Action\.domains (
1992$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
1994Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
1998 CURLEY MB A.ISI.EDU.
2003Note the use of the \ character in the SOA RR to specify the responsible
2004person mailbox "Action.domains@E.ISI.EDU".
2012Mockapetris [Page 36]
2014RFC 1035 Domain Implementation and Specification November 1987
20176. NAME SERVER IMPLEMENTATION
2021The optimal structure for the name server will depend on the host
2022operating system and whether the name server is integrated with resolver
2023operations, either by supporting recursive service, or by sharing its
2024database with a resolver. This section discusses implementation
2025considerations for a name server which shares a database with a
2026resolver, but most of these concerns are present in any name server.
2030A name server must employ multiple concurrent activities, whether they
2031are implemented as separate tasks in the host's OS or multiplexing
2032inside a single name server program. It is simply not acceptable for a
2033name server to block the service of UDP requests while it waits for TCP
2034data for refreshing or query activities. Similarly, a name server
2035should not attempt to provide recursive service without processing such
2036requests in parallel, though it may choose to serialize requests from a
2037single client, or to regard identical requests from the same client as
2038duplicates. A name server should not substantially delay requests while
2039it reloads a zone from master files or while it incorporates a newly
2040refreshed zone into its database.
2044While name server implementations are free to use any internal data
2045structures 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)
2059All of these data structures can be implemented an identical tree
2060structure format, with different data chained off the nodes in different
2061parts: in the catalog the data is pointers to zones, while in the zone
2062and cache data structures, the data will be RRs. In designing the tree
2063framework the designer should recognize that query processing will need
2064to traverse the tree using case-insensitive label comparisons; and that
2068Mockapetris [Page 37]
2070RFC 1035 Domain Implementation and Specification November 1987
2073in real data, a few nodes have a very high branching factor (100-1000 or
2074more), but the vast majority have a very low branching factor (0-1).
2076One way to solve the case problem is to store the labels for each node
2077in two pieces: a standardized-case representation of the label where all
2078ASCII characters are in a single case, together with a bit mask that
2079denotes which characters are actually of a different case. The
2080branching factor diversity can be handled using a simple linked list for
2081a node until the branching factor exceeds some threshold, and
2082transitioning to a hash structure after the threshold is exceeded. In
2083any case, hash structures used to store tree sections must insure that
2084hash functions and procedures preserve the casing conventions of the
2087The use of separate structures for the different parts of the database
2088is 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.
2118A major aspect of database design is selecting a structure which allows
2119the name server to deal with crashes of the name server's host. State
2120information which a name server should save across system crashes
2124Mockapetris [Page 38]
2126RFC 1035 Domain Implementation and Specification November 1987
2129includes the catalog structure (including the state of refreshing for
2130each zone) and the zone data itself.
2134Both the TTL data for RRs and the timing data for refreshing activities
2135depends on 32 bit timers in units of seconds. Inside the database,
2136refresh timers and TTLs for cached data conceptually "count down", while
2137data in the zone stays with constant TTLs.
2139A recommended implementation strategy is to store time in two ways: as
2140a relative increment and as an absolute time. One way to do this is to
2141use positive 32 bit numbers for one type and negative numbers for the
2142other. The RRs in zones use relative times; the refresh timers and
2143cache data use absolute times. Absolute numbers are taken with respect
2144to some known origin and converted to relative values when placed in the
2145response to a query. When an absolute TTL is negative after conversion
2146to relative, then the data is expired and should be ignored.
21486.2. Standard query processing
2150The major algorithm for standard query processing is presented in
2153When processing queries with QCLASS=*, or some other QCLASS which
2154matches multiple classes, the response should never be authoritative
2155unless the server can guarantee that the response covers all classes.
2157When composing a response, RRs which are to be inserted in the
2158additional section, but duplicate RRs in the answer or authority
2159sections, may be omitted from the additional section.
2161When a response is so long that truncation is required, the truncation
2162should start at the end of the response and work forward in the
2163datagram. Thus if there is any data for the authority section, the
2164answer section is guaranteed to be unique.
2166The MINIMUM value in the SOA should be used to set a floor on the TTL of
2167data distributed from a zone. This floor function should be done when
2168the data is copied into a response. This will allow future dynamic
2169update protocols to change the SOA MINIMUM field without ambiguous
21726.3. Zone refresh and reload processing
2174In spite of a server's best efforts, it may be unable to load zone data
2175from a master file due to syntax errors, etc., or be unable to refresh a
2176zone within the its expiration parameter. In this case, the name server
2180Mockapetris [Page 39]
2182RFC 1035 Domain Implementation and Specification November 1987
2185should answer queries as if it were not supposed to possess the zone.
2187If a master is sending a zone out via AXFR, and a new version is created
2188during the transfer, the master should continue to send the old version
2189if possible. In any case, it should never send part of one version and
2190part of another. If completion is not possible, the master should reset
2191the connection on which the zone transfer is taking place.
21936.4. Inverse queries (Optional)
2195Inverse queries are an optional part of the DNS. Name servers are not
2196required to support any form of inverse queries. If a name server
2197receives an inverse query that it does not support, it returns an error
2198response with the "Not Implemented" error set in the header. While
2199inverse query support is optional, all name servers must be at least
2200able to return the error response.
22026.4.1. The contents of inverse queries and responses Inverse
2203queries reverse the mappings performed by standard query operations;
2204while a standard query maps a domain name to a resource, an inverse
2205query maps a resource to a domain name. For example, a standard query
2206might bind a domain name to a host address; the corresponding inverse
2207query binds the host address to a domain name.
2209Inverse queries take the form of a single RR in the answer section of
2210the message, with an empty question section. The owner name of the
2211query RR and its TTL are not significant. The response carries
2212questions in the question section which identify all names possessing
2213the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
2214about all of the domain name space, the response can never be assumed to
2215be complete. Thus inverse queries are primarily useful for database
2216management and debugging activities. Inverse queries are NOT an
2217acceptable method of mapping host addresses to host names; use the IN-
2218ADDR.ARPA domain instead.
2220Where possible, name servers should provide case-insensitive comparisons
2221for 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
2224produce the same result as an inverse query for "IBM-pc unix". However,
2225this cannot be guaranteed because name servers may possess RRs that
2226contain character strings but the name server does not know that the
2229When 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
2236Mockapetris [Page 40]
2238RFC 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.
2244When the response to an inverse query contains one or more QNAMEs, the
2245owner name and TTL of the RR in the answer section which defines the
2246inverse query is modified to exactly match an RR found at the first
2249RRs returned in the inverse queries cannot be cached using the same
2250mechanism as is used for the replies to standard queries. One reason
2251for this is that a name might have multiple RRs of the same type, and
2252only one would appear. For example, an inverse query for a single
2253address of a multiply homed host might create the impression that only
22566.4.2. Inverse query and response example The overall structure
2257of an inverse query for retrieving the domain name that corresponds to
2258Internet 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 +-----------------------------------------+
2272This query asks for a question whose answer is the Internet style
2273address 10.1.0.52. Since the owner name is not known, any domain name
2274can be used as a placeholder (and is ignored). A single octet of zero,
2275signifying the root, is usually used because it minimizes the length of
2276the message. The TTL of the RR is not significant. The response to
2292Mockapetris [Page 41]
2294RFC 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 +-----------------------------------------+
2309Note that the QTYPE in a response to an inverse query is the same as the
2310TYPE field in the answer section of the inverse query. Responses to
2311inverse queries may contain multiple questions when the inverse is not
2312unique. If the question section in the response is not empty, then the
2313RR in the answer section is modified to correspond to be an exact copy
2314of an RR at the first QNAME.
23166.4.3. Inverse query processing
2318Name servers that support inverse queries can support these operations
2319through exhaustive searches of their databases, but this becomes
2320impractical as the size of the database increases. An alternative
2321approach is to invert the database according to the search key.
2323For name servers that support multiple zones and a large amount of data,
2324the recommended approach is separate inversions for each zone. When a
2325particular zone is changed during a refresh, only its inversions need to
2328Support for transfer of this type of inversion may be included in future
2329versions of the domain system, but is not supported in this version.
23316.5. Completion queries and responses
2333The optional completion services described in RFC-882 and RFC-883 have
2334been deleted. Redesigned services may become available in the future.
2348Mockapetris [Page 42]
2350RFC 1035 Domain Implementation and Specification November 1987
23537. RESOLVER IMPLEMENTATION
2355The top levels of the recommended resolver algorithm are discussed in
2356[RFC-1034]. This section discusses implementation details assuming the
2357database structure suggested in the name server implementation section
23607.1. Transforming a user request into a query
2362The first step a resolver takes is to transform the client's request,
2363stated in a format suitable to the local OS, into a search specification
2364for RRs at a specific name which match a specific QTYPE and QCLASS.
2365Where possible, the QTYPE and QCLASS should correspond to a single type
2366and a single class, because this makes the use of cached data much
2367simpler. The reason for this is that the presence of data of one type
2368in a cache doesn't confirm the existence or non-existence of data of
2369other types, hence the only way to be sure is to consult an
2370authoritative source. If QCLASS=* is used, then authoritative answers
2373Since a resolver must be able to multiplex multiple requests if it is to
2374perform its function efficiently, each pending request is usually
2375represented 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
2404Mockapetris [Page 43]
2406RFC 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.
24327.2. Sending the queries
2434As described in [RFC-1034], the basic task of the resolver is to
2435formulate a query which will answer the client's request and direct that
2436query to name servers which can provide the information. The resolver
2437will usually only have very strong hints about which servers to ask, in
2438the form of NS RRs, and may have to revise the query, in response to
2439CNAMEs, or revise the set of name servers the resolver is asking, in
2440response to delegation responses which point the resolver to name
2441servers closer to the desired information. In addition to the
2442information requested by the client, the resolver may have to call upon
2443its own services to determine the address of name servers it wishes to
2446In any case, the model used in this memo assumes that the resolver is
2447multiplexing attention between multiple requests, some from the client,
2448and some internally generated. Each request is represented by some
2449state information, and the desired behavior is that the resolver
2450transmit queries to name servers in a way that maximizes the probability
2451that the request is answered, minimizes the time that the request takes,
2452and avoids excessive transmissions. The key algorithm uses the state
2453information of the request to select the next name server address to
2454query, and also computes a timeout which will cause the next action
2455should a response not arrive. The next action will usually be a
2456transmission to some other server, but may be a temporary error to the
2460Mockapetris [Page 44]
2462RFC 1035 Domain Implementation and Specification November 1987
2467The resolver always starts with a list of server names to query (SLIST).
2468This list will be all NS RRs which correspond to the nearest ancestor
2469zone that the resolver knows about. To avoid startup problems, the
2470resolver should have a set of default servers which it will ask should
2471it have no current NS RRs which are appropriate. The resolver then adds
2472to SLIST all of the known addresses for the name servers, and may start
2473parallel requests to acquire the addresses of the servers when the
2474resolver has the name, but no addresses, for the name servers.
2476To complete initialization of SLIST, the resolver attaches whatever
2477history information it has to the each address in SLIST. This will
2478usually consist of some sort of weighted averages for the response time
2479of the address, and the batting average of the address (i.e., how often
2480the address responded at all to the request). Note that this
2481information should be kept on a per address basis, rather than on a per
2482name server basis, because the response time and batting average of a
2483particular server may vary considerably from address to address. Note
2484also that this information is actually specific to a resolver address /
2485server address pair, so a resolver with multiple addresses may wish to
2486keep separate histories for each of its addresses. Part of this step
2487must deal with addresses which have no such history; in this case an
2488expected round trip time of 5-10 seconds should be the worst case, with
2489lower estimates for the same local network, etc.
2491Note that whenever a delegation is followed, the resolver algorithm
2494The information establishes a partial ranking of the available name
2495server addresses. Each time an address is chosen and the state should
2496be altered to prevent its selection again until all other addresses have
2497been tried. The timeout for each transmission should be 50-100% greater
2498than 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.
2516Mockapetris [Page 45]
2518RFC 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.
25267.3. Processing responses
2528The first step in processing arriving response datagrams is to parse the
2529response. 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
2543The next step is to match the response to a current resolver request.
2544The recommended strategy is to do a preliminary matching using the ID
2545field in the domain header, and then to verify that the question section
2546corresponds to the information currently desired. This requires that
2547the transmission algorithm devote several bits of the domain ID field to
2548a 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.
2572Mockapetris [Page 46]
2574RFC 1035 Domain Implementation and Specification November 1987
2579In general, we expect a resolver to cache all data which it receives in
2580responses since it may be useful in answering future client requests.
2581However, 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.
2607In a similar vein, when a resolver has a set of RRs for some name in a
2608response, and wants to cache the RRs, it should check its cache for
2609already existing RRs. Depending on the circumstances, either the data
2610in the response or the cache is preferred, but the two should never be
2611combined. If the data in the response is from authoritative data in the
2612answer section, it is always preferred.
2616The domain system defines a standard for mapping mailboxes into domain
2617names, and two methods for using the mailbox information to derive mail
2618routing information. The first method is called mail exchange binding
2619and the other method is mailbox binding. The mailbox encoding standard
2620and mail exchange binding are part of the DNS official protocol, and are
2621the recommended method for mail routing in the Internet. Mailbox
2622binding is an experimental feature which is still under development and
2628Mockapetris [Page 47]
2630RFC 1035 Domain Implementation and Specification November 1987
2633The mailbox encoding standard assumes a mailbox name of the form
2634"<local-part>@<mail-domain>". While the syntax allowed in each of these
2635sections varies substantially between the various mail internets, the
2636preferred syntax for the ARPA Internet is given in [RFC-822].
2638The 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>
2640is prefaced to the domain name from <mail-domain> to form the domain
2641name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
2642NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
2643<local-part> contains dots or other special characters, its
2644representation in a master file will require the use of backslash
2645quoting to ensure that the domain name is properly encoded. For
2646example, the mailbox Action.domains@ISI.EDU would be represented as
2647Action\.domains.ISI.EDU.
26498.1. Mail exchange binding
2651Mail exchange binding uses the <mail-domain> part of a mailbox
2652specification to determine where mail should be sent. The <local-part>
2653is not even consulted. [RFC-974] specifies this method in detail, and
2654should be consulted before attempting to use mail exchange support.
2656One of the advantages of this method is that it decouples mail
2657destination naming from the hosts used to support mail service, at the
2658cost of another layer of indirection in the lookup function. However,
2659the addition layer should eliminate the need for complicated "%", "!",
2660etc encodings in <local-part>.
2662The essence of the method is that the <mail-domain> is used as a domain
2663name to locate type MX RRs which list hosts willing to accept mail for
2664<mail-domain>, together with preference values which rank the hosts
2665according to an order specified by the administrators for <mail-domain>.
2667In this memo, the <mail-domain> ISI.EDU is used in examples, together
2668with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
2669ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
2670route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
2671VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
26748.2. Mailbox binding (Experimental)
2676In mailbox binding, the mailer uses the entire mail destination
2677specification to construct a domain name. The encoded domain name for
2678the mailbox is used as the QNAME field in a QTYPE=MAILB query.
2680Several outcomes are possible for this query:
2684Mockapetris [Page 48]
2686RFC 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
2728In 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
2730legal with a MB. The MINFO RR identifies two mailboxes. One of these
2731identifies a responsible person for the original mailbox name. This
2732mailbox should be used for requests to be added to a mail group, etc.
2733The second mailbox name in the MINFO RR identifies a mailbox that should
2734receive error messages for mail failures. This is particularly
2735appropriate for mailing lists when errors in member names should be
2736reported to a person other than the one who sends a message to the list.
2740Mockapetris [Page 49]
2742RFC 1035 Domain Implementation and Specification November 1987
2745New fields may be added to this RR in the future.
27489. 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.
2796Mockapetris [Page 50]
2798RFC 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.
2852Mockapetris [Page 51]
2854RFC 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.
2908Mockapetris [Page 52]
2910RFC 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.
2964Mockapetris [Page 53]
2966RFC 1035 Domain Implementation and Specification November 1987
2975 <character-string> 35
2998 IN-ADDR.ARPA domain 22
3020Mockapetris [Page 54]
3022RFC 1035 Domain Implementation and Specification November 1987
3076Mockapetris [Page 55]