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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 1
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 2
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 3
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 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
` |
` +---------+ |
` / /| |
` +---------+ | +----------+ | +--------+
` | | | | |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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 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 | 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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 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:
`
` 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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 7
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 8
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 9
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 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:
`
` 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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 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 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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 12
`
`

`

`
`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]
`
`AT&T Exhibit 1030
`AT&T v. VoIP, IPR 2017-01383
`Page 13
`
`

`

`
`RFC 1035 Domain Implementation and Specification November 1987
`
`3.3.1. CNAME RDATA format
`
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` /