Network Working Group
`Request for Comments: 1035
`
`Obsoletes: RFCs—
`
`P. Mockapetris
`ISI
`November 1987
`
`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" [—].
`
`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
`2.
`INTRODUCTION
`2.1. Overview
`
`2.2. Common configurations
`2.3. Conventions
`
`2.3.1. Preferred name syntax
`2.3.2. Data Transmission Order
`2.3.3. Character Case
`2.3.4. Size limits
`3. DOMAIN NAME SPACE AND RR DEFINITIONS
`
`3.1. Name space definitions
`3.2. RR definitions
`3.2.1. Format
`3.2.2 TYPE values
`
`3.2.3. QTYPE values
`3.2 4
`CLASS values
`
`I
`3
`3
`
`4
`7
`
`7
`8
`9
`10
`10
`
`10
`11
`11
`12
`
`12
`13
`
`Mockapetris
`
`[Page 1]
`
`Page 1 of 55
`
`Verizon Exhibit 1015
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`3.2.5. QCLASS values
`3.3. Standard RRs
`3.3.1. CNAME RDATA format
`3.3.2. HINFO RDATA format
`3.3.3. MB RDATA format
`(EXPERIMENTAL)
`3.3.4. MD RDATA format
`(Obsolete)
`3.3.5. MF RDATA format
`(Obsolete)
`3.3.6. MG RDATA format
`(EXPERIMENTAL)
`3.3.7. MINFO RDATA format
`(EXPERIMENTAL)
`3.3.8. MR RDATA format
`(EXPERIMENTAL)
`3.3.9. MX RDATA format
`3.3.10. NULL RDATA format
`3.3.11. NS RDATA format
`3.3.12. PTR RDATA format
`3.3.13. SOA RDATA format
`3.3.14. TXT RDATA format
`
`(EXPERIMENTAL)
`
`3.4. ARPA Internet specific RRs
`3.4.1. A RDATA format
`3.4.2. WKS RDATA format
`IN—ADDR.ARPA domain
`
`3.5.
`
`3.6. Defining new types, classes, and special namespaces
`4. MESSAGES
`4.1. Format
`4.1.1. Header section format
`
`4.1.2. Question section format
`4.1.3. Resource record format
`
`4.1.4. Message compression
`4.2. Transport
`4.2.1. UDP usage
`4.2.2. TCP usage
`5. MASTER FILES
`5.1. Format
`5.2. Use of master files to define zones
`
`5.3. Master file example
`6. NAME SERVER IMPLEMENTATION
`6.1. Architecture
`6.1.1. Control
`6.1.2. Database
`6.1.3. Time
`
`6.2. Standard query processing
`6.3. Zone refresh and reload processing
`6.4.
`Inverse queries (Optional)
`6.4.1. The contents of inverse queries and responses
`6.4.2.
`Inverse query and response example
`6.4 3.
`Inverse query processing
`
`L3
`L3
`L4
`L4
`L4
`L5
`L5
`L6
`L6
`L7
`L7
`L7
`L8
`L8
`L9
`20
`
`20
`20
`21
`22
`
`24
`25
`25
`26
`
`28
`29
`
`30
`32
`32
`32
`33
`33
`35
`
`36
`37
`37
`37
`37
`39
`
`39
`39
`40
`40
`41
`42
`
`Mockapetris
`
`[Page 2]
`
`Page 2 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`6.5. Completion queries and responses
`7. RESOLVER IMPLEMENTATION
`
`7.1. Transforming a user request into a query
`7.2. Sending the queries
`7.3. Processing responses
`7.4. Using the cache
`8. MAIL SUPPORT
`
`8.1. Mail exchange binding
`8.2. Mailbox binding (Experimental)
`9. REFERENCES and BIBLIOGRAPHY
`Index
`
`2.
`
`INTRODUCTION
`
`2.1. Overview
`
`42
`43
`
`43
`44
`46
`47
`47
`
`48
`48
`50
`54
`
`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.
`
`the database that makes up the domain
`From the resolver’s point of view,
`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.
`
`The first kind of data held in
`Name servers manage two kinds of data.
`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]
`
`Page 3 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`The second
`from master files stored locally or in another name server.
`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.
`
`Common configurations
`
`st 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
`
`+ — — — — — — ——+
`
`|
`|
`|queries
`|
`| user queries
`|
`1 ------- -- ->1Foreign 1
`1 ------------ -->1
`user
`1
`|
`|
`Name
`|
`| Program |
`| Resolver
`1< ------ -- --1 server 1
`1
`1< ------------ --1
`|responses
`|
`|
`|
`| user responses|
`+ — — — — — — — ——+
`+ — — — — — — — — ——+
`+ — — — — — — ——+
`
`A
`|
`|
`cache additions |
`1
`v
`+ — — — — — — — — ——+
`
`references
`
`|
`cache
`|
`+ — — — — — — — — ——+
`
`User programs interact with the domain name space through resolvers;
`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.
`
`the
`
`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]
`
`Page 4 of 55
`
`

`

`‘ 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
`
`+ — — — — — — — ——+
`
`/I
`/
`+ — — — — — — ——+
`+ — — — — — — — — ——+
`|
`+ — — — — — — — ——+
`|
`|
`|
`|responses
`|
`|
`|
`|
`| — — — — — — — —— —>|Foreign |
`|
`|
`|
`| Master
`| — — — — — — — — — — — — ——>|
`|
`|Resolver|
`1
`files
`1
`1
`1
`1< ------ -- --1
`1
`|
`|/
`|
`| queries
`+ — — — — — — ——+
`+ — — — — — — — ——+
`+ — — — — — — — — ——+
`
`Name
`Server
`
`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
`
`+ — — — — — — — ——+
`
`/I
`/
`+ — — — — — — ——+
`+ — — — — — — — — ——+
`|
`+ — — — — — — — ——+
`|
`|
`|
`|responses
`|
`|
`|
`|
`| — — — — — — — —— —>|Foreign |
`|
`|
`|
`| Master
`| — — — — — — — — — — — — ——>|
`|
`|Resolver|
`1
`files
`1
`1
`1
`1< ------ -- --1
`1
`|
`|/
`|
`| queries
`+ — — — — — — ——+
`+ — — — — — — — ——+
`+ — — — — — — — — ——+
`
`Name
`Server
`
`+ — — — — — — ——+
`|maintenance
`A
`+ ---------- -- ->1
`1
`1
`queries
`|Foreign |
`|
`|
`Name
`|
`|
`+ — — — — — — — — — — — — — — — — —— ——| Server
`|
`maintenance responses
`+ — — — — — — ——+
`
`the name server periodically establishes a
`In this configuration,
`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]
`
`Page 5 of 55
`
`

`

`‘ 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
`
`+ — — — — — — ——+
`
`|
`|
`|queries
`|
`| user queries
`|
`1 ------- -- ->1Fereign 1
`1 ------------ -->1
`user
`1
`|
`|
`Name
`|
`| Program |
`| Resolver
`1< ------ -- --1 server 1
`1
`1< ------------ --1
`|responses
`|
`|
`|
`| user responses|
`+ — — — — — — — ——+
`+ — — — — — — — — ——+
`+ — — — — — — ——+
`
`A
`|
`|
`cache additions |
`1
`v
`+ — — — — — — — — ——+
`
`references
`
`|
`Shared
`|
`| database |
`+ — — — — — — — — ——+
`
`references
`
`1
`A
`|
`refreshes |
`+ — — — — — — — ——+
`V
`|
`/|
`/
`+ — — — — — — ——+
`+ — — — — — — — — ——+
`|
`+ — — — — — — — ——+
`|
`-
`|
`|
`|responses
`|
`|
`|
`|
`| — — — — — — — —— —>|Foreign |
`|
`|
`|
`| Master
`| — — — — — — — — — — — — ——>|
`|
`|Resolver|
`1 mes
`1
`1
`1
`1< ------ -- --1
`1
`|
`|/
`|
`| queries
`+ — — — — — — ——+
`+ — — — — — — — ——+
`+ — — — — — — — — ——+
`
`Name
`Server
`
`|maintenance
`----- --
`queries
`
`+ — — — — — — ——+
`A
`->1
`_
`1
`1
`|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]
`
`Page 6 of 55
`
`

`

`‘ 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
`|
`|
`|< ------------------
`I stub
`| Resolver|
`I
`I --------------
`+ — — — — — — — ——+ recursive
`queries
`
`|
`I
`|
`|
`|
`|
`I
`v
`+ — — — — — — — — ——+
`
`+ — — — — — — — ——+ recursive
`
`+ — — — — — — ——+
`
`|
`|
`|queries
`|
`| queries
`|
`| — — — — — — — — — — — — ——>| Recursive| — — — — — — — —— —>|Foreign |
`| Stub
`| Resolver|
`| Server
`|
`|
`Name
`|
`I
`|< ------------ --I
`|< ------ -- --I server I
`+ — — — — — — — ——+ 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.
`
`‘.1. Preferred name syntax
`
`to be as general as possible in the rules
`The DNS specifications attempt
`The idea is that the name of any
`for constructing domain names.
`existing object can be expressed as a domain name with minimal changes.
`
`Mockapetris
`
`[Page 7]
`
`Page 7 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`the prudent user
`However, when assigning a domain name for an object,
`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.
`
`the user should satisfy both the
`For example, when naming a mail domain,
`rules of this memo and those in_ 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.
`
`They must
`The labels must follow the rules for ARPANET host names.
`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. 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]
`
`Page 8 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`the order of transmission of those octets is the normal
`group of octets,
`order in which they are read in English.
`For example,
`in the following
`diagram,
`the octets are transmitted in the order they are numbered.
`
`1
`0
`4 5
`6 7 8 9 O 1 2 3
`O 1 2 3 4 5
`+—+—+—+—+—+—+—+—+—+—+-+—+—+—+—+—+
`
`I
`2
`I
`1
`I
`+—+—+—+—+—+—+—+—+—+—+-+—+—+—+—+—+
`
`I
`4
`I
`3
`I
`+—+—+—+—+—+—+—+—+—+—+-+—+—+—+—+—+
`
`I
`6
`I
`5
`I
`+—+—+—+—+—+—+—+—+—+—+-+—+—+—+—+—+
`
`the left most bit in
`Whenever an octet represents a numeric quantity,
`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).
`
`6 7
`0 1 2 3 4 5
`+-+-+-+-+-+-+-+-+
`
`|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.
`
`‘.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]
`
`Page 9 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`Thus while data for x.y
`Loss of case sensitive data must be minimized.
`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. 4. Size limits
`
`Various objects and parameters in the DNS have size limits.
`listed below.
`Some could be easily changed, others are more
`fundamental.
`
`They are
`
`labels
`
`names
`
`63 octets or less
`
`255 octets or less
`
`TTL
`
`positive values of a signed 32 bit number.
`
`UDP messages
`
`512 octets or less
`
`-. DOMAIN NAME SPACE AND RR DEFINITIONS
`
`-. 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.
`
`the total length of a domain name (i.e.,
`To simplify implementations,
`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]
`
`Page 10 of 55
`
`

`

`Domain Implementation and Specification
`
`November 1987
`
`
`
`efinitions
`
`rmat
`
`All RRs have the same top level format shown below:
`
`l
`l
`l
`l
`l
`l
`5
`4
`3
`2
`1
`O
`9
`8
`7
`6
`5
`4
`3
`2
`1
`O
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`/
`
`NAME
`
`/
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`TYPE
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`CLASS
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`TTL
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`RDLENGTH
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——
`
`/
`/
`/
`/
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`RDATA
`
`where:
`
`NAME
`
`TYPE
`
`CLASS
`
`TTL
`
`the name of the node to which this
`an owner name, i.e.,
`resource record pertains.
`
`two octets containing one of the RR TYPE codes.
`
`two octets containing one of the RR CLASS codes.
`
`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]
`
`Page 11 of 55
`
`

`

`‘ 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.
`
`.2. TYPE values
`
`fields are used in resource records. Note that these types are a
`et of QTYPEs.
`
`value and meaning
`
`1 a host address
`
`NS
`
`MD
`
`MF
`
`2 an authoritative name server
`
`3 a mail destination (Obsolete — use MX)
`
`4 a mail forwarder
`
`(Obsolete — use MX)
`
`CNAME
`
`5
`
`the canonical name for an alias
`
`SOA
`
`MB
`
`MG
`
`MR
`
`NULL
`
`WKS
`
`PTR
`
`HINFO
`
`MINFO
`
`MX
`
`TXT
`
`6 marks the start of a zone of authority
`
`7 a mailbox domain name
`
`(EXPERIMENTAL)
`
`8 a mail group member
`
`(EXPERIMENTAL)
`
`9 a mail rename domain name
`
`(EXPERIMENTAL)
`
`LO a null RR (EXPERIMENTAL)
`
`L1 a well known service description
`
`L2 a domain name pointer
`
`L3 host
`
`information
`
`L4 mailbox or mail list information
`
`L5 mail exchange
`
`L6 text strings
`
`‘.3. QTYPE values
`
`QTYPE fields appear in the question part of a query.
`superset of TYPEs, hence all TYPEs are valid QTYPEs.
`following QTYPEs are defined:
`
`QTYPES are a
`In addition,
`
`the
`
`Mockapetris
`
`[Page 12]
`
`Page 12 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`AXFR
`
`MAILB
`
`MAILA
`
`*
`
`252 A request for a transfer of an entire zone
`
`253 A request for mailbox—related records (MB, MG or MR)
`
`254 A request for mail agent RRs
`
`(Obsolete — see MX)
`
`255 A request for all records
`
`‘.4. CLASS values
`
`CLASS fields appear in resource records.
`and values are defined:
`
`The following CLASS mnemonics
`
`IN
`
`CS
`
`CH
`
`HS
`
`1 the Internet
`
`2 the CSNET class (Obsolete — used only for examples in
`some obsolete RFCs)
`
`3
`
`the CHAOS class
`
`4 Hesiod [Dyer 87]
`
`2. 5. QCLASS values
`
`QCLASS values
`QCLASS fields appear in the question section of a query.
`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
`
`- 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]
`
`Page 13 of 55
`
`

`

`Domain Implementation and Specification
`
`November 1987
`
`AME RDATA format
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`CNAM E
`
`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 [—] for details.
`
`-.2. HINFO RDATA format
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`CPU
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`/
`OS
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`where:
`
`CPU
`
`OS
`
`A <character—string> which specifies the CPU type.
`
`A <character—string> which specifies the operating
`system type.
`
`Standard values for CPU and OS can be found in [—.
`
`information about a host.
`HINFO records are used to acquire general
`main use is for protocols such as FTP that can use special procedures
`when talking between machines or operating systems of the same type.
`
`The
`
`(EXPERIMENTAL)
`3.'.3. MB RDATA format
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`MADNAME
`
`where:
`
`MADNAME
`
`A <domain—name> which specifies a host which has the
`specified mailbox.
`
`Mockapetris
`
`[Page 14]
`
`Page 14 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`MB records cause additional section processing which looks up an A type
`RRs corresponding to MADNAME.
`
`(Obsolete)
`3.'.4. MD RDATA format
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`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.
`
`See the definition of MX and _] for details of
`MD is obsolete.
`The recommended policy for dealing with MD RRs found in
`the new scheme.
`a master file is to reject them, or to convert
`them to MX RRs with a
`preference of O.
`
`— 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.
`
`See the definition of MX and [_] for details ofw
`MF is obsolete.
`The recommended policy for dealing with MD RRs found in
`the new scheme.
`a master file is to reject them, or to convert
`them to MX RRs with a
`preference of 10.
`
`Mockapetris
`
`[Page 15]
`
`Page 15 of 55
`
`

`

`Domain Implementation and Specification
`
`November 1987
`
`RDATA format
`
`(EXPERIMENTAL)
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`MGMNAME
`
`where:
`
`MGMAME
`
`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
`
`EMAILBX
`
`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.
`
`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]
`
`Page 16 of 55
`
`

`

`Domain Implementation and Specification
`
`November 1987
`
`RDATA format
`
`(EXPERIMENTAL)
`
`+——+——+-‘+——+——+——+——+——+——+-—+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`NEWNAME
`
`where:
`
`NEWNAME
`
`A <domain—name> which specifies a mailbox which is the
`proper rename of the specified mailbox.
`
`The main use for MR
`MR records cause no additional section processing.
`is as a forwarding entry for a user who has moved to a different
`mailbox.
`
`- 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
`].
`
`
`
` LL 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]
`
`Page 17 of 55
`
`

`

`‘ Domain Implementation and Specification
`
`November 1987
`
`NULL RRs are not
`NULL records cause no additional section processing.
`allowed in master files.
`NULLs are used as placeholders in some
`experimental extensions of the DNS.
`
`-1. 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.
`
`2. PTR RDATA format
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`/
`PTRDNAME
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`where:
`
`PTRDNAME
`
`A <domain—name> which points to some location in the
`domain name space.
`
`These RRs are used
`PTR records cause no additional section processing.
`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]
`
`Page 18 of 55
`
`

`

`Domain Implementation and Specification
`
`November 1987
`
`OA RDATA format
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`MAME
`
`/
`RNAME
`/
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`SERIAL
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`REFRESH
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`RETRY
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`EXPIRE
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`MINIMUM
`
`+——+——+-—+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`where:
`
`MNAME
`
`RNAME
`
`SERIAL
`
`REFRESH
`
`RETRY
`
`EXPIRE
`
`The <domain—name> of the name server that was the
`
`original or primary source of data for this zone.
`
`A <domain—name> which specifies the mailbox of the
`person responsible for this zone.
`
`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.
`
`A 32 bit time interval before the zone should be
`refreshed.
`
`A 32 bit time interval that should elapse before a
`failed refresh should be retried.
`
`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]
`
`Page 19 of 55
`
`

`

`‘ 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
`