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]
`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
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 1
`
`

`

`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]
`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
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 2
`
`

`

`Mockapetris [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]
`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
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 3
`
`

`

`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]
`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.
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 4
`
`

`

` 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]
`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]
`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."
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 5
`
`

`

` - 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]
`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
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 6
`
`

`

`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]
`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]
`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.
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 7
`
`

`

`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]
`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
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 8
`
`

`

` 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]
`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]
`RFC 1034 Domain Concepts and Facilities November 1987
`
`http://www.ietf.org/rfc/rfc1034.txt[7/8/2011 8:56:46 AM]
`
`Petitioner Apple Inc. - Ex. 1034, p. 9
`
`

`

`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 examples
`in the interests of clarity.
`The reso