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