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