throbber
Network Working Group P. Mockapetris
`Request for Comments: 1034 ISI
`Obsoletes: RFCs 882, 883, 973 November 1987
`
` DOMAIN NAMES - CONCEPTS AND FACILITIES
`
`1. STATUS OF THIS MEMO
`
`This RFC is an introduction to the Domain Name System (DNS), and omits
`many details which can be found in a companion RFC, "Domain Names -
`Implementation and Specification" [RFC-1035]. That RFC assumes that the
`reader is familiar with the concepts discussed in this memo.
`
`A subset of DNS functions and data types constitute an official
`protocol. The official protocol includes standard queries and their
`responses and most of the Internet class data formats (e.g., host
`addresses).
`
`However, the domain system is intentionally extensible. Researchers are
`continuously proposing, implementing and experimenting with new data
`types, query types, classes, functions, etc. Thus while the components
`of the official protocol are expected to stay essentially unchanged and
`operate as a production service, experimental behavior should always be
`expected in extensions beyond the official protocol. 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.
`
`2. INTRODUCTION
`
`This RFC introduces domain style names, their use for Internet mail and
`host address support, and the protocols and servers used to implement
`domain name facilities.
`
`2.1. The history of domain names
`
`The impetus for the development of the domain system was growth in the
`Internet:
`
` - Host name to address mappings were maintained by the Network
` Information Center (NIC) in a single file (HOSTS.TXT) which
` was FTPed by all hosts [RFC-952, RFC-953]. The total network
`
`Mockapetris [Page 1]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 1
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
` bandwidth consumed in distributing a new version by this
` scheme is proportional to the square of the number of hosts in
` the network, and even when multiple levels of FTP are used,
` the outgoing FTP load on the NIC host is considerable.
` Explosive growth in the number of hosts didn’t bode well for
` the future.
`
` - The network population was also changing in character. The
` timeshared hosts that made up the original ARPANET were being
` replaced with local networks of workstations. Local
` organizations were administering their own names and
` addresses, but had to wait for the NIC to change HOSTS.TXT to
` make changes visible to the Internet at large. Organizations
` also wanted some local structure on the name space.
`
` - The applications on the Internet were getting more
` sophisticated and creating a need for general purpose name
` service.
`
`The result was several ideas about name spaces and their management
`[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a
`common thread was the idea of a hierarchical name space, with the
`hierarchy roughly corresponding to organizational structure, and names
`using "." as the character to mark the boundary between hierarchy
`levels. A design using a distributed database and generalized resources
`was described in [RFC-882, RFC-883]. Based on experience with several
`implementations, the system evolved into the scheme described in this
`memo.
`
`The terms "domain" or "domain name" are used in many contexts beyond the
`DNS described here. Very often, the term domain name is used to refer
`to a name with structure indicated by dots, but no relation to the DNS.
`This is particularly true in mail addressing [Quarterman 86].
`
`2.2. DNS design goals
`
`The design goals of the DNS influence its structure. They are:
`
` - The primary goal is a consistent name space which will be used
` for referring to resources. In order to avoid the problems
` caused by ad hoc encodings, names should not be required to
` contain network identifiers, addresses, routes, or similar
` information as part of the name.
`
` - The sheer size of the database and frequency of updates
` suggest that it must be maintained in a distributed manner,
` with local caching to improve performance. Approaches that
`
`Mockapetris [Page 2]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 2
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
` attempt to collect a consistent copy of the entire database
` will become more and more expensive and difficult, and hence
` should be avoided. The same principle holds for the structure
` of the name space, and in particular mechanisms for creating
` and deleting names; these should also be distributed.
`
` - Where there tradeoffs between the cost of acquiring data, the
` speed of updates, and the accuracy of caches, the source of
` the data should control the tradeoff.
`
` - The costs of implementing such a facility dictate that it be
` generally useful, and not restricted to a single application.
` We should be able to use names to retrieve host addresses,
` mailbox data, and other as yet undetermined information. All
` data associated with a name is tagged with a type, and queries
` can be limited to a single type.
`
` - Because we want the name space to be useful in dissimilar
` networks and applications, we provide the ability to use the
` same name space with different protocol families or
` management. For example, host address formats differ between
` protocols, though all protocols have the notion of address.
` The DNS tags all data with a class as well as the type, so
` that we can allow parallel use of different formats for data
` of type address.
`
` - We want name server transactions to be independent of the
` communications system that carries them. Some systems may
` wish to use datagrams for queries and responses, and only
` establish virtual circuits for transactions that need the
` reliability (e.g., database updates, long transactions); other
` systems will use virtual circuits exclusively.
`
` - The system should be useful across a wide spectrum of host
` capabilities. Both personal computers and large timeshared
` hosts should be able to use the system, though perhaps in
` different ways.
`
`2.3. Assumptions about usage
`
`The organization of the domain system derives from some assumptions
`about the needs and usage patterns of its user community and is designed
`to avoid many of the the complicated problems found in general purpose
`database systems.
`
`The assumptions are:
`
` - The size of the total database will initially be proportional
`
`Mockapetris [Page 3]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 3
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
` to the number of hosts using the system, but will eventually
` grow to be proportional to the number of users on those hosts
` as mailboxes and other information are added to the domain
` system.
`
` - Most of the data in the system will change very slowly (e.g.,
` mailbox bindings, host addresses), but that the system should
` be able to deal with subsets that change more rapidly (on the
` order of seconds or minutes).
`
` - The administrative boundaries used to distribute
` responsibility for the database will usually correspond to
` organizations that have one or more hosts. Each organization
` that has responsibility for a particular set of domains will
` provide redundant name servers, either on the organization’s
` own hosts or other hosts that the organization arranges to
` use.
`
` - Clients of the domain system should be able to identify
` trusted name servers they prefer to use before accepting
` referrals to name servers outside of this "trusted" set.
`
` - Access to information is more critical than instantaneous
` updates or guarantees of consistency. Hence the update
` process allows updates to percolate out through the users of
` the domain system rather than guaranteeing that all copies are
` simultaneously updated. When updates are unavailable due to
` network or host failure, the usual course is to believe old
` information while continuing efforts to update it. The
` general model is that copies are distributed with timeouts for
` refreshing. The distributor sets the timeout value and the
` recipient of the distribution is responsible for performing
` the refresh. In special situations, very short intervals can
` be specified, or the owner can prohibit copies.
`
` - In any system that has a distributed database, a particular
` name server may be presented with a query that can only be
` answered by some other server. The two general approaches to
` dealing with this problem are "recursive", in which the first
` server pursues the query for the client at another server, and
` "iterative", in which the server refers the client to another
` server and lets the client pursue the query. Both approaches
` have advantages and disadvantages, but the iterative approach
` is preferred for the datagram style of access. The domain
` system requires implementation of the iterative approach, but
` allows the recursive approach as an option.
`
`Mockapetris [Page 4]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 4
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`The domain system assumes that all data originates in master files
`scattered through the hosts that use the domain system. These master
`files are updated by local system administrators. Master files are text
`files that are read by a local name server, and hence become available
`through the name servers to users of the domain system. The user
`programs access name servers through standard programs called resolvers.
`
`The standard format of master files allows them to be exchanged between
`hosts (via FTP, mail, or some other mechanism); this facility is useful
`when an organization wants a domain, but doesn’t want to support a name
`server. The organization can maintain the master files locally using a
`text editor, transfer them to a foreign host which runs a name server,
`and then arrange with the system administrator of the name server to get
`the files loaded.
`
`Each host’s name servers and resolvers are configured by a local system
`administrator [RFC-1033]. For a name server, this configuration data
`includes the identity of local master files and instructions on which
`non-local master files are to be loaded from foreign servers. The name
`server uses the master files or copies to load its zones. For
`resolvers, the configuration data identifies the name servers which
`should be the primary sources of information.
`
`The domain system defines procedures for accessing the data and for
`referrals to other name servers. The domain system also defines
`procedures for caching retrieved data and for periodic refreshing of
`data defined by the system administrator.
`
`The system administrators provide:
`
` - The definition of zone boundaries.
`
` - Master files of data.
`
` - Updates to master files.
`
` - Statements of the refresh policies desired.
`
`The domain system provides:
`
` - Standard formats for resource data.
`
` - Standard methods for querying the database.
`
` - Standard methods for name servers to refresh local data from
` foreign name servers.
`
`Mockapetris [Page 5]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 5
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`2.4. Elements of the DNS
`
`The DNS has three major components:
`
` - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
` specifications for a tree structured name space and data
` associated with the names. Conceptually, each node and leaf
` of the domain name space tree names a set of information, and
` query operations are attempts to extract specific types of
` information from a particular set. A query names the domain
` name of interest and describes the type of resource
` information that is desired. For example, the Internet
` uses some of its domain names to identify hosts; queries for
` address resources return Internet host addresses.
`
` - NAME SERVERS are server programs which hold information about
` the domain tree’s structure and set information. A name
` server may cache structure or set information about any part
` of the domain tree, but in general a particular name server
` has complete information about a subset of the domain space,
` and pointers to other name servers that can be used to lead to
` information from any part of the domain tree. Name servers
` know the parts of the domain tree for which they have complete
` information; a name server is said to be an AUTHORITY for
` these parts of the name space. Authoritative information is
` organized into units called ZONEs, and these zones can be
` automatically distributed to the name servers which provide
` redundant service for the data in a zone.
`
` - RESOLVERS are programs that extract information from name
` servers in response to client requests. Resolvers must be
` able to access at least one name server and use that name
` server’s information to answer a query directly, or pursue the
` query using referrals to other name servers. A resolver will
` typically be a system routine that is directly accessible to
` user programs; hence no protocol is necessary between the
` resolver and the user program.
`
`These three components roughly correspond to the three layers or views
`of the domain system:
`
` - From the user’s point of view, the domain system is accessed
` through a simple procedure or OS call to a local resolver.
` The domain space consists of a single tree and the user can
` request information from any section of the tree.
`
` - From the resolver’s point of view, the domain system is
` composed of an unknown number of name servers. Each name
`
`Mockapetris [Page 6]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 6
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
` server has one or more pieces of the whole domain tree’s data,
` but the resolver views each of these databases as essentially
` static.
`
` - From a name server’s point of view, the domain system consists
` of separate sets of local information called zones. The name
` server has local copies of some of the zones. The name server
` must periodically refresh its zones from master copies in
` local files or foreign name servers. The name server must
` concurrently process queries that arrive from resolvers.
`
`In the interests of performance, implementations may couple these
`functions. For example, a resolver on the same machine as a name server
`might share a database consisting of the the zones managed by the name
`server and the cache managed by the resolver.
`
`3. DOMAIN NAME SPACE and RESOURCE RECORDS
`
`3.1. Name space specifications and terminology
`
`The domain name space is a tree structure. Each node and leaf on the
`tree corresponds to a resource set (which may be empty). The domain
`system makes no distinctions between the uses of the interior nodes and
`leaves, and this memo uses the term "node" to refer to both.
`
`Each node has a label, which is zero to 63 octets in length. Brother
`nodes may not have the same label, although the same label can be used
`for nodes which are not brothers. One label is reserved, and that is
`the null (i.e., zero length) label used for the root.
`
`The domain name of a node is the list of the labels on the path from the
`node to the root of the tree. By convention, the labels that compose a
`domain name are printed or read left to right, from the most specific
`(lowest, farthest from the root) to the least specific (highest, closest
`to the root).
`
`Internally, programs that manipulate domain names should represent them
`as sequences of labels, where each label is a length octet followed by
`an octet string. Because all domain names end at the root, which has a
`null string for a label, these internal representations can use a length
`byte of zero to terminate a domain name.
`
`By convention, domain names can be stored with arbitrary case, but
`domain name comparisons for all present domain functions are done in a
`case-insensitive manner, assuming an ASCII character set, and a high
`order zero bit. This means that you are free to create a node with
`label "A" or a node with label "a", but not both as brothers; you could
`refer to either using "a" or "A". When you receive a domain name or
`
`Mockapetris [Page 7]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 7
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`label, you should preserve its case. The rationale for this choice is
`that we may someday need to add full binary domain names for new
`services; existing services would not be changed.
`
`When a user needs to type a domain name, the length of each label is
`omitted and the labels are separated by dots ("."). Since a complete
`domain name ends with the root label, this leads to a printed form which
`ends in a dot. We use this property to distinguish between:
`
` - a character string which represents a complete domain name
` (often called "absolute"). For example, "poneria.ISI.EDU."
`
` - a character string that represents the starting labels of a
` domain name which is incomplete, and should be completed by
` local software using knowledge of the local domain (often
` called "relative"). For example, "poneria" used in the
` ISI.EDU domain.
`
`Relative names are either taken relative to a well known origin, or to a
`list of domains used as a search list. Relative names appear mostly at
`the user interface, where their interpretation varies from
`implementation to implementation, and in master files, where they are
`relative to a single origin domain name. The most common interpretation
`uses the root "." as either the single origin or as one of the members
`of the search list, so a multi-label relative name is often one where
`the trailing dot has been omitted to save typing.
`
`To simplify implementations, the total number of octets that represent a
`domain name (i.e., the sum of all label octets and label lengths) is
`limited to 255.
`
`A domain is identified by a domain name, and consists of that part of
`the domain name space that is at or below the domain name which
`specifies the domain. A domain is a subdomain of another domain if it
`is contained within that domain. This relationship can be tested by
`seeing if the subdomain’s name ends with the containing domain’s name.
`For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
`
`3.2. Administrative guidelines on use
`
`As a matter of policy, the DNS technical specifications do not mandate a
`particular tree structure or rules for selecting labels; its goal is to
`be as general as possible, so that it can be used to build arbitrary
`applications. In particular, the system was designed so that the name
`space did not have to be organized along the lines of network
`boundaries, name servers, etc. The rationale for this is not that the
`name space should have no implied semantics, but rather that the choice
`of implied semantics should be left open to be used for the problem at
`
`Mockapetris [Page 8]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 8
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`hand, and that different parts of the tree can have different implied
`semantics. For example, the IN-ADDR.ARPA domain is organized and
`distributed by network and host address because its role is to translate
`from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
`1002] are flat because that is appropriate for that application.
`
`However, there are some guidelines that apply to the "normal" parts of
`the name space used for hosts, mailboxes, etc., that will make the name
`space more uniform, provide for growth, and minimize problems as
`software is converted from the older host table. The political
`decisions about the top levels of the tree originated in RFC-920.
`Current policy for the top levels is discussed in [RFC-1032]. MILNET
`conversion issues are covered in [RFC-1031].
`
`Lower domains which will eventually be broken into multiple zones should
`provide branching at the top of the domain so that the eventual
`decomposition can be done without renaming. Node labels which use
`special characters, leading digits, etc., are likely to break older
`software which depends on more restrictive choices.
`
`3.3. Technical guidelines on use
`
`Before the DNS can be used to hold naming information for some kind of
`object, two needs must be met:
`
` - A convention for mapping between object names and domain
` names. This describes how information about an object is
` accessed.
`
` - RR types and data formats for describing the object.
`
`These rules can be quite simple or fairly complex. Very often, the
`designer must take into account existing formats and plan for upward
`compatibility for existing usage. Multiple mappings or levels of
`mapping may be required.
`
`For hosts, the mapping depends on the existing syntax for host names
`which is a subset of the usual text representation for domain names,
`together with RR formats for describing host addresses, etc. Because we
`need a reliable inverse mapping from address to host name, a special
`mapping for addresses into the IN-ADDR.ARPA domain is also defined.
`
`For mailboxes, the mapping is slightly more complex. The usual mail
`address <local-part>@<mail-domain> is mapped into a domain name by
`converting <local-part> into a single label (regardles of dots it
`contains), converting <mail-domain> into a domain name using the usual
`text format for domain names (dots denote label breaks), and
`concatenating the two to form a single domain name. Thus the mailbox
`
`Mockapetris [Page 9]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 9
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
`HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this
`design also must take into account the scheme for mail exchanges [RFC-
`974].
`
`The typical user is not concerned with defining these rules, but should
`understand that they usually are the result of numerous compromises
`between desires for upward compatibility with old usage, interactions
`between different object definitions, and the inevitable urge to add new
`features when defining the rules. The way the DNS is used to support
`some object is often more crucial than the restrictions inherent in the
`DNS.
`
`3.4. Example name space
`
`The following figure shows a part of the current domain name space, and
`is used in many examples in this RFC. Note that the tree is a very
`small subset of the actual name space.
`
` |
` |
` +---------------------+------------------+
` | | |
` MIL EDU ARPA
` | | |
` | | |
` +-----+-----+ | +------+-----+-----+
` | | | | | | |
` BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
` |
` +--------+------------------+---------------+--------+
` | | | | |
` UCI MIT | UDEL YALE
` | ISI
` | |
` +---+---+ |
` | | |
` LCS ACHILLES +--+-----+-----+--------+
` | | | | | |
` XX A C VAXA VENERA Mockapetris
`
`In this example, the root domain has three immediate subdomains: MIL,
`EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named
`XX.LCS.MIT.EDU. All of the leaves are also domains.
`
`3.5. Preferred name syntax
`
`The DNS specifications attempt to be as general as possible in the rules
`
`Mockapetris [Page 10]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 10
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`for constructing domain names. The idea is that the name of any
`existing object can be expressed as a domain name with minimal changes.
`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
`
`3.6. Resource Records
`
`A domain name identifies a node. Each node has a set of resource
`
`Mockapetris [Page 11]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 11
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`information, which may be empty. The set of resource information
`associated with a particular name is composed of separate resource
`records (RRs). The order of RRs in a set is not significant, and need
`not be preserved by name servers, resolvers, or other parts of the DNS.
`
`When we talk about a specific RR, we assume it has the following:
`
`owner which is the domain name where the RR is found.
`
`type which is an encoded 16 bit value that specifies the type
` of the resource in this resource record. Types refer to
` abstract resources.
`
` This memo uses the following types:
`
` A a host address
`
` CNAME identifies the canonical name of an
` alias
`
` HINFO identifies the CPU and OS used by a host
`
` MX identifies a mail exchange for the
` domain. See [RFC-974 for details.
`
` NS
` the authoritative name server for the domain
`
` PTR
` a pointer to another part of the domain name space
`
` SOA
` identifies the start of a zone of authority]
`
`class which is an encoded 16 bit value which identifies a
` protocol family or instance of a protocol.
`
` This memo uses the following classes:
`
` IN the Internet system
`
` CH the Chaos system
`
`TTL which is the time to live of the RR. This field is a 32
` bit integer in units of seconds, an is primarily used by
` resolvers when they cache RRs. The TTL describes how
` long a RR can be cached before it should be discarded.
`
`Mockapetris [Page 12]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 12
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`RDATA which is the type and sometimes class dependent data
` which describes the resource:
`
` A For the IN class, a 32 bit IP address
`
` For the CH class, a domain name followed
` by a 16 bit octal Chaos address.
`
` CNAME a domain name.
`
` MX a 16 bit preference value (lower is
` better) followed by a host name willing
` to act as a mail exchange for the owner
` domain.
`
` NS a host name.
`
` PTR a domain name.
`
` SOA several fields.
`
`The owner name is often implicit, rather than forming an integral part
`of the RR. For example, many name servers internally form tree or hash
`structures for the name space, and chain RRs off nodes. The remaining
`RR parts are the fixed header (type, class, TTL) which is consistent for
`all RRs, and a variable part (RDATA) that fits the needs of the resource
`being described.
`
`The meaning of the TTL field is a time limit on how long an RR can be
`kept in a cache. This limit does not apply to authoritative data in
`zones; it is also timed out, but by the refreshing policies for the
`zone. The TTL is assigned by the administrator for the zone where the
`data originates. While short TTLs can be used to minimize caching, and
`a zero TTL prohibits caching, the realities of Internet performance
`suggest that these times should be on the order of days for the typical
`host. If a change can be anticipated, the TTL can be reduced prior to
`the change to minimize inconsistency during the change, and then
`increased back to its former value following the change.
`
`The data in the RDATA section of RRs is carried as a combination of
`binary strings and domain names. The domain names are frequently used
`as "pointers" to other data in the DNS.
`
`3.6.1. Textual expression of RRs
`
`RRs are represented in binary form in the packets of the DNS protocol,
`and are usually represented in highly encoded form when stored in a name
`server or resolver. In this memo, we adopt a style similar to that used
`
`Mockapetris [Page 13]
`
`AT&T Exhibit 1029
`AT&T v. VoIP, IPR 2017-01382
`Page 13
`
`

`

`
`RFC 1034 Domain Concepts and Facilities November 1987
`
`in master files in order to show the contents of RRs. In this format,
`most RRs are shown on a single line, although continuation lines are
`possible using parentheses.
`
`The start of the line gives the owner of the RR. If a line begins with
`a blank, then the owner is assumed to be the same as that of the
`previous RR. Blank lines are often included for readability.
`
`Following the owner, we list the TTL, type, and class of the RR. Class
`and type use the mnemonics defined above, and TTL is an integer before
`the type field. In order to avoid ambiguity in parsing, type and class
`mnemonics are disjoint, TTLs are integers, and the type mnemonic is
`always last. The IN class and TTL values are often omitted from example

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