summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7719.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7719.txt')
-rw-r--r--doc/rfc/rfc7719.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7719.txt b/doc/rfc/rfc7719.txt
new file mode 100644
index 0000000..e327092
--- /dev/null
+++ b/doc/rfc/rfc7719.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hoffman
+Request for Comments: 7719 ICANN
+Category: Informational A. Sullivan
+ISSN: 2070-1721 Dyn
+ K. Fujiwara
+ JPRS
+ December 2015
+
+
+ DNS Terminology
+
+Abstract
+
+ The DNS is defined in literally dozens of different RFCs. The
+ terminology used by implementers and developers of DNS protocols, and
+ by operators of DNS systems, has sometimes changed in the decades
+ since the DNS was first defined. This document gives current
+ definitions for many of the terms used in the DNS in a single
+ document.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7719.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 1]
+
+RFC 7719 DNS Terminology December 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 6
+ 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 7
+ 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 9
+ 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 17
+ 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18
+ 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 24
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
+
+1. Introduction
+
+ The Domain Name System (DNS) is a simple query-response protocol
+ whose messages in both directions have the same format. The protocol
+ and message format are defined in [RFC1034] and [RFC1035]. These
+ RFCs defined some terms, but later documents defined others. Some of
+ the terms from RFCs 1034 and 1035 now have somewhat different
+ meanings than they did in 1987.
+
+ This document collects a wide variety of DNS-related terms. Some of
+ them have been precisely defined in earlier RFCs, some have been
+ loosely defined in earlier RFCs, and some are not defined in any
+ earlier RFC at all.
+
+
+
+
+
+Hoffman, et al. Informational [Page 2]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Most of the definitions here are the consensus definition of the DNS
+ community -- both protocol developers and operators. Some of the
+ definitions differ from earlier RFCs, and those differences are
+ noted. In this document, where the consensus definition is the same
+ as the one in an RFC, that RFC is quoted. Where the consensus
+ definition has changed somewhat, the RFC is mentioned but the new
+ stand-alone definition is given.
+
+ It is important to note that, during the development of this
+ document, it became clear that some DNS-related terms are interpreted
+ quite differently by different DNS experts. Further, some terms that
+ are defined in early DNS RFCs now have definitions that are generally
+ agreed to, but that are different from the original definitions.
+ Therefore, the authors intend to follow this document with a
+ substantial revision in the not-distant future. That revision will
+ probably have more in-depth discussion of some terms as well as new
+ terms; it will also update some of the RFCs with new definitions.
+
+ The terms are organized loosely by topic. Some definitions are for
+ new terms for things that are commonly talked about in the DNS
+ community but that never had terms defined for them.
+
+ Other organizations sometimes define DNS-related terms their own way.
+ For example, the W3C defines "domain" at
+ https://specs.webplatform.org/url/webspecs/develop/.
+
+ Note that there is no single consistent definition of "the DNS". It
+ can be considered to be some combination of the following: a commonly
+ used naming scheme for objects on the Internet; a distributed
+ database representing the names and certain properties of these
+ objects; an architecture providing distributed maintenance,
+ resilience, and loose coherency for this database; and a simple
+ query-response protocol (as mentioned below) implementing this
+ architecture.
+
+ Capitalization in DNS terms is often inconsistent among RFCs and
+ various DNS practitioners. The capitalization used in this document
+ is a best guess at current practices, and is not meant to indicate
+ that other capitalization styles are wrong or archaic. In some
+ cases, multiple styles of capitalization are used for the same term
+ due to quoting from different RFCs.
+
+
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 3]
+
+RFC 7719 DNS Terminology December 2015
+
+
+2. Names
+
+ Domain name: Section 3.1 of [RFC1034] talks of "the domain name
+ space" as a tree structure. "Each node has a label, which is zero
+ to 63 octets in length. ... The domain name of a node is the list
+ of the labels on the path from the node to the root of the tree.
+ ... 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." Any label in a domain name can
+ contain any octet value.
+
+ Fully qualified domain name (FQDN): This is often just a clear way
+ of saying the same thing as "domain name of a node", as outlined
+ above. However, the term is ambiguous. Strictly speaking, a
+ fully qualified domain name would include every label, including
+ the final, zero-length label of the root: such a name would be
+ written "www.example.net." (note the terminating dot). But
+ because every name eventually shares the common root, names are
+ often written relative to the root (such as "www.example.net") and
+ are still called "fully qualified". This term first appeared in
+ [RFC819]. In this document, names are often written relative to
+ the root.
+
+ The need for the term "fully qualified domain name" comes from the
+ existence of partially qualified domain names, which are names
+ where some of the right-most names are left off and are understood
+ only by context.
+
+ Label: The identifier of an individual node in the sequence of nodes
+ identified by a fully qualified domain name.
+
+ Host name: This term and its equivalent, "hostname", have been
+ widely used but are not defined in [RFC1034], [RFC1035],
+ [RFC1123], or [RFC2181]. The DNS was originally deployed into the
+ Host Tables environment as outlined in [RFC952], and it is likely
+ that the term followed informally from the definition there. Over
+ time, the definition seems to have shifted. "Host name" is often
+ meant to be a domain name that follows the rules in Section 3.5 of
+ [RFC1034], the "preferred name syntax". Note that any label in a
+ domain name can contain any octet value; hostnames are generally
+ considered to be domain names where every label follows the rules
+ in the "preferred name syntax", with the amendment that labels can
+ start with ASCII digits (this amendment comes from Section 2.1 of
+ [RFC1123]).
+
+ People also sometimes use the term hostname to refer to just the
+ first label of an FQDN, such as "printer" in
+ "printer.admin.example.com". (Sometimes this is formalized in
+
+
+
+Hoffman, et al. Informational [Page 4]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ configuration in operating systems.) In addition, people
+ sometimes use this term to describe any name that refers to a
+ machine, and those might include labels that do not conform to the
+ "preferred name syntax".
+
+ TLD: A Top-Level Domain, meaning a zone that is one layer below the
+ root, such as "com" or "jp". There is nothing special, from the
+ point of view of the DNS, about TLDs. Most of them are also
+ delegation-centric zones, and there are significant policy issues
+ around their operation. TLDs are often divided into sub-groups
+ such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level
+ Domains (gTLDs), and others; the division is a matter of policy,
+ and beyond the scope of this document.
+
+ IDN: The common abbreviation for "Internationalized Domain Name".
+ The IDNA protocol is the standard mechanism for handling domain
+ names with non-ASCII characters in applications in the DNS. The
+ current standard, normally called "IDNA2008", is defined in
+ [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These
+ documents define many IDN-specific terms such as "LDH label",
+ "A-label", and "U-label". [RFC6365] defines more terms that
+ relate to internationalization (some of which relate to IDNs), and
+ [RFC6055] has a much more extensive discussion of IDNs, including
+ some new terminology.
+
+ Subdomain: "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." (Quoted from [RFC1034], Section 3.1). For example, in the
+ host name "nnn.mmm.example.com", both "mmm.example.com" and
+ "nnn.mmm.example.com" are subdomains of "example.com".
+
+ Alias: The owner of a CNAME resource record, or a subdomain of the
+ owner of a DNAME resource record [RFC6672]. See also "canonical
+ name".
+
+ Canonical name: A CNAME resource record "identifies its owner name
+ as an alias, and specifies the corresponding canonical name in the
+ RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2)
+ This usage of the word "canonical" is related to the mathematical
+ concept of "canonical form".
+
+ CNAME: "It is traditional to refer to the owner of a CNAME record as
+ 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of
+ 'canonical name', and the owner of a CNAME record is an alias, not
+ a canonical name." (Quoted from [RFC2181], Section 10.1.1)
+
+
+
+
+
+Hoffman, et al. Informational [Page 5]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Public suffix: "A domain that is controlled by a public registry."
+ (Quoted from [RFC6265], Section 5.3) A common definition for this
+ term is a domain under which subdomains can be registered, and on
+ which HTTP cookies ([RFC6265]) should not be set. There is no
+ indication in a domain name whether it is a public suffix; that
+ can only be determined by outside means. In fact, both a domain
+ and a subdomain of that domain can be public suffixes. At the
+ time this document is published, the IETF DBOUND Working Group
+ [DBOUND] is dealing with issues concerning public suffixes.
+
+ There is nothing inherent in a domain name to indicate whether it
+ is a public suffix. One resource for identifying public suffixes
+ is the Public Suffix List (PSL) maintained by Mozilla
+ (http://publicsuffix.org/).
+
+ For example, at the time this document is published, the "com.au"
+ domain is listed as a public suffix in the PSL. (Note that this
+ example might change in the future.)
+
+ Note that the term "public suffix" is controversial in the DNS
+ community for many reasons, and may be significantly changed in
+ the future. One example of the difficulty of calling a domain a
+ public suffix is that designation can change over time as the
+ registration policy for the zone changes, such as the case of the
+ "uk" TLD around the time this document is published.
+
+3. DNS Header and Response Codes
+
+ The header of a DNS message is its first 12 octets. Many of the
+ fields and flags in the header diagram in Sections 4.1.1 through
+ 4.1.3 of [RFC1035] are referred to by their names in that diagram.
+ For example, the response codes are called "RCODEs", the data for a
+ record is called the "RDATA", and the authoritative answer bit is
+ often called "the AA flag" or "the AA bit".
+
+ Some of response codes that are defined in [RFC1035] have gotten
+ their own shorthand names. Some common response code names that
+ appear without reference to the numeric value are "FORMERR",
+ "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
+ as "Name Error"). All of the RCODEs are listed at
+ http://www.iana.org/assignments/dns-parameters, although that site
+ uses mixed-case capitalization, while most documents use all-caps.
+
+ NODATA: "A pseudo RCODE which indicates that the name is valid for
+ the given class, but there are no records of the given type. A
+ NODATA response has to be inferred from the answer." (Quoted from
+ [RFC2308], Section 1.) "NODATA is indicated by an answer with the
+ RCODE set to NOERROR and no relevant answers in the answer
+
+
+
+Hoffman, et al. Informational [Page 6]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ section. The authority section will contain an SOA record, or
+ there will be no NS records there." (Quoted from [RFC2308],
+ Section 2.2.) Note that referrals have a similar format to NODATA
+ replies; [RFC2308] explains how to distinguish them.
+
+ The term "NXRRSET" is sometimes used as a synonym for NODATA.
+ However, this is a mistake, given that NXRRSET is a specific error
+ code defined in [RFC2136].
+
+ Negative response: A response that indicates that a particular RRset
+ does not exist, or whose RCODE indicates the nameserver cannot
+ answer. Sections 2 and 7 of [RFC2308] describe the types of
+ negative responses in detail.
+
+ Referrals: Data from the authority section of a non-authoritative
+ answer. [RFC1035] Section 2.1 defines "authoritative" data.
+ However, referrals at zone cuts (defined in Section 6) are not
+ authoritative. Referrals may be zone cut NS resource records and
+ their glue records. NS records on the parent side of a zone cut
+ are an authoritative delegation, but are normally not treated as
+ authoritative data. In general, a referral is a way for a server
+ to send an answer saying that the server does not know the answer,
+ but knows where the query should be directed in order to get an
+ answer. Historically, many authoritative servers answered with a
+ referral to the root zone when queried for a name for which they
+ were not authoritative, but this practice has declined.
+
+4. Resource Records
+
+ RR: An acronym for resource record. ([RFC1034], Section 3.6.)
+
+ RRset: A set of resource records with the same label, class and
+ type, but with different data. (Definition from [RFC2181]) Also
+ spelled RRSet in some documents. As a clarification, "same label"
+ in this definition means "same owner name". In addition,
+ [RFC2181] states that "the TTLs of all RRs in an RRSet must be the
+ same". (This definition is definitely not the same as "the
+ response one gets to a query for QTYPE=ANY", which is an
+ unfortunate misunderstanding.)
+
+ EDNS: The extension mechanisms for DNS, defined in [RFC6891].
+ Sometimes called "EDNS0" or "EDNS(0)" to indicate the version
+ number. EDNS allows DNS clients and servers to specify message
+ sizes larger than the original 512 octet limit, to expand the
+ response code space, and potentially to carry additional options
+ that affect the handling of a DNS query.
+
+
+
+
+
+Hoffman, et al. Informational [Page 7]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to
+ contain control information pertaining to the question-and-answer
+ sequence of a specific transaction. (Definition from [RFC6891],
+ Section 6.1.1) It is used by EDNS.
+
+ Owner: The domain name where a RR is found ([RFC1034], Section 3.6).
+ Often appears in the term "owner name".
+
+ SOA field names: DNS documents, including the definitions here,
+ often refer to the fields in the RDATA of an SOA resource record
+ by field name. Those fields are defined in Section 3.3.13 of
+ [RFC1035]. The names (in the order they appear in the SOA RDATA)
+ are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.
+ Note that the meaning of MINIMUM field is updated in Section 4 of
+ [RFC2308]; the new definition is that the MINIMUM field is only
+ "the TTL to be used for negative responses". This document tends
+ to use field names instead of terms that describe the fields.
+
+ TTL: The maximum "time to live" of a resource record. "A TTL value
+ is an unsigned number, with a minimum value of 0, and a maximum
+ value of 2147483647. That is, a maximum of 2^31 - 1. When
+ transmitted, the TTL is encoded in the less significant 31 bits of
+ the 32 bit TTL field, with the most significant, or sign, bit set
+ to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035]
+ erroneously stated that this is a signed integer; that was fixed
+ by [RFC2181].)
+
+ The TTL "specifies the time interval that the resource record may
+ be cached before the source of the information should again be
+ consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the
+ time interval (in seconds) that the resource record may be cached
+ before it should be discarded". (Quoted from [RFC1035],
+ Section 4.1.3). Despite being defined for a resource record, the
+ TTL of every resource record in an RRset is required to be the
+ same ([RFC2181], Section 5.2).
+
+ The reason that the TTL is the maximum time to live is that a
+ cache operator might decide to shorten the time to live for
+ operational purposes, such as if there is a policy to disallow TTL
+ values over a certain number. Also, if a value is flushed from
+ the cache when its value is still positive, the value effectively
+ becomes zero. Some servers are known to ignore the TTL on some
+ RRsets (such as when the authoritative data has a very short TTL)
+ even though this is against the advice in RFC 1035.
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 8]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ There is also the concept of a "default TTL" for a zone, which can
+ be a configuration parameter in the server software. This is
+ often expressed by a default for the entire server, and a default
+ for a zone using the $TTL directive in a zone file. The $TTL
+ directive was added to the master file format by [RFC2308].
+
+ Class independent: A resource record type whose syntax and semantics
+ are the same for every DNS class. A resource record type that is
+ not class independent has different meanings depending on the DNS
+ class of the record, or the meaning is undefined for classes other
+ than IN (class 1, the Internet).
+
+5. DNS Servers and Clients
+
+ This section defines the terms used for the systems that act as DNS
+ clients, DNS servers, or both.
+
+ Resolver: A program "that extract[s] information from name servers
+ in response to client requests." (Quoted from [RFC1034],
+ Section 2.4) "The resolver is located on the same machine as the
+ program that requests the resolver's services, but it may need to
+ consult name servers on other hosts." (Quoted from [RFC1034],
+ Section 5.1) A resolver performs queries for a name, type, and
+ class, and receives answers. The logical function is called
+ "resolution". In practice, the term is usually referring to some
+ specific type of resolver (some of which are defined below), and
+ understanding the use of the term depends on understanding the
+ context.
+
+ Stub resolver: A resolver that cannot perform all resolution itself.
+ Stub resolvers generally depend on a recursive resolver to
+ undertake the actual resolution function. Stub resolvers are
+ discussed but never fully defined in Section 5.3.1 of [RFC1034].
+ They are fully defined in Section 6.1.3.1 of [RFC1123].
+
+ Iterative mode: A resolution mode of a server that receives DNS
+ queries and responds with a referral to another server.
+ Section 2.3 of [RFC1034] describes this as "The server refers the
+ client to another server and lets the client pursue the query". A
+ resolver that works in iterative mode is sometimes called an
+ "iterative resolver".
+
+ Recursive mode: A resolution mode of a server that receives DNS
+ queries and either responds to those queries from a local cache or
+ sends queries to other servers in order to get the final answers
+ to the original queries. Section 2.3 of [RFC1034] describes this
+ as "The first server pursues the query for the client at another
+ server". A server operating in recursive mode may be thought of
+
+
+
+Hoffman, et al. Informational [Page 9]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ as having a name server side (which is what answers the query) and
+ a resolver side (which performs the resolution function). Systems
+ operating in this mode are commonly called "recursive servers".
+ Sometimes they are called "recursive resolvers". While strictly
+ the difference between these is that one of them sends queries to
+ another recursive server and the other does not, in practice it is
+ not possible to know in advance whether the server that one is
+ querying will also perform recursion; both terms can be observed
+ in use interchangeably.
+
+ Full resolver: This term is used in [RFC1035], but it is not defined
+ there. RFC 1123 defines a "full-service resolver" that may or may
+ not be what was intended by "full resolver" in [RFC1035]. This
+ term is not properly defined in any RFC.
+
+ Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
+ term to mean a resolver that acts in recursive mode with a cache
+ (and meets other requirements).
+
+ Priming: The mechanism used by a resolver to determine where to send
+ queries before there is anything in the resolver's cache. Priming
+ is most often done from a configuration setting that contains a
+ list of authoritative servers for the root zone.
+
+ Negative caching: "The storage of knowledge that something does not
+ exist, cannot give an answer, or does not give an answer."
+ (Quoted from [RFC2308], Section 1)
+
+ Authoritative server: "A server that knows the content of a DNS zone
+ from local knowledge, and thus can answer queries about that zone
+ without needing to query other servers." (Quoted from [RFC2182],
+ Section 2.) It is a system that responds to DNS queries with
+ information about zones for which it has been configured to answer
+ with the AA flag in the response header set to 1. It is a server
+ that has authority over one or more DNS zones. Note that it is
+ possible for an authoritative server to respond to a query without
+ the parent zone delegating authority to that server.
+ Authoritative servers also provide "referrals", usually to child
+ zones delegated from them; these referrals have the AA bit set to
+ 0 and come with referral data in the Authority and (if needed) the
+ Additional sections.
+
+ Authoritative-only server: A name server that only serves
+ authoritative data and ignores requests for recursion. It will
+ "not normally generate any queries of its own. Instead, it
+ answers non-recursive queries from iterative resolvers looking for
+ information in zones it serves." (Quoted from [RFC4697],
+ Section 2.4)
+
+
+
+Hoffman, et al. Informational [Page 10]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Zone transfer: The act of a client requesting a copy of a zone and
+ an authoritative server sending the needed information. (See
+ Section 6 for a description of zones.) There are two common
+ standard ways to do zone transfers: the AXFR ("Authoritative
+ Transfer") mechanism to copy the full zone (described in
+ [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
+ only parts of the zone that have changed (described in [RFC1995]).
+ Many systems use non-standard methods for zone transfer outside
+ the DNS protocol.
+
+ Secondary server: "An authoritative server which uses zone transfer
+ to retrieve the zone" (Quoted from [RFC1996], Section 2.1).
+ [RFC2182] describes secondary servers in detail. Although early
+ DNS RFCs such as [RFC1996] referred to this as a "slave", the
+ current common usage has shifted to calling it a "secondary".
+ Secondary servers are also discussed in [RFC1034].
+
+ Slave server: See secondary server.
+
+ Primary server: "Any authoritative server configured to be the
+ source of zone transfer for one or more [secondary] servers"
+ (Quoted from [RFC1996], Section 2.1) or, more specifically, "an
+ authoritative server configured to be the source of AXFR or IXFR
+ data for one or more [secondary] servers" (Quoted from [RFC2136]).
+ Although early DNS RFCs such as [RFC1996] referred to this as a
+ "master", the current common usage has shifted to "primary".
+ Primary servers are also discussed in [RFC1034].
+
+ Master server: See primary server.
+
+ Primary master: "The primary master is named in the zone's SOA MNAME
+ field and optionally by an NS RR". (Quoted from [RFC1996],
+ Section 2.1). [RFC2136] defines "primary master" as "Master
+ server at the root of the AXFR/IXFR dependency graph. The primary
+ master is named in the zone's SOA MNAME field and optionally by an
+ NS RR. There is by definition only one primary master server per
+ zone." The idea of a primary master is only used by [RFC2136],
+ and is considered archaic in other parts of the DNS.
+
+ Stealth server: This is "like a slave server except not listed in an
+ NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
+
+
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 11]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Hidden master: A stealth server that is a master for zone transfers.
+ "In this arrangement, the master name server that processes the
+ updates is unavailable to general hosts on the Internet; it is not
+ listed in the NS RRset." (Quoted from [RFC6781], Section 3.4.3.)
+ An earlier RFC, [RFC4641], said that the hidden master's name
+ appears in the SOA RRs MNAME field, although in some setups, the
+ name does not appear at all in the public DNS. A hidden master
+ can be either a secondary or a primary master.
+
+ Forwarding: The process of one server sending a DNS query with the
+ RD bit set to 1 to another server to resolve that query.
+ Forwarding is a function of a DNS resolver; it is different than
+ simply blindly relaying queries.
+
+ [RFC5625] does not give a specific definition for forwarding, but
+ describes in detail what features a system that forwards need to
+ support. Systems that forward are sometimes called "DNS proxies",
+ but that term has not yet been defined (even in [RFC5625]).
+
+ Forwarder: Section 1 of [RFC2308] describes a forwarder as "a
+ nameserver used to resolve queries instead of directly using the
+ authoritative nameserver chain". [RFC2308] further says "The
+ forwarder typically either has better access to the internet, or
+ maintains a bigger cache which may be shared amongst many
+ resolvers." That definition appears to suggest that forwarders
+ normally only query authoritative servers. In current use,
+ however, forwarders often stand between stub resolvers and
+ recursive servers. [RFC2308] is silent on whether a forwarder is
+ iterative-only or can be a full-service resolver.
+
+ Policy-implementing resolver: A resolver acting in recursive mode
+ that changes some of the answers that it returns based on policy
+ criteria, such as to prevent access to malware sites or
+ objectionable content. In general, a stub resolver has no idea
+ whether upstream resolvers implement such policy or, if they do,
+ the exact policy about what changes will be made. In some cases,
+ the user of the stub resolver has selected the policy-implementing
+ resolver with the explicit intention of using it to implement the
+ policies. In other cases, policies are imposed without the user
+ of the stub resolver being informed.
+
+ Open resolver: A full-service resolver that accepts and processes
+ queries from any (or nearly any) stub resolver. This is sometimes
+ also called a "public resolver", although the term "public
+ resolver" is used more with open resolvers that are meant to be
+ open, as compared to the vast majority of open resolvers that are
+ probably misconfigured to be open.
+
+
+
+
+Hoffman, et al. Informational [Page 12]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ View: A configuration for a DNS server that allows it to provide
+ different answers depending on attributes of the query.
+ Typically, views differ by the source IP address of a query, but
+ can also be based on the destination IP address, the type of query
+ (such as AXFR), whether it is recursive, and so on. Views are
+ often used to provide more names or different addresses to queries
+ from "inside" a protected network than to those "outside" that
+ network. Views are not a standardized part of the DNS, but they
+ are widely implemented in server software.
+
+ Passive DNS: A mechanism to collect large amounts of DNS data by
+ storing DNS responses from servers. Some of these systems also
+ collect the DNS queries associated with the responses; this can
+ raise privacy issues. Passive DNS databases can be used to answer
+ historical questions about DNS zones such as which records were
+ available for them at what times in the past. Passive DNS
+ databases allow searching of the stored records on keys other than
+ just the name, such as "find all names which have A records of a
+ particular value".
+
+ Anycast: "The practice of making a particular service address
+ available in multiple, discrete, autonomous locations, such that
+ datagrams sent are routed to one of several available locations."
+ (Quoted from [RFC4786], Section 2)
+
+6. Zones
+
+ This section defines terms that are used when discussing zones that
+ are being served or retrieved.
+
+ Zone: "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." (Quoted from [RFC1034], Section 2.4)
+
+ Child: "The entity on record that has the delegation of the domain
+ from the Parent." (Quoted from [RFC7344], Section 1.1)
+
+ Parent: "The domain in which the Child is registered." (Quoted from
+ [RFC7344], Section 1.1) Earlier, "parent name server" was defined
+ in [RFC882] as "the name server that has authority over the place
+ in the domain name space that will hold the new domain". (Note
+ that [RFC882] was obsoleted by [RFC1034] and [RFC1035].) [RFC819]
+ also has some description of the relationship between parents and
+ children.
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 13]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Origin:
+
+ (a) "The domain name that appears at the top of a zone (just below
+ the cut that separates the zone from its parent). The name of the
+ zone is the same as the name of the domain at the zone's origin."
+ (Quoted from [RFC2181], Section 6.) These days, this sense of
+ "origin" and "apex" (defined below) are often used
+ interchangeably.
+
+ (b) The domain name within which a given relative domain name
+ appears in zone files. Generally seen in the context of
+ "$ORIGIN", which is a control entry defined in [RFC1035],
+ Section 5.1, as part of the master file format. For example, if
+ the $ORIGIN is set to "example.org.", then a master file line for
+ "www" is in fact an entry for "www.example.org.".
+
+ Apex: The point in the tree at an owner of an SOA and corresponding
+ authoritative NS RRset. This is also called the "zone apex".
+ [RFC4033] defines it as "the name at the child's side of a zone
+ cut". The "apex" can usefully be thought of as a data-theoretic
+ description of a tree structure, and "origin" is the name of the
+ same concept when it is implemented in zone files. The
+ distinction is not always maintained in use, however, and one can
+ find uses that conflict subtly with this definition. [RFC1034]
+ uses the term "top node of the zone" as a synonym of "apex", but
+ that term is not widely used. These days, the first sense of
+ "origin" (above) and "apex" are often used interchangeably.
+
+ Zone cut: The delimitation point between two zones where the origin
+ of one of the zones is the child of the other zone.
+
+ "Zones are delimited by 'zone cuts'. Each zone cut separates a
+ 'child' zone (below the cut) from a 'parent' zone (above the cut).
+ (Quoted from [RFC2181], Section 6; note that this is barely an
+ ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as
+ 'zone cut'."
+
+ Delegation: The process by which a separate zone is created in the
+ name space beneath the apex of a given domain. Delegation happens
+ when an NS RRset is added in the parent zone for the child origin.
+ Delegation inherently happens at a zone cut. The term is also
+ commonly a noun: the new zone that is created by the act of
+ delegating.
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 14]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Glue records: "[Resource records] which are not part of the
+ authoritative data [of the zone], and are address resource records
+ for the [name servers in subzones]. These RRs are only necessary
+ if the name server's name is 'below' the cut, and are only used as
+ part of a referral response." Without glue "we could be faced
+ with the situation where the NS RRs tell us that in order to learn
+ a name server's address, we should contact the server using the
+ address we wish to learn." (Definition from [RFC1034],
+ Section 4.2.1)
+
+ A later definition is that glue "includes any record in a zone
+ file that is not properly part of that zone, including nameserver
+ records of delegated sub-zones (NS records), address records that
+ accompany those NS records (A, AAAA, etc), and any other stray
+ data that might appear" ([RFC2181], Section 5.4.1). Although glue
+ is sometimes used today with this wider definition in mind, the
+ context surrounding the [RFC2181] definition suggests it is
+ intended to apply to the use of glue within the document itself
+ and not necessarily beyond.
+
+ In-bailiwick:
+
+ (a) An adjective to describe a name server whose name is either
+ subordinate to or (rarely) the same as the zone origin. In-
+ bailiwick name servers require glue records in their parent zone
+ (using the first of the definitions of "glue records" in the
+ definition above).
+
+ (b) Data for which the server is either authoritative, or else
+ authoritative for an ancestor of the owner name. This sense of
+ the term normally is used when discussing the relevancy of glue
+ records in a response. For example, the server for the parent
+ zone "example.com" might reply with glue records for
+ "ns.child.example.com". Because the "child.example.com" zone is a
+ descendant of the "example.com" zone, the glue records are in-
+ bailiwick.
+
+ Out-of-bailiwick: The antonym of in-bailiwick.
+
+ Authoritative data: "All of the RRs attached to all of the nodes
+ from the top node of the zone down to leaf nodes or nodes above
+ cuts around the bottom edge of the zone." (Quoted from [RFC1034],
+ Section 4.2.1) It is noted that this definition might
+ inadvertently also include any NS records that appear in the zone,
+ even those that might not truly be authoritative because there are
+ identical NS RRs below the zone cut. This reveals the ambiguity
+
+
+
+
+
+Hoffman, et al. Informational [Page 15]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ in the notion of authoritative data, because the parent-side NS
+ records authoritatively indicate the delegation, even though they
+ are not themselves authoritative data.
+
+ Root zone: The zone whose apex is the zero-length label. Also
+ sometimes called "the DNS root".
+
+ Empty non-terminals: "Domain names that own no resource records but
+ have subdomains that do." (Quoted from [RFC4592], Section 2.2.2.)
+ A typical example is in SRV records: in the name
+ "_sip._tcp.example.com", it is likely that "_tcp.example.com" has
+ no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
+ RRset.
+
+ Delegation-centric zone: A zone that consists mostly of delegations
+ to child zones. This term is used in contrast to a zone that
+ might have some delegations to child zones, but also has many data
+ resource records for the zone itself and/or for child zones. The
+ term is used in [RFC4956] and [RFC5155], but is not defined there.
+
+ Wildcard: [RFC1034] defined "wildcard", but in a way that turned out
+ to be confusing to implementers. Special treatment is given to
+ RRs with owner names starting with the label "*". "Such RRs are
+ called 'wildcards'. Wildcard RRs can be thought of as
+ instructions for synthesizing RRs." (Quoted from [RFC1034],
+ Section 4.3.3) For an extended discussion of wildcards, including
+ clearer definitions, see [RFC4592].
+
+ Occluded name: "The addition of a delegation point via dynamic
+ update will render all subordinate domain names to be in a limbo,
+ still part of the zone, but not available to the lookup process.
+ The addition of a DNAME resource record has the same impact. The
+ subordinate names are said to be 'occluded'." (Quoted from
+ [RFC5936], Section 3.5)
+
+ Fast flux DNS: This "occurs when a domain is found in DNS using A
+ records to multiple IP addresses, each of which has a very short
+ Time-to-Live (TTL) value associated with it. This means that the
+ domain resolves to varying IP addresses over a short period of
+ time." (Quoted from [RFC6561], Section 1.1.5, with typo
+ corrected) It is often used to deliver malware. Because the
+ addresses change so rapidly, it is difficult to ascertain all the
+ hosts. It should be noted that the technique also works with AAAA
+ records, but such use is not frequently observed on the Internet
+ as of this writing.
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 16]
+
+RFC 7719 DNS Terminology December 2015
+
+
+7. Registration Model
+
+ Registry: The administrative operation of a zone that allows
+ registration of names within that zone. People often use this
+ term to refer only to those organizations that perform
+ registration in large delegation-centric zones (such as TLDs); but
+ formally, whoever decides what data goes into a zone is the
+ registry for that zone. This definition of "registry" is from a
+ DNS point of view; for some zones, the policies that determine
+ what can go in the zone are decided by superior zones and not the
+ registry operator.
+
+ Registrant: An individual or organization on whose behalf a name in
+ a zone is registered by the registry. In many zones, the registry
+ and the registrant may be the same entity, but in TLDs they often
+ are not.
+
+ Registrar: A service provider that acts as a go-between for
+ registrants and registries. Not all registrations require a
+ registrar, though it is common to have registrars involved in
+ registrations in TLDs.
+
+ EPP: The Extensible Provisioning Protocol (EPP), which is commonly
+ used for communication of registration information between
+ registries and registrars. EPP is defined in [RFC5730].
+
+ WHOIS: A protocol specified in [RFC3912], often used for querying
+ registry databases. WHOIS data is frequently used to associate
+ registration data (such as zone management contacts) with domain
+ names. The term "WHOIS data" is often used as a synonym for the
+ registry database, even though that database may be served by
+ different protocols, particularly RDAP. The WHOIS protocol is
+ also used with IP address registry data.
+
+ RDAP: The Registration Data Access Protocol, defined in [RFC7480],
+ [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The
+ RDAP protocol and data format are meant as a replacement for
+ WHOIS.
+
+ DNS operator: An entity responsible for running DNS servers. For a
+ zone's authoritative servers, the registrant may act as their own
+ DNS operator, or their registrar may do it on their behalf, or
+ they may use a third-party operator. For some zones, the registry
+ function is performed by the DNS operator plus other entities who
+ decide about the allowed contents of the zone.
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 17]
+
+RFC 7719 DNS Terminology December 2015
+
+
+8. General DNSSEC
+
+ Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
+ [RFC5155]. The terms that have caused confusion in the DNS community
+ are highlighted here.
+
+ DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
+ some RFCs, have not been formally defined. However, Section 2 of
+ [RFC4033] defines many types of resolvers and validators,
+ including "non-validating security-aware stub resolver", "non-
+ validating stub resolver", "security-aware name server",
+ "security-aware recursive name server", "security-aware resolver",
+ "security-aware stub resolver", and "security-oblivious
+ 'anything'". (Note that the term "validating resolver", which is
+ used in some places in DNSSEC-related documents, is also not
+ defined.)
+
+ Signed zone: "A zone whose RRsets are signed and that contains
+ properly constructed DNSKEY, Resource Record Signature (RRSIG),
+ Next Secure (NSEC), and (optionally) DS records." (Quoted from
+ [RFC4033], Section 2.) It has been noted in other contexts that
+ the zone itself is not really signed, but all the relevant RRsets
+ in the zone are signed. Nevertheless, if a zone that should be
+ signed contains any RRsets that are not signed (or opted out),
+ those RRsets will be treated as bogus, so the whole zone needs to
+ be handled in some way.
+
+ It should also be noted that, since the publication of [RFC6840],
+ NSEC records are no longer required for signed zones: a signed
+ zone might include NSEC3 records instead. [RFC7129] provides
+ additional background commentary and some context for the NSEC and
+ NSEC3 mechanisms used by DNSSEC to provide authenticated denial-
+ of-existence responses.
+
+ Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that
+ is not signed". Section 2 of [RFC4035] defines this as "A zone
+ that does not include these records [properly constructed DNSKEY,
+ Resource Record Signature (RRSIG), Next Secure (NSEC), and
+ (optionally) DS records] according to the rules in this section".
+ There is an important note at the end of Section 5.2 of [RFC4035]
+ that defines an additional situation in which a zone is considered
+ unsigned: "If the resolver does not support any of the algorithms
+ listed in an authenticated DS RRset, then the resolver will not be
+ able to verify the authentication path to the child zone. In this
+ case, the resolver SHOULD treat the child zone as if it were
+ unsigned."
+
+
+
+
+
+Hoffman, et al. Informational [Page 18]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ NSEC: "The NSEC record allows a security-aware resolver to
+ authenticate a negative reply for either name or type non-
+ existence with the same mechanisms used to authenticate other DNS
+ replies." (Quoted from [RFC4033], Section 3.2.) In short, an
+ NSEC record provides authenticated denial of existence.
+
+ "The NSEC resource record lists two separate things: the next
+ owner name (in the canonical ordering of the zone) that contains
+ authoritative data or a delegation point NS RRset, and the set of
+ RR types present at the NSEC RR's owner name." (Quoted from
+ Section 4 of RFC 4034)
+
+ NSEC3: Like the NSEC record, the NSEC3 record also provides
+ authenticated denial of existence; however, NSEC3 records mitigate
+ against zone enumeration and support Opt-Out. NSEC3 resource
+ records are defined in [RFC5155].
+
+ Note that [RFC6840] says that [RFC5155] "is now considered part of
+ the DNS Security Document Family as described by Section 10 of
+ [RFC4033]". This means that some of the definitions from earlier
+ RFCs that only talk about NSEC records should probably be
+ considered to be talking about both NSEC and NSEC3.
+
+ Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
+ unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.)
+ Opt-out tackles the high costs of securing a delegation to an
+ insecure zone. When using Opt-Out, names that are an insecure
+ delegation (and empty non-terminals that are only derived from
+ insecure delegations) don't require an NSEC3 record or its
+ corresponding RRSIG records. Opt-Out NSEC3 records are not able
+ to prove or deny the existence of the insecure delegations.
+ (Adapted from [RFC7129], Section 5.1)
+
+ Zone enumeration: "The practice of discovering the full content of a
+ zone via successive queries." (Quoted from [RFC5155],
+ Section 1.3.) This is also sometimes called "zone walking". Zone
+ enumeration is different from zone content guessing where the
+ guesser uses a large dictionary of possible labels and sends
+ successive queries for them, or matches the contents of NSEC3
+ records against such a dictionary.
+
+ Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
+ RRset in a zone."(Quoted from [RFC6781], Section 3.1)
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 19]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Zone signing key (ZSK): "DNSSEC keys that can be used to sign all
+ the RRsets in a zone that require signatures, other than the apex
+ DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the
+ roles KSK and ZSK are not mutually exclusive: a single key can be
+ both KSK and ZSK at the same time. Also note that a ZSK is
+ sometimes used to sign the apex DNSKEY RRset.
+
+ Combined signing key (CSK): "In cases where the differentiation
+ between the KSK and ZSK is not made, i.e., where keys have the
+ role of both KSK and ZSK, we talk about a Single-Type Signing
+ Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes
+ called a "combined signing key" or CSK. It is operational
+ practice, not protocol, that determines whether a particular key
+ is a ZSK, a KSK, or a CSK.
+
+ Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be
+ used to distinguish between keys that are intended to be used as
+ the secure entry point into the zone when building chains of
+ trust, i.e., they are (to be) pointed to by parental DS RRs or
+ configured as a trust anchor. Therefore, it is suggested that the
+ SEP flag be set on keys that are used as KSKs and not on keys that
+ are used as ZSKs, while in those cases where a distinction between
+ a KSK and ZSK is not made (i.e., for a Single-Type Signing
+ Scheme), it is suggested that the SEP flag be set on all keys."
+ (Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is
+ only a hint, and its presence or absence may not be used to
+ disqualify a given DNSKEY RR from use as a KSK or ZSK during
+ validation.
+
+ DNSSEC Policy (DP): A statement that "sets forth the security
+ requirements and standards to be implemented for a DNSSEC-signed
+ zone." (Quoted from [RFC6841], Section 2)
+
+ DNSSEC Practice Statement (DPS): "A practices disclosure document
+ that may support and be a supplemental document to the DNSSEC
+ Policy (if such exists), and it states how the management of a
+ given zone implements procedures and controls at a high level."
+ (Quoted from [RFC6841], Section 2)
+
+9. DNSSEC States
+
+ A validating resolver can determine that a response is in one of four
+ states: secure, insecure, bogus, or indeterminate. These states are
+ defined in [RFC4033] and [RFC4035], although the two definitions
+ differ a bit. This document makes no effort to reconcile the two
+ definitions, and takes no position as to whether they need to be
+ reconciled.
+
+
+
+
+Hoffman, et al. Informational [Page 20]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Section 5 of [RFC4033] says:
+
+ A validating resolver can determine the following 4 states:
+
+ Secure: The validating resolver has a trust anchor, has a chain
+ of trust, and is able to verify all the signatures in the
+ response.
+
+ Insecure: The validating resolver has a trust anchor, a chain
+ of trust, and, at some delegation point, signed proof of the
+ non-existence of a DS record. This indicates that subsequent
+ branches in the tree are provably insecure. A validating
+ resolver may have a local policy to mark parts of the domain
+ space as insecure.
+
+ Bogus: The validating resolver has a trust anchor and a secure
+ delegation indicating that subsidiary data is signed, but
+ the response fails to validate for some reason: missing
+ signatures, expired signatures, signatures with unsupported
+ algorithms, data missing that the relevant NSEC RR says
+ should be present, and so forth.
+
+ Indeterminate: There is no trust anchor that would indicate that a
+ specific portion of the tree is secure. This is the default
+ operation mode.
+
+ Section 4.3 of [RFC4035] says:
+
+ A security-aware resolver must be able to distinguish between four
+ cases:
+
+ Secure: An RRset for which the resolver is able to build a chain
+ of signed DNSKEY and DS RRs from a trusted security anchor to
+ the RRset. In this case, the RRset should be signed and is
+ subject to signature validation, as described above.
+
+ Insecure: An RRset for which the resolver knows that it has no
+ chain of signed DNSKEY and DS RRs from any trusted starting
+ point to the RRset. This can occur when the target RRset lies
+ in an unsigned zone or in a descendent [sic] of an unsigned
+ zone. In this case, the RRset may or may not be signed, but
+ the resolver will not be able to verify the signature.
+
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 21]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ Bogus: An RRset for which the resolver believes that it ought to
+ be able to establish a chain of trust but for which it is
+ unable to do so, either due to signatures that for some reason
+ fail to validate or due to missing data that the relevant
+ DNSSEC RRs indicate should be present. This case may indicate
+ an attack but may also indicate a configuration error or some
+ form of data corruption.
+
+ Indeterminate: An RRset for which the resolver is not able to
+ determine whether the RRset should be signed, as the resolver
+ is not able to obtain the necessary DNSSEC RRs. This can occur
+ when the security-aware resolver is not able to contact
+ security-aware name servers for the relevant zones.
+
+10. Security Considerations
+
+ These definitions do not change any security considerations for the
+ DNS.
+
+11. References
+
+11.1. Normative References
+
+ [RFC882] Mockapetris, P., "Domain names: Concepts and facilities",
+ RFC 882, DOI 10.17487/RFC0882, November 1983,
+ <http://www.rfc-editor.org/info/rfc882>.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
+ <http://www.rfc-editor.org/info/rfc1034>.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+ [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123,
+ DOI 10.17487/RFC1123, October 1989,
+ <http://www.rfc-editor.org/info/rfc1123>.
+
+ [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
+ Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
+ August 1996, <http://www.rfc-editor.org/info/rfc1996>.
+
+ [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+ RFC 2136, DOI 10.17487/RFC2136, April 1997,
+ <http://www.rfc-editor.org/info/rfc2136>.
+
+
+
+Hoffman, et al. Informational [Page 22]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
+ <http://www.rfc-editor.org/info/rfc2181>.
+
+ [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+ and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+ DOI 10.17487/RFC2182, July 1997,
+ <http://www.rfc-editor.org/info/rfc2182>.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
+ <http://www.rfc-editor.org/info/rfc2308>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <http://www.rfc-editor.org/info/rfc4033>.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, DOI 10.17487/RFC4034, March 2005,
+ <http://www.rfc-editor.org/info/rfc4034>.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+ <http://www.rfc-editor.org/info/rfc4035>.
+
+ [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
+ System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
+ <http://www.rfc-editor.org/info/rfc4592>.
+
+ [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+ Security (DNSSEC) Hashed Authenticated Denial of
+ Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+ <http://www.rfc-editor.org/info/rfc5155>.
+
+ [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
+ STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
+ <http://www.rfc-editor.org/info/rfc5730>.
+
+ [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
+ (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
+ <http://www.rfc-editor.org/info/rfc5936>.
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 23]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
+ "Recommendations for the Remediation of Bots in ISP
+ Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
+ <http://www.rfc-editor.org/info/rfc6561>.
+
+ [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
+ DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
+ <http://www.rfc-editor.org/info/rfc6672>.
+
+ [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+ Operational Practices, Version 2", RFC 6781,
+ DOI 10.17487/RFC6781, December 2012,
+ <http://www.rfc-editor.org/info/rfc6781>.
+
+ [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
+ Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
+ DOI 10.17487/RFC6840, February 2013,
+ <http://www.rfc-editor.org/info/rfc6840>.
+
+ [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
+ Framework for DNSSEC Policies and DNSSEC Practice
+ Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
+ <http://www.rfc-editor.org/info/rfc6841>.
+
+ [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+ for DNS (EDNS(0))", STD 75, RFC 6891,
+ DOI 10.17487/RFC6891, April 2013,
+ <http://www.rfc-editor.org/info/rfc6891>.
+
+ [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
+ DNSSEC Delegation Trust Maintenance", RFC 7344,
+ DOI 10.17487/RFC7344, September 2014,
+ <http://www.rfc-editor.org/info/rfc7344>.
+
+11.2. Informative References
+
+ [DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2015,
+ <https://datatracker.ietf.org/wg/dbound/charter/>.
+
+ [RFC819] Su, Z. and J. Postel, "The Domain Naming Convention for
+ Internet User Applications", RFC 819,
+ DOI 10.17487/RFC0819, August 1982,
+ <http://www.rfc-editor.org/info/rfc819>.
+
+ [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+ host table specification", RFC 952, DOI 10.17487/RFC0952,
+ October 1985, <http://www.rfc-editor.org/info/rfc952>.
+
+
+
+
+Hoffman, et al. Informational [Page 24]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ DOI 10.17487/RFC1995, August 1996,
+ <http://www.rfc-editor.org/info/rfc1995>.
+
+ [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
+ DOI 10.17487/RFC3912, September 2004,
+ <http://www.rfc-editor.org/info/rfc3912>.
+
+ [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ RFC 4641, DOI 10.17487/RFC4641, September 2006,
+ <http://www.rfc-editor.org/info/rfc4641>.
+
+ [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
+ Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
+ October 2006, <http://www.rfc-editor.org/info/rfc4697>.
+
+ [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
+ Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
+ December 2006, <http://www.rfc-editor.org/info/rfc4786>.
+
+ [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
+ (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
+ 2007, <http://www.rfc-editor.org/info/rfc4956>.
+
+ [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
+ BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
+ <http://www.rfc-editor.org/info/rfc5625>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, DOI 10.17487/RFC5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC5891] Klensin, J., "Internationalized Domain Names in
+ Applications (IDNA): Protocol", RFC 5891,
+ DOI 10.17487/RFC5891, August 2010,
+ <http://www.rfc-editor.org/info/rfc5891>.
+
+ [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
+ Internationalized Domain Names for Applications (IDNA)",
+ RFC 5892, DOI 10.17487/RFC5892, August 2010,
+ <http://www.rfc-editor.org/info/rfc5892>.
+
+ [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
+ for Internationalized Domain Names for Applications
+ (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
+ <http://www.rfc-editor.org/info/rfc5893>.
+
+
+
+
+Hoffman, et al. Informational [Page 25]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ [RFC5894] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Background, Explanation, and
+ Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
+ <http://www.rfc-editor.org/info/rfc5894>.
+
+ [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
+ Encodings for Internationalized Domain Names", RFC 6055,
+ DOI 10.17487/RFC6055, February 2011,
+ <http://www.rfc-editor.org/info/rfc6055>.
+
+ [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
+ DOI 10.17487/RFC6265, April 2011,
+ <http://www.rfc-editor.org/info/rfc6265>.
+
+ [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
+ Internationalization in the IETF", BCP 166, RFC 6365,
+ DOI 10.17487/RFC6365, September 2011,
+ <http://www.rfc-editor.org/info/rfc6365>.
+
+ [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
+ Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
+ February 2014, <http://www.rfc-editor.org/info/rfc7129>.
+
+ [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
+ Registration Data Access Protocol (RDAP)", RFC 7480,
+ DOI 10.17487/RFC7480, March 2015,
+ <http://www.rfc-editor.org/info/rfc7480>.
+
+ [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
+ Registration Data Access Protocol (RDAP)", RFC 7481,
+ DOI 10.17487/RFC7481, March 2015,
+ <http://www.rfc-editor.org/info/rfc7481>.
+
+ [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
+ Protocol (RDAP) Query Format", RFC 7482,
+ DOI 10.17487/RFC7482, March 2015,
+ <http://www.rfc-editor.org/info/rfc7482>.
+
+ [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
+ Registration Data Access Protocol (RDAP)", RFC 7483,
+ DOI 10.17487/RFC7483, March 2015,
+ <http://www.rfc-editor.org/info/rfc7483>.
+
+ [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
+ (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
+ 2015, <http://www.rfc-editor.org/info/rfc7484>.
+
+
+
+
+
+Hoffman, et al. Informational [Page 26]
+
+RFC 7719 DNS Terminology December 2015
+
+
+ [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
+ "Inventory and Analysis of WHOIS Registration Objects",
+ RFC 7485, DOI 10.17487/RFC7485, March 2015,
+ <http://www.rfc-editor.org/info/rfc7485>.
+
+Acknowledgements
+
+ The authors gratefully acknowledge all of the authors of DNS-related
+ RFCs that proceed this one. Comments from Tony Finch, Stephane
+ Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
+ Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
+ David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
+ John Klensin, David Black, and many others in the DNSOP Working Group
+ have helped shape this document.
+
+Authors' Addresses
+
+ Paul Hoffman
+ ICANN
+
+ Email: paul.hoffman@icann.org
+
+
+ Andrew Sullivan
+ Dyn
+ 150 Dow Street, Tower 2
+ Manchester, NH 03101
+ United States
+
+ Email: asullivan@dyn.com
+
+
+ Kazunori Fujiwara
+ Japan Registry Services Co., Ltd.
+ Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
+ Chiyoda-ku, Tokyo 101-0065
+ Japan
+
+ Phone: +81 3 5215 8451
+ Email: fujiwara@jprs.co.jp
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et al. Informational [Page 27]
+