draft-ietf-dnsop-terminology-bis-11.txt   draft-ietf-dnsop-terminology-bis-12.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)
Intended status: Best Current Practice K. Fujiwara Intended status: Best Current Practice K. Fujiwara
Expires: January 17, 2019 JPRS Expires: February 14, 2019 JPRS
July 16, 2018 August 13, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-11 draft-ietf-dnsop-terminology-bis-12
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 January 17, 2019. This Internet-Draft will expire on February 14, 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 19 skipping to change at page 2, line 19
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 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 . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Domain Name System (DNS) is a simple query-response protocol The Domain Name System (DNS) is a simple query-response protocol
whose messages in both directions have the same format. (Section 2 whose messages in both directions have the same format. (Section 2
gives a definition of "public DNS", which is often what people mean gives a definition of "public DNS", which is often what people mean
when they say "the DNS".) The protocol and message format are when they say "the DNS".) The protocol and message format are
defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,
but later documents defined others. Some of the terms from [RFC1034] but later documents defined others. Some of the terms from [RFC1034]
and [RFC1035] now have somewhat different meanings than they did in and [RFC1035] now have somewhat different meanings than they did in
skipping to change at page 4, line 47 skipping to change at page 4, line 47
to parts of the tree, or it can be fully qualified (in which case, to parts of the tree, or it can be fully qualified (in which case,
it begins at the common root of the graph). it begins at the common root of the graph).
Also note that different IETF and non-IETF documents have used the Also note that different IETF and non-IETF documents have used the
term "domain name" in many different ways. It is common for term "domain name" in many different ways. It is common for
earlier documents to use "domain name" to mean "names that match earlier documents to use "domain name" to mean "names that match
the syntax in [RFC1035]", but possibly with additional rules such the syntax in [RFC1035]", but possibly with additional rules such
as "and are, or will be, resolvable in the global DNS" or "but as "and are, or will be, resolvable in the global DNS" or "but
only using the presentation format". only using the presentation format".
Label: An ordered list of zero or more octets and which makes up a Label: An ordered list of zero or more octets that makes up a
portion of a domain name. Using graph theory, a label identifies portion of a domain name. Using graph theory, a label identifies
one node in a portion of the graph of all possible domain names. one node in a portion of the graph of all possible domain names.
Global DNS: Using the short set of facets listed in "Naming system", Global DNS: Using the short set of facets listed in "Naming system",
the global DNS can be defined as follows. Most of the rules here the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Administration of names -- Administration is specified by Administration of names -- Administration is specified by
delegation (see the definition of "delegation" in Section 7). delegation (see the definition of "delegation" in Section 7).
Policies for administration of the root zone in the global DNS are Policies for administration of the root zone in the global DNS are
determined by the names operational community, which convenes determined by the names operational community, which convenes
itself in the Internet Corporation for Assigned Names and Numbers itself in the Internet Corporation for Assigned Names and Numbers
(ICANN). The names operational community selects the IANA (ICANN). The names operational community selects the IANA
Functions Operator for the global DNS root zone. At the time this Functions Operator for the global DNS root zone. At the time this
document is published, that operator is Public Technical document is published, that operator is Public Technical
Identifiers (PTI). The name servers that serve the root zone are Identifiers (PTI). (See <https://pti.icann.org/> for more
provided by independent root operators. Other zones in the global information about PTI operating the IANA Functions.) The name
DNS have their own policies for administration. servers that serve the root zone are provided by independent root
operators. Other zones in the global DNS have their own policies
for administration.
Types of data that can be associated with names -- A name can have Types of data that can be associated with names -- A name can have
zero or more resource records associated with it. There are zero or more resource records associated with it. There are
numerous types of resource records with unique data structures numerous types of resource records with unique data structures
defined in many different RFCs and in the IANA registry at defined in many different RFCs and in the IANA registry at
[IANA_Resource_Registry]. [IANA_Resource_Registry].
Types of metadata for names -- Any name that is published in the Types of metadata for names -- Any name that is published in the
DNS appears as a set of resource records (see the definition of DNS appears as a set of resource records (see the definition of
"RRset" in Section 5). Some names do not themselves have data "RRset" in Section 5). Some names do not themselves have data
skipping to change at page 8, line 44 skipping to change at page 8, line 46
some new terminology. some new terminology.
Subdomain: "A domain is a subdomain of another domain if it is Subdomain: "A domain is a subdomain of another domain if it is
contained within that domain. This relationship can be tested by contained within that domain. This relationship can be tested by
seeing if the subdomain's name ends with the containing domain's seeing if the subdomain's name ends with the containing domain's
name." (Quoted from [RFC1034], Section 3.1). For example, in the name." (Quoted from [RFC1034], Section 3.1). For example, in the
host name "nnn.mmm.example.com", both "mmm.example.com" and host name "nnn.mmm.example.com", both "mmm.example.com" and
"nnn.mmm.example.com" are subdomains of "example.com". "nnn.mmm.example.com" are subdomains of "example.com".
Alias: The owner of a CNAME resource record, or a subdomain of the Alias: The owner of a CNAME resource record, or a subdomain of the
owner of a DNAME resource record. See also "canonical name". owner of a DNAME resource record (DNAME records are defined in
[RFC6672]). See also "canonical name".
Canonical name: A CNAME resource record "identifies its owner name Canonical name: A CNAME resource record "identifies its owner name
as an alias, and specifies the corresponding canonical name in the as an alias, and specifies the corresponding canonical name in the
RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2)
This usage of the word "canonical" is related to the mathematical This usage of the word "canonical" is related to the mathematical
concept of "canonical form". concept of "canonical form".
CNAME: "It is traditional to refer to the owner of a CNAME record as CNAME: "It is traditional to refer to the owner of a CNAME record as
'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of
'canonical name', and the owner of a CNAME record is an alias, not 'canonical name', and the owner of a CNAME record is an alias, not
skipping to change at page 11, line 4 skipping to change at page 11, line 8
CNAME." This definition has a certain internal logic, because of CNAME." This definition has a certain internal logic, because of
the way CNAME substitution works and the definition of CNAME. If the way CNAME substitution works and the definition of CNAME. If
a name server does not find an RRset that matches a query, but it a name server does not find an RRset that matches a query, but it
finds the same name in the same class with a CNAME record, then finds the same name in the same class with a CNAME record, then
the name server "includes the CNAME record in the response and the name server "includes the CNAME record in the response and
restarts the query at the domain name specified in the data field restarts the query at the domain name specified in the data field
of the CNAME record." ([RFC1034] Section 3.6.2). This is made of the CNAME record." ([RFC1034] Section 3.6.2). This is made
explicit in the resolution algorithm outlined in Section 4.3.2 of explicit in the resolution algorithm outlined in Section 4.3.2 of
[RFC1034], which says to "change QNAME to the canonical name in [RFC1034], which says to "change QNAME to the canonical name in
the CNAME RR, and go back to step 1" in the case of a CNAME RR. the CNAME RR, and go back to step 1" in the case of a CNAME RR.
Since a CNAME record explicitly declares that the owner name is Since a CNAME record explicitly declares that the owner name is
canonically named what is in the RDATA, then there is a way to canonically named what is in the RDATA, then there is a way to
view the new name (i.e. the name that was in the RDATA of the view the new name (i.e. the name that was in the RDATA of the
CNAME RR) as also being the QNAME. CNAME RR) as also being the QNAME.
This creates a kind of confusion, however, because the answer to a This creates a kind of confusion, however, because the response to
query that results in CNAME processing contains in the echoed a query that results in CNAME processing contains in the echoed
Question Section one QNAME (the name in the original query), and a Question Section one QNAME (the name in the original query), and a
second QNAME that is in the data field of the last CNAME. The second QNAME that is in the data field of the last CNAME. The
confusion comes from the iterative/recursive mode of resolution, confusion comes from the iterative/recursive mode of resolution,
which finally returns an answer that need not actually have the which finally returns an answer that need not actually have the
same owner name as the QNAME contained in the original query. same owner name as the QNAME contained in the original query.
To address this potential confusion, it is helpful to distinguish To address this potential confusion, it is helpful to distinguish
between three meanings: between three meanings:
* QNAME (original): The name actually sent in the Question * QNAME (original): The name actually sent in the Question
skipping to change at page 13, line 38 skipping to change at page 13, line 42
OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to
contain control information pertaining to the question-and-answer contain control information pertaining to the question-and-answer
sequence of a specific transaction. (Definition from [RFC6891], sequence of a specific transaction. (Definition from [RFC6891],
Section 6.1.1) It is used by EDNS. Section 6.1.1) It is used by EDNS.
Owner: The domain name where a RR is found ([RFC1034], Section 3.6). Owner: The domain name where a RR is found ([RFC1034], Section 3.6).
Often appears in the term "owner name". Often appears in the term "owner name".
SOA field names: DNS documents, including the definitions here, SOA field names: DNS documents, including the definitions here,
often refer to the fields in the RDATA of an SOA resource record often refer to the fields in the RDATA of an SOA resource record
by field name. Those fields are defined in Section 3.3.13 of by field name. "SOA" stands for "start of a zone of authority".
[RFC1035]. The names (in the order they appear in the SOA RDATA) Those fields are defined in Section 3.3.13 of [RFC1035]. The
are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. names (in the order they appear in the SOA RDATA) are MNAME,
Note that the meaning of MINIMUM field is updated in Section 4 of RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the
[RFC2308]; the new definition is that the MINIMUM field is only meaning of MINIMUM field is updated in Section 4 of [RFC2308]; the
"the TTL to be used for negative responses". This document tends new definition is that the MINIMUM field is only "the TTL to be
to use field names instead of terms that describe the fields. used for negative responses". This document tends to use field
names instead of terms that describe the fields.
TTL: The maximum "time to live" of a resource record. "A TTL value TTL: The maximum "time to live" of a resource record. "A TTL value
is an unsigned number, with a minimum value of 0, and a maximum is an unsigned number, with a minimum value of 0, and a maximum
value of 2147483647. That is, a maximum of 2^31 - 1. When value of 2147483647. That is, a maximum of 2^31 - 1. When
transmitted, the TTL is encoded in the less significant 31 bits of transmitted, the TTL is encoded in the less significant 31 bits of
the 32 bit TTL field, with the most significant, or sign, bit set the 32 bit TTL field, with the most significant, or sign, bit set
to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035] to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035]
erroneously stated that this is a signed integer; that was fixed erroneously stated that this is a signed integer; that was fixed
by [RFC2181].) by [RFC2181].)
skipping to change at page 14, line 37 skipping to change at page 14, line 41
There is also the concept of a "default TTL" for a zone, which can There is also the concept of a "default TTL" for a zone, which can
be a configuration parameter in the server software. This is be a configuration parameter in the server software. This is
often expressed by a default for the entire server, and a default often expressed by a default for the entire server, and a default
for a zone using the $TTL directive in a zone file. The $TTL for a zone using the $TTL directive in a zone file. The $TTL
directive was added to the master file format by [RFC2308]. directive was added to the master file format by [RFC2308].
Class independent: A resource record type whose syntax and semantics Class independent: A resource record type whose syntax and semantics
are the same for every DNS class. A resource record type that is are the same for every DNS class. A resource record type that is
not class independent has different meanings depending on the DNS not class independent has different meanings depending on the DNS
class of the record, or the meaning is undefined for some class. class of the record, or the meaning is undefined for some class.
Most resorece record types are defined for class 1 (IN, the Most resource record types are defined for class 1 (IN, the
Internet), but many are undefined for other classes. Internet), but many are undefined for other classes.
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
skipping to change at page 15, line 21 skipping to change at page 15, line 29
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 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) A resolver performs queries for a name, type, and Section 2.4) A resolver performs queries for a name, type, and
class, and receives answers. 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.
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 response". Similarly, an imputed
of "resolution" might be "the answer received from resolving". definition of "resolution" might be "the response received from
resolving".
Stub resolver: A resolver that cannot perform all resolution itself. Stub resolver: A resolver that cannot perform all resolution itself.
Stub resolvers generally depend on a recursive resolver to Stub resolvers generally depend on a recursive resolver to
undertake the actual resolution function. Stub resolvers are undertake the actual resolution function. Stub resolvers are
discussed but never fully defined in Section 5.3.1 of [RFC1034]. discussed but never fully defined in Section 5.3.1 of [RFC1034].
They are fully defined in Section 6.1.3.1 of [RFC1123]. They are fully defined in Section 6.1.3.1 of [RFC1123].
Iterative mode: A resolution mode of a server that receives DNS Iterative mode: A resolution mode of a server that receives DNS
queries and responds with a referral to another server. queries and responds with a referral to another server.
Section 2.3 of [RFC1034] describes this as "The server refers the Section 2.3 of [RFC1034] describes this as "The server refers the
skipping to change at page 17, line 40 skipping to change at page 17, line 49
the software." (Quoted from [IANA_RootFiles]) This file is often the software." (Quoted from [IANA_RootFiles]) This file is often
used in priming. used in priming.
Negative caching: "The storage of knowledge that something does not Negative caching: "The storage of knowledge that something does not
exist, cannot give an answer, or does not give an answer." exist, cannot give an answer, or does not give an answer."
(Quoted from [RFC2308], Section 1) (Quoted from [RFC2308], Section 1)
Authoritative server: "A server that knows the content of a DNS zone Authoritative server: "A server that knows the content of a DNS zone
from local knowledge, and thus can answer queries about that zone from local knowledge, and thus can answer queries about that zone
without needing to query other servers." (Quoted from [RFC2182], without needing to query other servers." (Quoted from [RFC2182],
Section 2.) It is a system that responds to DNS queries with Section 2.) An authoritative server is named in the NS ("name
information about zones for which it has been configured to answer server") record in a zone. It is a system that responds to DNS
with the AA flag in the response header set to 1. It is a server queries with information about zones for which it has been
that has authority over one or more DNS zones. Note that it is configured to answer with the AA flag in the response header set
possible for an authoritative server to respond to a query without to 1. It is a server that has authority over one or more DNS
the parent zone delegating authority to that server. zones. Note that it is possible for an authoritative server to
Authoritative servers also provide "referrals", usually to child respond to a query without the parent zone delegating authority to
zones delegated from them; these referrals have the AA bit set to that server. Authoritative servers also provide "referrals",
0 and come with referral data in the Authority and (if needed) the usually to child zones delegated from them; these referrals have
Additional sections. the AA bit set to 0 and come with referral data in the Authority
and (if needed) the 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) In this case, "ignores requests for recursion" means Section 2.4) In this case, "ignores requests for recursion" means
"responds to requests for recursion with responses indicating that "responds to requests for recursion with responses indicating that
recursion was not performed". recursion was not performed".
Zone transfer: The act of a client requesting a copy of a zone and Zone transfer: The act of a client requesting a copy of a zone and
an authoritative server sending the needed information. (See an authoritative server sending the needed information. (See
Section 7 for a description of zones.) There are two common Section 7 for a description of zones.) There are two common
standard ways to do zone transfers: the AXFR ("Authoritative standard ways to do zone transfers: the AXFR ("Authoritative
Transfer") mechanism to copy the full zone (described in Transfer") mechanism to copy the full zone (described in
[RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
only parts of the zone that have changed (described in [RFC1995]). only parts of the zone that have changed (described in [RFC1995]).
Many systems use non-standard methods for zone transfer outside Many systems use non-standard methods for zone transfer outside
the DNS protocol. the DNS protocol.
Slave server: See "Secondary server".
Secondary server: "An authoritative server which uses zone transfer Secondary server: "An authoritative server which uses zone transfer
to retrieve the zone" (Quoted from [RFC1996], Section 2.1). to retrieve the zone" (Quoted from [RFC1996], Section 2.1).
Secondary servers are also discussed in [RFC1034]. [RFC2182] Secondary servers are also discussed in [RFC1034]. [RFC2182]
describes secondary servers in more detail. Although early DNS describes secondary servers in more detail. Although early DNS
RFCs such as [RFC1996] referred to this as a "slave", the current RFCs such as [RFC1996] referred to this as a "slave", the current
common usage has shifted to calling it a "secondary". common usage has shifted to calling it a "secondary".
Slave server: See secondary server. Master server: See "Primary server".
Primary server: "Any authoritative server configured to be the Primary server: "Any authoritative server configured to be the
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]).
Primary servers are also discussed in [RFC1034]. Although early Primary servers are also discussed in [RFC1034]. Although early
DNS RFCs such as [RFC1996] referred to this as a "master", the DNS RFCs such as [RFC1996] referred to this as a "master", the
current common usage has shifted to "primary". current common usage has shifted to "primary".
Master server: See primary server.
Primary master: "The primary master is named in the zone's SOA MNAME Primary master: "The primary master is named in the zone's SOA MNAME
field and optionally by an NS RR". (Quoted from [RFC1996], field and optionally by an NS RR". (Quoted from [RFC1996],
Section 2.1). [RFC2136] defines "primary master" as "Master Section 2.1). [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The primary server at the root of the AXFR/IXFR dependency graph. The primary
master is named in the zone's SOA MNAME field and optionally by an master is named in the zone's SOA MNAME field and optionally by an
NS RR. There is by definition only one primary master server per NS RR. There is by definition only one primary master server per
zone." The idea of a primary master is only used by [RFC2136], zone." The idea of a primary master is only used by [RFC2136],
and is considered archaic in other parts of the DNS. and is considered archaic in other parts of the DNS.
The idea of a primary master is only used in [RFC1996] and The idea of a primary master is only used in [RFC1996] and
skipping to change at page 20, line 29 skipping to change at page 20, line 38
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.
[RFC2775], Section 3.8 gives a related definition that is too [RFC2775], Section 3.8 gives a related definition that is too
specific to be generally useful. specific to be generally useful.
View: A configuration for a DNS server that allows it to provide View: A configuration for a DNS server that allows it to provide
different answers depending on attributes of the query, such as different responses depending on attributes of the query, such as
for "split DNS". Typically, views differ by the source IP address for "split DNS". Typically, views differ by the source IP address
of a query, but can also be based on the destination IP address, of a query, but can also be based on the destination IP address,
the type of query (such as AXFR), whether it is recursive, and so the type of query (such as AXFR), whether it is recursive, and so
on. Views are often used to provide more names or different on. Views are often used to provide more names or different
addresses to queries from "inside" a protected network than to addresses to queries from "inside" a protected network than to
those "outside" that network. Views are not a standardized part those "outside" that network. Views are not a standardized part
of the DNS, but they are widely implemented in server software. of the DNS, but they are widely implemented in server software.
Passive DNS: A mechanism to collect DNS data by storing DNS Passive DNS: A mechanism to collect DNS data by storing DNS
responses from name servers. Some of these systems also collect responses from name servers. Some of these systems also collect
skipping to change at page 40, line 21 skipping to change at page 40, line 21
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>. <https://www.rfc-editor.org/info/rfc6365>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>. February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480, Registration Data Access Protocol (RDAP)", RFC 7480,
skipping to change at page 43, line 47 skipping to change at page 44, line 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 21
Apex 22 Apex 22
Asterisk label 26 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
skipping to change at page 45, line 7 skipping to change at page 45, line 17
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 30 Insecure delegation 30
Instance 21 Instance 21
Iterative mode 15 Iterative mode 15
Iterative resolution 16 Iterative resolution 17
K K
Key signing key (KSK) 31 Key signing key (KSK) 31
L L
Label 4 Label 4
Lame delegation 22 Lame delegation 23
Locally served DNS zone 7 Locally served DNS zone 7
M M
Master file 13 Master file 13
Master server 18 Master server 18
Multicast DNS 6 Multicast DNS 6
N N
NODATA 9 NODATA 9
NOERROR 9 NOERROR 9
NOTIMP 9 NOTIMP 9
NS 17
NSEC 29 NSEC 29
NSEC3 29 NSEC3 29
NXDOMAIN 9 NXDOMAIN 9
Naming system 3 Naming system 3
Negative caching 17 Negative caching 17
Negative response 10 Negative response 10
Next closer name 26 Next closer name 26
Non-recursive query 16 Non-recursive query 16
O O
OPT 13 OPT 13
Occluded name 24 Occluded name 25
Open resolver 20 Open resolver 20
Opt-out 29 Opt-out 30
Origin 21 Origin 21
Out-of-bailiwick 23 Out-of-bailiwick 23
Owner 13 Owner 13
P P
Parent 21 Parent 21
Passive DNS 20 Passive DNS 20
Policy-implementing resolver 19 Policy-implementing resolver 20
Presentation format 13 Presentation format 13
Primary master 18 Primary master 19
Primary server 18 Primary server 18
Priming 17 Priming 17
Privacy-enabling DNS server 21 Privacy-enabling DNS server 21
Private DNS 6 Private DNS 6
Public suffix 27 Public suffix 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 15 Recursive mode 16
Recursive query 16 Recursive query 16
Recursive resolver 16 Recursive resolver 16
Referrals 11 Referrals 11
Registrant 27 Registrant 27
Registrar 27 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 13
SOA field names 13 SOA field names 13
Secondary server 18 Secondary server 18
Secure Entry Point (SEP) 31 Secure Entry Point (SEP) 32
Service name 25 Service name 25
Signed zone 28 Signed zone 28
Signing software 32 Signing software 33
Slave server 18 Slave server 18
Source of Synthesis 26 Source of Synthesis 26
Split DNS 20 Split DNS 20
Split-horizon DNS 20 Split-horizon DNS 20
Stealth server 19 Stealth server 19
Stub resolver 15 Stub resolver 15
Subdomain 8 Subdomain 8
Subordinate 28 Subordinate 28
Superordinate 28 Superordinate 28
skipping to change at page 48, line 4 skipping to change at page 48, line 11
Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin
Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL
APPEAR HERE AS FOLKS CONTRIBUTE]]. APPEAR HERE AS FOLKS CONTRIBUTE]].
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
Andrew Sullivan Andrew Sullivan
Oracle
100 Milverton Drive
Mississauga, ON L5R 4H1
Canada
Email: andrew.s.sullivan@oracle.com Email: ajs@anvilwalrusden.com
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065 Chiyoda-ku, Tokyo 101-0065
Japan Japan
Phone: +81 3 5215 8451 Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp Email: fujiwara@jprs.co.jp
 End of changes. 37 change blocks. 
56 lines changed or deleted 64 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/