draft-ietf-dnsop-terminology-bis-13.txt   draft-ietf-dnsop-terminology-bis-14.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) Updates: 2308 (if approved)
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: February 21, 2019 JPRS Expires: March 17, 2019 JPRS
August 20, 2018 September 13, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-13 draft-ietf-dnsop-terminology-bis-14
Abstract Abstract
The domain name system (DNS) is defined in literally dozens of The domain name system (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes of DNS protocols, and by operators of DNS systems, has sometimes
changed in the decades since the DNS was first defined. This changed in the decades since the DNS was first defined. This
document gives current definitions for many of the terms used in the document gives current definitions for many of the terms used in the
DNS in a single document. DNS in a single document.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 https://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 February 21, 2019. This Internet-Draft will expire on March 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13
6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15
7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 27 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 27
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 29
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Definitions Updated by this Document . . . . . . . . 41 Appendix A. Definitions Updated by this Document . . . . . . . . 42
Appendix B. Definitions First Defined in this Document . . . . . 41 Appendix B. Definitions First Defined in this Document . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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. (Section 2 whose messages in both directions have the same format. (Section 2
gives a definition of "public DNS", which is often what people mean gives a definition of "public DNS", which is often what people mean
when they say "the DNS".) The protocol and message format are when they say "the DNS".) The protocol and message format are
defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,
but later documents defined others. Some of the terms from [RFC1034] but later documents defined others. Some of the terms from [RFC1034]
and [RFC1035] now have somewhat different meanings than they did in and [RFC1035] now have somewhat different meanings than they did in
skipping to change at page 4, line 10 skipping to change at page 4, line 10
topic. Someone who is not already familiar with the DNS can probably topic. Someone who is not already familiar with the DNS can probably
not learn about the DNS from scratch by reading this document from not learn about the DNS from scratch by reading this document from
front to back. Instead, skipping around may be the only way to get front to back. Instead, skipping around may be the only way to get
enough context to understand some of the definitions. This document enough context to understand some of the definitions. This document
has an index that might be useful for readers who are attempting to has an index that might be useful for readers who are attempting to
learn the DNS by reading this document. learn the DNS by reading this document.
2. Names 2. Names
Naming system: A naming system associates names with data. Naming Naming system: A naming system associates names with data. Naming
systems have many significant facets that help differentiate them. systems have many significant facets that help differentiate them
Some commonly-identified facets include: from each other. Some commonly-identified facets include:
* Composition of names * Composition of names
* Format of names * Format of names
* Administration of names * Administration of names
* Types of data that can be associated with names * Types of data that can be associated with names
* Types of metadata for names * Types of metadata for names
skipping to change at page 4, line 42 skipping to change at page 4, line 42
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 this definition has the same and their nodes in graph theory, and this definition has the same
practical result as the definition here. Using graph theory, a practical result as the definition here. Any path of a directed
domain name is a list of labels identifying a portion along one acyclic graph can be represented by a domain name consisting of
edge of a directed acyclic graph. A domain name can be relative the labels of its nodes, ordered by decreasing distance from the
to parts of the tree, or it can be fully qualified (in which case, root(s) (which is the normal convention within the DNS, including
it begins at the common root of the graph). this document). A domain name whose last label identifies a root
of the graph is fully qualified; other domain names whose labels
form a strict prefix of a fully qualified domain name are relative
to its first omitted node.
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 that makes up a Label: An ordered list of zero or more octets that makes up a
portion of a domain name. Using graph theory, a label identifies portion of a domain name. Using graph theory, a label identifies
one node in a portion of the graph of all possible domain names. one node in a portion of the graph of all possible domain names.
Global DNS: Using the short set of facets listed in "Naming system", Global DNS: Using the short set of facets listed in "Naming system",
the global DNS can be defined as follows. Most of the rules here the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
inclusive. In a fully-qualified domain name, the first label in inclusive. In a fully-qualified domain name, the last label in
the ordered list is 0 octets long; it is the only label whose the ordered list is 0 octets long; it is the only label whose
length may be 0 octets, and it is called the "root" or "root length may be 0 octets, and it is called the "root" or "root
label". A domain name in the global DNS has a maximum total label". A domain name in the global DNS has a maximum total
length of 255 octets in the wire format; the root represents one length of 255 octets in the wire format; the root represents one
octet for this calculation. (Multicast DNS [RFC6762] allows names octet for this calculation. (Multicast DNS [RFC6762] allows names
up to 255 bytes plus a terminating zero byte based on a different up to 255 bytes plus a terminating zero byte based on a different
interpretation of RFC 1035 and what is included in the 255 interpretation of RFC 1035 and what is included in the 255
octets.) octets.)
Format of names -- Names in the global DNS are domain names. Format of names -- Names in the global DNS are domain names.
skipping to change at page 6, line 7 skipping to change at page 6, line 13
in ASCII. in ASCII.
The common display format is used in applications and free text. The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done. For label and the "." before it is optional and is rarely done. For
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 root or TLD label in the ordered list is in both English and the C programming language the root or TLD
right-most; but in Arabic it may be left-most, depending on local label in the ordered list is right-most; but in Arabic it may be
conventions). left-most, depending on local conventions).
Administration of names -- Administration is specified by Administration of names -- Administration is specified by
delegation (see the definition of "delegation" in Section 7). 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). (See <https://pti.icann.org/> for more Identifiers (PTI). (See <https://pti.icann.org/> for more
skipping to change at page 7, line 47 skipping to change at page 7, line 51
fully qualified domain name would include every label, including fully qualified domain name would include every label, including
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 last labels in the ordered list are
omitted (for example, a name of "www" derived from omitted (for example, a domain name of "www" relative to
"www.example.net"). Such relative names are understood only by "example.net" identifies "www.example.net"). Such relative names
context. 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" (that is, every character [RFC1034], the "preferred name syntax" (that is, every character
in each label is a letter, a digit, or a hyphen). Note that any in each label is a letter, a digit, or a hyphen). Note that any
skipping to change at page 8, line 41 skipping to change at page 8, line 44
delegation-centric zones (defined in Section 7, and there are delegation-centric zones (defined in Section 7, and there are
significant policy issues around their operation. TLDs are often significant policy issues around their operation. TLDs are often
divided into sub-groups such as Country Code Top-Level Domains divided into sub-groups such as Country Code Top-Level Domains
(ccTLDs), Generic Top-Level Domains (gTLDs), and others; the (ccTLDs), Generic Top-Level Domains (gTLDs), and others; the
division is a matter of policy, and beyond the scope of this division is a matter of policy, and beyond the scope of this
document. 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 at the time of this writing, normally called
[RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These "IDNA2008", is defined in [RFC5890], [RFC5891], [RFC5892],
documents define many IDN-specific terms such as "LDH label", [RFC5893], and [RFC5894]. These documents define many IDN-
"A-label", and "U-label". [RFC6365] defines more terms that specific terms such as "LDH label", "A-label", and "U-label".
relate to internationalization (some of which relate to IDNs), and [RFC6365] defines more terms that relate to internationalization
[RFC6055] has a much more extensive discussion of IDNs, including (some of which relate to IDNs), and [RFC6055] has a much more
some new terminology. extensive discussion of IDNs, including 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". Note that
the comparisons here are done on whole labels; that is,
"ooo.example.com" is not a subdomain of "oo.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 (DNAME records are defined in owner of a DNAME resource record (DNAME records are defined in
[RFC6672]). See also "canonical name". [RFC6672]). See also "canonical 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".
skipping to change at page 10, line 36 skipping to change at page 10, line 43
4. DNS Transactions 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".
Class: A class "identifies a protocol family or instance of a
protocol" (Quoted from [RFC1034], Section 3.6). "The DNS tags all
data with a class as well as the type, so that we can allow
parallel use of different formats for data of type address."
(Quoted from [RFC1034], Section 2.2). In practice, the class for
nearly every query is "IN". There are some queries for "CH", but
they are usually for the purposes of information about the server
itself rather than for a different type of address.
QNAME: The most commonly-used rough definition is that the QNAME is QNAME: The most commonly-used rough definition is that the QNAME is
a 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
skipping to change at page 11, line 15 skipping to change at page 11, line 31
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." This definition has a certain internal logic, because of CNAME." This definition has a certain internal logic, because of
the way CNAME substitution works and the definition of CNAME. If the way CNAME substitution works and the definition of CNAME. If
a name server does not find an RRset that matches a query, but it a name server does not find an RRset that matches a query, but it
finds the same name in the same class with a CNAME record, then finds the same name in the same class with a CNAME record, then
the name server "includes the CNAME record in the response and the name server "includes the CNAME record in the response and
restarts the query at the domain name specified in the data field restarts the query at the domain name specified in the data field
of the CNAME record." ([RFC1034] Section 3.6.2). This is made of the CNAME record." (Quoted from [RFC1034] Section 3.6.2).
explicit in the resolution algorithm outlined in Section 4.3.2 of This is made explicit in the resolution algorithm outlined in
[RFC1034], which says to "change QNAME to the canonical name in Section 4.3.2 of [RFC1034], which says to "change QNAME to the
the CNAME RR, and go back to step 1" in the case of a CNAME RR. canonical name in the CNAME RR, and go back to step 1" in the case
Since a CNAME record explicitly declares that the owner name is of a CNAME RR. Since a CNAME record explicitly declares that the
canonically named what is in the RDATA, then there is a way to owner name is canonically named what is in the RDATA, then there
view the new name (i.e. the name that was in the RDATA of the is a way to view the new name (i.e. the name that was in the RDATA
CNAME RR) as also being the QNAME. of the CNAME RR) as also being the QNAME.
This creates a kind of confusion, however, because the response to This creates a kind of confusion, however, because the response to
a query that results in CNAME processing contains in the echoed a query that results in CNAME processing contains in the echoed
Question Section one QNAME (the name in the original query), and a Question Section one QNAME (the name in the original query), and a
second QNAME that is in the data field of the last CNAME. The second QNAME that is in the data field of the last CNAME. The
confusion comes from the iterative/recursive mode of resolution, confusion comes from the iterative/recursive mode of resolution,
which finally returns an answer that need not actually have the which finally returns an answer that need not actually have the
same owner name as the QNAME contained in the original query. same owner name as the QNAME contained in the original query.
To address this potential confusion, it is helpful to distinguish To address this potential confusion, it is helpful to distinguish
skipping to change at page 13, line 9 skipping to change at page 13, line 26
section. It has the NS RRset for the referred-to zone in the section. It has the NS RRset for the referred-to zone in the
authority section. It may contain RRs that provide addresses in authority section. It may contain RRs that provide addresses in
the additional section. The AA bit is set, because the first name the additional section. The AA bit is set, because the first name
in the answer section matches the QNAME and the server is in the answer section matches the QNAME and the server is
authoritative for that answer (see [RFC1035], Section 4.1.1). authoritative for that answer (see [RFC1035], Section 4.1.1).
5. 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],
spelled RRSet in some documents. As a clarification, "same label" Section 5) Also spelled RRSet in some documents. As a
in this definition means "same owner name". In addition, clarification, "same label" in this definition means "same owner
[RFC2181] states that "the TTLs of all RRs in an RRSet must be the name". In addition, [RFC2181] states that "the TTLs of all RRs in
same". an RRSet must be the same".
Note that RRSIG resource records do not match this definition. Note that RRSIG resource records do not match this definition.
[RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated [RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated
with it. Note that as RRSIG RRs are closely tied to the RRsets with it. Note that as RRSIG RRs are closely tied to the RRsets
whose signatures they contain, RRSIG RRs, unlike all other DNS RR whose signatures they contain, RRSIG RRs, unlike all other DNS RR
types, do not form RRsets. In particular, the TTL values among types, do not form RRsets. In particular, the TTL values among
RRSIG RRs with a common owner name do not follow the RRset rules RRSIG RRs with a common owner name do not follow the RRset rules
described in [RFC2181]." described in [RFC2181]."
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." (Quoted
([RFC1035], Section 5.) Master files are sometimes called "zone from [RFC1035], Section 5.) Master files are sometimes called
files". "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
response code space, and to carry additional options that affect response code space, and to carry additional options that affect
the handling of a DNS query. the handling of a DNS query.
OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to
contain control information pertaining to the question-and-answer contain control information pertaining to the question-and-answer
sequence of a specific transaction. (Definition from [RFC6891], sequence of a specific transaction. (Definition from [RFC6891],
Section 6.1.1) It is used by EDNS. Section 6.1.1) It is used by EDNS.
Owner: The domain name where a RR is found ([RFC1034], Section 3.6). Owner: "The domain name where a RR is found" (Quoted from [RFC1034],
Often appears in the term "owner name". Section 3.6). Often appears in the term "owner name".
SOA field names: DNS documents, including the definitions here, SOA field names: DNS documents, including the definitions here,
often refer to the fields in the RDATA of an SOA resource record often refer to the fields in the RDATA of an SOA resource record
by field name. "SOA" stands for "start of a zone of authority". by field name. "SOA" stands for "start of a zone of authority".
Those fields are defined in Section 3.3.13 of [RFC1035]. The Those fields are defined in Section 3.3.13 of [RFC1035]. The
names (in the order they appear in the SOA RDATA) are MNAME, names (in the order they appear in the SOA RDATA) are MNAME,
RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the
meaning of MINIMUM field is updated in Section 4 of [RFC2308]; the meaning of MINIMUM field is updated in Section 4 of [RFC2308]; the
new definition is that the MINIMUM field is only "the TTL to be new definition is that the MINIMUM field is only "the TTL to be
used for negative responses". This document tends to use field used for negative responses". This document tends to use field
skipping to change at page 16, line 20 skipping to change at page 16, line 36
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". See also "iterative resolution" later in "iterative resolver". See also "iterative resolution" later in
this section. 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". Section 4.3.1 of of [RFC1034] says "in [recursive] mode server". Section 4.3.1 of [RFC1034] says "in [recursive] mode the
the name server acts in the role of a resolver and returns either name server acts in the role of a resolver and returns either an
an error or the answer, but never referrals." That same section error or the answer, but never referrals." That same section also
also says "The recursive mode occurs when a query with RD set says "The recursive mode occurs when a query with RD set arrives
arrives at a server which is willing to provide recursive service; at a server which is willing to provide recursive service; the
the client can verify that recursive mode was used by checking client can verify that recursive mode was used by checking that
that both RA and RD are set in the reply." both RA and RD are set in the reply."
A server operating in recursive mode may be thought of as having a A server operating in recursive mode may be thought of as having a
name server side (which is what answers the query) and a resolver name server side (which is what answers the query) and a resolver
side (which performs the resolution function). Systems operating side (which performs the resolution function). Systems operating
in this mode are commonly called "recursive servers". Sometimes in this mode are commonly called "recursive servers". Sometimes
they are called "recursive resolvers". While strictly the they are called "recursive resolvers". In practice it is not
difference between these is that one of them sends queries to possible to know in advance whether the server that one is
another recursive server and the other does not, in practice it is
not possible to know in advance whether the server that one is
querying will also perform recursion; both terms can be observed querying will also perform recursion; both terms can be observed
in use interchangeably. in use interchangeably.
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.
[RFC4697] tried to differentiate between a recursive resolver and [RFC4697] tried to differentiate between a recursive resolver and
an iterative resolver. an iterative resolver.
skipping to change at page 19, line 16 skipping to change at page 19, line 29
Primary servers are also discussed in [RFC1034]. Although early Primary servers are also discussed in [RFC1034]. Although early
DNS RFCs such as [RFC1996] referred to this as a "master", the DNS RFCs such as [RFC1996] referred to this as a "master", the
current common usage has shifted to "primary". current common usage has shifted to "primary".
Primary master: "The primary master is named in the zone's SOA MNAME Primary master: "The primary master is named in the zone's SOA MNAME
field and optionally by an NS RR". (Quoted from [RFC1996], field and optionally by an NS RR". (Quoted from [RFC1996],
Section 2.1). [RFC2136] defines "primary master" as "Master Section 2.1). [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The primary server at the root of the AXFR/IXFR dependency graph. The primary
master is named in the zone's SOA MNAME field and optionally by an master is named in the zone's SOA MNAME field and optionally by an
NS RR. There is by definition only one primary master server per NS RR. There is by definition only one primary master server per
zone." The idea of a primary master is only used by [RFC2136], zone."
and is considered archaic in other parts of the DNS.
The idea of a primary master is only used in [RFC1996] and The idea of a primary master is only used in [RFC1996] and
[RFC2136]. A modern interpretation of the term "primary master" [RFC2136]. A modern interpretation of the term "primary master"
is a server that is both authoritative for a zone and that gets is a server that is both authoritative for a zone and that gets
its updates to the zone from configuration (such as a master file) its updates to the zone from configuration (such as a master file)
or from UPDATE transactions. or from UPDATE transactions.
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)
skipping to change at page 21, line 29 skipping to change at page 21, line 42
on Anycast and other terms that are specific to its use. on Anycast and other terms that are specific to its use.
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])
Privacy-enabling DNS server: "A DNS server that implements DNS over Privacy-enabling DNS server: "A DNS server that implements DNS over
TLS [RFC7858] and may optionally implement DNS over DTLS TLS [RFC7858] and may optionally implement DNS over DTLS
[RFC8094]." (Quoted from [RFC8310], Section 2) [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS
servers might also be considerd privacy-enabling, such as those
running DNS over HTTPS [I-D.ietf-doh-dns-over-https].
7. 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)
skipping to change at page 22, line 5 skipping to change at page 22, line 20
Parent: "The domain in which the Child is registered." (Quoted from Parent: "The domain in which the Child is registered." (Quoted from
[RFC7344], Section 1.1) Earlier, "parent name server" was defined [RFC7344], Section 1.1) Earlier, "parent name server" was defined
in [RFC0882] as "the name server that has authority over the place in [RFC0882] as "the name server that has authority over the place
in the domain name space that will hold the new domain". (Note in the domain name space that will hold the new domain". (Note
that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].) that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
[RFC0819] also has some description of the relationship between [RFC0819] also has some description of the relationship between
parents and children. parents and children.
Origin: Origin:
There are two different uses for this term:
(a) "The domain name that appears at the top of a zone (just below (a) "The domain name that appears at the top of a zone (just below
the cut that separates the zone from its parent). The name of the the cut that separates the zone from its parent). The name of the
zone is the same as the name of the domain at the zone's origin." zone is the same as the name of the domain at the zone's origin."
(Quoted from [RFC2181], Section 6.) These days, this sense of (Quoted from [RFC2181], Section 6.) These days, this sense of
"origin" and "apex" (defined below) are often used "origin" and "apex" (defined below) are often used
interchangeably. interchangeably.
(b) The domain name within which a given relative domain name (b) The domain name within which a given relative domain name
appears in zone files. Generally seen in the context of appears in zone files. Generally seen in the context of
"$ORIGIN", which is a control entry defined in [RFC1035], "$ORIGIN", which is a control entry defined in [RFC1035],
skipping to change at page 23, line 40 skipping to change at page 24, line 11
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" (Quoted from [RFC2181], Section 5.4.1).
is sometimes used today with this wider definition in mind, the Although glue is sometimes used today with this wider definition
context surrounding the [RFC2181] definition suggests it is in mind, the context surrounding the [RFC2181] definition suggests
intended to apply to the use of glue within the document itself it is intended to apply to the use of glue within the document
and not necessarily beyond. itself and not necessarily beyond.
Bailiwick: "In-bailiwick" is an adjective to describe a name server Bailiwick: "In-bailiwick" is an adjective to describe a name server
whose name is either a subdomain of or (rarely) the same as the whose name is either a subdomain of or (rarely) the same as the
origin of the zone that contains the delegation to the name origin of the zone that contains the delegation to the name
server. In-bailiwick name servers may have glue records in their server. In-bailiwick name servers may have glue records in their
parent zone (using the first of the definitions of "glue records" parent zone (using the first of the definitions of "glue records"
in the definition above). (The term "bailiwick" means the in the definition above). (The term "bailiwick" means the
district or territory where a bailiff or policeman has district or territory where a bailiff or policeman has
jurisdiction.) jurisdiction.)
skipping to change at page 26, line 36 skipping to change at page 27, line 10
(Quoted from [RFC5155], Section 1.3) An earlier definition is "The (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 node in the zone's tree of existing domain names that has the most
labels matching the query name (consecutively, counting from the labels matching the query name (consecutively, counting from the
root label downward). Each match is a 'label match' and the order root label downward). Each match is a 'label match' and the order
of the labels is the same." (Quoted from [RFC4592], of the labels is the same." (Quoted from [RFC4592],
Section 3.3.1) Section 3.3.1)
Closest provable encloser: "The longest ancestor of a name that can Closest provable encloser: "The longest ancestor of a name that can
be proven to exist. Note that this is only different from the be proven to exist. Note that this is only different from the
closest encloser in an Opt-Out zone." (Quoted from [RFC5155], closest encloser in an Opt-Out zone." (Quoted from [RFC5155],
Section 1.3) Section 1.3) See Section 10 for more on "opt-out".
Next closer name: "The name one label longer than the closest Next closer name: "The name one label longer than the closest
provable encloser of a name." (Quoted from [RFC5155], provable encloser of a name." (Quoted from [RFC5155],
Section 1.3) Section 1.3)
Source of Synthesis: "The source of synthesis is defined in the Source of Synthesis: "The source of synthesis is defined in the
context of a query process as that wildcard domain name context of a query process as that wildcard domain name
immediately descending from the closest encloser, provided that immediately descending from the closest encloser, provided that
this wildcard domain name exists. 'Immediately descending' means this wildcard domain name exists. 'Immediately descending' means
that the source of synthesis has a name of the form: <asterisk that the source of synthesis has a name of the form: <asterisk
skipping to change at page 31, line 21 skipping to change at page 31, line 41
[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
sections of the response [are considered] to be authentic" sections of the response [are considered] to be authentic" (Quoted
([RFC4035]). DNS data or responses deemed to be authentic or from [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" (Quoted from [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, 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 6), "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) Also note DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note
that a ZSK is sometimes used to sign the apex DNSKEY RRset. 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
skipping to change at page 33, line 6 skipping to change at page 33, line 26
requirements and standards to be implemented for a DNSSEC-signed requirements and standards to be implemented for a DNSSEC-signed
zone." (Quoted from [RFC6841], Section 2) zone." (Quoted from [RFC6841], Section 2)
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 without
DNSSEC, HSMs are often used to hold the private keys for KSKs and ever disclosing the private key. In DNSSEC, HSMs are often used
ZSKs and to create the signatures used in RRSIG records at to hold the private keys for KSKs and ZSKs and to create the
periodic intervals. signatures used in RRSIG records at periodic intervals.
Signing software: Authoritative DNS servers that support DNSSEC Signing software: Authoritative DNS servers that support DNSSEC
often contain 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.
11. DNSSEC States 11. DNSSEC States
skipping to change at page 37, line 41 skipping to change at page 38, line 41
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>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-14 (work in
progress), August 2018.
[IANA_Resource_Registry] [IANA_Resource_Registry]
Internet Assigned Numbers Authority, "Resource Record (RR) Internet Assigned Numbers Authority, "Resource Record (RR)
TYPEs", 2017, TYPEs", 2017,
<http://www.iana.org/assignments/dns-parameters/>. <http://www.iana.org/assignments/dns-parameters/>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819, Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982, DOI 10.17487/RFC0819, August 1982,
<https://www.rfc-editor.org/info/rfc819>. <https://www.rfc-editor.org/info/rfc819>.
skipping to change at page 44, line 13 skipping to change at page 45, line 16
o "Zone transfer" in Section 6 o "Zone transfer" in Section 6
Index Index
A A
Address records 15 Address records 15
Alias 9 Alias 9
Anycast 21 Anycast 21
Apex 22 Apex 22
Asterisk label 26 Asterisk label 26
Authoritative data 22 Authoritative data 23
Authoritative server 18 Authoritative server 18
Authoritative-only server 18 Authoritative-only server 18
arpa: Address and Routing Parameter Area Domain 25 arpa: Address and Routing Parameter Area Domain 26
C C
CNAME 9 CNAME 9
Canonical name 9 Canonical name 9
Child 21 Child 22
Class independent 14 Class 10
Class independent 15
Closest encloser 26 Closest encloser 26
Closest provable encloser 26 Closest provable encloser 27
Combined signing key (CSK) 31 Combined signing key (CSK) 32
D D
DNS operator 27 DNS operator 28
DNSSEC Policy (DP) 32 DNSSEC Policy (DP) 33
DNSSEC Practice Statement (DPS) 32 DNSSEC Practice Statement (DPS) 33
DNSSEC-aware and DNSSEC-unaware 28 DNSSEC-aware and DNSSEC-unaware 29
Delegation 22 Delegation 23
Delegation-centric zone 25 Delegation-centric zone 25
Domain name 4 Domain name 4
E E
EDNS 13 EDNS 14
EPP 27 EPP 27
Empty non-terminals (ENT) 24 Empty non-terminals (ENT) 25
F F
FORMERR 9 FORMERR 9
Fast flux DNS 25 Fast flux DNS 25
Forward lookup 25 Forward lookup 26
Forwarder 19 Forwarder 20
Forwarding 19 Forwarding 19
Full resolver 17 Full resolver 17
Full-service resolver 17 Full-service resolver 17
Fully qualified domain name (FQDN) 7 Fully qualified domain name (FQDN) 7
G G
Global DNS 5 Global DNS 5
Glue records 23 Glue records 23
H H
Hardware security module (HSM) 33 Hardware security module (HSM) 33
Hidden master 19 Hidden master 19
Host name 8 Host name 8
I I
IDN 8 IDN 8
In-bailiwick 23 In-bailiwick 24
Insecure delegation 30 Insecure delegation 30
Instance 21 Instance 21
Iterative mode 16 Iterative mode 16
Iterative resolution 17 Iterative resolution 17
K K
Key signing key (KSK) 31 Key signing key (KSK) 32
L L
Label 5 Label 5
Lame delegation 23 Lame delegation 23
Locally served DNS zone 7 Locally served DNS zone 7
M M
Master file 13 Master file 13
Master server 18 Master server 19
Multicast DNS 7 Multicast DNS 7
N N
NODATA 10 NODATA 10
NOERROR 9 NOERROR 9
NOTIMP 9 NOTIMP 10
NS 18 NS 18
NSEC 29 NSEC 30
NSEC3 29 NSEC3 30
NXDOMAIN 9 NXDOMAIN 9
Naming system 4 Naming system 4
Negative caching 17 Negative caching 18
Negative response 10 Negative response 10
Next closer name 26 Next closer name 27
Non-recursive query 17 Non-recursive query 17
O O
OPT 13 OPT 14
Occluded name 25 Occluded name 25
Open resolver 20 Open resolver 20
Opt-out 30 Opt-out 30
Origin 21 Origin 22
Out-of-bailiwick 23 Out-of-bailiwick 24
Owner 13 Owner 14
P P
Parent 21 Parent 22
Passive DNS 21 Passive DNS 21
Policy-implementing resolver 20 Policy-implementing resolver 20
Presentation format 13 Presentation format 13
Primary master 19 Primary master 19
Primary server 18 Primary server 19
Priming 17 Priming 17
Privacy-enabling DNS server 21 Privacy-enabling DNS server 21
Private DNS 6 Private DNS 6
Public suffix 27 Public suffix 28
Q Q
QNAME 10 QNAME 11
R R
RDAP 27 RDAP 28
REFUSED 9 REFUSED 10
RR 13 RR 13
RRset 13 RRset 13
Recursive mode 16 Recursive mode 16
Recursive query 16 Recursive query 17
Recursive resolver 16 Recursive resolver 17
Referrals 12 Referrals 12
Registrant 27 Registrant 27
Registrar 27 Registrar 27
Registry 27 Registry 27
Resolver 15 Resolver 15
Reverse DNS, reverse lookup 25 Reverse DNS, reverse lookup 25
Root hints 17 Root hints 18
Root zone 24 Root zone 25
S S
SERVFAIL 9 SERVFAIL 9
SOA 13 SOA 14
SOA field names 13 SOA field names 14
Secondary server 18 Secondary server 19
Secure Entry Point (SEP) 32 Secure Entry Point (SEP) 32
Service name 25 Service name 26
Signed zone 29 Signed zone 29
Signing software 33 Signing software 33
Slave server 18 Slave server 18
Source of Synthesis 26 Source of Synthesis 27
Split DNS 20 Split DNS 20
Split-horizon DNS 20 Split-horizon DNS 20
Stealth server 19 Stealth server 19
Stub resolver 15 Stub resolver 16
Subdomain 8 Subdomain 9
Subordinate 28 Subordinate 28
Superordinate 28 Superordinate 28
T T
TLD 8 TLD 8
TTL 14 TTL 14
Trust anchor 32 Trust anchor 33
U U
Unsigned zone 29 Unsigned zone 29
V V
Validating resolver 31 Validating resolver 32
Validation 30 Validation 31
View 20 View 21
W W
WHOIS 27 WHOIS 27
Wildcard 26 Wildcard 26
Wildcard domain name 26 Wildcard domain name 26
Z Z
Zone 21 Zone 21
Zone cut 22 Zone cut 22
Zone enumeration 30 Zone enumeration 30
Zone signing key (ZSK) 31 Zone signing key (ZSK) 32
Zone transfer 18 Zone transfer 18
Acknowledgements Acknowledgements
The following is the Acknowledgements for RFC 7719. Additional The following is the Acknowledgements for RFC 7719.
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.
Most of the major changes between RFC 7719 and this document came Most of the major changes between RFC 7719 and this document came
 End of changes. 61 change blocks. 
136 lines changed or deleted 156 lines changed or added

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