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