Network Working Group
`Request for Comments: 1035
`
`Obsoletes: RFCs 882, 883, 973
`
`P. Mockapetris
`I81
`November 1987
`
`DOMAIN NAMES —
`
`IMPLEMENTATION AND SPECIFICATION
`
`l. 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
`3
`3
`
`4
`
`77 8
`
`9
`10
`10
`
`:0
`11
`11
`:2
`
`12
`:3
`
`
`
`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
`
`Mockapetris
`
`[Page 1]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 1
`
`Petitioner Apple Inc. - Exhibit 1037, p. 1
`
`

`

`RFC 1035
`
`Domain Implementation and Specification
`
`November 1987
`
`3.2.5. QCLASS values
`3.3. Standard RES
`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 RJATA 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
`
`13
`:3
`14
`14
`14
`15
`15
`16
`16
`17
`17
`
`
`
`1?
`18
`18
`19
`20
`
`20
`20
`21
`22
`
`24
`25
`25
`26
`28
`29
`
`30
`32
`32
`32
`33
`33
`35
`
`36
`37
`37
`3?
`37
`39
`
`39
`39
`40
`40
`41
`42
`
`Mockapetris
`
`[Page 2]
`
`PefifionerfiqnfleInc.-Exhflflt1037,p.2
`
`Petitioner Apple Inc. - Exhibit 1037, p. 2
`
`

`

`RFC 1035
`
`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
`4?
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 3
`
`Petitioner Apple Inc. - Exhibit 1037, p. 3
`
`

`

`RFC 1035
`
`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.
`
`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:
`
`Foreign
`
`Local Host
`
`|
`|
`+ ———————— +
`I
`+ —————————— +
`+ ————————— +
`I
`I
`I
`I
`Iqueries
`|
`I user queries
`I User
`| -------------- )I
`I --------- I-blForeign |
`| Program I
`| Resolver |
`|
`I
`Name
`|
`I
`I< -------------- I
`I< -------- I--I Server I
`|
`I user responsesl
`|responses|
`I
`|
`+ --------- +
`+ ---------- +
`I
`+ -------- +
`|
`A
`|
`cache additions I
`I
`references |
`V
`|
`|
`+ ---------- +
`I
`I
`cache
`I
`|
`+ —————————— +
`I
`
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 4
`
`Petitioner Apple Inc. - Exhibit 1037, p. 4
`
`

`

`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
`
`|
`|
`I
`+ ————————— +
`|
`/|
`/
`+ -------- +
`I
`+ ---------- +
`I
`+ ————————— +
`|
`|
`|
`lresponseSI
`|
`|
`|
`I
`| --------- |->|Foreign |
`I
`|
`I
`| Master
`| —————————————— >|
`|
`|
`IResolverl
`I
`files
`II
`I
`|< ———————— I——I
`I
`|
`|/
`|
`| queries |
`+ ———————— +
`+ --------- +
`+ ---------- +
`
`Name
`Server
`
`Here a primary name server vauires 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 vauire 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
`|
`I
`+ ————————— +
`|
`/|
`/
`+ ———————— +
`|
`+ —————————— +
`I
`+ ————————— +
`|
`|
`IresponSF-‘Sl
`|
`|
`|
`I
`I --------- |-) Foreign I
`I
`I
`I
`| Master
`I —————————————— >I
`I
`I
`ResolverI
`I
`tiles
`II
`I
`|< 77777777 I~
`I
`I
`I/
`I
`I queries I
`+ -------- +
`+ --------- +
`+ ---------- +
`
`Name
`Server
`
`
`
`+ -------- +
`Imaintenance |
`A
`I
`+ ———————————— |->
`I
`Foreign |
`queries
`|
`I
`Name
`|
`|
`I
`+ ------------------ I-- Server I
`maintenance responses I
`+ ———————— +
`
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 5
`
`Petitioner Apple Inc. - Exhibit 1037, p. 5
`
`

`

`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
`
`+ ————————— +
`
`+ —————————— +
`
`|
`
`I
`
`Foreign
`
`+ ———————— +
`
`I
`I
`I
`Iqueries
`I
`I user queries
`I
`I --------- I-blForeign I
`I -------------- )I
`I User
`I Program I
`I Resolver I
`I
`I
`Name
`I
`I
`I< -------------- I
`|< -------- |--| Server I
`|
`I user responsesl
`Iresponsesl
`I
`|
`+ ————————— +
`+ —————————— +
`I
`+ ———————— +
`|
`A
`|
`cache additions I
`I
`references I
`V
`|
`|
`+ ---------- +
`I
`I
`Shared
`I
`I
`I database I
`I
`+ ---------- +
`I
`A
`|
`|
`refreshes I
`I
`references |
`+ ————————— +
`|
`V
`|
`/J
`/
`+ -------- +
`+ ---------- +
`|
`I
`+ --------- +
`|
`|
`|
`IresponseSI
`I
`|
`I
`I
`I ————————— |—>IForeign I
`I
`I
`I
`I Master I -------------- a]
`I
`I
`IResolverI
`I
`files
`||
`|
`|< ———————— |--|
`I
`I
`I/
`I
`I queries I
`+ -------- +
`+ ————————— +
`+ —————————— +
`
`Name
`Server
`
`+ ———————— +
`Imaintenance I
`A
`+ ------------ |->|
`I
`I
`queries
`I
`IForeign I
`I
`I
`I
`Name
`I
`I
`+ ------------------ I--I Server I
`maintenance responses I
`+ -------- +
`
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 6
`
`Petitioner Apple Inc. - Exhibit 1037, p. 6
`
`

`

`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:
`
`Foreign
`
`Local Hosts
`
`|
`|
`|
`+ ————————— +
`I
`responses
`|
`J
`|
`| Stub
`]< -------------------- +
`|
`| Resolver|
`|
`|
`|
`I ---------------- +
`|
`|
`+ ————————— + recursive
`|
`|
`|
`queries
`|
`|
`|
`V
`l
`+ -------- +
`|
`+ ---------- +
`+ --------- + recursive
`|
`|
`|
`|
`|queries
`|
`J queries
`| Stub
`J -------------- >| Recursive| --------- |->|Foreign |
`| Resolverl
`| 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 T]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 7
`
`Petitioner Apple Inc. - Exhibit 1037, p. 7
`
`

`

`RFC 1035
`
`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 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> "." <1abel>
`
`alabel> ::= <letter> [
`
`[ dldh-Strb ] <let-dig) ]
`
`<ldh—str>
`
`= <let—dig—hyp> | <let—dig—hyp> <ldh—str>
`
`(let-dig-hyp) ::= clet-dig> I
`
`"-"
`
`<let-dig> ::= <letter> I <digit>
`
`<letter> ::= any one of the 52 alphabetic characters A through Z in
`upper case and a through 2
`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. 181 . 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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 8
`
`Petitioner Apple Inc. - Exhibit 1037, p. 8
`
`

`

`RFC 1035
`
`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
`1 2 3 4 5
`O
`9
`0 l 2 3 4 5 6 7 8
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-n
`
`2
`l
`1
`|
`+—+—+—+—+-+-+—+-+-+—+—+—+—+-+—+—+
`
`4
`|
`3
`|
`+—+—+—+—+-+-+-+-+-+-+-+-+-+-+-+-+
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-n
`
`|
`
`5
`
`|
`
`6
`
`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}.
`
`01234567
`+—+—+—+—+—+—+—+—+
`
`|10101010|
`+—+-+-+-+-+-+-+-+
`
`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.
`
`its original case should be
`when data enters the domain system,
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 9
`
`Petitioner Apple Inc. - Exhibit 1037, p. 9
`
`

`

`RFC 1035
`
`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 3.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.
`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
`
`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.
`
`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 ootets 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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 10
`
`Petitioner Apple Inc. - Exhibit 1037, p. 10
`
`

`

`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:
`
`l
`1
`l
`l
`l
`l
`5
`4
`3
`2
`1
`0
`9
`8
`7
`6
`5
`4
`3
`2
`1
`0
`+——+——+——+—-+——+—-+——+——+——+——+——+——+——+——+——+——+
`
`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]
`
`PefifionerfiqqfleIncu-Exhflflt1037,p.11
`
`Petitioner Apple Inc. - Exhibit 1037, p. 11
`
`

`

`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
`
`NS
`
`MD
`
`MF
`
`l a host address
`
`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
`
`30A
`
`MB
`
`MG
`
`MR
`
`NULL
`
`WKS
`
`PTR
`
`HINFO
`
`MINFO
`
`MK
`
`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)
`
`10 a null RR (EXPERIMENTAL)
`
`11 a well known service description
`
`12 a domain name pointer
`
`13 host information
`
`14 mailbox or mail list information
`
`15 mail exchange
`
`16 text strings
`
`3.2.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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 12
`
`Petitioner Apple Inc. - Exhibit 1037, p. 12
`
`

`

`RFC 1035
`
`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 (ME, MG or MR)
`
`254 A request for mail agent RRs
`
`(Obsolete — see MK)
`
`255 A request for all records
`
`3.2.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]
`
`3.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
`
`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.
`coharacter-string:
`is treated as binary information, and can be up to 256 characters in
`length (including the length octet).
`
`Mockapetris
`
`[Page 13]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 13
`
`Petitioner Apple Inc. - Exhibit 1037, p. 13
`
`

`

`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
`
`OS
`
`A <character-string> which specifies the CPU type.
`
`A <character-string: which specifies the operating
`system type.
`
`Standard values for CPU and 08 can be found in [RFC—1010].
`
`HINFO records are used to acquire general information about a host.
`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
`
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 14
`
`Petitioner Apple Inc. - Exhibit 1037, p. 14
`
`

`

`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.
`
`for details of
`See the definition of MK and [RFC—974]
`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 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.
`
`for details ofw
`See the definition of MK and [RFC-974]
`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]
`
`Petitioner Apple Inc. - Exhibit 1037, p. 15
`
`Petitioner Apple Inc. - Exhibit 1037, p. 15
`
`

`

`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
`
`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 cdomain-nameb 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]
`
`PefifionerfiqxfleIncu-Exhflflt1037,p.16
`
`Petitioner Apple Inc. - Exhibit 1037, p. 16
`
`

`

`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.
`
`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.
`
`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 1?]
`
`PefifionerfiqxfleIncu-Exhflflt1037,p.17
`
`Petitioner Apple Inc. - Exhibit 1037, p. 17
`
`

`

`RFC 1035
`
`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.
`
`3.3.11. NS RDATA format
`
`+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
`
`/
`/
`/
`/
`+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`NSDNAME
`
`where:
`
`NSDNAME
`
`A <domain—name> which specifies a host which should he
`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 <domainsname> 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]
`
`PefifionerfiqxfleIncu-Exhflflt1037,p.18
`
`Petitioner Apple Inc. - Exhibit 1037, p. 18
`
`

`

`RFC 1035
`
`Domain Implementation and Specification
`
`November 1987
`
`3.3.13. SOA RDATA format
`
`+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`/
`/
`/
`/
`+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`MNAME
`
`/
`RNAME
`/
`+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+——+
`
`|
`
`SERIAL
`
`+—-+-—+—-+--+