throbber
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
`
` +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
` /

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket