rfc9499.original   rfc9499.txt 
Network Working Group P. Hoffman Internet Engineering Task Force (IETF) P. Hoffman
Internet-Draft ICANN Request for Comments: 9499 ICANN
Obsoletes: 8499 (if approved) K. Fujiwara BCP: 219 K. Fujiwara
Updates: 2308 (if approved) JPRS Obsoletes: 8499 JPRS
Intended status: Best Current Practice 25 September 2023 Updates: 2308 March 2024
Expires: 28 March 2024 Category: Best Current Practice
ISSN: 2070-1721
DNS Terminology DNS Terminology
draft-ietf-dnsop-rfc8499bis-10
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 changed in the of DNS protocols, and by operators of DNS systems, has changed in the
decades since the DNS was first defined. This document gives current decades 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 updates RFC 2308 by clarifying the definitions of This document updates RFC 2308 by clarifying the definitions of
"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple
terms and clarifications. Comprehensive lists of changed and new terms and clarifications. Comprehensive lists of changed and new
definitions can be found in Appendices A and B. definitions can be found in Appendices A and B.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 28 March 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9499.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Names
3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 3. DNS Response Codes
4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 11 4. DNS Transactions
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13 5. Resource Records
6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 16 6. DNS Servers and Clients
7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Zones
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Wildcards
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 29 9. Registration Model
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 31 10. General DNSSEC
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 36 11. DNSSEC States
12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 12. Security Considerations
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. IANA Considerations
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 14. References
14.1. Normative References . . . . . . . . . . . . . . . . . . 38 14.1. Normative References
14.2. Informative References . . . . . . . . . . . . . . . . . 42 14.2. Informative References
Appendix A. Definitions Updated by This Document . . . . . . . . 46 Appendix A. Definitions Updated by This Document
Appendix B. Definitions First Defined in This Document . . . . . 46 Appendix B. Definitions First Defined in This Document
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48 Acknowledgements
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Index
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses
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 "global DNS", which is often what people mean gives a definition of "global 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,
and later documents defined others. Some of the terms from [RFC1034] and later documents defined others. Some of the terms from [RFC1034]
and [RFC1035] have somewhat different meanings now than they did in and [RFC1035] have somewhat different meanings now than they did in
1987. 1987.
This document contains a collection of a wide variety of DNS-related This document contains a collection of a wide variety of DNS-related
terms, organized loosely by topic. Some of them have been precisely terms, organized loosely by topic. Some of them have been precisely
defined in earlier RFCs, some have been loosely defined in earlier defined in earlier RFCs, some have been loosely defined in earlier
RFCs, and some are not defined in an earlier RFC at all. RFCs, and some are not defined in an earlier RFC at all.
Other organizations sometimes define DNS-related terms their own way. Other organizations sometimes define DNS-related terms in their own
For example, the WHATWG defines "domain" at way. For example, the WHATWG defines "domain" at
<https://url.spec.whatwg.org/>. The Root Server System Advisory <https://url.spec.whatwg.org/>. The Root Server System Advisory
Committee (RSSAC) has a good lexicon [RSSAC026]. Committee (RSSAC) has a good lexicon [RSSAC026].
Most of the definitions listed here represent the consensus Most of the definitions listed here represent the consensus
definition of the DNS community -- both protocol developers and definition of the DNS community -- both protocol developers and
operators. Some of the definitions differ from earlier RFCs, and operators. Some of the definitions differ from earlier RFCs, and
those differences are noted. In this document, where the consensus those differences are noted. In this document, where the consensus
definition is the same as the one in an RFC, that RFC is quoted. definition is the same as the one in an RFC, that RFC is quoted.
Where the consensus definition has changed somewhat, the RFC is Where the consensus definition has changed somewhat, the RFC is
mentioned but the new stand-alone definition is given. See mentioned but the new stand-alone definition is given. See
skipping to change at page 3, line 45 skipping to change at line 135
way to deal with these differing definitions. way to deal with these differing definitions.
Capitalization in DNS terms is often inconsistent among RFCs and Capitalization in DNS terms is often inconsistent among RFCs and
various DNS practitioners. The capitalization used in this document various DNS practitioners. The capitalization used in this document
is a best guess at current practices, and is not meant to indicate is a best guess at current practices, and is not meant to indicate
that other capitalization styles are wrong or archaic. In some that other capitalization styles are wrong or archaic. In some
cases, multiple styles of capitalization are used for the same term cases, multiple styles of capitalization are used for the same term
due to quoting from different RFCs. due to quoting from different RFCs.
In this document, the words "byte" and "octet" are used In this document, the words "byte" and "octet" are used
interchangably. They both appear here because they both appear in interchangeably. They appear here because they both appear in the
the earlier RFCs that defined terms in the DNS. earlier RFCs that defined terms in the DNS.
Readers should note that the terms in this document are grouped by Readers should note that the terms in this document are grouped by
topic. Someone who is not already familiar with the DNS probably topic. Someone who is not already familiar with the DNS probably
cannot learn about the DNS from scratch by reading this document from cannot 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
skipping to change at page 5, line 6 skipping to change at line 188
([RFC1034] and [RFC1035]), and the definition here also applies to ([RFC1034] and [RFC1035]), and the definition here also applies to
systems other than the DNS. [RFC1034] defines the "domain name systems other than the DNS. [RFC1034] defines the "domain name
space" using mathematical trees and their nodes in graph theory, space" using mathematical trees and their nodes in graph theory,
and that definition has the same practical result as the and that definition has the same practical result as the
definition here. Any path of a directed acyclic graph can be definition here. Any path of a directed acyclic graph can be
represented by a domain name consisting of the labels of its represented by a domain name consisting of the labels of its
nodes, ordered by decreasing distance from the root(s) (which is nodes, ordered by decreasing distance from the root(s) (which is
the normal convention within the DNS, including this document). A the normal convention within the DNS, including this document). A
domain name whose last label identifies a root of the graph is domain name whose last label identifies a root of the graph is
fully qualified; other domain names whose labels form a strict fully qualified; other domain names whose labels form a strict
prefix of a fully-qualified domain name are relative to its first prefix of a fully qualified domain name are relative to its first
omitted node. 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 last 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
octet for this calculation. (Multicast DNS [RFC6762] allows names one octet for this calculation. (Multicast DNS [RFC6762]
up to 255 bytes plus a terminating zero byte based on a different allows names up to 255 bytes plus a terminating zero byte based
interpretation of RFC 1035 and what is included in the 255 on a different interpretation of RFC 1035 and what is included
octets.) in the 255 octets.)
Format of names: Names in the global DNS are domain names. There Format of names: Names in the global DNS are domain names. There
are three formats: wire format, presentation format, and common are three formats: wire format, presentation format, and common
display. display.
The basic wire format for names in the global DNS is a list of Wire format: The basic wire format for names in the global DNS
labels ordered by decreasing distance from the root, with the is a list of labels ordered by decreasing distance from the
root label last. Each label is preceded by a length octet. root, with the root label last. Each label is preceded by a
[RFC1035] also defines a compression scheme that modifies this length octet. [RFC1035] also defines a compression scheme
format. that modifies this format.
The presentation format for names in the global DNS is a list Presentation format: The presentation format for names in the
of labels ordered by decreasing distance from the root, encoded global DNS is a list of labels ordered by decreasing
as ASCII, with a "." character between each label. In distance from the root, encoded as ASCII, with a "."
presentation format, a fully-qualified domain name includes the character between each label. In presentation format, a
root label and the associated separator dot. For example, in fully qualified domain name includes the root label and the
presentation format, a fully-qualified domain name with two associated separator dot. For example, in presentation
non-root labels is always shown as "example.tld." instead of format, a fully qualified domain name with two non-root
"example.tld". [RFC1035] defines a method for showing octets labels is always shown as "example.tld." instead of
that do not display in ASCII. "example.tld". [RFC1035] defines a method for showing
octets that do not display in ASCII.
The common display format is used in applications and free Common display format: The common display format is used in
text. It is the same as the presentation format, but showing applications and free text. It is the same as the
the root label and the "." before it is optional and is rarely presentation format, but showing the root label and the "."
done. For example, in common display format, a fully-qualified before it is optional and is rarely done. For example, in
domain name with two non-root labels is usually shown as common display format, a fully qualified domain name with
"example.tld" instead of "example.tld.". Names in the common two non-root labels is usually shown as "example.tld"
display format are normally written such that the instead of "example.tld.". Names in the common display
directionality of the writing system presents labels by format are normally written such that the directionality of
decreasing distance from the root (so, in both English and the the writing system presents labels by decreasing distance
C programming language the root or Top-Level Domain (TLD) label from the root (so, in both English and the C programming
in the ordered list is rightmost; but in Arabic, it may be language, the root or Top-Level Domain (TLD) label in the
leftmost, depending on local conventions). ordered list is rightmost; but in Arabic, it may be
leftmost, depending on local conventions).
Administration of names: Administration is specified by delegation Administration of names: Administration is specified by
(see the definition of "delegation" in Section 7). Policies for delegation (see the definition of "delegation" in Section 7).
administration of the root zone in the global DNS are determined Policies for administration of the root zone in the global DNS
by the names operational community, which convenes itself in the are determined by the names operational community, which
Internet Corporation for Assigned Names and Numbers (ICANN). The convenes itself in the Internet Corporation for Assigned Names
names operational community selects the IANA Functions Operator and Numbers (ICANN). The names operational community selects
for the global DNS root zone. The name servers that serve the the IANA Functions Operator for the global DNS root zone. The
root zone are provided by independent root operators. Other zones name servers that serve the root zone are provided by
in the global DNS have their own policies for administration. independent root operators. Other zones in the global DNS have
their own policies for administration.
Types of data that can be associated with names: A name can have Types of data that can be associated with names: A name can have
zero or more resource records associated with it. There are zero or more resource records associated with it. There are
numerous types of resource records with unique data structures numerous types of resource records with unique data structures
defined in many different RFCs and in the IANA registry at defined in many different RFCs and in the IANA registry at
[IANA_Resource_Registry]. [IANA_Resource_Registry].
Types of metadata for names: Any name that is published in the DNS Types of metadata for names: Any name that is published in the
appears as a set of resource records (see the definition of DNS appears as a set of resource records (see the definition of
"RRset" in Section 5). Some names do not, themselves, have data "RRset" in Section 5). Some names do not, themselves, have
associated with them in the DNS, but they "appear" in the DNS data associated with them in the DNS, but they "appear" in the
anyway because they form part of a longer name that does have data DNS anyway because they form part of a longer name that does
associated with it (see the definition of "empty non-terminals" in have data associated with it (see the definition of "empty non-
Section 7). terminals" in Section 7).
Protocol for getting data from a name: The protocol described in Protocol for getting data from a name: The protocol described in
[RFC1035]. [RFC1035].
Context for resolving a name: The global DNS root zone distributed Context for resolving a name: The global DNS root zone
by Public Technical Identifiers (PTI). distributed by Public Technical Identifiers (PTIs).
Private DNS: Names that use the protocol described in [RFC1035] but Private DNS: Names that use the protocol described in [RFC1035] but
that do not rely on the global DNS root zone or names that are do not rely on the global DNS root zone or names that are
otherwise not generally available on the Internet but are using otherwise not generally available on the Internet but are using
the protocol described in [RFC1035]. A system can use both the the protocol described in [RFC1035]. A system can use both the
global DNS and one or more private DNS systems; for example, see global DNS and one or more private DNS systems; for example, see
"Split DNS" in Section 6. "Split DNS" in Section 6.
Note that domain names that do not appear in the DNS, and that are Note that domain names that do not appear in the DNS and that are
intended never to be looked up using the DNS protocol, are not intended never to be looked up using the DNS protocol are not part
part of the global DNS or a private DNS even though they are of the global DNS or a private DNS, even though they are domain
domain names. names.
Multicast DNS (mDNS): "Multicast DNS (mDNS) provides the ability to Multicast DNS (mDNS): "Multicast DNS (mDNS) provides the ability to
perform DNS-like operations on the local link in the absence of perform DNS-like operations on the local link in the absence of
any conventional Unicast DNS server. In addition, Multicast DNS any conventional Unicast DNS server. In addition, Multicast DNS
designates a portion of the DNS namespace to be free for local designates a portion of the DNS namespace to be free for local
use, without the need to pay any annual fee, and without the need use, without the need to pay any annual fee, and without the need
to set up delegations or otherwise configure a conventional DNS to set up delegations or otherwise configure a conventional DNS
server to answer for those names." (Quoted from [RFC6762], server to answer for those names." (Quoted from [RFC6762],
Abstract) Although it uses a compatible wire format, mDNS is, Abstract) Although it uses a compatible wire format, mDNS is,
strictly speaking, a different protocol than DNS. Also, where the strictly speaking, a different protocol than DNS. Also, where the
skipping to change at page 7, line 41 skipping to change at line 321
of private DNS. Names are resolved using the DNS protocol in a of private DNS. Names are resolved using the DNS protocol in a
local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that
are locally served zones. Resolution of names through locally are locally served zones. Resolution of names through locally
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 for a locally served DNS served DNS zone contexts. The context for a locally served DNS
zone may be explicit, such as those that are listed in [RFC6303] zone may be explicit, such as those that are listed in [RFC6303]
and [RFC7793], or implicit, such as those defined by local DNS and [RFC7793], or implicit, such as those defined by local DNS
administration and not known to the resolution client. administration and not known to the resolution client.
Fully-Qualified Domain Name (FQDN): This is often just a clear way Fully Qualified Domain Name (FQDN): This is often just a clear way
of saying the same thing as "domain name of a node", as outlined of saying the same thing as "domain name of a node", as outlined
above. However, the term is ambiguous. Strictly speaking, a above. However, the term is ambiguous. Strictly speaking, a
fully-qualified domain name would include every label, including fully qualified domain name would include every label, including
the 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 [RFC819].
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 last labels in the ordered list are where one or more of the last labels in the ordered list are
omitted (for example, a domain name of "www" relative to omitted (for example, a domain name of "www" relative to
"example.net" identifies "www.example.net"). Such relative names "example.net" identifies "www.example.net"). Such relative names
are understood only by 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 [RFC952], 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], which is also called the "preferred name syntax". (In [RFC1034], which is also called the "preferred name syntax". (In
that syntax, every character in each label is a letter, a digit, that syntax, every character in each label is a letter, a digit,
or a hyphen). Note that any label in a domain name can contain or a hyphen). Note that any label in a domain name can contain
any octet value; hostnames are generally considered to be domain any octet value; hostnames are generally considered to be domain
names where every label follows the rules in the "preferred name names where every label follows the rules in the "preferred name
syntax", with the amendment that labels can start with ASCII syntax", with the amendment that labels can start with ASCII
digits (this amendment comes from Section 2.1 of [RFC1123]). digits (this amendment comes from Section 2.1 of [RFC1123]).
skipping to change at page 10, line 36 skipping to change at line 452
a name server may not wish to provide the information to the a name server may not wish to provide the information to the
particular requester, or a name server may not wish to perform a particular requester, or a name server may not wish to perform a
particular operation (e.g., zone transfer) for particular data." particular operation (e.g., zone transfer) for particular data."
in Section 4.1.1 of [RFC1035]. in Section 4.1.1 of [RFC1035].
NODATA: "A pseudo RCODE which indicates that the name is valid, for NODATA: "A pseudo RCODE which indicates that the name is valid, for
the given class, but [there] are no records of the given type. A the given class, but [there] are no records of the given type. A
NODATA response has to be inferred from the answer." (Quoted from NODATA response has to be inferred from the answer." (Quoted from
[RFC2308], Section 1) "NODATA is indicated by an answer with the [RFC2308], Section 1) "NODATA is indicated by an answer with the
RCODE set to NOERROR and no relevant answers in the Answer RCODE set to NOERROR and no relevant answers in the Answer
section. The authority section will contain an SOA record, or section. The Authority section will contain an SOA record, or
there will be no NS records there." (Quoted from [RFC2308], there will be no NS records there." (Quoted from [RFC2308],
Section 2.2) Note that referrals have a similar format to NODATA Section 2.2) Note that referrals have a similar format to NODATA
replies; [RFC2308] explains how to distinguish them. replies; [RFC2308] explains how to distinguish them.
The term "NXRRSET" is sometimes used as a synonym for NODATA. The term "NXRRSET" is sometimes used as a synonym for NODATA.
However, this is a mistake, given that NXRRSET is a specific error However, this is a mistake, given that NXRRSET is a specific error
code defined in [RFC2136]. code defined in [RFC2136].
Negative response: A response that indicates that a particular RRset Negative response: A response that indicates that a particular RRset
does not exist or whose RCODE indicates that the nameserver cannot does not exist or whose RCODE indicates that the nameserver cannot
skipping to change at page 11, line 31 skipping to change at line 492
of information about the server itself rather than for a different of information about the server itself rather than for a different
type of address. 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 comes [RFC1034], Section 3.7.1) Strictly speaking, the definition comes
from [RFC1035], Section 4.1.2, where the QNAME is defined in 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 applied consistently, as the discussion of inverse queries in
Section 6.4.1 refers to the "owner name of the query RR and its Section 6.4.1 of [RFC1035] refers to the "owner name of the query
TTL", because inverse queries populate the Answer section and RR and its TTL" because inverse queries populate the Answer
leave the Question section empty. (Inverse queries are deprecated section and leave the Question section empty. (Inverse queries
in [RFC3425]; thus, relevant definitions do not appear in this are deprecated in [RFC3425]; thus, relevant definitions do not
document.) appear in this document.)
However, [RFC2308] has an alternate definition that puts the QNAME However, [RFC2308] has an alternate definition that puts the QNAME
in the answer (or series of answers) instead of the query. It in the answer (or series of answers) instead of the query. It
defines QNAME as "...the name in the query section of an answer, defines QNAME as "...the name in the query section of an answer,
or where this resolves to a CNAME, or CNAME chain, the data field or where this resolves to a CNAME, or CNAME chain, the data field
of the last CNAME. The last CNAME in this sense is that which of the last CNAME. The last CNAME in this sense is that which
contains a value which does not resolve to another CNAME." This contains a value which does not resolve to another CNAME." This
definition has a certain internal logic, because of the way CNAME definition has a certain internal logic, because of the way CNAME
substitution works and the definition of CNAME. If a name server substitution works and the definition of CNAME. If a name server
does not find an RRset that matches a query, but does find the does not find an RRset that matches a query, but does find the
skipping to change at page 12, line 21 skipping to change at line 531
that results in CNAME processing contains in the echoed Question that results in CNAME processing contains in the echoed Question
section one QNAME (the name in the original query) and a second section one QNAME (the name in the original query) and a second
QNAME that is in the data field of the last CNAME. The confusion QNAME that is in the data field of the last CNAME. The confusion
comes from the iterative/recursive mode of resolution, which comes from the iterative/recursive mode of resolution, which
finally returns an answer that need not actually have the same finally returns an answer that need not actually have the same
owner name as the QNAME contained in the original query. 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
between three meanings: between three meanings:
* QNAME (original): The name actually sent in the Question QNAME (original): The name actually sent in the Question section
section in the original query, which is always echoed in the in the original query, which is always echoed in the (final)
(final) reply in the Question section when the QR bit is set to reply in the Question section when the QR bit is set to 1.
1.
* QNAME (effective): A name actually resolved, which is either QNAME (effective): A name actually resolved, which is either the
the name originally queried or a name received in a CNAME chain name originally queried or a name received in a CNAME chain
response. response.
* QNAME (final): The name actually resolved, which is either the QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain name actually queried or else the last name in a CNAME chain
response. response.
Note that, because the definition in [RFC2308] is actually for a Note that, because the definition in [RFC2308] is actually for a
different concept than what was in [RFC1034], it would have been different concept than what was in [RFC1034], it would have been
better if [RFC2308] had used a different name for that concept. better if [RFC2308] had used a different name for that concept.
In general use today, QNAME almost always means what is defined In general use today, QNAME almost always means what is defined
above as "QNAME (original)". above as "QNAME (original)".
Referrals: A type of response in which a server, signaling that it Referrals: A type of response in which a server, signaling that it
skipping to change at page 13, line 6 skipping to change at line 561
querying resolver with an alternative place to send its query. querying resolver with an alternative place to send its query.
Referrals can be partial. Referrals can be partial.
A referral arises when a server is not performing recursive A referral arises when a server is not performing recursive
service while answering a query. It appears in step 3(b) of the service while answering a query. It appears in step 3(b) of the
algorithm in [RFC1034], Section 4.3.2. algorithm in [RFC1034], Section 4.3.2.
There are two types of referral response. The first is a downward There are two types of referral response. The first is a downward
referral (sometimes described as "delegation response"), where the referral (sometimes described as "delegation response"), where the
server is authoritative for some portion of the QNAME. The server is authoritative for some portion of the QNAME. The
authority section RRset's RDATA contains the name servers Authority section RRset's RDATA contains the name servers
specified at the referred-to zone cut. In normal DNS operation, specified at the referred-to zone cut. In normal DNS operation,
this kind of response is required in order to find names beneath a this kind of response is required in order to find names beneath a
delegation. The bare use of "referral" means this kind of delegation. The bare use of "referral" means this kind of
referral, and many people believe that this is the only legitimate referral, and many people believe that this is the only legitimate
kind of referral in the DNS. kind of referral in the DNS.
The second is an upward referral (sometimes described as "root The second is an upward referral (sometimes described as "root
referral"), where the server is not authoritative for any portion referral"), where the server is not authoritative for any portion
of the QNAME. When this happens, the referred-to zone in the of the QNAME. When this happens, the referred-to zone in the
authority section is usually the root zone ("."). In normal DNS Authority section is usually the root zone ("."). In normal DNS
operation, this kind of response is not required for resolution or operation, this kind of response is not required for resolution or
for correctly answering any query. There is no requirement that for correctly answering any query. There is no requirement that
any server send upward referrals. Some people regard upward any server send upward referrals. Some people regard upward
referrals as a sign of a misconfiguration or error. Upward referrals as a sign of a misconfiguration or error. Upward
referrals always need some sort of qualifier (such as "upward" or referrals always need some sort of qualifier (such as "upward" or
"root") and are never identified simply by the word "referral". "root") and are never identified simply by the word "referral".
A response that has only a referral contains an empty answer A response that has only a referral contains an empty Answer
section. It contains the NS RRset for the referred-to zone in the section. It contains 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 clear. the Additional section. The AA bit is clear.
In the case where the query matches an alias, and the server is In the case where the query matches an alias, and the server is
not authoritative for the target of the alias but is authoritative not authoritative for the target of the alias but is authoritative
for some name above the target of the alias, the resolution for some name above the target of the alias, the resolution
algorithm will produce a response that contains both the algorithm will produce a response that contains both the
authoritative answer for the alias and a referral. Such a partial authoritative answer for the alias and a referral. Such a partial
answer and referral response has data in the Answer section. It answer and referral response has data in the Answer section. It
has the NS RRset for the referred-to zone in the Authority has the NS RRset for the referred-to zone in the Authority
section. It may contain RRs that provide addresses in the section. It may contain RRs that provide addresses in the
additional section. The AA bit is set, because the first name in Additional section. The AA bit is set because the first name in
the Answer section matches the QNAME and the server is 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. (See [RFC1034], Section 3.6.) RR: An acronym for resource record. (See [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" (according to [RFC2181], type, but with different data" (according to [RFC2181],
Section 5). Also written as "RRSet" in some documents. As a Section 5). Also written as "RRSet" in some documents. As a
clarification, "same label" in this definition means "same owner clarification, "same label" in this definition means "same owner
name". In addition, [RFC2181] states that "the TTLs of all RRs in name". In addition, [RFC2181] states that "the TTLs of all RRs in
an RRSet must be the 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: [RFC4035] says:
An RRset MAY have multiple RRSIG RRs associated with it. Note "An RRset MAY have multiple RRSIG RRs associated with it. Note
that as RRSIG RRs are closely tied to the RRsets whose that as RRSIG RRs are closely tied to the RRsets whose
signatures they contain, RRSIG RRs, unlike all other DNS RR 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 RRSIG RRs with a common owner name do not follow the RRset
rules described in [RFC2181]. rules 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." (Quoted zone, though it can be used to list a cache's contents." (Quoted
from [RFC1035], Section 5) Master files are sometimes called "zone from [RFC1035], Section 5) Master files are sometimes called "zone
files". 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] or format is shown but not formally defined in [RFC1034] or
[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 paraphrased from sequence of a specific transaction. (Definition paraphrased from
[RFC6891], Section 6.1.1.) It is used by EDNS. [RFC6891], Section 6.1.1.) It is used by EDNS.
Owner: "The domain name where the RR is found." (Quoted from Owner: "The domain name where the RR is found." (Quoted from
[RFC1034], Section 3.6) Often appears in the term "owner name". [RFC1034], Section 3.6) Often appears in the term "owner name".
skipping to change at page 15, line 10 skipping to change at line 660
meaning of the MINIMUM field is updated in Section 4 of [RFC2308]; meaning of the MINIMUM field is updated in Section 4 of [RFC2308];
the new definition is that the MINIMUM field is only "the TTL to the new definition is that the MINIMUM field is only "the TTL to
be used for negative responses". This document tends to use field be used for negative responses". This document tends to use field
names instead of terms that describe the fields. names instead of terms that describe the fields.
TTL: The maximum "time to live" of a resource record. "A TTL value TTL: The maximum "time to live" of a resource record. "A TTL value
is an unsigned number, with a minimum value of 0, and a maximum is an unsigned number, with a minimum value of 0, and a maximum
value of 2147483647. That is, a maximum of 2^31 - 1. When value of 2147483647. That is, a maximum of 2^31 - 1. When
transmitted, this value shall be encoded in the less significant transmitted, this value shall be encoded in the less significant
31 bits of the 32 bit TTL field, with the most significant, or 31 bits of the 32 bit TTL field, with the most significant, or
sign, bit set to zero." (Quoted from [RFC2181], Section 8) (Note sign, bit set to zero." (Quoted from [RFC2181], Section 8) Note
that [RFC1035] erroneously stated that this is a signed integer; that [RFC1035] erroneously stated that this is a signed integer;
that was fixed by [RFC2181].) that was fixed by [RFC2181].
The TTL "specifies the time interval that the resource record may The TTL "specifies the time interval that the resource record may
be cached before the source of the information should again be be cached before the source of the information should again be
consulted." (Quoted from [RFC1035], Section 3.2.1) Section 4.1.3 consulted." (Quoted from [RFC1035], Section 3.2.1) Section 4.1.3
of the same document states: "the time interval (in seconds) that of [RFC1035] states "the time interval (in seconds) that the
the resource record may be cached before it should be discarded". resource record may be cached before it should be discarded".
Despite being defined for a resource record, the TTL of every Despite being defined for a resource record, the TTL of every
resource record in an RRset is required to be the same ([RFC2181], resource record in an RRset is required to be the same ([RFC2181],
Section 5.2). Section 5.2).
The reason that the TTL is the maximum time to live is that a The reason that the TTL is the maximum time to live is that a
cache operator might decide to shorten the time to live for cache operator might decide to shorten the time to live for
operational purposes, such as if there is a policy to disallow TTL operational purposes, for example, if there is a policy to
values over a certain number. Some servers are known to ignore disallow TTL values over a certain number. Some servers are known
the TTL on some RRsets (such as when the authoritative data has a to ignore the TTL on some RRsets (such as when the authoritative
very short TTL) even though this is against the advice in RFC data has a very short TTL) even though this is against the advice
1035. An RRset can be flushed from the cache before the end of in [RFC1035]. An RRset can be flushed from the cache before the
the TTL interval, at which point, the value of the TTL becomes end of the TTL interval, at which point, the value of the TTL
unknown because the RRset with which it was associated no longer becomes unknown because the RRset with which it was associated no
exists. longer exists.
There is also the concept of a "default TTL" for a zone, which can There is also the concept of a "default TTL" for a zone, which can
be a configuration parameter in the server software. This is be a configuration parameter in the server software. This is
often expressed by a default for the entire server, and a default often expressed by a default for the entire server, and a default
for a zone using the $TTL directive in a zone file. The $TTL for a zone using the $TTL directive in a zone file. The $TTL
directive was added to the master file format by [RFC2308]. directive was added to the master file format by [RFC2308].
Class independent: A resource record type whose syntax and semantics Class independent: A resource record type whose syntax and semantics
are the same for every DNS class. A resource record type that is are the same for every DNS class. A resource record type that is
not class independent has different meanings depending on the DNS not class independent has different meanings, depending on the DNS
class of the record, or the meaning is undefined for some class. class of the record or if the meaning is undefined for some
Most resource record types are defined for class 1 (IN, the classes. Most resource record types are defined for class 1 (IN,
Internet), but many are undefined for other classes. the Internet), but many are undefined for other classes.
Address records: Records whose type is A or AAAA. [RFC2181] Address records: Records whose type is either A or AAAA. [RFC2181]
informally defines these as "(A, AAAA, etc)". Note that new types informally defines these as "(A, AAAA, etc)". Note that new types
of address records could be defined in the future. of address records could be defined in the future.
6. DNS Servers and Clients 6. DNS Servers and Clients
This section defines the terms used for the systems that act as DNS This section defines the terms used for the systems that act as DNS
clients, DNS servers, or both. In past RFCs, DNS servers are clients, DNS servers, or both. In past RFCs, DNS servers are
sometimes called "name servers", "nameservers", or just "servers". sometimes called "name servers", "nameservers", or just "servers".
There is no formal definition of "DNS server", but RFCs generally There is no formal definition of "DNS server", but RFCs generally
assume that it is an Internet server that listens for queries and assume that it is an Internet server that listens for queries and
skipping to change at page 17, line 21 skipping to change at line 762
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 [RFC1034] says: "in [recursive] mode server". Section 4.3.1 of [RFC1034] says: "in [recursive] mode
the name server acts in the role of a resolver and returns either the name server acts in the role of a resolver and returns either
an error or the answer, but never referrals." That same section an error or the answer, but never referrals." That same section
also says: also says:
The recursive mode occurs when a query with RD set arrives at a "The recursive mode occurs when a query with RD set arrives at
server which is willing to provide recursive service; the a server which is willing to provide recursive service; the
client can verify that recursive mode was used by checking that client can verify that recursive mode was used by checking 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". In practice, it is not they are called "recursive resolvers". In practice, it is not
possible to know in advance whether the server that one is 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.
skipping to change at page 18, line 29 skipping to change at line 816
resolution algorithm is described in Section 5.3.3 of [RFC1034]. resolution algorithm is described in Section 5.3.3 of [RFC1034].
Full resolver: This term is used in [RFC1035], but it is not defined Full resolver: This term is used in [RFC1035], but it is not defined
there. RFC 1123 defines a "full-service resolver" that may or may there. RFC 1123 defines a "full-service resolver" that may or may
not be what was intended by "full resolver" in [RFC1035]. This not be what was intended by "full resolver" in [RFC1035]. This
term is not properly defined in any RFC, and there is no consensus term is not properly defined in any RFC, and there is no consensus
on what the term means. The use of this term without proper on what the term means. The use of this term without proper
context is discouraged. context is discouraged.
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 as a resolver that acts in recursive mode with a cache (and
(and meets other requirements). meets other requirements).
Priming: "The act of finding the list of root servers from a Priming: "The act of finding the list of root servers from a
configuration that lists some or all of the purported IP addresses configuration that lists some or all of the purported IP addresses
of some or all of those root servers." (Quoted from [RFC8109], of some or all of those root servers." (Quoted from [RFC8109],
Section 2) In order to operate in recursive mode, a resolver needs Section 2) In order to operate in recursive mode, a resolver needs
to know the address of at least one root server. Priming is most to know the address of at least one root server. Priming is most
often done from a configuration setting that contains a list of often done from a configuration setting that contains a list of
authoritative servers for the root zone. 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
skipping to change at page 19, line 36 skipping to change at line 870
"responds to requests for recursion with responses indicating that "responds to requests for recursion with responses indicating that
recursion was not performed". recursion was not performed".
Zone transfer: The act of a client requesting a copy of a zone and Zone transfer: The act of a client requesting a copy of a zone and
an authoritative server sending the needed information. (See an authoritative server sending the needed information. (See
Section 7 for a description of zones.) There are two common Section 7 for a description of zones.) There are two common
standard ways to do zone transfers: the AXFR ("Authoritative standard ways to do zone transfers: the AXFR ("Authoritative
Transfer") mechanism to copy the full zone (described in Transfer") mechanism to copy the full zone (described in
[RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
only parts of the zone that have changed (described in [RFC1995]). only parts of the zone that have changed (described in [RFC1995]).
Many systems use non-standard methods for zone transfer outside Many systems use non-standard methods for zone transfers outside
the DNS protocol. the DNS protocol.
Slave server: See "Secondary server". Slave server: See "Secondary server".
Secondary server: "An authoritative server which uses zone transfer Secondary server: "An authoritative server which uses zone transfer
to retrieve the zone." (Quoted from [RFC1996], Section 2.1) to retrieve the zone." (Quoted from [RFC1996], Section 2.1)
Secondary servers are also discussed in [RFC1034]. [RFC2182] Secondary servers are also discussed in [RFC1034]. [RFC2182]
describes secondary servers in more detail. Although early DNS describes secondary servers in more detail. Although early DNS
RFCs such as [RFC1996] referred to this as a "slave", the current RFCs such as [RFC1996] referred to this as a "slave", the current
common usage has shifted to calling it a "secondary". common usage has shifted to calling it a "secondary".
skipping to change at page 20, line 32 skipping to change at line 913
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)
Hidden master: A stealth server that is a primary server for zone Hidden master: A stealth server that is a primary server for zone
transfers. "In this arrangement, the master name server that transfers. "In this arrangement, the master name server that
processes the updates is unavailable to general hosts on the processes the updates is unavailable to general hosts on the
Internet; it is not listed in the NS RRset." (Quoted from Internet; it is not listed in the NS RRset." (Quoted from
[RFC6781], Section 3.4.3) An earlier RFC, [RFC4641], said that the [RFC6781], Section 3.4.3) [RFC4641] said that the hidden master's
hidden master's name "appears in the SOA RRs MNAME field", name "appears in the SOA RRs MNAME field"; however, the name does
although, in some setups, the name does not appear at all in the not appear at all in the global DNS in some setups. A hidden
global DNS. A hidden master can also be a secondary server for master can also be a secondary server for the zone itself.
the zone itself.
Forwarding: The process of one server sending a DNS query with the Forwarding: The process of one server sending a DNS query with the
RD bit set to 1 to another server to resolve that query. RD bit set to 1 to another server to resolve that query.
Forwarding is a function of a DNS resolver; it is different than Forwarding is a function of a DNS resolver; it is different than
simply blindly relaying queries. simply blindly relaying queries.
[RFC5625] does not give a specific definition for forwarding, but [RFC5625] does not give a specific definition for forwarding, but
describes in detail what features a system that forwards needs to describes in detail what features a system that forwards needs to
support. Systems that forward are sometimes called "DNS proxies", support. Systems that forward are sometimes called "DNS proxies",
but that term has not yet been defined (even in [RFC5625]). but that term has not yet been defined (even in [RFC5625]).
skipping to change at page 21, line 35 skipping to change at line 963
used more with open resolvers that are meant to be open, as used more with open resolvers that are meant to be open, as
compared to the vast majority of open resolvers that are probably compared to the vast majority of open resolvers that are probably
misconfigured to be open. Open resolvers are discussed in misconfigured to be open. Open resolvers are discussed in
[RFC5358]. [RFC5358].
Split DNS: The terms "split DNS" and "split-horizon DNS" have long Split DNS: The terms "split DNS" and "split-horizon DNS" have long
been used in the DNS community without formal definition. In been used in the DNS community without formal definition. In
general, they refer to situations in which DNS servers that are general, they refer to situations in which DNS servers that are
authoritative for a particular set of domains provide partly or authoritative for a particular set of domains provide partly or
completely different answers in those domains depending on the completely different answers in those domains depending on the
source of the query. The effect of this is that a domain name source of the query. Nevertheless, the effect of this is that a
that is notionally globally unique nevertheless has different domain name that is notionally globally unique has different
meanings for different network users. This can sometimes be the meanings for different network users. This can sometimes be the
result of a "view" configuration, described below. result of a "view" configuration, as described below.
Section 3.8 of [RFC2775] gives a related definition that is too Section 3.8 of [RFC2775] gives a related definition that is too
specific to be generally useful. specific to be generally useful.
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 responses depending on attributes of the query, such as different responses depending on attributes of the query, such as
for "split DNS". Typically, views differ by the source IP address for "split DNS". Typically, views differ by the source IP address
of a query, but can also be based on the destination IP address, of a query, but can also be based on the destination IP address,
the type of query (such as AXFR), whether it is recursive, and so the type of query (such as AXFR), whether it is recursive, and so
on. Views are often used to provide more names or different on. Views are often used to provide more names or different
addresses to queries from "inside" a protected network than to addresses to queries from "inside" a protected network than to
those "outside" that network. Views are not a standardized part those "outside" that network. Views are not a standardized part
of the DNS, but they are widely implemented in server software. of the DNS, but they are widely implemented in server software.
Passive DNS: A mechanism to collect DNS data by storing DNS Passive DNS: A mechanism to collect DNS data by storing DNS
responses from name servers. Some of these systems also collect responses from name servers. Some of these systems also collect
the DNS queries associated with the responses, although doing so the DNS queries associated with the responses, although doing so
raises some privacy concerns. Passive DNS databases can be used raises some privacy concerns. Passive DNS databases can be used
to answer historical questions about DNS zones such as which to answer historical questions about DNS zones, such as which
values were present at a given time in the past, or when a name values were present at a given time in the past, or when a name
was spotted first. Passive DNS databases allow searching of the was spotted first. Passive DNS databases allow searching of the
stored records on keys other than just the name and type, such as stored records on keys other than just the name and type, such as
"find all names which have A records of a particular value". "find all names which have A records of a particular value".
Anycast: "The practice of making a particular service address Anycast: "The practice of making a particular service address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations." datagrams sent are routed to one of several available locations."
(Quoted from [RFC4786], Section 2) See [RFC4786] for more detail (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail
on Anycast and other terms that are specific to its use. on Anycast and other terms that are specific to its use.
skipping to change at page 22, line 40 skipping to change at line 1016
servers might also be considered privacy-enabling, such as those servers might also be considered privacy-enabling, such as those
running DNS-over-HTTPS [RFC8484] or DNS-over-QUIC [RFC9250]. running DNS-over-HTTPS [RFC8484] or DNS-over-QUIC [RFC9250].
DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its
successors. successors.
DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its
successors. successors.
DNS-over-QUIC (DoQ): DNS over QUIC as defined in [RFC9250] and its DNS-over-QUIC (DoQ): DNS over QUIC as defined in [RFC9250] and its
successors. [RFC9250] specifically defines DoQ as a general successors. [RFC9250] specifically defines DoQ as general-purpose
purpose transport for DNS that can be used in stub to recursive, transport for DNS that can be used in stub to recursive, recursive
recursive to authoritative or zone transfer scenarios. to authoritative, and zone transfer scenarios.
Classic DNS: DNS over UDP or TCP as defined in [RFC1035] and its Classic DNS: DNS over UDP or DNS over TCP as defined in [RFC1035]
successors. Classic DNS applies to DNS communication between stub and its successors. Classic DNS applies to DNS communication
resolvers and recursive resolvers, and between recursive resolvers between stub resolvers and recursive resolvers, and between
and authoritative servers. This has sometimes been called "Do53". recursive resolvers and authoritative servers. This has sometimes
Classic DNS is not encrypted. been called "Do53". Classic DNS is not encrypted.
Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for
transport between a stub resolver and a recursive resolver, or transport between a stub resolver and a recursive resolver, or
between a recursive resolver and another recursive resolver. This between a recursive resolver and another recursive resolver. This
term is necessary because it is expected that DNS-over-TLS will term is necessary because it is expected that DNS-over-TLS will
later be defined as a transport between recursive resolvers and later be defined as a transport between recursive resolvers and
authoritative servers. authoritative servers.
Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a
transport between recursive resolvers and authoritative servers, transport between recursive resolvers and authoritative servers,
skipping to change at page 23, line 37 skipping to change at line 1060
zone." (Quoted from [RFC1034], Section 2.4) zone." (Quoted from [RFC1034], Section 2.4)
Child: "The entity on record that has the delegation of the domain Child: "The entity on record that has the delegation of the domain
from the Parent." (Quoted from [RFC7344], Section 1.1) from the Parent." (Quoted from [RFC7344], Section 1.1)
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 [RFC819] also has some description of the relationship between
parents and children. parents and children.
Origin: Origin:
There are two different uses for this term: There are two different uses for this term:
(a) "The domain name that appears at the top of a zone (just (a) "The domain name that appears at the top of a zone (just
below the cut that separates the zone from its parent)... The below the cut that separates the zone from its parent)... The
name of the zone is the same as the name of the domain at the name of the zone is the same as the name of the domain at the
zone's origin." (Quoted from [RFC2181], Section 6) These zone's origin." (Quoted from [RFC2181], Section 6) These
skipping to change at page 24, line 45 skipping to change at line 1114
when an NS RRset is added in the parent zone for the child origin. when an NS RRset is added in the parent zone for the child origin.
Delegation inherently happens at a zone cut. The term is also Delegation inherently happens at a zone cut. The term is also
commonly a noun: the new zone that is created by the act of commonly a noun: the new zone that is created by the act of
delegating. delegating.
Authoritative data: "All of the RRs attached to all of the nodes 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) Note that this definition might inadvertently also Section 4.2.1) Note that this definition might inadvertently also
cause any NS records that appear in the zone to be included, even cause any NS records that appear in the zone to be included, even
those that might not truly be authoritative because there are 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.
[RFC4033], Section 2, defines "Authoritative RRset", which is [RFC4033], Section 2, defines "Authoritative RRset", which is
related to authoritative data but has a more precise definition. related to authoritative data but has a more precise definition.
Lame delegation: "A lame delegations exists [sic] when a nameserver Lame delegation: "A lame delegations exists [sic] when a nameserver
is delegated responsibility for providing nameservice for a zone is delegated responsibility for providing nameservice for a zone
skipping to change at page 25, line 19 skipping to change at line 1137
the zone)." (Quoted from [RFC1912], Section 2.8) Another the zone)." (Quoted from [RFC1912], Section 2.8) Another
definition is that a lame delegation "...happens when a name definition is that a lame delegation "...happens when a name
server is listed in the NS records for some domain and in fact it server is listed in the NS records for some domain and in fact it
is not a server for that domain. Queries are thus sent to the is not a server for that domain. Queries are thus sent to the
wrong servers, who don't know nothing [sic] (at least not as wrong servers, who don't know nothing [sic] (at least not as
expected) about the queried domain. Furthermore, sometimes these expected) about the queried domain. Furthermore, sometimes these
hosts (if they exist!) don't even run name servers." (Quoted from hosts (if they exist!) don't even run name servers." (Quoted from
[RFC1713], Section 2.3) [RFC1713], Section 2.3)
These early definitions do not match the current use of the term These early definitions do not match the current use of the term
"lame delegation", but there is not consensus on what a lame "lame delegation", but there is no consensus on what a lame
delegation is. The term is used not only for the specific case delegation is. The term is used not only for the specific case
described above, but for a variety of other flaws in delegations described above, but for a variety of other flaws in delegations
that lead to non-authoritative answers or no answers at all, such that lead to non-authoritative answers or no answers at all, such
as: as:
* a nameserver with an NS record for a zone that does not answer * a nameserver with an NS record for a zone that does not answer
DNS queries DNS queries;
* a nameserver with an IP address that is not reachable by the * a nameserver with an IP address that is not reachable by the
resolver resolver; and
* a nameserver that responds to a query for a specific name with * a nameserver that responds to a query for a specific name with
an error or without the authoritative bit set an error or without the authoritative bit set.
Because the term in current usage has drifted from the original Because the term in current usage has drifted from the original
definition, and now is not specific or clear as to the intended definition, and now is not specific or clear as to the intended
meaning, it should be considered historic, and avoided in favor of meaning, it should be considered historic and avoided in favor of
terms that are specific and clear. terms that are specific and clear.
Glue records: "...[Resource records] which are not part of the Glue records: "...[Resource records] which are not part of the
authoritative data [of the zone], and are address RRs for the authoritative data [of the zone], and are address RRs for the
[name] servers [in subzones]. These RRs are only necessary if the [name] servers [in subzones]. These RRs are only necessary if the
name server's name is 'below' the cut, and are only used as part name server's name is 'below' the cut, and are only used as part
of a referral response." Without glue "we could be faced with the of a referral response." Without glue "we could be faced with the
situation where the NS RRs tell us that in order to learn a name situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address server's address, we should contact the server using the address
we wish to learn." (Quoted from [RFC1034], Section 4.2.1) we wish to learn." (Quoted from [RFC1034], Section 4.2.1)
skipping to change at page 26, line 10 skipping to change at line 1177
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." (Quoted from [RFC2181], Section 5.4.1) data that might appear." (Quoted from [RFC2181], Section 5.4.1)
Although glue is sometimes used today with this wider definition Although glue is sometimes used today with this wider definition
in mind, the context surrounding the definition in [RFC2181] in mind, the context surrounding the definition in [RFC2181]
suggests it is intended to apply to the use of glue within the suggests it is intended to apply to the use of glue within the
document itself and not necessarily beyond. document itself and not necessarily beyond.
In an NS record, there are three types of relationships between In an NS record, there are three types of relationships between
the owner name of the record and the name in the NS RDATA and the the owner name of the record, the name in the NS RDATA, and the
zone origin: unrelated, in-domain, and sibling domain. The zone origin: unrelated, in-domain, and sibling domain. The
application of these three types of relationships to glue records application of these three types of relationships to glue records
is defined in [I-D.ietf-dnsop-glue-is-not-optional]. is defined in [RFC9471].
An unrelated relationship is one where the NS RDATA contains a An unrelated relationship is one where the NS RDATA contains a
name server that is not subordinate to the zone origin and name server that is not subordinate to the zone origin and
therefore is not part of the same zone. therefore is not part of the same zone.
An in-domain relationship is one where the NS RDATA contains a An in-domain relationship is one where the NS RDATA contains a
name server whose name is either subordinate to or (rarely) the name server whose name is either subordinate to or (rarely) the
same as the owner name of the NS resource records. For example, a same as the owner name of the NS resource records. For example, a
delegation for "child.example.com" might have an in-domain name delegation for "child.example.com" might have an in-domain name
server called "ns.child.example.com". server called "ns.child.example.com".
skipping to change at page 27, line 36 skipping to change at line 1233
Bailiwick: "In-bailiwick" and "Out-of-bailiwick" are modifiers used Bailiwick: "In-bailiwick" and "Out-of-bailiwick" are modifiers used
to describe the relationship between a zone and the name servers to describe the relationship between a zone and the name servers
for that zone. The dictionary definition of bailiwick has been for that zone. The dictionary definition of bailiwick has been
observed to cause more confusion than meaning for this use. These observed to cause more confusion than meaning for this use. These
terms should be considered historic in nature. terms should be considered historic in nature.
Root zone: The zone of a DNS-based tree whose apex is the zero- Root zone: The zone of a DNS-based tree whose apex is the zero-
length label. Also sometimes called "the DNS root". length label. Also sometimes called "the DNS root".
Empty non-terminals (ENT): "Domain names that own no resource Empty non-terminals (ENTs): "Domain names that own no resource
records but have subdomains that do." (Quoted from [RFC4592], records but have subdomains that do." (Quoted from [RFC4592],
Section 2.2.2) A typical example is in SRV records: in the name Section 2.2.2) A typical example is in SRV records: in the name
"_sip._tcp.example.com", it is likely that "_tcp.example.com" has "_sip._tcp.example.com", it is likely that "_tcp.example.com" has
no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
RRset. RRset.
Delegation-centric zone: A zone that consists mostly of delegations Delegation-centric zone: A zone that consists mostly of delegations
to child zones. This term is used in contrast to a zone that to child zones. This term is used in contrast to a zone that
might have some delegations to child zones but also has many data might have some delegations to child zones but also has many data
resource records for the zone itself and/or for child zones. The resource records for the zone itself and/or for child zones. The
skipping to change at page 28, line 16 skipping to change at line 1260
The addition of a DNAME resource record has the same impact. The The addition of a DNAME resource record has the same impact. The
subordinate names are said to be 'occluded'." (Quoted from subordinate names are said to be 'occluded'." (Quoted from
[RFC5936], Section 3.5) [RFC5936], Section 3.5)
Fast flux DNS: This "occurs when a domain is [found] in DNS using A Fast flux DNS: This "occurs when a domain is [found] in DNS using A
records to multiple IP addresses, each of which has a very short records to multiple IP addresses, each of which has a very short
Time-to-Live (TTL) value associated with it. This means that the Time-to-Live (TTL) value associated with it. This means that the
domain resolves to varying IP addresses over a short period of domain resolves to varying IP addresses over a short period of
time." (Quoted from [RFC6561], Section 1.1.5, with a typo time." (Quoted from [RFC6561], Section 1.1.5, with a typo
corrected) In addition to having legitimate uses, fast flux DNS corrected) In addition to having legitimate uses, fast flux DNS
can used to deliver malware. Because the addresses change so can be used to deliver malware. Because the addresses change so
rapidly, it is difficult to ascertain all the hosts. It should be rapidly, it is difficult to ascertain all the hosts. It should be
noted that the technique also works with AAAA records, but such noted that the technique also works with AAAA records, but such
use is not frequently observed on the Internet as of this writing. use is not frequently observed on the Internet as of this writing.
Reverse DNS, reverse lookup: "The process of mapping an address to a Reverse DNS, reverse lookup: "The process of mapping an address to a
name is generally known as a 'reverse lookup', and the IN- name is generally known as a 'reverse lookup', and the IN-
ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
DNS'." (Quoted from [RFC5855], Section 1) DNS'." (Quoted from [RFC5855], Section 1)
Forward lookup: "Hostname-to-address translation". (Quoted from Forward lookup: "Hostname-to-address translation". (Quoted from
[RFC3493], Section 6) [RFC3493], Section 6)
arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain arpa (Address and Routing Parameter Area Domain): "The 'arpa' domain
was originally established as part of the initial deployment of was originally established as part of the initial deployment of
the DNS, to provide a transition mechanism from the Host Tables the DNS to provide a transition mechanism from the Host Tables
that were common in the ARPANET, as well as a home for the IPv4 that were common in the ARPANET, as well as a home for the IPv4
reverse mapping domain. During 2000, the abbreviation was reverse mapping domain. During 2000, the abbreviation was
redesignated to 'Address and Routing Parameter Area' in the hope redesignated to 'Address and Routing Parameter Area' in the hope
of reducing confusion with the earlier network name." (Quoted of reducing confusion with the earlier network name." (Quoted
from [RFC3172], Section 2) .arpa is an "infrastructure domain", a from [RFC3172], Section 2) .arpa is an "infrastructure domain", a
domain whose "role is to support the operating infrastructure of domain whose "role is to support the operating infrastructure of
the Internet". (Quoted from [RFC3172], Section 2) See [RFC3172] the Internet". (Quoted from [RFC3172], Section 2) See [RFC3172]
for more history of this name. for more history of this name.
Service name: "Service names are the unique key in the Service Name Service name: "Service names are the unique key in the Service Name
skipping to change at page 30, line 36 skipping to change at line 1374
WHOIS: A protocol specified in [RFC3912], often used for querying WHOIS: A protocol specified in [RFC3912], often used for querying
registry databases. WHOIS data is frequently used to associate registry databases. WHOIS data is frequently used to associate
registration data (such as zone management contacts) with domain registration data (such as zone management contacts) with domain
names. The term "WHOIS data" is often used as a synonym for the names. The term "WHOIS data" is often used as a synonym for the
registry database, even though that database may be served by registry database, even though that database may be served by
different protocols, particularly RDAP. The WHOIS protocol is different protocols, particularly RDAP. The WHOIS protocol is
also used with IP address registry data. also used with IP address registry data.
RDAP: The Registration Data Access Protocol, defined in [RFC7480], RDAP: The Registration Data Access Protocol, defined in [RFC7480],
[RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The [RFC7481], [RFC7485], [RFC9082], [RFC9083], and [RFC9224]. The
RDAP protocol and data format are meant as a replacement for RDAP protocol and data format are meant as a replacement for
WHOIS. WHOIS.
DNS operator: An entity responsible for running DNS servers. For a DNS operator: An entity responsible for running DNS servers. For a
zone's authoritative servers, the registrant may act as their own zone's authoritative servers, the registrant may act as their own
DNS operator, their registrar may do it on their behalf, or they DNS operator, their registrar may do it on their behalf, or they
may use a third-party operator. For some zones, the registry may use a third-party operator. For some zones, the registry
function is performed by the DNS operator plus other entities who function is performed by the DNS operator plus other entities who
decide about the allowed contents of the zone. decide about the allowed contents of the zone.
skipping to change at page 31, line 11 skipping to change at line 1397
term is a domain under which subdomains can be registered by third term is a domain under which subdomains can be registered by third
parties and on which HTTP cookies (which are described in detail parties and on which HTTP cookies (which are described in detail
in [RFC6265]) should not be set. There is no indication in a in [RFC6265]) should not be set. There is no indication in a
domain name whether it is a public suffix; that can only be domain name whether it is a public suffix; that can only be
determined by outside means. In fact, both a domain and a determined by outside means. In fact, both a domain and a
subdomain of that domain can be public suffixes. subdomain of that domain can be 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
(https://publicsuffix.org/). <https://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 it may be significantly changed in community for many reasons, and it 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 was the case registration policy for the zone changes, such as was the case
skipping to change at page 32, line 51 skipping to change at line 1484
NSEC: "The NSEC record allows a security-aware resolver to NSEC: "The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non- authenticate a negative reply for either name or type non-
existence with the same mechanisms used to authenticate other DNS existence with the same mechanisms used to authenticate other DNS
replies." (Quoted from [RFC4033], Section 3.2) In short, an NSEC replies." (Quoted from [RFC4033], Section 3.2) In short, an NSEC
record provides authenticated denial of existence. record provides authenticated denial of existence.
"The NSEC resource record lists two separate things: the next "The NSEC resource record lists two separate things: the next
owner name (in the canonical ordering of the zone) that contains owner name (in the canonical ordering of the zone) that contains
authoritative data or a delegation point NS RRset, and the set of authoritative data or a delegation point NS RRset, and the set of
RR types present at the NSEC RR's owner name." (Quoted from RR types present at the NSEC RR's owner name." (Quoted from
Section 4 of RFC 4034) Section 4 of [RFC4034])
NSEC3: Like the NSEC record, the NSEC3 record also provides NSEC3: Like the NSEC record, the NSEC3 record also provides
authenticated denial of existence; however, NSEC3 records mitigate authenticated denial of existence; however, NSEC3 records mitigate
zone enumeration and support Opt-Out. NSEC3 resource records zone enumeration and support Opt-Out. NSEC3 resource records
require associated NSEC3PARAM resource records. NSEC3 and require associated NSEC3PARAM resource records. NSEC3 and
NSEC3PARAM resource records are defined in [RFC5155]. NSEC3PARAM resource records are defined in [RFC5155].
Note that [RFC6840] says that [RFC5155] "is now considered part of Note that [RFC6840] says that [RFC5155] "is now considered part of
the DNS Security Document Family as described by Section 10 of the DNS Security Document Family as described by Section 10 of
[RFC4033]". This means that some of the definitions from earlier [RFC4033]". This means that some of the definitions from earlier
skipping to change at page 33, line 48 skipping to change at line 1529
Validation: Validation, in the context of DNSSEC, refers to one of Validation: Validation, in the context of DNSSEC, refers to one of
the following: the following:
* Checking the validity of DNSSEC signatures, * Checking the validity of DNSSEC signatures,
* Checking the validity of DNS responses, such as those including * Checking the validity of DNS responses, such as those including
authenticated denial of existence, or authenticated denial of existence, or
* Building an authentication chain from a trust anchor to a DNS * Building an authentication chain from a trust anchor to a DNS
response or individual DNS RRsets in a response response or individual DNS RRsets in a response.
The first two definitions above consider only the validity of The first two definitions above consider only the validity of
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; thus, it requires the entire DNSSEC authentication chain; thus, it 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"; thus, it uses the first and third signed DNS response"; thus, it uses the first and third
definitions above. The process of validating an RRSIG resource definitions above. The process of validating an RRSIG resource
record is 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
sections of the response [are considered] to be authentic" (Quoted sections of the response [are considered] to be authentic" (Quoted
from [RFC4035]) DNS data or responses deemed to be authentic or from [RFC4035]) DNS data or responses deemed to be authentic or
skipping to change at page 34, line 39 skipping to change at line 1567
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..." (Quoted from override the [DNSSEC] protocol extensions..." (Quoted from
[RFC4033], Section 3.1) [RFC4033], Section 3.1)
The term "verification", when used, is usually a synonym for The term "verification", when used, is usually a 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
skipping to change at page 36, line 29 skipping to change at line 1653
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
A validating resolver can determine that a response is in one of four A validating resolver can determine that a response is in one of four
states: secure, insecure, bogus, or indeterminate. These states are states: secure, insecure, bogus, or indeterminate. These states are
defined in [RFC4033] and [RFC4035], although the definitions in the defined in [RFC4033] and [RFC4035], although the definitions in the
two documents differ a bit. This document makes no effort to two documents differ a bit. This document makes no effort to
reconcile the definitions in the two documents, and takes no position reconcile the definitions in the two documents and takes no position
as to whether they need to be reconciled. as to whether they need to be reconciled.
Section 5 of [RFC4033] says: Section 5 of [RFC4033] says:
A validating resolver can determine the following 4 states: | A validating resolver can determine the following 4 states:
| Secure: The validating resolver has a trust anchor, has a chain
Secure: The validating resolver has a trust anchor, has a chain | of trust, and is able to verify all the signatures in the
of trust, and is able to verify all the signatures in the | response.
response. |
| Insecure: The validating resolver has a trust anchor, a chain of
Insecure: The validating resolver has a trust anchor, a chain | trust, and, at some delegation point, signed proof of the non-
of trust, and, at some delegation point, signed proof of the | existence of a DS record. This indicates that subsequent
non-existence of a DS record. This indicates that subsequent | branches in the tree are provably insecure. A validating
branches in the tree are provably insecure. A validating | resolver may have a local policy to mark parts of the domain
resolver may have a local policy to mark parts of the domain | space as insecure.
space as insecure. |
| Bogus: The validating resolver has a trust anchor and a secure
Bogus: The validating resolver has a trust anchor and a secure | delegation indicating that subsidiary data is signed, but the
delegation indicating that subsidiary data is signed, but | response fails to validate for some reason: missing signatures,
the response fails to validate for some reason: missing | expired signatures, signatures with unsupported algorithms,
signatures, expired signatures, signatures with unsupported | data missing that the relevant NSEC RR says should be present,
algorithms, data missing that the relevant NSEC RR says | and so forth.
should be present, and so forth. |
| Indeterminate: There is no trust anchor that would indicate that
Indeterminate: There is no trust anchor that would indicate that a | a specific portion of the tree is secure. This is the default
specific portion of the tree is secure. This is the default | operation mode.
operation mode.
Section 4.3 of [RFC4035] says: Section 4.3 of [RFC4035] says:
A security-aware resolver must be able to distinguish between four | A security-aware resolver must be able to distinguish between four
cases: | cases:
| Secure: An RRset for which the resolver is able to build a chain
Secure: An RRset for which the resolver is able to build a chain | of signed DNSKEY and DS RRs from a trusted security anchor to
of signed DNSKEY and DS RRs from a trusted security anchor to | the RRset. In this case, the RRset should be signed and is
the RRset. In this case, the RRset should be signed and is | subject to signature validation, as described above.
subject to signature validation, as described above. |
| Insecure: An RRset for which the resolver knows that it has no
Insecure: An RRset for which the resolver knows that it has no | chain of signed DNSKEY and DS RRs from any trusted starting
chain of signed DNSKEY and DS RRs from any trusted starting | point to the RRset. This can occur when the target RRset lies
point to the RRset. This can occur when the target RRset lies | in an unsigned zone or in a descendent [sic] of an unsigned
in an unsigned zone or in a descendent [sic] of an unsigned | zone. In this case, the RRset may or may not be signed, but
zone. In this case, the RRset may or may not be signed, but | the resolver will not be able to verify the signature.
the resolver will not be able to verify the signature. |
| Bogus: An RRset for which the resolver believes that it ought to
Bogus: An RRset for which the resolver believes that it ought to | be able to establish a chain of trust but for which it is
be able to establish a chain of trust but for which it is | unable to do so, either due to signatures that for some reason
unable to do so, either due to signatures that for some reason | fail to validate or due to missing data that the relevant
fail to validate or due to missing data that the relevant | DNSSEC RRs indicate should be present. This case may indicate
DNSSEC RRs indicate should be present. This case may indicate | an attack but may also indicate a configuration error or some
an attack but may also indicate a configuration error or some | form of data corruption.
form of data corruption. |
| Indeterminate: An RRset for which the resolver is not able to
Indeterminate: An RRset for which the resolver is not able to | determine whether the RRset should be signed, as the resolver
determine whether the RRset should be signed, as the resolver | is not able to obtain the necessary DNSSEC RRs. This can occur
is not able to obtain the necessary DNSSEC RRs. This can occur | when the security-aware resolver is not able to contact
when the security-aware resolver is not able to contact | security-aware name servers for the relevant zones.
security-aware name servers for the relevant zones.
12. Security Considerations 12. Security Considerations
These definitions do not change any security considerations for These definitions do not change any security considerations for
either the global DNS or the private DNS. either the global DNS or private DNS.
13. IANA Considerations 13. IANA Considerations
Any reference to RFC 8499 in the IANA registries should be replaced References to RFC 8499 in the IANA registries have been replaced with
with a reference to this document. references to this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-dnsop-glue-is-not-optional]
Andrews, M. P., Huque, S., Wouters, P., and D. Wessels,
"DNS Glue Requirements in Referral Responses", Work in
Progress, Internet-Draft, draft-ietf-dnsop-glue-is-not-
optional-09, 14 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
glue-is-not-optional-09>.
[IANA_RootFiles] [IANA_RootFiles]
IANA, "Root Files", IANA, "Root Files",
<https://www.iana.org/domains/root/files>. <https://www.iana.org/domains/root/files>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<https://www.rfc-editor.org/info/rfc882>. <https://www.rfc-editor.org/info/rfc882>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
skipping to change at page 42, line 14 skipping to change at line 1866
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250, Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022, DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>. <https://www.rfc-editor.org/info/rfc9250>.
[RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS
Glue Requirements in Referral Responses", RFC 9471,
DOI 10.17487/RFC9471, September 2023,
<https://www.rfc-editor.org/info/rfc9471>.
14.2. Informative References 14.2. Informative References
[IANA_Resource_Registry] [IANA_Resource_Registry]
IANA, "Resource Record (RR) TYPEs", IANA, "Resource Record (RR) TYPEs",
<https://www.iana.org/assignments/dns-parameters/>. <https://www.iana.org/assignments/dns-parameters/>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC819] 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>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952, host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <https://www.rfc-editor.org/info/rfc952>. October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713, [RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713,
DOI 10.17487/RFC1713, November 1994, DOI 10.17487/RFC1713, November 1994,
<https://www.rfc-editor.org/info/rfc1713>. <https://www.rfc-editor.org/info/rfc1713>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
<https://www.rfc-editor.org/info/rfc1995>. <https://www.rfc-editor.org/info/rfc1995>.
skipping to change at page 45, line 19 skipping to change at line 2022
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015, RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>. <https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015, RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>. <https://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc7482>. <https://www.rfc-editor.org/info/rfc9082>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483, Registration Data Access Protocol (RDAP)", STD 95,
DOI 10.17487/RFC7483, March 2015, RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc7483>. <https://www.rfc-editor.org/info/rfc9083>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March Access Protocol (RDAP) Service", STD 95, RFC 9224,
2015, <https://www.rfc-editor.org/info/rfc7484>. DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>. <https://www.rfc-editor.org/info/rfc7485>.
[RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4 [RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4
Locally-Served DNS Zones Registry", BCP 163, RFC 7793, Locally-Served DNS Zones Registry", BCP 163, RFC 7793,
DOI 10.17487/RFC7793, May 2016, DOI 10.17487/RFC7793, May 2016,
<https://www.rfc-editor.org/info/rfc7793>. <https://www.rfc-editor.org/info/rfc7793>.
skipping to change at page 46, line 19 skipping to change at line 2071
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
Mankin, "DNS Zone Transfer over TLS", RFC 9103, Mankin, "DNS Zone Transfer over TLS", RFC 9103,
DOI 10.17487/RFC9103, August 2021, DOI 10.17487/RFC9103, August 2021,
<https://www.rfc-editor.org/info/rfc9103>. <https://www.rfc-editor.org/info/rfc9103>.
[RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC [RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC0226
Lexicon", 2017, RSSAC Lexicon", 2017,
<https://www.icann.org/en/system/files/files/rssac- <https://www.icann.org/en/system/files/files/rssac-
026-14mar17-en.pdf>. 026-14mar17-en.pdf>.
Appendix A. Definitions Updated by This Document Appendix A. Definitions Updated by This Document
The following definitions from RFCs are updated by this document: The following definitions from RFCs are updated by this document:
* Forwarder in [RFC2308] * Forwarder in [RFC2308]
* QNAME in [RFC2308] * QNAME in [RFC2308]
skipping to change at page 47, line 4 skipping to change at line 2104
* "arpa" in Section 7 * "arpa" in Section 7
* "Authoritative DoT (ADot)" in Section 6 * "Authoritative DoT (ADot)" in Section 6
* "Bailiwick" in Section 7 * "Bailiwick" in Section 7
* "Class independent" in Section 5 * "Class independent" in Section 5
* "Classic DNS" in Section 6 * "Classic DNS" in Section 6
* "Delegation-centric zone" in Section 7 * "Delegation-centric zone" in Section 7
* "Delegation" in Section 7 * "Delegation" in Section 7
* "DNS operator" in Section 9 * "DNS operator" in Section 9
* "DNSSEC-aware" in Section 10 * "DNSSEC-aware" in Section 10
* "DNSSEC-unaware" in Section 10 * "DNSSEC-unaware" in Section 10
* "Forwarding" in Section 6 * "Forwarding" in Section 6
* "Full resolver" in Section 6 * "Full resolver" in Section 6
* "Fully-qualified domain name" in Section 2 * "Fully Qualified Domain Name" in Section 2
* "Global DNS" in Section 2 * "Global DNS" in Section 2
* "Hardware Security Module (HSM)" in Section 10 * "Hardware Security Module (HSM)" in Section 10
* "Host name" in Section 2 * "Host name" in Section 2
* "IDN" in Section 2 * "IDN" in Section 2
* "In-domain" in Section 7 * "In-domain" in Section 7
skipping to change at page 48, line 4 skipping to change at line 2152
* "Open resolver" in Section 6 * "Open resolver" in Section 6
* "Passive DNS" in Section 6 * "Passive DNS" in Section 6
* "Policy-implementing resolver" in Section 6 * "Policy-implementing resolver" in Section 6
* "Presentation format" in Section 5 * "Presentation format" in Section 5
* "Priming" in Section 6 * "Priming" in Section 6
* "Private DNS" in Section 2 * "Private DNS" in Section 2
* "Recrusive DoT (RDot)" in Section 6 * "Recursive DoT (RDot)" in Section 6
* "Recursive resolver" in Section 6 * "Recursive resolver" in Section 6
* "Referrals" in Section 4 * "Referrals" in Section 4
* "Registrant" in Section 9 * "Registrant" in Section 9
* "Registrar" in Section 9 * "Registrar" in Section 9
* "Registry" in Section 9 * "Registry" in Section 9
skipping to change at page 48, line 46 skipping to change at line 2195
* "Validating resolver" in Section 10 * "Validating resolver" in Section 10
* "Validation" in Section 10 * "Validation" in Section 10
* "View" in Section 6 * "View" in Section 6
* "Zone transfer" in Section 6 * "Zone transfer" in Section 6
Acknowledgements Acknowledgements
RFC 8499 and its predecessor, RFC 7719, were co-authored by Andrew [RFC8499] and its predecessor, [RFC7719], were co-authored by Andrew
Sullivan. The current document, which is a small update to RFC 8499, Sullivan. The current document, which is a small update to
has just two authors. Andrew's work on the earlier documents is [RFC8499], has just two authors. Andrew's work on the earlier
greatly appreciated. documents is greatly appreciated.
Numerous people made significant contributions to RFC 8499 and RFC Numerous people made significant contributions to [RFC8499] and
7719. Please see the acknowledgements sections in those two [RFC7719]. Please see the acknowledgements sections in those two
documents for the extensive list of contributors. documents for the extensive list of contributors.
Even though the current document is a small revision, many people in Even though the current document is a small revision, many people in
the DNSOP Working Group have contributed to it, and their work is the DNSOP Working Group have contributed to it, and their work is
greatly appreciated. greatly appreciated.
Index Index
A B C D E F G H I K L M N O P Q R S T U V W X Z A B C D E F G H I K L M N O P Q R S T U V W X Z
A A
Address and Routing Parameter Area Domain (arpa)
Section 7
Address records Address records
Section 5 Section 5
ADoT ADoT
Section 6 Section 6
Alias Alias
Section 2 Section 2
Anycast Anycast
Section 6 Section 6
Apex Apex
Section 7 Section 7
arpa: Address and Routing Parameter Area Domain
Section 7
Asterisk label Asterisk label
Section 8 Section 8
Authoritative data Authoritative data
Section 7 Section 7
Authoritative server Authoritative server
Section 6 Section 6
Authoritative-only server Authoritative-only server
Section 6 Section 6
AXoT AXoT
Section 6 Section 6
skipping to change at page 50, line 4 skipping to change at line 2248
Bailiwick Bailiwick
Section 7 Section 7
C C
Canonical name Canonical name
Section 2 Section 2
Child Child
Section 7 Section 7
Class Class
Section 4 Section 4
Class independent Class independent
Section 5 Section 5
Classic DNS Classic DNS
Section 6 Section 6
Closest encloser Closest encloser
Section 8 Section 8
Closest provable encloser Closest provable encloser
Section 8 Section 8
CNAME CNAME
Section 2 Section 2
Combined signing key (CSK) Combined Signing Key (CSK)
Section 10 Section 10
D D
Delegation Delegation
Section 7 Section 7
Delegation-centric zone Delegation-centric zone
Section 7 Section 7
DNS operator DNS operator
Section 9 Section 9
skipping to change at page 51, line 4 skipping to change at line 2296
Section 2 Section 2
DoQ DoQ
Section 6 Section 6
DoT DoT
Section 6 Section 6
E E
EDNS EDNS
Section 5 Section 5
Empty non-terminals (ENTs)
Empty non-terminals (ENT)
Section 7 Section 7
EPP EPP
Section 9 Section 9
F F
Fast flux DNS Fast flux DNS
Section 7 Section 7
FORMERR FORMERR
Section 3 Section 3
Forward lookup Forward lookup
Section 7 Section 7
Forwarder Forwarder
Section 6 Section 6
Forwarding Forwarding
Section 6 Section 6
Full resolver Full resolver
Section 6 Section 6
Full-service resolver Full-service resolver
Section 6 Section 6
Fully-qualified domain name (FQDN) Fully Qualified Domain Name (FQDN)
Section 2 Section 2
G G
Global DNS Global DNS
Section 2 Section 2
Glue records Glue records
Section 7 Section 7
H H
skipping to change at page 52, line 4 skipping to change at line 2344
Section 2 Section 2
I I
IDN IDN
Section 2 Section 2
In-bailiwick In-bailiwick
Section 7 Section 7
In-domain In-domain
Section 7 Section 7
Insecure delegation Insecure delegation
Section 10 Section 10
Instance Instance
Section 6 Section 6
Internationalized Domain Name Internationalized Domain Name
Section 2 Section 2
Iterative mode Iterative mode
Section 6 Section 6
Iterative resolution Iterative resolution
Section 6 Section 6
IXoT IXoT
Section 6 Section 6
K K
Key signing key (KSK) Key Signing Key (KSK)
Section 10 Section 10
L L
Label Label
Section 2 Section 2
Lame delegation Lame delegation
Section 7 Section 7
Locally served DNS zone Locally served DNS zone
Section 2 Section 2
skipping to change at page 56, line 50 skipping to change at line 2579
Section 6 Section 6
Z Z
Zone Zone
Section 7 Section 7
Zone cut Zone cut
Section 7 Section 7
Zone enumeration Zone enumeration
Section 10 Section 10
Zone signing key (ZSK) Zone Signing Key (ZSK)
Section 10 Section 10
Zone transfer Zone transfer
Section 6 Section 6
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
 End of changes. 105 change blocks. 
308 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.48.