1Network Working Group P. Mockapetris
2Request for Comments: 1035 ISI
3 November 1987
4Obsoletes: RFCs 882, 883, 973
5
6 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
7
8
91. STATUS OF THIS MEMO
10
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].
14
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.
23
24Experimental or obsolete features are clearly marked in these RFCs, and
25such information should be used with caution.
26
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.
30
31 Table of Contents
32
33 1. STATUS OF THIS MEMO 1
34 2. INTRODUCTION 3
35 2.1. Overview 3
36 2.2. Common configurations 4
37 2.3. Conventions 7
38 2.3.1. Preferred name syntax 7
39 2.3.2. Data Transmission Order 8
40 2.3.3. Character Case 9
41 2.3.4. Size limits 10
42 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
43 3.1. Name space definitions 10
44 3.2. RR definitions 11
45 3.2.1. Format 11
46 3.2.2. TYPE values 12
47 3.2.3. QTYPE values 12
48 3.2.4. CLASS values 13
49
50
51
52Mockapetris [Page 1]
53
54RFC 1035 Domain Implementation and Specification November 1987
55
56
57 3.2.5. QCLASS values 13
58 3.3. Standard RRs 13
59 3.3.1. CNAME RDATA format 14
60 3.3.2. HINFO RDATA format 14
61 3.3.3. MB RDATA format (EXPERIMENTAL) 14
62 3.3.4. MD RDATA format (Obsolete) 15
63 3.3.5. MF RDATA format (Obsolete) 15
64 3.3.6. MG RDATA format (EXPERIMENTAL) 16
65 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
66 3.3.8. MR RDATA format (EXPERIMENTAL) 17
67 3.3.9. MX RDATA format 17
68 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
69 3.3.11. NS RDATA format 18
70 3.3.12. PTR RDATA format 18
71 3.3.13. SOA RDATA format 19
72 3.3.14. TXT RDATA format 20
73 3.4. ARPA Internet specific RRs 20
74 3.4.1. A RDATA format 20
75 3.4.2. WKS RDATA format 21
76 3.5. IN-ADDR.ARPA domain 22
77 3.6. Defining new types, classes, and special namespaces 24
78 4. MESSAGES 25
79 4.1. Format 25
80 4.1.1. Header section format 26
81 4.1.2. Question section format 28
82 4.1.3. Resource record format 29
83 4.1.4. Message compression 30
84 4.2. Transport 32
85 4.2.1. UDP usage 32
86 4.2.2. TCP usage 32
87 5. MASTER FILES 33
88 5.1. Format 33
89 5.2. Use of master files to define zones 35
90 5.3. Master file example 36
91 6. NAME SERVER IMPLEMENTATION 37
92 6.1. Architecture 37
93 6.1.1. Control 37
94 6.1.2. Database 37
95 6.1.3. Time 39
96 6.2. Standard query processing 39
97 6.3. Zone refresh and reload processing 39
98 6.4. Inverse queries (Optional) 40
99 6.4.1. The contents of inverse queries and responses 40
100 6.4.2. Inverse query and response example 41
101 6.4.3. Inverse query processing 42
102
103
104
105
106
107
108Mockapetris [Page 2]
109
110RFC 1035 Domain Implementation and Specification November 1987
111
112
113 6.5. Completion queries and responses 42
114 7. RESOLVER IMPLEMENTATION 43
115 7.1. Transforming a user request into a query 43
116 7.2. Sending the queries 44
117 7.3. Processing responses 46
118 7.4. Using the cache 47
119 8. MAIL SUPPORT 47
120 8.1. Mail exchange binding 48
121 8.2. Mailbox binding (Experimental) 48
122 9. REFERENCES and BIBLIOGRAPHY 50
123 Index 54
124
1252. INTRODUCTION
126
1272.1. Overview
128
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.
132
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
141the user.
142
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.
155
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
161
162
163
164Mockapetris [Page 3]
165
166RFC 1035 Domain Implementation and Specification November 1987
167
168
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.
174
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.
178
1792.2. Common configurations
180
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:
186
187 Local Host | Foreign
188 |
189 +---------+ +----------+ | +--------+
190 | | user queries | |queries | | |
191 | User |-------------->| |---------|->|Foreign |
192 | Program | | Resolver | | | Name |
193 | |<--------------| |<--------|--| Server |
194 | | user responses| |responses| | |
195 +---------+ +----------+ | +--------+
196 | A |
197 cache additions | | references |
198 V | |
199 +----------+ |
200 | cache | |
201 +----------+ |
202
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.
211
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
217
218
219
220Mockapetris [Page 4]
221
222RFC 1035 Domain Implementation and Specification November 1987
223
224
225in this memo, and may be datagrams.
226
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:
230
231 Local Host | Foreign
232 |
233 +---------+ |
234 / /| |
235 +---------+ | +----------+ | +--------+
236 | | | | |responses| | |
237 | | | | Name |---------|->|Foreign |
238 | Master |-------------->| Server | | |Resolver|
239 | files | | | |<--------|--| |
240 | |/ | | queries | +--------+
241 +---------+ +----------+ |
242
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.
246
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:
251
252 Local Host | Foreign
253 |
254 +---------+ |
255 / /| |
256 +---------+ | +----------+ | +--------+
257 | | | | |responses| | |
258 | | | | Name |---------|->|Foreign |
259 | Master |-------------->| Server | | |Resolver|
260 | files | | | |<--------|--| |
261 | |/ | | queries | +--------+
262 +---------+ +----------+ |
263 A |maintenance | +--------+
264 | +------------|->| |
265 | queries | |Foreign |
266 | | | Name |
267 +------------------|--| Server |
268 maintenance responses | +--------+
269
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
273
274
275
276Mockapetris [Page 5]
277
278RFC 1035 Domain Implementation and Specification November 1987
279
280
281these maintenance activities follow the same form as queries and
282responses, but the message sequences are somewhat different.
283
284The information flow in a host that supports all aspects of the domain
285name system is shown below:
286
287 Local Host | Foreign
288 |
289 +---------+ +----------+ | +--------+
290 | | user queries | |queries | | |
291 | User |-------------->| |---------|->|Foreign |
292 | Program | | Resolver | | | Name |
293 | |<--------------| |<--------|--| Server |
294 | | user responses| |responses| | |
295 +---------+ +----------+ | +--------+
296 | A |
297 cache additions | | references |
298 V | |
299 +----------+ |
300 | Shared | |
301 | database | |
302 +----------+ |
303 A | |
304 +---------+ refreshes | | references |
305 / /| | V |
306 +---------+ | +----------+ | +--------+
307 | | | | |responses| | |
308 | | | | Name |---------|->|Foreign |
309 | Master |-------------->| Server | | |Resolver|
310 | files | | | |<--------|--| |
311 | |/ | | queries | +--------+
312 +---------+ +----------+ |
313 A |maintenance | +--------+
314 | +------------|->| |
315 | queries | |Foreign |
316 | | | Name |
317 +------------------|--| Server |
318 maintenance responses | +--------+
319
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
327local implementor.
328
329
330
331
332Mockapetris [Page 6]
333
334RFC 1035 Domain Implementation and Specification November 1987
335
336
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:
348
349 Local Hosts | Foreign
350 |
351 +---------+ |
352 | | responses |
353 | Stub |<--------------------+ |
354 | Resolver| | |
355 | |----------------+ | |
356 +---------+ recursive | | |
357 queries | | |
358 V | |
359 +---------+ recursive +----------+ | +--------+
360 | | queries | |queries | | |
361 | Stub |-------------->| Recursive|---------|->|Foreign |
362 | Resolver| | Server | | | Name |
363 | |<--------------| |<--------|--| Server |
364 +---------+ responses | |responses| | |
365 +----------+ | +--------+
366 | Central | |
367 | cache | |
368 +----------+ |
369
370In any case, note that domain components are always replicated for
371reliability whenever possible.
372
3732.3. Conventions
374
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.
379
3802.3.1. Preferred name syntax
381
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.
385
386
387
388Mockapetris [Page 7]
389
390RFC 1035 Domain Implementation and Specification November 1987
391
392
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.
397
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.
402
403The following syntax will result in fewer problems with many
404
405applications that use domain names (e.g., mail, TELNET).
406
407<domain> ::= <subdomain> | " "
408
409<subdomain> ::= <label> | <subdomain> "." <label>
410
411<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
412
413<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
414
415<let-dig-hyp> ::= <let-dig> | "-"
416
417<let-dig> ::= <letter> | <digit>
418
419<letter> ::= any one of the 52 alphabetic characters A through Z in
420upper case and a through z in lower case
421
422<digit> ::= any one of the ten digits 0 through 9
423
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.
427
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.
432
433For example, the following strings identify hosts in the Internet:
434
435A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
436
4372.3.2. Data Transmission Order
438
439The order of transmission of the header and data described in this
440document is resolved to the octet level. Whenever a diagram shows a
441
442
443
444Mockapetris [Page 8]
445
446RFC 1035 Domain Implementation and Specification November 1987
447
448
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.
452
453 0 1
454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
456 | 1 | 2 |
457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
458 | 3 | 4 |
459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
460 | 5 | 6 |
461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
462
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).
467
468 0 1 2 3 4 5 6 7
469 +-+-+-+-+-+-+-+-+
470 |1 0 1 0 1 0 1 0|
471 +-+-+-+-+-+-+-+-+
472
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
476transmitted first.
477
4782.3.3. Character Case
479
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.
487
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
495insensitive manner.
496
497
498
499
500Mockapetris [Page 9]
501
502RFC 1035 Domain Implementation and Specification November 1987
503
504
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.
510
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.
516
5172.3.4. Size limits
518
519Various objects and parameters in the DNS have size limits. They are
520listed below. Some could be easily changed, others are more
521fundamental.
522
523labels 63 octets or less
524
525names 255 octets or less
526
527TTL positive values of a signed 32 bit number.
528
529UDP messages 512 octets or less
530
5313. DOMAIN NAME SPACE AND RR DEFINITIONS
532
5333.1. Name space definitions
534
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
541less.
542
543To simplify implementations, the total length of a domain name (i.e.,
544label octets and label length octets) is restricted to 255 octets or
545less.
546
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.
553
554
555
556Mockapetris [Page 10]
557
558RFC 1035 Domain Implementation and Specification November 1987
559
560
5613.2. RR definitions
562
5633.2.1. Format
564
565All RRs have the same top level format shown below:
566
567 1 1 1 1 1 1
568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
569 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
570 | |
571 / /
572 / NAME /
573 | |
574 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
575 | TYPE |
576 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
577 | CLASS |
578 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
579 | TTL |
580 | |
581 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
582 | RDLENGTH |
583 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
584 / RDATA /
585 / /
586 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
587
588
589where:
590
591NAME an owner name, i.e., the name of the node to which this
592 resource record pertains.
593
594TYPE two octets containing one of the RR TYPE codes.
595
596CLASS two octets containing one of the RR CLASS codes.
597
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.
606
607RDLENGTH an unsigned 16 bit integer that specifies the length in
608 octets of the RDATA field.
609
610
611
612Mockapetris [Page 11]
613
614RFC 1035 Domain Implementation and Specification November 1987
615
616
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.
620
6213.2.2. TYPE values
622
623TYPE fields are used in resource records. Note that these types are a
624subset of QTYPEs.
625
626TYPE value and meaning
627
628A 1 a host address
629
630NS 2 an authoritative name server
631
632MD 3 a mail destination (Obsolete - use MX)
633
634MF 4 a mail forwarder (Obsolete - use MX)
635
636CNAME 5 the canonical name for an alias
637
638SOA 6 marks the start of a zone of authority
639
640MB 7 a mailbox domain name (EXPERIMENTAL)
641
642MG 8 a mail group member (EXPERIMENTAL)
643
644MR 9 a mail rename domain name (EXPERIMENTAL)
645
646NULL 10 a null RR (EXPERIMENTAL)
647
648WKS 11 a well known service description
649
650PTR 12 a domain name pointer
651
652HINFO 13 host information
653
654MINFO 14 mailbox or mail list information
655
656MX 15 mail exchange
657
658TXT 16 text strings
659
6603.2.3. QTYPE values
661
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:
665
666
667
668Mockapetris [Page 12]
669
670RFC 1035 Domain Implementation and Specification November 1987
671
672
673AXFR 252 A request for a transfer of an entire zone
674
675MAILB 253 A request for mailbox-related records (MB, MG or MR)
676
677MAILA 254 A request for mail agent RRs (Obsolete - see MX)
678
679* 255 A request for all records
680
6813.2.4. CLASS values
682
683CLASS fields appear in resource records. The following CLASS mnemonics
684and values are defined:
685
686IN 1 the Internet
687
688CS 2 the CSNET class (Obsolete - used only for examples in
689 some obsolete RFCs)
690
691CH 3 the CHAOS class
692
693HS 4 Hesiod [Dyer 87]
694
6953.2.5. QCLASS values
696
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:
700
701* 255 any class
702
7033.3. Standard RRs
704
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.
710
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).
716
717
718
719
720
721
722
723
724Mockapetris [Page 13]
725
726RFC 1035 Domain Implementation and Specification November 1987
727
728
7293.3.1. CNAME RDATA format
730
731 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
732 / CNAME /
733 / /
734 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
735
736where:
737
738CNAME A <domain-name> which specifies the canonical or primary
739 name for the owner. The owner name is an alias.
740
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.
744
7453.3.2. HINFO RDATA format
746
747 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
748 / CPU /
749 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
750 / OS /
751 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
752
753where:
754
755CPU A <character-string> which specifies the CPU type.
756
757OS A <character-string> which specifies the operating
758 system type.
759
760Standard values for CPU and OS can be found in [RFC-1010].
761
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.
765
7663.3.3. MB RDATA format (EXPERIMENTAL)
767
768 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
769 / MADNAME /
770 / /
771 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
772
773where:
774
775MADNAME A <domain-name> which specifies a host which has the
776 specified mailbox.
777
778
779
780Mockapetris [Page 14]
781
782RFC 1035 Domain Implementation and Specification November 1987
783
784
785MB records cause additional section processing which looks up an A type
786RRs corresponding to MADNAME.
787
7883.3.4. MD RDATA format (Obsolete)
789
790 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
791 / MADNAME /
792 / /
793 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
794
795where:
796
797MADNAME A <domain-name> which specifies a host which has a mail
798 agent for the domain which should be able to deliver
799 mail for the domain.
800
801MD records cause additional section processing which looks up an A type
802record corresponding to MADNAME.
803
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
807preference of 0.
808
8093.3.5. MF RDATA format (Obsolete)
810
811 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
812 / MADNAME /
813 / /
814 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
815
816where:
817
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.
821
822MF records cause additional section processing which looks up an A type
823record corresponding to MADNAME.
824
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
828preference of 10.
829
830
831
832
833
834
835
836Mockapetris [Page 15]
837
838RFC 1035 Domain Implementation and Specification November 1987
839
840
8413.3.6. MG RDATA format (EXPERIMENTAL)
842
843 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
844 / MGMNAME /
845 / /
846 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
847
848where:
849
850MGMNAME A <domain-name> which specifies a mailbox which is a
851 member of the mail group specified by the domain name.
852
853MG records cause no additional section processing.
854
8553.3.7. MINFO RDATA format (EXPERIMENTAL)
856
857 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
858 / RMAILBX /
859 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
860 / EMAILBX /
861 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
862
863where:
864
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.
872
873
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.
880
881MINFO records cause no additional section processing. Although these
882records can be associated with a simple mailbox, they are usually used
883with a mailing list.
884
885
886
887
888
889
890
891
892Mockapetris [Page 16]
893
894RFC 1035 Domain Implementation and Specification November 1987
895
896
8973.3.8. MR RDATA format (EXPERIMENTAL)
898
899 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
900 / NEWNAME /
901 / /
902 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
903
904where:
905
906NEWNAME A <domain-name> which specifies a mailbox which is the
907 proper rename of the specified mailbox.
908
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
911mailbox.
912
9133.3.9. MX RDATA format
914
915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
916 | PREFERENCE |
917 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
918 / EXCHANGE /
919 / /
920 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
921
922where:
923
924PREFERENCE A 16 bit integer which specifies the preference given to
925 this RR among others at the same owner. Lower values
926 are preferred.
927
928EXCHANGE A <domain-name> which specifies a host willing to act as
929 a mail exchange for the owner name.
930
931MX records cause type A additional section processing for the host
932specified by EXCHANGE. The use of MX RRs is explained in detail in
933[RFC-974].
934
9353.3.10. NULL RDATA format (EXPERIMENTAL)
936
937 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
938 / <anything> /
939 / /
940 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
941
942Anything at all may be in the RDATA field so long as it is 65535 octets
943or less.
944
945
946
947
948Mockapetris [Page 17]
949
950RFC 1035 Domain Implementation and Specification November 1987
951
952
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.
956
9573.3.11. NS RDATA format
958
959 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
960 / NSDNAME /
961 / /
962 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
963
964where:
965
966NSDNAME A <domain-name> which specifies a host which should be
967 authoritative for the specified class and domain.
968
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.
972
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.
979
9803.3.12. PTR RDATA format
981
982 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
983 / PTRDNAME /
984 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
985
986where:
987
988PTRDNAME A <domain-name> which points to some location in the
989 domain name space.
990
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.
996
997
998
999
1000
1001
1002
1003
1004Mockapetris [Page 18]
1005
1006RFC 1035 Domain Implementation and Specification November 1987
1007
1008
10093.3.13. SOA RDATA format
1010
1011 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1012 / MNAME /
1013 / /
1014 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1015 / RNAME /
1016 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1017 | SERIAL |
1018 | |
1019 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1020 | REFRESH |
1021 | |
1022 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1023 | RETRY |
1024 | |
1025 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1026 | EXPIRE |
1027 | |
1028 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1029 | MINIMUM |
1030 | |
1031 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1032
1033where:
1034
1035MNAME The <domain-name> of the name server that was the
1036 original or primary source of data for this zone.
1037
1038RNAME A <domain-name> which specifies the mailbox of the
1039 person responsible for this zone.
1040
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
1044 arithmetic.
1045
1046REFRESH A 32 bit time interval before the zone should be
1047 refreshed.
1048
1049RETRY A 32 bit time interval that should elapse before a
1050 failed refresh should be retried.
1051
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.
1055
1056
1057
1058
1059
1060Mockapetris [Page 19]
1061
1062RFC 1035 Domain Implementation and Specification November 1987
1063
1064
1065MINIMUM The unsigned 32 bit minimum TTL field that should be
1066 exported with any RR from this zone.
1067
1068SOA records cause no additional section processing.
1069
1070All times are in units of seconds.
1071
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.
1082
1083
10843.3.14. TXT RDATA format
1085
1086 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1087 / TXT-DATA /
1088 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1089
1090where:
1091
1092TXT-DATA One or more <character-string>s.
1093
1094TXT RRs are used to hold descriptive text. The semantics of the text
1095depends on the domain where it is found.
1096
10973.4. Internet specific RRs
1098
10993.4.1. A RDATA format
1100
1101 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1102 | ADDRESS |
1103 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1104
1105where:
1106
1107ADDRESS A 32 bit Internet address.
1108
1109Hosts that have multiple Internet addresses will have multiple A
1110records.
1111
1112
1113
1114
1115
1116Mockapetris [Page 20]
1117
1118RFC 1035 Domain Implementation and Specification November 1987
1119
1120
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").
1125
11263.4.2. WKS RDATA format
1127
1128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1129 | ADDRESS |
1130 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1131 | PROTOCOL | |
1132 +--+--+--+--+--+--+--+--+ |
1133 | |
1134 / <BIT MAP> /
1135 / /
1136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1137
1138where:
1139
1140ADDRESS An 32 bit Internet address
1141
1142PROTOCOL An 8 bit IP protocol number
1143
1144<BIT MAP> A variable length bit map. The bit map must be a
1145 multiple of 8 bits long.
1146
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].
1154
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
1158address.
1159
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.
1163
1164WKS RRs cause no additional section processing.
1165
1166In master files, both ports and protocols are expressed using mnemonics
1167or decimal numbers.
1168
1169
1170
1171
1172Mockapetris [Page 21]
1173
1174RFC 1035 Domain Implementation and Specification November 1987
1175
1176
11773.5. IN-ADDR.ARPA domain
1178
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
1184Internet.
1185
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.
1191
1192The domain begins at IN-ADDR.ARPA and has a substructure which follows
1193the Internet addressing structure.
1194
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
1200zero).
1201
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.
1210
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.
1218
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.
1222
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
1225
1226
1227
1228Mockapetris [Page 22]
1229
1230RFC 1035 Domain Implementation and Specification November 1987
1231
1232
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:
1237
1238 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1239 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1240 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1241 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1242 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1243 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1244 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1245 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1246 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
1247 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
1248
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:
1252
1253 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
1254 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
1255
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
1258these gateways.
1259
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:
1263
1264 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
1265
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.
1270
1271 - Gateways will often have two names in separate domains, only
1272 one of which can be primary.
1273
1274 - Systems that use the domain database to initialize their
1275 routing tables must start with enough gateway information to
1276 guarantee that they can access the appropriate name server.
1277
1278 - The gateway data only reflects the existence of a gateway in a
1279 manner equivalent to the current HOSTS.TXT file. It doesn't
1280 replace the dynamic availability information from GGP or EGP.
1281
1282
1283
1284Mockapetris [Page 23]
1285
1286RFC 1035 Domain Implementation and Specification November 1987
1287
1288
12893.6. Defining new types, classes, and special namespaces
1290
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.
1296
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.
1305
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.
1308
1309TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
1310respectively.
1311
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.
1317
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.
1324
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.
1330
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
1337
1338
1339
1340Mockapetris [Page 24]
1341
1342RFC 1035 Domain Implementation and Specification November 1987
1343
1344
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.
1348
13494. MESSAGES
1350
13514.1. Format
1352
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:
1356
1357 +---------------------+
1358 | Header |
1359 +---------------------+
1360 | Question | the question for the name server
1361 +---------------------+
1362 | Answer | RRs answering the question
1363 +---------------------+
1364 | Authority | RRs pointing toward an authority
1365 +---------------------+
1366 | Additional | RRs holding additional information
1367 +---------------------+
1368
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
1372other opcode, etc.
1373
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
1383question.
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396Mockapetris [Page 25]
1397
1398RFC 1035 Domain Implementation and Specification November 1987
1399
1400
14014.1.1. Header section format
1402
1403The header contains the following fields:
1404
1405 1 1 1 1 1 1
1406 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1407 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1408 | ID |
1409 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1410 |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
1411 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1412 | QDCOUNT |
1413 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1414 | ANCOUNT |
1415 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1416 | NSCOUNT |
1417 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1418 | ARCOUNT |
1419 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1420
1421where:
1422
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.
1427
1428QR A one bit field that specifies whether this message is a
1429 query (0), or a response (1).
1430
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:
1434
1435 0 a standard query (QUERY)
1436
1437 1 an inverse query (IQUERY)
1438
1439 2 a server status request (STATUS)
1440
1441 3-15 reserved for future use
1442
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.
1446
1447 Note that the contents of the answer section may have
1448 multiple owner names because of aliases. The AA bit
1449
1450
1451
1452Mockapetris [Page 26]
1453
1454RFC 1035 Domain Implementation and Specification November 1987
1455
1456
1457 corresponds to the name which matches the query name, or
1458 the first owner name in the answer section.
1459
1460TC TrunCation - specifies that this message was truncated
1461 due to length greater than that permitted on the
1462 transmission channel.
1463
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.
1468
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.
1472
1473Z Reserved for future use. Must be zero in all queries
1474 and responses.
1475
1476RCODE Response code - this 4 bit field is set as part of
1477 responses. The values have the following
1478 interpretation:
1479
1480 0 No error condition
1481
1482 1 Format error - The name server was
1483 unable to interpret the query.
1484
1485 2 Server failure - The name server was
1486 unable to process this query due to a
1487 problem with the name server.
1488
1489 3 Name Error - Meaningful only for
1490 responses from an authoritative name
1491 server, this code signifies that the
1492 domain name referenced in the query does
1493 not exist.
1494
1495 4 Not Implemented - The name server does
1496 not support the requested kind of query.
1497
1498 5 Refused - The name server refuses to
1499 perform the specified operation for
1500 policy reasons. For example, a name
1501 server may not wish to provide the
1502 information to the particular requester,
1503 or a name server may not wish to perform
1504 a particular operation (e.g., zone
1505
1506
1507
1508Mockapetris [Page 27]
1509
1510RFC 1035 Domain Implementation and Specification November 1987
1511
1512
1513 transfer) for particular data.
1514
1515 6-15 Reserved for future use.
1516
1517QDCOUNT an unsigned 16 bit integer specifying the number of
1518 entries in the question section.
1519
1520ANCOUNT an unsigned 16 bit integer specifying the number of
1521 resource records in the answer section.
1522
1523NSCOUNT an unsigned 16 bit integer specifying the number of name
1524 server resource records in the authority records
1525 section.
1526
1527ARCOUNT an unsigned 16 bit integer specifying the number of
1528 resource records in the additional records section.
1529
15304.1.2. Question section format
1531
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:
1535
1536 1 1 1 1 1 1
1537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1538 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1539 | |
1540 / QNAME /
1541 / /
1542 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1543 | QTYPE |
1544 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1545 | QCLASS |
1546 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1547
1548where:
1549
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
1555 padding is used.
1556
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.
1561
1562
1563
1564Mockapetris [Page 28]
1565
1566RFC 1035 Domain Implementation and Specification November 1987
1567
1568
1569QCLASS a two octet code that specifies the class of the query.
1570 For example, the QCLASS field is IN for the Internet.
1571
15724.1.3. Resource record format
1573
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:
1578 1 1 1 1 1 1
1579 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1580 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1581 | |
1582 / /
1583 / NAME /
1584 | |
1585 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1586 | TYPE |
1587 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1588 | CLASS |
1589 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1590 | TTL |
1591 | |
1592 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1593 | RDLENGTH |
1594 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
1595 / RDATA /
1596 / /
1597 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1598
1599where:
1600
1601NAME a domain name to which this resource record pertains.
1602
1603TYPE two octets containing one of the RR type codes. This
1604 field specifies the meaning of the data in the RDATA
1605 field.
1606
1607CLASS two octets which specify the class of the data in the
1608 RDATA field.
1609
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.
1615
1616
1617
1618
1619
1620Mockapetris [Page 29]
1621
1622RFC 1035 Domain Implementation and Specification November 1987
1623
1624
1625RDLENGTH an unsigned 16 bit integer that specifies the length in
1626 octets of the RDATA field.
1627
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.
1633
16344.1.4. Message compression
1635
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
1640of the same name.
1641
1642The pointer takes the form of a two octet sequence:
1643
1644 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1645 | 1 1| OFFSET |
1646 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1647
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,
1654etc.
1655
1656The compression scheme allows a domain name in a message to be
1657represented as either:
1658
1659 - a sequence of labels ending in a zero octet
1660
1661 - a pointer
1662
1663 - a sequence of labels ending with a pointer
1664
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
1669formats.
1670
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
1673
1674
1675
1676Mockapetris [Page 30]
1677
1678RFC 1035 Domain Implementation and Specification November 1987
1679
1680
1681used, the length of the compressed name is used in the length
1682calculation, rather than the length of the expanded name.
1683
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
1687contain pointers.
1688
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:
1692
1693 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1694 20 | 1 | F |
1695 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1696 22 | 3 | I |
1697 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1698 24 | S | I |
1699 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1700 26 | 4 | A |
1701 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1702 28 | R | P |
1703 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1704 30 | A | 0 |
1705 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1706
1707 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1708 40 | 3 | F |
1709 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1710 42 | O | O |
1711 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1712 44 | 1 1| 20 |
1713 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1714
1715 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1716 64 | 1 1| 26 |
1717 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1718
1719 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1720 92 | 0 | |
1721 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1722
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
1729
1730
1731
1732Mockapetris [Page 31]
1733
1734RFC 1035 Domain Implementation and Specification November 1987
1735
1736
1737defined by a single octet of zeros at 92; the root domain name has no
1738labels.
1739
17404.2. Transport
1741
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.
1747
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
1750port 53 (decimal).
1751
17524.2.1. UDP usage
1753
1754Messages sent using UDP user server port 53 (decimal).
1755
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
1758the header.
1759
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.
1765
1766The optimal UDP retransmission policy will vary with performance of the
1767Internet and the needs of the client, but the following are recommended:
1768
1769 - The client should try other servers and server addresses
1770 before repeating a query to a specific address of a server.
1771
1772 - The retransmission interval should be based on prior
1773 statistics if possible. Too aggressive retransmission can
1774 easily slow responses for the community at large. Depending
1775 on how well connected the client is to its expected servers,
1776 the minimum retransmission interval should be 2-5 seconds.
1777
1778More suggestions on server selection and retransmission policy can be
1779found in the resolver section of this memo.
1780
17814.2.2. TCP usage
1782
1783Messages sent over TCP connections use server port 53 (decimal). The
1784message is prefixed with a two byte length field which gives the message
1785
1786
1787
1788Mockapetris [Page 32]
1789
1790RFC 1035 Domain Implementation and Specification November 1987
1791
1792
1793length, excluding the two byte length field. This length field allows
1794the low-level processing to assemble a complete message before beginning
1795to parse it.
1796
1797Several connection management policies are recommended:
1798
1799 - The server should not block other activities waiting for TCP
1800 data.
1801
1802 - The server should support multiple connections.
1803
1804 - The server should assume that the client will initiate
1805 connection closing, and should delay closing its end of the
1806 connection until all outstanding client requests have been
1807 satisfied.
1808
1809 - If the server needs to close a dormant connection to reclaim
1810 resources, it should wait until the connection has been idle
1811 for a period on the order of two minutes. In particular, the
1812 server should allow the SOA and AXFR request sequence (which
1813 begins a refresh operation) to be made on a single connection.
1814 Since the server would be unable to answer queries anyway, a
1815 unilateral close or reset may be used instead of a graceful
1816 close.
1817
18185. MASTER FILES
1819
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.
1826
18275.1. Format
1828
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).
1836
1837The following entries are defined:
1838
1839 <blank>[<comment>]
1840
1841
1842
1843
1844Mockapetris [Page 33]
1845
1846RFC 1035 Domain Implementation and Specification November 1987
1847
1848
1849 $ORIGIN <domain-name> [<comment>]
1850
1851 $INCLUDE <file-name> [<domain-name>] [<comment>]
1852
1853 <domain-name><rr> [<comment>]
1854
1855 <blank><rr> [<comment>]
1856
1857Blank lines, with or without comments, are allowed anywhere in the file.
1858
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.
1867
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.
1871
1872<rr> contents take one of the following forms:
1873
1874 [<TTL>] [<class>] <type> <RDATA>
1875
1876 [<class>] [<TTL>] <type> <RDATA>
1877
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.)
1885
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.
1895
1896
1897
1898
1899
1900Mockapetris [Page 34]
1901
1902RFC 1035 Domain Implementation and Specification November 1987
1903
1904
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).
1909
1910Because these files are text files several special encodings are
1911necessary to allow arbitrary data to be loaded. In particular:
1912
1913 of the root.
1914
1915@ A free standing @ is used to denote the current origin.
1916
1917\X where X is any character other than a digit (0-9), is
1918 used to quote that character so that its special meaning
1919 does not apply. For example, "\." can be used to place
1920 a dot character in a label.
1921
1922\DDD where each D is a digit is the octet corresponding to
1923 the decimal number described by DDD. The resulting
1924 octet is assumed to be text and is not checked for
1925 special meaning.
1926
1927( ) Parentheses are used to group data that crosses a line
1928 boundary. In effect, line terminations are not
1929 recognized within parentheses.
1930
1931; Semicolon is used to start a comment; the remainder of
1932 the line is ignored.
1933
19345.2. Use of master files to define zones
1935
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).
1943
1944Several other validity checks that should be performed in addition to
1945insuring that the file is syntactically correct:
1946
1947 1. All RRs in the file should have the same class.
1948
1949 2. Exactly one SOA RR should be present at the top of the zone.
1950
1951 3. If delegations are present and glue information is required,
1952 it should be present.
1953
1954
1955
1956Mockapetris [Page 35]
1957
1958RFC 1035 Domain Implementation and Specification November 1987
1959
1960
1961 4. Information present outside of the authoritative nodes in the
1962 zone should be glue information, rather than the result of an
1963 origin or similar error.
1964
19655.3. Master file example
1966
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:
1969
1970@ IN SOA VENERA Action\.domains (
1971 20 ; SERIAL
1972 7200 ; REFRESH
1973 600 ; RETRY
1974 3600000; EXPIRE
1975 60) ; MINIMUM
1976
1977 NS A.ISI.EDU.
1978 NS VENERA
1979 NS VAXA
1980 MX 10 VENERA
1981 MX 20 VAXA
1982
1983A A 26.3.0.103
1984
1985VENERA A 10.1.0.52
1986 A 128.9.0.32
1987
1988VAXA A 10.2.0.27
1989 A 128.9.0.33
1990
1991
1992$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
1993
1994Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
1995
1996 MOE MB A.ISI.EDU.
1997 LARRY MB A.ISI.EDU.
1998 CURLEY MB A.ISI.EDU.
1999 STOOGES MG MOE
2000 MG LARRY
2001 MG CURLEY
2002
2003Note the use of the \ character in the SOA RR to specify the responsible
2004person mailbox "Action.domains@E.ISI.EDU".
2005
2006
2007
2008
2009
2010
2011
2012Mockapetris [Page 36]
2013
2014RFC 1035 Domain Implementation and Specification November 1987
2015
2016
20176. NAME SERVER IMPLEMENTATION
2018
20196.1. Architecture
2020
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.
2027
20286.1.1. Control
2029
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.
2041
20426.1.2. Database
2043
2044While name server implementations are free to use any internal data
2045structures they choose, the suggested structure consists of three major
2046parts:
2047
2048 - A "catalog" data structure which lists the zones available to
2049 this server, and a "pointer" to the zone data structure. The
2050 main purpose of this structure is to find the nearest ancestor
2051 zone, if any, for arriving standard queries.
2052
2053 - Separate data structures for each of the zones held by the
2054 name server.
2055
2056 - A data structure for cached data. (or perhaps separate caches
2057 for different classes)
2058
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
2065
2066
2067
2068Mockapetris [Page 37]
2069
2070RFC 1035 Domain Implementation and Specification November 1987
2071
2072
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).
2075
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
2085DNS.
2086
2087The use of separate structures for the different parts of the database
2088is motivated by several factors:
2089
2090 - The catalog structure can be an almost static structure that
2091 need change only when the system administrator changes the
2092 zones supported by the server. This structure can also be
2093 used to store parameters used to control refreshing
2094 activities.
2095
2096 - The individual data structures for zones allow a zone to be
2097 replaced simply by changing a pointer in the catalog. Zone
2098 refresh operations can build a new structure and, when
2099 complete, splice it into the database via a simple pointer
2100 replacement. It is very important that when a zone is
2101 refreshed, queries should not use old and new data
2102 simultaneously.
2103
2104 - With the proper search procedures, authoritative data in zones
2105 will always "hide", and hence take precedence over, cached
2106 data.
2107
2108 - Errors in zone definitions that cause overlapping zones, etc.,
2109 may cause erroneous responses to queries, but problem
2110 determination is simplified, and the contents of one "bad"
2111 zone can't corrupt another.
2112
2113 - Since the cache is most frequently updated, it is most
2114 vulnerable to corruption during system restarts. It can also
2115 become full of expired RR data. In either case, it can easily
2116 be discarded without disturbing zone data.
2117
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
2121
2122
2123
2124Mockapetris [Page 38]
2125
2126RFC 1035 Domain Implementation and Specification November 1987
2127
2128
2129includes the catalog structure (including the state of refreshing for
2130each zone) and the zone data itself.
2131
21326.1.3. Time
2133
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.
2138
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.
2147
21486.2. Standard query processing
2149
2150The major algorithm for standard query processing is presented in
2151[RFC-1034].
2152
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.
2156
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.
2160
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.
2165
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
2170semantics.
2171
21726.3. Zone refresh and reload processing
2173
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
2177
2178
2179
2180Mockapetris [Page 39]
2181
2182RFC 1035 Domain Implementation and Specification November 1987
2183
2184
2185should answer queries as if it were not supposed to possess the zone.
2186
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.
2192
21936.4. Inverse queries (Optional)
2194
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.
2201
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.
2208
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.
2219
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
2227data is character.
2228
2229When a name server processes an inverse query, it either returns:
2230
2231 1. zero, one, or multiple domain names for the specified
2232 resource as QNAMEs in the question section
2233
2234
2235
2236Mockapetris [Page 40]
2237
2238RFC 1035 Domain Implementation and Specification November 1987
2239
2240
2241 2. an error code indicating that the name server doesn't support
2242 inverse mapping of the specified resource type.
2243
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
2247QNAME.
2248
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
2254one address existed.
2255
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:
2259
2260 +-----------------------------------------+
2261 Header | OPCODE=IQUERY, ID=997 |
2262 +-----------------------------------------+
2263 Question | <empty> |
2264 +-----------------------------------------+
2265 Answer | <anyname> A IN 10.1.0.52 |
2266 +-----------------------------------------+
2267 Authority | <empty> |
2268 +-----------------------------------------+
2269 Additional | <empty> |
2270 +-----------------------------------------+
2271
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
2277this query might be:
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292Mockapetris [Page 41]
2293
2294RFC 1035 Domain Implementation and Specification November 1987
2295
2296
2297 +-----------------------------------------+
2298 Header | OPCODE=RESPONSE, ID=997 |
2299 +-----------------------------------------+
2300 Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
2301 +-----------------------------------------+
2302 Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
2303 +-----------------------------------------+
2304 Authority | <empty> |
2305 +-----------------------------------------+
2306 Additional | <empty> |
2307 +-----------------------------------------+
2308
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.
2315
23166.4.3. Inverse query processing
2317
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.
2322
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
2326be redone.
2327
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.
2330
23316.5. Completion queries and responses
2332
2333The optional completion services described in RFC-882 and RFC-883 have
2334been deleted. Redesigned services may become available in the future.
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348Mockapetris [Page 42]
2349
2350RFC 1035 Domain Implementation and Specification November 1987
2351
2352
23537. RESOLVER IMPLEMENTATION
2354
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
2358of this memo.
2359
23607.1. Transforming a user request into a query
2361
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
2371won't be available.
2372
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
2376typically contain:
2377
2378 - A timestamp indicating the time the request began.
2379 The timestamp is used to decide whether RRs in the database
2380 can be used or are out of date. This timestamp uses the
2381 absolute time format previously discussed for RR storage in
2382 zones and caches. Note that when an RRs TTL indicates a
2383 relative time, the RR must be timely, since it is part of a
2384 zone. When the RR has an absolute time, it is part of a
2385 cache, and the TTL of the RR is compared against the timestamp
2386 for the start of the request.
2387
2388 Note that using the timestamp is superior to using a current
2389 time, since it allows RRs with TTLs of zero to be entered in
2390 the cache in the usual manner, but still used by the current
2391 request, even after intervals of many seconds due to system
2392 load, query retransmission timeouts, etc.
2393
2394 - Some sort of parameters to limit the amount of work which will
2395 be performed for this request.
2396
2397 The amount of work which a resolver will do in response to a
2398 client request must be limited to guard against errors in the
2399 database, such as circular CNAME references, and operational
2400 problems, such as network partition which prevents the
2401
2402
2403
2404Mockapetris [Page 43]
2405
2406RFC 1035 Domain Implementation and Specification November 1987
2407
2408
2409 resolver from accessing the name servers it needs. While
2410 local limits on the number of times a resolver will retransmit
2411 a particular query to a particular name server address are
2412 essential, the resolver should have a global per-request
2413 counter to limit work on a single request. The counter should
2414 be set to some initial value and decremented whenever the
2415 resolver performs any action (retransmission timeout,
2416 retransmission, etc.) If the counter passes zero, the request
2417 is terminated with a temporary error.
2418
2419 Note that if the resolver structure allows one request to
2420 start others in parallel, such as when the need to access a
2421 name server for one request causes a parallel resolve for the
2422 name server's addresses, the spawned request should be started
2423 with a lower counter. This prevents circular references in
2424 the database from starting a chain reaction of resolver
2425 activity.
2426
2427 - The SLIST data structure discussed in [RFC-1034].
2428
2429 This structure keeps track of the state of a request if it
2430 must wait for answers from foreign name servers.
2431
24327.2. Sending the queries
2433
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
2444contact.
2445
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
2457
2458
2459
2460Mockapetris [Page 44]
2461
2462RFC 1035 Domain Implementation and Specification November 1987
2463
2464
2465client.
2466
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.
2475
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.
2490
2491Note that whenever a delegation is followed, the resolver algorithm
2492reinitializes SLIST.
2493
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.
2499
2500Some fine points:
2501
2502 - The resolver may encounter a situation where no addresses are
2503 available for any of the name servers named in SLIST, and
2504 where the servers in the list are precisely those which would
2505 normally be used to look up their own addresses. This
2506 situation typically occurs when the glue address RRs have a
2507 smaller TTL than the NS RRs marking delegation, or when the
2508 resolver caches the result of a NS search. The resolver
2509 should detect this condition and restart the search at the
2510 next ancestor zone, or alternatively at the root.
2511
2512
2513
2514
2515
2516Mockapetris [Page 45]
2517
2518RFC 1035 Domain Implementation and Specification November 1987
2519
2520
2521 - If a resolver gets a server error or other bizarre response
2522 from a name server, it should remove it from SLIST, and may
2523 wish to schedule an immediate transmission to the next
2524 candidate server address.
2525
25267.3. Processing responses
2527
2528The first step in processing arriving response datagrams is to parse the
2529response. This procedure should include:
2530
2531 - Check the header for reasonableness. Discard datagrams which
2532 are queries when responses are expected.
2533
2534 - Parse the sections of the message, and insure that all RRs are
2535 correctly formatted.
2536
2537 - As an optional step, check the TTLs of arriving data looking
2538 for RRs with excessively long TTLs. If a RR has an
2539 excessively long TTL, say greater than 1 week, either discard
2540 the whole response, or limit all TTLs in the response to 1
2541 week.
2542
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:
2549
2550 - Some name servers send their responses from different
2551 addresses than the one used to receive the query. That is, a
2552 resolver cannot rely that a response will come from the same
2553 address which it sent the corresponding query to. This name
2554 server bug is typically encountered in UNIX systems.
2555
2556 - If the resolver retransmits a particular request to a name
2557 server it should be able to use a response from any of the
2558 transmissions. However, if it is using the response to sample
2559 the round trip time to access the name server, it must be able
2560 to determine which transmission matches the response (and keep
2561 transmission times for each outgoing message), or only
2562 calculate round trip times based on initial transmissions.
2563
2564 - A name server will occasionally not have a current copy of a
2565 zone which it should have according to some NS RRs. The
2566 resolver should simply remove the name server from the current
2567 SLIST, and continue.
2568
2569
2570
2571
2572Mockapetris [Page 46]
2573
2574RFC 1035 Domain Implementation and Specification November 1987
2575
2576
25777.4. Using the cache
2578
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:
2582
2583 - When several RRs of the same type are available for a
2584 particular owner name, the resolver should either cache them
2585 all or none at all. When a response is truncated, and a
2586 resolver doesn't know whether it has a complete set, it should
2587 not cache a possibly partial set of RRs.
2588
2589 - Cached data should never be used in preference to
2590 authoritative data, so if caching would cause this to happen
2591 the data should not be cached.
2592
2593 - The results of an inverse query should not be cached.
2594
2595 - The results of standard queries where the QNAME contains "*"
2596 labels if the data might be used to construct wildcards. The
2597 reason is that the cache does not necessarily contain existing
2598 RRs or zone boundary information which is necessary to
2599 restrict the application of the wildcard RRs.
2600
2601 - RR data in responses of dubious reliability. When a resolver
2602 receives unsolicited responses or RR data other than that
2603 requested, it should discard it without caching it. The basic
2604 implication is that all sanity checks on a packet should be
2605 performed before any of it is cached.
2606
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.
2613
26148. MAIL SUPPORT
2615
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
2623subject to change.
2624
2625
2626
2627
2628Mockapetris [Page 47]
2629
2630RFC 1035 Domain Implementation and Specification November 1987
2631
2632
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].
2637
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.
2648
26498.1. Mail exchange binding
2650
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.
2655
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>.
2661
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>.
2666
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
2672addresses.
2673
26748.2. Mailbox binding (Experimental)
2675
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.
2679
2680Several outcomes are possible for this query:
2681
2682
2683
2684Mockapetris [Page 48]
2685
2686RFC 1035 Domain Implementation and Specification November 1987
2687
2688
2689 1. The query can return a name error indicating that the mailbox
2690 does not exist as a domain name.
2691
2692 In the long term, this would indicate that the specified
2693 mailbox doesn't exist. However, until the use of mailbox
2694 binding is universal, this error condition should be
2695 interpreted to mean that the organization identified by the
2696 global part does not support mailbox binding. The
2697 appropriate procedure is to revert to exchange binding at
2698 this point.
2699
2700 2. The query can return a Mail Rename (MR) RR.
2701
2702 The MR RR carries new mailbox specification in its RDATA
2703 field. The mailer should replace the old mailbox with the
2704 new one and retry the operation.
2705
2706 3. The query can return a MB RR.
2707
2708 The MB RR carries a domain name for a host in its RDATA
2709 field. The mailer should deliver the message to that host
2710 via whatever protocol is applicable, e.g., b,SMTP.
2711
2712 4. The query can return one or more Mail Group (MG) RRs.
2713
2714 This condition means that the mailbox was actually a mailing
2715 list or mail group, rather than a single mailbox. Each MG RR
2716 has a RDATA field that identifies a mailbox that is a member
2717 of the group. The mailer should deliver a copy of the
2718 message to each member.
2719
2720 5. The query can return a MB RR as well as one or more MG RRs.
2721
2722 This condition means the the mailbox was actually a mailing
2723 list. The mailer can either deliver the message to the host
2724 specified by the MB RR, which will in turn do the delivery to
2725 all members, or the mailer can use the MG RRs to do the
2726 expansion itself.
2727
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.
2737
2738
2739
2740Mockapetris [Page 49]
2741
2742RFC 1035 Domain Implementation and Specification November 1987
2743
2744
2745New fields may be added to this RR in the future.
2746
2747
27489. REFERENCES and BIBLIOGRAPHY
2749
2750[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
2751 Technical Plan - Name Service, April 1987, version 1.9.
2752
2753 Describes the fundamentals of the Hesiod name service.
2754
2755[IEN-116] J. Postel, "Internet Name Server", IEN-116,
2756 USC/Information Sciences Institute, August 1979.
2757
2758 A name service obsoleted by the Domain Name System, but
2759 still in use.
2760
2761[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
2762 Communications of the ACM, October 1986, volume 29, number
2763 10.
2764
2765[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
2766 Information Center, SRI International, December 1977.
2767
2768[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
2769 USC/Information Sciences Institute, August 1980.
2770
2771[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
2772 USC/Information Sciences Institute, September 1981.
2773
2774[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
2775 September 1981.
2776
2777 Suggests introduction of a hierarchy in place of a flat
2778 name space for the Internet.
2779
2780[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
2781 USC/Information Sciences Institute, February 1982.
2782
2783[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
2784 Internet Host Table Specification", RFC-810, Network
2785 Information Center, SRI International, March 1982.
2786
2787 Obsolete. See RFC-952.
2788
2789[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
2790 Server", RFC-811, Network Information Center, SRI
2791 International, March 1982.
2792
2793
2794
2795
2796Mockapetris [Page 50]
2797
2798RFC 1035 Domain Implementation and Specification November 1987
2799
2800
2801 Obsolete. See RFC-953.
2802
2803[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
2804 Network Information Center, SRI International, March
2805 1982.
2806
2807[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
2808 Internet User Applications", RFC-819, Network
2809 Information Center, SRI International, August 1982.
2810
2811 Early thoughts on the design of the domain system.
2812 Current implementation is completely different.
2813
2814[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
2815 USC/Information Sciences Institute, August 1980.
2816
2817[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
2818 RFC-830, Network Information Center, SRI International,
2819 October 1982.
2820
2821 Early thoughts on the design of the domain system.
2822 Current implementation is completely different.
2823
2824[RFC-882] P. Mockapetris, "Domain names - Concepts and
2825 Facilities," RFC-882, USC/Information Sciences
2826 Institute, November 1983.
2827
2828 Superceeded by this memo.
2829
2830[RFC-883] P. Mockapetris, "Domain names - Implementation and
2831 Specification," RFC-883, USC/Information Sciences
2832 Institute, November 1983.
2833
2834 Superceeded by this memo.
2835
2836[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
2837 RFC-920, USC/Information Sciences Institute,
2838 October 1984.
2839
2840 Explains the naming scheme for top level domains.
2841
2842[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
2843 Table Specification", RFC-952, SRI, October 1985.
2844
2845 Specifies the format of HOSTS.TXT, the host/address
2846 table replaced by the DNS.
2847
2848
2849
2850
2851
2852Mockapetris [Page 51]
2853
2854RFC 1035 Domain Implementation and Specification November 1987
2855
2856
2857[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
2858 RFC-953, SRI, October 1985.
2859
2860 This RFC contains the official specification of the
2861 hostname server protocol, which is obsoleted by the DNS.
2862 This TCP based protocol accesses information stored in
2863 the RFC-952 format, and is used to obtain copies of the
2864 host table.
2865
2866[RFC-973] P. Mockapetris, "Domain System Changes and
2867 Observations", RFC-973, USC/Information Sciences
2868 Institute, January 1986.
2869
2870 Describes changes to RFC-882 and RFC-883 and reasons for
2871 them.
2872
2873[RFC-974] C. Partridge, "Mail routing and the domain system",
2874 RFC-974, CSNET CIC BBN Labs, January 1986.
2875
2876 Describes the transition from HOSTS.TXT based mail
2877 addressing to the more powerful MX system used with the
2878 domain system.
2879
2880[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
2881 service on a TCP/UDP transport: Concepts and Methods",
2882 RFC-1001, March 1987.
2883
2884 This RFC and RFC-1002 are a preliminary design for
2885 NETBIOS on top of TCP/IP which proposes to base NetBIOS
2886 name service on top of the DNS.
2887
2888[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
2889 service on a TCP/UDP transport: Detailed
2890 Specifications", RFC-1002, March 1987.
2891
2892[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
2893 USC/Information Sciences Institute, May 1987.
2894
2895 Contains socket numbers and mnemonics for host names,
2896 operating systems, etc.
2897
2898[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
2899 November 1987.
2900
2901 Describes a plan for converting the MILNET to the DNS.
2902
2903[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
2904 Administrators", RFC-1032, November 1987.
2905
2906
2907
2908Mockapetris [Page 52]
2909
2910RFC 1035 Domain Implementation and Specification November 1987
2911
2912
2913 Describes the registration policies used by the NIC to
2914 administer the top level domains and delegate subzones.
2915
2916[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
2917 RFC-1033, November 1987.
2918
2919 A cookbook for domain administrators.
2920
2921[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
2922 Name Server", Computer Networks, vol 6, nr 3, July 1982.
2923
2924 Describes a name service for CSNET which is independent
2925 from the DNS and DNS use in the CSNET.
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964Mockapetris [Page 53]
2965
2966RFC 1035 Domain Implementation and Specification November 1987
2967
2968
2969Index
2970
2971 * 13
2972
2973 ; 33, 35
2974
2975 <character-string> 35
2976 <domain-name> 34
2977
2978 @ 35
2979
2980 \ 35
2981
2982 A 12
2983
2984 Byte order 8
2985
2986 CH 13
2987 Character case 9
2988 CLASS 11
2989 CNAME 12
2990 Completion 42
2991 CS 13
2992
2993 Hesiod 13
2994 HINFO 12
2995 HS 13
2996
2997 IN 13
2998 IN-ADDR.ARPA domain 22
2999 Inverse queries 40
3000
3001 Mailbox names 47
3002 MB 12
3003 MD 12
3004 MF 12
3005 MG 12
3006 MINFO 12
3007 MINIMUM 20
3008 MR 12
3009 MX 12
3010
3011 NS 12
3012 NULL 12
3013
3014 Port numbers 32
3015 Primary server 5
3016 PTR 12, 18
3017
3018
3019
3020Mockapetris [Page 54]
3021
3022RFC 1035 Domain Implementation and Specification November 1987
3023
3024
3025 QCLASS 13
3026 QTYPE 12
3027
3028 RDATA 12
3029 RDLENGTH 11
3030
3031 Secondary server 5
3032 SOA 12
3033 Stub resolvers 7
3034
3035 TCP 32
3036 TXT 12
3037 TYPE 11
3038
3039 UDP 32
3040
3041 WKS 12
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076Mockapetris [Page 55]
3077
3078