draft-ietf-dnsop-terminology-bis-07.txt   draft-ietf-dnsop-terminology-bis-08.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft ICANN Internet-Draft ICANN
Obsoletes: 7719 (if approved) A. Sullivan Obsoletes: 7719 (if approved) A. Sullivan
Updates: 2308 (if approved) Oracle Updates: 2308 (if approved) Oracle
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: April 21, 2018 JPRS Expires: May 31, 2018 JPRS
October 18, 2017 November 27, 2017
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-07 draft-ietf-dnsop-terminology-bis-08
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018. This Internet-Draft will expire on May 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 9
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 11 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 13 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 13
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 23 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 24
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 24 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 25
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 28 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Definitions Updated by this Document . . . . . . . . 36 Appendix A. Definitions Updated by this Document . . . . . . . . 37
Appendix B. Definitions First Defined in this Document . . . . . 37 Appendix B. Definitions First Defined in this Document . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (See whose messages in both directions have the same format. (See
Section 2 for a fuller definition.) The protocol and message format Section 2 for a fuller definition.) The protocol and message format
are defined in [RFC1034] and [RFC1035]. These RFCs defined some are defined in [RFC1034] and [RFC1035]. These RFCs defined some
terms, but later documents defined others. Some of the terms from terms, but later documents defined others. Some of the terms from
[RFC1034] and [RFC1035] now have somewhat different meanings than [RFC1034] and [RFC1035] now have somewhat different meanings than
they did in 1987. they did in 1987.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
* QNAME (effective): A name actually resolved, which is either * QNAME (effective): A name actually resolved, which is either
the name originally queried, or a name received in a CNAME the name originally queried, or a name received in a CNAME
chain response. chain response.
* QNAME (final): The name actually resolved, which is either the * QNAME (final): The name actually resolved, which is either the
name actually queried or else the last name in a CNAME chain name actually queried or else the last name in a CNAME chain
response. response.
Some of response codes that are defined in [RFC1035] have acquired Some of response codes that are defined in [RFC1035] have acquired
their own shorthand names. Some common response code names that their own shorthand names. All of the RCODEs are listed at
appear without reference to the numeric value are "FORMERR",
"SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
as "Name Error"). All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps. uses mixed-case capitalization, while most documents use all-caps.
Some of the names are described here, but the official list is in the
IANA registry.
NOERROR: "No error condition" (Quoted from [RFC1035],
Section 4.1.1.)
FORMERR: "Format error - The name server was unable to interpret the
query." (Quoted from [RFC1035], Section 4.1.1.)
SERVFAIL: "Server failure - The name server was unable to process
this query due to a problem with the name server." (Quoted from
[RFC1035], Section 4.1.1.)
NXDOMAIN: "Name Error - Meaningful only for responses from an
authoritative name server, this code signifies that the domain
name referenced in the query does not exist." (Quoted from
[RFC1035], Section 4.1.1.)
NOTIMP: "Not Implemented - The name server does not support the
requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)
REFUSED: "Refused - The name server refuses to perform the specified
operation for policy reasons. For example, a name server may not
wish to provide the information to the particular requester, or a
name server may not wish to perform a particular operation (e.g.,
zone transfer) for particular data." (Quoted from [RFC1035],
Section 4.1.1.)
NODATA: "A pseudo RCODE which indicates that the name is valid for 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 the nameserver cannot does not exist, or whose RCODE indicates the nameserver cannot
answer. Sections 2 and 7 of [RFC2308] describe the types of answer. Sections 2 and 7 of [RFC2308] describe the types of
negative responses in detail. negative responses in detail.
Referrals: Data from the authority section of a non-authoritative Referrals: \[\[ This text is being modified in the WG and a changed
answer. [RFC1035] Section 2.1 defines "authoritative" data. definition will appear in a future draft. \]\]
However, referrals at zone cuts (defined in Section 6) are not
Data from the authority section of a non-authoritative answer.
[RFC1035] Section 2.1 defines "authoritative" data. However,
referrals at zone cuts (defined in Section 6) are not
authoritative. Referrals may be zone cut NS resource records and authoritative. Referrals may be zone cut NS resource records and
their glue records. NS records on the parent side of a zone cut their glue records. NS records on the parent side of a zone cut
are an authoritative delegation, but are normally not treated as are an authoritative delegation, but are normally not treated as
authoritative data. In general, a referral is a way for a server authoritative data. In general, a referral is a way for a server
to send an answer saying that the server does not know the answer, to send an answer saying that the server does not know the answer,
but knows where the query should be directed in order to get an but knows where the query should be directed in order to get an
answer. Historically, many authoritative servers answered with a answer. Historically, many authoritative servers answered with a
referral to the root zone when queried for a name for which they referral to the root zone when queried for a name for which they
were not authoritative, but this practice has declined. were not authoritative, but this practice has declined.
skipping to change at page 14, line 42 skipping to change at page 15, line 22
Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
term to mean a resolver that acts in recursive mode with a cache term to mean a resolver that acts in recursive mode with a cache
(and meets other requirements). (and meets other requirements).
Recursive resolver: A resolver that acts in recursive mode. In Recursive resolver: A resolver that acts in recursive mode. In
general, a recursive resolver is expected to cache the answers it general, a recursive resolver is expected to cache the answers it
receives (which would make it a full-service resolver), but some receives (which would make it a full-service resolver), but some
recursive resolvers might not cache. recursive resolvers might not cache.
Recursive query: A query with the Recursion Desired (RD) bit set to
1 in the header.(See Section 4.1.1 of [RFC1035].) If recursive
service is available and is requested by the RD bit in the query,
the server uses its resolver to answer the query. (See
Section 4.3.2 of [RFC1035].)
Non-recursive query: A query with the Recursion Desired (RD) bit set
to 0 in the header. A server can answer non-recursive queries
using only local information: the response contains either an
error, the answer, or a referral to some other server "closer" to
the answer. (See Section 4.3.1 of [RFC1035].)
Iterative query: Synonym for non-recursive query that happens to be
a query in a series of recursive queries, but that is itself not a
recursive query. This term is used in a number of RFCs though
never explicitly defined.
Iterative resolution: A name server may be presented with a query
that can only be answered by some other server. The two general
approaches to dealing with this problem are "recursive", in which
the first server pursues the query for the client at another
server, and "iterative", in which the server refers the client to
another server and lets the client pursue the query there. (See
Section 2.3 of [RFC1034].)
In iterative resolution, the client repeatedly makes non-recursive
queries and follows referrals and/or aliases. The iterative
resolution algorithm is described in Section 5.3.3 of [RFC1034].
Priming: "The act of finding the list of root servers from a Priming: "The act of finding the list of root servers from a
configuration that lists some or all of the purported IP addresses configuration that lists some or all of the purported IP addresses
of some or all of those root servers." (Quoted from [RFC8109], of some or all of those root servers." (Quoted from [RFC8109],
Section 2.) Priming is most often done from a configuration Section 2.) Priming is most often done from a configuration
setting that contains a list of authoritative servers for the root setting that contains a list of authoritative servers for the root
zone. zone.
Root hints: "Operators who manage a DNS recursive resolver typically Root hints: "Operators who manage a DNS recursive resolver typically
need to configure a 'root hints file'. This file contains the need to configure a 'root hints file'. This file contains the
names and IP addresses of the authoritative name servers for the names and IP addresses of the authoritative name servers for the
skipping to change at page 16, line 16 skipping to change at page 17, line 25
source of zone transfer for one or more [secondary] servers" source of zone transfer for one or more [secondary] servers"
(Quoted from [RFC1996], Section 2.1) or, more specifically, "an (Quoted from [RFC1996], Section 2.1) or, more specifically, "an
authoritative server configured to be the source of AXFR or IXFR authoritative server configured to be the source of AXFR or IXFR
data for one or more [secondary] servers" (Quoted from [RFC2136]). data for one or more [secondary] servers" (Quoted from [RFC2136]).
Although early DNS RFCs such as [RFC1996] referred to this as a Although early DNS RFCs such as [RFC1996] referred to this as a
"master", the current common usage has shifted to "primary". "master", the current common usage has shifted to "primary".
Primary servers are also discussed in [RFC1034]. Primary servers are also discussed in [RFC1034].
Master server: See primary server. Master server: See primary server.
Primary master: "The primary master is named in the zone's SOA MNAME Primary master: \[\[ There is active discussion in the WG of this
field and optionally by an NS RR". (Quoted from [RFC1996], term. It will be resolved in a future version of the draft. \]\]
Section 2.1). [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The primary "The primary master is named in the zone's SOA MNAME field and
master is named in the zone's SOA MNAME field and optionally by an optionally by an NS RR". (Quoted from [RFC1996], Section 2.1).
NS RR. There is by definition only one primary master server per [RFC2136] defines "primary master" as "Master server at the root
zone." The idea of a primary master is only used by [RFC2136], of the AXFR/IXFR dependency graph. The primary master is named in
and is considered archaic in other parts of the DNS. the zone's SOA MNAME field and optionally by an NS RR. There is
by definition only one primary master server per zone." The idea
of a primary master is only used by [RFC2136], and is considered
archaic in other parts of the DNS.
Stealth server: This is "like a slave server except not listed in an Stealth server: This is "like a slave server except not listed in an
NS RR for the zone." (Quoted from [RFC1996], Section 2.1) NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
Hidden master: A stealth server that is a primary server for zone Hidden master: A stealth server that is a primary server for zone
transfers. "In this arrangement, the master name server that transfers. "In this arrangement, the master name server that
processes the updates is unavailable to general hosts on the processes the updates is unavailable to general hosts on the
Internet; it is not listed in the NS RRset." (Quoted from Internet; it is not listed in the NS RRset." (Quoted from
[RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that
the hidden master's name "appears in the SOA RRs MNAME field", the hidden master's name "appears in the SOA RRs MNAME field",
skipping to change at page 24, line 5 skipping to change at page 25, line 17
RDAP protocol and data format are meant as a replacement for RDAP protocol and data format are meant as a replacement for
WHOIS. WHOIS.
DNS operator: An entity responsible for running DNS servers. For a DNS operator: An entity responsible for running DNS servers. For a
zone's authoritative servers, the registrant may act as their own zone's authoritative servers, the registrant may act as their own
DNS operator, or their registrar may do it on their behalf, or DNS operator, or their registrar may do it on their behalf, or
they may use a third-party operator. For some zones, the registry they may use a third-party operator. For some zones, the registry
function is performed by the DNS operator plus other entities who function is performed by the DNS operator plus other entities who
decide about the allowed contents of the zone. decide about the allowed contents of the zone.
Subordinate and Superordinate: These terms are introduced in
[RFC3731] but not defined there. Instead, they are given in
examples. "For example, domain name 'example.com' has a
superordinate relationship to host name ns1.example.com'." "For
example, host ns1.example1.com is a subordinate host of domain
example1.com, but it is a not a subordinate host of domain
example2.com." (Quoted from [RFC3731], Section 1.1.) These terms
are strictly ways of referring to the relationship standing of two
domains where one is a subdomain of the other.
8. General DNSSEC 8. General DNSSEC
Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
[RFC5155]. The terms that have caused confusion in the DNS community [RFC5155]. The terms that have caused confusion in the DNS community
are highlighted here. are highlighted here.
DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
some RFCs, have not been formally defined. However, Section 2 of some RFCs, have not been formally defined. However, Section 2 of
[RFC4033] defines many types of resolvers and validators, [RFC4033] defines many types of resolvers and validators,
including "non-validating security-aware stub resolver", "non- including "non-validating security-aware stub resolver", "non-
skipping to change at page 31, line 44 skipping to change at page 32, line 44
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997, <https://www.rfc- DOI 10.17487/RFC2182, July 1997, <https://www.rfc-
editor.org/info/rfc2182>. editor.org/info/rfc2182>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>. <https://www.rfc-editor.org/info/rfc2308>.
[RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", RFC 3731, DOI 10.17487/RFC3731,
March 2004, <https://www.rfc-editor.org/info/rfc3731>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
skipping to change at page 38, line 48 skipping to change at page 39, line 48
o "Validation" in Section 8 o "Validation" in Section 8
o "View" in Section 5 o "View" in Section 5
o "Zone transfer" in Section 5 o "Zone transfer" in Section 5
Index Index
A A
Alias 8 Alias 8
Anycast 17 Anycast 19
Apex 19 Apex 20
Asterisk label 21 Asterisk label 22
Authoritative data 20 Authoritative data 21
Authoritative server 15 Authoritative server 16
Authoritative-only server 15 Authoritative-only server 16
arpa: Address and Routing Parameter Area Domain 22 arpa: Address and Routing Parameter Area Domain 23
C C
CNAME 8 CNAME 8
Canonical name 8 Canonical name 8
Child 18 Child 19
Class independent 13 Class independent 13
Closest encloser 21 Closest encloser 22
Closest provable encloser 21 Closest provable encloser 23
Combined signing key (CSK) 27 Combined signing key (CSK) 28
D D
DNS operator 23 DNS operator 25
DNSSEC Policy (DP) 28 DNSSEC Policy (DP) 29
DNSSEC Practice Statement (DPS) 28 DNSSEC Practice Statement (DPS) 29
DNSSEC-aware and DNSSEC-unaware 24 DNSSEC-aware and DNSSEC-unaware 25
Delegation 19 Delegation 20
Delegation-centric zone 21 Delegation-centric zone 22
Domain name 4 Domain name 4
E E
EDNS 11 EDNS 12
EPP 23 EPP 24
Empty non-terminals (ENT) 20 Empty non-terminals (ENT) 22
F F
Fast flux DNS 22 FORMERR 10
Forward lookup 22 Fast flux DNS 23
Forwarder 16 Forward lookup 23
Forwarding 16 Forwarder 18
Full resolver 14 Forwarding 17
Full-service resolver 14 Full resolver 15
Full-service resolver 15
Fully qualified domain name (FQDN) 7 Fully qualified domain name (FQDN) 7
G G
Global DNS 4 Global DNS 4
Glue records 19 Glue records 20
H H
Hardware security module (HSM) 28 Hardware security module (HSM) 29
Hidden master 16 Hidden master 17
Host name 7 Host name 7
I I
IDN 8 IDN 8
In-bailiwick 20 In-bailiwick 21
Infrastructure domain 22 Infrastructure domain 24
Insecure delegation 25 Insecure delegation 27
Instance 18 Instance 19
Iterative mode 14 Iterative mode 14
Iterative query 15
Iterative resolution 15
K K
Key signing key (KSK) 27 Key signing key (KSK) 28
L L
Label 4 Label 4
Locally served DNS zone 6 Locally served DNS zone 6
M M
Master file 11 Master file 12
Master server 16 Master server 17
N N
NODATA 10 NODATA 11
NSEC 25 NOERROR 10
NSEC3 25 NOTIMP 11
NSEC 26
NSEC3 26
NXDOMAIN 10
Naming system 3 Naming system 3
Negative caching 15 Negative caching 16
Negative response 11 Negative response 11
Next closer name 21 Next closer name 23
Non-recursive query 15
O O
OPT 12 OPT 12
Occluded name 22 Occluded name 23
Open resolver 17 Open resolver 18
Opt-out 25 Opt-out 26
Origin 18 Origin 20
Out-of-bailiwick 20 Out-of-bailiwick 21
Owner 12 Owner 12
P P
Parent 18 Parent 19
Passive DNS 17 Passive DNS 19
Policy-implementing resolver 17 Policy-implementing resolver 18
Presentation format 11 Presentation format 12
Primary master 16 Primary master 17
Primary server 16 Primary server 17
Priming 14 Priming 16
Private DNS 6 Private DNS 6
Public suffix 8 Public suffix 8
R R
RDAP 23 RDAP 25
RR 11 REFUSED 11
RRset 11 RR 12
RRset 12
Recursive mode 14 Recursive mode 14
Recursive resolver 14 Recursive query 15
Recursive resolver 15
Referrals 11 Referrals 11
Registrant 23 Registrant 24
Registrar 23 Registrar 24
Registry 23 Registry 24
Resolver 13 Resolver 14
Reverse DNS, reverse lookup 22 Reverse DNS, reverse lookup 23
Root hints 14 Root hints 16
Root zone 20 Root zone 22
S S
SERVFAIL 10
SOA field names 12 SOA field names 12
Secondary server 15 Secondary server 17
Secure Entry Point (SEP) 27 Secure Entry Point (SEP) 28
Service name 22 Service name 24
Signed zone 24 Signed zone 25
Signing software 28 Signing software 29
Slave server 15 Slave server 17
Source of Synthesis 21 Source of Synthesis 23
Split DNS 18 Split DNS 19
Stealth server 16 Stealth server 17
Stub resolver 13 Stub resolver 14
Subdomain 8 Subdomain 8
Subordinate 25
Superordinate 25
T T
TLD 7 TLD 7
TTL 12 TTL 13
Trust anchor 28 Trust anchor 29
U U
Unsigned zone 24 Unsigned zone 26
V V
Validating resolver 26 Validating resolver 28
Validation 25 Validation 27
View 17 View 18
W W
WHOIS 23 WHOIS 24
Wildcard 21 Wildcard 22
Wildcard domain name 21 Wildcard domain name 22
Z Z
Zone 18 Zone 19
Zone cut 19 Zone cut 20
Zone enumeration 25 Zone enumeration 27
Zone signing key (ZSK) 27 Zone signing key (ZSK) 28
Zone transfer 15 Zone transfer 16
Acknowledgements Acknowledgements
The following is the Acknowledgements for RFC 7719. Additional The following is the Acknowledgements for RFC 7719. Additional
acknowledgements may be added as this draft is worked on. acknowledgements may be added as this draft is worked on.
The authors gratefully acknowledge all of the authors of DNS-related The authors gratefully acknowledge all of the authors of DNS-related
RFCs that proceed this one. Comments from Tony Finch, Stephane RFCs that proceed this one. Comments from Tony Finch, Stephane
Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
 End of changes. 40 change blocks. 
122 lines changed or deleted 207 lines changed or added

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