draft-ietf-dnsop-terminology-bis-08.txt   draft-ietf-dnsop-terminology-bis-09.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 (if approved) Oracle Updates: 2308 (if approved) Oracle
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: May 31, 2018 JPRS Expires: September 6, 2018 JPRS
November 27, 2017 March 5, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-08 draft-ietf-dnsop-terminology-bis-09
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.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
obsolete RFC 7719. It will also update RFC 2308. 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 https://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 May 31, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 Response Codes . . . . . . . . . . . . . . . . . . . . . 8
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 9
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 13 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 24 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 25 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Definitions Updated by this Document . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
Appendix B. Definitions First Defined in this Document . . . . . 38 14.2. Informative References . . . . . . . . . . . . . . . . . 36
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Definitions Updated by this Document . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix B. Definitions First Defined in this Document . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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. (Section 2
Section 2 for a fuller definition.) The protocol and message format gives a definition of "public DNS", which is often what people mean
are defined in [RFC1034] and [RFC1035]. These RFCs defined some when they say "the DNS".) The protocol and message format are
terms, but later documents defined others. Some of the terms from defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,
[RFC1034] and [RFC1035] now have somewhat different meanings than but later documents defined others. Some of the terms from [RFC1034]
they did in 1987. and [RFC1035] now have somewhat different meanings than they did in
1987.
This document collects a wide variety of DNS-related terms. Some of This document collects a wide variety of DNS-related terms. Some of
them have been precisely defined in earlier RFCs, some have been them have been precisely defined in earlier RFCs, some have been
loosely defined in earlier RFCs, and some are not defined in any loosely defined in earlier RFCs, and some are not defined in any
earlier RFC at all. earlier RFC at all.
Most of the definitions here are the consensus definition of the DNS Most of the definitions here are the consensus definition of the DNS
community -- both protocol developers and operators. Some of the community -- both protocol developers and operators. Some of the
definitions differ from earlier RFCs, and those differences are definitions differ from earlier RFCs, and those differences are
noted. In this document, where the consensus definition is the same noted. In this document, where the consensus definition is the same
skipping to change at page 4, line 28 skipping to change at page 4, line 33
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 are not as well-defined as the associated with names", but those are not as well-defined as the
ones listed above. The list here is chosen because it helps ones listed above. The list here is chosen because it helps
describe the DNS and naming systems similar to the DNS. describe the DNS and naming systems similar to 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 this definition has the same
has the same practical result as the definition here. Using graph practical result as the definition here. Using graph theory, a
theory, a domain name is a list of labels identifying a portion domain name is a list of labels identifying a portion along one
along one edge of a directed acyclic graph. A domain name can be edge of a directed acyclic graph. A domain name can be relative
relative to other parts of the tree, or it can be fully qualified to parts of the tree, or it can be fully qualified (in which case,
(in which case, it begins at the common root of the graph). 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
skipping to change at page 5, line 46 skipping to change at page 5, line 48
example, in common display format, a fully-qualified domain name example, in common display format, a fully-qualified domain name
with two non-root labels is usually shown as "example.tld" instead with two non-root labels is usually shown as "example.tld" instead
of "example.tld.". Names in the common display format are of "example.tld.". Names in the common display format are
normally written such that the directionality of the writing normally written such that the directionality of the writing
system presents labels by decreasing distance from the root (so, system presents labels by decreasing distance from the root (so,
in both English and C the first label in the ordered list is in both English and C the first label in the ordered list is
right-most; but in Arabic it may be left-most, depending on local right-most; but in Arabic it may be left-most, 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 "delegation" in Section 7).
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
provided by independent root operators. Other zones in the global provided by independent root operators. Other zones in the global
DNS have their own policies for administration. DNS have their own policies for administration.
Types of data that can be associated with names -- A name can have Types of data that can be associated with names -- A name can have
zero or more resource records associated with it. There are zero or more resource records associated with it. There are
numerous types of resource records with unique data structures numerous types of resource records with unique data structures
defined in many different RFCs and in the IANA registry at defined in many different RFCs and in the IANA registry at
[IANA_Resource_Registry]. [IANA_Resource_Registry].
Types of metadata for names -- Any name that is published in the Types of metadata for names -- Any name that is published in the
DNS appears as a set of resource records (see the definition of DNS appears as a set of resource records (see the definition of
"RRset" in Section 4). Some names do not themselves have data "RRset" in Section 5). Some names do not themselves have data
associated with them in the DNS, but "appear" in the DNS anyway associated with them in the DNS, but "appear" in the DNS anyway
because they form part of a longer name that does have data because they form part of a longer name that does have data
associated with it (see the defintion of "empty non-terminals" in associated with it (see the defintion of "empty non-terminals" in
Section 6). Section 7).
Protocol for getting data from a name -- The protocol described in Protocol for getting data from a name -- The protocol described in
[RFC1035]. [RFC1035].
Context for resolving a name -- The global DNS root zone Context for resolving a name -- The global DNS root zone
distributed by PTI. distributed by PTI.
Private DNS: Names that use the protocol described in [RFC1035] but Private DNS: Names that use the protocol described in [RFC1035] but
that do not rely on the global DNS root zone, or names that are that do not rely on the global DNS root zone, or names that are
otherwise not generally available on the Internet but are using otherwise not generally available on the Internet but are using
the protocol described in [RFC1035]. A system can use both the the protocol described in [RFC1035]. A system can use both the
global DNS and one or more private DNS systems; for example, see global DNS and one or more private DNS systems; for example, see
"Split DNS" in Section 7. "Split DNS" in Section 6.
Note that domain names that do not appear in the DNS, and that are Note that domain names that do not appear in the DNS, and that are
intended never to be looked up using the DNS protocol, are not intended never to be looked up using the DNS protocol, are not
part of the global DNS or a private DNS even though they are part of the global DNS or a private DNS even though they are
domain names. domain names.
Locally served DNS zone: A locally served DNS zone is a special case Locally served DNS zone: A locally served DNS zone is a special case
of private DNS. Names are resolved using the DNS protocol in a of private DNS. Names are resolved using the DNS protocol in a
local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that
are locally served zones. Resolution of names through locally are locally served zones. Resolution of names through locally
skipping to change at page 7, line 19 skipping to change at page 7, line 21
the zero-length label of the root: such a name would be written the zero-length label of the root: such a name would be written
"www.example.net." (note the terminating dot). But because every "www.example.net." (note the terminating dot). But because every
name eventually shares the common root, names are often written name eventually shares the common root, names are often written
relative to the root (such as "www.example.net") and are still relative to the root (such as "www.example.net") and are still
called "fully qualified". This term first appeared in [RFC0819]. called "fully qualified". This term first appeared in [RFC0819].
In this document, names are often written relative to the root. In this document, names are often written relative to 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 one or more of the earliest labels in the ordered list are where one or more of the earliest labels in the ordered list are
omitted (for example, "www"). Such relative names are understood omitted (for example, a name of "www" derived from
only by context. "www.example.net"). Such relative names are understood 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
domain name can contain any octet value; hostnames are generally domain name can contain any octet value; hostnames are generally
skipping to change at page 7, line 47 skipping to change at page 7, line 50
first label of an FQDN, such as "printer" in first label of an FQDN, such as "printer" in
"printer.admin.example.com". (Sometimes this is formalized in "printer.admin.example.com". (Sometimes this is formalized in
configuration in operating systems.) In addition, people configuration in operating systems.) In addition, people
sometimes use this term to describe any name that refers to a sometimes use this term to describe any name that refers to a
machine, and those might include labels that do not conform to the machine, and those might include labels that do not conform to the
"preferred name syntax". "preferred name syntax".
TLD: A Top-Level Domain, meaning a zone that is one layer below the 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 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 point of view of the DNS, about TLDs. Most of them are also
delegation-centric zones, and there are significant policy issues delegation-centric zones (defined in Section 7, and there are
around their operation. TLDs are often divided into sub-groups significant policy issues around their operation. TLDs are often
such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level divided into sub-groups such as Country Code Top-Level Domains
Domains (gTLDs), and others; the division is a matter of policy, (ccTLDs), Generic Top-Level Domains (gTLDs), and others; the
and beyond the scope of this document. division is a matter of policy, and beyond the scope of this
document.
IDN: The common abbreviation for "Internationalized Domain Name". IDN: The common abbreviation for "Internationalized Domain Name".
The IDNA protocol is the standard mechanism for handling domain The IDNA protocol is the standard mechanism for handling domain
names with non-ASCII characters in applications in the DNS. The names with non-ASCII characters in applications in the DNS. The
current standard, normally called "IDNA2008", is defined in current standard, normally called "IDNA2008", is defined in
[RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These
documents define many IDN-specific terms such as "LDH label", documents define many IDN-specific terms such as "LDH label",
"A-label", and "U-label". [RFC6365] defines more terms that "A-label", and "U-label". [RFC6365] defines more terms that
relate to internationalization (some of which relate to IDNs), and relate to internationalization (some of which relate to IDNs), and
[RFC6055] has a much more extensive discussion of IDNs, including [RFC6055] has a much more extensive discussion of IDNs, including
skipping to change at page 8, line 37 skipping to change at page 8, line 41
as an alias, and specifies the corresponding canonical name in the as an alias, and specifies the corresponding canonical name in the
RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2)
This usage of the word "canonical" is related to the mathematical This usage of the word "canonical" is related to the mathematical
concept of "canonical form". concept of "canonical form".
CNAME: "It is traditional to refer to the owner of a CNAME record as 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 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of
'canonical name', and the owner of a CNAME record is an alias, not 'canonical name', and the owner of a CNAME record is an alias, not
a canonical name." (Quoted from [RFC2181], Section 10.1.1) a canonical name." (Quoted from [RFC2181], Section 10.1.1)
Public suffix: "A domain that is controlled by a public registry." 3. DNS Response Codes
(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.
There is nothing inherent in a domain name to indicate whether it Some of response codes that are defined in [RFC1035] have acquired
is a public suffix. One resource for identifying public suffixes their own shorthand names. All of the RCODEs are listed at
is the Public Suffix List (PSL) maintained by Mozilla [IANA_Resource_Registry], although that site uses mixed-case
(http://publicsuffix.org/). capitalization, while most documents use all-caps. Some of the
common names are described here, but the official list is in the IANA
registry.
For example, at the time this document is published, the "com.au" NOERROR: "No error condition" (Quoted from [RFC1035],
domain is listed as a public suffix in the PSL. (Note that this Section 4.1.1.)
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 was the case
with the "uk" TLD in 2014.
3. DNS Header and Response Codes FORMERR: "Format error - The name server was unable to interpret the
query." (Quoted from [RFC1035], Section 4.1.1.)
SERVFAIL: "Server failure - The name server was unable to process
this query due to a problem with the name server." (Quoted from
[RFC1035], Section 4.1.1.)
NXDOMAIN: "Name Error - Meaningful only for responses from an
authoritative name server, this code signifies that the domain
name referenced in the query does not exist." (Quoted from
[RFC1035], Section 4.1.1.)
NOTIMP: "Not Implemented - The name server does not support the
requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)
REFUSED: "Refused - The name server refuses to perform the specified
operation for policy reasons. For example, a name server may not
wish to provide the information to the particular requester, or a
name server may not wish to perform a particular operation (e.g.,
zone transfer) for particular data." (Quoted from [RFC1035],
Section 4.1.1.)
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
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.
4. DNS Transactions
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 rough definition is that the QNAME is a QNAME: The most commonly-used rough definition is that the QNAME is
field in the Question section of a query. "A standard query a field in the Question section of a query. "A standard query
specifies a target domain name (QNAME), query type (QTYPE), and specifies a target domain name (QNAME), query type (QTYPE), and
query class (QCLASS) and asks for RRs which match." (Quoted from query class (QCLASS) and asks for RRs which match." (Quoted from
[RFC1034], Section 3.7.1.). Strictly speaking, the definition [RFC1034], Section 3.7.1.). Strictly speaking, the definition
comes from [RFC1035], Section 4.1.2, where the QNAME is defined in comes from [RFC1035], Section 4.1.2, where the QNAME is defined in
respect of the Question Section. This definition appears to be respect of the Question Section. This definition appears to be
applied consistently: the discussion of inverse queries in section applied consistently: the discussion of inverse queries in section
6.4 refers to the "owner name of the query RR and its TTL", 6.4 refers to the "owner name of the query RR and its TTL",
because inverse queries populate the Answer Section and leave the because inverse queries populate the Answer Section and leave the
Question Section empty. (Inverse queries are deprecated in Question Section empty. (Inverse queries are deprecated in
[RFC3425], and so relevant definitions do not appear in this [RFC3425], and so relevant definitions do not appear in this
skipping to change at page 10, line 31 skipping to change at page 11, line 18
1. 1.
* QNAME (effective): A name actually resolved, which is either * QNAME (effective): A name actually resolved, which is either
the name originally queried, or a name received in a CNAME the name originally queried, or a name received in a CNAME
chain response. chain response.
* QNAME (final): The name actually resolved, which is either the * QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain name actually queried or else the last name in a CNAME chain
response. response.
Some of response codes that are defined in [RFC1035] have acquired Note that, because the definition in [RFC2308] is actually for a
their own shorthand names. All of the RCODEs are listed at different concept than what was in [RFC1034], it would have be
http://www.iana.org/assignments/dns-parameters, although that site better if [RFC2308] had used a different name for that concept.
uses mixed-case capitalization, while most documents use all-caps. In general use today, QNAME almost always means what is defined
Some of the names are described here, but the official list is in the above as "QNAME (original)".
IANA registry.
NOERROR: "No error condition" (Quoted from [RFC1035],
Section 4.1.1.)
FORMERR: "Format error - The name server was unable to interpret the
query." (Quoted from [RFC1035], Section 4.1.1.)
SERVFAIL: "Server failure - The name server was unable to process
this query due to a problem with the name server." (Quoted from
[RFC1035], Section 4.1.1.)
NXDOMAIN: "Name Error - Meaningful only for responses from an
authoritative name server, this code signifies that the domain
name referenced in the query does not exist." (Quoted from
[RFC1035], Section 4.1.1.)
NOTIMP: "Not Implemented - The name server does not support the
requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)
REFUSED: "Refused - The name server refuses to perform the specified Referrals: A type of response in which a server, signalling that it
operation for policy reasons. For example, a name server may not is not (completely) authoritative for an answer, provides the
wish to provide the information to the particular requester, or a querying resolver with an alternative place to send its query.
name server may not wish to perform a particular operation (e.g., Referrals can be partial.
zone transfer) for particular data." (Quoted from [RFC1035],
Section 4.1.1.)
NODATA: "A pseudo RCODE which indicates that the name is valid for A referral arises when a server is not performing recursive
the given class, but there are no records of the given type. A service while answering a query. It appears in step 3(b) of the
NODATA response has to be inferred from the answer." (Quoted from algorithm in [RFC1034], Section 4.3.2.
[RFC2308], Section 1.) "NODATA is indicated by an answer with the
RCODE set to NOERROR and no relevant answers in the answer
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. There are two types of referral response. The first is a downward
However, this is a mistake, given that NXRRSET is a specific error referral (sometimes described as "delegation response"), where the
code defined in [RFC2136]. server is authoritative for some portion of the QNAME. The
authority section RRset's RDATA contains the name servers
specified at the referred-to zone cut. In normal DNS operation,
this kind of response is required in order to find names beneath a
delegation. The bare use of "referral" means this kind of
referral, and many people believe that this is the only legitimate
kind of referral in the DNS.
Negative response: A response that indicates that a particular RRset The second is an upward referral (sometimes described as "root
does not exist, or whose RCODE indicates the nameserver cannot referral"), where the server is not authoritative for any portion
answer. Sections 2 and 7 of [RFC2308] describe the types of of the QNAME. When this happens, the referred-to zone in the
negative responses in detail. authority section is usually the root zone (.). In normal DNS
operation, this kind of response is not required for resolution or
for correctly answering any query. There is no requirement that
any server send upward referrals. Some people regard upward
referrals as a sign of a misconfiguration or error. Upward
referrals always need some sort of qualifier (such as "upward" or
"root"), and are never identified by the bare word "referral".
Referrals: \[\[ This text is being modified in the WG and a changed A response that has only a referral contains an empty answer
definition will appear in a future draft. \]\] section. It contains the NS RRset for the referred-to zone in the
authority section. It may contain RRs that provide addresses in
the additional section. The AA bit is clear.
Data from the authority section of a non-authoritative answer. In the case where the query matches an alias, and the server is
[RFC1035] Section 2.1 defines "authoritative" data. However, not authoritative for the target of the alias but it is
referrals at zone cuts (defined in Section 6) are not authoritative for some name above the target of the alias, the
authoritative. Referrals may be zone cut NS resource records and resolution algorithm will produce a response that contains both
their glue records. NS records on the parent side of a zone cut the authoritative answer for the alias, and also a referral. Such
are an authoritative delegation, but are normally not treated as a partial answer and referral response has data in the answer
authoritative data. In general, a referral is a way for a server section. It has the NS RRset for the referred-to zone in the
to send an answer saying that the server does not know the answer, authority section. It may contain RRs that provide addresses in
but knows where the query should be directed in order to get an the additional section. The AA bit is set, because the first name
answer. Historically, many authoritative servers answered with a in the answer section matches the QNAME and the server is
referral to the root zone when queried for a name for which they authoritative for that answer (see [RFC1035], Section 4.1.1).
were not authoritative, but this practice has declined.
4. Resource Records 5. Resource Records
RR: An acronym for resource record. ([RFC1034], Section 3.6.) RR: An acronym for resource record. ([RFC1034], Section 3.6.)
RRset: A set of resource records with the same label, class and RRset: A set of resource records with the same label, class and
type, but with different data. (Definition from [RFC2181]) Also type, but with different data. (Definition from [RFC2181]) Also
spelled RRSet in some documents. As a clarification, "same label" spelled RRSet in some documents. As a clarification, "same label"
in this definition means "same owner name". In addition, in this definition means "same owner name". In addition,
[RFC2181] states that "the TTLs of all RRs in an RRSet must be the [RFC2181] states that "the TTLs of all RRs in an RRSet must be the
same". (This definition is definitely not the same as "the same". (This definition is definitely not the same as "the
response one gets to a query for QTYPE=ANY", which is an response one gets to a query for QTYPE=ANY", which is an
unfortunate misunderstanding.) unfortunate misunderstanding.)
Master file: "Master files are text files that contain RRs in text Master file: "Master files are text files that contain RRs in text
form. Since the contents of a zone can be expressed in the form form. Since the contents of a zone can be expressed in the form
of a list of RRs a master file is most often used to define a of a list of RRs a master file is most often used to define a
zone, though it can be used to list a cache's contents." zone, though it can be used to list a cache's contents."
([RFC1035], Section 5.) ([RFC1035], Section 5.) Master files are sometimes called "zone
files".
Presentation format: The text format used in master files. This Presentation format: The text format used in master files. This
format is shown but not formally defined in [RFC1034] and format is shown but not formally defined in [RFC1034] and
[RFC1035]. The term "presentation format" first appears in [RFC1035]. The term "presentation format" first appears in
[RFC4034]. [RFC4034].
EDNS: The extension mechanisms for DNS, defined in [RFC6891]. EDNS: The extension mechanisms for DNS, defined in [RFC6891].
Sometimes called "EDNS0" or "EDNS(0)" to indicate the version Sometimes called "EDNS0" or "EDNS(0)" to indicate the version
number. EDNS allows DNS clients and servers to specify message number. EDNS allows DNS clients and servers to specify message
sizes larger than the original 512 octet limit, to expand the sizes larger than the original 512 octet limit, to expand the
skipping to change at page 13, line 26 skipping to change at page 13, line 44
consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the
time interval (in seconds) that the resource record may be cached time interval (in seconds) that the resource record may be cached
before it should be discarded". (Quoted from [RFC1035], before it should be discarded". (Quoted from [RFC1035],
Section 4.1.3). Despite being defined for a resource record, the 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 TTL of every resource record in an RRset is required to be the
same ([RFC2181], Section 5.2). same ([RFC2181], Section 5.2).
The reason that the TTL is the maximum time to live is that a 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 cache operator might decide to shorten the time to live for
operational purposes, such as if there is a policy to disallow TTL operational purposes, such as if there is a policy to disallow TTL
values over a certain number. Also, if a value is flushed from values over a certain number. Some servers are known to ignore
the cache when its value is still positive, the value effectively the TTL on some RRsets (such as when the authoritative data has a
becomes zero. Some servers are known to ignore the TTL on some very short TTL) even though this is against the advice in RFC
RRsets (such as when the authoritative data has a very short TTL) 1035. An RRset can be flushed from the cache before the end of
even though this is against the advice in RFC 1035. the TTL interval, at which point the value of the TTL becomes
unknown because the RRset with which it was associated no longer
exists.
There is also the concept of a "default TTL" for a zone, which can There is also the concept of a "default TTL" for a zone, which can
be a configuration parameter in the server software. This is be a configuration parameter in the server software. This is
often expressed by a default for the entire server, and a default 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 for a zone using the $TTL directive in a zone file. The $TTL
directive was added to the master file format by [RFC2308]. directive was added to the master file format by [RFC2308].
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 Address records: Records whose type is A or AAAA. [RFC2181]
informally defines these as "(A, AAAA, etc)". Note that new types
of address records could be defined in the future.
6. 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. In the RFCs, DNS servers are clients, DNS servers, or both. In the RFCs, DNS servers are
sometimes called "name servers", "nameservers", or just "servers". sometimes called "name servers", "nameservers", or just "servers".
There is no formal definition of DNS server, but the RFCs generally There is no formal definition of DNS server, but the RFCs generally
assume that it is an Internet server that listens for queries and assume that it is an Internet server that listens for queries and
sends responses using the DNS protocol defined in [RFC1035] and its sends responses using the DNS protocol defined in [RFC1035] and its
successors. successors.
For terminology specific to the public DNS root server system, see For terminology specific to the public DNS root server system, see
skipping to change at page 14, line 39 skipping to change at page 15, line 16
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
resolver that works in iterative mode is sometimes called an resolver that works in iterative mode is sometimes called an
"iterative resolver". "iterative resolver". See also "iterative resolution" later in
this section.
Recursive mode: A resolution mode of a server that receives DNS Recursive mode: A resolution mode of a server that receives DNS
queries and either responds to those queries from a local cache or queries and either responds to those queries from a local cache or
sends queries to other servers in order to get the final answers sends queries to other servers in order to get the final answers
to the original queries. Section 2.3 of [RFC1034] describes this to the original queries. Section 2.3 of [RFC1034] describes this
as "The first server pursues the query for the client at another as "The first server pursues the query for the client at another
server". A server operating in recursive mode may be thought of server". A server operating in recursive mode may be thought of
as having a name server side (which is what answers the query) and as having a name server side (which is what answers the query) and
a resolver side (which performs the resolution function). Systems a resolver side (which performs the resolution function). Systems
operating in this mode are commonly called "recursive servers". operating in this mode are commonly called "recursive servers".
skipping to change at page 16, line 8 skipping to change at page 16, line 33
another server and lets the client pursue the query there. (See another server and lets the client pursue the query there. (See
Section 2.3 of [RFC1034].) Section 2.3 of [RFC1034].)
In iterative resolution, the client repeatedly makes non-recursive In iterative resolution, the client repeatedly makes non-recursive
queries and follows referrals and/or aliases. The iterative queries and follows referrals and/or aliases. The iterative
resolution algorithm is described in Section 5.3.3 of [RFC1034]. resolution algorithm is described in Section 5.3.3 of [RFC1034].
Priming: "The act of finding the list of root servers from a Priming: "The act of finding the list of root servers from a
configuration that lists some or all of the purported IP addresses configuration that lists some or all of the purported IP addresses
of some or all of those root servers." (Quoted from [RFC8109], of some or all of those root servers." (Quoted from [RFC8109],
Section 2.) Priming is most often done from a configuration Section 2.) In order to operate in recursive mode, a resolver
setting that contains a list of authoritative servers for the root needs to know the address of at least one root server. Priming is
zone. most often done from a configuration setting that contains a list
of authoritative servers for the root zone.
Root hints: "Operators who manage a DNS recursive resolver typically Root hints: "Operators who manage a DNS recursive resolver typically
need to configure a 'root hints file'. This file contains the need to configure a 'root hints file'. This file contains the
names and IP addresses of the authoritative name servers for the names and IP addresses of the authoritative name servers for the
root zone, so the software can bootstrap the DNS resolution root zone, so the software can bootstrap the DNS resolution
process. For many pieces of software, this list comes built into process. For many pieces of software, this list comes built into
the software." (Quoted from [IANA_RootFiles]) the software." (Quoted from [IANA_RootFiles]) This file is often
used in priming.
Negative caching: "The storage of knowledge that something does not Negative caching: "The storage of knowledge that something does not
exist, cannot give an answer, or does not give an answer." exist, cannot give an answer, or does not give an answer."
(Quoted from [RFC2308], Section 1) (Quoted from [RFC2308], Section 1)
Authoritative server: "A server that knows the content of a DNS zone Authoritative server: "A server that knows the content of a DNS zone
from local knowledge, and thus can answer queries about that zone from local knowledge, and thus can answer queries about that zone
without needing to query other servers." (Quoted from [RFC2182], without needing to query other servers." (Quoted from [RFC2182],
Section 2.) It is a system that responds to DNS queries with Section 2.) It is a system that responds to DNS queries with
information about zones for which it has been configured to answer information about zones for which it has been configured to answer
skipping to change at page 16, line 46 skipping to change at page 17, line 25
Authoritative-only server: A name server that only serves Authoritative-only server: A name server that only serves
authoritative data and ignores requests for recursion. It will authoritative data and ignores requests for recursion. It will
"not normally generate any queries of its own. Instead, it "not normally generate any queries of its own. Instead, it
answers non-recursive queries from iterative resolvers looking for answers non-recursive queries from iterative resolvers looking for
information in zones it serves." (Quoted from [RFC4697], information in zones it serves." (Quoted from [RFC4697],
Section 2.4) Section 2.4)
Zone transfer: The act of a client requesting a copy of a zone and Zone transfer: The act of a client requesting a copy of a zone and
an authoritative server sending the needed information. (See an authoritative server sending the needed information. (See
Section 6 for a description of zones.) There are two common Section 7 for a description of zones.) There are two common
standard ways to do zone transfers: the AXFR ("Authoritative standard ways to do zone transfers: the AXFR ("Authoritative
Transfer") mechanism to copy the full zone (described in Transfer") mechanism to copy the full zone (described in
[RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
only parts of the zone that have changed (described in [RFC1995]). only parts of the zone that have changed (described in [RFC1995]).
Many systems use non-standard methods for zone transfer outside Many systems use non-standard methods for zone transfer outside
the DNS protocol. the DNS protocol.
Secondary server: "An authoritative server which uses zone transfer Secondary server: "An authoritative server which uses zone transfer
to retrieve the zone" (Quoted from [RFC1996], Section 2.1). to retrieve the zone" (Quoted from [RFC1996], Section 2.1).
[RFC2182] describes secondary servers in detail. Although early Secondary servers are also discussed in [RFC1034]. [RFC2182]
DNS RFCs such as [RFC1996] referred to this as a "slave", the describes secondary servers in more detail. Although early DNS
current common usage has shifted to calling it a "secondary". RFCs such as [RFC1996] referred to this as a "slave", the current
Secondary servers are also discussed in [RFC1034]. common usage has shifted to calling it a "secondary".
Slave server: See secondary server. Slave server: See secondary server.
Primary server: "Any authoritative server configured to be the Primary server: "Any authoritative server configured to be the
source of zone transfer for one or more [secondary] servers" source of zone transfer for one or more [secondary] servers"
(Quoted from [RFC1996], Section 2.1) or, more specifically, "an (Quoted from [RFC1996], Section 2.1) or, more specifically, "an
authoritative server configured to be the source of AXFR or IXFR authoritative server configured to be the source of AXFR or IXFR
data for one or more [secondary] servers" (Quoted from [RFC2136]). data for one or more [secondary] servers" (Quoted from [RFC2136]).
Although early DNS RFCs such as [RFC1996] referred to this as a Primary servers are also discussed in [RFC1034]. Although early
"master", the current common usage has shifted to "primary". DNS RFCs such as [RFC1996] referred to this as a "master", the
Primary servers are also discussed in [RFC1034]. current common usage has shifted to "primary".
Master server: See primary server. Master server: See primary server.
Primary master: \[\[ There is active discussion in the WG of this Primary master: "The primary master is named in the zone's SOA MNAME
term. It will be resolved in a future version of the draft. \]\] 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.
"The primary master is named in the zone's SOA MNAME field and The idea of a primary master is only used in [RFC1996] and
optionally by an NS RR". (Quoted from [RFC1996], Section 2.1). [RFC2136]. A modern interpretation of the term "primary master"
[RFC2136] defines "primary master" as "Master server at the root is a server that is both authoritative for a zone and that gets
of the AXFR/IXFR dependency graph. The primary master is named in its updates to the zone from configuration (such as a master file)
the zone's SOA MNAME field and optionally by an NS RR. There is or from UPDATE transactions.
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 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 primary server for zone Hidden master: A stealth server that is a primary server for zone
transfers. "In this arrangement, the master name server that transfers. "In this arrangement, the master name server that
processes the updates is unavailable to general hosts on the processes the updates is unavailable to general hosts on the
Internet; it is not listed in the NS RRset." (Quoted from Internet; it is not listed in the NS RRset." (Quoted from
[RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that
the hidden master's name "appears in the SOA RRs MNAME field", the hidden master's name "appears in the SOA RRs MNAME field",
skipping to change at page 18, line 4 skipping to change at page 18, line 35
processes the updates is unavailable to general hosts on the processes the updates is unavailable to general hosts on the
Internet; it is not listed in the NS RRset." (Quoted from Internet; it is not listed in the NS RRset." (Quoted from
[RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that
the hidden master's name "appears in the SOA RRs MNAME field", 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 although in some setups, the name does not appear at all in the
public DNS. A hidden master can also be a secondary server public DNS. A hidden master can also be a secondary server
itself. 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 needs 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]).
Forwarder: Section 1 of [RFC2308] describes a forwarder as "a Forwarder: Section 1 of [RFC2308] describes a forwarder as "a
nameserver used to resolve queries instead of directly using the nameserver used to resolve queries instead of directly using the
authoritative nameserver chain". [RFC2308] further says "The authoritative nameserver chain". [RFC2308] further says "The
forwarder typically either has better access to the internet, or forwarder typically either has better access to the internet, or
maintains a bigger cache which may be shared amongst many maintains a bigger cache which may be shared amongst many
resolvers." That definition appears to suggest that forwarders resolvers." That definition appears to suggest that forwarders
normally only query authoritative servers. In current use, normally only query authoritative servers. In current use,
skipping to change at page 19, line 6 skipping to change at page 19, line 35
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.
Passive DNS: A mechanism to collect DNS data by storing DNS Passive DNS: A mechanism to collect DNS data by storing DNS
transactions from name servers. Some of these systems also responses from name servers. Some of these systems also collect
collect the DNS queries associated with the responses. Passive the DNS queries associated with the responses, although doing so
DNS databases can be used to answer historical questions about DNS raises some privacy concerns. Passive DNS databases can be used
zones such as which answers were witnessed at what times in the to answer historical questions about DNS zones such as which
past. Passive DNS databases allow searching of the stored records values were present at a given time in the past, or when a name
on keys other than just the name and type, such as "find all names was spotted first. Passive DNS databases allow searching of the
which have A records of a particular value". stored records on keys other than just the name and type, such as
"find all names which have A records of a particular value".
Anycast: "The practice of making a particular service address Anycast: "The practice of making a particular service address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations." datagrams sent are routed to one of several available locations."
(Quoted from [RFC4786], Section 2) (Quoted from [RFC4786], Section 2)
Instance: "When anycast routing is used to allow more than one Instance: "When anycast routing is used to allow more than one
server to have the same IP address, each one of those servers is server to have the same IP address, each one of those servers is
commonly referred to as an 'instance'." "An instance of a server, commonly referred to as an 'instance'." "An instance of a server,
such as a root server, is often referred to as an 'Anycast such as a root server, is often referred to as an 'Anycast
instance'." (Quoted from [RSSAC026]) instance'." (Quoted from [RSSAC026])
Split DNS: "Where a corporate network serves up partly or completely Split DNS: "Where a corporate network serves up partly or completely
different DNS inside and outside its firewall. There are many different DNS inside and outside its firewall. There are many
possible variants on this; the basic point is that the possible variants on this; the basic point is that the
correspondence between a given FQDN (fully qualified domain name) correspondence between a given FQDN (fully qualified domain name)
and a given IPv4 address is no longer universal and stable over and a given IPv4 address is no longer universal and stable over
long periods." (Quoted from [RFC2775], Section 3.8) long periods." (Quoted from [RFC2775], Section 3.8)
6. Zones 7. Zones
This section defines terms that are used when discussing zones that This section defines terms that are used when discussing zones that
are being served or retrieved. are being served or retrieved.
Zone: "Authoritative information is organized into units called Zone: "Authoritative information is organized into units called
'zones', and these zones can be automatically distributed to the 'zones', and these zones can be automatically distributed to the
name servers which provide redundant service for the data in a name servers which provide redundant service for the data in a
zone." (Quoted from [RFC1034], Section 2.4) zone." (Quoted from [RFC1034], Section 2.4)
Child: "The entity on record that has the delegation of the domain Child: "The entity on record that has the delegation of the domain
skipping to change at page 20, line 49 skipping to change at page 21, line 33
ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as
'zone cut'." 'zone cut'."
Delegation: The process by which a separate zone is created in the Delegation: The process by which a separate zone is created in the
name space beneath the apex of a given domain. Delegation happens 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. 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 Delegation inherently happens at a zone cut. The term is also
commonly a noun: the new zone that is created by the act of commonly a noun: the new zone that is created by the act of
delegating. delegating.
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
in the notion of authoritative data, because the parent-side NS
records authoritatively indicate the delegation, even though they
are not themselves authoritative data.
Lame delegation: "A lame delegations exists when a nameserver is
delegated responsibility for providing nameservice for a zone (via
NS records) but is not performing nameservice for that zone
(usually because it is not set up as a primary or secondary for
the zone)." (Definition from [RFC1912], Section 2.8)
Glue records: "[Resource records] which are not part of the Glue records: "[Resource records] which are not part of the
authoritative data [of the zone], and are address resource records authoritative data [of the zone], and are address resource records
for the [name servers in subzones]. These RRs are only necessary 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 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 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 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 a name server's address, we should contact the server using the
address we wish to learn." (Definition from [RFC1034], address we wish to learn." (Definition from [RFC1034],
Section 4.2.1) Section 4.2.1)
A later definition is that glue "includes any record in a zone A later definition is that glue "includes any record in a zone
file that is not properly part of that zone, including nameserver file that is not properly part of that zone, including nameserver
records of delegated sub-zones (NS records), address records that records of delegated sub-zones (NS records), address records that
accompany those NS records (A, AAAA, etc), and any other stray accompany those NS records (A, AAAA, etc), and any other stray
data that might appear" ([RFC2181], Section 5.4.1). Although glue data that might appear" ([RFC2181], Section 5.4.1). Although glue
is sometimes used today with this wider definition in mind, the is sometimes used today with this wider definition in mind, the
context surrounding the [RFC2181] definition suggests it is context surrounding the [RFC2181] definition suggests it is
intended to apply to the use of glue within the document itself intended to apply to the use of glue within the document itself
and not necessarily beyond. and not necessarily beyond.
In-bailiwick: An adjective to describe a name server whose name is Bailiwick: "In-bailiwick" is an adjective to describe a name server
either subordinate to or (rarely) the same as the zone origin. whose name is either subordinate to or (rarely) the same as the
In-bailiwick name servers may have glue records in their parent origin of the zone that contains the delegation to the name
zone (using the first of the definitions of "glue records" in the server. In-bailiwick name servers may have glue records in their
definition above). "In-bailiwick" names are divided into two type parent zone (using the first of the definitions of "glue records"
of name server names: "in-domain" names and "sibling domain" in the definition above). (The term "bailiwick" means the
names: district or territory where a bailiff or policeman has
jusrisdiction.)
* In-domain -- an adjective to describe a name server whose name "In-bailiwick" names are divided into two type of name server
is either subordinate to or (rarely) the same as the owner name names: "in-domain" names and "sibling domain" names.
of the NS resource records. An in-domain name server name MUST
* In-domain: an adjective to describe a name server whose name is
either subordinate to or (rarely) the same as the owner name of
the NS resource records. An in-domain name server name MUST
have glue records or name resolution fails. For example, a have glue records or name resolution fails. For example, a
delegation for "child.example.com" may have "in-domain" name delegation for "child.example.com" may have "in-domain" name
server name "ns.child.example.com". server name "ns.child.example.com".
* Sibling domain: -- a name server's name that is either * Sibling domain: a name server's name that is either subordinate
subordinate to or (rarely) the same as the zone origin and not to or (rarely) the same as the zone origin and not subordinate
subordinate to or the same as the owner name of the NS resource to or the same as the owner name of the NS resource records.
records. Glue records for sibling domains are allowed, but not Glue records for sibling domains are allowed, but not
necessary. For example, a delegation for "child.example.com" necessary. For example, a delegation for "child.example.com"
in "example.com" zone may have "sibling" name server name in "example.com" zone may have "sibling" name server name
"ns.another.example.com". "ns.another.example.com".
Out-of-bailiwick: The antonym of in-bailiwick. An adjective to "Out-of-bailiwick" is the antonym of in-bailiwick. An adjective
describe a name server whose name is not subordinate to or the to describe a name server whose name is not subordinate to or the
same as the zone origin. Glue records for out-of-bailiwick name same as the zone origin. Glue records for out-of-bailiwick name
servers are useless. servers are useless. Following table shows examples of delegation
types.
Authoritative data: "All of the RRs attached to all of the nodes Delegation |Parent|Name Server Name | Type
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], com | . |a.gtld-servers.net|in-bailiwick / sibling domain
Section 4.2.1) It is noted that this definition might net | . |a.gtld-servers.net|in-bailiwick / in-domain
inadvertently also include any NS records that appear in the zone, example.org| org |ns.example.org |in-bailiwick / in-domain
even those that might not truly be authoritative because there are example.org| org |ns.ietf.org |in-bailiwick / sibling domain
identical NS RRs below the zone cut. This reveals the ambiguity example.org| org |ns.example.com |out-of-bailiwick
in the notion of authoritative data, because the parent-side NS example.jp | jp |ns.example.jp |in-bailiwick / in-domain
records authoritatively indicate the delegation, even though they example.jp | jp |ns.example.ne.jp |in-bailiwick / sibling domain
are not themselves authoritative data. example.jp | jp |ns.example.com |out-of-bailiwick
Root zone: The zone of a DNS-based tree whose apex is the zero- Root zone: The zone of a DNS-based tree whose apex is the zero-
length label. Also sometimes called "the DNS root". length label. Also sometimes called "the DNS root".
Empty non-terminals (ENT): "Domain names that own no resource Empty non-terminals (ENT): "Domain names that own no resource
records but have subdomains that do." (Quoted from [RFC4592], records but have subdomains that do." (Quoted from [RFC4592],
Section 2.2.2.) A typical example is in SRV records: in the name 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 "_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 no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
RRset. RRset.
Delegation-centric zone: A zone that consists mostly of delegations Delegation-centric zone: A zone that consists mostly of delegations
to child zones. This term is used in contrast to a zone that 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 might have some delegations to child zones, but also has many data
resource records for the zone itself and/or for child zones. The resource records for the zone itself and/or for child zones. The
term is used in [RFC4956] and [RFC5155], but is not defined there. 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].
Asterisk label: "The first octet is the normal label type and length
for a 1-octet-long label, and the second octet is the ASCII
representation for the '*' character. A descriptive name of a
label equaling that value is an 'asterisk label'." (Quoted from
[RFC4592], Section 2.1.1)
Wildcard domain name: "A 'wildcard domain name' is defined by having
its initial (i.e., leftmost or least significant) label be
asterisk label." (Quoted from [RFC4592], Section 2.1.1)
Closest encloser: "The longest existing ancestor of a name."
(Quoted from [RFC5155], Section 1.3) An earlier definition is "The
node in the zone's tree of existing domain names that has the most
labels matching the query name (consecutively, counting from the
root label downward). Each match is a 'label match' and the order
of the labels is the same." (Quoted from [RFC4592],
Section 3.3.1)
Closest provable encloser: "The longest ancestor of a name that can
be proven to exist. Note that this is only different from the
closest encloser in an Opt-Out zone." (Quoted from [RFC5155],
Section 1.3)
Next closer name: "The name one label longer than the closest
provable encloser of a name." (Quoted from [RFC5155],
Section 1.3)
Source of Synthesis: "The source of synthesis is defined in the
context of a query process as that wildcard domain name
immediately descending from the closest encloser, provided that
this wildcard domain name exists. 'Immediately descending' means
that the source of synthesis has a name of the form: <asterisk
label>.<closest encloser>." (Quoted from [RFC4592],
Section 3.3.1)
Occluded name: "The addition of a delegation point via dynamic Occluded name: "The addition of a delegation point via dynamic
update will render all subordinate domain names to be in a limbo, update will render all subordinate domain names to be in a limbo,
still part of the zone, but not available to the lookup process. still part of the zone, but not available to the lookup process.
The addition of a DNAME resource record has the same impact. The The addition of a DNAME resource record has the same impact. The
subordinate names are said to be 'occluded'." (Quoted from subordinate names are said to be 'occluded'." (Quoted from
[RFC5936], Section 3.5) [RFC5936], Section 3.5)
Fast flux DNS: This "occurs when a domain is found in DNS using A 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 records to multiple IP addresses, each of which has a very short
Time-to-Live (TTL) value associated with it. This means that the Time-to-Live (TTL) value associated with it. This means that the
skipping to change at page 24, line 6 skipping to change at page 24, line 20
Forward lookup: "Hostname-to-address translation". (Quoted from Forward lookup: "Hostname-to-address translation". (Quoted from
[RFC2133], Section 6) [RFC2133], Section 6)
arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain
was originally established as part of the initial deployment of was originally established as part of the initial deployment of
the DNS, to provide a transition mechanism from the Host Tables the DNS, to provide a transition mechanism from the Host Tables
that were common in the ARPANET, as well as a home for the IPv4 that were common in the ARPANET, as well as a home for the IPv4
reverse mapping domain. During 2000, the abbreviation was reverse mapping domain. During 2000, the abbreviation was
redesignated to 'Address and Routing Parameter Area' in the hope redesignated to 'Address and Routing Parameter Area' in the hope
of reducing confusion with the earlier network name." (Quoted of reducing confusion with the earlier network name." (Quoted
from [RFC3172], Section 2.) from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a
domain whose "role is to support the operating infrastructure of
Infrastructure domain: A domain whose "role is to support the the Internet". (Quoted from [RFC3172], Section 2.)
operating infrastructure of the Internet". (Quoted from
[RFC3172], Section 2.)
Service name: "Service names are the unique key in the Service Name Service name: "Service names are the unique key in the Service Name
and Transport Protocol Port Number registry. This unique symbolic and Transport Protocol Port Number registry. This unique symbolic
name for a service may also be used for other purposes, such as in name for a service may also be used for other purposes, such as in
DNS SRV records." (Quoted from [RFC6335], Section 5.) DNS SRV records." (Quoted from [RFC6335], Section 5.)
7. Registration Model 8. Wildcards
Wildcard: [RFC1034] defined "wildcard", but in a way that turned out
to be confusing to implementers. For an extended discussion of
wildcards, including clearer definitions, see [RFC4592]. 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)
Asterisk label: "The first octet is the normal label type and length
for a 1-octet-long label, and the second octet is the ASCII
representation for the '*' character. A descriptive name of a
label equaling that value is an 'asterisk label'." (Quoted from
[RFC4592], Section 2.1.1)
Wildcard domain name: "A 'wildcard domain name' is defined by having
its initial (i.e., leftmost or least significant) label be
asterisk label." (Quoted from [RFC4592], Section 2.1.1)
Closest encloser: "The longest existing ancestor of a name."
(Quoted from [RFC5155], Section 1.3) An earlier definition is "The
node in the zone's tree of existing domain names that has the most
labels matching the query name (consecutively, counting from the
root label downward). Each match is a 'label match' and the order
of the labels is the same." (Quoted from [RFC4592],
Section 3.3.1)
Closest provable encloser: "The longest ancestor of a name that can
be proven to exist. Note that this is only different from the
closest encloser in an Opt-Out zone." (Quoted from [RFC5155],
Section 1.3)
Next closer name: "The name one label longer than the closest
provable encloser of a name." (Quoted from [RFC5155],
Section 1.3)
Source of Synthesis: "The source of synthesis is defined in the
context of a query process as that wildcard domain name
immediately descending from the closest encloser, provided that
this wildcard domain name exists. 'Immediately descending' means
that the source of synthesis has a name of the form: <asterisk
label>.<closest encloser>." (Quoted from [RFC4592],
Section 3.3.1)
9. Registration Model
Registry: The administrative operation of a zone that allows Registry: The administrative operation of a zone that allows
registration of names within that zone. People often use this registration of names within that zone. People often use this
term to refer only to those organizations that perform term to refer only to those organizations that perform
registration in large delegation-centric zones (such as TLDs); but registration in large delegation-centric zones (such as TLDs); but
formally, whoever decides what data goes into a zone is the formally, whoever decides what data goes into a zone is the
registry for that zone. This definition of "registry" is from a registry for that zone. This definition of "registry" is from a
DNS point of view; for some zones, the policies that determine 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 what can go in the zone are decided by superior zones and not the
registry operator. registry operator.
skipping to change at page 25, line 17 skipping to change at page 26, line 25
RDAP protocol and data format are meant as a replacement for RDAP protocol and data format are meant as a replacement for
WHOIS. WHOIS.
DNS operator: An entity responsible for running DNS servers. For a DNS operator: An entity responsible for running DNS servers. For a
zone's authoritative servers, the registrant may act as their own zone's authoritative servers, the registrant may act as their own
DNS operator, or their registrar may do it on their behalf, or DNS operator, or their registrar may do it on their behalf, or
they may use a third-party operator. For some zones, the registry they may use a third-party operator. For some zones, the registry
function is performed by the DNS operator plus other entities who function is performed by the DNS operator plus other entities who
decide about the allowed contents of the zone. decide about the allowed contents of the zone.
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 (which are described in detail in [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.
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 was the case
with the "uk" TLD in 2014.
Subordinate and Superordinate: These terms are introduced in Subordinate and Superordinate: These terms are introduced in
[RFC3731] but not defined there. Instead, they are given in [RFC3731] for use in the registration model, but not defined
examples. "For example, domain name 'example.com' has a there. Instead, they are given in examples. "For example, domain
superordinate relationship to host name ns1.example.com'." "For name 'example.com' has a superordinate relationship to host name
example, host ns1.example1.com is a subordinate host of domain ns1.example.com'." "For example, host ns1.example1.com is a
example1.com, but it is a not a subordinate host of domain subordinate host of domain example1.com, but it is a not a
example2.com." (Quoted from [RFC3731], Section 1.1.) These terms subordinate host of domain example2.com." (Quoted from [RFC3731],
are strictly ways of referring to the relationship standing of two Section 1.1.) These terms are strictly ways of referring to the
domains where one is a subdomain of the other. relationship standing of two domains where one is a subdomain of
the other.
8. General DNSSEC 10. General DNSSEC
Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
[RFC5155]. The terms that have caused confusion in the DNS community [RFC5155]. The terms that have caused confusion in the DNS community
are highlighted here. are highlighted here.
DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
some RFCs, have not been formally defined. However, Section 2 of some RFCs, have not been formally defined. However, Section 2 of
[RFC4033] defines many types of resolvers and validators, [RFC4033] defines many types of resolvers and validators,
including "non-validating security-aware stub resolver", "non- including "non-validating security-aware stub resolver", "non-
validating stub resolver", "security-aware name server", validating stub resolver", "security-aware name server",
skipping to change at page 27, line 22 skipping to change at page 29, line 9
unsigned subzone." (Quoted from [RFC4956], Section 2.) 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 one of
following: the following:
* Checking the validity of DNSSEC signatures * Checking the validity of DNSSEC signatures
* Checking the validity of DNS responses, such as those including * Checking the validity of DNS responses, such as those including
authenticated denial of existence authenticated denial of existence
* Building an authentication chain from a trust anchor to a DNS * Building an authentication chain from a trust anchor to a DNS
response or individual DNS RRsets in a response response or individual DNS RRsets in a response
The first two definitions above consider only the validity of The first two definitions above consider only the validity of
skipping to change at page 28, line 26 skipping to change at page 30, line 13
Section 3.1). Section 3.1).
The term "verification", when used, is usually synonym for The term "verification", when used, is usually synonym for
"validation". "validation".
Validating resolver: A security-aware recursive name server, Validating resolver: A security-aware recursive name server,
security-aware resolver, or security-aware stub resolver that is security-aware resolver, or security-aware stub resolver that is
applying at least one of the definitions of validation (above), as applying at least one of the definitions of validation (above), as
appropriate to the resolution context. For the same reason that appropriate to the resolution context. For the same reason that
the generic term "resolver" is sometimes ambiguous and needs to be the generic term "resolver" is sometimes ambiguous and needs to be
evaluated in context (see Section 5), "validating resolver" is a evaluated in context (see Section 6), "validating resolver" is a
context-sensitive term. context-sensitive term.
Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
RRset in a zone."(Quoted from [RFC6781], Section 3.1) RRset in a zone."(Quoted from [RFC6781], Section 3.1)
Zone signing key (ZSK): "DNSSEC keys that can be used to sign all 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 the RRsets in a zone that require signatures, other than the apex
DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note
roles KSK and ZSK are not mutually exclusive: a single key can be that a ZSK is sometimes used to sign the apex DNSKEY RRset.
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 Combined signing key (CSK): "In cases where the differentiation
between the KSK and ZSK is not made, i.e., where keys have the 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 role of both KSK and ZSK, we talk about a Single-Type Signing
Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes
called a "combined signing key" or CSK. It is operational called a "combined signing key" or CSK. It is operational
practice, not protocol, that determines whether a particular key practice, not protocol, that determines whether a particular key
is a ZSK, a KSK, or a CSK. is a ZSK, a KSK, or a CSK.
Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be
skipping to change at page 29, line 42 skipping to change at page 31, line 27
DNSSEC Practice Statement (DPS): "A practices disclosure document DNSSEC Practice Statement (DPS): "A practices disclosure document
that may support and be a supplemental document to the DNSSEC that may support and be a supplemental document to the DNSSEC
Policy (if such exists), and it states how the management of a Policy (if such exists), and it states how the management of a
given zone implements procedures and controls at a high level." given zone implements procedures and controls at a high level."
(Quoted from [RFC6841], Section 2) (Quoted from [RFC6841], Section 2)
Hardware security module (HSM): A specialized piece of hardware that Hardware security module (HSM): A specialized piece of hardware that
is used to create keys for signatures and to sign messages. In is used to create keys for signatures and to sign messages. In
DNSSEC, HSMs are often used to hold the private keys for KSKs and DNSSEC, HSMs are often used to hold the private keys for KSKs and
ZSKs and to create the RRSIG records at periodic intervals. ZSKs and to create the signatures used in RRSIG records at
periodic intervals.
Signing software: Authoritative DNS servers that supports DNSSEC Signing software: Authoritative DNS servers that support DNSSEC
often contains software that facilitates the creation and often contain software that facilitates the creation and
maintenance of DNSSEC signatures in zones. There is also stand- maintenance of DNSSEC signatures in zones. There is also stand-
alone software that can be used to sign a zone regardless of alone software that can be used to sign a zone regardless of
whether the authoritative server itself supports signing. whether the authoritative server itself supports signing.
Sometimes signing software can support particular HSMs as part of Sometimes signing software can support particular HSMs as part of
the signing process. the signing process.
9. DNSSEC States 11. DNSSEC States
A validating resolver can determine that a response is in one of four A validating resolver can determine that a response is in one of four
states: secure, insecure, bogus, or indeterminate. These states are states: secure, insecure, bogus, or indeterminate. These states are
defined in [RFC4033] and [RFC4035], although the two definitions defined in [RFC4033] and [RFC4035], although the two definitions
differ a bit. This document makes no effort to reconcile the two differ a bit. This document makes no effort to reconcile the two
definitions, and takes no position as to whether they need to be definitions, and takes no position as to whether they need to be
reconciled. reconciled.
Section 5 of [RFC4033] says: Section 5 of [RFC4033] says:
skipping to change at page 31, line 34 skipping to change at page 33, line 34
DNSSEC RRs indicate should be present. This case may indicate DNSSEC RRs indicate should be present. This case may indicate
an attack but may also indicate a configuration error or some an attack but may also indicate a configuration error or some
form of data corruption. form of data corruption.
Indeterminate: An RRset for which the resolver is not able to Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver determine whether the RRset should be signed, as the resolver
is not able to obtain the necessary DNSSEC RRs. This can occur is not able to obtain the necessary DNSSEC RRs. This can occur
when the security-aware resolver is not able to contact when the security-aware resolver is not able to contact
security-aware name servers for the relevant zones. security-aware name servers for the relevant zones.
10. Security Considerations 12. Security Considerations
These definitions do not change any security considerations for the These definitions do not change any security considerations for the
DNS. DNS.
11. IANA Considerations 13. IANA Considerations
None. None.
12. References 14. References
12.1. Normative References 14.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,
<https://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,
<https://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, <https://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, <https://www.rfc- DOI 10.17487/RFC1123, October 1989,
editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
<https://www.rfc-editor.org/info/rfc1912>.
[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, <https://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,
<https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC2182, July 1997,
editor.org/info/rfc2182>. <https://www.rfc-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,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", RFC 3731, DOI 10.17487/RFC3731, Domain Name Mapping", RFC 3731, DOI 10.17487/RFC3731,
March 2004, <https://www.rfc-editor.org/info/rfc3731>. March 2004, <https://www.rfc-editor.org/info/rfc3731>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 33, line 26 skipping to change at page 35, line 31
System", RFC 4592, DOI 10.17487/RFC4592, July 2006, System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://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,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358,
DOI 10.17487/RFC5358, October 2008, <https://www.rfc- DOI 10.17487/RFC5358, October 2008,
editor.org/info/rfc5358>. <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,
<https://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, <https://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,
<https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC6781, December 2012,
editor.org/info/rfc6781>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC6840, February 2013,
editor.org/info/rfc6840>. <https://www.rfc-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,
<https://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, <https://www.rfc- DOI 10.17487/RFC6891, April 2013,
editor.org/info/rfc6891>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7344, September 2014,
editor.org/info/rfc7344>. <https://www.rfc-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, <https://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
12.2. Informative References 14.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, <https://www.rfc- DOI 10.17487/RFC0819, August 1982,
editor.org/info/rfc819>. <https://www.rfc-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, <https://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, <https://www.rfc- DOI 10.17487/RFC1995, August 1996,
editor.org/info/rfc1995>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC2133, April 1997,
editor.org/info/rfc2133>. <https://www.rfc-editor.org/info/rfc2133>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000, <https://www.rfc- DOI 10.17487/RFC2775, February 2000,
editor.org/info/rfc2775>. <https://www.rfc-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, <https://www.rfc-editor.org/info/rfc3172>. September 2001, <https://www.rfc-editor.org/info/rfc3172>.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
DOI 10.17487/RFC3425, November 2002, <https://www.rfc- DOI 10.17487/RFC3425, November 2002,
editor.org/info/rfc3425>. <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, <https://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, <https://www.rfc- DOI 10.17487/RFC3912, September 2004,
editor.org/info/rfc3912>. <https://www.rfc-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,
<https://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, <https://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
skipping to change at page 36, line 7 skipping to change at page 38, line 12
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC5891, August 2010,
editor.org/info/rfc5891>. <https://www.rfc-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,
<https://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,
<https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC6055, February 2011,
editor.org/info/rfc6055>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC6265, April 2011,
editor.org/info/rfc6265>. <https://www.rfc-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,
<https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC6365, September 2011,
editor.org/info/rfc6365>. <https://www.rfc-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, <https://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, <https://www.rfc- DOI 10.17487/RFC7480, March 2015,
editor.org/info/rfc7480>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7481, March 2015,
editor.org/info/rfc7481>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7482, March 2015,
editor.org/info/rfc7482>. <https://www.rfc-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, <https://www.rfc- DOI 10.17487/RFC7483, March 2015,
editor.org/info/rfc7483>. <https://www.rfc-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, <https://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,
<https://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, <https://www.rfc- DOI 10.17487/RFC8109, March 2017,
editor.org/info/rfc8109>. <https://www.rfc-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/
026-14mar17-en.pdf>. rssac-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]; note, however, that this o Secure Entry Point (SEP) in [RFC3757]; note, however, that this
RFC is already obsolete 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 7
o "arpa" in Section 6 o "arpa" in Section 7
o "Class independent" in Section 4 o "Class independent" in Section 5
o "Delegation-centric zone" in Section 6 o "Delegation-centric zone" in Section 7
o "Delegation" in Section 6 o "Delegation" in Section 7
o "DNS operator" in Section 7 o "DNS operator" in Section 9
o "DNSSEC-aware" in Section 8 o "DNSSEC-aware" in Section 10
o "DNSSEC-unaware" in Section 8 o "DNSSEC-unaware" in Section 10
o "Forwarding" in Section 5 o "Forwarding" in Section 6
o "Full resolver" in Section 5 o "Full resolver" in Section 6
o "Fully qualified domain name" in Section 2 o "Fully qualified domain name" in Section 2
o "Global DNS" in Section 2 o "Global DNS" in Section 2
o "Hardware Security Module (HSM)" in Section 8 o "Hardware Security Module (HSM)" in Section 10
o "Host name" in Section 2 o "Host name" in Section 2
o "IDN" in Section 2 o "IDN" in Section 2
o "In-bailiwick" in Section 6 o "In-bailiwick" in Section 7
o "Label" in Section 2 o "Label" in Section 2
o "Locally served DNS zone" in Section 2 o "Locally served DNS zone" in Section 2
o "Naming system" in Section 2 o "Naming system" in Section 2
o "Negative response" in Section 3 o "Negative response" in Section 3
o "Open resolver" in Section 5 o "Open resolver" in Section 6
o "Out-of-bailiwick" in Section 6
o "Passive DNS" in Section 5 o "Out-of-bailiwick" in Section 7
o "Policy-implementing resolver" in Section 5 o "Passive DNS" in Section 6
o "Presentation format" in Section 4 o "Policy-implementing resolver" in Section 6
o "Priming" in Section 5 o "Presentation format" in Section 5
o "Priming" in Section 6
o "Private DNS" in Section 2 o "Private DNS" in Section 2
o "Recursive resolver" in Section 5 o "Recursive resolver" in Section 6
o "Referrals" in Section 3 o "Referrals" in Section 4
o "Registrant" in Section 7 o "Registrant" in Section 9
o "Registrar" in Section 7 o "Registrar" in Section 9
o "Registry" in Section 7 o "Registry" in Section 9
o "Root zone" in Section 6 o "Root zone" in Section 7
o "Secure Entry Point (SEP)" in Section 8 o "Secure Entry Point (SEP)" in Section 10
o "Signing software" in Section 8 o "Signing software" in Section 10
o "Stub resolver" in Section 5 o "Stub resolver" in Section 6
o "TLD" in Section 2 o "TLD" in Section 2
o "Validating resolver" in Section 8 o "Validating resolver" in Section 10
o "Validation" in Section 8 o "Validation" in Section 10
o "View" in Section 5 o "View" in Section 6
o "Zone transfer" in Section 5 o "Zone transfer" in Section 6
Index Index
A A
Address records 14
Alias 8 Alias 8
Anycast 19 Anycast 19
Apex 20 Apex 21
Asterisk label 22 Asterisk label 24
Authoritative data 21 Authoritative data 21
Authoritative server 16 Authoritative server 16
Authoritative-only server 16 Authoritative-only server 17
arpa: Address and Routing Parameter Area Domain 23 arpa: Address and Routing Parameter Area Domain 24
C C
CNAME 8 CNAME 8
Canonical name 8 Canonical name 8
Child 19 Child 20
Class independent 13 Class independent 14
Closest encloser 22 Closest encloser 24
Closest provable encloser 23 Closest provable encloser 25
Combined signing key (CSK) 28 Combined signing key (CSK) 30
D D
DNS operator 25 DNS operator 26
DNSSEC Policy (DP) 29 DNSSEC Policy (DP) 31
DNSSEC Practice Statement (DPS) 29 DNSSEC Practice Statement (DPS) 31
DNSSEC-aware and DNSSEC-unaware 25 DNSSEC-aware and DNSSEC-unaware 27
Delegation 20 Delegation 21
Delegation-centric zone 22 Delegation-centric zone 23
Domain name 4 Domain name 4
E E
EDNS 12 EDNS 12
EPP 24 EPP 25
Empty non-terminals (ENT) 22 Empty non-terminals (ENT) 23
F F
FORMERR 10 FORMERR 9
Fast flux DNS 23 Fast flux DNS 23
Forward lookup 23 Forward lookup 24
Forwarder 18 Forwarder 18
Forwarding 17 Forwarding 18
Full resolver 15 Full resolver 15
Full-service resolver 15 Full-service resolver 15
Fully qualified domain name (FQDN) 7 Fully qualified domain name (FQDN) 7
G G
Global DNS 4 Global DNS 4
Glue records 20 Glue records 21
H H
Hardware security module (HSM) 29 Hardware security module (HSM) 31
Hidden master 17 Hidden master 18
Host name 7 Host name 7
I I
IDN 8 IDN 8
In-bailiwick 21 In-bailiwick 22
Infrastructure domain 24 Insecure delegation 28
Insecure delegation 27
Instance 19 Instance 19
Iterative mode 14 Iterative mode 15
Iterative query 15 Iterative query 16
Iterative resolution 15 Iterative resolution 16
K K
Key signing key (KSK) 28 Key signing key (KSK) 30
L L
Label 4 Label 4
Lame delegation 21
Locally served DNS zone 6 Locally served DNS zone 6
M M
Master file 12 Master file 12
Master server 17 Master server 17
N N
NODATA 11 NODATA 9
NOERROR 10 NOERROR 8
NOTIMP 11 NOTIMP 9
NSEC 26 NSEC 28
NSEC3 26 NSEC3 28
NXDOMAIN 10 NXDOMAIN 9
Naming system 3 Naming system 3
Negative caching 16 Negative caching 16
Negative response 11 Negative response 9
Next closer name 23 Next closer name 25
Non-recursive query 15 Non-recursive query 16
O O
OPT 12 OPT 13
Occluded name 23 Occluded name 23
Open resolver 18 Open resolver 19
Opt-out 26 Opt-out 28
Origin 20 Origin 20
Out-of-bailiwick 21 Out-of-bailiwick 22
Owner 12 Owner 13
P P
Parent 19 Parent 20
Passive DNS 19 Passive DNS 19
Policy-implementing resolver 18 Policy-implementing resolver 19
Presentation format 12 Presentation format 12
Primary master 17 Primary master 18
Primary server 17 Primary server 17
Priming 16 Priming 16
Private DNS 6 Private DNS 6
Public suffix 8 Public suffix 26
Q
QNAME 10
R R
RDAP 25 RDAP 26
REFUSED 11 REFUSED 9
RR 12 RR 12
RRset 12 RRset 12
Recursive mode 14 Recursive mode 15
Recursive query 15 Recursive query 15
Recursive resolver 15 Recursive resolver 15
Referrals 11 Referrals 11
Registrant 24 Registrant 25
Registrar 24 Registrar 25
Registry 24 Registry 25
Resolver 14 Resolver 14
Reverse DNS, reverse lookup 23 Reverse DNS, reverse lookup 24
Root hints 16 Root hints 16
Root zone 22 Root zone 23
S S
SERVFAIL 10 SERVFAIL 9
SOA field names 12 SOA field names 13
Secondary server 17 Secondary server 17
Secure Entry Point (SEP) 28 Secure Entry Point (SEP) 30
Service name 24 Service name 24
Signed zone 25 Signed zone 27
Signing software 29 Signing software 31
Slave server 17 Slave server 17
Source of Synthesis 23 Source of Synthesis 25
Split DNS 19 Split DNS 20
Stealth server 17 Stealth server 18
Stub resolver 14 Stub resolver 15
Subdomain 8 Subdomain 8
Subordinate 25 Subordinate 26
Superordinate 25 Superordinate 26
T T
TLD 7 TLD 7
TTL 13 TTL 13
Trust anchor 29 Trust anchor 31
U U
Unsigned zone 26 Unsigned zone 27
V V
Validating resolver 28 Validating resolver 30
Validation 27 Validation 29
View 18 View 19
W W
WHOIS 24 WHOIS 26
Wildcard 22 Wildcard 24
Wildcard domain name 22 Wildcard domain name 24
Z Z
Zone 19 Zone 20
Zone cut 20 Zone cut 21
Zone enumeration 27 Zone enumeration 28
Zone signing key (ZSK) 28 Zone signing key (ZSK) 30
Zone transfer 16 Zone transfer 17
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,
John Klensin, David Black, and many others in the DNSOP Working Group John Klensin, David Black, and many others in the DNSOP Working Group
helped shape RFC 7719. helped shape RFC 7719.
Additional people contributed to this document, including: John Additional people contributed to this document, including: Bob
Dickinson, Bob Harold, Peter Koch, [[ MORE NAMES WILL APPEAR HERE AS Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin
Hoffmann, Paul Vixie, Peter Koch, [[ MORE NAMES WILL APPEAR HERE AS
FOLKS CONTRIBUTE]]. FOLKS CONTRIBUTE]].
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
Andrew Sullivan Andrew Sullivan
 End of changes. 161 change blocks. 
432 lines changed or deleted 522 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/