draft-ietf-dnsop-rfc8499bis-00.txt   draft-ietf-dnsop-rfc8499bis-01.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft ICANN Internet-Draft ICANN
Obsoletes: 8499 (if approved) K. Fujiwara Obsoletes: 8499 (if approved) K. Fujiwara
Updates: 2308 (if approved) JPRS Updates: 2308 (if approved) JPRS
Intended status: Best Current Practice 17 November 2020 Intended status: Best Current Practice 20 November 2020
Expires: 21 May 2021 Expires: 24 May 2021
DNS Terminology DNS Terminology
draft-ietf-dnsop-rfc8499bis-00 draft-ietf-dnsop-rfc8499bis-01
Abstract Abstract
The Domain Name System (DNS) is defined in literally dozens of The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes of DNS protocols, and by operators of DNS systems, has sometimes
changed in the decades since the DNS was first defined. This changed in the decades since the DNS was first defined. This
document gives current definitions for many of the terms used in the document gives current definitions for many of the terms used in the
DNS in a single document. DNS in a single document.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 May 2021. This Internet-Draft will expire on 24 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13
6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15
7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 27 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 28
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 29 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 30
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 34 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . 36 14.1. Normative References . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . 39 14.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Definitions Updated by This Document . . . . . . . . 43 Appendix A. Definitions Updated by This Document . . . . . . . . 45
Appendix B. Definitions First Defined in This Document . . . . . 44 Appendix B. Definitions First Defined in This Document . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (Section 2 whose messages in both directions have the same format. (Section 2
gives a definition of "public DNS", which is often what people mean gives a definition of "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.
skipping to change at page 15, line 49 skipping to change at page 15, line 49
assume that it is an Internet server that listens for queries and assume that it is an Internet server that listens for queries and
sends responses using the DNS protocol defined in [RFC1035] and its sends responses using the DNS protocol defined in [RFC1035] and its
successors. successors.
It is important to note that the terms "DNS server" and "name server" It is important to note that the terms "DNS server" and "name server"
require context in order to understand the services being provided. require context in order to understand the services being provided.
Both authoritative servers and recursive resolvers are often called Both authoritative servers and recursive resolvers are often called
"DNS servers" and "name servers" even though they serve different "DNS servers" and "name servers" even though they serve different
roles (but may be part of the same software package). roles (but may be part of the same software package).
For terminology specific to the public DNS root server system, see For terminology specific to the global DNS root server system, see
[RSSAC026]. That document defines terms such as "root server", "root [RSSAC026]. That document defines terms such as "root server", "root
server operator", and terms that are specific to the way that the server operator", and terms that are specific to the way that the
root zone of the public DNS is served. root zone of the global DNS is served.
Resolver: A program "that extract[s] information from name servers Resolver: A program "that extract[s] information from name servers
in response to client requests." (Quoted from [RFC1034], in response to client requests." (Quoted from [RFC1034],
Section 2.4) A resolver performs queries for a name, type, and Section 2.4) A resolver performs queries for a name, type, and
class, and receives responses. The logical function is called class, and receives responses. The logical function is called
"resolution". In practice, the term is usually referring to some "resolution". In practice, the term is usually referring to some
specific type of resolver (some of which are defined below), and specific type of resolver (some of which are defined below), and
understanding the use of the term depends on understanding the understanding the use of the term depends on understanding the
context. context.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
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) An earlier RFC, [RFC4641], said that the
hidden master's name "appears in the SOA RRs MNAME field", hidden master's name "appears in the SOA RRs MNAME field",
although, in some setups, the name does not appear at all in the although, in some setups, the name does not appear at all in the
public DNS. A hidden master can also be a secondary server for global DNS. A hidden 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",
skipping to change at page 22, line 5 skipping to change at page 21, line 51
commonly referred to as an 'instance'." It goes on to say: "An commonly referred to as an 'instance'." It goes on to say: "An
instance of a server, such as a root server, is often referred to instance of a server, such as a root server, is often referred to
as an 'Anycast instance'." (Quoted from [RSSAC026]) as an 'Anycast instance'." (Quoted from [RSSAC026])
Privacy-enabling DNS server: "A DNS server that implements DNS over Privacy-enabling DNS server: "A DNS server that implements DNS over
TLS [RFC7858] and may optionally implement DNS over DTLS TLS [RFC7858] and may optionally implement DNS over DTLS
[RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS
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]. running DNS over HTTPS [RFC8484].
DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its
successors.
DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its
successors.
DNS-over-QUIC (DoQ): DNS over QUIC as defined in
[I-D.ietf-dprive-dnsoquic]
Classic DNS: DNS over UDP or TCP as defined in [RFC1035] and its
successors. Classic DNS applies to DNS communication between stub
resolvers and recursive resolvers, and between recursive resolvers
and authoritative servers. This has sometimes been called "Do53".
Classic DNS is not encrypted.
Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for
transport between a stub resolver and a recursive resolver, or
between a recursive resolver and another recursive resolver. This
term is necessary because it is expected that DNS-over-TLS will
later be defined as a transport between recursive resolvers and
authoritative servers,
Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a
transport between recursive resolvers and authoritative servers,
ADoT specifically means DNS-over-TLS for transport between
recursive resolvers and authoritative servers.
7. Zones 7. Zones
This section defines terms that are used when discussing zones that This section defines terms that are used when discussing zones that
are being served or retrieved. are being served or retrieved.
Zone: "Authoritative information is organized into units called Zone: "Authoritative information is organized into units called
ZONEs, and these zones can be automatically distributed to the ZONEs, and these zones can be automatically distributed to the
name servers which provide redundant service for the data in a name servers which provide redundant service for the data in a
zone." (Quoted from [RFC1034], Section 2.4) zone." (Quoted from [RFC1034], Section 2.4)
skipping to change at page 25, line 11 skipping to change at page 25, line 33
to or (rarely) the same as the zone origin and not subordinate to or (rarely) the same as the zone origin and not subordinate
to or the same as the owner name of the NS resource records. to or the same as the owner name of the NS resource records.
Glue records for sibling domains are allowed, but not Glue records for sibling domains are allowed, but not
necessary. For example, a delegation for "child.example.com" necessary. For example, a delegation for "child.example.com"
in "example.com" zone may have "sibling" name server name in "example.com" zone may have "sibling" name server name
"ns.another.example.com". "ns.another.example.com".
"Out-of-bailiwick" is the antonym of "in-bailiwick". It is a "Out-of-bailiwick" is the antonym of "in-bailiwick". It is a
modifier to describe a name server whose name is not subordinate modifier to describe a name server whose name is not subordinate
to or the same as the zone origin. Glue records for out-of- to or the same as the zone origin. Glue records for out-of-
bailiwick name servers are useless. The following table shows bailiwick name servers are useless.
examples of delegation types.
Delegation |Parent|Name Server Name | Type The following table shows examples of delegation types.
-----------+------+------------------+-----------------------------
com | . |a.gtld-servers.net|in-bailiwick / sibling domain +=============+========+====================+==================+
net | . |a.gtld-servers.net|in-bailiwick / in-domain | Delegation | Parent | Name Server Name | Type |
example.org| org |ns.example.org |in-bailiwick / in-domain +=============+========+====================+==================+
example.org| org |ns.ietf.org |in-bailiwick / sibling domain | com | . | a.gtld-servers.net | in-bailiwick / |
example.org| org |ns.example.com |out-of-bailiwick | | | | sibling domain |
example.jp | jp |ns.example.jp |in-bailiwick / in-domain +-------------+--------+--------------------+------------------+
example.jp | jp |ns.example.ne.jp |in-bailiwick / sibling domain | net | . | a.gtld-servers.net | in-bailiwick / |
example.jp | jp |ns.example.com |out-of-bailiwick | | | | in-domain |
+-------------+--------+--------------------+------------------+
| example.org | org | ns.example.org | in-bailiwick / |
| | | | in-domain |
+-------------+--------+--------------------+------------------+
| example.org | org | ns.ietf.org | in-bailiwick / |
| | | | sibling domain |
+-------------+--------+--------------------+------------------+
| example.org | org | ns.example.com | out-of-bailiwick |
+-------------+--------+--------------------+------------------+
| example.jp | jp | ns.example.jp | in-bailiwick / |
| | | | in-domain |
+-------------+--------+--------------------+------------------+
| example.jp | jp | ns.example.ne.jp | in-bailiwick / |
| | | | sibling domain |
+-------------+--------+--------------------+------------------+
| example.jp | jp | ns.example.com | out-of-bailiwick |
+-------------+--------+--------------------+------------------+
Table 1
Root zone: The zone of a DNS-based tree whose apex is the zero- Root zone: The zone of a DNS-based tree whose apex is the zero-
length label. Also sometimes called "the DNS root". length label. Also sometimes called "the DNS root".
Empty non-terminals (ENT): "Domain names that own no resource Empty non-terminals (ENT): "Domain names that own no resource
records but have subdomains that do." (Quoted from [RFC4592], records but have subdomains that do." (Quoted from [RFC4592],
Section 2.2.2) A typical example is in SRV records: in the name Section 2.2.2) A typical example is in SRV records: in the name
"_sip._tcp.example.com", it is likely that "_tcp.example.com" has "_sip._tcp.example.com", it is likely that "_tcp.example.com" has
no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
RRset. RRset.
skipping to change at page 29, line 11 skipping to change at page 30, line 11
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
(http://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 39, line 45 skipping to change at page 40, line 45
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[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>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", Work in Progress,
Internet-Draft, draft-ietf-dprive-dnsoquic-01, 20 October
2020, <http://www.ietf.org/internet-drafts/draft-ietf-
dprive-dnsoquic-01.txt>.
[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 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819, Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982, DOI 10.17487/RFC0819, August 1982,
<https://www.rfc-editor.org/info/rfc819>. <https://www.rfc-editor.org/info/rfc819>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
skipping to change at page 44, line 15 skipping to change at page 45, line 26
Appendix B. Definitions First Defined in This Document Appendix B. Definitions First Defined in This Document
The following definitions are first defined in this document: The following definitions are first defined in this document:
* "Alias" in Section 2 * "Alias" in Section 2
* "Apex" in Section 7 * "Apex" in Section 7
* "arpa" in Section 7 * "arpa" in Section 7
* "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
* "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
skipping to change at page 45, line 22 skipping to change at page 46, line 36
* "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 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 46, line 24 skipping to change at page 47, line 40
Numerous people made significant contributions to RFC 8499 and RFC Numerous people made significant contributions to RFC 8499 and RFC
7719. Please see the acknowledgements sections in those two 7719. Please see the acknowledgements sections in those two
documents for the extensive list of contributors. documents for the extensive list of contributors.
Index Index
A C D E F G H I K L M N O P Q R S T U V W Z A C D E F G H I K L M N O P Q R S T U V W Z
A A
ADoT
ADoT
Address records Address records
Address records Address records
Alias Alias
Alias Alias
Anycast Anycast
Anycast Anycast
Apex Apex
Apex Apex
Asterisk label Asterisk label
Asterisk label Asterisk label
skipping to change at page 46, line 51 skipping to change at page 48, line 22
arpa: Address and Routing Parameter Area Domain arpa: Address and Routing Parameter Area Domain
C C
CNAME CNAME
CNAME CNAME
Canonical name Canonical name
Canonical name Canonical name
Child Child
Child Child
Class independent Class independent
Class independent Class independent
Classic DNS
Classic DNS
Class Class
Class Class
Closest encloser Closest encloser
Closest encloser Closest encloser
Closest provable encloser Closest provable encloser
Closest provable encloser Closest provable encloser
Combined signing key (CSK) Combined signing key (CSK)
Combined signing key (CSK) Combined signing key (CSK)
D D
DNS operator DNS operator
DNS operator DNS operator
DNS-over-HTTPS
DNS-over-HTTPS
DNS-over-QUIC
DNS-over-QUIC
DNS-over-TLS
DNS-over-TLS
DNSSEC Policy (DP) DNSSEC Policy (DP)
DNSSEC Policy (DP) DNSSEC Policy (DP)
DNSSEC Practice Statement (DPS) DNSSEC Practice Statement (DPS)
DNSSEC Practice Statement (DPS) DNSSEC Practice Statement (DPS)
DNSSEC-aware and DNSSEC-unaware DNSSEC-aware and DNSSEC-unaware
DNSSEC-aware and DNSSEC-unaware DNSSEC-aware and DNSSEC-unaware
Delegation-centric zone Delegation-centric zone
Delegation-centric zone Delegation-centric zone
Delegation Delegation
Delegation Delegation
DoH
DoH
DoQ
DoQ
DoT
DoT
Domain name Domain name
Domain name Domain name
E E
EDNS EDNS
EDNS EDNS
EPP EPP
EPP EPP
Empty non-terminals (ENT) Empty non-terminals (ENT)
Empty non-terminals (ENT) Empty non-terminals (ENT)
F F
skipping to change at page 50, line 19 skipping to change at page 51, line 51
Private DNS Private DNS
Private DNS Private DNS
Public suffix Public suffix
Public suffix Public suffix
Q Q
QNAME QNAME
QNAME QNAME
R R
RDAP RDAP
RDAP RDAP
RDoT
RDoT
REFUSED REFUSED
REFUSED REFUSED
RRset RRset
RRset RRset
RR RR
RR RR
Recursive DoT
Recursive DoT
Recursive mode Recursive mode
Recursive mode Recursive mode
Recursive query Recursive query
Recursive query Recursive query
Recursive resolver Recursive resolver
Recursive resolver Recursive resolver
Referrals Referrals
Referrals Referrals
Registrant Registrant
Registrant Registrant
 End of changes. 22 change blocks. 
34 lines changed or deleted 113 lines changed or added

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