draft-ietf-dnsop-terminology-bis-06.txt   draft-ietf-dnsop-terminology-bis-07.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft ICANN Internet-Draft ICANN
Obsoletes: 7719 (if approved) A. Sullivan Obsoletes: 7719 (if approved) A. Sullivan
Updates: 2308, 3757 (if approved) Oracle Updates: 2308 (if approved) Oracle
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: January 2, 2018 JPRS Expires: April 21, 2018 JPRS
July 1, 2017 October 18, 2017
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-06 draft-ietf-dnsop-terminology-bis-07
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
This document will be the successor to RFC 7719, and thus will This document will be the successor to RFC 7719, and thus will
obsolete RFC 7719. It will also update RFC 2308 and RFC 3758. obsolete RFC 7719. It will also update RFC 2308.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2018. This Internet-Draft will expire on April 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 10 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 11
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 12 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 13
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 21 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 23
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 22 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 24
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 27 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Definitions Updated by this Document . . . . . . . . 34 Appendix A. Definitions Updated by this Document . . . . . . . . 36
Appendix B. Definitions First Defined in this Document . . . . . 34 Appendix B. Definitions First Defined in this Document . . . . . 37
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (See whose messages in both directions have the same format. (See
Section 2 for a fuller definition.) The protocol and message format Section 2 for a fuller definition.) The protocol and message format
are defined in [RFC1034] and [RFC1035]. These RFCs defined some are defined in [RFC1034] and [RFC1035]. These RFCs defined some
terms, but later documents defined others. Some of the terms from terms, but later documents defined others. Some of the terms from
[RFC1034] and [RFC1035] now have somewhat different meanings than [RFC1034] and [RFC1035] now have somewhat different meanings than
they did in 1987. they did in 1987.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
* Protocol for getting data from a name * Protocol for getting data from a name
* Context for resolving a name * Context for resolving a name
Note that this list is a small subset of facets that people have Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming agree on a good set of facets that can be used to compare naming
systems. For example, other facets might include "protocol to systems. For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data update data in a name", "privacy of names", and "privacy of data
associated with names", but those do not not have a clear associated with names", but those are not as well-defined as the
definitions as the ones listed above. The list here is chosen ones listed above. The list here is chosen because it helps
because it helps describe the DNS and naming systems similar to describe the DNS and naming systems similar to the DNS.
the DNS.
Domain name: An ordered list of one or more labels. Domain name: An ordered list of one or more labels.
Note that this is a definition independent of the DNS RFCs, and Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS. the definition here also applies to systems other than the DNS.
[RFC1034] defines the "domain name space" using mathematical trees [RFC1034] defines the "domain name space" using mathematical trees
and their nodes in graph theory, and the definition in [RFC1034] and their nodes in graph theory, and the definition in [RFC1034]
has the same practical result as the definition here. Using graph has the same practical result as the definition here. Using graph
theory, a domain name is a list of labels identifying a portion theory, a domain name is a list of labels identifying a portion
along one edge of an acyclic directed graph. A domain name can be along one edge of a directed acyclic graph. A domain name can be
relative to other parts of the tree, or it can be fully qualified relative to other parts of the tree, or it can be fully qualified
(in which case, it ends at the common root of the graph). (in which case, it begins at the common root of the graph).
Also note that different IETF and non-IETF documents have used the Also note that different IETF and non-IETF documents have used the
term "domain name" in many different ways. It is common for term "domain name" in many different ways. It is common for
earlier documents to use "domain name" to mean "names that match earlier documents to use "domain name" to mean "names that match
the syntax in [RFC1035]", but possibly with additional rules such the syntax in [RFC1035]", but possibly with additional rules such
as "and are, or will be, resolvable in the global DNS" or "but as "and are, or will be, resolvable in the global DNS" or "but
only using the presentation format". only using the presentation format".
Label: An ordered list of zero or more octets and which makes up a Label: An ordered list of zero or more octets and which makes up a
portion of a domain name. Using graph theory, a label identifies portion of a domain name. Using graph theory, a label identifies
one node in a portion of the graph of all possible domain names. one node in a portion of the graph of all possible domain names.
Global DNS: Using the short set of facets listed in "Naming system", Global DNS: Using the short set of facets listed in "Naming system",
the global DNS can be defined as follows. Most of the rules here the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
inclusive. In a fully-qualified domain name, the first label inclusive. In a fully-qualified domain name, the first label in
(logically speaking) is 0 octets long; it is the only label whose the ordered list is 0 octets long; it is the only label whose
length may be 0 octets, and it is called the "root" or "root length may be 0 octets, and it is called the "root" or "root
label". A domain name in the global DNS has a maximum total label". A domain name in the global DNS has a maximum total
length of 255 octets in the wire format; the root represents one length of 255 octets in the wire format; the root represents one
octet for this calculation. octet for this calculation.
Format of names -- Names in the global DNS are domain names. Format of names -- Names in the global DNS are domain names.
There are three formats: wire format, presentation format, and There are three formats: wire format, presentation format, and
common display. common display.
The basic wire format for names in the global DNS is a list of The basic wire format for names in the global DNS is a list of
labels with the root label last. Each label is preceded by a labels ordered by decreasing distance from the root, with the root
length octet. [RFC1035] also defines a compression scheme that label last. Each label is preceded by a length octet. [RFC1035]
modifies this format. also defines a compression scheme that modifies this format.
The presentation format for names in the global DNS is a list of The presentation format for names in the global DNS is a list of
labels, encoded as ASCII, with the root label last, and a "." labels ordered by decreasing distance from the root, encoded as
character between each label. In presentation format, a fully- ASCII, with a "." character between each label. In presentation
qualified domain name includes the root label and the associated format, a fully-qualified domain name includes the root label and
separator dot. In presentation format, a fully-qualified domain the associated separator dot. For example, in presentation
name with two additional labels is always shown as "example.tld." format, a fully-qualified domain name with two non-root labels is
instead of "example.tld". [RFC1035] defines a method for showing always shown as "example.tld." instead of "example.tld".
octets that do not display in ASCII. [RFC1035] defines a method for showing octets that do not display
in ASCII.
The common display format is used in applications and free text. The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done. In label and the "." before it is optional and is rarely done. For
common display format, a fully-qualified domain name with two example, in common display format, a fully-qualified domain name
additional labels is usually shown as "example.tld" instead of with two non-root labels is usually shown as "example.tld" instead
"example.tld.". Names in the common display format are normally of "example.tld.". Names in the common display format are
written such that the first label in the ordered list is in the normally written such that the directionality of the writing
last position from the point of view of the directionality of the system presents labels by decreasing distance from the root (so,
writing system (so, in both English and C the first label is the in both English and C the first label in the ordered list is
right-most label; but in Arabic it may be the left-most label, right-most; but in Arabic it may be left-most, depending on local
depending on local conventions). conventions).
Administration of names -- Administration is specified by Administration of names -- Administration is specified by
delegation (see the definition of to "delegation" in Section 6). delegation (see the definition of to "delegation" in Section 6).
Policies for administration of the root zone in the global DNS are Policies for administration of the root zone in the global DNS are
determined by the names operational community, which convenes determined by the names operational community, which convenes
itself in the Internet Corporation for Assigned Names and Numbers itself in the Internet Corporation for Assigned Names and Numbers
(ICANN). The names operational community selects the IANA (ICANN). The names operational community selects the IANA
Functions Operator for the global DNS root zone. At the time this Functions Operator for the global DNS root zone. At the time this
document is published, that operator is Public Technical document is published, that operator is Public Technical
Identifiers (PTI). The name servers that serve the root zone are Identifiers (PTI). The name servers that serve the root zone are
skipping to change at page 7, line 6 skipping to change at page 7, line 9
same name may resolve to different results in different locally same name may resolve to different results in different locally
served DNS zone contexts. The context through which a locally served DNS zone contexts. The context through which a locally
served zone may be explicit, for example, as defined in [RFC6303], served zone may be explicit, for example, as defined in [RFC6303],
or implicit, as defined by local DNS administration and not known or implicit, as defined by local DNS administration and not known
to the resolution client. to the resolution client.
Fully qualified domain name (FQDN): This is often just a clear way 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 of saying the same thing as "domain name of a node", as outlined
above. However, the term is ambiguous. Strictly speaking, a above. However, the term is ambiguous. Strictly speaking, a
fully qualified domain name would include every label, including fully qualified domain name would include every label, including
the final, zero-length label of the root: such a name would be the zero-length label of the root: such a name would be written
written "www.example.net." (note the terminating dot). But "www.example.net." (note the terminating dot). But because every
because every name eventually shares the common root, names are name eventually shares the common root, names are often written
often written relative to the root (such as "www.example.net") and relative to the root (such as "www.example.net") and are still
are still called "fully qualified". This term first appeared in called "fully qualified". This term first appeared in [RFC0819].
[RFC0819]. In this document, names are often written relative to In this document, names are often written relative to the root.
the root.
The need for the term "fully qualified domain name" comes from the The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names existence of partially qualified domain names, which are names
where some of the right-most names are left off and are understood where one or more of the earliest labels in the ordered list are
omitted (for example, "www"). Such relative names are understood
only by context. only by context.
Host name: This term and its equivalent, "hostname", have been Host name: This term and its equivalent, "hostname", have been
widely used but are not defined in [RFC1034], [RFC1035], widely used but are not defined in [RFC1034], [RFC1035],
[RFC1123], or [RFC2181]. The DNS was originally deployed into the [RFC1123], or [RFC2181]. The DNS was originally deployed into the
Host Tables environment as outlined in [RFC0952], and it is likely Host Tables environment as outlined in [RFC0952], and it is likely
that the term followed informally from the definition there. Over that the term followed informally from the definition there. Over
time, the definition seems to have shifted. "Host name" is often 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 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 [RFC1034], the "preferred name syntax". Note that any label in a
skipping to change at page 9, line 20 skipping to change at page 9, line 20
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is its first 12 octets. Many of the 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 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. 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 For example, the response codes are called "RCODEs", the data for a
record is called the "RDATA", and the authoritative answer bit is record is called the "RDATA", and the authoritative answer bit is
often called "the AA flag" or "the AA bit". often called "the AA flag" or "the AA bit".
QNAME The most commonly-used definition is that the QNAME is a field QNAME The most commonly-used rough definition is that the QNAME is a
in the Question section of a query. "A standard query specifies a field in the Question section of a query. "A standard query
target domain name (QNAME), query type (QTYPE), and query class specifies a target domain name (QNAME), query type (QTYPE), and
(QCLASS) and asks for RRs which match." (Quoted from [RFC1034], query class (QCLASS) and asks for RRs which match." (Quoted from
Section 3.7.1.) [RFC1034], Section 3.7.1.). Strictly speaking, the definition
comes from [RFC1035], Section 4.1.2, where the QNAME is defined in
respect of the Question Section. This definition appears to be
applied consistently: the discussion of inverse queries in section
6.4 refers to the "owner name of the query RR and its TTL",
because inverse queries populate the Answer Section and leave the
Question Section empty. (Inverse queries are deprecated in
[RFC3425], and so relevant definitions do not appear in this
document.)
[RFC2308], however, has an alternate definition that puts the [RFC2308], however, has an alternate definition that puts the
QNAME in the answer (or series of answers) instead of the query. QNAME in the answer (or series of answers) instead of the query.
It defines QNAME as: "...the name in the query section of an It defines QNAME as: "...the name in the query section of an
answer, or where this resolves to a CNAME, or CNAME chain, the answer, or where this resolves to a CNAME, or CNAME chain, the
data field of the last CNAME. The last CNAME in this sense is data field of the last CNAME. The last CNAME in this sense is
that which contains a value which does not resolve to another that which contains a value which does not resolve to another
CNAME." CNAME." This definition has a certain internal logic, because of
the way CNAME substitution works and the definition of CNAME. If
a name server does not find an RRset that matches a query, but it
finds the same name in the same class with a CNAME record, then
the name server "includes the CNAME record in the response and
restarts the query at the domain name specified in the data field
of the CNAME record." ([RFC1034] Section 3.6.2). This is made
explicit in the resolution algorithm outlined in Section 4.3.2 of
[RFC1034], which says to "change QNAME to the canonical name in
the CNAME RR, and go back to step 1" in the case of a CNAME RR.
Since a CNAME record explicitly declares that the owner name is
canonically named what is in the RDATA, then there is a way to
view the new name (i.e. the name that was in the RDATA of the
CNAME RR) as also being the QNAME.
This creates a kind of confusion, however, because the answer to a
query that results in CNAME processing contains in the echoed
Question Section one QNAME (the name in the original query), and a
second QNAME that is in the data field of the last CNAME. The
confusion comes from the iterative/recursive mode of resolution,
which finally returns an answer that need not actually have the
same owner name as the QNAME contained in the original query.
To address this potential confusion, it is helpful to distinguish
between three meanings:
* QNAME (original): The name actually sent in the Question
Section in the orignal query, which is always echoed in the
(final) reply in the Question Section when the QR bit is set to
1.
* QNAME (effective): A name actually resolved, which is either
the name originally queried, or a name received in a CNAME
chain response.
* QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain
response.
Some of response codes that are defined in [RFC1035] have acquired Some of response codes that are defined in [RFC1035] have acquired
their own shorthand names. Some common response code names that their own shorthand names. Some common response code names that
appear without reference to the numeric value are "FORMERR", appear without reference to the numeric value are "FORMERR",
"SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
as "Name Error"). All of the RCODEs are listed at as "Name Error"). All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps. uses mixed-case capitalization, while most documents use all-caps.
NODATA: "A pseudo RCODE which indicates that the name is valid for NODATA: "A pseudo RCODE which indicates that the name is valid for
skipping to change at page 12, line 22 skipping to change at page 13, line 16
Class independent: A resource record type whose syntax and semantics Class independent: A resource record type whose syntax and semantics
are the same for every DNS class. A resource record type that is are the same for every DNS class. A resource record type that is
not class independent has different meanings depending on the DNS not class independent has different meanings depending on the DNS
class of the record, or the meaning is undefined for classes other class of the record, or the meaning is undefined for classes other
than IN (class 1, the Internet). than IN (class 1, the Internet).
5. DNS Servers and Clients 5. DNS Servers and Clients
This section defines the terms used for the systems that act as DNS This section defines the terms used for the systems that act as DNS
clients, DNS servers, or both. clients, DNS servers, or both. In the RFCs, DNS servers are
sometimes called "name servers", "nameservers", or just "servers".
There is no formal definition of DNS server, but the RFCs generally
assume that it is an Internet server that listens for queries and
sends responses using the DNS protocol defined in [RFC1035] and its
successors.
For terminology specific to the public DNS root server system, see For terminology specific to the public DNS root server system, see
[RSSAC026]. That document defines terms such as "root server", "root [RSSAC026]. That document defines terms such as "root server", "root
server operator", and terms that are specific to the way that the server operator", and terms that are specific to the way that the
root zone of the public DNS is served. root zone of the public DNS is served.
Resolver: A program "that extract[s] information from name servers Resolver: A program "that extract[s] information from name servers
in response to client requests." (Quoted from [RFC1034], in response to client requests." (Quoted from [RFC1034],
Section 2.4) "The resolver is located on the same machine as the 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 program that requests the resolver's services, but it may need to
consult name servers on other hosts." (Quoted from [RFC1034], consult name servers on other hosts." (Quoted from [RFC1034],
Section 5.1) A resolver performs queries for a name, type, and Section 5.1) A resolver performs queries for a name, type, and
class, and receives answers. The logical function is called class, and receives answers. The logical function is called
"resolution". In practice, the term is usually referring to some "resolution". In practice, the term is usually referring to some
specific type of resolver (some of which are defined below), and specific type of resolver (some of which are defined below), and
understanding the use of the term depends on understanding the understanding the use of the term depends on understanding the
context. context.
A related term is "resolve", which is not formally defined in
[RFC1034] or [RFC1035]. An imputed definition might be "asking a
question that consists of a domain name, class, and type, and
receiving some sort of answer". Similarly, an imputed definition
of "resolution" might be "the answer received from resolving".
Stub resolver: A resolver that cannot perform all resolution itself. Stub resolver: A resolver that cannot perform all resolution itself.
Stub resolvers generally depend on a recursive resolver to Stub resolvers generally depend on a recursive resolver to
undertake the actual resolution function. Stub resolvers are undertake the actual resolution function. Stub resolvers are
discussed but never fully defined in Section 5.3.1 of [RFC1034]. discussed but never fully defined in Section 5.3.1 of [RFC1034].
They are fully defined in Section 6.1.3.1 of [RFC1123]. They are fully defined in Section 6.1.3.1 of [RFC1123].
Iterative mode: A resolution mode of a server that receives DNS Iterative mode: A resolution mode of a server that receives DNS
queries and responds with a referral to another server. queries and responds with a referral to another server.
Section 2.3 of [RFC1034] describes this as "The server refers the Section 2.3 of [RFC1034] describes this as "The server refers the
client to another server and lets the client pursue the query". A client to another server and lets the client pursue the query". A
skipping to change at page 15, line 23 skipping to change at page 16, line 28
Section 2.1). [RFC2136] defines "primary master" as "Master Section 2.1). [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The primary 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 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 NS RR. There is by definition only one primary master server per
zone." The idea of a primary master is only used by [RFC2136], zone." The idea of a primary master is only used by [RFC2136],
and is considered archaic in other parts of the DNS. and is considered archaic in other parts of the DNS.
Stealth server: This is "like a slave server except not listed in an Stealth server: This is "like a slave server except not listed in an
NS RR for the zone." (Quoted from [RFC1996], Section 2.1) NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
Hidden master: A stealth server that is a master for zone transfers. Hidden master: A stealth server that is a primary server for zone
"In this arrangement, the master name server that processes the transfers. "In this arrangement, the master name server that
updates is unavailable to general hosts on the Internet; it is not processes the updates is unavailable to general hosts on the
listed in the NS RRset." (Quoted from [RFC6781], Section 3.4.3.) Internet; it is not listed in the NS RRset." (Quoted from
An earlier RFC, [RFC4641], said that the hidden master's name [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that
appears in the SOA RRs MNAME field, although in some setups, the the hidden master's name "appears in the SOA RRs MNAME field",
name does not appear at all in the public DNS. A hidden master although in some setups, the name does not appear at all in the
can be either a secondary or a primary master. public DNS. A hidden master can also be a secondary server
itself.
Forwarding: The process of one server sending a DNS query with the Forwarding: The process of one server sending a DNS query with the
RD bit set to 1 to another server to resolve that query. RD bit set to 1 to another server to resolve that query.
Forwarding is a function of a DNS resolver; it is different than Forwarding is a function of a DNS resolver; it is different than
simply blindly relaying queries. simply blindly relaying queries.
[RFC5625] does not give a specific definition for forwarding, but [RFC5625] does not give a specific definition for forwarding, but
describes in detail what features a system that forwards need to describes in detail what features a system that forwards need to
support. Systems that forward are sometimes called "DNS proxies", support. Systems that forward are sometimes called "DNS proxies",
but that term has not yet been defined (even in [RFC5625]). but that term has not yet been defined (even in [RFC5625]).
skipping to change at page 16, line 21 skipping to change at page 17, line 26
the user of the stub resolver has selected the policy-implementing the user of the stub resolver has selected the policy-implementing
resolver with the explicit intention of using it to implement the resolver with the explicit intention of using it to implement the
policies. In other cases, policies are imposed without the user policies. In other cases, policies are imposed without the user
of the stub resolver being informed. of the stub resolver being informed.
Open resolver: A full-service resolver that accepts and processes Open resolver: A full-service resolver that accepts and processes
queries from any (or nearly any) stub resolver. This is sometimes queries from any (or nearly any) stub resolver. This is sometimes
also called a "public resolver", although the term "public also called a "public resolver", although the term "public
resolver" is used more with open resolvers that are meant to be resolver" is used more with open resolvers that are meant to be
open, as compared to the vast majority of open resolvers that are open, as compared to the vast majority of open resolvers that are
probably misconfigured to be open. probably misconfigured to be open. Open resolvers are discussed
in [RFC5358]
View: A configuration for a DNS server that allows it to provide View: A configuration for a DNS server that allows it to provide
different answers depending on attributes of the query. different answers depending on attributes of the query.
Typically, views differ by the source IP address of a query, but 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 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 (such as AXFR), whether it is recursive, and so on. Views are
often used to provide more names or different addresses to queries often used to provide more names or different addresses to queries
from "inside" a protected network than to those "outside" that from "inside" a protected network than to those "outside" that
network. Views are not a standardized part of the DNS, but they network. Views are not a standardized part of the DNS, but they
are widely implemented in server software. are widely implemented in server software.
skipping to change at page 24, line 29 skipping to change at page 25, line 39
Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.) unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.)
Opt-out tackles the high costs of securing a delegation to an Opt-out tackles the high costs of securing a delegation to an
insecure zone. When using Opt-Out, names that are an insecure insecure zone. When using Opt-Out, names that are an insecure
delegation (and empty non-terminals that are only derived from delegation (and empty non-terminals that are only derived from
insecure delegations) don't require an NSEC3 record or its insecure delegations) don't require an NSEC3 record or its
corresponding RRSIG records. Opt-Out NSEC3 records are not able corresponding RRSIG records. Opt-Out NSEC3 records are not able
to prove or deny the existence of the insecure delegations. to prove or deny the existence of the insecure delegations.
(Adapted from [RFC7129], Section 5.1) (Adapted from [RFC7129], Section 5.1)
Insecure delegation: "A signed name containing a delegation (NS
RRset), but lacking a DS RRset, signifying a delegation to an
unsigned subzone." (Quoted from [RFC4956], Section 2.)
Zone enumeration: "The practice of discovering the full content of a Zone enumeration: "The practice of discovering the full content of a
zone via successive queries." (Quoted from [RFC5155], zone via successive queries." (Quoted from [RFC5155],
Section 1.3.) This is also sometimes called "zone walking". Zone Section 1.3.) This is also sometimes called "zone walking". Zone
enumeration is different from zone content guessing where the enumeration is different from zone content guessing where the
guesser uses a large dictionary of possible labels and sends guesser uses a large dictionary of possible labels and sends
successive queries for them, or matches the contents of NSEC3 successive queries for them, or matches the contents of NSEC3
records against such a dictionary. records against such a dictionary.
Validation: Validation, in the context of DNSSEC, refers to the Validation: Validation, in the context of DNSSEC, refers to the
following: following:
skipping to change at page 29, line 7 skipping to change at page 31, line 7
12. References 12. References
12.1. Normative References 12.1. Normative References
[IANA_RootFiles] [IANA_RootFiles]
Internet Assigned Numbers Authority, "IANA Root Files", Internet Assigned Numbers Authority, "IANA Root Files",
2016, <http://www.iana.org/domains/root/files>. 2016, <http://www.iana.org/domains/root/files>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>. <https://www.rfc-editor.org/info/rfc882>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc1123>. editor.org/info/rfc1123>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>. <https://www.rfc-editor.org/info/rfc2181>.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997, DOI 10.17487/RFC2182, July 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2182>. editor.org/info/rfc2182>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006, System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<http://www.rfc-editor.org/info/rfc4592>. <https://www.rfc-editor.org/info/rfc4592>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
DOI 10.17487/RFC5358, October 2008, <https://www.rfc-
editor.org/info/rfc5358>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<http://www.rfc-editor.org/info/rfc5730>. <https://www.rfc-editor.org/info/rfc5730>.
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
May 2010, <http://www.rfc-editor.org/info/rfc5855>. May 2010, <https://www.rfc-editor.org/info/rfc5855>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
"Recommendations for the Remediation of Bots in ISP "Recommendations for the Remediation of Bots in ISP
Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
<http://www.rfc-editor.org/info/rfc6561>. <https://www.rfc-editor.org/info/rfc6561>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6781>. editor.org/info/rfc6781>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840, Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013, DOI 10.17487/RFC6840, February 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6840>. editor.org/info/rfc6840>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<http://www.rfc-editor.org/info/rfc6841>. <https://www.rfc-editor.org/info/rfc6841>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6891>. editor.org/info/rfc6891>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7344>. editor.org/info/rfc7344>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
12.2. Informative References 12.2. Informative References
[IANA_Resource_Registry] [IANA_Resource_Registry]
Internet Assigned Numbers Authority, "Resource Record (RR) Internet Assigned Numbers Authority, "Resource Record (RR)
TYPEs", 2017, TYPEs", 2017,
<http://www.iana.org/assignments/dns-parameters/>. <http://www.iana.org/assignments/dns-parameters/>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819, Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982, DOI 10.17487/RFC0819, August 1982, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc819>. editor.org/info/rfc819>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952, host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <http://www.rfc-editor.org/info/rfc952>. October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc1995>. editor.org/info/rfc1995>.
[RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2133, "Basic Socket Interface Extensions for IPv6", RFC 2133,
DOI 10.17487/RFC2133, April 1997, DOI 10.17487/RFC2133, April 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2133>. editor.org/info/rfc2133>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2775>. editor.org/info/rfc2775>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <http://www.rfc-editor.org/info/rfc3172>. September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
DOI 10.17487/RFC3425, November 2002, <https://www.rfc-
editor.org/info/rfc3425>.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April
2004, <http://www.rfc-editor.org/info/rfc3757>. 2004, <https://www.rfc-editor.org/info/rfc3757>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3912>. editor.org/info/rfc3912>.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, DOI 10.17487/RFC4641, September 2006, RFC 4641, DOI 10.17487/RFC4641, September 2006,
<http://www.rfc-editor.org/info/rfc4641>. <https://www.rfc-editor.org/info/rfc4641>.
[RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
October 2006, <http://www.rfc-editor.org/info/rfc4697>. October 2006, <https://www.rfc-editor.org/info/rfc4697>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
(DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
2007, <http://www.rfc-editor.org/info/rfc4956>. 2007, <https://www.rfc-editor.org/info/rfc4956>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>. <https://www.rfc-editor.org/info/rfc5625>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5891>. editor.org/info/rfc5891>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)", Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010, RFC 5892, DOI 10.17487/RFC5892, August 2010,
<http://www.rfc-editor.org/info/rfc5892>. <https://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
<http://www.rfc-editor.org/info/rfc5893>. <https://www.rfc-editor.org/info/rfc5893>.
[RFC5894] Klensin, J., "Internationalized Domain Names for [RFC5894] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Background, Explanation, and Applications (IDNA): Background, Explanation, and
Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
<http://www.rfc-editor.org/info/rfc5894>. <https://www.rfc-editor.org/info/rfc5894>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055, Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011, DOI 10.17487/RFC6055, February 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6055>. editor.org/info/rfc6055>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6265>. editor.org/info/rfc6265>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011, RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>. <https://www.rfc-editor.org/info/rfc6303>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6365>. editor.org/info/rfc6365>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <http://www.rfc-editor.org/info/rfc7129>. February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480, Registration Data Access Protocol (RDAP)", RFC 7480,
DOI 10.17487/RFC7480, March 2015, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7480>. editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", RFC 7481, Registration Data Access Protocol (RDAP)", RFC 7481,
DOI 10.17487/RFC7481, March 2015, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7481>. editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7482>. editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483, Registration Data Access Protocol (RDAP)", RFC 7483,
DOI 10.17487/RFC7483, March 2015, DOI 10.17487/RFC7483, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7483>. editor.org/info/rfc7483>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <http://www.rfc-editor.org/info/rfc7484>. 2015, <https://www.rfc-editor.org/info/rfc7484>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<http://www.rfc-editor.org/info/rfc7485>. <https://www.rfc-editor.org/info/rfc7485>.
[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
Resolver with Priming Queries", BCP 209, RFC 8109, Resolver with Priming Queries", BCP 209, RFC 8109,
DOI 10.17487/RFC8109, March 2017, DOI 10.17487/RFC8109, March 2017, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc8109>. editor.org/info/rfc8109>.
[RSSAC026] [RSSAC026]
Root Server System Advisory Committee (RSSAC), "RSSAC Root Server System Advisory Committee (RSSAC), "RSSAC
Lexicon", 2017, Lexicon", 2017,
<https://www.icann.org/en/system/files/files/rssac- <https://www.icann.org/en/system/files/files/rssac-
026-14mar17-en.pdf>. 026-14mar17-en.pdf>.
Appendix A. Definitions Updated by this Document Appendix A. Definitions Updated by this Document
The following definitions from RFCs are updated by this document: The following definitions from RFCs are updated by this document:
o Forwarder in [RFC2308] o Forwarder in [RFC2308]
o Secure Entry Point (SEP) in [RFC3757] o Secure Entry Point (SEP) in [RFC3757]; note, however, that this
RFC is already obsolete
Appendix B. Definitions First Defined in this Document Appendix B. Definitions First Defined in this Document
The following definitions are first defined in this document: The following definitions are first defined in this document:
o "Alias" in Section 2 o "Alias" in Section 2
o "Apex" in Section 6 o "Apex" in Section 6
o "arpa" in Section 6 o "arpa" in Section 6
skipping to change at page 36, line 28 skipping to change at page 38, line 44
o "TLD" in Section 2 o "TLD" in Section 2
o "Validating resolver" in Section 8 o "Validating resolver" in Section 8
o "Validation" in Section 8 o "Validation" in Section 8
o "View" in Section 5 o "View" in Section 5
o "Zone transfer" in Section 5 o "Zone transfer" in Section 5
Index
A
Alias 8
Anycast 17
Apex 19
Asterisk label 21
Authoritative data 20
Authoritative server 15
Authoritative-only server 15
arpa: Address and Routing Parameter Area Domain 22
C
CNAME 8
Canonical name 8
Child 18
Class independent 13
Closest encloser 21
Closest provable encloser 21
Combined signing key (CSK) 27
D
DNS operator 23
DNSSEC Policy (DP) 28
DNSSEC Practice Statement (DPS) 28
DNSSEC-aware and DNSSEC-unaware 24
Delegation 19
Delegation-centric zone 21
Domain name 4
E
EDNS 11
EPP 23
Empty non-terminals (ENT) 20
F
Fast flux DNS 22
Forward lookup 22
Forwarder 16
Forwarding 16
Full resolver 14
Full-service resolver 14
Fully qualified domain name (FQDN) 7
G
Global DNS 4
Glue records 19
H
Hardware security module (HSM) 28
Hidden master 16
Host name 7
I
IDN 8
In-bailiwick 20
Infrastructure domain 22
Insecure delegation 25
Instance 18
Iterative mode 14
K
Key signing key (KSK) 27
L
Label 4
Locally served DNS zone 6
M
Master file 11
Master server 16
N
NODATA 10
NSEC 25
NSEC3 25
Naming system 3
Negative caching 15
Negative response 11
Next closer name 21
O
OPT 12
Occluded name 22
Open resolver 17
Opt-out 25
Origin 18
Out-of-bailiwick 20
Owner 12
P
Parent 18
Passive DNS 17
Policy-implementing resolver 17
Presentation format 11
Primary master 16
Primary server 16
Priming 14
Private DNS 6
Public suffix 8
R
RDAP 23
RR 11
RRset 11
Recursive mode 14
Recursive resolver 14
Referrals 11
Registrant 23
Registrar 23
Registry 23
Resolver 13
Reverse DNS, reverse lookup 22
Root hints 14
Root zone 20
S
SOA field names 12
Secondary server 15
Secure Entry Point (SEP) 27
Service name 22
Signed zone 24
Signing software 28
Slave server 15
Source of Synthesis 21
Split DNS 18
Stealth server 16
Stub resolver 13
Subdomain 8
T
TLD 7
TTL 12
Trust anchor 28
U
Unsigned zone 24
V
Validating resolver 26
Validation 25
View 17
W
WHOIS 23
Wildcard 21
Wildcard domain name 21
Z
Zone 18
Zone cut 19
Zone enumeration 25
Zone signing key (ZSK) 27
Zone transfer 15
Acknowledgements Acknowledgements
The following is the Acknowledgements for RFC 7719. Additional The following is the Acknowledgements for RFC 7719. Additional
acknowledgements may be added as this draft is worked on. acknowledgements may be added as this draft is worked on.
The authors gratefully acknowledge all of the authors of DNS-related The authors gratefully acknowledge all of the authors of DNS-related
RFCs that proceed this one. Comments from Tony Finch, Stephane RFCs that proceed this one. Comments from Tony Finch, Stephane
Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
 End of changes. 79 change blocks. 
148 lines changed or deleted 376 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/