-Network Working Group P. Mockapetris
\rRequest for Comments: 1035 ISI
\r November 1987
\rObsoletes: RFCs 882, 883, 973
\r\r DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
\r\r\r1. STATUS OF THIS MEMO
\r\rThis RFC describes the details of the domain system and protocol, and
\rassumes that the reader is familiar with the concepts discussed in a
\rcompanion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
\r\rThe domain system is a mixture of functions and data types which are an
\rofficial protocol and functions and data types which are still
\rexperimental. Since the domain system is intentionally extensible, new
\rdata types and experimental behavior should always be expected in parts
\rof the system beyond the official protocol. The official protocol parts
\rinclude standard queries, responses and the Internet class RR data
\rformats (e.g., host addresses). Since the previous RFC set, several
\rdefinitions have changed, so some previous definitions are obsolete.
\r\rExperimental or obsolete features are clearly marked in these RFCs, and
\rsuch information should be used with caution.
\r\rThe reader is especially cautioned not to depend on the values which
\rappear in examples to be current or complete, since their purpose is
\rprimarily pedagogical. Distribution of this memo is unlimited.
\r\r Table of Contents
\r\r 1. STATUS OF THIS MEMO 1
\r 2. INTRODUCTION 3
\r 2.1. Overview 3
\r 2.2. Common configurations 4
\r 2.3. Conventions 7
\r 2.3.1. Preferred name syntax 7
\r 2.3.2. Data Transmission Order 8
\r 2.3.3. Character Case 9
\r 2.3.4. Size limits 10
\r 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
\r 3.1. Name space definitions 10
\r 3.2. RR definitions 11
\r 3.2.1. Format 11
\r 3.2.2. TYPE values 12
\r 3.2.3. QTYPE values 12
\r 3.2.4. CLASS values 13
\r\r\r\rMockapetris [Page 1]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r 3.2.5. QCLASS values 13
\r 3.3. Standard RRs 13
\r 3.3.1. CNAME RDATA format 14
\r 3.3.2. HINFO RDATA format 14
\r 3.3.3. MB RDATA format (EXPERIMENTAL) 14
\r 3.3.4. MD RDATA format (Obsolete) 15
\r 3.3.5. MF RDATA format (Obsolete) 15
\r 3.3.6. MG RDATA format (EXPERIMENTAL) 16
\r 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
\r 3.3.8. MR RDATA format (EXPERIMENTAL) 17
\r 3.3.9. MX RDATA format 17
\r 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
\r 3.3.11. NS RDATA format 18
\r 3.3.12. PTR RDATA format 18
\r 3.3.13. SOA RDATA format 19
\r 3.3.14. TXT RDATA format 20
\r 3.4. ARPA Internet specific RRs 20
\r 3.4.1. A RDATA format 20
\r 3.4.2. WKS RDATA format 21
\r 3.5. IN-ADDR.ARPA domain 22
\r 3.6. Defining new types, classes, and special namespaces 24
\r 4. MESSAGES 25
\r 4.1. Format 25
\r 4.1.1. Header section format 26
\r 4.1.2. Question section format 28
\r 4.1.3. Resource record format 29
\r 4.1.4. Message compression 30
\r 4.2. Transport 32
\r 4.2.1. UDP usage 32
\r 4.2.2. TCP usage 32
\r 5. MASTER FILES 33
\r 5.1. Format 33
\r 5.2. Use of master files to define zones 35
\r 5.3. Master file example 36
\r 6. NAME SERVER IMPLEMENTATION 37
\r 6.1. Architecture 37
\r 6.1.1. Control 37
\r 6.1.2. Database 37
\r 6.1.3. Time 39
\r 6.2. Standard query processing 39
\r 6.3. Zone refresh and reload processing 39
\r 6.4. Inverse queries (Optional) 40
\r 6.4.1. The contents of inverse queries and responses 40
\r 6.4.2. Inverse query and response example 41
\r 6.4.3. Inverse query processing 42
\r\r\r\r\r\r\rMockapetris [Page 2]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r 6.5. Completion queries and responses 42
\r 7. RESOLVER IMPLEMENTATION 43
\r 7.1. Transforming a user request into a query 43
\r 7.2. Sending the queries 44
\r 7.3. Processing responses 46
\r 7.4. Using the cache 47
\r 8. MAIL SUPPORT 47
\r 8.1. Mail exchange binding 48
\r 8.2. Mailbox binding (Experimental) 48
\r 9. REFERENCES and BIBLIOGRAPHY 50
\r Index 54
\r\r2. INTRODUCTION
\r\r2.1. Overview
\r\rThe goal of domain names is to provide a mechanism for naming resources
\rin such a way that the names are usable in different hosts, networks,
\rprotocol families, internets, and administrative organizations.
\r\rFrom the user's point of view, domain names are useful as arguments to a
\rlocal agent, called a resolver, which retrieves information associated
\rwith the domain name. Thus a user might ask for the host address or
\rmail information associated with a particular domain name. To enable
\rthe user to request a particular type of information, an appropriate
\rquery type is passed to the resolver with the domain name. To the user,
\rthe domain tree is a single information space; the resolver is
\rresponsible for hiding the distribution of data among name servers from
\rthe user.
\r\rFrom the resolver's point of view, the database that makes up the domain
\rspace is distributed among various name servers. Different parts of the
\rdomain space are stored in different name servers, although a particular
\rdata item will be stored redundantly in two or more name servers. The
\rresolver starts with knowledge of at least one name server. When the
\rresolver processes a user query it asks a known name server for the
\rinformation; in return, the resolver either receives the desired
\rinformation or a referral to another name server. Using these
\rreferrals, resolvers learn the identities and contents of other name
\rservers. Resolvers are responsible for dealing with the distribution of
\rthe domain space and dealing with the effects of name server failure by
\rconsulting redundant databases in other servers.
\r\rName servers manage two kinds of data. The first kind of data held in
\rsets called zones; each zone is the complete database for a particular
\r"pruned" subtree of the domain space. This data is called
\rauthoritative. A name server periodically checks to make sure that its
\rzones are up to date, and if not, obtains a new copy of updated zones
\r\r\r\rMockapetris [Page 3]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rfrom master files stored locally or in another name server. The second
\rkind of data is cached data which was acquired by a local resolver.
\rThis data may be incomplete, but improves the performance of the
\rretrieval process when non-local data is repeatedly accessed. Cached
\rdata is eventually discarded by a timeout mechanism.
\r\rThis functional structure isolates the problems of user interface,
\rfailure recovery, and distribution in the resolvers and isolates the
\rdatabase update and refresh problems in the name servers.
\r\r2.2. Common configurations
\r\rA host can participate in the domain name system in a number of ways,
\rdepending on whether the host runs programs that retrieve information
\rfrom the domain system, name servers that answer queries from other
\rhosts, or various combinations of both functions. The simplest, and
\rperhaps most typical, configuration is shown below:
\r\r Local Host | Foreign
\r |
\r +---------+ +----------+ | +--------+
\r | | user queries | |queries | | |
\r | User |-------------->| |---------|->|Foreign |
\r | Program | | Resolver | | | Name |
\r | |<--------------| |<--------|--| Server |
\r | | user responses| |responses| | |
\r +---------+ +----------+ | +--------+
\r | A |
\r cache additions | | references |
\r V | |
\r +----------+ |
\r | cache | |
\r +----------+ |
\r\rUser programs interact with the domain name space through resolvers; the
\rformat of user queries and user responses is specific to the host and
\rits operating system. User queries will typically be operating system
\rcalls, and the resolver and its cache will be part of the host operating
\rsystem. Less capable hosts may choose to implement the resolver as a
\rsubroutine to be linked in with every program that needs its services.
\rResolvers answer user queries with information they acquire via queries
\rto foreign name servers and the local cache.
\r\rNote that the resolver may have to make several queries to several
\rdifferent foreign name servers to answer a particular user query, and
\rhence the resolution of a user query may involve several network
\raccesses and an arbitrary amount of time. The queries to foreign name
\rservers and the corresponding responses have a standard format described
\r\r\r\rMockapetris [Page 4]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rin this memo, and may be datagrams.
\r\rDepending on its capabilities, a name server could be a stand alone
\rprogram on a dedicated machine or a process or processes on a large
\rtimeshared host. A simple configuration might be:
\r\r Local Host | Foreign
\r |
\r +---------+ |
\r / /| |
\r +---------+ | +----------+ | +--------+
\r | | | | |responses| | |
\r | | | | Name |---------|->|Foreign |
\r | Master |-------------->| Server | | |Resolver|
\r | files | | | |<--------|--| |
\r | |/ | | queries | +--------+
\r +---------+ +----------+ |
\r\rHere a primary name server acquires information about one or more zones
\rby reading master files from its local file system, and answers queries
\rabout those zones that arrive from foreign resolvers.
\r\rThe DNS requires that all zones be redundantly supported by more than
\rone name server. Designated secondary servers can acquire zones and
\rcheck for updates from the primary server using the zone transfer
\rprotocol of the DNS. This configuration is shown below:
\r\r Local Host | Foreign
\r |
\r +---------+ |
\r / /| |
\r +---------+ | +----------+ | +--------+
\r | | | | |responses| | |
\r | | | | Name |---------|->|Foreign |
\r | Master |-------------->| Server | | |Resolver|
\r | files | | | |<--------|--| |
\r | |/ | | queries | +--------+
\r +---------+ +----------+ |
\r A |maintenance | +--------+
\r | +------------|->| |
\r | queries | |Foreign |
\r | | | Name |
\r +------------------|--| Server |
\r maintenance responses | +--------+
\r\rIn this configuration, the name server periodically establishes a
\rvirtual circuit to a foreign name server to acquire a copy of a zone or
\rto check that an existing copy has not changed. The messages sent for
\r\r\r\rMockapetris [Page 5]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rthese maintenance activities follow the same form as queries and
\rresponses, but the message sequences are somewhat different.
\r\rThe information flow in a host that supports all aspects of the domain
\rname system is shown below:
\r\r Local Host | Foreign
\r |
\r +---------+ +----------+ | +--------+
\r | | user queries | |queries | | |
\r | User |-------------->| |---------|->|Foreign |
\r | Program | | Resolver | | | Name |
\r | |<--------------| |<--------|--| Server |
\r | | user responses| |responses| | |
\r +---------+ +----------+ | +--------+
\r | A |
\r cache additions | | references |
\r V | |
\r +----------+ |
\r | Shared | |
\r | database | |
\r +----------+ |
\r A | |
\r +---------+ refreshes | | references |
\r / /| | V |
\r +---------+ | +----------+ | +--------+
\r | | | | |responses| | |
\r | | | | Name |---------|->|Foreign |
\r | Master |-------------->| Server | | |Resolver|
\r | files | | | |<--------|--| |
\r | |/ | | queries | +--------+
\r +---------+ +----------+ |
\r A |maintenance | +--------+
\r | +------------|->| |
\r | queries | |Foreign |
\r | | | Name |
\r +------------------|--| Server |
\r maintenance responses | +--------+
\r\rThe shared database holds domain space data for the local name server
\rand resolver. The contents of the shared database will typically be a
\rmixture of authoritative data maintained by the periodic refresh
\roperations of the name server and cached data from previous resolver
\rrequests. The structure of the domain data and the necessity for
\rsynchronization between name servers and resolvers imply the general
\rcharacteristics of this database, but the actual format is up to the
\rlocal implementor.
\r\r\r\r\rMockapetris [Page 6]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rInformation flow can also be tailored so that a group of hosts act
\rtogether to optimize activities. Sometimes this is done to offload less
\rcapable hosts so that they do not have to implement a full resolver.
\rThis can be appropriate for PCs or hosts which want to minimize the
\ramount of new network code which is required. This scheme can also
\rallow a group of hosts can share a small number of caches rather than
\rmaintaining a large number of separate caches, on the premise that the
\rcentralized caches will have a higher hit ratio. In either case,
\rresolvers are replaced with stub resolvers which act as front ends to
\rresolvers located in a recursive server in one or more name servers
\rknown to perform that service:
\r\r Local Hosts | Foreign
\r |
\r +---------+ |
\r | | responses |
\r | Stub |<--------------------+ |
\r | Resolver| | |
\r | |----------------+ | |
\r +---------+ recursive | | |
\r queries | | |
\r V | |
\r +---------+ recursive +----------+ | +--------+
\r | | queries | |queries | | |
\r | Stub |-------------->| Recursive|---------|->|Foreign |
\r | Resolver| | Server | | | Name |
\r | |<--------------| |<--------|--| Server |
\r +---------+ responses | |responses| | |
\r +----------+ | +--------+
\r | Central | |
\r | cache | |
\r +----------+ |
\r\rIn any case, note that domain components are always replicated for
\rreliability whenever possible.
\r\r2.3. Conventions
\r\rThe domain system has several conventions dealing with low-level, but
\rfundamental, issues. While the implementor is free to violate these
\rconventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
\rALL behavior observed from other hosts.
\r\r2.3.1. Preferred name syntax
\r\rThe DNS specifications attempt to be as general as possible in the rules
\rfor constructing domain names. The idea is that the name of any
\rexisting object can be expressed as a domain name with minimal changes.
\r\r\r\rMockapetris [Page 7]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rHowever, when assigning a domain name for an object, the prudent user
\rwill select a name which satisfies both the rules of the domain system
\rand any existing rules for the object, whether these rules are published
\ror implied by existing programs.
\r\rFor example, when naming a mail domain, the user should satisfy both the
\rrules of this memo and those in RFC-822. When creating a new host name,
\rthe old rules for HOSTS.TXT should be followed. This avoids problems
\rwhen old software is converted to use domain names.
\r\rThe following syntax will result in fewer problems with many
\r\rapplications that use domain names (e.g., mail, TELNET).
\r\r<domain> ::= <subdomain> | " "
\r\r<subdomain> ::= <label> | <subdomain> "." <label>
\r\r<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
\r\r<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
\r\r<let-dig-hyp> ::= <let-dig> | "-"
\r\r<let-dig> ::= <letter> | <digit>
\r\r<letter> ::= any one of the 52 alphabetic characters A through Z in
\rupper case and a through z in lower case
\r\r<digit> ::= any one of the ten digits 0 through 9
\r\rNote that while upper and lower case letters are allowed in domain
\rnames, no significance is attached to the case. That is, two names with
\rthe same spelling but different case are to be treated as if identical.
\r\rThe labels must follow the rules for ARPANET host names. They must
\rstart with a letter, end with a letter or digit, and have as interior
\rcharacters only letters, digits, and hyphen. There are also some
\rrestrictions on the length. Labels must be 63 characters or less.
\r\rFor example, the following strings identify hosts in the Internet:
\r\rA.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
\r\r2.3.2. Data Transmission Order
\r\rThe order of transmission of the header and data described in this
\rdocument is resolved to the octet level. Whenever a diagram shows a
\r\r\r\rMockapetris [Page 8]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rgroup of octets, the order of transmission of those octets is the normal
\rorder in which they are read in English. For example, in the following
\rdiagram, the octets are transmitted in the order they are numbered.
\r\r 0 1
\r 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
\r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\r | 1 | 2 |
\r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\r | 3 | 4 |
\r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\r | 5 | 6 |
\r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\r\rWhenever an octet represents a numeric quantity, the left most bit in
\rthe diagram is the high order or most significant bit. That is, the bit
\rlabeled 0 is the most significant bit. For example, the following
\rdiagram represents the value 170 (decimal).
\r\r 0 1 2 3 4 5 6 7
\r +-+-+-+-+-+-+-+-+
\r |1 0 1 0 1 0 1 0|
\r +-+-+-+-+-+-+-+-+
\r\rSimilarly, whenever a multi-octet field represents a numeric quantity
\rthe left most bit of the whole field is the most significant bit. When
\ra multi-octet quantity is transmitted the most significant octet is
\rtransmitted first.
\r\r2.3.3. Character Case
\r\rFor all parts of the DNS that are part of the official protocol, all
\rcomparisons between character strings (e.g., labels, domain names, etc.)
\rare done in a case-insensitive manner. At present, this rule is in
\rforce throughout the domain system without exception. However, future
\radditions beyond current usage may need to use the full binary octet
\rcapabilities in names, so attempts to store domain names in 7-bit ASCII
\ror use of special bytes to terminate labels, etc., should be avoided.
\r\rWhen data enters the domain system, its original case should be
\rpreserved whenever possible. In certain circumstances this cannot be
\rdone. For example, if two RRs are stored in a database, one at x.y and
\rone at X.Y, they are actually stored at the same place in the database,
\rand hence only one casing would be preserved. The basic rule is that
\rcase can be discarded only when data is used to define structure in a
\rdatabase, and two names are identical when compared in a case
\rinsensitive manner.
\r\r\r\r\rMockapetris [Page 9]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rLoss of case sensitive data must be minimized. Thus while data for x.y
\rand X.Y may both be stored under a single location x.y or X.Y, data for
\ra.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
\rgeneral, this preserves the case of the first label of a domain name,
\rbut forces standardization of interior node labels.
\r\rSystems administrators who enter data into the domain database should
\rtake care to represent the data they supply to the domain system in a
\rcase-consistent manner if their system is case-sensitive. The data
\rdistribution system in the domain system will ensure that consistent
\rrepresentations are preserved.
\r\r2.3.4. Size limits
\r\rVarious objects and parameters in the DNS have size limits. They are
\rlisted below. Some could be easily changed, others are more
\rfundamental.
\r\rlabels 63 octets or less
\r\rnames 255 octets or less
\r\rTTL positive values of a signed 32 bit number.
\r\rUDP messages 512 octets or less
\r\r3. DOMAIN NAME SPACE AND RR DEFINITIONS
\r\r3.1. Name space definitions
\r\rDomain names in messages are expressed in terms of a sequence of labels.
\rEach label is represented as a one octet length field followed by that
\rnumber of octets. Since every domain name ends with the null label of
\rthe root, a domain name is terminated by a length byte of zero. The
\rhigh order two bits of every length octet must be zero, and the
\rremaining six bits of the length field limit the label to 63 octets or
\rless.
\r\rTo simplify implementations, the total length of a domain name (i.e.,
\rlabel octets and label length octets) is restricted to 255 octets or
\rless.
\r\rAlthough labels can contain any 8 bit values in octets that make up a
\rlabel, it is strongly recommended that labels follow the preferred
\rsyntax described elsewhere in this memo, which is compatible with
\rexisting host naming conventions. Name servers and resolvers must
\rcompare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
\rwith zero parity. Non-alphabetic codes must match exactly.
\r\r\r\rMockapetris [Page 10]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.2. RR definitions
\r\r3.2.1. Format
\r\rAll RRs have the same top level format shown below:
\r\r 1 1 1 1 1 1
\r 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | |
\r / /
\r / NAME /
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | TYPE |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | CLASS |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | TTL |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | RDLENGTH |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
\r / RDATA /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\r\rwhere:
\r\rNAME an owner name, i.e., the name of the node to which this
\r resource record pertains.
\r\rTYPE two octets containing one of the RR TYPE codes.
\r\rCLASS two octets containing one of the RR CLASS codes.
\r\rTTL a 32 bit signed integer that specifies the time interval
\r that the resource record may be cached before the source
\r of the information should again be consulted. Zero
\r values are interpreted to mean that the RR can only be
\r used for the transaction in progress, and should not be
\r cached. For example, SOA records are always distributed
\r with a zero TTL to prohibit caching. Zero values can
\r also be used for extremely volatile data.
\r\rRDLENGTH an unsigned 16 bit integer that specifies the length in
\r octets of the RDATA field.
\r\r\r\rMockapetris [Page 11]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rRDATA a variable length string of octets that describes the
\r resource. The format of this information varies
\r according to the TYPE and CLASS of the resource record.
\r\r3.2.2. TYPE values
\r\rTYPE fields are used in resource records. Note that these types are a
\rsubset of QTYPEs.
\r\rTYPE value and meaning
\r\rA 1 a host address
\r\rNS 2 an authoritative name server
\r\rMD 3 a mail destination (Obsolete - use MX)
\r\rMF 4 a mail forwarder (Obsolete - use MX)
\r\rCNAME 5 the canonical name for an alias
\r\rSOA 6 marks the start of a zone of authority
\r\rMB 7 a mailbox domain name (EXPERIMENTAL)
\r\rMG 8 a mail group member (EXPERIMENTAL)
\r\rMR 9 a mail rename domain name (EXPERIMENTAL)
\r\rNULL 10 a null RR (EXPERIMENTAL)
\r\rWKS 11 a well known service description
\r\rPTR 12 a domain name pointer
\r\rHINFO 13 host information
\r\rMINFO 14 mailbox or mail list information
\r\rMX 15 mail exchange
\r\rTXT 16 text strings
\r\r3.2.3. QTYPE values
\r\rQTYPE fields appear in the question part of a query. QTYPES are a
\rsuperset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
\rfollowing QTYPEs are defined:
\r\r\r\rMockapetris [Page 12]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rAXFR 252 A request for a transfer of an entire zone
\r\rMAILB 253 A request for mailbox-related records (MB, MG or MR)
\r\rMAILA 254 A request for mail agent RRs (Obsolete - see MX)
\r\r* 255 A request for all records
\r\r3.2.4. CLASS values
\r\rCLASS fields appear in resource records. The following CLASS mnemonics
\rand values are defined:
\r\rIN 1 the Internet
\r\rCS 2 the CSNET class (Obsolete - used only for examples in
\r some obsolete RFCs)
\r\rCH 3 the CHAOS class
\r\rHS 4 Hesiod [Dyer 87]
\r\r3.2.5. QCLASS values
\r\rQCLASS fields appear in the question section of a query. QCLASS values
\rare a superset of CLASS values; every CLASS is a valid QCLASS. In
\raddition to CLASS values, the following QCLASSes are defined:
\r\r* 255 any class
\r\r3.3. Standard RRs
\r\rThe following RR definitions are expected to occur, at least
\rpotentially, in all classes. In particular, NS, SOA, CNAME, and PTR
\rwill be used in all classes, and have the same format in all classes.
\rBecause their RDATA format is known, all domain names in the RDATA
\rsection of these RRs may be compressed.
\r\r<domain-name> is a domain name represented as a series of labels, and
\rterminated by a label with zero length. <character-string> is a single
\rlength octet followed by that number of characters. <character-string>
\ris treated as binary information, and can be up to 256 characters in
\rlength (including the length octet).
\r\r\r\r\r\r\r\r\rMockapetris [Page 13]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.3.1. CNAME RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / CNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rCNAME A <domain-name> which specifies the canonical or primary
\r name for the owner. The owner name is an alias.
\r\rCNAME RRs cause no additional section processing, but name servers may
\rchoose to restart the query at the canonical name in certain cases. See
\rthe description of name server logic in [RFC-1034] for details.
\r\r3.3.2. HINFO RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / CPU /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / OS /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rCPU A <character-string> which specifies the CPU type.
\r\rOS A <character-string> which specifies the operating
\r system type.
\r\rStandard values for CPU and OS can be found in [RFC-1010].
\r\rHINFO records are used to acquire general information about a host. The
\rmain use is for protocols such as FTP that can use special procedures
\rwhen talking between machines or operating systems of the same type.
\r\r3.3.3. MB RDATA format (EXPERIMENTAL)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / MADNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rMADNAME A <domain-name> which specifies a host which has the
\r specified mailbox.
\r\r\r\rMockapetris [Page 14]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rMB records cause additional section processing which looks up an A type
\rRRs corresponding to MADNAME.
\r\r3.3.4. MD RDATA format (Obsolete)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / MADNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rMADNAME A <domain-name> which specifies a host which has a mail
\r agent for the domain which should be able to deliver
\r mail for the domain.
\r\rMD records cause additional section processing which looks up an A type
\rrecord corresponding to MADNAME.
\r\rMD is obsolete. See the definition of MX and [RFC-974] for details of
\rthe new scheme. The recommended policy for dealing with MD RRs found in
\ra master file is to reject them, or to convert them to MX RRs with a
\rpreference of 0.
\r\r3.3.5. MF RDATA format (Obsolete)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / MADNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rMADNAME A <domain-name> which specifies a host which has a mail
\r agent for the domain which will accept mail for
\r forwarding to the domain.
\r\rMF records cause additional section processing which looks up an A type
\rrecord corresponding to MADNAME.
\r\rMF is obsolete. See the definition of MX and [RFC-974] for details ofw
\rthe new scheme. The recommended policy for dealing with MD RRs found in
\ra master file is to reject them, or to convert them to MX RRs with a
\rpreference of 10.
\r\r\r\r\r\r\r\rMockapetris [Page 15]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.3.6. MG RDATA format (EXPERIMENTAL)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / MGMNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rMGMNAME A <domain-name> which specifies a mailbox which is a
\r member of the mail group specified by the domain name.
\r\rMG records cause no additional section processing.
\r\r3.3.7. MINFO RDATA format (EXPERIMENTAL)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / RMAILBX /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / EMAILBX /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rRMAILBX A <domain-name> which specifies a mailbox which is
\r responsible for the mailing list or mailbox. If this
\r domain name names the root, the owner of the MINFO RR is
\r responsible for itself. Note that many existing mailing
\r lists use a mailbox X-request for the RMAILBX field of
\r mailing list X, e.g., Msgroup-request for Msgroup. This
\r field provides a more general mechanism.
\r\r\rEMAILBX A <domain-name> which specifies a mailbox which is to
\r receive error messages related to the mailing list or
\r mailbox specified by the owner of the MINFO RR (similar
\r to the ERRORS-TO: field which has been proposed). If
\r this domain name names the root, errors should be
\r returned to the sender of the message.
\r\rMINFO records cause no additional section processing. Although these
\rrecords can be associated with a simple mailbox, they are usually used
\rwith a mailing list.
\r\r\r\r\r\r\r\r\rMockapetris [Page 16]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.3.8. MR RDATA format (EXPERIMENTAL)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / NEWNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rNEWNAME A <domain-name> which specifies a mailbox which is the
\r proper rename of the specified mailbox.
\r\rMR records cause no additional section processing. The main use for MR
\ris as a forwarding entry for a user who has moved to a different
\rmailbox.
\r\r3.3.9. MX RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | PREFERENCE |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / EXCHANGE /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rPREFERENCE A 16 bit integer which specifies the preference given to
\r this RR among others at the same owner. Lower values
\r are preferred.
\r\rEXCHANGE A <domain-name> which specifies a host willing to act as
\r a mail exchange for the owner name.
\r\rMX records cause type A additional section processing for the host
\rspecified by EXCHANGE. The use of MX RRs is explained in detail in
\r[RFC-974].
\r\r3.3.10. NULL RDATA format (EXPERIMENTAL)
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / <anything> /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rAnything at all may be in the RDATA field so long as it is 65535 octets
\ror less.
\r\r\r\r\rMockapetris [Page 17]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rNULL records cause no additional section processing. NULL RRs are not
\rallowed in master files. NULLs are used as placeholders in some
\rexperimental extensions of the DNS.
\r\r3.3.11. NS RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / NSDNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rNSDNAME A <domain-name> which specifies a host which should be
\r authoritative for the specified class and domain.
\r\rNS records cause both the usual additional section processing to locate
\ra type A record, and, when used in a referral, a special search of the
\rzone in which they reside for glue information.
\r\rThe NS RR states that the named host should be expected to have a zone
\rstarting at owner name of the specified class. Note that the class may
\rnot indicate the protocol family which should be used to communicate
\rwith the host, although it is typically a strong hint. For example,
\rhosts which are name servers for either Internet (IN) or Hesiod (HS)
\rclass information are normally queried using IN class protocols.
\r\r3.3.12. PTR RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / PTRDNAME /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rPTRDNAME A <domain-name> which points to some location in the
\r domain name space.
\r\rPTR records cause no additional section processing. These RRs are used
\rin special domains to point to some other location in the domain space.
\rThese records are simple data, and don't imply any special processing
\rsimilar to that performed by CNAME, which identifies aliases. See the
\rdescription of the IN-ADDR.ARPA domain for an example.
\r\r\r\r\r\r\r\r\rMockapetris [Page 18]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.3.13. SOA RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / MNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / RNAME /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | SERIAL |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | REFRESH |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | RETRY |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | EXPIRE |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | MINIMUM |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rMNAME The <domain-name> of the name server that was the
\r original or primary source of data for this zone.
\r\rRNAME A <domain-name> which specifies the mailbox of the
\r person responsible for this zone.
\r\rSERIAL The unsigned 32 bit version number of the original copy
\r of the zone. Zone transfers preserve this value. This
\r value wraps and should be compared using sequence space
\r arithmetic.
\r\rREFRESH A 32 bit time interval before the zone should be
\r refreshed.
\r\rRETRY A 32 bit time interval that should elapse before a
\r failed refresh should be retried.
\r\rEXPIRE A 32 bit time value that specifies the upper limit on
\r the time interval that can elapse before the zone is no
\r longer authoritative.
\r\r\r\r\r\rMockapetris [Page 19]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rMINIMUM The unsigned 32 bit minimum TTL field that should be
\r exported with any RR from this zone.
\r\rSOA records cause no additional section processing.
\r\rAll times are in units of seconds.
\r\rMost of these fields are pertinent only for name server maintenance
\roperations. However, MINIMUM is used in all query operations that
\rretrieve RRs from a zone. Whenever a RR is sent in a response to a
\rquery, the TTL field is set to the maximum of the TTL field from the RR
\rand the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
\rbound on the TTL field for all RRs in a zone. Note that this use of
\rMINIMUM should occur when the RRs are copied into the response and not
\rwhen the zone is loaded from a master file or via a zone transfer. The
\rreason for this provison is to allow future dynamic update facilities to
\rchange the SOA RR with known semantics.
\r\r\r3.3.14. TXT RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r / TXT-DATA /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rTXT-DATA One or more <character-string>s.
\r\rTXT RRs are used to hold descriptive text. The semantics of the text
\rdepends on the domain where it is found.
\r\r3.4. Internet specific RRs
\r\r3.4.1. A RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | ADDRESS |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rADDRESS A 32 bit Internet address.
\r\rHosts that have multiple Internet addresses will have multiple A
\rrecords.
\r\r\r\r\r\rMockapetris [Page 20]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rA records cause no additional section processing. The RDATA section of
\ran A line in a master file is an Internet address expressed as four
\rdecimal numbers separated by dots without any imbedded spaces (e.g.,
\r"10.2.0.52" or "192.0.5.6").
\r\r3.4.2. WKS RDATA format
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | ADDRESS |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | PROTOCOL | |
\r +--+--+--+--+--+--+--+--+ |
\r | |
\r / <BIT MAP> /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rADDRESS An 32 bit Internet address
\r\rPROTOCOL An 8 bit IP protocol number
\r\r<BIT MAP> A variable length bit map. The bit map must be a
\r multiple of 8 bits long.
\r\rThe WKS record is used to describe the well known services supported by
\ra particular protocol on a particular internet address. The PROTOCOL
\rfield specifies an IP protocol number, and the bit map has one bit per
\rport of the specified protocol. The first bit corresponds to port 0,
\rthe second to port 1, etc. If the bit map does not include a bit for a
\rprotocol of interest, that bit is assumed zero. The appropriate values
\rand mnemonics for ports and protocols are specified in [RFC-1010].
\r\rFor example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
\r25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
\rport 25; if zero, SMTP service is not supported on the specified
\raddress.
\r\rThe purpose of WKS RRs is to provide availability information for
\rservers for TCP and UDP. If a server supports both TCP and UDP, or has
\rmultiple Internet addresses, then multiple WKS RRs are used.
\r\rWKS RRs cause no additional section processing.
\r\rIn master files, both ports and protocols are expressed using mnemonics
\ror decimal numbers.
\r\r\r\r\rMockapetris [Page 21]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.5. IN-ADDR.ARPA domain
\r\rThe Internet uses a special domain to support gateway location and
\rInternet address to host mapping. Other classes may employ a similar
\rstrategy in other domains. The intent of this domain is to provide a
\rguaranteed method to perform host address to host name mapping, and to
\rfacilitate queries to locate all gateways on a particular network in the
\rInternet.
\r\rNote that both of these services are similar to functions that could be
\rperformed by inverse queries; the difference is that this part of the
\rdomain name space is structured according to address, and hence can
\rguarantee that the appropriate data can be located without an exhaustive
\rsearch of the domain space.
\r\rThe domain begins at IN-ADDR.ARPA and has a substructure which follows
\rthe Internet addressing structure.
\r\rDomain names in the IN-ADDR.ARPA domain are defined to have up to four
\rlabels in addition to the IN-ADDR.ARPA suffix. Each label represents
\rone octet of an Internet address, and is expressed as a character string
\rfor a decimal value in the range 0-255 (with leading zeros omitted
\rexcept in the case of a zero octet which is represented by a single
\rzero).
\r\rHost addresses are represented by domain names that have all four labels
\rspecified. Thus data for Internet address 10.2.0.52 is located at
\rdomain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
\rread, allows zones to be delegated which are exactly one network of
\raddress space. For example, 10.IN-ADDR.ARPA can be a zone containing
\rdata for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
\rMILNET. Address nodes are used to hold pointers to primary host names
\rin the normal domain space.
\r\rNetwork numbers correspond to some non-terminal nodes at various depths
\rin the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
\r2, or 3 octets. Network nodes are used to hold pointers to the primary
\rhost names of gateways attached to that network. Since a gateway is, by
\rdefinition, on more than one network, it will typically have two or more
\rnetwork nodes which point at it. Gateways will also have host level
\rpointers at their fully qualified addresses.
\r\rBoth the gateway pointers at network nodes and the normal host pointers
\rat full address nodes use the PTR RR to point back to the primary domain
\rnames of the corresponding hosts.
\r\rFor example, the IN-ADDR.ARPA domain will contain information about the
\rISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
\r\r\r\rMockapetris [Page 22]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rnet 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
\rgateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
\rGW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
\rand a name GW.LCS.MIT.EDU, the domain database would contain:
\r\r 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
\r 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
\r 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
\r 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
\r 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
\r 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
\r 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
\r 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
\r 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
\r 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
\r\rThus a program which wanted to locate gateways on net 10 would originate
\ra query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
\rwould receive two RRs in response:
\r\r 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
\r 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
\r\rThe program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
\rGW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
\rthese gateways.
\r\rA resolver which wanted to find the host name corresponding to Internet
\rhost address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
\rQCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
\r\r 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
\r\rSeveral cautions apply to the use of these services:
\r - Since the IN-ADDR.ARPA special domain and the normal domain
\r for a particular host or gateway will be in different zones,
\r the possibility exists that that the data may be inconsistent.
\r\r - Gateways will often have two names in separate domains, only
\r one of which can be primary.
\r\r - Systems that use the domain database to initialize their
\r routing tables must start with enough gateway information to
\r guarantee that they can access the appropriate name server.
\r\r - The gateway data only reflects the existence of a gateway in a
\r manner equivalent to the current HOSTS.TXT file. It doesn't
\r replace the dynamic availability information from GGP or EGP.
\r\r\r\rMockapetris [Page 23]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r3.6. Defining new types, classes, and special namespaces
\r\rThe previously defined types and classes are the ones in use as of the
\rdate of this memo. New definitions should be expected. This section
\rmakes some recommendations to designers considering additions to the
\rexisting facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
\rforum where general discussion of design issues takes place.
\r\rIn general, a new type is appropriate when new information is to be
\radded to the database about an existing object, or we need new data
\rformats for some totally new object. Designers should attempt to define
\rtypes and their RDATA formats that are generally applicable to all
\rclasses, and which avoid duplication of information. New classes are
\rappropriate when the DNS is to be used for a new protocol, etc which
\rrequires new class-specific data formats, or when a copy of the existing
\rname space is desired, but a separate management domain is necessary.
\r\rNew types and classes need mnemonics for master files; the format of the
\rmaster files requires that the mnemonics for type and class be disjoint.
\r\rTYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
\rrespectively.
\r\rThe present system uses multiple RRs to represent multiple values of a
\rtype rather than storing multiple values in the RDATA section of a
\rsingle RR. This is less efficient for most applications, but does keep
\rRRs shorter. The multiple RRs assumption is incorporated in some
\rexperimental work on dynamic update methods.
\r\rThe present system attempts to minimize the duplication of data in the
\rdatabase in order to insure consistency. Thus, in order to find the
\raddress of the host for a mail exchange, you map the mail domain name to
\ra host name, then the host name to addresses, rather than a direct
\rmapping to host address. This approach is preferred because it avoids
\rthe opportunity for inconsistency.
\r\rIn defining a new type of data, multiple RR types should not be used to
\rcreate an ordering between entries or express different formats for
\requivalent bindings, instead this information should be carried in the
\rbody of the RR and a single type used. This policy avoids problems with
\rcaching multiple types and defining QTYPEs to match multiple types.
\r\rFor example, the original form of mail exchange binding used two RR
\rtypes one to represent a "closer" exchange (MD) and one to represent a
\r"less close" exchange (MF). The difficulty is that the presence of one
\rRR type in a cache doesn't convey any information about the other
\rbecause the query which acquired the cached information might have used
\ra QTYPE of MF, MD, or MAILA (which matched both). The redesigned
\r\r\r\rMockapetris [Page 24]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rservice used a single type (MX) with a "preference" value in the RDATA
\rsection which can order different RRs. However, if any MX RRs are found
\rin the cache, then all should be there.
\r\r4. MESSAGES
\r\r4.1. Format
\r\rAll communications inside of the domain protocol are carried in a single
\rformat called a message. The top level format of message is divided
\rinto 5 sections (some of which are empty in certain cases) shown below:
\r\r +---------------------+
\r | Header |
\r +---------------------+
\r | Question | the question for the name server
\r +---------------------+
\r | Answer | RRs answering the question
\r +---------------------+
\r | Authority | RRs pointing toward an authority
\r +---------------------+
\r | Additional | RRs holding additional information
\r +---------------------+
\r\rThe header section is always present. The header includes fields that
\rspecify which of the remaining sections are present, and also specify
\rwhether the message is a query or a response, a standard query or some
\rother opcode, etc.
\r\rThe names of the sections after the header are derived from their use in
\rstandard queries. The question section contains fields that describe a
\rquestion to a name server. These fields are a query type (QTYPE), a
\rquery class (QCLASS), and a query domain name (QNAME). The last three
\rsections have the same format: a possibly empty list of concatenated
\rresource records (RRs). The answer section contains RRs that answer the
\rquestion; the authority section contains RRs that point toward an
\rauthoritative name server; the additional records section contains RRs
\rwhich relate to the query, but are not strictly answers for the
\rquestion.
\r\r\r\r\r\r\r\r\r\r\r\r\rMockapetris [Page 25]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r4.1.1. Header section format
\r\rThe header contains the following fields:
\r\r 1 1 1 1 1 1
\r 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | ID |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | QDCOUNT |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | ANCOUNT |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | NSCOUNT |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | ARCOUNT |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rID A 16 bit identifier assigned by the program that
\r generates any kind of query. This identifier is copied
\r the corresponding reply and can be used by the requester
\r to match up replies to outstanding queries.
\r\rQR A one bit field that specifies whether this message is a
\r query (0), or a response (1).
\r\rOPCODE A four bit field that specifies kind of query in this
\r message. This value is set by the originator of a query
\r and copied into the response. The values are:
\r\r 0 a standard query (QUERY)
\r\r 1 an inverse query (IQUERY)
\r\r 2 a server status request (STATUS)
\r\r 3-15 reserved for future use
\r\rAA Authoritative Answer - this bit is valid in responses,
\r and specifies that the responding name server is an
\r authority for the domain name in question section.
\r\r Note that the contents of the answer section may have
\r multiple owner names because of aliases. The AA bit
\r\r\r\rMockapetris [Page 26]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r corresponds to the name which matches the query name, or
\r the first owner name in the answer section.
\r\rTC TrunCation - specifies that this message was truncated
\r due to length greater than that permitted on the
\r transmission channel.
\r\rRD Recursion Desired - this bit may be set in a query and
\r is copied into the response. If RD is set, it directs
\r the name server to pursue the query recursively.
\r Recursive query support is optional.
\r\rRA Recursion Available - this be is set or cleared in a
\r response, and denotes whether recursive query support is
\r available in the name server.
\r\rZ Reserved for future use. Must be zero in all queries
\r and responses.
\r\rRCODE Response code - this 4 bit field is set as part of
\r responses. The values have the following
\r interpretation:
\r\r 0 No error condition
\r\r 1 Format error - The name server was
\r unable to interpret the query.
\r\r 2 Server failure - The name server was
\r unable to process this query due to a
\r problem with the name server.
\r\r 3 Name Error - Meaningful only for
\r responses from an authoritative name
\r server, this code signifies that the
\r domain name referenced in the query does
\r not exist.
\r\r 4 Not Implemented - The name server does
\r not support the requested kind of query.
\r\r 5 Refused - The name server refuses to
\r perform the specified operation for
\r policy reasons. For example, a name
\r server may not wish to provide the
\r information to the particular requester,
\r or a name server may not wish to perform
\r a particular operation (e.g., zone
\r\r\r\rMockapetris [Page 27]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r transfer) for particular data.
\r\r 6-15 Reserved for future use.
\r\rQDCOUNT an unsigned 16 bit integer specifying the number of
\r entries in the question section.
\r\rANCOUNT an unsigned 16 bit integer specifying the number of
\r resource records in the answer section.
\r\rNSCOUNT an unsigned 16 bit integer specifying the number of name
\r server resource records in the authority records
\r section.
\r\rARCOUNT an unsigned 16 bit integer specifying the number of
\r resource records in the additional records section.
\r\r4.1.2. Question section format
\r\rThe question section is used to carry the "question" in most queries,
\ri.e., the parameters that define what is being asked. The section
\rcontains QDCOUNT (usually 1) entries, each of the following format:
\r\r 1 1 1 1 1 1
\r 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | |
\r / QNAME /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | QTYPE |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | QCLASS |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rQNAME a domain name represented as a sequence of labels, where
\r each label consists of a length octet followed by that
\r number of octets. The domain name terminates with the
\r zero length octet for the null label of the root. Note
\r that this field may be an odd number of octets; no
\r padding is used.
\r\rQTYPE a two octet code which specifies the type of the query.
\r The values for this field include all codes valid for a
\r TYPE field, together with some more general codes which
\r can match more than one type of RR.
\r\r\r\rMockapetris [Page 28]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rQCLASS a two octet code that specifies the class of the query.
\r For example, the QCLASS field is IN for the Internet.
\r\r4.1.3. Resource record format
\r\rThe answer, authority, and additional sections all share the same
\rformat: a variable number of resource records, where the number of
\rrecords is specified in the corresponding count field in the header.
\rEach resource record has the following format:
\r 1 1 1 1 1 1
\r 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | |
\r / /
\r / NAME /
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | TYPE |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | CLASS |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | TTL |
\r | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | RDLENGTH |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
\r / RDATA /
\r / /
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rwhere:
\r\rNAME a domain name to which this resource record pertains.
\r\rTYPE two octets containing one of the RR type codes. This
\r field specifies the meaning of the data in the RDATA
\r field.
\r\rCLASS two octets which specify the class of the data in the
\r RDATA field.
\r\rTTL a 32 bit unsigned integer that specifies the time
\r interval (in seconds) that the resource record may be
\r cached before it should be discarded. Zero values are
\r interpreted to mean that the RR can only be used for the
\r transaction in progress, and should not be cached.
\r\r\r\r\r\rMockapetris [Page 29]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rRDLENGTH an unsigned 16 bit integer that specifies the length in
\r octets of the RDATA field.
\r\rRDATA a variable length string of octets that describes the
\r resource. The format of this information varies
\r according to the TYPE and CLASS of the resource record.
\r For example, the if the TYPE is A and the CLASS is IN,
\r the RDATA field is a 4 octet ARPA Internet address.
\r\r4.1.4. Message compression
\r\rIn order to reduce the size of messages, the domain system utilizes a
\rcompression scheme which eliminates the repetition of domain names in a
\rmessage. In this scheme, an entire domain name or a list of labels at
\rthe end of a domain name is replaced with a pointer to a prior occurance
\rof the same name.
\r\rThe pointer takes the form of a two octet sequence:
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r | 1 1| OFFSET |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rThe first two bits are ones. This allows a pointer to be distinguished
\rfrom a label, since the label must begin with two zero bits because
\rlabels are restricted to 63 octets or less. (The 10 and 01 combinations
\rare reserved for future use.) The OFFSET field specifies an offset from
\rthe start of the message (i.e., the first octet of the ID field in the
\rdomain header). A zero offset specifies the first byte of the ID field,
\retc.
\r\rThe compression scheme allows a domain name in a message to be
\rrepresented as either:
\r\r - a sequence of labels ending in a zero octet
\r\r - a pointer
\r\r - a sequence of labels ending with a pointer
\r\rPointers can only be used for occurances of a domain name where the
\rformat is not class specific. If this were not the case, a name server
\ror resolver would be required to know the format of all RRs it handled.
\rAs yet, there are no such cases, but they may occur in future RDATA
\rformats.
\r\rIf a domain name is contained in a part of the message subject to a
\rlength field (such as the RDATA section of an RR), and compression is
\r\r\r\rMockapetris [Page 30]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rused, the length of the compressed name is used in the length
\rcalculation, rather than the length of the expanded name.
\r\rPrograms are free to avoid using pointers in messages they generate,
\ralthough this will reduce datagram capacity, and may cause truncation.
\rHowever all programs are required to understand arriving messages that
\rcontain pointers.
\r\rFor example, a datagram might need to use the domain names F.ISI.ARPA,
\rFOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
\rmessage, these domain names might be represented as:
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 20 | 1 | F |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 22 | 3 | I |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 24 | S | I |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 26 | 4 | A |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 28 | R | P |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 30 | A | 0 |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 40 | 3 | F |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 42 | O | O |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 44 | 1 1| 20 |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 64 | 1 1| 26 |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r 92 | 0 | |
\r +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\r\rThe domain name for F.ISI.ARPA is shown at offset 20. The domain name
\rFOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
\rconcatenate a label for FOO to the previously defined F.ISI.ARPA. The
\rdomain name ARPA is defined at offset 64 using a pointer to the ARPA
\rcomponent of the name F.ISI.ARPA at 20; note that this pointer relies on
\rARPA being the last label in the string at 20. The root domain name is
\r\r\r\rMockapetris [Page 31]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rdefined by a single octet of zeros at 92; the root domain name has no
\rlabels.
\r\r4.2. Transport
\r\rThe DNS assumes that messages will be transmitted as datagrams or in a
\rbyte stream carried by a virtual circuit. While virtual circuits can be
\rused for any DNS activity, datagrams are preferred for queries due to
\rtheir lower overhead and better performance. Zone refresh activities
\rmust use virtual circuits because of the need for reliable transfer.
\r\rThe Internet supports name server access using TCP [RFC-793] on server
\rport 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
\rport 53 (decimal).
\r\r4.2.1. UDP usage
\r\rMessages sent using UDP user server port 53 (decimal).
\r\rMessages carried by UDP are restricted to 512 bytes (not counting the IP
\ror UDP headers). Longer messages are truncated and the TC bit is set in
\rthe header.
\r\rUDP is not acceptable for zone transfers, but is the recommended method
\rfor standard queries in the Internet. Queries sent using UDP may be
\rlost, and hence a retransmission strategy is required. Queries or their
\rresponses may be reordered by the network, or by processing in name
\rservers, so resolvers should not depend on them being returned in order.
\r\rThe optimal UDP retransmission policy will vary with performance of the
\rInternet and the needs of the client, but the following are recommended:
\r\r - The client should try other servers and server addresses
\r before repeating a query to a specific address of a server.
\r\r - The retransmission interval should be based on prior
\r statistics if possible. Too aggressive retransmission can
\r easily slow responses for the community at large. Depending
\r on how well connected the client is to its expected servers,
\r the minimum retransmission interval should be 2-5 seconds.
\r\rMore suggestions on server selection and retransmission policy can be
\rfound in the resolver section of this memo.
\r\r4.2.2. TCP usage
\r\rMessages sent over TCP connections use server port 53 (decimal). The
\rmessage is prefixed with a two byte length field which gives the message
\r\r\r\rMockapetris [Page 32]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rlength, excluding the two byte length field. This length field allows
\rthe low-level processing to assemble a complete message before beginning
\rto parse it.
\r\rSeveral connection management policies are recommended:
\r\r - The server should not block other activities waiting for TCP
\r data.
\r\r - The server should support multiple connections.
\r\r - The server should assume that the client will initiate
\r connection closing, and should delay closing its end of the
\r connection until all outstanding client requests have been
\r satisfied.
\r\r - If the server needs to close a dormant connection to reclaim
\r resources, it should wait until the connection has been idle
\r for a period on the order of two minutes. In particular, the
\r server should allow the SOA and AXFR request sequence (which
\r begins a refresh operation) to be made on a single connection.
\r Since the server would be unable to answer queries anyway, a
\r unilateral close or reset may be used instead of a graceful
\r close.
\r\r5. MASTER FILES
\r\rMaster files are text files that contain RRs in text form. Since the
\rcontents of a zone can be expressed in the form of a list of RRs a
\rmaster file is most often used to define a zone, though it can be used
\rto list a cache's contents. Hence, this section first discusses the
\rformat of RRs in a master file, and then the special considerations when
\ra master file is used to create a zone in some name server.
\r\r5.1. Format
\r\rThe format of these files is a sequence of entries. Entries are
\rpredominantly line-oriented, though parentheses can be used to continue
\ra list of items across a line boundary, and text literals can contain
\rCRLF within the text. Any combination of tabs and spaces act as a
\rdelimiter between the separate items that make up an entry. The end of
\rany line in the master file can end with a comment. The comment starts
\rwith a ";" (semicolon).
\r\rThe following entries are defined:
\r\r <blank>[<comment>]
\r\r\r\r\rMockapetris [Page 33]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r $ORIGIN <domain-name> [<comment>]
\r\r $INCLUDE <file-name> [<domain-name>] [<comment>]
\r\r <domain-name><rr> [<comment>]
\r\r <blank><rr> [<comment>]
\r\rBlank lines, with or without comments, are allowed anywhere in the file.
\r\rTwo control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
\rfollowed by a domain name, and resets the current origin for relative
\rdomain names to the stated name. $INCLUDE inserts the named file into
\rthe current file, and may optionally specify a domain name that sets the
\rrelative domain name origin for the included file. $INCLUDE may also
\rhave a comment. Note that a $INCLUDE entry never changes the relative
\rorigin of the parent file, regardless of changes to the relative origin
\rmade within the included file.
\r\rThe last two forms represent RRs. If an entry for an RR begins with a
\rblank, then the RR is assumed to be owned by the last stated owner. If
\ran RR entry begins with a <domain-name>, then the owner name is reset.
\r\r<rr> contents take one of the following forms:
\r\r [<TTL>] [<class>] <type> <RDATA>
\r\r [<class>] [<TTL>] <type> <RDATA>
\r\rThe RR begins with optional TTL and class fields, followed by a type and
\rRDATA field appropriate to the type and class. Class and type use the
\rstandard mnemonics, TTL is a decimal integer. Omitted class and TTL
\rvalues are default to the last explicitly stated values. Since type and
\rclass mnemonics are disjoint, the parse is unique. (Note that this
\rorder is different from the order used in examples and the order used in
\rthe actual RRs; the given order allows easier parsing and defaulting.)
\r\r<domain-name>s make up a large share of the data in the master file.
\rThe labels in the domain name are expressed as character strings and
\rseparated by dots. Quoting conventions allow arbitrary characters to be
\rstored in domain names. Domain names that end in a dot are called
\rabsolute, and are taken as complete. Domain names which do not end in a
\rdot are called relative; the actual domain name is the concatenation of
\rthe relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
\ran argument to the master file loading routine. A relative name is an
\rerror when no origin is available.
\r\r\r\r\r\rMockapetris [Page 34]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r<character-string> is expressed in one or two ways: as a contiguous set
\rof characters without interior spaces, or as a string beginning with a "
\rand ending with a ". Inside a " delimited string any character can
\roccur, except for a " itself, which must be quoted using \ (back slash).
\r\rBecause these files are text files several special encodings are
\rnecessary to allow arbitrary data to be loaded. In particular:
\r\r of the root.
\r\r@ A free standing @ is used to denote the current origin.
\r\r\X where X is any character other than a digit (0-9), is
\r used to quote that character so that its special meaning
\r does not apply. For example, "\." can be used to place
\r a dot character in a label.
\r\r\DDD where each D is a digit is the octet corresponding to
\r the decimal number described by DDD. The resulting
\r octet is assumed to be text and is not checked for
\r special meaning.
\r\r( ) Parentheses are used to group data that crosses a line
\r boundary. In effect, line terminations are not
\r recognized within parentheses.
\r\r; Semicolon is used to start a comment; the remainder of
\r the line is ignored.
\r\r5.2. Use of master files to define zones
\r\rWhen a master file is used to load a zone, the operation should be
\rsuppressed if any errors are encountered in the master file. The
\rrationale for this is that a single error can have widespread
\rconsequences. For example, suppose that the RRs defining a delegation
\rhave syntax errors; then the server will return authoritative name
\rerrors for all names in the subzone (except in the case where the
\rsubzone is also present on the server).
\r\rSeveral other validity checks that should be performed in addition to
\rinsuring that the file is syntactically correct:
\r\r 1. All RRs in the file should have the same class.
\r\r 2. Exactly one SOA RR should be present at the top of the zone.
\r\r 3. If delegations are present and glue information is required,
\r it should be present.
\r\r\r\rMockapetris [Page 35]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r 4. Information present outside of the authoritative nodes in the
\r zone should be glue information, rather than the result of an
\r origin or similar error.
\r\r5.3. Master file example
\r\rThe following is an example file which might be used to define the
\rISI.EDU zone.and is loaded with an origin of ISI.EDU:
\r\r@ IN SOA VENERA Action\.domains (
\r 20 ; SERIAL
\r 7200 ; REFRESH
\r 600 ; RETRY
\r 3600000; EXPIRE
\r 60) ; MINIMUM
\r\r NS A.ISI.EDU.
\r NS VENERA
\r NS VAXA
\r MX 10 VENERA
\r MX 20 VAXA
\r\rA A 26.3.0.103
\r\rVENERA A 10.1.0.52
\r A 128.9.0.32
\r\rVAXA A 10.2.0.27
\r A 128.9.0.33
\r\r\r$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
\r\rWhere the file <SUBSYS>ISI-MAILBOXES.TXT is:
\r\r MOE MB A.ISI.EDU.
\r LARRY MB A.ISI.EDU.
\r CURLEY MB A.ISI.EDU.
\r STOOGES MG MOE
\r MG LARRY
\r MG CURLEY
\r\rNote the use of the \ character in the SOA RR to specify the responsible
\rperson mailbox "Action.domains@E.ISI.EDU".
\r\r\r\r\r\r\r\rMockapetris [Page 36]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r6. NAME SERVER IMPLEMENTATION
\r\r6.1. Architecture
\r\rThe optimal structure for the name server will depend on the host
\roperating system and whether the name server is integrated with resolver
\roperations, either by supporting recursive service, or by sharing its
\rdatabase with a resolver. This section discusses implementation
\rconsiderations for a name server which shares a database with a
\rresolver, but most of these concerns are present in any name server.
\r\r6.1.1. Control
\r\rA name server must employ multiple concurrent activities, whether they
\rare implemented as separate tasks in the host's OS or multiplexing
\rinside a single name server program. It is simply not acceptable for a
\rname server to block the service of UDP requests while it waits for TCP
\rdata for refreshing or query activities. Similarly, a name server
\rshould not attempt to provide recursive service without processing such
\rrequests in parallel, though it may choose to serialize requests from a
\rsingle client, or to regard identical requests from the same client as
\rduplicates. A name server should not substantially delay requests while
\rit reloads a zone from master files or while it incorporates a newly
\rrefreshed zone into its database.
\r\r6.1.2. Database
\r\rWhile name server implementations are free to use any internal data
\rstructures they choose, the suggested structure consists of three major
\rparts:
\r\r - A "catalog" data structure which lists the zones available to
\r this server, and a "pointer" to the zone data structure. The
\r main purpose of this structure is to find the nearest ancestor
\r zone, if any, for arriving standard queries.
\r\r - Separate data structures for each of the zones held by the
\r name server.
\r\r - A data structure for cached data. (or perhaps separate caches
\r for different classes)
\r\rAll of these data structures can be implemented an identical tree
\rstructure format, with different data chained off the nodes in different
\rparts: in the catalog the data is pointers to zones, while in the zone
\rand cache data structures, the data will be RRs. In designing the tree
\rframework the designer should recognize that query processing will need
\rto traverse the tree using case-insensitive label comparisons; and that
\r\r\r\rMockapetris [Page 37]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rin real data, a few nodes have a very high branching factor (100-1000 or
\rmore), but the vast majority have a very low branching factor (0-1).
\r\rOne way to solve the case problem is to store the labels for each node
\rin two pieces: a standardized-case representation of the label where all
\rASCII characters are in a single case, together with a bit mask that
\rdenotes which characters are actually of a different case. The
\rbranching factor diversity can be handled using a simple linked list for
\ra node until the branching factor exceeds some threshold, and
\rtransitioning to a hash structure after the threshold is exceeded. In
\rany case, hash structures used to store tree sections must insure that
\rhash functions and procedures preserve the casing conventions of the
\rDNS.
\r\rThe use of separate structures for the different parts of the database
\ris motivated by several factors:
\r\r - The catalog structure can be an almost static structure that
\r need change only when the system administrator changes the
\r zones supported by the server. This structure can also be
\r used to store parameters used to control refreshing
\r activities.
\r\r - The individual data structures for zones allow a zone to be
\r replaced simply by changing a pointer in the catalog. Zone
\r refresh operations can build a new structure and, when
\r complete, splice it into the database via a simple pointer
\r replacement. It is very important that when a zone is
\r refreshed, queries should not use old and new data
\r simultaneously.
\r\r - With the proper search procedures, authoritative data in zones
\r will always "hide", and hence take precedence over, cached
\r data.
\r\r - Errors in zone definitions that cause overlapping zones, etc.,
\r may cause erroneous responses to queries, but problem
\r determination is simplified, and the contents of one "bad"
\r zone can't corrupt another.
\r\r - Since the cache is most frequently updated, it is most
\r vulnerable to corruption during system restarts. It can also
\r become full of expired RR data. In either case, it can easily
\r be discarded without disturbing zone data.
\r\rA major aspect of database design is selecting a structure which allows
\rthe name server to deal with crashes of the name server's host. State
\rinformation which a name server should save across system crashes
\r\r\r\rMockapetris [Page 38]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rincludes the catalog structure (including the state of refreshing for
\reach zone) and the zone data itself.
\r\r6.1.3. Time
\r\rBoth the TTL data for RRs and the timing data for refreshing activities
\rdepends on 32 bit timers in units of seconds. Inside the database,
\rrefresh timers and TTLs for cached data conceptually "count down", while
\rdata in the zone stays with constant TTLs.
\r\rA recommended implementation strategy is to store time in two ways: as
\ra relative increment and as an absolute time. One way to do this is to
\ruse positive 32 bit numbers for one type and negative numbers for the
\rother. The RRs in zones use relative times; the refresh timers and
\rcache data use absolute times. Absolute numbers are taken with respect
\rto some known origin and converted to relative values when placed in the
\rresponse to a query. When an absolute TTL is negative after conversion
\rto relative, then the data is expired and should be ignored.
\r\r6.2. Standard query processing
\r\rThe major algorithm for standard query processing is presented in
\r[RFC-1034].
\r\rWhen processing queries with QCLASS=*, or some other QCLASS which
\rmatches multiple classes, the response should never be authoritative
\runless the server can guarantee that the response covers all classes.
\r\rWhen composing a response, RRs which are to be inserted in the
\radditional section, but duplicate RRs in the answer or authority
\rsections, may be omitted from the additional section.
\r\rWhen a response is so long that truncation is required, the truncation
\rshould start at the end of the response and work forward in the
\rdatagram. Thus if there is any data for the authority section, the
\ranswer section is guaranteed to be unique.
\r\rThe MINIMUM value in the SOA should be used to set a floor on the TTL of
\rdata distributed from a zone. This floor function should be done when
\rthe data is copied into a response. This will allow future dynamic
\rupdate protocols to change the SOA MINIMUM field without ambiguous
\rsemantics.
\r\r6.3. Zone refresh and reload processing
\r\rIn spite of a server's best efforts, it may be unable to load zone data
\rfrom a master file due to syntax errors, etc., or be unable to refresh a
\rzone within the its expiration parameter. In this case, the name server
\r\r\r\rMockapetris [Page 39]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rshould answer queries as if it were not supposed to possess the zone.
\r\rIf a master is sending a zone out via AXFR, and a new version is created
\rduring the transfer, the master should continue to send the old version
\rif possible. In any case, it should never send part of one version and
\rpart of another. If completion is not possible, the master should reset
\rthe connection on which the zone transfer is taking place.
\r\r6.4. Inverse queries (Optional)
\r\rInverse queries are an optional part of the DNS. Name servers are not
\rrequired to support any form of inverse queries. If a name server
\rreceives an inverse query that it does not support, it returns an error
\rresponse with the "Not Implemented" error set in the header. While
\rinverse query support is optional, all name servers must be at least
\rable to return the error response.
\r\r6.4.1. The contents of inverse queries and responses Inverse
\rqueries reverse the mappings performed by standard query operations;
\rwhile a standard query maps a domain name to a resource, an inverse
\rquery maps a resource to a domain name. For example, a standard query
\rmight bind a domain name to a host address; the corresponding inverse
\rquery binds the host address to a domain name.
\r\rInverse queries take the form of a single RR in the answer section of
\rthe message, with an empty question section. The owner name of the
\rquery RR and its TTL are not significant. The response carries
\rquestions in the question section which identify all names possessing
\rthe query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
\rabout all of the domain name space, the response can never be assumed to
\rbe complete. Thus inverse queries are primarily useful for database
\rmanagement and debugging activities. Inverse queries are NOT an
\racceptable method of mapping host addresses to host names; use the IN-
\rADDR.ARPA domain instead.
\r\rWhere possible, name servers should provide case-insensitive comparisons
\rfor inverse queries. Thus an inverse query asking for an MX RR of
\r"Venera.isi.edu" should get the same response as a query for
\r"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
\rproduce the same result as an inverse query for "IBM-pc unix". However,
\rthis cannot be guaranteed because name servers may possess RRs that
\rcontain character strings but the name server does not know that the
\rdata is character.
\r\rWhen a name server processes an inverse query, it either returns:
\r\r 1. zero, one, or multiple domain names for the specified
\r resource as QNAMEs in the question section
\r\r\r\rMockapetris [Page 40]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r 2. an error code indicating that the name server doesn't support
\r inverse mapping of the specified resource type.
\r\rWhen the response to an inverse query contains one or more QNAMEs, the
\rowner name and TTL of the RR in the answer section which defines the
\rinverse query is modified to exactly match an RR found at the first
\rQNAME.
\r\rRRs returned in the inverse queries cannot be cached using the same
\rmechanism as is used for the replies to standard queries. One reason
\rfor this is that a name might have multiple RRs of the same type, and
\ronly one would appear. For example, an inverse query for a single
\raddress of a multiply homed host might create the impression that only
\rone address existed.
\r\r6.4.2. Inverse query and response example The overall structure
\rof an inverse query for retrieving the domain name that corresponds to
\rInternet address 10.1.0.52 is shown below:
\r\r +-----------------------------------------+
\r Header | OPCODE=IQUERY, ID=997 |
\r +-----------------------------------------+
\r Question | <empty> |
\r +-----------------------------------------+
\r Answer | <anyname> A IN 10.1.0.52 |
\r +-----------------------------------------+
\r Authority | <empty> |
\r +-----------------------------------------+
\r Additional | <empty> |
\r +-----------------------------------------+
\r\rThis query asks for a question whose answer is the Internet style
\raddress 10.1.0.52. Since the owner name is not known, any domain name
\rcan be used as a placeholder (and is ignored). A single octet of zero,
\rsignifying the root, is usually used because it minimizes the length of
\rthe message. The TTL of the RR is not significant. The response to
\rthis query might be:
\r\r\r\r\r\r\r\r\r\r\r\r\r\r\rMockapetris [Page 41]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r +-----------------------------------------+
\r Header | OPCODE=RESPONSE, ID=997 |
\r +-----------------------------------------+
\r Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
\r +-----------------------------------------+
\r Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
\r +-----------------------------------------+
\r Authority | <empty> |
\r +-----------------------------------------+
\r Additional | <empty> |
\r +-----------------------------------------+
\r\rNote that the QTYPE in a response to an inverse query is the same as the
\rTYPE field in the answer section of the inverse query. Responses to
\rinverse queries may contain multiple questions when the inverse is not
\runique. If the question section in the response is not empty, then the
\rRR in the answer section is modified to correspond to be an exact copy
\rof an RR at the first QNAME.
\r\r6.4.3. Inverse query processing
\r\rName servers that support inverse queries can support these operations
\rthrough exhaustive searches of their databases, but this becomes
\rimpractical as the size of the database increases. An alternative
\rapproach is to invert the database according to the search key.
\r\rFor name servers that support multiple zones and a large amount of data,
\rthe recommended approach is separate inversions for each zone. When a
\rparticular zone is changed during a refresh, only its inversions need to
\rbe redone.
\r\rSupport for transfer of this type of inversion may be included in future
\rversions of the domain system, but is not supported in this version.
\r\r6.5. Completion queries and responses
\r\rThe optional completion services described in RFC-882 and RFC-883 have
\rbeen deleted. Redesigned services may become available in the future.
\r\r\r\r\r\r\r\r\r\r\r\r\r\rMockapetris [Page 42]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r7. RESOLVER IMPLEMENTATION
\r\rThe top levels of the recommended resolver algorithm are discussed in
\r[RFC-1034]. This section discusses implementation details assuming the
\rdatabase structure suggested in the name server implementation section
\rof this memo.
\r\r7.1. Transforming a user request into a query
\r\rThe first step a resolver takes is to transform the client's request,
\rstated in a format suitable to the local OS, into a search specification
\rfor RRs at a specific name which match a specific QTYPE and QCLASS.
\rWhere possible, the QTYPE and QCLASS should correspond to a single type
\rand a single class, because this makes the use of cached data much
\rsimpler. The reason for this is that the presence of data of one type
\rin a cache doesn't confirm the existence or non-existence of data of
\rother types, hence the only way to be sure is to consult an
\rauthoritative source. If QCLASS=* is used, then authoritative answers
\rwon't be available.
\r\rSince a resolver must be able to multiplex multiple requests if it is to
\rperform its function efficiently, each pending request is usually
\rrepresented in some block of state information. This state block will
\rtypically contain:
\r\r - A timestamp indicating the time the request began.
\r The timestamp is used to decide whether RRs in the database
\r can be used or are out of date. This timestamp uses the
\r absolute time format previously discussed for RR storage in
\r zones and caches. Note that when an RRs TTL indicates a
\r relative time, the RR must be timely, since it is part of a
\r zone. When the RR has an absolute time, it is part of a
\r cache, and the TTL of the RR is compared against the timestamp
\r for the start of the request.
\r\r Note that using the timestamp is superior to using a current
\r time, since it allows RRs with TTLs of zero to be entered in
\r the cache in the usual manner, but still used by the current
\r request, even after intervals of many seconds due to system
\r load, query retransmission timeouts, etc.
\r\r - Some sort of parameters to limit the amount of work which will
\r be performed for this request.
\r\r The amount of work which a resolver will do in response to a
\r client request must be limited to guard against errors in the
\r database, such as circular CNAME references, and operational
\r problems, such as network partition which prevents the
\r\r\r\rMockapetris [Page 43]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r resolver from accessing the name servers it needs. While
\r local limits on the number of times a resolver will retransmit
\r a particular query to a particular name server address are
\r essential, the resolver should have a global per-request
\r counter to limit work on a single request. The counter should
\r be set to some initial value and decremented whenever the
\r resolver performs any action (retransmission timeout,
\r retransmission, etc.) If the counter passes zero, the request
\r is terminated with a temporary error.
\r\r Note that if the resolver structure allows one request to
\r start others in parallel, such as when the need to access a
\r name server for one request causes a parallel resolve for the
\r name server's addresses, the spawned request should be started
\r with a lower counter. This prevents circular references in
\r the database from starting a chain reaction of resolver
\r activity.
\r\r - The SLIST data structure discussed in [RFC-1034].
\r\r This structure keeps track of the state of a request if it
\r must wait for answers from foreign name servers.
\r\r7.2. Sending the queries
\r\rAs described in [RFC-1034], the basic task of the resolver is to
\rformulate a query which will answer the client's request and direct that
\rquery to name servers which can provide the information. The resolver
\rwill usually only have very strong hints about which servers to ask, in
\rthe form of NS RRs, and may have to revise the query, in response to
\rCNAMEs, or revise the set of name servers the resolver is asking, in
\rresponse to delegation responses which point the resolver to name
\rservers closer to the desired information. In addition to the
\rinformation requested by the client, the resolver may have to call upon
\rits own services to determine the address of name servers it wishes to
\rcontact.
\r\rIn any case, the model used in this memo assumes that the resolver is
\rmultiplexing attention between multiple requests, some from the client,
\rand some internally generated. Each request is represented by some
\rstate information, and the desired behavior is that the resolver
\rtransmit queries to name servers in a way that maximizes the probability
\rthat the request is answered, minimizes the time that the request takes,
\rand avoids excessive transmissions. The key algorithm uses the state
\rinformation of the request to select the next name server address to
\rquery, and also computes a timeout which will cause the next action
\rshould a response not arrive. The next action will usually be a
\rtransmission to some other server, but may be a temporary error to the
\r\r\r\rMockapetris [Page 44]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rclient.
\r\rThe resolver always starts with a list of server names to query (SLIST).
\rThis list will be all NS RRs which correspond to the nearest ancestor
\rzone that the resolver knows about. To avoid startup problems, the
\rresolver should have a set of default servers which it will ask should
\rit have no current NS RRs which are appropriate. The resolver then adds
\rto SLIST all of the known addresses for the name servers, and may start
\rparallel requests to acquire the addresses of the servers when the
\rresolver has the name, but no addresses, for the name servers.
\r\rTo complete initialization of SLIST, the resolver attaches whatever
\rhistory information it has to the each address in SLIST. This will
\rusually consist of some sort of weighted averages for the response time
\rof the address, and the batting average of the address (i.e., how often
\rthe address responded at all to the request). Note that this
\rinformation should be kept on a per address basis, rather than on a per
\rname server basis, because the response time and batting average of a
\rparticular server may vary considerably from address to address. Note
\ralso that this information is actually specific to a resolver address /
\rserver address pair, so a resolver with multiple addresses may wish to
\rkeep separate histories for each of its addresses. Part of this step
\rmust deal with addresses which have no such history; in this case an
\rexpected round trip time of 5-10 seconds should be the worst case, with
\rlower estimates for the same local network, etc.
\r\rNote that whenever a delegation is followed, the resolver algorithm
\rreinitializes SLIST.
\r\rThe information establishes a partial ranking of the available name
\rserver addresses. Each time an address is chosen and the state should
\rbe altered to prevent its selection again until all other addresses have
\rbeen tried. The timeout for each transmission should be 50-100% greater
\rthan the average predicted value to allow for variance in response.
\r\rSome fine points:
\r\r - The resolver may encounter a situation where no addresses are
\r available for any of the name servers named in SLIST, and
\r where the servers in the list are precisely those which would
\r normally be used to look up their own addresses. This
\r situation typically occurs when the glue address RRs have a
\r smaller TTL than the NS RRs marking delegation, or when the
\r resolver caches the result of a NS search. The resolver
\r should detect this condition and restart the search at the
\r next ancestor zone, or alternatively at the root.
\r\r\r\r\r\rMockapetris [Page 45]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r - If a resolver gets a server error or other bizarre response
\r from a name server, it should remove it from SLIST, and may
\r wish to schedule an immediate transmission to the next
\r candidate server address.
\r\r7.3. Processing responses
\r\rThe first step in processing arriving response datagrams is to parse the
\rresponse. This procedure should include:
\r\r - Check the header for reasonableness. Discard datagrams which
\r are queries when responses are expected.
\r\r - Parse the sections of the message, and insure that all RRs are
\r correctly formatted.
\r\r - As an optional step, check the TTLs of arriving data looking
\r for RRs with excessively long TTLs. If a RR has an
\r excessively long TTL, say greater than 1 week, either discard
\r the whole response, or limit all TTLs in the response to 1
\r week.
\r\rThe next step is to match the response to a current resolver request.
\rThe recommended strategy is to do a preliminary matching using the ID
\rfield in the domain header, and then to verify that the question section
\rcorresponds to the information currently desired. This requires that
\rthe transmission algorithm devote several bits of the domain ID field to
\ra request identifier of some sort. This step has several fine points:
\r\r - Some name servers send their responses from different
\r addresses than the one used to receive the query. That is, a
\r resolver cannot rely that a response will come from the same
\r address which it sent the corresponding query to. This name
\r server bug is typically encountered in UNIX systems.
\r\r - If the resolver retransmits a particular request to a name
\r server it should be able to use a response from any of the
\r transmissions. However, if it is using the response to sample
\r the round trip time to access the name server, it must be able
\r to determine which transmission matches the response (and keep
\r transmission times for each outgoing message), or only
\r calculate round trip times based on initial transmissions.
\r\r - A name server will occasionally not have a current copy of a
\r zone which it should have according to some NS RRs. The
\r resolver should simply remove the name server from the current
\r SLIST, and continue.
\r\r\r\r\rMockapetris [Page 46]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r7.4. Using the cache
\r\rIn general, we expect a resolver to cache all data which it receives in
\rresponses since it may be useful in answering future client requests.
\rHowever, there are several types of data which should not be cached:
\r\r - When several RRs of the same type are available for a
\r particular owner name, the resolver should either cache them
\r all or none at all. When a response is truncated, and a
\r resolver doesn't know whether it has a complete set, it should
\r not cache a possibly partial set of RRs.
\r\r - Cached data should never be used in preference to
\r authoritative data, so if caching would cause this to happen
\r the data should not be cached.
\r\r - The results of an inverse query should not be cached.
\r\r - The results of standard queries where the QNAME contains "*"
\r labels if the data might be used to construct wildcards. The
\r reason is that the cache does not necessarily contain existing
\r RRs or zone boundary information which is necessary to
\r restrict the application of the wildcard RRs.
\r\r - RR data in responses of dubious reliability. When a resolver
\r receives unsolicited responses or RR data other than that
\r requested, it should discard it without caching it. The basic
\r implication is that all sanity checks on a packet should be
\r performed before any of it is cached.
\r\rIn a similar vein, when a resolver has a set of RRs for some name in a
\rresponse, and wants to cache the RRs, it should check its cache for
\ralready existing RRs. Depending on the circumstances, either the data
\rin the response or the cache is preferred, but the two should never be
\rcombined. If the data in the response is from authoritative data in the
\ranswer section, it is always preferred.
\r\r8. MAIL SUPPORT
\r\rThe domain system defines a standard for mapping mailboxes into domain
\rnames, and two methods for using the mailbox information to derive mail
\rrouting information. The first method is called mail exchange binding
\rand the other method is mailbox binding. The mailbox encoding standard
\rand mail exchange binding are part of the DNS official protocol, and are
\rthe recommended method for mail routing in the Internet. Mailbox
\rbinding is an experimental feature which is still under development and
\rsubject to change.
\r\r\r\r\rMockapetris [Page 47]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rThe mailbox encoding standard assumes a mailbox name of the form
\r"<local-part>@<mail-domain>". While the syntax allowed in each of these
\rsections varies substantially between the various mail internets, the
\rpreferred syntax for the ARPA Internet is given in [RFC-822].
\r\rThe DNS encodes the <local-part> as a single label, and encodes the
\r<mail-domain> as a domain name. The single label from the <local-part>
\ris prefaced to the domain name from <mail-domain> to form the domain
\rname corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
\rNIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
\r<local-part> contains dots or other special characters, its
\rrepresentation in a master file will require the use of backslash
\rquoting to ensure that the domain name is properly encoded. For
\rexample, the mailbox Action.domains@ISI.EDU would be represented as
\rAction\.domains.ISI.EDU.
\r\r8.1. Mail exchange binding
\r\rMail exchange binding uses the <mail-domain> part of a mailbox
\rspecification to determine where mail should be sent. The <local-part>
\ris not even consulted. [RFC-974] specifies this method in detail, and
\rshould be consulted before attempting to use mail exchange support.
\r\rOne of the advantages of this method is that it decouples mail
\rdestination naming from the hosts used to support mail service, at the
\rcost of another layer of indirection in the lookup function. However,
\rthe addition layer should eliminate the need for complicated "%", "!",
\retc encodings in <local-part>.
\r\rThe essence of the method is that the <mail-domain> is used as a domain
\rname to locate type MX RRs which list hosts willing to accept mail for
\r<mail-domain>, together with preference values which rank the hosts
\raccording to an order specified by the administrators for <mail-domain>.
\r\rIn this memo, the <mail-domain> ISI.EDU is used in examples, together
\rwith the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
\rISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
\rroute it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
\rVENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
\raddresses.
\r\r8.2. Mailbox binding (Experimental)
\r\rIn mailbox binding, the mailer uses the entire mail destination
\rspecification to construct a domain name. The encoded domain name for
\rthe mailbox is used as the QNAME field in a QTYPE=MAILB query.
\r\rSeveral outcomes are possible for this query:
\r\r\r\rMockapetris [Page 48]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r 1. The query can return a name error indicating that the mailbox
\r does not exist as a domain name.
\r\r In the long term, this would indicate that the specified
\r mailbox doesn't exist. However, until the use of mailbox
\r binding is universal, this error condition should be
\r interpreted to mean that the organization identified by the
\r global part does not support mailbox binding. The
\r appropriate procedure is to revert to exchange binding at
\r this point.
\r\r 2. The query can return a Mail Rename (MR) RR.
\r\r The MR RR carries new mailbox specification in its RDATA
\r field. The mailer should replace the old mailbox with the
\r new one and retry the operation.
\r\r 3. The query can return a MB RR.
\r\r The MB RR carries a domain name for a host in its RDATA
\r field. The mailer should deliver the message to that host
\r via whatever protocol is applicable, e.g., b,SMTP.
\r\r 4. The query can return one or more Mail Group (MG) RRs.
\r\r This condition means that the mailbox was actually a mailing
\r list or mail group, rather than a single mailbox. Each MG RR
\r has a RDATA field that identifies a mailbox that is a member
\r of the group. The mailer should deliver a copy of the
\r message to each member.
\r\r 5. The query can return a MB RR as well as one or more MG RRs.
\r\r This condition means the the mailbox was actually a mailing
\r list. The mailer can either deliver the message to the host
\r specified by the MB RR, which will in turn do the delivery to
\r all members, or the mailer can use the MG RRs to do the
\r expansion itself.
\r\rIn any of these cases, the response may include a Mail Information
\r(MINFO) RR. This RR is usually associated with a mail group, but is
\rlegal with a MB. The MINFO RR identifies two mailboxes. One of these
\ridentifies a responsible person for the original mailbox name. This
\rmailbox should be used for requests to be added to a mail group, etc.
\rThe second mailbox name in the MINFO RR identifies a mailbox that should
\rreceive error messages for mail failures. This is particularly
\rappropriate for mailing lists when errors in member names should be
\rreported to a person other than the one who sends a message to the list.
\r\r\r\rMockapetris [Page 49]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rNew fields may be added to this RR in the future.
\r\r\r9. REFERENCES and BIBLIOGRAPHY
\r\r[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
\r Technical Plan - Name Service, April 1987, version 1.9.
\r\r Describes the fundamentals of the Hesiod name service.
\r\r[IEN-116] J. Postel, "Internet Name Server", IEN-116,
\r USC/Information Sciences Institute, August 1979.
\r\r A name service obsoleted by the Domain Name System, but
\r still in use.
\r\r[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
\r Communications of the ACM, October 1986, volume 29, number
\r 10.
\r\r[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
\r Information Center, SRI International, December 1977.
\r\r[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
\r USC/Information Sciences Institute, August 1980.
\r\r[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
\r USC/Information Sciences Institute, September 1981.
\r\r[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
\r September 1981.
\r\r Suggests introduction of a hierarchy in place of a flat
\r name space for the Internet.
\r\r[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
\r USC/Information Sciences Institute, February 1982.
\r\r[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
\r Internet Host Table Specification", RFC-810, Network
\r Information Center, SRI International, March 1982.
\r\r Obsolete. See RFC-952.
\r\r[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
\r Server", RFC-811, Network Information Center, SRI
\r International, March 1982.
\r\r\r\r\rMockapetris [Page 50]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r Obsolete. See RFC-953.
\r\r[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
\r Network Information Center, SRI International, March
\r 1982.
\r\r[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
\r Internet User Applications", RFC-819, Network
\r Information Center, SRI International, August 1982.
\r\r Early thoughts on the design of the domain system.
\r Current implementation is completely different.
\r\r[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
\r USC/Information Sciences Institute, August 1980.
\r\r[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
\r RFC-830, Network Information Center, SRI International,
\r October 1982.
\r\r Early thoughts on the design of the domain system.
\r Current implementation is completely different.
\r\r[RFC-882] P. Mockapetris, "Domain names - Concepts and
\r Facilities," RFC-882, USC/Information Sciences
\r Institute, November 1983.
\r\r Superceeded by this memo.
\r\r[RFC-883] P. Mockapetris, "Domain names - Implementation and
\r Specification," RFC-883, USC/Information Sciences
\r Institute, November 1983.
\r\r Superceeded by this memo.
\r\r[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
\r RFC-920, USC/Information Sciences Institute,
\r October 1984.
\r\r Explains the naming scheme for top level domains.
\r\r[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
\r Table Specification", RFC-952, SRI, October 1985.
\r\r Specifies the format of HOSTS.TXT, the host/address
\r table replaced by the DNS.
\r\r\r\r\r\rMockapetris [Page 51]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
\r RFC-953, SRI, October 1985.
\r\r This RFC contains the official specification of the
\r hostname server protocol, which is obsoleted by the DNS.
\r This TCP based protocol accesses information stored in
\r the RFC-952 format, and is used to obtain copies of the
\r host table.
\r\r[RFC-973] P. Mockapetris, "Domain System Changes and
\r Observations", RFC-973, USC/Information Sciences
\r Institute, January 1986.
\r\r Describes changes to RFC-882 and RFC-883 and reasons for
\r them.
\r\r[RFC-974] C. Partridge, "Mail routing and the domain system",
\r RFC-974, CSNET CIC BBN Labs, January 1986.
\r\r Describes the transition from HOSTS.TXT based mail
\r addressing to the more powerful MX system used with the
\r domain system.
\r\r[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
\r service on a TCP/UDP transport: Concepts and Methods",
\r RFC-1001, March 1987.
\r\r This RFC and RFC-1002 are a preliminary design for
\r NETBIOS on top of TCP/IP which proposes to base NetBIOS
\r name service on top of the DNS.
\r\r[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
\r service on a TCP/UDP transport: Detailed
\r Specifications", RFC-1002, March 1987.
\r\r[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
\r USC/Information Sciences Institute, May 1987.
\r\r Contains socket numbers and mnemonics for host names,
\r operating systems, etc.
\r\r[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
\r November 1987.
\r\r Describes a plan for converting the MILNET to the DNS.
\r\r[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
\r Administrators", RFC-1032, November 1987.
\r\r\r\rMockapetris [Page 52]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r Describes the registration policies used by the NIC to
\r administer the top level domains and delegate subzones.
\r\r[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
\r RFC-1033, November 1987.
\r\r A cookbook for domain administrators.
\r\r[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
\r Name Server", Computer Networks, vol 6, nr 3, July 1982.
\r\r Describes a name service for CSNET which is independent
\r from the DNS and DNS use in the CSNET.
\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\rMockapetris [Page 53]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\rIndex
\r\r * 13
\r\r ; 33, 35
\r\r <character-string> 35
\r <domain-name> 34
\r\r @ 35
\r\r \ 35
\r\r A 12
\r\r Byte order 8
\r\r CH 13
\r Character case 9
\r CLASS 11
\r CNAME 12
\r Completion 42
\r CS 13
\r\r Hesiod 13
\r HINFO 12
\r HS 13
\r\r IN 13
\r IN-ADDR.ARPA domain 22
\r Inverse queries 40
\r\r Mailbox names 47
\r MB 12
\r MD 12
\r MF 12
\r MG 12
\r MINFO 12
\r MINIMUM 20
\r MR 12
\r MX 12
\r\r NS 12
\r NULL 12
\r\r Port numbers 32
\r Primary server 5
\r PTR 12, 18
\r\r\r\rMockapetris [Page 54]
\r\f\rRFC 1035 Domain Implementation and Specification November 1987
\r\r\r QCLASS 13
\r QTYPE 12
\r\r RDATA 12
\r RDLENGTH 11
\r\r Secondary server 5
\r SOA 12
\r Stub resolvers 7
\r\r TCP 32
\r TXT 12
\r TYPE 11
\r\r UDP 32
\r\r WKS 12
\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\r\rMockapetris [Page 55]
\r\f\r\ No newline at end of file
+Network Working Group P. Mockapetris
+Request for Comments: 1035 ISI
+ November 1987
+Obsoletes: RFCs 882, 883, 973
+
+ DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+
+
+1. STATUS OF THIS MEMO
+
+This RFC describes the details of the domain system and protocol, and
+assumes that the reader is familiar with the concepts discussed in a
+companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
+
+The domain system is a mixture of functions and data types which are an
+official protocol and functions and data types which are still
+experimental. Since the domain system is intentionally extensible, new
+data types and experimental behavior should always be expected in parts
+of the system beyond the official protocol. The official protocol parts
+include standard queries, responses and the Internet class RR data
+formats (e.g., host addresses). Since the previous RFC set, several
+definitions have changed, so some previous definitions are obsolete.
+
+Experimental or obsolete features are clearly marked in these RFCs, and
+such information should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical. Distribution of this memo is unlimited.
+
+ Table of Contents
+
+ 1. STATUS OF THIS MEMO 1
+ 2. INTRODUCTION 3
+ 2.1. Overview 3
+ 2.2. Common configurations 4
+ 2.3. Conventions 7
+ 2.3.1. Preferred name syntax 7
+ 2.3.2. Data Transmission Order 8
+ 2.3.3. Character Case 9
+ 2.3.4. Size limits 10
+ 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
+ 3.1. Name space definitions 10
+ 3.2. RR definitions 11
+ 3.2.1. Format 11
+ 3.2.2. TYPE values 12
+ 3.2.3. QTYPE values 12
+ 3.2.4. CLASS values 13
+
+
+
+Mockapetris [Page 1]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ 3.2.5. QCLASS values 13
+ 3.3. Standard RRs 13
+ 3.3.1. CNAME RDATA format 14
+ 3.3.2. HINFO RDATA format 14
+ 3.3.3. MB RDATA format (EXPERIMENTAL) 14
+ 3.3.4. MD RDATA format (Obsolete) 15
+ 3.3.5. MF RDATA format (Obsolete) 15
+ 3.3.6. MG RDATA format (EXPERIMENTAL) 16
+ 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
+ 3.3.8. MR RDATA format (EXPERIMENTAL) 17
+ 3.3.9. MX RDATA format 17
+ 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
+ 3.3.11. NS RDATA format 18
+ 3.3.12. PTR RDATA format 18
+ 3.3.13. SOA RDATA format 19
+ 3.3.14. TXT RDATA format 20
+ 3.4. ARPA Internet specific RRs 20
+ 3.4.1. A RDATA format 20
+ 3.4.2. WKS RDATA format 21
+ 3.5. IN-ADDR.ARPA domain 22
+ 3.6. Defining new types, classes, and special namespaces 24
+ 4. MESSAGES 25
+ 4.1. Format 25
+ 4.1.1. Header section format 26
+ 4.1.2. Question section format 28
+ 4.1.3. Resource record format 29
+ 4.1.4. Message compression 30
+ 4.2. Transport 32
+ 4.2.1. UDP usage 32
+ 4.2.2. TCP usage 32
+ 5. MASTER FILES 33
+ 5.1. Format 33
+ 5.2. Use of master files to define zones 35
+ 5.3. Master file example 36
+ 6. NAME SERVER IMPLEMENTATION 37
+ 6.1. Architecture 37
+ 6.1.1. Control 37
+ 6.1.2. Database 37
+ 6.1.3. Time 39
+ 6.2. Standard query processing 39
+ 6.3. Zone refresh and reload processing 39
+ 6.4. Inverse queries (Optional) 40
+ 6.4.1. The contents of inverse queries and responses 40
+ 6.4.2. Inverse query and response example 41
+ 6.4.3. Inverse query processing 42
+
+
+
+
+
+
+Mockapetris [Page 2]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ 6.5. Completion queries and responses 42
+ 7. RESOLVER IMPLEMENTATION 43
+ 7.1. Transforming a user request into a query 43
+ 7.2. Sending the queries 44
+ 7.3. Processing responses 46
+ 7.4. Using the cache 47
+ 8. MAIL SUPPORT 47
+ 8.1. Mail exchange binding 48
+ 8.2. Mailbox binding (Experimental) 48
+ 9. REFERENCES and BIBLIOGRAPHY 50
+ Index 54
+
+2. INTRODUCTION
+
+2.1. Overview
+
+The goal of domain names is to provide a mechanism for naming resources
+in such a way that the names are usable in different hosts, networks,
+protocol families, internets, and administrative organizations.
+
+From the user's point of view, domain names are useful as arguments to a
+local agent, called a resolver, which retrieves information associated
+with the domain name. Thus a user might ask for the host address or
+mail information associated with a particular domain name. To enable
+the user to request a particular type of information, an appropriate
+query type is passed to the resolver with the domain name. To the user,
+the domain tree is a single information space; the resolver is
+responsible for hiding the distribution of data among name servers from
+the user.
+
+From the resolver's point of view, the database that makes up the domain
+space is distributed among various name servers. Different parts of the
+domain space are stored in different name servers, although a particular
+data item will be stored redundantly in two or more name servers. The
+resolver starts with knowledge of at least one name server. When the
+resolver processes a user query it asks a known name server for the
+information; in return, the resolver either receives the desired
+information or a referral to another name server. Using these
+referrals, resolvers learn the identities and contents of other name
+servers. Resolvers are responsible for dealing with the distribution of
+the domain space and dealing with the effects of name server failure by
+consulting redundant databases in other servers.
+
+Name servers manage two kinds of data. The first kind of data held in
+sets called zones; each zone is the complete database for a particular
+"pruned" subtree of the domain space. This data is called
+authoritative. A name server periodically checks to make sure that its
+zones are up to date, and if not, obtains a new copy of updated zones
+
+
+
+Mockapetris [Page 3]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+from master files stored locally or in another name server. The second
+kind of data is cached data which was acquired by a local resolver.
+This data may be incomplete, but improves the performance of the
+retrieval process when non-local data is repeatedly accessed. Cached
+data is eventually discarded by a timeout mechanism.
+
+This functional structure isolates the problems of user interface,
+failure recovery, and distribution in the resolvers and isolates the
+database update and refresh problems in the name servers.
+
+2.2. Common configurations
+
+A host can participate in the domain name system in a number of ways,
+depending on whether the host runs programs that retrieve information
+from the domain system, name servers that answer queries from other
+hosts, or various combinations of both functions. The simplest, and
+perhaps most typical, configuration is shown below:
+
+ Local Host | Foreign
+ |
+ +---------+ +----------+ | +--------+
+ | | user queries | |queries | | |
+ | User |-------------->| |---------|->|Foreign |
+ | Program | | Resolver | | | Name |
+ | |<--------------| |<--------|--| Server |
+ | | user responses| |responses| | |
+ +---------+ +----------+ | +--------+
+ | A |
+ cache additions | | references |
+ V | |
+ +----------+ |
+ | cache | |
+ +----------+ |
+
+User programs interact with the domain name space through resolvers; the
+format of user queries and user responses is specific to the host and
+its operating system. User queries will typically be operating system
+calls, and the resolver and its cache will be part of the host operating
+system. Less capable hosts may choose to implement the resolver as a
+subroutine to be linked in with every program that needs its services.
+Resolvers answer user queries with information they acquire via queries
+to foreign name servers and the local cache.
+
+Note that the resolver may have to make several queries to several
+different foreign name servers to answer a particular user query, and
+hence the resolution of a user query may involve several network
+accesses and an arbitrary amount of time. The queries to foreign name
+servers and the corresponding responses have a standard format described
+
+
+
+Mockapetris [Page 4]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+in this memo, and may be datagrams.
+
+Depending on its capabilities, a name server could be a stand alone
+program on a dedicated machine or a process or processes on a large
+timeshared host. A simple configuration might be:
+
+ Local Host | Foreign
+ |
+ +---------+ |
+ / /| |
+ +---------+ | +----------+ | +--------+
+ | | | | |responses| | |
+ | | | | Name |---------|->|Foreign |
+ | Master |-------------->| Server | | |Resolver|
+ | files | | | |<--------|--| |
+ | |/ | | queries | +--------+
+ +---------+ +----------+ |
+
+Here a primary name server acquires information about one or more zones
+by reading master files from its local file system, and answers queries
+about those zones that arrive from foreign resolvers.
+
+The DNS requires that all zones be redundantly supported by more than
+one name server. Designated secondary servers can acquire zones and
+check for updates from the primary server using the zone transfer
+protocol of the DNS. This configuration is shown below:
+
+ Local Host | Foreign
+ |
+ +---------+ |
+ / /| |
+ +---------+ | +----------+ | +--------+
+ | | | | |responses| | |
+ | | | | Name |---------|->|Foreign |
+ | Master |-------------->| Server | | |Resolver|
+ | files | | | |<--------|--| |
+ | |/ | | queries | +--------+
+ +---------+ +----------+ |
+ A |maintenance | +--------+
+ | +------------|->| |
+ | queries | |Foreign |
+ | | | Name |
+ +------------------|--| Server |
+ maintenance responses | +--------+
+
+In this configuration, the name server periodically establishes a
+virtual circuit to a foreign name server to acquire a copy of a zone or
+to check that an existing copy has not changed. The messages sent for
+
+
+
+Mockapetris [Page 5]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+these maintenance activities follow the same form as queries and
+responses, but the message sequences are somewhat different.
+
+The information flow in a host that supports all aspects of the domain
+name system is shown below:
+
+ Local Host | Foreign
+ |
+ +---------+ +----------+ | +--------+
+ | | user queries | |queries | | |
+ | User |-------------->| |---------|->|Foreign |
+ | Program | | Resolver | | | Name |
+ | |<--------------| |<--------|--| Server |
+ | | user responses| |responses| | |
+ +---------+ +----------+ | +--------+
+ | A |
+ cache additions | | references |
+ V | |
+ +----------+ |
+ | Shared | |
+ | database | |
+ +----------+ |
+ A | |
+ +---------+ refreshes | | references |
+ / /| | V |
+ +---------+ | +----------+ | +--------+
+ | | | | |responses| | |
+ | | | | Name |---------|->|Foreign |
+ | Master |-------------->| Server | | |Resolver|
+ | files | | | |<--------|--| |
+ | |/ | | queries | +--------+
+ +---------+ +----------+ |
+ A |maintenance | +--------+
+ | +------------|->| |
+ | queries | |Foreign |
+ | | | Name |
+ +------------------|--| Server |
+ maintenance responses | +--------+
+
+The shared database holds domain space data for the local name server
+and resolver. The contents of the shared database will typically be a
+mixture of authoritative data maintained by the periodic refresh
+operations of the name server and cached data from previous resolver
+requests. The structure of the domain data and the necessity for
+synchronization between name servers and resolvers imply the general
+characteristics of this database, but the actual format is up to the
+local implementor.
+
+
+
+
+Mockapetris [Page 6]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+Information flow can also be tailored so that a group of hosts act
+together to optimize activities. Sometimes this is done to offload less
+capable hosts so that they do not have to implement a full resolver.
+This can be appropriate for PCs or hosts which want to minimize the
+amount of new network code which is required. This scheme can also
+allow a group of hosts can share a small number of caches rather than
+maintaining a large number of separate caches, on the premise that the
+centralized caches will have a higher hit ratio. In either case,
+resolvers are replaced with stub resolvers which act as front ends to
+resolvers located in a recursive server in one or more name servers
+known to perform that service:
+
+ Local Hosts | Foreign
+ |
+ +---------+ |
+ | | responses |
+ | Stub |<--------------------+ |
+ | Resolver| | |
+ | |----------------+ | |
+ +---------+ recursive | | |
+ queries | | |
+ V | |
+ +---------+ recursive +----------+ | +--------+
+ | | queries | |queries | | |
+ | Stub |-------------->| Recursive|---------|->|Foreign |
+ | Resolver| | Server | | | Name |
+ | |<--------------| |<--------|--| Server |
+ +---------+ responses | |responses| | |
+ +----------+ | +--------+
+ | Central | |
+ | cache | |
+ +----------+ |
+
+In any case, note that domain components are always replicated for
+reliability whenever possible.
+
+2.3. Conventions
+
+The domain system has several conventions dealing with low-level, but
+fundamental, issues. While the implementor is free to violate these
+conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
+ALL behavior observed from other hosts.
+
+2.3.1. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+for constructing domain names. The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+
+
+
+Mockapetris [Page 7]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822. When creating a new host name,
+the old rules for HOSTS.TXT should be followed. This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case. That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names. They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen. There are also some
+restrictions on the length. Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
+
+2.3.2. Data Transmission Order
+
+The order of transmission of the header and data described in this
+document is resolved to the octet level. Whenever a diagram shows a
+
+
+
+Mockapetris [Page 8]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+group of octets, the order of transmission of those octets is the normal
+order in which they are read in English. For example, in the following
+diagram, the octets are transmitted in the order they are numbered.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 1 | 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 3 | 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 5 | 6 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Whenever an octet represents a numeric quantity, the left most bit in
+the diagram is the high order or most significant bit. That is, the bit
+labeled 0 is the most significant bit. For example, the following
+diagram represents the value 170 (decimal).
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ |1 0 1 0 1 0 1 0|
+ +-+-+-+-+-+-+-+-+
+
+Similarly, whenever a multi-octet field represents a numeric quantity
+the left most bit of the whole field is the most significant bit. When
+a multi-octet quantity is transmitted the most significant octet is
+transmitted first.
+
+2.3.3. Character Case
+
+For all parts of the DNS that are part of the official protocol, all
+comparisons between character strings (e.g., labels, domain names, etc.)
+are done in a case-insensitive manner. At present, this rule is in
+force throughout the domain system without exception. However, future
+additions beyond current usage may need to use the full binary octet
+capabilities in names, so attempts to store domain names in 7-bit ASCII
+or use of special bytes to terminate labels, etc., should be avoided.
+
+When data enters the domain system, its original case should be
+preserved whenever possible. In certain circumstances this cannot be
+done. For example, if two RRs are stored in a database, one at x.y and
+one at X.Y, they are actually stored at the same place in the database,
+and hence only one casing would be preserved. The basic rule is that
+case can be discarded only when data is used to define structure in a
+database, and two names are identical when compared in a case
+insensitive manner.
+
+
+
+
+Mockapetris [Page 9]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+Loss of case sensitive data must be minimized. Thus while data for x.y
+and X.Y may both be stored under a single location x.y or X.Y, data for
+a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
+general, this preserves the case of the first label of a domain name,
+but forces standardization of interior node labels.
+
+Systems administrators who enter data into the domain database should
+take care to represent the data they supply to the domain system in a
+case-consistent manner if their system is case-sensitive. The data
+distribution system in the domain system will ensure that consistent
+representations are preserved.
+
+2.3.4. Size limits
+
+Various objects and parameters in the DNS have size limits. They are
+listed below. Some could be easily changed, others are more
+fundamental.
+
+labels 63 octets or less
+
+names 255 octets or less
+
+TTL positive values of a signed 32 bit number.
+
+UDP messages 512 octets or less
+
+3. DOMAIN NAME SPACE AND RR DEFINITIONS
+
+3.1. Name space definitions
+
+Domain names in messages are expressed in terms of a sequence of labels.
+Each label is represented as a one octet length field followed by that
+number of octets. Since every domain name ends with the null label of
+the root, a domain name is terminated by a length byte of zero. The
+high order two bits of every length octet must be zero, and the
+remaining six bits of the length field limit the label to 63 octets or
+less.
+
+To simplify implementations, the total length of a domain name (i.e.,
+label octets and label length octets) is restricted to 255 octets or
+less.
+
+Although labels can contain any 8 bit values in octets that make up a
+label, it is strongly recommended that labels follow the preferred
+syntax described elsewhere in this memo, which is compatible with
+existing host naming conventions. Name servers and resolvers must
+compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
+with zero parity. Non-alphabetic codes must match exactly.
+
+
+
+Mockapetris [Page 10]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.2. RR definitions
+
+3.2.1. Format
+
+All RRs have the same top level format shown below:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / /
+ / NAME /
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TYPE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | CLASS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TTL |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | RDLENGTH |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+ / RDATA /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+where:
+
+NAME an owner name, i.e., the name of the node to which this
+ resource record pertains.
+
+TYPE two octets containing one of the RR TYPE codes.
+
+CLASS two octets containing one of the RR CLASS codes.
+
+TTL a 32 bit signed integer that specifies the time interval
+ that the resource record may be cached before the source
+ of the information should again be consulted. Zero
+ values are interpreted to mean that the RR can only be
+ used for the transaction in progress, and should not be
+ cached. For example, SOA records are always distributed
+ with a zero TTL to prohibit caching. Zero values can
+ also be used for extremely volatile data.
+
+RDLENGTH an unsigned 16 bit integer that specifies the length in
+ octets of the RDATA field.
+
+
+
+Mockapetris [Page 11]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+RDATA a variable length string of octets that describes the
+ resource. The format of this information varies
+ according to the TYPE and CLASS of the resource record.
+
+3.2.2. TYPE values
+
+TYPE fields are used in resource records. Note that these types are a
+subset of QTYPEs.
+
+TYPE value and meaning
+
+A 1 a host address
+
+NS 2 an authoritative name server
+
+MD 3 a mail destination (Obsolete - use MX)
+
+MF 4 a mail forwarder (Obsolete - use MX)
+
+CNAME 5 the canonical name for an alias
+
+SOA 6 marks the start of a zone of authority
+
+MB 7 a mailbox domain name (EXPERIMENTAL)
+
+MG 8 a mail group member (EXPERIMENTAL)
+
+MR 9 a mail rename domain name (EXPERIMENTAL)
+
+NULL 10 a null RR (EXPERIMENTAL)
+
+WKS 11 a well known service description
+
+PTR 12 a domain name pointer
+
+HINFO 13 host information
+
+MINFO 14 mailbox or mail list information
+
+MX 15 mail exchange
+
+TXT 16 text strings
+
+3.2.3. QTYPE values
+
+QTYPE fields appear in the question part of a query. QTYPES are a
+superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
+following QTYPEs are defined:
+
+
+
+Mockapetris [Page 12]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+AXFR 252 A request for a transfer of an entire zone
+
+MAILB 253 A request for mailbox-related records (MB, MG or MR)
+
+MAILA 254 A request for mail agent RRs (Obsolete - see MX)
+
+* 255 A request for all records
+
+3.2.4. CLASS values
+
+CLASS fields appear in resource records. The following CLASS mnemonics
+and values are defined:
+
+IN 1 the Internet
+
+CS 2 the CSNET class (Obsolete - used only for examples in
+ some obsolete RFCs)
+
+CH 3 the CHAOS class
+
+HS 4 Hesiod [Dyer 87]
+
+3.2.5. QCLASS values
+
+QCLASS fields appear in the question section of a query. QCLASS values
+are a superset of CLASS values; every CLASS is a valid QCLASS. In
+addition to CLASS values, the following QCLASSes are defined:
+
+* 255 any class
+
+3.3. Standard RRs
+
+The following RR definitions are expected to occur, at least
+potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
+will be used in all classes, and have the same format in all classes.
+Because their RDATA format is known, all domain names in the RDATA
+section of these RRs may be compressed.
+
+<domain-name> is a domain name represented as a series of labels, and
+terminated by a label with zero length. <character-string> is a single
+length octet followed by that number of characters. <character-string>
+is treated as binary information, and can be up to 256 characters in
+length (including the length octet).
+
+
+
+
+
+
+
+
+Mockapetris [Page 13]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.3.1. CNAME RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / CNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CNAME A <domain-name> which specifies the canonical or primary
+ name for the owner. The owner name is an alias.
+
+CNAME RRs cause no additional section processing, but name servers may
+choose to restart the query at the canonical name in certain cases. See
+the description of name server logic in [RFC-1034] for details.
+
+3.3.2. HINFO RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / CPU /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / OS /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CPU A <character-string> which specifies the CPU type.
+
+OS A <character-string> which specifies the operating
+ system type.
+
+Standard values for CPU and OS can be found in [RFC-1010].
+
+HINFO records are used to acquire general information about a host. The
+main use is for protocols such as FTP that can use special procedures
+when talking between machines or operating systems of the same type.
+
+3.3.3. MB RDATA format (EXPERIMENTAL)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / MADNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME A <domain-name> which specifies a host which has the
+ specified mailbox.
+
+
+
+Mockapetris [Page 14]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+MB records cause additional section processing which looks up an A type
+RRs corresponding to MADNAME.
+
+3.3.4. MD RDATA format (Obsolete)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / MADNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME A <domain-name> which specifies a host which has a mail
+ agent for the domain which should be able to deliver
+ mail for the domain.
+
+MD records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MD is obsolete. See the definition of MX and [RFC-974] for details of
+the new scheme. The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 0.
+
+3.3.5. MF RDATA format (Obsolete)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / MADNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME A <domain-name> which specifies a host which has a mail
+ agent for the domain which will accept mail for
+ forwarding to the domain.
+
+MF records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MF is obsolete. See the definition of MX and [RFC-974] for details ofw
+the new scheme. The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 10.
+
+
+
+
+
+
+
+Mockapetris [Page 15]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.3.6. MG RDATA format (EXPERIMENTAL)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / MGMNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MGMNAME A <domain-name> which specifies a mailbox which is a
+ member of the mail group specified by the domain name.
+
+MG records cause no additional section processing.
+
+3.3.7. MINFO RDATA format (EXPERIMENTAL)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / RMAILBX /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / EMAILBX /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+RMAILBX A <domain-name> which specifies a mailbox which is
+ responsible for the mailing list or mailbox. If this
+ domain name names the root, the owner of the MINFO RR is
+ responsible for itself. Note that many existing mailing
+ lists use a mailbox X-request for the RMAILBX field of
+ mailing list X, e.g., Msgroup-request for Msgroup. This
+ field provides a more general mechanism.
+
+
+EMAILBX A <domain-name> which specifies a mailbox which is to
+ receive error messages related to the mailing list or
+ mailbox specified by the owner of the MINFO RR (similar
+ to the ERRORS-TO: field which has been proposed). If
+ this domain name names the root, errors should be
+ returned to the sender of the message.
+
+MINFO records cause no additional section processing. Although these
+records can be associated with a simple mailbox, they are usually used
+with a mailing list.
+
+
+
+
+
+
+
+
+Mockapetris [Page 16]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.3.8. MR RDATA format (EXPERIMENTAL)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / NEWNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NEWNAME A <domain-name> which specifies a mailbox which is the
+ proper rename of the specified mailbox.
+
+MR records cause no additional section processing. The main use for MR
+is as a forwarding entry for a user who has moved to a different
+mailbox.
+
+3.3.9. MX RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | PREFERENCE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / EXCHANGE /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PREFERENCE A 16 bit integer which specifies the preference given to
+ this RR among others at the same owner. Lower values
+ are preferred.
+
+EXCHANGE A <domain-name> which specifies a host willing to act as
+ a mail exchange for the owner name.
+
+MX records cause type A additional section processing for the host
+specified by EXCHANGE. The use of MX RRs is explained in detail in
+[RFC-974].
+
+3.3.10. NULL RDATA format (EXPERIMENTAL)
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / <anything> /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Anything at all may be in the RDATA field so long as it is 65535 octets
+or less.
+
+
+
+
+Mockapetris [Page 17]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+NULL records cause no additional section processing. NULL RRs are not
+allowed in master files. NULLs are used as placeholders in some
+experimental extensions of the DNS.
+
+3.3.11. NS RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / NSDNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NSDNAME A <domain-name> which specifies a host which should be
+ authoritative for the specified class and domain.
+
+NS records cause both the usual additional section processing to locate
+a type A record, and, when used in a referral, a special search of the
+zone in which they reside for glue information.
+
+The NS RR states that the named host should be expected to have a zone
+starting at owner name of the specified class. Note that the class may
+not indicate the protocol family which should be used to communicate
+with the host, although it is typically a strong hint. For example,
+hosts which are name servers for either Internet (IN) or Hesiod (HS)
+class information are normally queried using IN class protocols.
+
+3.3.12. PTR RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / PTRDNAME /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PTRDNAME A <domain-name> which points to some location in the
+ domain name space.
+
+PTR records cause no additional section processing. These RRs are used
+in special domains to point to some other location in the domain space.
+These records are simple data, and don't imply any special processing
+similar to that performed by CNAME, which identifies aliases. See the
+description of the IN-ADDR.ARPA domain for an example.
+
+
+
+
+
+
+
+
+Mockapetris [Page 18]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.3.13. SOA RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / MNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / RNAME /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | SERIAL |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | REFRESH |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | RETRY |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | EXPIRE |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | MINIMUM |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MNAME The <domain-name> of the name server that was the
+ original or primary source of data for this zone.
+
+RNAME A <domain-name> which specifies the mailbox of the
+ person responsible for this zone.
+
+SERIAL The unsigned 32 bit version number of the original copy
+ of the zone. Zone transfers preserve this value. This
+ value wraps and should be compared using sequence space
+ arithmetic.
+
+REFRESH A 32 bit time interval before the zone should be
+ refreshed.
+
+RETRY A 32 bit time interval that should elapse before a
+ failed refresh should be retried.
+
+EXPIRE A 32 bit time value that specifies the upper limit on
+ the time interval that can elapse before the zone is no
+ longer authoritative.
+
+
+
+
+
+Mockapetris [Page 19]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+MINIMUM The unsigned 32 bit minimum TTL field that should be
+ exported with any RR from this zone.
+
+SOA records cause no additional section processing.
+
+All times are in units of seconds.
+
+Most of these fields are pertinent only for name server maintenance
+operations. However, MINIMUM is used in all query operations that
+retrieve RRs from a zone. Whenever a RR is sent in a response to a
+query, the TTL field is set to the maximum of the TTL field from the RR
+and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
+bound on the TTL field for all RRs in a zone. Note that this use of
+MINIMUM should occur when the RRs are copied into the response and not
+when the zone is loaded from a master file or via a zone transfer. The
+reason for this provison is to allow future dynamic update facilities to
+change the SOA RR with known semantics.
+
+
+3.3.14. TXT RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ / TXT-DATA /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+TXT-DATA One or more <character-string>s.
+
+TXT RRs are used to hold descriptive text. The semantics of the text
+depends on the domain where it is found.
+
+3.4. Internet specific RRs
+
+3.4.1. A RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ADDRESS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS A 32 bit Internet address.
+
+Hosts that have multiple Internet addresses will have multiple A
+records.
+
+
+
+
+
+Mockapetris [Page 20]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+A records cause no additional section processing. The RDATA section of
+an A line in a master file is an Internet address expressed as four
+decimal numbers separated by dots without any imbedded spaces (e.g.,
+"10.2.0.52" or "192.0.5.6").
+
+3.4.2. WKS RDATA format
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ADDRESS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | PROTOCOL | |
+ +--+--+--+--+--+--+--+--+ |
+ | |
+ / <BIT MAP> /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS An 32 bit Internet address
+
+PROTOCOL An 8 bit IP protocol number
+
+<BIT MAP> A variable length bit map. The bit map must be a
+ multiple of 8 bits long.
+
+The WKS record is used to describe the well known services supported by
+a particular protocol on a particular internet address. The PROTOCOL
+field specifies an IP protocol number, and the bit map has one bit per
+port of the specified protocol. The first bit corresponds to port 0,
+the second to port 1, etc. If the bit map does not include a bit for a
+protocol of interest, that bit is assumed zero. The appropriate values
+and mnemonics for ports and protocols are specified in [RFC-1010].
+
+For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
+25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
+port 25; if zero, SMTP service is not supported on the specified
+address.
+
+The purpose of WKS RRs is to provide availability information for
+servers for TCP and UDP. If a server supports both TCP and UDP, or has
+multiple Internet addresses, then multiple WKS RRs are used.
+
+WKS RRs cause no additional section processing.
+
+In master files, both ports and protocols are expressed using mnemonics
+or decimal numbers.
+
+
+
+
+Mockapetris [Page 21]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.5. IN-ADDR.ARPA domain
+
+The Internet uses a special domain to support gateway location and
+Internet address to host mapping. Other classes may employ a similar
+strategy in other domains. The intent of this domain is to provide a
+guaranteed method to perform host address to host name mapping, and to
+facilitate queries to locate all gateways on a particular network in the
+Internet.
+
+Note that both of these services are similar to functions that could be
+performed by inverse queries; the difference is that this part of the
+domain name space is structured according to address, and hence can
+guarantee that the appropriate data can be located without an exhaustive
+search of the domain space.
+
+The domain begins at IN-ADDR.ARPA and has a substructure which follows
+the Internet addressing structure.
+
+Domain names in the IN-ADDR.ARPA domain are defined to have up to four
+labels in addition to the IN-ADDR.ARPA suffix. Each label represents
+one octet of an Internet address, and is expressed as a character string
+for a decimal value in the range 0-255 (with leading zeros omitted
+except in the case of a zero octet which is represented by a single
+zero).
+
+Host addresses are represented by domain names that have all four labels
+specified. Thus data for Internet address 10.2.0.52 is located at
+domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
+read, allows zones to be delegated which are exactly one network of
+address space. For example, 10.IN-ADDR.ARPA can be a zone containing
+data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
+MILNET. Address nodes are used to hold pointers to primary host names
+in the normal domain space.
+
+Network numbers correspond to some non-terminal nodes at various depths
+in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
+2, or 3 octets. Network nodes are used to hold pointers to the primary
+host names of gateways attached to that network. Since a gateway is, by
+definition, on more than one network, it will typically have two or more
+network nodes which point at it. Gateways will also have host level
+pointers at their fully qualified addresses.
+
+Both the gateway pointers at network nodes and the normal host pointers
+at full address nodes use the PTR RR to point back to the primary domain
+names of the corresponding hosts.
+
+For example, the IN-ADDR.ARPA domain will contain information about the
+ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
+
+
+
+Mockapetris [Page 22]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
+gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
+GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
+and a name GW.LCS.MIT.EDU, the domain database would contain:
+
+ 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
+ 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
+ 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
+ 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
+ 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
+ 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
+ 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
+ 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
+ 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
+ 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
+
+Thus a program which wanted to locate gateways on net 10 would originate
+a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
+would receive two RRs in response:
+
+ 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
+ 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
+
+The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
+GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
+these gateways.
+
+A resolver which wanted to find the host name corresponding to Internet
+host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
+QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
+
+ 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
+
+Several cautions apply to the use of these services:
+ - Since the IN-ADDR.ARPA special domain and the normal domain
+ for a particular host or gateway will be in different zones,
+ the possibility exists that that the data may be inconsistent.
+
+ - Gateways will often have two names in separate domains, only
+ one of which can be primary.
+
+ - Systems that use the domain database to initialize their
+ routing tables must start with enough gateway information to
+ guarantee that they can access the appropriate name server.
+
+ - The gateway data only reflects the existence of a gateway in a
+ manner equivalent to the current HOSTS.TXT file. It doesn't
+ replace the dynamic availability information from GGP or EGP.
+
+
+
+Mockapetris [Page 23]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+3.6. Defining new types, classes, and special namespaces
+
+The previously defined types and classes are the ones in use as of the
+date of this memo. New definitions should be expected. This section
+makes some recommendations to designers considering additions to the
+existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
+forum where general discussion of design issues takes place.
+
+In general, a new type is appropriate when new information is to be
+added to the database about an existing object, or we need new data
+formats for some totally new object. Designers should attempt to define
+types and their RDATA formats that are generally applicable to all
+classes, and which avoid duplication of information. New classes are
+appropriate when the DNS is to be used for a new protocol, etc which
+requires new class-specific data formats, or when a copy of the existing
+name space is desired, but a separate management domain is necessary.
+
+New types and classes need mnemonics for master files; the format of the
+master files requires that the mnemonics for type and class be disjoint.
+
+TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
+respectively.
+
+The present system uses multiple RRs to represent multiple values of a
+type rather than storing multiple values in the RDATA section of a
+single RR. This is less efficient for most applications, but does keep
+RRs shorter. The multiple RRs assumption is incorporated in some
+experimental work on dynamic update methods.
+
+The present system attempts to minimize the duplication of data in the
+database in order to insure consistency. Thus, in order to find the
+address of the host for a mail exchange, you map the mail domain name to
+a host name, then the host name to addresses, rather than a direct
+mapping to host address. This approach is preferred because it avoids
+the opportunity for inconsistency.
+
+In defining a new type of data, multiple RR types should not be used to
+create an ordering between entries or express different formats for
+equivalent bindings, instead this information should be carried in the
+body of the RR and a single type used. This policy avoids problems with
+caching multiple types and defining QTYPEs to match multiple types.
+
+For example, the original form of mail exchange binding used two RR
+types one to represent a "closer" exchange (MD) and one to represent a
+"less close" exchange (MF). The difficulty is that the presence of one
+RR type in a cache doesn't convey any information about the other
+because the query which acquired the cached information might have used
+a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
+
+
+
+Mockapetris [Page 24]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+service used a single type (MX) with a "preference" value in the RDATA
+section which can order different RRs. However, if any MX RRs are found
+in the cache, then all should be there.
+
+4. MESSAGES
+
+4.1. Format
+
+All communications inside of the domain protocol are carried in a single
+format called a message. The top level format of message is divided
+into 5 sections (some of which are empty in certain cases) shown below:
+
+ +---------------------+
+ | Header |
+ +---------------------+
+ | Question | the question for the name server
+ +---------------------+
+ | Answer | RRs answering the question
+ +---------------------+
+ | Authority | RRs pointing toward an authority
+ +---------------------+
+ | Additional | RRs holding additional information
+ +---------------------+
+
+The header section is always present. The header includes fields that
+specify which of the remaining sections are present, and also specify
+whether the message is a query or a response, a standard query or some
+other opcode, etc.
+
+The names of the sections after the header are derived from their use in
+standard queries. The question section contains fields that describe a
+question to a name server. These fields are a query type (QTYPE), a
+query class (QCLASS), and a query domain name (QNAME). The last three
+sections have the same format: a possibly empty list of concatenated
+resource records (RRs). The answer section contains RRs that answer the
+question; the authority section contains RRs that point toward an
+authoritative name server; the additional records section contains RRs
+which relate to the query, but are not strictly answers for the
+question.
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris [Page 25]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+4.1.1. Header section format
+
+The header contains the following fields:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ID |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ID A 16 bit identifier assigned by the program that
+ generates any kind of query. This identifier is copied
+ the corresponding reply and can be used by the requester
+ to match up replies to outstanding queries.
+
+QR A one bit field that specifies whether this message is a
+ query (0), or a response (1).
+
+OPCODE A four bit field that specifies kind of query in this
+ message. This value is set by the originator of a query
+ and copied into the response. The values are:
+
+ 0 a standard query (QUERY)
+
+ 1 an inverse query (IQUERY)
+
+ 2 a server status request (STATUS)
+
+ 3-15 reserved for future use
+
+AA Authoritative Answer - this bit is valid in responses,
+ and specifies that the responding name server is an
+ authority for the domain name in question section.
+
+ Note that the contents of the answer section may have
+ multiple owner names because of aliases. The AA bit
+
+
+
+Mockapetris [Page 26]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ corresponds to the name which matches the query name, or
+ the first owner name in the answer section.
+
+TC TrunCation - specifies that this message was truncated
+ due to length greater than that permitted on the
+ transmission channel.
+
+RD Recursion Desired - this bit may be set in a query and
+ is copied into the response. If RD is set, it directs
+ the name server to pursue the query recursively.
+ Recursive query support is optional.
+
+RA Recursion Available - this be is set or cleared in a
+ response, and denotes whether recursive query support is
+ available in the name server.
+
+Z Reserved for future use. Must be zero in all queries
+ and responses.
+
+RCODE Response code - this 4 bit field is set as part of
+ responses. The values have the following
+ interpretation:
+
+ 0 No error condition
+
+ 1 Format error - The name server was
+ unable to interpret the query.
+
+ 2 Server failure - The name server was
+ unable to process this query due to a
+ problem with the name server.
+
+ 3 Name Error - Meaningful only for
+ responses from an authoritative name
+ server, this code signifies that the
+ domain name referenced in the query does
+ not exist.
+
+ 4 Not Implemented - The name server does
+ not support the requested kind of query.
+
+ 5 Refused - The name server refuses to
+ perform the specified operation for
+ policy reasons. For example, a name
+ server may not wish to provide the
+ information to the particular requester,
+ or a name server may not wish to perform
+ a particular operation (e.g., zone
+
+
+
+Mockapetris [Page 27]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ transfer) for particular data.
+
+ 6-15 Reserved for future use.
+
+QDCOUNT an unsigned 16 bit integer specifying the number of
+ entries in the question section.
+
+ANCOUNT an unsigned 16 bit integer specifying the number of
+ resource records in the answer section.
+
+NSCOUNT an unsigned 16 bit integer specifying the number of name
+ server resource records in the authority records
+ section.
+
+ARCOUNT an unsigned 16 bit integer specifying the number of
+ resource records in the additional records section.
+
+4.1.2. Question section format
+
+The question section is used to carry the "question" in most queries,
+i.e., the parameters that define what is being asked. The section
+contains QDCOUNT (usually 1) entries, each of the following format:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / QNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QTYPE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QCLASS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+QNAME a domain name represented as a sequence of labels, where
+ each label consists of a length octet followed by that
+ number of octets. The domain name terminates with the
+ zero length octet for the null label of the root. Note
+ that this field may be an odd number of octets; no
+ padding is used.
+
+QTYPE a two octet code which specifies the type of the query.
+ The values for this field include all codes valid for a
+ TYPE field, together with some more general codes which
+ can match more than one type of RR.
+
+
+
+Mockapetris [Page 28]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+QCLASS a two octet code that specifies the class of the query.
+ For example, the QCLASS field is IN for the Internet.
+
+4.1.3. Resource record format
+
+The answer, authority, and additional sections all share the same
+format: a variable number of resource records, where the number of
+records is specified in the corresponding count field in the header.
+Each resource record has the following format:
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / /
+ / NAME /
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TYPE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | CLASS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TTL |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | RDLENGTH |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+ / RDATA /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NAME a domain name to which this resource record pertains.
+
+TYPE two octets containing one of the RR type codes. This
+ field specifies the meaning of the data in the RDATA
+ field.
+
+CLASS two octets which specify the class of the data in the
+ RDATA field.
+
+TTL a 32 bit unsigned integer that specifies the time
+ interval (in seconds) that the resource record may be
+ cached before it should be discarded. Zero values are
+ interpreted to mean that the RR can only be used for the
+ transaction in progress, and should not be cached.
+
+
+
+
+
+Mockapetris [Page 29]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+RDLENGTH an unsigned 16 bit integer that specifies the length in
+ octets of the RDATA field.
+
+RDATA a variable length string of octets that describes the
+ resource. The format of this information varies
+ according to the TYPE and CLASS of the resource record.
+ For example, the if the TYPE is A and the CLASS is IN,
+ the RDATA field is a 4 octet ARPA Internet address.
+
+4.1.4. Message compression
+
+In order to reduce the size of messages, the domain system utilizes a
+compression scheme which eliminates the repetition of domain names in a
+message. In this scheme, an entire domain name or a list of labels at
+the end of a domain name is replaced with a pointer to a prior occurance
+of the same name.
+
+The pointer takes the form of a two octet sequence:
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | 1 1| OFFSET |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The first two bits are ones. This allows a pointer to be distinguished
+from a label, since the label must begin with two zero bits because
+labels are restricted to 63 octets or less. (The 10 and 01 combinations
+are reserved for future use.) The OFFSET field specifies an offset from
+the start of the message (i.e., the first octet of the ID field in the
+domain header). A zero offset specifies the first byte of the ID field,
+etc.
+
+The compression scheme allows a domain name in a message to be
+represented as either:
+
+ - a sequence of labels ending in a zero octet
+
+ - a pointer
+
+ - a sequence of labels ending with a pointer
+
+Pointers can only be used for occurances of a domain name where the
+format is not class specific. If this were not the case, a name server
+or resolver would be required to know the format of all RRs it handled.
+As yet, there are no such cases, but they may occur in future RDATA
+formats.
+
+If a domain name is contained in a part of the message subject to a
+length field (such as the RDATA section of an RR), and compression is
+
+
+
+Mockapetris [Page 30]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+used, the length of the compressed name is used in the length
+calculation, rather than the length of the expanded name.
+
+Programs are free to avoid using pointers in messages they generate,
+although this will reduce datagram capacity, and may cause truncation.
+However all programs are required to understand arriving messages that
+contain pointers.
+
+For example, a datagram might need to use the domain names F.ISI.ARPA,
+FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
+message, these domain names might be represented as:
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 20 | 1 | F |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 22 | 3 | I |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 24 | S | I |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 26 | 4 | A |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 28 | R | P |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 30 | A | 0 |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 40 | 3 | F |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 42 | O | O |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 44 | 1 1| 20 |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 64 | 1 1| 26 |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ 92 | 0 | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The domain name for F.ISI.ARPA is shown at offset 20. The domain name
+FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
+concatenate a label for FOO to the previously defined F.ISI.ARPA. The
+domain name ARPA is defined at offset 64 using a pointer to the ARPA
+component of the name F.ISI.ARPA at 20; note that this pointer relies on
+ARPA being the last label in the string at 20. The root domain name is
+
+
+
+Mockapetris [Page 31]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+defined by a single octet of zeros at 92; the root domain name has no
+labels.
+
+4.2. Transport
+
+The DNS assumes that messages will be transmitted as datagrams or in a
+byte stream carried by a virtual circuit. While virtual circuits can be
+used for any DNS activity, datagrams are preferred for queries due to
+their lower overhead and better performance. Zone refresh activities
+must use virtual circuits because of the need for reliable transfer.
+
+The Internet supports name server access using TCP [RFC-793] on server
+port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
+port 53 (decimal).
+
+4.2.1. UDP usage
+
+Messages sent using UDP user server port 53 (decimal).
+
+Messages carried by UDP are restricted to 512 bytes (not counting the IP
+or UDP headers). Longer messages are truncated and the TC bit is set in
+the header.
+
+UDP is not acceptable for zone transfers, but is the recommended method
+for standard queries in the Internet. Queries sent using UDP may be
+lost, and hence a retransmission strategy is required. Queries or their
+responses may be reordered by the network, or by processing in name
+servers, so resolvers should not depend on them being returned in order.
+
+The optimal UDP retransmission policy will vary with performance of the
+Internet and the needs of the client, but the following are recommended:
+
+ - The client should try other servers and server addresses
+ before repeating a query to a specific address of a server.
+
+ - The retransmission interval should be based on prior
+ statistics if possible. Too aggressive retransmission can
+ easily slow responses for the community at large. Depending
+ on how well connected the client is to its expected servers,
+ the minimum retransmission interval should be 2-5 seconds.
+
+More suggestions on server selection and retransmission policy can be
+found in the resolver section of this memo.
+
+4.2.2. TCP usage
+
+Messages sent over TCP connections use server port 53 (decimal). The
+message is prefixed with a two byte length field which gives the message
+
+
+
+Mockapetris [Page 32]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+length, excluding the two byte length field. This length field allows
+the low-level processing to assemble a complete message before beginning
+to parse it.
+
+Several connection management policies are recommended:
+
+ - The server should not block other activities waiting for TCP
+ data.
+
+ - The server should support multiple connections.
+
+ - The server should assume that the client will initiate
+ connection closing, and should delay closing its end of the
+ connection until all outstanding client requests have been
+ satisfied.
+
+ - If the server needs to close a dormant connection to reclaim
+ resources, it should wait until the connection has been idle
+ for a period on the order of two minutes. In particular, the
+ server should allow the SOA and AXFR request sequence (which
+ begins a refresh operation) to be made on a single connection.
+ Since the server would be unable to answer queries anyway, a
+ unilateral close or reset may be used instead of a graceful
+ close.
+
+5. MASTER FILES
+
+Master files are text files that contain RRs in text form. Since the
+contents of a zone can be expressed in the form of a list of RRs a
+master file is most often used to define a zone, though it can be used
+to list a cache's contents. Hence, this section first discusses the
+format of RRs in a master file, and then the special considerations when
+a master file is used to create a zone in some name server.
+
+5.1. Format
+
+The format of these files is a sequence of entries. Entries are
+predominantly line-oriented, though parentheses can be used to continue
+a list of items across a line boundary, and text literals can contain
+CRLF within the text. Any combination of tabs and spaces act as a
+delimiter between the separate items that make up an entry. The end of
+any line in the master file can end with a comment. The comment starts
+with a ";" (semicolon).
+
+The following entries are defined:
+
+ <blank>[<comment>]
+
+
+
+
+Mockapetris [Page 33]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ $ORIGIN <domain-name> [<comment>]
+
+ $INCLUDE <file-name> [<domain-name>] [<comment>]
+
+ <domain-name><rr> [<comment>]
+
+ <blank><rr> [<comment>]
+
+Blank lines, with or without comments, are allowed anywhere in the file.
+
+Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
+followed by a domain name, and resets the current origin for relative
+domain names to the stated name. $INCLUDE inserts the named file into
+the current file, and may optionally specify a domain name that sets the
+relative domain name origin for the included file. $INCLUDE may also
+have a comment. Note that a $INCLUDE entry never changes the relative
+origin of the parent file, regardless of changes to the relative origin
+made within the included file.
+
+The last two forms represent RRs. If an entry for an RR begins with a
+blank, then the RR is assumed to be owned by the last stated owner. If
+an RR entry begins with a <domain-name>, then the owner name is reset.
+
+<rr> contents take one of the following forms:
+
+ [<TTL>] [<class>] <type> <RDATA>
+
+ [<class>] [<TTL>] <type> <RDATA>
+
+The RR begins with optional TTL and class fields, followed by a type and
+RDATA field appropriate to the type and class. Class and type use the
+standard mnemonics, TTL is a decimal integer. Omitted class and TTL
+values are default to the last explicitly stated values. Since type and
+class mnemonics are disjoint, the parse is unique. (Note that this
+order is different from the order used in examples and the order used in
+the actual RRs; the given order allows easier parsing and defaulting.)
+
+<domain-name>s make up a large share of the data in the master file.
+The labels in the domain name are expressed as character strings and
+separated by dots. Quoting conventions allow arbitrary characters to be
+stored in domain names. Domain names that end in a dot are called
+absolute, and are taken as complete. Domain names which do not end in a
+dot are called relative; the actual domain name is the concatenation of
+the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
+an argument to the master file loading routine. A relative name is an
+error when no origin is available.
+
+
+
+
+
+Mockapetris [Page 34]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+<character-string> is expressed in one or two ways: as a contiguous set
+of characters without interior spaces, or as a string beginning with a "
+and ending with a ". Inside a " delimited string any character can
+occur, except for a " itself, which must be quoted using \ (back slash).
+
+Because these files are text files several special encodings are
+necessary to allow arbitrary data to be loaded. In particular:
+
+ of the root.
+
+@ A free standing @ is used to denote the current origin.
+
+\X where X is any character other than a digit (0-9), is
+ used to quote that character so that its special meaning
+ does not apply. For example, "\." can be used to place
+ a dot character in a label.
+
+\DDD where each D is a digit is the octet corresponding to
+ the decimal number described by DDD. The resulting
+ octet is assumed to be text and is not checked for
+ special meaning.
+
+( ) Parentheses are used to group data that crosses a line
+ boundary. In effect, line terminations are not
+ recognized within parentheses.
+
+; Semicolon is used to start a comment; the remainder of
+ the line is ignored.
+
+5.2. Use of master files to define zones
+
+When a master file is used to load a zone, the operation should be
+suppressed if any errors are encountered in the master file. The
+rationale for this is that a single error can have widespread
+consequences. For example, suppose that the RRs defining a delegation
+have syntax errors; then the server will return authoritative name
+errors for all names in the subzone (except in the case where the
+subzone is also present on the server).
+
+Several other validity checks that should be performed in addition to
+insuring that the file is syntactically correct:
+
+ 1. All RRs in the file should have the same class.
+
+ 2. Exactly one SOA RR should be present at the top of the zone.
+
+ 3. If delegations are present and glue information is required,
+ it should be present.
+
+
+
+Mockapetris [Page 35]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ 4. Information present outside of the authoritative nodes in the
+ zone should be glue information, rather than the result of an
+ origin or similar error.
+
+5.3. Master file example
+
+The following is an example file which might be used to define the
+ISI.EDU zone.and is loaded with an origin of ISI.EDU:
+
+@ IN SOA VENERA Action\.domains (
+ 20 ; SERIAL
+ 7200 ; REFRESH
+ 600 ; RETRY
+ 3600000; EXPIRE
+ 60) ; MINIMUM
+
+ NS A.ISI.EDU.
+ NS VENERA
+ NS VAXA
+ MX 10 VENERA
+ MX 20 VAXA
+
+A A 26.3.0.103
+
+VENERA A 10.1.0.52
+ A 128.9.0.32
+
+VAXA A 10.2.0.27
+ A 128.9.0.33
+
+
+$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
+
+Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
+
+ MOE MB A.ISI.EDU.
+ LARRY MB A.ISI.EDU.
+ CURLEY MB A.ISI.EDU.
+ STOOGES MG MOE
+ MG LARRY
+ MG CURLEY
+
+Note the use of the \ character in the SOA RR to specify the responsible
+person mailbox "Action.domains@E.ISI.EDU".
+
+
+
+
+
+
+
+Mockapetris [Page 36]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+6. NAME SERVER IMPLEMENTATION
+
+6.1. Architecture
+
+The optimal structure for the name server will depend on the host
+operating system and whether the name server is integrated with resolver
+operations, either by supporting recursive service, or by sharing its
+database with a resolver. This section discusses implementation
+considerations for a name server which shares a database with a
+resolver, but most of these concerns are present in any name server.
+
+6.1.1. Control
+
+A name server must employ multiple concurrent activities, whether they
+are implemented as separate tasks in the host's OS or multiplexing
+inside a single name server program. It is simply not acceptable for a
+name server to block the service of UDP requests while it waits for TCP
+data for refreshing or query activities. Similarly, a name server
+should not attempt to provide recursive service without processing such
+requests in parallel, though it may choose to serialize requests from a
+single client, or to regard identical requests from the same client as
+duplicates. A name server should not substantially delay requests while
+it reloads a zone from master files or while it incorporates a newly
+refreshed zone into its database.
+
+6.1.2. Database
+
+While name server implementations are free to use any internal data
+structures they choose, the suggested structure consists of three major
+parts:
+
+ - A "catalog" data structure which lists the zones available to
+ this server, and a "pointer" to the zone data structure. The
+ main purpose of this structure is to find the nearest ancestor
+ zone, if any, for arriving standard queries.
+
+ - Separate data structures for each of the zones held by the
+ name server.
+
+ - A data structure for cached data. (or perhaps separate caches
+ for different classes)
+
+All of these data structures can be implemented an identical tree
+structure format, with different data chained off the nodes in different
+parts: in the catalog the data is pointers to zones, while in the zone
+and cache data structures, the data will be RRs. In designing the tree
+framework the designer should recognize that query processing will need
+to traverse the tree using case-insensitive label comparisons; and that
+
+
+
+Mockapetris [Page 37]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+in real data, a few nodes have a very high branching factor (100-1000 or
+more), but the vast majority have a very low branching factor (0-1).
+
+One way to solve the case problem is to store the labels for each node
+in two pieces: a standardized-case representation of the label where all
+ASCII characters are in a single case, together with a bit mask that
+denotes which characters are actually of a different case. The
+branching factor diversity can be handled using a simple linked list for
+a node until the branching factor exceeds some threshold, and
+transitioning to a hash structure after the threshold is exceeded. In
+any case, hash structures used to store tree sections must insure that
+hash functions and procedures preserve the casing conventions of the
+DNS.
+
+The use of separate structures for the different parts of the database
+is motivated by several factors:
+
+ - The catalog structure can be an almost static structure that
+ need change only when the system administrator changes the
+ zones supported by the server. This structure can also be
+ used to store parameters used to control refreshing
+ activities.
+
+ - The individual data structures for zones allow a zone to be
+ replaced simply by changing a pointer in the catalog. Zone
+ refresh operations can build a new structure and, when
+ complete, splice it into the database via a simple pointer
+ replacement. It is very important that when a zone is
+ refreshed, queries should not use old and new data
+ simultaneously.
+
+ - With the proper search procedures, authoritative data in zones
+ will always "hide", and hence take precedence over, cached
+ data.
+
+ - Errors in zone definitions that cause overlapping zones, etc.,
+ may cause erroneous responses to queries, but problem
+ determination is simplified, and the contents of one "bad"
+ zone can't corrupt another.
+
+ - Since the cache is most frequently updated, it is most
+ vulnerable to corruption during system restarts. It can also
+ become full of expired RR data. In either case, it can easily
+ be discarded without disturbing zone data.
+
+A major aspect of database design is selecting a structure which allows
+the name server to deal with crashes of the name server's host. State
+information which a name server should save across system crashes
+
+
+
+Mockapetris [Page 38]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+includes the catalog structure (including the state of refreshing for
+each zone) and the zone data itself.
+
+6.1.3. Time
+
+Both the TTL data for RRs and the timing data for refreshing activities
+depends on 32 bit timers in units of seconds. Inside the database,
+refresh timers and TTLs for cached data conceptually "count down", while
+data in the zone stays with constant TTLs.
+
+A recommended implementation strategy is to store time in two ways: as
+a relative increment and as an absolute time. One way to do this is to
+use positive 32 bit numbers for one type and negative numbers for the
+other. The RRs in zones use relative times; the refresh timers and
+cache data use absolute times. Absolute numbers are taken with respect
+to some known origin and converted to relative values when placed in the
+response to a query. When an absolute TTL is negative after conversion
+to relative, then the data is expired and should be ignored.
+
+6.2. Standard query processing
+
+The major algorithm for standard query processing is presented in
+[RFC-1034].
+
+When processing queries with QCLASS=*, or some other QCLASS which
+matches multiple classes, the response should never be authoritative
+unless the server can guarantee that the response covers all classes.
+
+When composing a response, RRs which are to be inserted in the
+additional section, but duplicate RRs in the answer or authority
+sections, may be omitted from the additional section.
+
+When a response is so long that truncation is required, the truncation
+should start at the end of the response and work forward in the
+datagram. Thus if there is any data for the authority section, the
+answer section is guaranteed to be unique.
+
+The MINIMUM value in the SOA should be used to set a floor on the TTL of
+data distributed from a zone. This floor function should be done when
+the data is copied into a response. This will allow future dynamic
+update protocols to change the SOA MINIMUM field without ambiguous
+semantics.
+
+6.3. Zone refresh and reload processing
+
+In spite of a server's best efforts, it may be unable to load zone data
+from a master file due to syntax errors, etc., or be unable to refresh a
+zone within the its expiration parameter. In this case, the name server
+
+
+
+Mockapetris [Page 39]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+should answer queries as if it were not supposed to possess the zone.
+
+If a master is sending a zone out via AXFR, and a new version is created
+during the transfer, the master should continue to send the old version
+if possible. In any case, it should never send part of one version and
+part of another. If completion is not possible, the master should reset
+the connection on which the zone transfer is taking place.
+
+6.4. Inverse queries (Optional)
+
+Inverse queries are an optional part of the DNS. Name servers are not
+required to support any form of inverse queries. If a name server
+receives an inverse query that it does not support, it returns an error
+response with the "Not Implemented" error set in the header. While
+inverse query support is optional, all name servers must be at least
+able to return the error response.
+
+6.4.1. The contents of inverse queries and responses Inverse
+queries reverse the mappings performed by standard query operations;
+while a standard query maps a domain name to a resource, an inverse
+query maps a resource to a domain name. For example, a standard query
+might bind a domain name to a host address; the corresponding inverse
+query binds the host address to a domain name.
+
+Inverse queries take the form of a single RR in the answer section of
+the message, with an empty question section. The owner name of the
+query RR and its TTL are not significant. The response carries
+questions in the question section which identify all names possessing
+the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
+about all of the domain name space, the response can never be assumed to
+be complete. Thus inverse queries are primarily useful for database
+management and debugging activities. Inverse queries are NOT an
+acceptable method of mapping host addresses to host names; use the IN-
+ADDR.ARPA domain instead.
+
+Where possible, name servers should provide case-insensitive comparisons
+for inverse queries. Thus an inverse query asking for an MX RR of
+"Venera.isi.edu" should get the same response as a query for
+"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
+produce the same result as an inverse query for "IBM-pc unix". However,
+this cannot be guaranteed because name servers may possess RRs that
+contain character strings but the name server does not know that the
+data is character.
+
+When a name server processes an inverse query, it either returns:
+
+ 1. zero, one, or multiple domain names for the specified
+ resource as QNAMEs in the question section
+
+
+
+Mockapetris [Page 40]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ 2. an error code indicating that the name server doesn't support
+ inverse mapping of the specified resource type.
+
+When the response to an inverse query contains one or more QNAMEs, the
+owner name and TTL of the RR in the answer section which defines the
+inverse query is modified to exactly match an RR found at the first
+QNAME.
+
+RRs returned in the inverse queries cannot be cached using the same
+mechanism as is used for the replies to standard queries. One reason
+for this is that a name might have multiple RRs of the same type, and
+only one would appear. For example, an inverse query for a single
+address of a multiply homed host might create the impression that only
+one address existed.
+
+6.4.2. Inverse query and response example The overall structure
+of an inverse query for retrieving the domain name that corresponds to
+Internet address 10.1.0.52 is shown below:
+
+ +-----------------------------------------+
+ Header | OPCODE=IQUERY, ID=997 |
+ +-----------------------------------------+
+ Question | <empty> |
+ +-----------------------------------------+
+ Answer | <anyname> A IN 10.1.0.52 |
+ +-----------------------------------------+
+ Authority | <empty> |
+ +-----------------------------------------+
+ Additional | <empty> |
+ +-----------------------------------------+
+
+This query asks for a question whose answer is the Internet style
+address 10.1.0.52. Since the owner name is not known, any domain name
+can be used as a placeholder (and is ignored). A single octet of zero,
+signifying the root, is usually used because it minimizes the length of
+the message. The TTL of the RR is not significant. The response to
+this query might be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris [Page 41]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ +-----------------------------------------+
+ Header | OPCODE=RESPONSE, ID=997 |
+ +-----------------------------------------+
+ Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+ +-----------------------------------------+
+ Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+ +-----------------------------------------+
+ Authority | <empty> |
+ +-----------------------------------------+
+ Additional | <empty> |
+ +-----------------------------------------+
+
+Note that the QTYPE in a response to an inverse query is the same as the
+TYPE field in the answer section of the inverse query. Responses to
+inverse queries may contain multiple questions when the inverse is not
+unique. If the question section in the response is not empty, then the
+RR in the answer section is modified to correspond to be an exact copy
+of an RR at the first QNAME.
+
+6.4.3. Inverse query processing
+
+Name servers that support inverse queries can support these operations
+through exhaustive searches of their databases, but this becomes
+impractical as the size of the database increases. An alternative
+approach is to invert the database according to the search key.
+
+For name servers that support multiple zones and a large amount of data,
+the recommended approach is separate inversions for each zone. When a
+particular zone is changed during a refresh, only its inversions need to
+be redone.
+
+Support for transfer of this type of inversion may be included in future
+versions of the domain system, but is not supported in this version.
+
+6.5. Completion queries and responses
+
+The optional completion services described in RFC-882 and RFC-883 have
+been deleted. Redesigned services may become available in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris [Page 42]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+7. RESOLVER IMPLEMENTATION
+
+The top levels of the recommended resolver algorithm are discussed in
+[RFC-1034]. This section discusses implementation details assuming the
+database structure suggested in the name server implementation section
+of this memo.
+
+7.1. Transforming a user request into a query
+
+The first step a resolver takes is to transform the client's request,
+stated in a format suitable to the local OS, into a search specification
+for RRs at a specific name which match a specific QTYPE and QCLASS.
+Where possible, the QTYPE and QCLASS should correspond to a single type
+and a single class, because this makes the use of cached data much
+simpler. The reason for this is that the presence of data of one type
+in a cache doesn't confirm the existence or non-existence of data of
+other types, hence the only way to be sure is to consult an
+authoritative source. If QCLASS=* is used, then authoritative answers
+won't be available.
+
+Since a resolver must be able to multiplex multiple requests if it is to
+perform its function efficiently, each pending request is usually
+represented in some block of state information. This state block will
+typically contain:
+
+ - A timestamp indicating the time the request began.
+ The timestamp is used to decide whether RRs in the database
+ can be used or are out of date. This timestamp uses the
+ absolute time format previously discussed for RR storage in
+ zones and caches. Note that when an RRs TTL indicates a
+ relative time, the RR must be timely, since it is part of a
+ zone. When the RR has an absolute time, it is part of a
+ cache, and the TTL of the RR is compared against the timestamp
+ for the start of the request.
+
+ Note that using the timestamp is superior to using a current
+ time, since it allows RRs with TTLs of zero to be entered in
+ the cache in the usual manner, but still used by the current
+ request, even after intervals of many seconds due to system
+ load, query retransmission timeouts, etc.
+
+ - Some sort of parameters to limit the amount of work which will
+ be performed for this request.
+
+ The amount of work which a resolver will do in response to a
+ client request must be limited to guard against errors in the
+ database, such as circular CNAME references, and operational
+ problems, such as network partition which prevents the
+
+
+
+Mockapetris [Page 43]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ resolver from accessing the name servers it needs. While
+ local limits on the number of times a resolver will retransmit
+ a particular query to a particular name server address are
+ essential, the resolver should have a global per-request
+ counter to limit work on a single request. The counter should
+ be set to some initial value and decremented whenever the
+ resolver performs any action (retransmission timeout,
+ retransmission, etc.) If the counter passes zero, the request
+ is terminated with a temporary error.
+
+ Note that if the resolver structure allows one request to
+ start others in parallel, such as when the need to access a
+ name server for one request causes a parallel resolve for the
+ name server's addresses, the spawned request should be started
+ with a lower counter. This prevents circular references in
+ the database from starting a chain reaction of resolver
+ activity.
+
+ - The SLIST data structure discussed in [RFC-1034].
+
+ This structure keeps track of the state of a request if it
+ must wait for answers from foreign name servers.
+
+7.2. Sending the queries
+
+As described in [RFC-1034], the basic task of the resolver is to
+formulate a query which will answer the client's request and direct that
+query to name servers which can provide the information. The resolver
+will usually only have very strong hints about which servers to ask, in
+the form of NS RRs, and may have to revise the query, in response to
+CNAMEs, or revise the set of name servers the resolver is asking, in
+response to delegation responses which point the resolver to name
+servers closer to the desired information. In addition to the
+information requested by the client, the resolver may have to call upon
+its own services to determine the address of name servers it wishes to
+contact.
+
+In any case, the model used in this memo assumes that the resolver is
+multiplexing attention between multiple requests, some from the client,
+and some internally generated. Each request is represented by some
+state information, and the desired behavior is that the resolver
+transmit queries to name servers in a way that maximizes the probability
+that the request is answered, minimizes the time that the request takes,
+and avoids excessive transmissions. The key algorithm uses the state
+information of the request to select the next name server address to
+query, and also computes a timeout which will cause the next action
+should a response not arrive. The next action will usually be a
+transmission to some other server, but may be a temporary error to the
+
+
+
+Mockapetris [Page 44]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+client.
+
+The resolver always starts with a list of server names to query (SLIST).
+This list will be all NS RRs which correspond to the nearest ancestor
+zone that the resolver knows about. To avoid startup problems, the
+resolver should have a set of default servers which it will ask should
+it have no current NS RRs which are appropriate. The resolver then adds
+to SLIST all of the known addresses for the name servers, and may start
+parallel requests to acquire the addresses of the servers when the
+resolver has the name, but no addresses, for the name servers.
+
+To complete initialization of SLIST, the resolver attaches whatever
+history information it has to the each address in SLIST. This will
+usually consist of some sort of weighted averages for the response time
+of the address, and the batting average of the address (i.e., how often
+the address responded at all to the request). Note that this
+information should be kept on a per address basis, rather than on a per
+name server basis, because the response time and batting average of a
+particular server may vary considerably from address to address. Note
+also that this information is actually specific to a resolver address /
+server address pair, so a resolver with multiple addresses may wish to
+keep separate histories for each of its addresses. Part of this step
+must deal with addresses which have no such history; in this case an
+expected round trip time of 5-10 seconds should be the worst case, with
+lower estimates for the same local network, etc.
+
+Note that whenever a delegation is followed, the resolver algorithm
+reinitializes SLIST.
+
+The information establishes a partial ranking of the available name
+server addresses. Each time an address is chosen and the state should
+be altered to prevent its selection again until all other addresses have
+been tried. The timeout for each transmission should be 50-100% greater
+than the average predicted value to allow for variance in response.
+
+Some fine points:
+
+ - The resolver may encounter a situation where no addresses are
+ available for any of the name servers named in SLIST, and
+ where the servers in the list are precisely those which would
+ normally be used to look up their own addresses. This
+ situation typically occurs when the glue address RRs have a
+ smaller TTL than the NS RRs marking delegation, or when the
+ resolver caches the result of a NS search. The resolver
+ should detect this condition and restart the search at the
+ next ancestor zone, or alternatively at the root.
+
+
+
+
+
+Mockapetris [Page 45]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ - If a resolver gets a server error or other bizarre response
+ from a name server, it should remove it from SLIST, and may
+ wish to schedule an immediate transmission to the next
+ candidate server address.
+
+7.3. Processing responses
+
+The first step in processing arriving response datagrams is to parse the
+response. This procedure should include:
+
+ - Check the header for reasonableness. Discard datagrams which
+ are queries when responses are expected.
+
+ - Parse the sections of the message, and insure that all RRs are
+ correctly formatted.
+
+ - As an optional step, check the TTLs of arriving data looking
+ for RRs with excessively long TTLs. If a RR has an
+ excessively long TTL, say greater than 1 week, either discard
+ the whole response, or limit all TTLs in the response to 1
+ week.
+
+The next step is to match the response to a current resolver request.
+The recommended strategy is to do a preliminary matching using the ID
+field in the domain header, and then to verify that the question section
+corresponds to the information currently desired. This requires that
+the transmission algorithm devote several bits of the domain ID field to
+a request identifier of some sort. This step has several fine points:
+
+ - Some name servers send their responses from different
+ addresses than the one used to receive the query. That is, a
+ resolver cannot rely that a response will come from the same
+ address which it sent the corresponding query to. This name
+ server bug is typically encountered in UNIX systems.
+
+ - If the resolver retransmits a particular request to a name
+ server it should be able to use a response from any of the
+ transmissions. However, if it is using the response to sample
+ the round trip time to access the name server, it must be able
+ to determine which transmission matches the response (and keep
+ transmission times for each outgoing message), or only
+ calculate round trip times based on initial transmissions.
+
+ - A name server will occasionally not have a current copy of a
+ zone which it should have according to some NS RRs. The
+ resolver should simply remove the name server from the current
+ SLIST, and continue.
+
+
+
+
+Mockapetris [Page 46]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+7.4. Using the cache
+
+In general, we expect a resolver to cache all data which it receives in
+responses since it may be useful in answering future client requests.
+However, there are several types of data which should not be cached:
+
+ - When several RRs of the same type are available for a
+ particular owner name, the resolver should either cache them
+ all or none at all. When a response is truncated, and a
+ resolver doesn't know whether it has a complete set, it should
+ not cache a possibly partial set of RRs.
+
+ - Cached data should never be used in preference to
+ authoritative data, so if caching would cause this to happen
+ the data should not be cached.
+
+ - The results of an inverse query should not be cached.
+
+ - The results of standard queries where the QNAME contains "*"
+ labels if the data might be used to construct wildcards. The
+ reason is that the cache does not necessarily contain existing
+ RRs or zone boundary information which is necessary to
+ restrict the application of the wildcard RRs.
+
+ - RR data in responses of dubious reliability. When a resolver
+ receives unsolicited responses or RR data other than that
+ requested, it should discard it without caching it. The basic
+ implication is that all sanity checks on a packet should be
+ performed before any of it is cached.
+
+In a similar vein, when a resolver has a set of RRs for some name in a
+response, and wants to cache the RRs, it should check its cache for
+already existing RRs. Depending on the circumstances, either the data
+in the response or the cache is preferred, but the two should never be
+combined. If the data in the response is from authoritative data in the
+answer section, it is always preferred.
+
+8. MAIL SUPPORT
+
+The domain system defines a standard for mapping mailboxes into domain
+names, and two methods for using the mailbox information to derive mail
+routing information. The first method is called mail exchange binding
+and the other method is mailbox binding. The mailbox encoding standard
+and mail exchange binding are part of the DNS official protocol, and are
+the recommended method for mail routing in the Internet. Mailbox
+binding is an experimental feature which is still under development and
+subject to change.
+
+
+
+
+Mockapetris [Page 47]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+The mailbox encoding standard assumes a mailbox name of the form
+"<local-part>@<mail-domain>". While the syntax allowed in each of these
+sections varies substantially between the various mail internets, the
+preferred syntax for the ARPA Internet is given in [RFC-822].
+
+The DNS encodes the <local-part> as a single label, and encodes the
+<mail-domain> as a domain name. The single label from the <local-part>
+is prefaced to the domain name from <mail-domain> to form the domain
+name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
+NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
+<local-part> contains dots or other special characters, its
+representation in a master file will require the use of backslash
+quoting to ensure that the domain name is properly encoded. For
+example, the mailbox Action.domains@ISI.EDU would be represented as
+Action\.domains.ISI.EDU.
+
+8.1. Mail exchange binding
+
+Mail exchange binding uses the <mail-domain> part of a mailbox
+specification to determine where mail should be sent. The <local-part>
+is not even consulted. [RFC-974] specifies this method in detail, and
+should be consulted before attempting to use mail exchange support.
+
+One of the advantages of this method is that it decouples mail
+destination naming from the hosts used to support mail service, at the
+cost of another layer of indirection in the lookup function. However,
+the addition layer should eliminate the need for complicated "%", "!",
+etc encodings in <local-part>.
+
+The essence of the method is that the <mail-domain> is used as a domain
+name to locate type MX RRs which list hosts willing to accept mail for
+<mail-domain>, together with preference values which rank the hosts
+according to an order specified by the administrators for <mail-domain>.
+
+In this memo, the <mail-domain> ISI.EDU is used in examples, together
+with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
+ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
+route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
+VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
+addresses.
+
+8.2. Mailbox binding (Experimental)
+
+In mailbox binding, the mailer uses the entire mail destination
+specification to construct a domain name. The encoded domain name for
+the mailbox is used as the QNAME field in a QTYPE=MAILB query.
+
+Several outcomes are possible for this query:
+
+
+
+Mockapetris [Page 48]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ 1. The query can return a name error indicating that the mailbox
+ does not exist as a domain name.
+
+ In the long term, this would indicate that the specified
+ mailbox doesn't exist. However, until the use of mailbox
+ binding is universal, this error condition should be
+ interpreted to mean that the organization identified by the
+ global part does not support mailbox binding. The
+ appropriate procedure is to revert to exchange binding at
+ this point.
+
+ 2. The query can return a Mail Rename (MR) RR.
+
+ The MR RR carries new mailbox specification in its RDATA
+ field. The mailer should replace the old mailbox with the
+ new one and retry the operation.
+
+ 3. The query can return a MB RR.
+
+ The MB RR carries a domain name for a host in its RDATA
+ field. The mailer should deliver the message to that host
+ via whatever protocol is applicable, e.g., b,SMTP.
+
+ 4. The query can return one or more Mail Group (MG) RRs.
+
+ This condition means that the mailbox was actually a mailing
+ list or mail group, rather than a single mailbox. Each MG RR
+ has a RDATA field that identifies a mailbox that is a member
+ of the group. The mailer should deliver a copy of the
+ message to each member.
+
+ 5. The query can return a MB RR as well as one or more MG RRs.
+
+ This condition means the the mailbox was actually a mailing
+ list. The mailer can either deliver the message to the host
+ specified by the MB RR, which will in turn do the delivery to
+ all members, or the mailer can use the MG RRs to do the
+ expansion itself.
+
+In any of these cases, the response may include a Mail Information
+(MINFO) RR. This RR is usually associated with a mail group, but is
+legal with a MB. The MINFO RR identifies two mailboxes. One of these
+identifies a responsible person for the original mailbox name. This
+mailbox should be used for requests to be added to a mail group, etc.
+The second mailbox name in the MINFO RR identifies a mailbox that should
+receive error messages for mail failures. This is particularly
+appropriate for mailing lists when errors in member names should be
+reported to a person other than the one who sends a message to the list.
+
+
+
+Mockapetris [Page 49]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+New fields may be added to this RR in the future.
+
+
+9. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
+ Technical Plan - Name Service, April 1987, version 1.9.
+
+ Describes the fundamentals of the Hesiod name service.
+
+[IEN-116] J. Postel, "Internet Name Server", IEN-116,
+ USC/Information Sciences Institute, August 1979.
+
+ A name service obsoleted by the Domain Name System, but
+ still in use.
+
+[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
+ Communications of the ACM, October 1986, volume 29, number
+ 10.
+
+[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
+ Information Center, SRI International, December 1977.
+
+[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
+ USC/Information Sciences Institute, August 1980.
+
+[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
+ USC/Information Sciences Institute, September 1981.
+
+[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+ September 1981.
+
+ Suggests introduction of a hierarchy in place of a flat
+ name space for the Internet.
+
+[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
+ USC/Information Sciences Institute, February 1982.
+
+[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+ Internet Host Table Specification", RFC-810, Network
+ Information Center, SRI International, March 1982.
+
+ Obsolete. See RFC-952.
+
+[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
+ Server", RFC-811, Network Information Center, SRI
+ International, March 1982.
+
+
+
+
+Mockapetris [Page 50]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ Obsolete. See RFC-953.
+
+[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+ Network Information Center, SRI International, March
+ 1982.
+
+[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
+ Internet User Applications", RFC-819, Network
+ Information Center, SRI International, August 1982.
+
+ Early thoughts on the design of the domain system.
+ Current implementation is completely different.
+
+[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+ USC/Information Sciences Institute, August 1980.
+
+[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
+ RFC-830, Network Information Center, SRI International,
+ October 1982.
+
+ Early thoughts on the design of the domain system.
+ Current implementation is completely different.
+
+[RFC-882] P. Mockapetris, "Domain names - Concepts and
+ Facilities," RFC-882, USC/Information Sciences
+ Institute, November 1983.
+
+ Superceeded by this memo.
+
+[RFC-883] P. Mockapetris, "Domain names - Implementation and
+ Specification," RFC-883, USC/Information Sciences
+ Institute, November 1983.
+
+ Superceeded by this memo.
+
+[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
+ RFC-920, USC/Information Sciences Institute,
+ October 1984.
+
+ Explains the naming scheme for top level domains.
+
+[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
+ Table Specification", RFC-952, SRI, October 1985.
+
+ Specifies the format of HOSTS.TXT, the host/address
+ table replaced by the DNS.
+
+
+
+
+
+Mockapetris [Page 51]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+ RFC-953, SRI, October 1985.
+
+ This RFC contains the official specification of the
+ hostname server protocol, which is obsoleted by the DNS.
+ This TCP based protocol accesses information stored in
+ the RFC-952 format, and is used to obtain copies of the
+ host table.
+
+[RFC-973] P. Mockapetris, "Domain System Changes and
+ Observations", RFC-973, USC/Information Sciences
+ Institute, January 1986.
+
+ Describes changes to RFC-882 and RFC-883 and reasons for
+ them.
+
+[RFC-974] C. Partridge, "Mail routing and the domain system",
+ RFC-974, CSNET CIC BBN Labs, January 1986.
+
+ Describes the transition from HOSTS.TXT based mail
+ addressing to the more powerful MX system used with the
+ domain system.
+
+[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
+ service on a TCP/UDP transport: Concepts and Methods",
+ RFC-1001, March 1987.
+
+ This RFC and RFC-1002 are a preliminary design for
+ NETBIOS on top of TCP/IP which proposes to base NetBIOS
+ name service on top of the DNS.
+
+[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
+ service on a TCP/UDP transport: Detailed
+ Specifications", RFC-1002, March 1987.
+
+[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
+ USC/Information Sciences Institute, May 1987.
+
+ Contains socket numbers and mnemonics for host names,
+ operating systems, etc.
+
+[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+ November 1987.
+
+ Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
+ Administrators", RFC-1032, November 1987.
+
+
+
+Mockapetris [Page 52]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ Describes the registration policies used by the NIC to
+ administer the top level domains and delegate subzones.
+
+[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
+ RFC-1033, November 1987.
+
+ A cookbook for domain administrators.
+
+[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+ Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+ Describes a name service for CSNET which is independent
+ from the DNS and DNS use in the CSNET.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris [Page 53]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+Index
+
+ * 13
+
+ ; 33, 35
+
+ <character-string> 35
+ <domain-name> 34
+
+ @ 35
+
+ \ 35
+
+ A 12
+
+ Byte order 8
+
+ CH 13
+ Character case 9
+ CLASS 11
+ CNAME 12
+ Completion 42
+ CS 13
+
+ Hesiod 13
+ HINFO 12
+ HS 13
+
+ IN 13
+ IN-ADDR.ARPA domain 22
+ Inverse queries 40
+
+ Mailbox names 47
+ MB 12
+ MD 12
+ MF 12
+ MG 12
+ MINFO 12
+ MINIMUM 20
+ MR 12
+ MX 12
+
+ NS 12
+ NULL 12
+
+ Port numbers 32
+ Primary server 5
+ PTR 12, 18
+
+
+
+Mockapetris [Page 54]
+\f
+RFC 1035 Domain Implementation and Specification November 1987
+
+
+ QCLASS 13
+ QTYPE 12
+
+ RDATA 12
+ RDLENGTH 11
+
+ Secondary server 5
+ SOA 12
+ Stub resolvers 7
+
+ TCP 32
+ TXT 12
+ TYPE 11
+
+ UDP 32
+
+ WKS 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris [Page 55]
+\f
projects / user / henk / code / inspircd.git / blobdiff