draft-ietf-dnsop-terminology-bis-05.txt   draft-ietf-dnsop-terminology-bis-06.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
Intended status: Best Current Practice Dyn Updates: 2308, 3757 (if approved) Oracle
Expires: September 14, 2017 K. Fujiwara Intended status: Best Current Practice K. Fujiwara
JPRS Expires: January 2, 2018 JPRS
March 13, 2017 July 1, 2017
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-05 draft-ietf-dnsop-terminology-bis-06
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
This document will be the successor to RFC 7719. This document will be the successor to RFC 7719, and thus will
obsolete RFC 7719. It will also update RFC 2308 and RFC 3758.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 10 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 10
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 12 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 12
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 21 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 21
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 22 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 22
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 26 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Definitions Updated by this Document . . . . . . . . 34 Appendix A. Definitions Updated by this Document . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Definitions First Defined in this Document . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (See whose messages in both directions have the same format. (See
Section 2 for a fuller definition.) The protocol and message format Section 2 for a fuller definition.) The protocol and message format
are defined in [RFC1034] and [RFC1035]. These RFCs defined some are defined in [RFC1034] and [RFC1035]. These RFCs defined some
terms, but later documents defined others. Some of the terms from terms, but later documents defined others. Some of the terms from
[RFC1034] and [RFC1035] now have somewhat different meanings than [RFC1034] and [RFC1035] now have somewhat different meanings than
they did in 1987. they did in 1987.
skipping to change at page 3, line 20 skipping to change at page 3, line 22
are defined in early DNS RFCs now have definitions that are generally are defined in early DNS RFCs now have definitions that are generally
agreed to, but that are different from the original definitions. agreed to, but that are different from the original definitions.
Therefore, this document is a substantial revision to [RFC7719]. Therefore, this document is a substantial revision to [RFC7719].
The terms are organized loosely by topic. Some definitions are for The terms are organized loosely by topic. Some definitions are for
new terms for things that are commonly talked about in the DNS new terms for things that are commonly talked about in the DNS
community but that never had terms defined for them. community but that never had terms defined for them.
Other organizations sometimes define DNS-related terms their own way. Other organizations sometimes define DNS-related terms their own way.
For example, the W3C defines "domain" at For example, the W3C defines "domain" at
https://specs.webplatform.org/url/webspecs/develop/. https://specs.webplatform.org/url/webspecs/develop/. The Root Server
System Advisory Committee (RSSAC) has a good lexicon [RSSAC026].
Note that there is no single consistent definition of "the DNS". It Note that there is no single consistent definition of "the DNS". It
can be considered to be some combination of the following: a commonly can be considered to be some combination of the following: a commonly
used naming scheme for objects on the Internet; a distributed used naming scheme for objects on the Internet; a distributed
database representing the names and certain properties of these database representing the names and certain properties of these
objects; an architecture providing distributed maintenance, objects; an architecture providing distributed maintenance,
resilience, and loose coherency for this database; and a simple resilience, and loose coherency for this database; and a simple
query-response protocol (as mentioned below) implementing this query-response protocol (as mentioned below) implementing this
architecture. Section 2 defines "global DNS" and "private DNS" as a architecture. Section 2 defines "global DNS" and "private DNS" as a
way to deal with these differing definitions. way to deal with these differing definitions.
skipping to change at page 4, line 22 skipping to change at page 4, line 24
Note that this list is a small subset of facets that people have Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming agree on a good set of facets that can be used to compare naming
systems. For example, other facets might include "protocol to systems. For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data update data in a name", "privacy of names", and "privacy of data
associated with names", but those do not not have a clear associated with names", but those do not not have a clear
definitions as the ones listed above. The list here is chosen definitions as the ones listed above. The list here is chosen
because it helps describe the DNS and naming systems similar to because it helps describe the DNS and naming systems similar to
the DNS. the DNS.
Domain name: An ordered list of zero or more labels. Domain name: An ordered list of one or more labels.
Note that this is a definition independent of the DNS RFCs, and Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS. the definition here also applies to systems other than the DNS.
[RFC1034] defines the "domain name space" using mathematical trees [RFC1034] defines the "domain name space" using mathematical trees
and their nodes in graph theory, and the definition in [RFC1034] and their nodes in graph theory, and the definition in [RFC1034]
has the same practical result as the definition here. Using graph has the same practical result as the definition here. Using graph
theory, a domain name is a list of labels identifying a portion theory, a domain name is a list of labels identifying a portion
along one edge of an acyclic directed graph. A domain name can be along one edge of an acyclic directed graph. A domain name can be
relative to other parts of the tree, or it can be fully qualified relative to other parts of the tree, or it can be fully qualified
(in which case, it ends at the common root of the graph). (in which case, it ends at the common root of the graph).
skipping to change at page 5, line 4 skipping to change at page 5, line 7
portion of a domain name. Using graph theory, a label identifies portion of a domain name. Using graph theory, a label identifies
one node in a portion of the graph of all possible domain names. one node in a portion of the graph of all possible domain names.
Global DNS: Using the short set of facets listed in "Naming system", Global DNS: Using the short set of facets listed in "Naming system",
the global DNS can be defined as follows. Most of the rules here the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
inclusive. In a fully-qualified domain name, the first label is 0 inclusive. In a fully-qualified domain name, the first label
octets long; it is the only label whose length may be 0 octets, (logically speaking) is 0 octets long; it is the only label whose
and it is called the "root" or "root label". A domain name in the length may be 0 octets, and it is called the "root" or "root
global DNS has a maximum total length of 255 octets in the wire label". A domain name in the global DNS has a maximum total
format; the root represents one octet for this calculation. length of 255 octets in the wire format; the root represents one
octet for this calculation.
Format of names -- Names in the global DNS are domain names. Format of names -- Names in the global DNS are domain names.
There are three formats: wire format, presentation format, and There are three formats: wire format, presentation format, and
common display. common display.
The basic wire format for names in the global DNS is a list of The basic wire format for names in the global DNS is a list of
labels with the root label last. Each label is preceded by a labels with the root label last. Each label is preceded by a
length octet. [RFC1035] also defines a compression scheme that length octet. [RFC1035] also defines a compression scheme that
modifies this format. modifies this format.
skipping to change at page 6, line 39 skipping to change at page 6, line 41
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 7.
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 tha 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
served zones may result in ambiguous results. For example, the served zones may result in ambiguous results. For example, the
same name may resolve to different results in different locally same name may resolve to different results in different locally
served DNS zone contexts. The context through which a locally served DNS zone contexts. The context through which a locally
served zone may be explicit, for example, as defined in [RFC6303], served zone may be explicit, for example, as defined in [RFC6303],
or implicit, as defined by local DNS administration and not known or implicit, as defined by local DNS administration and not known
to the resolution client. to the resolution client.
Fully qualified domain name (FQDN): This is often just a clear way Fully qualified domain name (FQDN): This is often just a clear way
of saying the same thing as "domain name of a node", as outlined of saying the same thing as "domain name of a node", as outlined
skipping to change at page 8, line 18 skipping to change at page 8, line 21
some new terminology. some new terminology.
Subdomain: "A domain is a subdomain of another domain if it is Subdomain: "A domain is a subdomain of another domain if it is
contained within that domain. This relationship can be tested by contained within that domain. This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's seeing if the subdomain's name ends with the containing domain's
name." (Quoted from [RFC1034], Section 3.1). For example, in the name." (Quoted from [RFC1034], Section 3.1). For example, in the
host name "nnn.mmm.example.com", both "mmm.example.com" and host name "nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com". "nnn.mmm.example.com" are subdomains of "example.com".
Alias: The owner of a CNAME resource record, or a subdomain of the Alias: The owner of a CNAME resource record, or a subdomain of the
owner of a DNAME resource record [RFC6672]. See also "canonical owner of a DNAME resource record. See also "canonical name".
name".
Canonical name: A CNAME resource record "identifies its owner name Canonical name: A CNAME resource record "identifies its owner name
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." Public suffix: "A domain that is controlled by a public registry."
(Quoted from [RFC6265], Section 5.3) A common definition for this (Quoted from [RFC6265], Section 5.3) A common definition for this
term is a domain under which subdomains can be registered, and on term is a domain under which subdomains can be registered, and on
which HTTP cookies ([RFC6265]) should not be set. There is no which HTTP cookies ([RFC6265]) should not be set. There is no
indication in a domain name whether it is a public suffix; that indication in a domain name whether it is a public suffix; that
can only be determined by outside means. In fact, both a domain can only be determined by outside means. In fact, both a domain
and a subdomain of that domain can be public suffixes. At the and a subdomain of that domain can be public suffixes.
time this document is published, the IETF DBOUND Working Group
[DBOUND] is dealing with issues concerning public suffixes.
There is nothing inherent in a domain name to indicate whether it There is nothing inherent in a domain name to indicate whether it
is a public suffix. One resource for identifying public suffixes is a public suffix. One resource for identifying public suffixes
is the Public Suffix List (PSL) maintained by Mozilla is the Public Suffix List (PSL) maintained by Mozilla
(http://publicsuffix.org/). (http://publicsuffix.org/).
For example, at the time this document is published, the "com.au" 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 domain is listed as a public suffix in the PSL. (Note that this
example might change in the future.) example might change in the future.)
Note that the term "public suffix" is controversial in the DNS Note that the term "public suffix" is controversial in the DNS
community for many reasons, and may be significantly changed in community for many reasons, and may be significantly changed in
the future. One example of the difficulty of calling a domain a the future. One example of the difficulty of calling a domain a
public suffix is that designation can change over time as the public suffix is that designation can change over time as the
registration policy for the zone changes, such as the case of the registration policy for the zone changes, such as was the case
"uk" TLD around the time this document is published. with the "uk" TLD in 2014.
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is its first 12 octets. Many of the The header of a DNS message is its first 12 octets. Many of the
fields and flags in the header diagram in Sections 4.1.1 through fields and flags in the header diagram in Sections 4.1.1 through
4.1.3 of [RFC1035] are referred to by their names in that diagram. 4.1.3 of [RFC1035] are referred to by their names in that diagram.
For example, the response codes are called "RCODEs", the data for a For example, the response codes are called "RCODEs", the data for a
record is called the "RDATA", and the authoritative answer bit is record is called the "RDATA", and the authoritative answer bit is
often called "the AA flag" or "the AA bit". often called "the AA flag" or "the AA bit".
QNAME The most commonly-used definitions are that the QNAME is a QNAME The most commonly-used definition is that the QNAME is a field
field in the Question section of a query. "A standard query in the Question section of a query. "A standard query specifies a
specifies a target domain name (QNAME), query type (QTYPE), and target domain name (QNAME), query type (QTYPE), and query class
query class (QCLASS) and asks for RRs which match." (Quoted from (QCLASS) and asks for RRs which match." (Quoted from [RFC1034],
[RFC1034], Section 3.7.1.) Section 3.7.1.)
[RFC2308], however, has an alternate definition that puts the [RFC2308], however, has an alternate definition that puts the
QNAME in the answer (or series of answers) instead of the query. QNAME in the answer (or series of answers) instead of the query.
It defines QNAME as: "...the name in the query section of an It defines QNAME as: "...the name in the query section of an
answer, or where this resolves to a CNAME, or CNAME chain, the answer, or where this resolves to a CNAME, or CNAME chain, the
data field of the last CNAME. The last CNAME in this sense is data field of the last CNAME. The last CNAME in this sense is
that which contains a value which does not resolve to another that which contains a value which does not resolve to another
CNAME." CNAME."
Some of response codes that are defined in [RFC1035] have acquired Some of response codes that are defined in [RFC1035] have acquired
skipping to change at page 12, line 24 skipping to change at page 12, line 24
are the same for every DNS class. A resource record type that is are the same for every DNS class. A resource record type that is
not class independent has different meanings depending on the DNS not class independent has different meanings depending on the DNS
class of the record, or the meaning is undefined for classes other class of the record, or the meaning is undefined for classes other
than IN (class 1, the Internet). than IN (class 1, the Internet).
5. DNS Servers and Clients 5. DNS Servers and Clients
This section defines the terms used for the systems that act as DNS This section defines the terms used for the systems that act as DNS
clients, DNS servers, or both. clients, DNS servers, or both.
For terminology specific to the public DNS root server system, see
[RSSAC026]. That document defines terms such as "root server", "root
server operator", and terms that are specific to the way that the
root zone of the public DNS is served.
Resolver: A program "that extract[s] information from name servers Resolver: A program "that extract[s] information from name servers
in response to client requests." (Quoted from [RFC1034], in response to client requests." (Quoted from [RFC1034],
Section 2.4) "The resolver is located on the same machine as the Section 2.4) "The resolver is located on the same machine as the
program that requests the resolver's services, but it may need to program that requests the resolver's services, but it may need to
consult name servers on other hosts." (Quoted from [RFC1034], consult name servers on other hosts." (Quoted from [RFC1034],
Section 5.1) A resolver performs queries for a name, type, and Section 5.1) A resolver performs queries for a name, type, and
class, and receives answers. The logical function is called class, and receives answers. The logical function is called
"resolution". In practice, the term is usually referring to some "resolution". In practice, the term is usually referring to some
specific type of resolver (some of which are defined below), and specific type of resolver (some of which are defined below), and
understanding the use of the term depends on understanding the understanding the use of the term depends on understanding the
skipping to change at page 13, line 31 skipping to change at page 13, line 37
Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
term to mean a resolver that acts in recursive mode with a cache term to mean a resolver that acts in recursive mode with a cache
(and meets other requirements). (and meets other requirements).
Recursive resolver: A resolver that acts in recursive mode. In Recursive resolver: A resolver that acts in recursive mode. In
general, a recursive resolver is expected to cache the answers it general, a recursive resolver is expected to cache the answers it
receives (which would make it a full-service resolver), but some receives (which would make it a full-service resolver), but some
recursive resolvers might not cache. recursive resolvers might not cache.
Priming: The mechanism used by a resolver to determine where to send Priming: "The act of finding the list of root servers from a
queries before there is anything in the resolver's cache. Priming configuration that lists some or all of the purported IP addresses
is most often done from a configuration setting that contains a of some or all of those root servers." (Quoted from [RFC8109],
list of authoritative servers for the root zone. Section 2.) Priming is 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])
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."
skipping to change at page 16, line 24 skipping to change at page 16, line 33
View: A configuration for a DNS server that allows it to provide View: A configuration for a DNS server that allows it to provide
different answers depending on attributes of the query. different answers depending on attributes of the query.
Typically, views differ by the source IP address of a query, but Typically, views differ by the source IP address of a query, but
can also be based on the destination IP address, the type of query can also be based on the destination IP address, the type of query
(such as AXFR), whether it is recursive, and so on. Views are (such as AXFR), whether it is recursive, and so on. Views are
often used to provide more names or different addresses to queries often used to provide more names or different addresses to queries
from "inside" a protected network than to those "outside" that from "inside" a protected network than to those "outside" that
network. Views are not a standardized part of the DNS, but they network. Views are not a standardized part of the DNS, but they
are widely implemented in server software. are widely implemented in server software.
Passive DNS: A mechanism to collect large amounts of DNS data by Passive DNS: A mechanism to collect DNS data by storing DNS
storing DNS responses from servers. Some of these systems also transactions from name servers. Some of these systems also
collect the DNS queries associated with the responses; this can collect the DNS queries associated with the responses. Passive
raise privacy issues. Passive DNS databases can be used to answer DNS databases can be used to answer historical questions about DNS
historical questions about DNS zones such as which records were zones such as which answers were witnessed at what times in the
available for them at what times in the past. Passive DNS past. Passive DNS databases allow searching of the stored records
databases allow searching of the stored records on keys other than on keys other than just the name and type, such as "find all names
just the name, such as "find all names which have A records of a which have A records of a particular value".
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
server to have the same IP address, each one of those servers is
commonly referred to as an 'instance'." "An instance of a server,
such as a root server, is often referred to as an 'Anycast
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 6. Zones
This section defines terms that are used when discussing zones that This section defines terms that are used when discussing zones that
skipping to change at page 18, line 38 skipping to change at page 18, line 48
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: In-bailiwick: An adjective to describe a name server whose name is
either subordinate to or (rarely) the same as the zone origin.
In-bailiwick name servers may have glue records in their parent
zone (using the first of the definitions of "glue records" in the
definition above). "In-bailiwick" names are divided into two type
of name server names: "in-domain" names and "sibling domain"
names:
(a) An adjective to describe a name server whose name is either * In-domain -- an adjective to describe a name server whose name
subordinate to or (rarely) the same as the zone origin. In- is either subordinate to or (rarely) the same as the owner name
bailiwick name servers require glue records in their parent zone of the NS resource records. An in-domain name server name MUST
(using the first of the definitions of "glue records" in the have glue records or name resolution fails. For example, a
definition above). delegation for "child.example.com" may have "in-domain" name
server name "ns.child.example.com".
(b) Data for which the server is either authoritative, or else * Sibling domain: -- a name server's name that is either
authoritative for an ancestor of the owner name. This sense of subordinate to or (rarely) the same as the zone origin and not
the term normally is used when discussing the relevancy of glue subordinate to or the same as the owner name of the NS resource
records in a response. For example, the server for the parent records. Glue records for sibling domains are allowed, but not
zone "example.com" might reply with glue records for necessary. For example, a delegation for "child.example.com"
"ns.child.example.com". Because the "child.example.com" zone is a in "example.com" zone may have "sibling" name server name
descendant of the "example.com" zone, the glue records are in- "ns.another.example.com".
bailiwick.
Out-of-bailiwick: The antonym of in-bailiwick. Out-of-bailiwick: The antonym of in-bailiwick. An adjective 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
servers are useless.
Authoritative data: "All of the RRs attached to all of the nodes 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 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], cuts around the bottom edge of the zone." (Quoted from [RFC1034],
Section 4.2.1) It is noted that this definition might Section 4.2.1) It is noted that this definition might
inadvertently also include any NS records that appear in the zone, inadvertently also include any NS records that appear in the zone,
even those that might not truly be authoritative because there are even those that might not truly be authoritative because there are
identical NS RRs below the zone cut. This reveals the ambiguity identical NS RRs below the zone cut. This reveals the ambiguity
in the notion of authoritative data, because the parent-side NS in the notion of authoritative data, because the parent-side NS
records authoritatively indicate the delegation, even though they records authoritatively indicate the delegation, even though they
are not themselves authoritative data. are not themselves authoritative data.
Root zone: The zone whose apex is the zero-length label. Also Root zone: The zone of a DNS-based tree whose apex is the zero-
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
skipping to change at page 22, line 37 skipping to change at page 23, line 4
decide about the allowed contents of the zone. decide about the allowed contents of the zone.
8. General DNSSEC 8. 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",
"security-aware recursive name server", "security-aware resolver", "security-aware recursive name server", "security-aware resolver",
"security-aware stub resolver", and "security-oblivious "security-aware stub resolver", and "security-oblivious
'anything'". (Note that the term "validating resolver", which is 'anything'". (Note that the term "validating resolver", which is
used in some places in DNSSEC-related documents, is also not used in some places in DNSSEC-related documents, is also not
defined.) defined in those RFCs, but is defined below.)
Signed zone: "A zone whose RRsets are signed and that contains Signed zone: "A zone whose RRsets are signed and that contains
properly constructed DNSKEY, Resource Record Signature (RRSIG), properly constructed DNSKEY, Resource Record Signature (RRSIG),
Next Secure (NSEC), and (optionally) DS records." (Quoted from Next Secure (NSEC), and (optionally) DS records." (Quoted from
[RFC4033], Section 2.) It has been noted in other contexts that [RFC4033], Section 2.) It has been noted in other contexts that
the zone itself is not really signed, but all the relevant RRsets the zone itself is not really signed, but all the relevant RRsets
in the zone are signed. Nevertheless, if a zone that should be in the zone are signed. Nevertheless, if a zone that should be
signed contains any RRsets that are not signed (or opted out), signed contains any RRsets that are not signed (or opted out),
those RRsets will be treated as bogus, so the whole zone needs to those RRsets will be treated as bogus, so the whole zone needs to
be handled in some way. be handled in some way.
skipping to change at page 24, line 45 skipping to change at page 25, line 11
individual DNSSEC components such as the RRSIG validity or NSEC individual DNSSEC components such as the RRSIG validity or NSEC
proof validity. The third definition considers the components of proof validity. The third definition considers the components of
the entire DNSSEC authentication chain, and thus requires the entire DNSSEC authentication chain, and thus requires
"configured knowledge of at least one authenticated DNSKEY or DS "configured knowledge of at least one authenticated DNSKEY or DS
RR" (as described in [RFC4035], Section 5). RR" (as described in [RFC4035], Section 5).
[RFC4033], Section 2, says that a "Validating Security-Aware Stub [RFC4033], Section 2, says that a "Validating Security-Aware Stub
Resolver... performs signature validation" and uses a trust anchor Resolver... performs signature validation" and uses a trust anchor
"as a starting point for building the authentication chain to a "as a starting point for building the authentication chain to a
signed DNS response", and thus uses the first and third signed DNS response", and thus uses the first and third
definitions above. The process of validating an RRSIG RR is definitions above. The process of validating an RRSIG resource
described in [RFC4035], Section 5.3. record is described in [RFC4035], Section 5.3.
[RFC5155] refers to validating responses throughout the document, [RFC5155] refers to validating responses throughout the document,
in the context of hashed authenticated denial of existence; this in the context of hashed authenticated denial of existence; this
uses the second definition above. uses the second definition above.
The term "authentication" is used interchangeably with The term "authentication" is used interchangeably with
"validation", in the sense of the third definition above. "validation", in the sense of the third definition above.
[RFC4033], Section 2, describes the chain linking trust anchor to [RFC4033], Section 2, describes the chain linking trust anchor to
DNS data as the "authentication chain". A response is considered DNS data as the "authentication chain". A response is considered
to be authentic if "all RRsets in the Answer and Authority to be authentic if "all RRsets in the Answer and Authority
skipping to change at page 25, line 21 skipping to change at page 25, line 34
([RFC4035]). DNS data or responses deemed to be authentic or ([RFC4035]). DNS data or responses deemed to be authentic or
validated have a security status of "secure" ([RFC4035], validated have a security status of "secure" ([RFC4035],
Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys
and data is a matter of local policy, which may extend or even and data is a matter of local policy, which may extend or even
override the [DNSSEC] protocol extensions" ([RFC4033], override the [DNSSEC] protocol extensions" ([RFC4033],
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,
security-aware resolver, or security-aware stub resolver that is
applying at least one of the definitions of validation (above), as
appropriate to the resolution context. For the same reason that
the generic term "resolver" is sometimes ambiguous and needs to be
evaluated in context (see Section 5), "validating resolver" is a
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) Note that the
roles KSK and ZSK are not mutually exclusive: a single key can be roles KSK and ZSK are not mutually exclusive: a single key can be
both KSK and ZSK at the same time. Also note that a ZSK is both KSK and ZSK at the same time. Also note that a ZSK is
sometimes used to sign the apex DNSKEY RRset. sometimes used to sign the apex DNSKEY RRset.
skipping to change at page 30, line 36 skipping to change at page 30, line 36
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>. <http://www.rfc-editor.org/info/rfc5936>.
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
"Recommendations for the Remediation of Bots in ISP "Recommendations for the Remediation of Bots in ISP
Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
<http://www.rfc-editor.org/info/rfc6561>. <http://www.rfc-editor.org/info/rfc6561>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://www.rfc-editor.org/info/rfc6672>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>. <http://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, DOI 10.17487/RFC6840, February 2013,
<http://www.rfc-editor.org/info/rfc6840>. <http://www.rfc-editor.org/info/rfc6840>.
skipping to change at page 31, line 26 skipping to change at page 31, line 21
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>. <http://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, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
12.2. Informative References 12.2. Informative References
[DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2016,
<https://datatracker.ietf.org/wg/dbound/charter/>.
[IANA_Resource_Registry] [IANA_Resource_Registry]
Internet Assigned Numbers Authority, "Resource Record (RR) Internet Assigned Numbers Authority, "Resource Record (RR)
TYPEs", 2017, TYPEs", 2017,
<http://www.iana.org/assignments/dns-parameters/>. <http://www.iana.org/assignments/dns-parameters/>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819, Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982, DOI 10.17487/RFC0819, August 1982,
<http://www.rfc-editor.org/info/rfc819>. <http://www.rfc-editor.org/info/rfc819>.
skipping to change at page 34, line 29 skipping to change at page 34, line 19
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <http://www.rfc-editor.org/info/rfc7484>. 2015, <http://www.rfc-editor.org/info/rfc7484>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<http://www.rfc-editor.org/info/rfc7485>. <http://www.rfc-editor.org/info/rfc7485>.
[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
Resolver with Priming Queries", BCP 209, RFC 8109,
DOI 10.17487/RFC8109, March 2017,
<http://www.rfc-editor.org/info/rfc8109>.
[RSSAC026]
Root Server System Advisory Committee (RSSAC), "RSSAC
Lexicon", 2017,
<https://www.icann.org/en/system/files/files/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] o Secure Entry Point (SEP) in [RFC3757]
Appendix B. Definitions First Defined in this Document
The following definitions are first defined in this document:
o "Alias" in Section 2
o "Apex" in Section 6
o "arpa" in Section 6
o "Class independent" in Section 4
o "Delegation-centric zone" in Section 6
o "Delegation" in Section 6
o "DNS operator" in Section 7
o "DNSSEC-aware" in Section 8
o "DNSSEC-unaware" in Section 8
o "Forwarding" in Section 5
o "Full resolver" in Section 5
o "Fully qualified domain name" in Section 2
o "Global DNS" in Section 2
o "Hardware Security Module (HSM)" in Section 8
o "Host name" in Section 2
o "IDN" in Section 2
o "In-bailiwick" in Section 6
o "Label" in Section 2
o "Locally served DNS zone" in Section 2
o "Naming system" in Section 2
o "Negative response" in Section 3
o "Open resolver" in Section 5
o "Out-of-bailiwick" in Section 6
o "Passive DNS" in Section 5
o "Policy-implementing resolver" in Section 5
o "Presentation format" in Section 4
o "Priming" in Section 5
o "Private DNS" in Section 2
o "Recursive resolver" in Section 5
o "Referrals" in Section 3
o "Registrant" in Section 7
o "Registrar" in Section 7
o "Registry" in Section 7
o "Root zone" in Section 6
o "Secure Entry Point (SEP)" in Section 8
o "Signing software" in Section 8
o "Stub resolver" in Section 5
o "TLD" in Section 2
o "Validating resolver" in Section 8
o "Validation" in Section 8
o "View" in Section 5
o "Zone transfer" in Section 5
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: John
Dickinson, Bob Harold, [[ MORE NAMES WILL APPEAR HERE AS FOLKS Dickinson, Bob Harold, Peter Koch, [[ MORE NAMES WILL APPEAR HERE AS
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
Dyn Oracle
150 Dow Street, Tower 2 100 Milverton Drive
Manchester, NH 03101 Mississauga, ON L5R 4H1
United States Canada
Email: asullivan@dyn.com Email: andrew.s.sullivan@oracle.com
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
 End of changes. 36 change blocks. 
79 lines changed or deleted 199 lines changed or added

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