draft-ietf-dnsop-terminology-bis-03.txt   draft-ietf-dnsop-terminology-bis-04.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
Intended status: Best Current Practice Dyn Intended status: Best Current Practice Dyn
Expires: May 4, 2017 K. Fujiwara Expires: July 31, 2017 K. Fujiwara
JPRS JPRS
October 31, 2016 January 27, 2017
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-03 draft-ietf-dnsop-terminology-bis-04
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on July 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 Header and Response Codes . . . . . . . . . . . . . . . . 6 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 8
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 7 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 9
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 9 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 11
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 18 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 20
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 19 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 21
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 22 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Definitions Updated by this Document . . . . . . . . 30 Appendix A. Definitions Updated by this Document . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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. The protocol whose messages in both directions have the same format. (See
and message format are defined in [RFC1034] and [RFC1035]. These Section 2 for a fuller definition.) The protocol and message format
RFCs defined some terms, but later documents defined others. Some of are defined in [RFC1034] and [RFC1035]. These RFCs defined some
the terms from RFCs 1034 and 1035 now have somewhat different terms, but later documents defined others. Some of the terms from
meanings than they did in 1987. [RFC1034] and [RFC1035] now have somewhat different meanings than
they did in 1987.
This document collects a wide variety of DNS-related terms. Some of This document collects a wide variety of DNS-related terms. Some of
them have been precisely defined in earlier RFCs, some have been them have been precisely defined in earlier RFCs, some have been
loosely defined in earlier RFCs, and some are not defined in any loosely defined in earlier RFCs, and some are not defined in any
earlier RFC at all. earlier RFC at all.
Most of the definitions here are the consensus definition of the DNS Most of the definitions here are the consensus definition of the DNS
community -- both protocol developers and operators. Some of the community -- both protocol developers and operators. Some of the
definitions differ from earlier RFCs, and those differences are definitions differ from earlier RFCs, and those differences are
noted. In this document, where the consensus definition is the same noted. In this document, where the consensus definition is the same
skipping to change at page 3, line 29 skipping to change at page 3, line 29
For example, the W3C defines "domain" at For example, the W3C defines "domain" at
https://specs.webplatform.org/url/webspecs/develop/. https://specs.webplatform.org/url/webspecs/develop/.
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. architecture. Section 2 defines "global DNS" and "private DNS" as a
way to deal with these differing definitions.
Capitalization in DNS terms is often inconsistent among RFCs and Capitalization in DNS terms is often inconsistent among RFCs and
various DNS practitioners. The capitalization used in this document various DNS practitioners. The capitalization used in this document
is a best guess at current practices, and is not meant to indicate is a best guess at current practices, and is not meant to indicate
that other capitalization styles are wrong or archaic. In some that other capitalization styles are wrong or archaic. In some
cases, multiple styles of capitalization are used for the same term cases, multiple styles of capitalization are used for the same term
due to quoting from different RFCs. due to quoting from different RFCs.
2. Names 2. Names
Domain name: Section 3.1 of [RFC1034] talks of "the domain name Naming system: A naming system associates names with data. Naming
space" as a tree structure. "Each node has a label, which is zero systems have many significant facets that help differentiate them.
to 63 octets in length. ... The domain name of a node is the list Some commonly-identified facets include:
of the labels on the path from the node to the root of the tree.
... To simplify implementations, the total number of octets that
represent a domain name (i.e., the sum of all label octets and
label lengths) is limited to 255." Any label in a domain name can
contain any octet value.
The term "domain name" was defined before [RFC1034], most likely * Composition of names
in [RFC0799], which precedes the existence of the DNS. In this
document, domain names are only described in terms of the DNS. * Format of names
* Administration of names
* Types of data that can be associated with names
* Types of metadata for names
* Protocol for getting data from a name
Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming
systems. For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data
associated with names", but those do not not have a clear
definitions as the ones listed above. The list here is chosen
because it helps describe the DNS and naming systems similar to
the DNS.
Domain name: An ordered list of zero or more labels.
Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS.
[RFC1034] defines the "domain name space" using mathematical trees
and their nodes in graph theory, and the definition in [RFC1034]
has the same practical result as the definition here. Using graph
theory, a domain name is a list of labels identifying a portion
along one edge of an acyclic directed graph. A domain name can be
relative to other parts of the tree, or it can be fully qualified
(in which case, it ends at the common root of the graph).
Also note that different IETF and non-IETF documents have used the
term "domain name" in many different ways. It is common for
earlier documents to use "domain name" to mean "names that match
the syntax in [RFC1035]", but possibly with additional rules such
as "and are, or will be, resolvable in the global DNS" or "but
only using the presentation format".
Label: An ordered list of zero or more octets and which makes up a
portion of a domain name. Using graph theory, a label identifies
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",
the global DNS can be defined as follows. Most of the rules here
come from [RFC1034] and [RFC1035], although the term "global DNS"
has not been defined before now.
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
inclusive. In a fully-qualified domain name, the first label is 0
octets long; it is the only label whose 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 length of 255 octets; the root
represents one octet for this calculation.
Format of names -- Names in the global DNS are domain names.
There are three formats: wire format, presentation format, and
common display.
The basic wire format for names in the global DNS is a list of
labels with the root label last. Each label is preceded by a
length octet. [RFC1035] also defines a compression scheme that
modifies this format.
The presentation format for names in the global DNS is a list of
labels, encoded as ASCII, with the root label last, and a "."
character between each label. In presentation format, a fully-
qualified domain name includes the root label and the associated
separator dot. In presentation format, a fully-qualified domain
name with two additional labels is always shown as "example.tld."
instead of "example.tld". [RFC1035] defines a method for showing
octets that do not display in ASCII.
The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done. In
common display format, a fully-qualified domain name with two
additional labels is usually shown as "example.tld" instead of
"example.tld.". Names in the common display format are normally
written such that the first label in the ordered list is in the
last position from the point of view of the directionality of the
writing system (so, in both English and C the first label is the
right-most label; but in Arabic it may be the left-most label,
depending on local conventions).
Administration of names -- Administration is specified by
delegation (see the definition of to "delegation" in Section 6).
Policies for administration of the root zone in the global DNS are
determined by the names operational community, which convenes
itself in the Internet Corporation for Assigned Names and Numbers
(ICANN). The names operational community selects the IANA
Functions Operator for the global DNS root zone. At the time this
document is published, that operator is Public Technical
Identifiers (PTI). The name 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
zero or more resource records associated with it. There are
numerous types of resource records with unique data structures
defined in many different RFCs and in the IANA registry at
[IANA_Resource_Registry].
Types of metadata for names -- Any name that is published in the
DNS appears as a set of resource records (see the definition of
"RRset" in Section 4). Some names do not themselves have data
associated with them in the DNS, but "appear" in the DNS anyway
because they form part of a longer name that does have data
associated with it (see the defintion of "empty non-terminals" in
Section 6).
Protocol for getting data from a name -- The protocol described in
[RFC1035].
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
otherwise not generally available on the Internet but are using
the protocol described in [RFC1035]. A system can use both the
global DNS and one or more private DNS systems; for example, see
"Split DNS" in Section 7.
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
part of the global DNS or a private DNS even though they are
domain names.
Fully qualified domain name (FQDN): This is often just a clear way Fully qualified domain name (FQDN): This is often just a clear way
of saying the same thing as "domain name of a node", as outlined of saying the same thing as "domain name of a node", as outlined
above. However, the term is ambiguous. Strictly speaking, a above. However, the term is ambiguous. Strictly speaking, a
fully qualified domain name would include every label, including fully qualified domain name would include every label, including
the final, zero-length label of the root: such a name would be the final, zero-length label of the root: such a name would be
written "www.example.net." (note the terminating dot). But written "www.example.net." (note the terminating dot). But
because every name eventually shares the common root, names are because every name eventually shares the common root, names are
often written relative to the root (such as "www.example.net") and often written relative to the root (such as "www.example.net") and
are still called "fully qualified". This term first appeared in are still called "fully qualified". This term first appeared in
[RFC0819]. In this document, names are often written relative to [RFC0819]. In this document, names are often written relative to
the root. the root.
The need for the term "fully qualified domain name" comes from the The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names existence of partially qualified domain names, which are names
where some of the right-most names are left off and are understood where some of the right-most names are left off and are understood
only by context. only by context.
Label: The identifier of an individual node in the sequence of nodes
identified by a fully qualified domain name.
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". Note that any label in a
domain name can contain any octet value; hostnames are generally domain name can contain any octet value; hostnames are generally
considered to be domain names where every label follows the rules considered to be domain names where every label follows the rules
skipping to change at page 7, line 33 skipping to change at page 10, line 7
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". (This definition is definitely not the same as "the
response one gets to a query for QTYPE=ANY", which is an response one gets to a query for QTYPE=ANY", which is an
unfortunate misunderstanding.) unfortunate misunderstanding.)
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
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."
([RFC1035], Section 5.)
Presentation format: The text format used in master files. This
format is shown but not formally defined in [RFC1034] and
[RFC1035]. The term "presentation format" first appears in
[RFC4034].
EDNS: The extension mechanisms for DNS, defined in [RFC6891]. EDNS: The extension mechanisms for DNS, defined in [RFC6891].
Sometimes called "EDNS0" or "EDNS(0)" to indicate the version Sometimes called "EDNS0" or "EDNS(0)" to indicate the version
number. EDNS allows DNS clients and servers to specify message number. EDNS allows DNS clients and servers to specify message
sizes larger than the original 512 octet limit, to expand the sizes larger than the original 512 octet limit, to expand the
response code space, and potentially to carry additional options response code space, and potentially to carry additional options
that affect the handling of a DNS query. that affect the handling of a DNS query.
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],
skipping to change at page 20, line 47 skipping to change at page 23, line 29
(Adapted from [RFC7129], Section 5.1) (Adapted from [RFC7129], Section 5.1)
Zone enumeration: "The practice of discovering the full content of a Zone enumeration: "The practice of discovering the full content of a
zone via successive queries." (Quoted from [RFC5155], zone via successive queries." (Quoted from [RFC5155],
Section 1.3.) This is also sometimes called "zone walking". Zone Section 1.3.) This is also sometimes called "zone walking". Zone
enumeration is different from zone content guessing where the enumeration is different from zone content guessing where the
guesser uses a large dictionary of possible labels and sends guesser uses a large dictionary of possible labels and sends
successive queries for them, or matches the contents of NSEC3 successive queries for them, or matches the contents of NSEC3
records against such a dictionary. records against such a dictionary.
Validation: Validation, in the context of DNSSEC, refers to the
following:
* Checking the validity of DNSSEC signatures
* Checking the validity of DNS responses, such as those including
authenticated denial of existence
* Building an authentication chain from a trust anchor to a DNS
response or individual DNS RRsets in a response
The first two definitions above consider the only validity of
individual DNSSEC components such as the RRSIG validity or NSEC
proof validity. The third definition considers the components of
the entire DNSSEC authentication chain, and thus requires
"configured knowledge of at least one authenticated DNSKEY or DS
RR" (as described in [RFC4035], Section 5).
[RFC4033], Section 2, says that a "Validating Security-Aware Stub
Resolver... performs signature validation" and uses a trust anchor
"as a starting point for building the authentication chain to a
signed DNS response", and thus uses the first and third
definitions above. The process of validating an RRSIG RR is
described in [RFC4035], Section 5.3.
[RFC5155] refers to validating responses throughout the document,
in the context of hashed authenticated denial of existence; this
uses the second definition above.
The terms "authentication" and "verification" are used
interchangeably with "validation" in the sense of the third
definition above. [RFC4033], Section 2, describes the chain
linking trust anchor to DNS data as the "authentication chain". A
response is considered to be authentic if "all RRsets in the
Answer and Authority sections of the response [are considered] to
be authentic" ([RFC4035]). DNS data or responses deemed to be
authentic or validated have a security status of "secure"
([RFC4035], Section 4.3; [RFC4033], Section 5). "Authenticating
both DNS keys and data is a matter of local policy, which may
extend or even override the [DNSSEC] protocol extensions"
([RFC4033], Section 3.1).
Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
RRset in a zone."(Quoted from [RFC6781], Section 3.1) RRset in a zone."(Quoted from [RFC6781], Section 3.1)
Zone signing key (ZSK): "DNSSEC keys that can be used to sign all Zone signing key (ZSK): "DNSSEC keys that can be used to sign all
the RRsets in a zone that require signatures, other than the apex the RRsets in a zone that require signatures, other than the apex
DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the
roles KSK and ZSK are not mutually exclusive: a single key can be roles KSK and ZSK are not mutually exclusive: a single key can be
both KSK and ZSK at the same time. Also note that a ZSK is both KSK and ZSK at the same time. Also note that a ZSK is
sometimes used to sign the apex DNSKEY RRset. sometimes used to sign the apex DNSKEY RRset.
skipping to change at page 27, line 29 skipping to change at page 30, line 29
[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, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
12.2. Informative References 12.2. Informative References
[DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2016, [DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2016,
<https://datatracker.ietf.org/wg/dbound/charter/>. <https://datatracker.ietf.org/wg/dbound/charter/>.
[RFC0799] Mills, D., "Internet name domains", RFC 799, [IANA_Resource_Registry]
DOI 10.17487/RFC0799, September 1981, Internet Assigned Numbers Authority, "Resource Record (RR)
<http://www.rfc-editor.org/info/rfc799>. TYPEs", 2017,
<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,
<http://www.rfc-editor.org/info/rfc819>. <http://www.rfc-editor.org/info/rfc819>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, DOI 10.17487/RFC0952, host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <http://www.rfc-editor.org/info/rfc952>. October 1985, <http://www.rfc-editor.org/info/rfc952>.
 End of changes. 14 change blocks. 
43 lines changed or deleted 215 lines changed or added

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