draft-ietf-dnsop-terminology-bis-10.txt   draft-ietf-dnsop-terminology-bis-11.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: October 29, 2018 JPRS Expires: January 17, 2019 JPRS
April 27, 2018 July 16, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-10 draft-ietf-dnsop-terminology-bis-11
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 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 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 October 29, 2018. This Internet-Draft will expire on January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . 12 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12
6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14
7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 32 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Definitions Updated by this Document . . . . . . . . 41 Appendix A. Definitions Updated by this Document . . . . . . . . 41
Appendix B. Definitions First Defined in this Document . . . . . 41 Appendix B. Definitions First Defined in this Document . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
skipping to change at page 7, line 4 skipping to change at page 7, line 4
intended never to be looked up using the DNS protocol, are not intended never to be looked up using the DNS protocol, are not
part of the global DNS or a private DNS even though they are part of the global DNS or a private DNS even though they are
domain names. domain names.
Multicast DNS: "Multicast DNS (mDNS) provides the ability to perform Multicast DNS: "Multicast DNS (mDNS) provides the ability to perform
DNS-like operations on the local link in the absence of any DNS-like operations on the local link in the absence of any
conventional Unicast DNS server. In addition, Multicast DNS 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
above quote says "a portion of the DNS namespace", it would be above quote says "a portion of the DNS namespace", it would be
clearer to say "a portion of the domain name space" The names in clearer to say "a portion of the domain name space" The names in
mDNS are not intended to be looked up in the DNS. mDNS are not intended to be looked up in the DNS.
Locally served DNS zone: A locally served DNS zone is a special case Locally served DNS zone: A locally served DNS zone is a special case
of private DNS. Names are resolved using the DNS protocol in a of private DNS. Names are resolved using the DNS protocol in a
local context. [RFC6303] defines subdomains of IN-ADDR.ARPA 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
skipping to change at page 7, line 48 skipping to change at page 7, line 48
context. context.
Host name: This term and its equivalent, "hostname", have been Host name: This term and its equivalent, "hostname", have been
widely used but are not defined in [RFC1034], [RFC1035], widely used but are not defined in [RFC1034], [RFC1035],
[RFC1123], or [RFC2181]. The DNS was originally deployed into the [RFC1123], or [RFC2181]. The DNS was originally deployed into the
Host Tables environment as outlined in [RFC0952], and it is likely Host Tables environment as outlined in [RFC0952], and it is likely
that the term followed informally from the definition there. Over that the term followed informally from the definition there. Over
time, the definition seems to have shifted. "Host name" is often time, the definition seems to have shifted. "Host name" is often
meant to be a domain name that follows the rules in Section 3.5 of meant to be a domain name that follows the rules in Section 3.5 of
[RFC1034], the "preferred name syntax" (that is, every character [RFC1034], the "preferred name syntax" (that is, every character
in each label are a letter, a digit, or a hyphen). Note that any in each label is a letter, a digit, or a hyphen). Note that any
label in a domain name can contain any octet value; hostnames are label in a domain name can contain any octet value; hostnames are
generally considered to be domain names where every label follows generally considered to be domain names where every label follows
the rules in the "preferred name syntax", with the amendment that the rules in the "preferred name syntax", with the amendment that
labels can start with ASCII digits (this amendment comes from labels can start with ASCII digits (this amendment comes from
Section 2.1 of [RFC1123]). Section 2.1 of [RFC1123]).
People also sometimes use the term hostname to refer to just the People also sometimes use the term hostname to refer to just the
first label of an FQDN, such as "printer" in first label of an FQDN, such as "printer" in
"printer.admin.example.com". (Sometimes this is formalized in "printer.admin.example.com". (Sometimes this is formalized in
configuration in operating systems.) In addition, people configuration in operating systems.) In addition, people
skipping to change at page 9, line 29 skipping to change at page 9, line 29
NOERROR: "No error condition" (Quoted from [RFC1035], NOERROR: "No error condition" (Quoted from [RFC1035],
Section 4.1.1.) Section 4.1.1.)
FORMERR: "Format error - The name server was unable to interpret the FORMERR: "Format error - The name server was unable to interpret the
query." (Quoted from [RFC1035], Section 4.1.1.) query." (Quoted from [RFC1035], Section 4.1.1.)
SERVFAIL: "Server failure - The name server was unable to process SERVFAIL: "Server failure - The name server was unable to process
this query due to a problem with the name server." (Quoted from this query due to a problem with the name server." (Quoted from
[RFC1035], Section 4.1.1.) [RFC1035], Section 4.1.1.)
NXDOMAIN: "Name Error - Meaningful only for responses from an NXDOMAIN: "Name Error - This code signifies that the domain name
authoritative name server, this code signifies that the domain referenced in the query does not exist." (Quoted from [RFC1035],
name referenced in the query does not exist." (Quoted from Section 4.1.1.) [RFC2308] established NXDOMAIN as a synonym for
[RFC1035], Section 4.1.1.) [RFC2308] established NXDOMAIN as a Name Error.
synonym for Name Error.
NOTIMP: "Not Implemented - The name server does not support the NOTIMP: "Not Implemented - The name server does not support the
requested kind of query." (Quoted from [RFC1035], Section 4.1.1.) requested kind of query." (Quoted from [RFC1035], Section 4.1.1.)
REFUSED: "Refused - The name server refuses to perform the specified REFUSED: "Refused - The name server refuses to perform the specified
operation for policy reasons. For example, a name server may not operation for policy reasons. For example, a name server may not
wish to provide the information to the particular requester, or a wish to provide the information to the particular requester, or a
name server may not wish to perform a particular operation (e.g., name server may not wish to perform a particular operation (e.g.,
zone transfer) for particular data." (Quoted from [RFC1035], zone transfer) for particular data." (Quoted from [RFC1035],
Section 4.1.1.) Section 4.1.1.)
skipping to change at page 15, line 4 skipping to change at page 14, line 49
Address records: Records whose type is A or AAAA. [RFC2181] Address records: Records whose type is 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 the RFCs, DNS servers are clients, DNS servers, or both. In the 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 the RFCs generally There is no formal definition of DNS server, but the 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
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 (and 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 public 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 public DNS is served.
Resolver: A program "that extract[s] information from name servers Resolver: A program "that extract[s] information from name servers
in response to client requests." (Quoted from [RFC1034], in response to client requests." (Quoted from [RFC1034],
Section 2.4) "The resolver is located on the same machine as the Section 2.4) A resolver performs queries for a name, type, and
program that requests the resolver's services, but it may need to
consult name servers on other hosts." (Quoted from [RFC1034],
Section 5.1) A resolver performs queries for a name, type, and
class, and receives answers. The logical function is called class, and receives answers. The logical function is called
"resolution". In practice, the term is usually referring to some "resolution". In practice, the term is usually referring to some
specific type of resolver (some of which are defined below), and specific type of resolver (some of which are defined below), and
understanding the use of the term depends on understanding the understanding the use of the term depends on understanding the
context. context.
A related term is "resolve", which is not formally defined in A related term is "resolve", which is not formally defined in
[RFC1034] or [RFC1035]. An imputed definition might be "asking a [RFC1034] or [RFC1035]. An imputed definition might be "asking a
question that consists of a domain name, class, and type, and question that consists of a domain name, class, and type, and
receiving some sort of answer". Similarly, an imputed definition receiving some sort of answer". Similarly, an imputed definition
skipping to change at page 16, line 10 skipping to change at page 16, line 4
client to another server and lets the client pursue the query". A client to another server and lets the client pursue the query". A
resolver that works in iterative mode is sometimes called an resolver that works in iterative mode is sometimes called an
"iterative resolver". See also "iterative resolution" later in "iterative resolver". See also "iterative resolution" later in
this section. this section.
Recursive mode: A resolution mode of a server that receives DNS Recursive mode: A resolution mode of a server that receives DNS
queries and either responds to those queries from a local cache or queries and either responds to those queries from a local cache or
sends queries to other servers in order to get the final answers sends queries to other servers in order to get the final answers
to the original queries. Section 2.3 of [RFC1034] describes this to the original queries. Section 2.3 of [RFC1034] describes this
as "The first server pursues the query for the client at another as "The first server pursues the query for the client at another
server". Section 4.3.1 of of [RFC1034] says "in \[recursive\] server". Section 4.3.1 of of [RFC1034] says "in [recursive] mode
mode the name server acts in the role of a resolver and returns the name server acts in the role of a resolver and returns either
either an error or the answer, but never referrals." That same an error or the answer, but never referrals." That same section
section also says "The recursive mode occurs when a query with RD also says "The recursive mode occurs when a query with RD set
set arrives at a server which is willing to provide recursive arrives at a server which is willing to provide recursive service;
service; the client can verify that recursive mode was used by the client can verify that recursive mode was used by checking
checking that both RA and RD are set in the reply." that both RA and RD are set in the reply."
A server operating in recursive mode may be thought of as having a A server operating in recursive mode may be thought of as having a
name server side (which is what answers the query) and a resolver name server side (which is what answers the query) and a resolver
side (which performs the resolution function). Systems operating side (which performs the resolution function). Systems operating
in this mode are commonly called "recursive servers". Sometimes in this mode are commonly called "recursive servers". Sometimes
they are called "recursive resolvers". While strictly the they are called "recursive resolvers". While strictly the
difference between these is that one of them sends queries to difference between these is that one of them sends queries to
another recursive server and the other does not, in practice it is another recursive server and the other does not, in practice it is
not possible to know in advance whether the server that one is not possible to know in advance whether the server that one is
querying will also perform recursion; both terms can be observed querying will also perform recursion; both terms can be observed
skipping to change at page 18, line 12 skipping to change at page 18, line 10
Authoritative servers also provide "referrals", usually to child Authoritative servers also provide "referrals", usually to child
zones delegated from them; these referrals have the AA bit set to zones delegated from them; these referrals have the AA bit set to
0 and come with referral data in the Authority and (if needed) the 0 and come with referral data in the Authority and (if needed) the
Additional sections. Additional sections.
Authoritative-only server: A name server that only serves Authoritative-only server: A name server that only serves
authoritative data and ignores requests for recursion. It will authoritative data and ignores requests for recursion. It will
"not normally generate any queries of its own. Instead, it "not normally generate any queries of its own. Instead, it
answers non-recursive queries from iterative resolvers looking for answers non-recursive queries from iterative resolvers looking for
information in zones it serves." (Quoted from [RFC4697], information in zones it serves." (Quoted from [RFC4697],
Section 2.4) Section 2.4) In this case, "ignores requests for recursion" means
"responds to requests for recursion with responses indicating that
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 transfer outside
the DNS protocol. the DNS protocol.
skipping to change at page 20, line 8 skipping to change at page 20, line 8
criteria, such as to prevent access to malware sites or criteria, such as to prevent access to malware sites or
objectionable content. In general, a stub resolver has no idea objectionable content. In general, a stub resolver has no idea
whether upstream resolvers implement such policy or, if they do, whether upstream resolvers implement such policy or, if they do,
the exact policy about what changes will be made. In some cases, the exact policy about what changes will be made. In some cases,
the user of the stub resolver has selected the policy-implementing the user of the stub resolver has selected the policy-implementing
resolver with the explicit intention of using it to implement the resolver with the explicit intention of using it to implement the
policies. In other cases, policies are imposed without the user policies. In other cases, policies are imposed without the user
of the stub resolver being informed. of the stub resolver being informed.
Open resolver: A full-service resolver that accepts and processes Open resolver: A full-service resolver that accepts and processes
queries from any (or nearly any) stub resolver. This is sometimes queries from any (or nearly any) client. This is sometimes also
also called a "public resolver", although the term "public called a "public resolver", although the term "public resolver" is
resolver" is used more with open resolvers that are meant to be used more with open resolvers that are meant to be open, as
open, as compared to the vast majority of open resolvers that are compared to the vast majority of open resolvers that are probably
probably misconfigured to be open. Open resolvers are discussed misconfigured to be open. Open resolvers are discussed in
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. The effect of this is that a domain name
that is notionally globally unique nevertheless has different that is notionally globally unique nevertheless 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, described below.
skipping to change at page 22, line 46 skipping to change at page 22, line 46
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
related to authoritative data but has a more precise definition.
Lame delegation: "A lame delegations exists when a nameserver is Lame delegation: "A lame delegations exists when a nameserver is
delegated responsibility for providing nameservice for a zone (via delegated responsibility for providing nameservice for a zone (via
NS records) but is not performing nameservice for that zone NS records) but is not performing nameservice for that zone
(usually because it is not set up as a primary or secondary for (usually because it is not set up as a primary or secondary for
the zone)." (Definition from [RFC1912], Section 2.8) the zone)." (Quoted from [RFC1912], Section 2.8)
Another definition is that a lame delegation "happens when a name
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
wrong servers, who don't know nothing (at least not as expected)
about the queried domain. Furthermore, sometimes these hosts (if
they exist!) don't even run name servers." (Quoted from
[RFC1713], Section 2.3)
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 resource records authoritative data [of the zone], and are address resource records
for the [name servers in subzones]. These RRs are only necessary for 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 if the name server's name is 'below' the cut, and are only used as
part of a referral response." Without glue "we could be faced part of a referral response." Without glue "we could be faced
with the situation where the NS RRs tell us that in order to learn with the situation where the NS RRs tell us that in order to learn
a name server's address, we should contact the server using the a name server's address, we should contact the server using the
address we wish to learn." (Definition from [RFC1034], address we wish to learn." (Definition from [RFC1034],
Section 4.2.1) Section 4.2.1)
skipping to change at page 29, line 28 skipping to change at page 29, line 39
NSEC record provides authenticated denial of existence. NSEC 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 RFC 4034)
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
against zone enumeration and support Opt-Out. NSEC resource against zone enumeration and support Opt-Out. NSEC3 resource
records require associated NSEC3PARAM resource records. NSEC3 and records 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
RFCs that only talk about NSEC records should probably be RFCs that only talk about NSEC records should probably be
considered to be talking about both NSEC and NSEC3. considered to be talking about both NSEC and NSEC3.
Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
skipping to change at page 38, line 9 skipping to change at page 38, line 9
[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
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,
DOI 10.17487/RFC1713, November 1994,
<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>.
[RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2133, "Basic Socket Interface Extensions for IPv6", RFC 2133,
DOI 10.17487/RFC2133, April 1997, DOI 10.17487/RFC2133, April 1997,
<https://www.rfc-editor.org/info/rfc2133>. <https://www.rfc-editor.org/info/rfc2133>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
skipping to change at page 41, line 45 skipping to change at page 41, line 50
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:
o "Alias" in Section 2 o "Alias" in Section 2
o "Apex" in Section 7 o "Apex" in Section 7
o "arpa" in Section 7 o "arpa" in Section 7
o "Class independent" in Section 5 o "Bailiwick" in Section 7
o "Class independent" in Section 5
o "Delegation-centric zone" in Section 7 o "Delegation-centric zone" in Section 7
o "Delegation" in Section 7 o "Delegation" in Section 7
o "DNS operator" in Section 9 o "DNS operator" in Section 9
o "DNSSEC-aware" in Section 10 o "DNSSEC-aware" in Section 10
o "DNSSEC-unaware" in Section 10 o "DNSSEC-unaware" in Section 10
o "Forwarding" in Section 6 o "Forwarding" in Section 6
o "Full resolver" in Section 6 o "Full resolver" in Section 6
o "Fully qualified domain name" in Section 2 o "Fully qualified domain name" in Section 2
skipping to change at page 42, line 24 skipping to change at page 42, line 30
o "Global DNS" in Section 2 o "Global DNS" in Section 2
o "Hardware Security Module (HSM)" in Section 10 o "Hardware Security Module (HSM)" in Section 10
o "Host name" in Section 2 o "Host name" in Section 2
o "IDN" in Section 2 o "IDN" in Section 2
o "In-bailiwick" in Section 7 o "In-bailiwick" in Section 7
o "Iterative resolution" in Section 6
o "Label" in Section 2 o "Label" in Section 2
o "Locally served DNS zone" in Section 2 o "Locally served DNS zone" in Section 2
o "Naming system" in Section 2 o "Naming system" in Section 2
o "Negative response" in Section 3 o "Negative response" in Section 3
o "Non-recursive query" in Section 6
o "Open resolver" in Section 6 o "Open resolver" in Section 6
o "Out-of-bailiwick" in Section 7 o "Out-of-bailiwick" in Section 7
o "Passive DNS" in Section 6 o "Passive DNS" in Section 6
o "Policy-implementing resolver" in Section 6 o "Policy-implementing resolver" in Section 6
o "Presentation format" in Section 5 o "Presentation format" in Section 5
o "Priming" in Section 6 o "Priming" in Section 6
o "Private DNS" in Section 2 o "Private DNS" in Section 2
o "Recursive resolver" in Section 6 o "Recursive resolver" in Section 6
o "Referrals" in Section 4 o "Referrals" in Section 4
o "Registrant" in Section 9 o "Registrant" in Section 9
o "Registrar" in Section 9 o "Registrar" in Section 9
o "Registry" in Section 9 o "Registry" in Section 9
o "Root zone" in Section 7 o "Root zone" in Section 7
o "Secure Entry Point (SEP)" in Section 10 o "Secure Entry Point (SEP)" in Section 10
o "Signing software" in Section 10 o "Signing software" in Section 10
skipping to change at page 43, line 14 skipping to change at page 43, line 24
o "Registrar" in Section 9 o "Registrar" in Section 9
o "Registry" in Section 9 o "Registry" in Section 9
o "Root zone" in Section 7 o "Root zone" in Section 7
o "Secure Entry Point (SEP)" in Section 10 o "Secure Entry Point (SEP)" in Section 10
o "Signing software" in Section 10 o "Signing software" in Section 10
o "Split DNS" in Section 6
o "Stub resolver" in Section 6 o "Stub resolver" in Section 6
o "Subordinate" in Section 8
o "Superordinate" in Section 8
o "TLD" in Section 2 o "TLD" in Section 2
o "Validating resolver" in Section 10 o "Validating resolver" in Section 10
o "Validation" in Section 10 o "Validation" in Section 10
o "View" in Section 6 o "View" in Section 6
o "Zone transfer" in Section 6 o "Zone transfer" in Section 6
Index Index
A A
Address records 14 Address records 14
Alias 8 Alias 8
Anycast 20 Anycast 20
Apex 22 Apex 22
Asterisk label 25 Asterisk label 26
Authoritative data 22 Authoritative data 22
Authoritative server 17 Authoritative server 17
Authoritative-only server 18 Authoritative-only server 18
arpa: Address and Routing Parameter Area Domain 25 arpa: Address and Routing Parameter Area Domain 25
C C
CNAME 9 CNAME 9
Canonical name 8 Canonical name 8
Child 21 Child 21
Class independent 14 Class independent 14
skipping to change at page 44, line 16 skipping to change at page 44, line 32
Delegation-centric zone 24 Delegation-centric zone 24
Domain name 4 Domain name 4
E E
EDNS 13 EDNS 13
EPP 27 EPP 27
Empty non-terminals (ENT) 24 Empty non-terminals (ENT) 24
F F
FORMERR 9 FORMERR 9
Fast flux DNS 24 Fast flux DNS 25
Forward lookup 25 Forward lookup 25
Forwarder 19 Forwarder 19
Forwarding 19 Forwarding 19
Full resolver 17 Full resolver 17
Full-service resolver 17 Full-service resolver 17
Fully qualified domain name (FQDN) 7 Fully qualified domain name (FQDN) 7
G G
Global DNS 4 Global DNS 4
Glue records 23 Glue records 23
H H
Hardware security module (HSM) 32 Hardware security module (HSM) 32
Hidden master 19 Hidden master 19
Host name 7 Host name 7
I I
IDN 8 IDN 8
In-bailiwick 23 In-bailiwick 23
Insecure delegation 29 Insecure delegation 30
Instance 21 Instance 21
Iterative mode 15 Iterative mode 15
Iterative resolution 16 Iterative resolution 16
K K
Key signing key (KSK) 31 Key signing key (KSK) 31
L L
Label 4 Label 4
Lame delegation 22 Lame delegation 22
skipping to change at page 45, line 48 skipping to change at page 46, line 16
Public suffix 27 Public suffix 27
Q Q
QNAME 10 QNAME 10
R R
RDAP 27 RDAP 27
REFUSED 9 REFUSED 9
RR 12 RR 12
RRset 12 RRset 12
Recursive mode 16 Recursive mode 15
Recursive query 16 Recursive query 16
Recursive resolver 16 Recursive resolver 16
Referrals 11 Referrals 11
Registrant 26 Registrant 27
Registrar 26 Registrar 27
Registry 26 Registry 26
Resolver 15 Resolver 15
Reverse DNS, reverse lookup 25 Reverse DNS, reverse lookup 25
Root hints 17 Root hints 17
Root zone 24 Root zone 24
S S
SERVFAIL 9 SERVFAIL 9
SOA field names 13 SOA field names 13
Secondary server 18 Secondary server 18
skipping to change at page 46, line 36 skipping to change at page 47, line 4
Subdomain 8 Subdomain 8
Subordinate 28 Subordinate 28
Superordinate 28 Superordinate 28
T T
TLD 8 TLD 8
TTL 13 TTL 13
Trust anchor 32 Trust anchor 32
U U
Unsigned zone 28 Unsigned zone 29
V V
Validating resolver 31 Validating resolver 31
Validation 30 Validation 30
View 20 View 20
W W
WHOIS 27 WHOIS 27
Wildcard 25 Wildcard 25
Wildcard domain name 25 Wildcard domain name 26
Z Z
Zone 21 Zone 21
Zone cut 22 Zone cut 22
Zone enumeration 30 Zone enumeration 30
Zone signing key (ZSK) 31 Zone signing key (ZSK) 31
Zone transfer 18 Zone transfer 18
Acknowledgements Acknowledgements
 End of changes. 33 change blocks. 
44 lines changed or deleted 68 lines changed or added

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