draft-ietf-dnsop-terminology-bis-09.txt   draft-ietf-dnsop-terminology-bis-10.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: September 6, 2018 JPRS Expires: October 29, 2018 JPRS
March 5, 2018 April 27, 2018
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-09 draft-ietf-dnsop-terminology-bis-10
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The domain name system (DNS) is defined in literally dozens of
terminology used by implementers and developers of DNS protocols, and different RFCs. The terminology used by implementers and developers
by operators of DNS systems, has sometimes changed in the decades of DNS protocols, and by operators of DNS systems, has sometimes
since the DNS was first defined. This document gives current changed in the decades since the DNS was first defined. This
definitions for many of the terms used in the DNS in a single document gives current definitions for many of the terms used in the
document. DNS in a single document.
This document will be the successor to RFC 7719, and thus will This document will be the successor to RFC 7719, and thus will
obsolete RFC 7719. It will also update RFC 2308. obsolete RFC 7719. It will also update RFC 2308.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 6, 2018. This Internet-Draft will expire on October 29, 2018.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 Response Codes . . . . . . . . . . . . . . . . . . . . . 8 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Registration Model . . . . . . . . . . . . . . . . . . . . . 25 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26
10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 27 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28
11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 31 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. Normative References . . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 34
14.2. Informative References . . . . . . . . . . . . . . . . . 36 14.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Definitions Updated by this Document . . . . . . . . 40 Appendix A. Definitions Updated by this Document . . . . . . . . 41
Appendix B. Definitions First Defined in this Document . . . . . 40 Appendix B. Definitions First Defined in this Document . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 3, line 27 skipping to change at page 3, line 27
are defined in early DNS RFCs now have definitions that are generally are defined in early DNS RFCs now have definitions that are generally
agreed to, but that are different from the original definitions. agreed to, but that are different from the original definitions.
Therefore, this document is a substantial revision to [RFC7719]. Therefore, this document is a substantial revision to [RFC7719].
The terms are organized loosely by topic. Some definitions are for The terms are organized loosely by topic. Some definitions are for
new terms for things that are commonly talked about in the DNS new terms for things that are commonly talked about in the DNS
community but that never had terms defined for them. community but that never had terms defined for them.
Other organizations sometimes define DNS-related terms their own way. Other organizations sometimes define DNS-related terms their own way.
For example, the W3C defines "domain" at For example, the W3C defines "domain" at
https://specs.webplatform.org/url/webspecs/develop/. The Root Server <https://url.spec.whatwg.org/>. The Root Server System Advisory
System Advisory Committee (RSSAC) has a good lexicon [RSSAC026]. Committee (RSSAC) has a good lexicon [RSSAC026].
Note that there is no single consistent definition of "the DNS". It Note that there is no single consistent definition of "the DNS". It
can be considered to be some combination of the following: a commonly can be considered to be some combination of the following: a commonly
used naming scheme for objects on the Internet; a distributed used naming scheme for objects on the Internet; a distributed
database representing the names and certain properties of these database representing the names and certain properties of these
objects; an architecture providing distributed maintenance, objects; an architecture providing distributed maintenance,
resilience, and loose coherency for this database; and a simple resilience, and loose coherency for this database; and a simple
query-response protocol (as mentioned below) implementing this query-response protocol (as mentioned below) implementing this
architecture. Section 2 defines "global DNS" and "private DNS" as a architecture. Section 2 defines "global DNS" and "private DNS" as a
way to deal with these differing definitions. way to deal with these differing definitions.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
come from [RFC1034] and [RFC1035], although the term "global DNS" come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now. has not been defined before now.
Composition of names -- A name in the global DNS has one or more Composition of names -- A name in the global DNS has one or more
labels. The length of each label is between 0 and 63 octets labels. The length of each label is between 0 and 63 octets
inclusive. In a fully-qualified domain name, the first label in inclusive. In a fully-qualified domain name, the first label in
the ordered list is 0 octets long; it is the only label whose the ordered list is 0 octets long; it is the only label whose
length may be 0 octets, and it is called the "root" or "root length may be 0 octets, and it is called the "root" or "root
label". A domain name in the global DNS has a maximum total label". A domain name in the global DNS has a maximum total
length of 255 octets in the wire format; the root represents one length of 255 octets in the wire format; the root represents one
octet for this calculation. octet for this calculation. (Multicast DNS [RFC6762] allows names
up to 255 bytes plus a terminating zero byte based on a different
interpretation of RFC 1035 and what is included in the 255
octets.)
Format of names -- Names in the global DNS are domain names. Format of names -- Names in the global DNS are domain names.
There are three formats: wire format, presentation format, and There are three formats: wire format, presentation format, and
common display. common display.
The basic wire format for names in the global DNS is a list of The basic wire format for names in the global DNS is a list of
labels ordered by decreasing distance from the root, with the root labels ordered by decreasing distance from the root, with the root
label last. Each label is preceded by a length octet. [RFC1035] label last. Each label is preceded by a length octet. [RFC1035]
also defines a compression scheme that modifies this format. also defines a compression scheme that modifies this format.
skipping to change at page 5, line 43 skipping to change at page 5, line 46
in ASCII. in ASCII.
The common display format is used in applications and free text. The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done. For label and the "." before it is optional and is rarely done. For
example, in common display format, a fully-qualified domain name example, in common display format, a fully-qualified domain name
with two non-root labels is usually shown as "example.tld" instead with two non-root labels is usually shown as "example.tld" instead
of "example.tld.". Names in the common display format are of "example.tld.". Names in the common display format are
normally written such that the directionality of the writing normally written such that the directionality of the writing
system presents labels by decreasing distance from the root (so, system presents labels by decreasing distance from the root (so,
in both English and C the first label in the ordered list is in both English and C the root or TLD label in the ordered list is
right-most; but in Arabic it may be left-most, depending on local right-most; but in Arabic it may be left-most, depending on local
conventions). conventions).
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). The name servers that serve the root zone are
provided by independent root operators. Other zones in the global provided by independent root operators. Other zones in the global
DNS have their own policies for administration. DNS have their own policies for administration.
skipping to change at page 6, line 22 skipping to change at page 6, line 26
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
associated with them in the DNS, but "appear" in the DNS anyway associated with them in the DNS, but "appear" in the DNS anyway
because they form part of a longer name that does have data because they form part of a longer name that does have data
associated with it (see the defintion of "empty non-terminals" in associated with it (see the definition of "empty non-terminals" in
Section 7). Section 7).
Protocol for getting data from a name -- The protocol described in Protocol for getting data from a name -- The protocol described in
[RFC1035]. [RFC1035].
Context for resolving a name -- The global DNS root zone Context for resolving a name -- The global DNS root zone
distributed by PTI. distributed by PTI.
Private DNS: Names that use the protocol described in [RFC1035] but Private DNS: Names that use the protocol described in [RFC1035] but
that do not rely on the global DNS root zone, or names that are that do not rely on the global DNS root zone, or names that are
otherwise not generally available on the Internet but are using otherwise not generally available on the Internet but are using
the protocol described in [RFC1035]. A system can use both the the protocol described in [RFC1035]. A system can use both the
global DNS and one or more private DNS systems; for example, see global DNS and one or more private DNS systems; for example, see
"Split DNS" in Section 6. "Split DNS" in Section 6.
Note that domain names that do not appear in the DNS, and that are Note that domain names that do not appear in the DNS, and that are
intended never to be looked up using the DNS protocol, are not intended never to be looked up using the DNS protocol, are not
part 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
DNS-like operations on the local link in the absence of any
conventional Unicast DNS server. In addition, Multicast DNS
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
to set up delegations or otherwise configure a conventional DNS
server to answer for those names." Quoted from [RFC6762],
Abstract) Although it uses a compatible wire format, mDNS is
strictly speaking a different protocol than DNS. Also, where the
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
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
served zones may result in ambiguous results. For example, the served zones may result in ambiguous results. For example, the
same name may resolve to different results in different locally same name may resolve to different results in different locally
served DNS zone contexts. The context through which a locally served DNS zone contexts. The context through which a locally
served zone may be explicit, for example, as defined in [RFC6303], served zone may be explicit, for example, as defined in [RFC6303],
or implicit, as defined by local DNS administration and not known or implicit, as defined by local DNS administration and not known
to the resolution client. to the resolution client.
skipping to change at page 7, line 32 skipping to change at page 7, line 47
"www.example.net"). Such relative names are understood only by "www.example.net"). Such relative names are understood only by
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". Note that any label in a [RFC1034], the "preferred name syntax" (that is, every character
domain name can contain any octet value; hostnames are generally in each label are a letter, a digit, or a hyphen). Note that any
considered to be domain names where every label follows the rules label in a domain name can contain any octet value; hostnames are
in the "preferred name syntax", with the amendment that labels can generally considered to be domain names where every label follows
start with ASCII digits (this amendment comes from Section 2.1 of the rules in the "preferred name syntax", with the amendment that
[RFC1123]). labels can start with ASCII digits (this amendment comes from
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
sometimes use this term to describe any name that refers to a sometimes use this term to describe any name that refers to a
machine, and those might include labels that do not conform to the machine, and those might include labels that do not conform to the
"preferred name syntax". "preferred name syntax".
TLD: A Top-Level Domain, meaning a zone that is one layer below the TLD: A Top-Level Domain, meaning a zone that is one layer below the
skipping to change at page 9, line 15 skipping to change at page 9, line 32
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 - Meaningful only for responses from an
authoritative name server, this code signifies that the domain authoritative name server, this code signifies that the domain
name referenced in the query does not exist." (Quoted from name referenced in the query does not exist." (Quoted from
[RFC1035], Section 4.1.1.) [RFC1035], Section 4.1.1.) [RFC2308] established NXDOMAIN as a
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 11, line 6 skipping to change at page 11, line 24
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
Section in the orignal query, which is always echoed in the Section in the original query, which is always echoed in the
(final) reply in the Question Section when the QR bit is set to (final) reply in the Question Section when the QR bit is set to
1. 1.
* QNAME (effective): A name actually resolved, which is either * QNAME (effective): A name actually resolved, which is either
the 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.
Note that, because the definition in [RFC2308] is actually for a Note that, because the definition in [RFC2308] is actually for a
different concept than what was in [RFC1034], it would have be different concept than what was in [RFC1034], it would have be
better if [RFC2308] had used a different name for that concept. better if [RFC2308] had used a different name for that concept.
In general use today, QNAME almost always means what is defined In general use today, QNAME almost always means what is defined
above as "QNAME (original)". above as "QNAME (original)".
Referrals: A type of response in which a server, signalling that it Referrals: A type of response in which a server, signaling that it
is not (completely) authoritative for an answer, provides the is not (completely) authoritative for an answer, provides the
querying resolver with an alternative place to send its query. querying resolver with an alternative place to send its query.
Referrals can be partial. Referrals can be partial.
A referral arises when a server is not performing recursive A referral arises when a server is not performing recursive
service while answering a query. It appears in step 3(b) of the service while answering a query. It appears in step 3(b) of the
algorithm in [RFC1034], Section 4.3.2. algorithm in [RFC1034], Section 4.3.2.
There are two types of referral response. The first is a downward There are two types of referral response. The first is a downward
referral (sometimes described as "delegation response"), where the referral (sometimes described as "delegation response"), where the
skipping to change at page 12, line 31 skipping to change at page 12, line 52
5. Resource Records 5. Resource Records
RR: An acronym for resource record. ([RFC1034], Section 3.6.) RR: An acronym for resource record. ([RFC1034], Section 3.6.)
RRset: A set of resource records with the same label, class and RRset: A set of resource records with the same label, class and
type, but with different data. (Definition from [RFC2181]) Also type, but with different data. (Definition from [RFC2181]) Also
spelled RRSet in some documents. As a clarification, "same label" spelled RRSet in some documents. As a clarification, "same label"
in this definition means "same owner name". In addition, in this definition means "same owner name". In addition,
[RFC2181] states that "the TTLs of all RRs in an RRSet must be the [RFC2181] states that "the TTLs of all RRs in an RRSet must be the
same". (This definition is definitely not the same as "the same".
response one gets to a query for QTYPE=ANY", which is an
unfortunate misunderstanding.) Note that RRSIG resource records do not match this definition.
[RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated
with it. Note that as RRSIG RRs are closely tied to the RRsets
whose signatures they contain, RRSIG RRs, unlike all other DNS RR
types, do not form RRsets. In particular, the TTL values among
RRSIG RRs with a common owner name do not follow the RRset rules
described in [RFC2181]."
Master file: "Master files are text files that contain RRs in text Master file: "Master files are text files that contain RRs in text
form. Since the contents of a zone can be expressed in the form form. Since the contents of a zone can be expressed in the form
of a list of RRs a master file is most often used to define a of a list of RRs a master file is most often used to define a
zone, though it can be used to list a cache's contents." zone, though it can be used to list a cache's contents."
([RFC1035], Section 5.) Master files are sometimes called "zone ([RFC1035], Section 5.) Master files are sometimes called "zone
files". files".
Presentation format: The text format used in master files. This Presentation format: The text format used in master files. This
format is shown but not formally defined in [RFC1034] and format is shown but not formally defined in [RFC1034] and
skipping to change at page 14, line 14 skipping to change at page 14, line 39
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 classes other class of the record, or the meaning is undefined for some class.
than IN (class 1, the Internet). Most resorece record types are defined for class 1 (IN, the
Internet), but many are undefined for other classes.
Address records: Records whose type is A or AAAA. [RFC2181] Address records: Records whose type is 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".
skipping to change at page 14, line 26 skipping to change at page 15, line 4
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"
require context in order to understand the services being provided.
Both authoritative servers and recursive resolvers are often called
"DNS servers" and "name servers" even though they serve different
roles (and 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) "The resolver is located on the same machine as the
program that requests the resolver's services, but it may need to program that requests the resolver's services, but it may need to
consult name servers on other hosts." (Quoted from [RFC1034], consult name servers on other hosts." (Quoted from [RFC1034],
skipping to change at page 15, line 24 skipping to change at page 16, line 10
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". A server operating in recursive mode may be thought of server". Section 4.3.1 of of [RFC1034] says "in \[recursive\]
as having a name server side (which is what answers the query) and mode the name server acts in the role of a resolver and returns
a resolver side (which performs the resolution function). Systems either an error or the answer, but never referrals." That same
operating in this mode are commonly called "recursive servers". section also says "The recursive mode occurs when a query with RD
Sometimes they are called "recursive resolvers". While strictly set arrives at a server which is willing to provide recursive
the difference between these is that one of them sends queries to service; the client can verify that recursive mode was used by
checking that both RA and RD are set in the reply."
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
side (which performs the resolution function). Systems operating
in this mode are commonly called "recursive servers". Sometimes
they are called "recursive resolvers". While strictly the
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
in use interchangeably. in use interchangeably.
Full resolver: This term is used in [RFC1035], but it is not defined
there. RFC 1123 defines a "full-service resolver" that may or may
not be what was intended by "full resolver" in [RFC1035]. This
term is not properly defined in any RFC.
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
(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.
[RFC4697] tried to differentiate between a recursive resolver and
an iterative resolver.
Recursive query: A query with the Recursion Desired (RD) bit set to 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 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, service is available and is requested by the RD bit in the query,
the server uses its resolver to answer the query. (See the server uses its resolver to answer the query. (See
Section 4.3.2 of [RFC1035].) Section 4.3.2 of [RFC1035].)
Non-recursive query: A query with the Recursion Desired (RD) bit set Non-recursive query: A query with the Recursion Desired (RD) bit set
to 0 in the header. A server can answer non-recursive queries to 0 in the header. A server can answer non-recursive queries
using only local information: the response contains either an using only local information: the response contains either an
error, the answer, or a referral to some other server "closer" to error, the answer, or a referral to some other server "closer" to
the answer. (See Section 4.3.1 of [RFC1035].) 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 Iterative resolution: A name server may be presented with a query
that can only be answered by some other server. The two general that can only be answered by some other server. The two general
approaches to dealing with this problem are "recursive", in which approaches to dealing with this problem are "recursive", in which
the first server pursues the query for the client at another the first server pursues the query on behalf of the client at
server, and "iterative", in which the server refers the client to another server, and "iterative", in which the server refers the
another server and lets the client pursue the query there. (See client to another server and lets the client pursue the query
Section 2.3 of [RFC1034].) there. (See Section 2.3 of [RFC1034].)
In iterative resolution, the client repeatedly makes non-recursive In iterative resolution, the client repeatedly makes non-recursive
queries and follows referrals and/or aliases. The iterative queries and follows referrals and/or aliases. The iterative
resolution algorithm is described in Section 5.3.3 of [RFC1034]. resolution algorithm is described in Section 5.3.3 of [RFC1034].
Full resolver: This term is used in [RFC1035], but it is not defined
there. RFC 1123 defines a "full-service resolver" that may or may
not be what was intended by "full resolver" in [RFC1035]. This
term is not properly defined in any RFC.
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
(and meets other requirements).
Priming: "The act of finding the list of root servers from a Priming: "The act of finding the list of root servers from a
configuration that lists some or all of the purported IP addresses configuration that lists some or all of the purported IP addresses
of some or all of those root servers." (Quoted from [RFC8109], of some or all of those root servers." (Quoted from [RFC8109],
Section 2.) In order to operate in recursive mode, a resolver Section 2.) In order to operate in recursive mode, a resolver
needs to know the address of at least one root server. Priming is needs to know the address of at least one root server. Priming is
most often done from a configuration setting that contains a list most often done from a configuration setting that contains a list
of authoritative servers for the root zone. of authoritative servers for the root zone.
Root hints: "Operators who manage a DNS recursive resolver typically Root hints: "Operators who manage a DNS recursive resolver typically
need to configure a 'root hints file'. This file contains the need to configure a 'root hints file'. This file contains the
skipping to change at page 18, line 30 skipping to change at page 19, line 21
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",
although in some setups, the name does not appear at all in the although in some setups, the name does not appear at all in the
public DNS. A hidden master can also be a secondary server public DNS. A hidden master can also be a secondary server for
itself. the zone itself.
Forwarding: The process of one server sending a DNS query with the Forwarding: The process of one server sending a DNS query with the
RD bit set to 1 to another server to resolve that query. RD bit set to 1 to another server to resolve that query.
Forwarding is a function of a DNS resolver; it is different than Forwarding is a function of a DNS resolver; it is different than
simply blindly relaying queries. simply blindly relaying queries.
[RFC5625] does not give a specific definition for forwarding, but [RFC5625] does not give a specific definition for forwarding, but
describes in detail what features a system that forwards needs to describes in detail what features a system that forwards needs to
support. Systems that forward are sometimes called "DNS proxies", support. Systems that forward are sometimes called "DNS proxies",
but that term has not yet been defined (even in [RFC5625]). but that term has not yet been defined (even in [RFC5625]).
skipping to change at page 19, line 24 skipping to change at page 20, line 15
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) stub resolver. This is sometimes
also called a "public resolver", although the term "public also called a "public resolver", although the term "public
resolver" is used more with open resolvers that are meant to be resolver" is used more with open resolvers that are meant to be
open, as compared to the vast majority of open resolvers that are open, as compared to the vast majority of open resolvers that are
probably misconfigured to be open. Open resolvers are discussed probably misconfigured to be open. Open resolvers are discussed
in [RFC5358] in [RFC5358]
Split DNS: The terms "split DNS" and "split-horizon DNS" have long
been used in the DNS community without formal definition. In
general, they refer to situations in which DNS servers that are
authoritative for a particular set of domains provide partly or
completely different answers in those domains depending on the
source of the query. The effect of this is that a domain name
that is notionally globally unique nevertheless has different
meanings for different network users. This can sometimes be the
result of a "view" configuration, described below.
[RFC2775], Section 3.8 gives a related definition that is too
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. different answers depending on attributes of the query, such as
Typically, views differ by the source IP address of a query, but for "split DNS". Typically, views differ by the source IP address
can also be based on the destination IP address, the type of query of a query, but can also be based on the destination IP address,
(such as AXFR), whether it is recursive, and so on. Views are the type of query (such as AXFR), whether it is recursive, and so
often used to provide more names or different addresses to queries on. Views are often used to provide more names or different
from "inside" a protected network than to those "outside" that addresses to queries from "inside" a protected network than to
network. Views are not a standardized part of the DNS, but they those "outside" that network. Views are not a standardized part
are widely implemented in server software. of the DNS, but they are widely implemented in server software.
Passive DNS: A mechanism to collect DNS data by storing DNS Passive DNS: A mechanism to collect DNS data by storing DNS
responses from name servers. Some of these systems also collect responses from name servers. Some of these systems also collect
the DNS queries associated with the responses, although doing so the DNS queries associated with the responses, although doing so
raises some privacy concerns. Passive DNS databases can be used raises some privacy concerns. Passive DNS databases can be used
to answer historical questions about DNS zones such as which to answer historical questions about DNS zones such as which
values were present at a given time in the past, or when a name values were present at a given time in the past, or when a name
was spotted first. Passive DNS databases allow searching of the was spotted first. Passive DNS databases allow searching of the
stored records on keys other than just the name and type, such as stored records on keys other than just the name and type, such as
"find all names which have A records of a particular value". "find all names which have A records of a particular value".
Anycast: "The practice of making a particular service address Anycast: "The practice of making a particular service address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations." datagrams sent are routed to one of several available locations."
(Quoted from [RFC4786], Section 2) (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail
on Anycast and other terms that are specific to its use.
Instance: "When anycast routing is used to allow more than one Instance: "When anycast routing is used to allow more than one
server to have the same IP address, each one of those servers is server to have the same IP address, each one of those servers is
commonly referred to as an 'instance'." "An instance of a server, commonly referred to as an 'instance'." "An instance of a server,
such as a root server, is often referred to as an 'Anycast such as a root server, is often referred to as an 'Anycast
instance'." (Quoted from [RSSAC026]) instance'." (Quoted from [RSSAC026])
Split DNS: "Where a corporate network serves up partly or completely Privacy-enabling DNS server: "A DNS server that implements DNS over
different DNS inside and outside its firewall. There are many TLS [RFC7858] and may optionally implement DNS over DTLS
possible variants on this; the basic point is that the [RFC8094]." (Quoted from [RFC8310], Section 2)
correspondence between a given FQDN (fully qualified domain name)
and a given IPv4 address is no longer universal and stable over
long periods." (Quoted from [RFC2775], Section 3.8)
7. Zones 7. Zones
This section defines terms that are used when discussing zones that This section defines terms that are used when discussing zones that
are being served or retrieved. are being served or retrieved.
Zone: "Authoritative information is organized into units called Zone: "Authoritative information is organized into units called
'zones', and these zones can be automatically distributed to the 'zones', and these zones can be automatically distributed to the
name servers which provide redundant service for the data in a name servers which provide redundant service for the data in a
zone." (Quoted from [RFC1034], Section 2.4) zone." (Quoted from [RFC1034], Section 2.4)
skipping to change at page 21, line 21 skipping to change at page 22, line 23
distinction is not always maintained in use, however, and one can distinction is not always maintained in use, however, and one can
find uses that conflict subtly with this definition. [RFC1034] find uses that conflict subtly with this definition. [RFC1034]
uses the term "top node of the zone" as a synonym of "apex", but uses the term "top node of the zone" as a synonym of "apex", but
that term is not widely used. These days, the first sense of that term is not widely used. These days, the first sense of
"origin" (above) and "apex" are often used interchangeably. "origin" (above) and "apex" are often used interchangeably.
Zone cut: The delimitation point between two zones where the origin Zone cut: The delimitation point between two zones where the origin
of one of the zones is the child of the other zone. of one of the zones is the child of the other zone.
"Zones are delimited by 'zone cuts'. Each zone cut separates a "Zones are delimited by 'zone cuts'. Each zone cut separates a
'child' zone (below the cut) from a 'parent' zone (above the cut). 'child' zone (below the cut) from a 'parent' zone (above the
(Quoted from [RFC2181], Section 6; note that this is barely an cut)." (Quoted from [RFC2181], Section 6; note that this is
ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as barely an ostensive definition.) Section 4.2 of [RFC1034] uses
'zone cut'." "cuts" instead of "zone cut".
Delegation: The process by which a separate zone is created in the Delegation: The process by which a separate zone is created in the
name space beneath the apex of a given domain. Delegation happens name space beneath the apex of a given domain. Delegation happens
when an NS RRset is added in the parent zone for the child origin. when an NS RRset is added in the parent zone for the child origin.
Delegation inherently happens at a zone cut. The term is also Delegation inherently happens at a zone cut. The term is also
commonly a noun: the new zone that is created by the act of commonly a noun: the new zone that is created by the act of
delegating. delegating.
Authoritative data: "All of the RRs attached to all of the nodes Authoritative data: "All of the RRs attached to all of the nodes
from the top node of the zone down to leaf nodes or nodes above from the top node of the zone down to leaf nodes or nodes above
cuts around the bottom edge of the zone." (Quoted from [RFC1034], cuts around the bottom edge of the zone." (Quoted from [RFC1034],
Section 4.2.1) It is noted that this definition might Section 4.2.1) Note that this definition might inadvertently also
inadvertently also include any NS records that appear in the zone, cause any NS records that appear in the zone to be included, even
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.
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)." (Definition from [RFC1912], Section 2.8)
skipping to change at page 22, line 22 skipping to change at page 23, line 26
file that is not properly part of that zone, including nameserver file that is not properly part of that zone, including nameserver
records of delegated sub-zones (NS records), address records that records of delegated sub-zones (NS records), address records that
accompany those NS records (A, AAAA, etc), and any other stray accompany those NS records (A, AAAA, etc), and any other stray
data that might appear" ([RFC2181], Section 5.4.1). Although glue data that might appear" ([RFC2181], Section 5.4.1). Although glue
is sometimes used today with this wider definition in mind, the is sometimes used today with this wider definition in mind, the
context surrounding the [RFC2181] definition suggests it is context surrounding the [RFC2181] definition suggests it is
intended to apply to the use of glue within the document itself intended to apply to the use of glue within the document itself
and not necessarily beyond. and not necessarily beyond.
Bailiwick: "In-bailiwick" is an adjective to describe a name server Bailiwick: "In-bailiwick" is an adjective to describe a name server
whose name is either subordinate to or (rarely) the same as the whose name is either a subdomain of or (rarely) the same as the
origin of the zone that contains the delegation to the name origin of the zone that contains the delegation to the name
server. In-bailiwick name servers may have glue records in their server. In-bailiwick name servers may have glue records in their
parent zone (using the first of the definitions of "glue records" parent zone (using the first of the definitions of "glue records"
in the definition above). (The term "bailiwick" means the in the definition above). (The term "bailiwick" means the
district or territory where a bailiff or policeman has district or territory where a bailiff or policeman has
jusrisdiction.) jurisdiction.)
"In-bailiwick" names are divided into two type of name server "In-bailiwick" names are divided into two type of name server
names: "in-domain" names and "sibling domain" names. names: "in-domain" names and "sibling domain" names.
* In-domain: an adjective to describe a name server whose name is * In-domain: an adjective to describe a name server whose name is
either subordinate to or (rarely) the same as the owner name of either subordinate to or (rarely) the same as the owner name of
the NS resource records. An in-domain name server name MUST the NS resource records. An in-domain name server name MUST
have glue records or name resolution fails. For example, a have glue records or name resolution fails. For example, a
delegation for "child.example.com" may have "in-domain" name delegation for "child.example.com" may have "in-domain" name
server name "ns.child.example.com". server name "ns.child.example.com".
skipping to change at page 23, line 46 skipping to change at page 24, line 50
still part of the zone, but not available to the lookup process. still part of the zone, but not available to the lookup process.
The addition of a DNAME resource record has the same impact. The The addition of a DNAME resource record has the same impact. The
subordinate names are said to be 'occluded'." (Quoted from subordinate names are said to be 'occluded'." (Quoted from
[RFC5936], Section 3.5) [RFC5936], Section 3.5)
Fast flux DNS: This "occurs when a domain is found in DNS using A Fast flux DNS: This "occurs when a domain is found in DNS using A
records to multiple IP addresses, each of which has a very short records to multiple IP addresses, each of which has a very short
Time-to-Live (TTL) value associated with it. This means that the Time-to-Live (TTL) value associated with it. This means that the
domain resolves to varying IP addresses over a short period of domain resolves to varying IP addresses over a short period of
time." (Quoted from [RFC6561], Section 1.1.5, with typo time." (Quoted from [RFC6561], Section 1.1.5, with typo
corrected) It is often used to deliver malware. Because the corrected) In addition to having legitimate uses, fast flux DNS
addresses change so rapidly, it is difficult to ascertain all the can used to deliver malware. Because the addresses change so
hosts. It should be noted that the technique also works with AAAA rapidly, it is difficult to ascertain all the hosts. It should be
records, but such use is not frequently observed on the Internet noted that the technique also works with AAAA records, but such
as of this writing. use is not frequently observed on the Internet as of this writing.
Reverse DNS, reverse lookup: "The process of mapping an address to a Reverse DNS, reverse lookup: "The process of mapping an address to a
name is generally known as a 'reverse lookup', and the IN- name is generally known as a 'reverse lookup', and the IN-
ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
DNS'." (Quoted from [RFC5855], Section 1) DNS'." (Quoted from [RFC5855], Section 1)
Forward lookup: "Hostname-to-address translation". (Quoted from Forward lookup: "Hostname-to-address translation". (Quoted from
[RFC2133], Section 6) [RFC2133], Section 6)
arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain
was originally established as part of the initial deployment of was originally established as part of the initial deployment of
the DNS, to provide a transition mechanism from the Host Tables the DNS, to provide a transition mechanism from the Host Tables
that were common in the ARPANET, as well as a home for the IPv4 that were common in the ARPANET, as well as a home for the IPv4
reverse mapping domain. During 2000, the abbreviation was reverse mapping domain. During 2000, the abbreviation was
redesignated to 'Address and Routing Parameter Area' in the hope redesignated to 'Address and Routing Parameter Area' in the hope
of reducing confusion with the earlier network name." (Quoted of reducing confusion with the earlier network name." (Quoted
from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a
domain whose "role is to support the operating infrastructure of domain whose "role is to support the operating infrastructure of
the Internet". (Quoted from [RFC3172], Section 2.) the Internet". (Quoted from [RFC3172], Section 2.) See [RFC3172]
for more history of this name.
Service name: "Service names are the unique key in the Service Name Service name: "Service names are the unique key in the Service Name
and Transport Protocol Port Number registry. This unique symbolic and Transport Protocol Port Number registry. This unique symbolic
name for a service may also be used for other purposes, such as in name for a service may also be used for other purposes, such as in
DNS SRV records." (Quoted from [RFC6335], Section 5.) DNS SRV records." (Quoted from [RFC6335], Section 5.)
8. Wildcards 8. Wildcards
Wildcard: [RFC1034] defined "wildcard", but in a way that turned out Wildcard: [RFC1034] defined "wildcard", but in a way that turned out
to be confusing to implementers. For an extended discussion of to be confusing to implementers. For an extended discussion of
skipping to change at page 26, line 27 skipping to change at page 27, line 31
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.
Public suffix: "A domain that is controlled by a public registry." Public suffix: "A domain that is controlled by a public registry."
(Quoted from [RFC6265], Section 5.3) A common definition for this (Quoted from [RFC6265], Section 5.3) A common definition for this
term is a domain under which subdomains can be registered, and on term is a domain under which subdomains can be registered by third
which HTTP cookies (which are described in detail in [RFC6265]) parties, and on which HTTP cookies (which are described in detail
should not be set. There is no indication in a domain name in [RFC6265]) should not be set. There is no indication in a
whether it is a public suffix; that can only be determined by domain name whether it is a public suffix; that can only be
outside means. In fact, both a domain and a subdomain of that determined by outside means. In fact, both a domain and a
domain can be public suffixes. subdomain of that domain can be public suffixes.
There is nothing inherent in a domain name to indicate whether it There is nothing inherent in a domain name to indicate whether it
is a public suffix. One resource for identifying public suffixes is a public suffix. One resource for identifying public suffixes
is the Public Suffix List (PSL) maintained by Mozilla is the Public Suffix List (PSL) maintained by Mozilla
(http://publicsuffix.org/). (http://publicsuffix.org/).
For example, at the time this document is published, the "com.au" For example, at the time this document is published, the "com.au"
domain is listed as a public suffix in the PSL. (Note that this domain is listed as a public suffix in the PSL. (Note that this
example might change in the future.) example might change in the future.)
skipping to change at page 30, line 46 skipping to change at page 31, line 48
configured as a trust anchor. Therefore, it is suggested that the configured as a trust anchor. Therefore, it is suggested that the
SEP flag be set on keys that are used as KSKs and not on keys that SEP flag be set on keys that are used as KSKs and not on keys that
are used as ZSKs, while in those cases where a distinction between are used as ZSKs, while in those cases where a distinction between
a KSK and ZSK is not made (i.e., for a Single-Type Signing a KSK and ZSK is not made (i.e., for a Single-Type Signing
Scheme), it is suggested that the SEP flag be set on all keys." Scheme), it is suggested that the SEP flag be set on all keys."
(Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is (Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is
only a hint, and its presence or absence may not be used to only a hint, and its presence or absence may not be used to
disqualify a given DNSKEY RR from use as a KSK or ZSK during disqualify a given DNSKEY RR from use as a KSK or ZSK during
validation. validation.
The original defintion of SEPs was in [RFC3757]. That definition The original definition of SEPs was in [RFC3757]. That definition
clearly indicated that the SEP was a key, not just a bit in the clearly indicated that the SEP was a key, not just a bit in the
key. The abstract of [RFC3757] says: "With the Delegation Signer key. The abstract of [RFC3757] says: "With the Delegation Signer
(DS) resource record (RR), the concept of a public key acting as a (DS) resource record (RR), the concept of a public key acting as a
secure entry point (SEP) has been introduced. During exchanges of secure entry point (SEP) has been introduced. During exchanges of
public keys with the parent there is a need to differentiate SEP public keys with the parent there is a need to differentiate SEP
keys from other public keys in the Domain Name System KEY (DNSKEY) keys from other public keys in the Domain Name System KEY (DNSKEY)
resource record set. A flag bit in the DNSKEY RR is defined to resource record set. A flag bit in the DNSKEY RR is defined to
indicate that DNSKEY is to be used as a SEP." That definition of indicate that DNSKEY is to be used as a SEP." That definition of
the SEP as a key was made obsolete by [RFC4034], and the the SEP as a key was made obsolete by [RFC4034], and the
definition from [RFC6781] is consistent with [RFC4034]. definition from [RFC6781] is consistent with [RFC4034].
Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
A validating security-aware resolver uses this public key or hash A validating security-aware resolver uses this public key or hash
as a starting point for building the authentication chain to a as a starting point for building the authentication chain to a
signed DNS response." (Quoted from [RFC4033], Section 2) signed DNS response. In general, a validating resolver will have
to obtain the initial values of its trust anchors via some secure
or trusted means outside the DNS protocol." (Quoted from
[RFC4033], Section 2)
DNSSEC Policy (DP): A statement that "sets forth the security DNSSEC Policy (DP): A statement that "sets forth the security
requirements and standards to be implemented for a DNSSEC-signed requirements and standards to be implemented for a DNSSEC-signed
zone." (Quoted from [RFC6841], Section 2) zone." (Quoted from [RFC6841], Section 2)
DNSSEC Practice Statement (DPS): "A practices disclosure document DNSSEC Practice Statement (DPS): "A practices disclosure document
that may support and be a supplemental document to the DNSSEC that may support and be a supplemental document to the DNSSEC
Policy (if such exists), and it states how the management of a Policy (if such exists), and it states how the management of a
given zone implements procedures and controls at a high level." given zone implements procedures and controls at a high level."
(Quoted from [RFC6841], Section 2) (Quoted from [RFC6841], Section 2)
skipping to change at page 36, line 34 skipping to change at page 37, line 34
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>. <https://www.rfc-editor.org/info/rfc7344>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>.
14.2. Informative References 14.2. Informative References
[IANA_Resource_Registry] [IANA_Resource_Registry]
Internet Assigned Numbers Authority, "Resource Record (RR) Internet Assigned Numbers Authority, "Resource Record (RR)
TYPEs", 2017, TYPEs", 2017,
<http://www.iana.org/assignments/dns-parameters/>. <http://www.iana.org/assignments/dns-parameters/>.
[RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
Internet User Applications", RFC 819, Internet User Applications", RFC 819,
DOI 10.17487/RFC0819, August 1982, DOI 10.17487/RFC0819, August 1982,
skipping to change at page 39, line 10 skipping to change at page 40, line 17
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>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<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,
DOI 10.17487/RFC7480, March 2015, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>. <https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
skipping to change at page 39, line 43 skipping to change at page 41, line 5
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2015, <https://www.rfc-editor.org/info/rfc7484>. 2015, <https://www.rfc-editor.org/info/rfc7484>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects", "Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015, RFC 7485, DOI 10.17487/RFC7485, March 2015,
<https://www.rfc-editor.org/info/rfc7485>. <https://www.rfc-editor.org/info/rfc7485>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
Resolver with Priming Queries", BCP 209, RFC 8109, Resolver with Priming Queries", BCP 209, RFC 8109,
DOI 10.17487/RFC8109, March 2017, DOI 10.17487/RFC8109, March 2017,
<https://www.rfc-editor.org/info/rfc8109>. <https://www.rfc-editor.org/info/rfc8109>.
[RSSAC026] [RSSAC026]
Root Server System Advisory Committee (RSSAC), "RSSAC Root Server System Advisory Committee (RSSAC), "RSSAC
Lexicon", 2017, Lexicon", 2017,
<https://www.icann.org/en/system/files/files/ <https://www.icann.org/en/system/files/files/
rssac-026-14mar17-en.pdf>. rssac-026-14mar17-en.pdf>.
skipping to change at page 42, line 10 skipping to change at page 43, line 31
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 19 Anycast 20
Apex 21 Apex 22
Asterisk label 24 Asterisk label 25
Authoritative data 21 Authoritative data 22
Authoritative server 16 Authoritative server 17
Authoritative-only server 17 Authoritative-only server 18
arpa: Address and Routing Parameter Area Domain 24 arpa: Address and Routing Parameter Area Domain 25
C C
CNAME 8 CNAME 9
Canonical name 8 Canonical name 8
Child 20 Child 21
Class independent 14 Class independent 14
Closest encloser 24 Closest encloser 26
Closest provable encloser 25 Closest provable encloser 26
Combined signing key (CSK) 30 Combined signing key (CSK) 31
D D
DNS operator 26 DNS operator 27
DNSSEC Policy (DP) 31 DNSSEC Policy (DP) 32
DNSSEC Practice Statement (DPS) 31 DNSSEC Practice Statement (DPS) 32
DNSSEC-aware and DNSSEC-unaware 27 DNSSEC-aware and DNSSEC-unaware 28
Delegation 21 Delegation 22
Delegation-centric zone 23 Delegation-centric zone 24
Domain name 4 Domain name 4
E E
EDNS 12 EDNS 13
EPP 25 EPP 27
Empty non-terminals (ENT) 23 Empty non-terminals (ENT) 24
F F
FORMERR 9 FORMERR 9
Fast flux DNS 23 Fast flux DNS 24
Forward lookup 24 Forward lookup 25
Forwarder 18 Forwarder 19
Forwarding 18 Forwarding 19
Full resolver 15 Full resolver 17
Full-service resolver 15 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 21 Glue records 23
H H
Hardware security module (HSM) 31 Hardware security module (HSM) 32
Hidden master 18 Hidden master 19
Host name 7 Host name 7
I I
IDN 8 IDN 8
In-bailiwick 22 In-bailiwick 23
Insecure delegation 28 Insecure delegation 29
Instance 19 Instance 21
Iterative mode 15 Iterative mode 15
Iterative query 16
Iterative resolution 16 Iterative resolution 16
K K
Key signing key (KSK) 30 Key signing key (KSK) 31
L L
Label 4 Label 4
Lame delegation 21 Lame delegation 22
Locally served DNS zone 6 Locally served DNS zone 7
M M
Master file 12 Master file 13
Master server 17 Master server 18
Multicast DNS 6
N N
NODATA 9 NODATA 9
NOERROR 8 NOERROR 9
NOTIMP 9 NOTIMP 9
NSEC 28 NSEC 29
NSEC3 28 NSEC3 29
NXDOMAIN 9 NXDOMAIN 9
Naming system 3 Naming system 3
Negative caching 16 Negative caching 17
Negative response 9 Negative response 10
Next closer name 25 Next closer name 26
Non-recursive query 16 Non-recursive query 16
O O
OPT 13 OPT 13
Occluded name 23 Occluded name 24
Open resolver 19 Open resolver 20
Opt-out 28 Opt-out 29
Origin 20 Origin 21
Out-of-bailiwick 22 Out-of-bailiwick 23
Owner 13 Owner 13
P P
Parent 20 Parent 21
Passive DNS 19 Passive DNS 20
Policy-implementing resolver 19 Policy-implementing resolver 19
Presentation format 12 Presentation format 13
Primary master 18 Primary master 18
Primary server 17 Primary server 18
Priming 16 Priming 17
Privacy-enabling DNS server 21
Private DNS 6 Private DNS 6
Public suffix 26 Public suffix 27
Q Q
QNAME 10 QNAME 10
R R
RDAP 26 RDAP 27
REFUSED 9 REFUSED 9
RR 12 RR 12
RRset 12 RRset 12
Recursive mode 15 Recursive mode 16
Recursive query 15 Recursive query 16
Recursive resolver 15 Recursive resolver 16
Referrals 11 Referrals 11
Registrant 25 Registrant 26
Registrar 25 Registrar 26
Registry 25 Registry 26
Resolver 14 Resolver 15
Reverse DNS, reverse lookup 24 Reverse DNS, reverse lookup 25
Root hints 16 Root hints 17
Root zone 23 Root zone 24
S S
SERVFAIL 9 SERVFAIL 9
SOA field names 13 SOA field names 13
Secondary server 17 Secondary server 18
Secure Entry Point (SEP) 30 Secure Entry Point (SEP) 31
Service name 24 Service name 25
Signed zone 27 Signed zone 28
Signing software 31 Signing software 32
Slave server 17 Slave server 18
Source of Synthesis 25 Source of Synthesis 26
Split DNS 20 Split DNS 20
Stealth server 18 Split-horizon DNS 20
Stealth server 19
Stub resolver 15 Stub resolver 15
Subdomain 8 Subdomain 8
Subordinate 26 Subordinate 28
Superordinate 26 Superordinate 28
T T
TLD 7 TLD 8
TTL 13 TTL 13
Trust anchor 31 Trust anchor 32
U U
Unsigned zone 27 Unsigned zone 28
V V
Validating resolver 30 Validating resolver 31
Validation 29 Validation 30
View 19 View 20
W W
WHOIS 26 WHOIS 27
Wildcard 24 Wildcard 25
Wildcard domain name 24 Wildcard domain name 25
Z Z
Zone 20 Zone 21
Zone cut 21 Zone cut 22
Zone enumeration 28 Zone enumeration 30
Zone signing key (ZSK) 30 Zone signing key (ZSK) 31
Zone transfer 17 Zone transfer 18
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,
David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
John Klensin, David Black, and many others in the DNSOP Working Group John Klensin, David Black, and many others in the DNSOP Working Group
helped shape RFC 7719. helped shape RFC 7719.
Additional people contributed to this document, including: Bob Additional people contributed to this document, including: Bob
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, [[ MORE NAMES WILL APPEAR HERE AS Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL
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 Oracle
 End of changes. 79 change blocks. 
204 lines changed or deleted 279 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/