draft-ietf-dnsop-terminology-bis-00.txt   draft-ietf-dnsop-terminology-bis-01.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: July 15, 2016 K. Fujiwara Expires: January 9, 2017 K. Fujiwara
JPRS JPRS
January 12, 2016 July 8, 2016
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-00 draft-ietf-dnsop-terminology-bis-01
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.
This document will be the successor to RFC 7719. It will update many This document will be the successor to RFC 7719. It will update many
of the original RFCs. This first draft is essentially the same text of the original RFCs.
as RFC 7719 and is used as a baseline for creating diffs during the
document prepration process.
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 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 July 15, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . 6
4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 7 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 7
5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 9 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 9
6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Registration Model . . . . . . . . . . . . . . . . . . . . . 16 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 17
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 17 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 20 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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. The protocol
and message format are defined in [RFC1034] and [RFC1035]. These and message format are defined in [RFC1034] and [RFC1035]. These
RFCs defined some terms, but later documents defined others. Some of RFCs defined some terms, but later documents defined others. Some of
the terms from RFCs 1034 and 1035 now have somewhat different the terms from RFCs 1034 and 1035 now have somewhat different
meanings than they did in 1987. 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.
[[ The following two paragraphs will be majorly changed in future
versions of this draft as the DNSOP WG works on the document. ]]
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
as the one in an RFC, that RFC is quoted. Where the consensus as the one in an RFC, that RFC is quoted. Where the consensus
definition has changed somewhat, the RFC is mentioned but the new definition has changed somewhat, the RFC is mentioned but the new
stand-alone definition is given. stand-alone definition is given. During the progression of this
draft, it is expected that, where the consensus definition is
different than the RFC, the RFC will then be updated by this
document.
It is important to note that, during the development of this It is important to note that, during the development of this
document, it became clear that some DNS-related terms are interpreted document, it became clear that some DNS-related terms are interpreted
quite differently by different DNS experts. Further, some terms that quite differently by different DNS experts. Further, some terms that
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, the authors intend to follow this document with a Therefore, this document is a substantial revision to [RFC7719].
substantial revision in the not-distant future. That revision will
probably have more in-depth discussion of some terms as well as new
terms; it will also update some of the RFCs with new definitions.
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/. 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
skipping to change at page 4, line 7 skipping to change at page 4, line 5
Domain name: Section 3.1 of [RFC1034] talks of "the domain name Domain name: Section 3.1 of [RFC1034] talks of "the domain name
space" as a tree structure. "Each node has a label, which is zero space" as a tree structure. "Each node has a label, which is zero
to 63 octets in length. ... The domain name of a node is the list to 63 octets in length. ... The domain name of a node is the list
of the labels on the path from the node to the root of the tree. of the labels on the path from the node to the root of the tree.
... To simplify implementations, the total number of octets that ... To simplify implementations, the total number of octets that
represent a domain name (i.e., the sum of all label octets and 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 label lengths) is limited to 255." Any label in a domain name can
contain any octet value. contain any octet value.
The term "domain name" was defined before [RFC1034], most likely
in [RFC0799], which precedes the existence of the DNS. In this
document, domain names are only described in terms of the DNS.
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
skipping to change at page 6, line 30 skipping to change at page 6, line 32
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is its first 12 octets. Many of the The header of a DNS message is its first 12 octets. Many of the
fields and flags in the header diagram in Sections 4.1.1 through fields and flags in the header diagram in Sections 4.1.1 through
4.1.3 of [RFC1035] are referred to by their names in that diagram. 4.1.3 of [RFC1035] are referred to by their names in that diagram.
For example, the response codes are called "RCODEs", the data for a For example, the response codes are called "RCODEs", the data for a
record is called the "RDATA", and the authoritative answer bit is record is called the "RDATA", and the authoritative answer bit is
often called "the AA flag" or "the AA bit". often called "the AA flag" or "the AA bit".
Some of response codes that are defined in [RFC1035] have gotten Some of response codes that are defined in [RFC1035] have acquired
their own shorthand names. Some common response code names that their own shorthand names. Some common response code names that
appear without reference to the numeric value are "FORMERR", appear without reference to the numeric value are "FORMERR",
"SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to
as "Name Error"). All of the RCODEs are listed at as "Name Error"). All of the RCODEs are listed at
http://www.iana.org/assignments/dns-parameters, although that site http://www.iana.org/assignments/dns-parameters, although that site
uses mixed-case capitalization, while most documents use all-caps. uses mixed-case capitalization, while most documents use all-caps.
NODATA: "A pseudo RCODE which indicates that the name is valid for NODATA: "A pseudo RCODE which indicates that the name is valid for
the given class, but there are no records of the given type. A the given class, but there are no records of the given type. A
NODATA response has to be inferred from the answer." (Quoted from NODATA response has to be inferred from the answer." (Quoted from
skipping to change at page 16, line 8 skipping to change at page 16, line 15
term is used in [RFC4956] and [RFC5155], but is not defined there. term is used in [RFC4956] and [RFC5155], but is not defined there.
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. Special treatment is given to to be confusing to implementers. Special treatment is given to
RRs with owner names starting with the label "*". "Such RRs are RRs with owner names starting with the label "*". "Such RRs are
called 'wildcards'. Wildcard RRs can be thought of as called 'wildcards'. Wildcard RRs can be thought of as
instructions for synthesizing RRs." (Quoted from [RFC1034], instructions for synthesizing RRs." (Quoted from [RFC1034],
Section 4.3.3) For an extended discussion of wildcards, including Section 4.3.3) For an extended discussion of wildcards, including
clearer definitions, see [RFC4592]. clearer definitions, see [RFC4592].
Asterisk label: "The first octet is the normal label type and length
for a 1-octet-long label, and the second octet is the ASCII
representation for the '*' character. A descriptive name of a
label equaling that value is an 'asterisk label'." (Quoted from
[RFC4592], Section 2.1.1)
Wildcard domain name: "A 'wildcard domain name' is defined by having
its initial (i.e., leftmost or least significant) label be
asterisk label." (Quoted from [RFC4592], Section 2.1.1)
Closest encloser: "The longest existing ancestor of a name."
(Quoted from [RFC5155], Section 1.3) An earlier definition is "The
node in the zone's tree of existing domain names that has the most
labels matching the query name (consecutively, counting from the
root label downward). Each match is a 'label match' and the order
of the labels is the same." (Quoted from [RFC4592],
Section 3.3.1)
Closest provable encloser: "The longest ancestor of a name that can
be proven to exist. Note that this is only different from the
closest encloser in an Opt-Out zone." (Quoted from [RFC5155],
Section 1.3)
Next closer name: "The name one label longer than the closest
provable encloser of a name." (Quoted from [RFC5155],
Section 1.3)
Source of Synthesis: "The source of synthesis is defined in the
context of a query process as that wildcard domain name
immediately descending from the closest encloser, provided that
this wildcard domain name exists. 'Immediately descending' means
that the source of synthesis has a name of the form: >asterisk
label<.>closest encloser<." (Quoted from [RFC4592], Section 3.3.1)
Occluded name: "The addition of a delegation point via dynamic Occluded name: "The addition of a delegation point via dynamic
update will render all subordinate domain names to be in a limbo, update will render all subordinate domain names to be in a limbo,
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) It is often used to deliver malware. Because the
skipping to change at page 16, line 26 skipping to change at page 17, line 20
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) It is often used to deliver malware. Because the
addresses change so rapidly, it is difficult to ascertain all the addresses change so rapidly, it is difficult to ascertain all the
hosts. It should be noted that the technique also works with AAAA hosts. It should be noted that the technique also works with AAAA
records, but such use is not frequently observed on the Internet records, but such use is not frequently observed on the Internet
as of this writing. as of this writing.
Reverse DNS, reverse lookup: "The process of mapping an address to a
name is generally known as a 'reverse lookup', and the IN-
ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
DNS'." (Quoted from [RFC5855], Section 1)
Forward lookup: "Hostname-to-address translation". (Quoted from
[RFC2133], Section 6)
arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain
was originally established as part of the initial deployment of
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
reverse mapping domain. During 2000, the abbreviation was
redesignated to 'Address and Routing Parameter Area' in the hope
of reducing confusion with the earlier network name." (Quoted
from [RFC3172], Section 2.)
Infrastructure domain: A domain whose "role is to support the
operating infrastructure of the Internet". (Quoted from
[RFC3172], Section 2.)
Service name: "Service names are the unique key in the Service Name
and Transport Protocol Port Number registry. This unique symbolic
name for a service may also be used for other purposes, such as in
DNS SRV records." (Quoted from [RFC6335], Section 5.)
7. Registration Model 7. Registration Model
Registry: The administrative operation of a zone that allows Registry: The administrative operation of a zone that allows
registration of names within that zone. People often use this registration of names within that zone. People often use this
term to refer only to those organizations that perform term to refer only to those organizations that perform
registration in large delegation-centric zones (such as TLDs); but registration in large delegation-centric zones (such as TLDs); but
formally, whoever decides what data goes into a zone is the formally, whoever decides what data goes into a zone is the
registry for that zone. This definition of "registry" is from a registry for that zone. This definition of "registry" is from a
DNS point of view; for some zones, the policies that determine DNS point of view; for some zones, the policies that determine
what can go in the zone are decided by superior zones and not the what can go in the zone are decided by superior zones and not the
skipping to change at page 19, line 49 skipping to change at page 21, line 21
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 oginal defintion of SEPs was in [RFC3757]. That definition
clearly indicated that the SEP was a key, not just a bit in the
key. The abstract of [RFC3757] says: "With the Delegation Signer
(DS) resource record (RR), the concept of a public key acting as a
secure entry point (SEP) has been introduced. During exchanges of
public keys with the parent there is a need to differentiate SEP
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
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
definition from [RFC6781] is consistent with [RFC4034].
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 22, line 14 skipping to change at page 24, line 14
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, DOI 10.17487/ Application and Support", STD 3, RFC 1123,
RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>. <http://www.rfc-editor.org/info/rfc1123>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>. August 1996, <http://www.rfc-editor.org/info/rfc1996>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>. <http://www.rfc-editor.org/info/rfc2136>.
skipping to change at page 22, line 41 skipping to change at page 24, line 41
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182, and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
DOI 10.17487/RFC2182, July 1997, DOI 10.17487/RFC2182, July 1997,
<http://www.rfc-editor.org/info/rfc2182>. <http://www.rfc-editor.org/info/rfc2182>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<http://www.rfc-editor.org/info/rfc2308>. <http://www.rfc-editor.org/info/rfc2308>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
skipping to change at page 23, line 23 skipping to change at page 25, line 23
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<http://www.rfc-editor.org/info/rfc5155>. <http://www.rfc-editor.org/info/rfc5155>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<http://www.rfc-editor.org/info/rfc5730>. <http://www.rfc-editor.org/info/rfc5730>.
[RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
May 2010, <http://www.rfc-editor.org/info/rfc5855>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<http://www.rfc-editor.org/info/rfc5936>. <http://www.rfc-editor.org/info/rfc5936>.
[RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
"Recommendations for the Remediation of Bots in ISP "Recommendations for the Remediation of Bots in ISP
Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
<http://www.rfc-editor.org/info/rfc6561>. <http://www.rfc-editor.org/info/rfc6561>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://www.rfc-editor.org/info/rfc6672>. <http://www.rfc-editor.org/info/rfc6672>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, DOI 10.17487/ Operational Practices, Version 2", RFC 6781,
RFC6781, December 2012, DOI 10.17487/RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>. <http://www.rfc-editor.org/info/rfc6781>.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
Implementation Notes for DNS Security (DNSSEC)", RFC 6840, Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
DOI 10.17487/RFC6840, February 2013, DOI 10.17487/RFC6840, February 2013,
<http://www.rfc-editor.org/info/rfc6840>. <http://www.rfc-editor.org/info/rfc6840>.
[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<http://www.rfc-editor.org/info/rfc6841>. <http://www.rfc-editor.org/info/rfc6841>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ for DNS (EDNS(0))", STD 75, RFC 6891,
RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>. <http://www.rfc-editor.org/info/rfc6891>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DOI DNSSEC Delegation Trust Maintenance", RFC 7344,
10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>. <http://www.rfc-editor.org/info/rfc7344>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.
12.2. Informative References 12.2. Informative References
[DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2015, [DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2015,
<https://datatracker.ietf.org/wg/dbound/charter/>. <https://datatracker.ietf.org/wg/dbound/charter/>.
[RFC0799] Mills, D., "Internet name domains", RFC 799,
DOI 10.17487/RFC0799, September 1981,
<http://www.rfc-editor.org/info/rfc799>.
[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, DOI 10.17487/ Internet User Applications", RFC 819,
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>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, DOI 10.17487/RFC1995, August 1996,
<http://www.rfc-editor.org/info/rfc1995>. <http://www.rfc-editor.org/info/rfc1995>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
10.17487/RFC3912, September 2004, "Basic Socket Interface Extensions for IPv6", RFC 2133,
DOI 10.17487/RFC2133, April 1997,
<http://www.rfc-editor.org/info/rfc2133>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April
2004, <http://www.rfc-editor.org/info/rfc3757>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<http://www.rfc-editor.org/info/rfc3912>. <http://www.rfc-editor.org/info/rfc3912>.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, DOI 10.17487/RFC4641, September 2006, RFC 4641, DOI 10.17487/RFC4641, September 2006,
<http://www.rfc-editor.org/info/rfc4641>. <http://www.rfc-editor.org/info/rfc4641>.
[RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
October 2006, <http://www.rfc-editor.org/info/rfc4697>. October 2006, <http://www.rfc-editor.org/info/rfc4697>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>. December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
(DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
2007, <http://www.rfc-editor.org/info/rfc4956>. 2007, <http://www.rfc-editor.org/info/rfc4956>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>. <http://www.rfc-editor.org/info/rfc5625>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ Applications (IDNA): Protocol", RFC 5891,
RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>. <http://www.rfc-editor.org/info/rfc5891>.
[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)", Internationalized Domain Names for Applications (IDNA)",
RFC 5892, DOI 10.17487/RFC5892, August 2010, RFC 5892, DOI 10.17487/RFC5892, August 2010,
<http://www.rfc-editor.org/info/rfc5892>. <http://www.rfc-editor.org/info/rfc5892>.
[RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
for Internationalized Domain Names for Applications for Internationalized Domain Names for Applications
(IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
skipping to change at page 25, line 43 skipping to change at page 28, line 24
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
Encodings for Internationalized Domain Names", RFC 6055, Encodings for Internationalized Domain Names", RFC 6055,
DOI 10.17487/RFC6055, February 2011, DOI 10.17487/RFC6055, February 2011,
<http://www.rfc-editor.org/info/rfc6055>. <http://www.rfc-editor.org/info/rfc6055>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <http://www.rfc-editor.org/info/rfc6265>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://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, DOI Internationalization in the IETF", BCP 166, RFC 6365,
10.17487/RFC6365, September 2011, DOI 10.17487/RFC6365, September 2011,
<http://www.rfc-editor.org/info/rfc6365>. <http://www.rfc-editor.org/info/rfc6365>.
[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, <http://www.rfc-editor.org/info/rfc7129>. February 2014, <http://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, DOI Registration Data Access Protocol (RDAP)", RFC 7480,
10.17487/RFC7480, March 2015, DOI 10.17487/RFC7480, March 2015,
<http://www.rfc-editor.org/info/rfc7480>. <http://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
Registration Data Access Protocol (RDAP)", RFC 7481, DOI Registration Data Access Protocol (RDAP)", RFC 7481,
10.17487/RFC7481, March 2015, DOI 10.17487/RFC7481, March 2015,
<http://www.rfc-editor.org/info/rfc7481>. <http://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/ Protocol (RDAP) Query Format", RFC 7482,
RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015,
<http://www.rfc-editor.org/info/rfc7482>. <http://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
Registration Data Access Protocol (RDAP)", RFC 7483, DOI Registration Data Access Protocol (RDAP)", RFC 7483,
10.17487/RFC7483, March 2015, DOI 10.17487/RFC7483, March 2015,
<http://www.rfc-editor.org/info/rfc7483>. <http://www.rfc-editor.org/info/rfc7483>.
[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, <http://www.rfc-editor.org/info/rfc7484>. 2015, <http://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,
<http://www.rfc-editor.org/info/rfc7485>. <http://www.rfc-editor.org/info/rfc7485>.
skipping to change at page 26, line 45 skipping to change at page 29, line 35
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
have helped shape this document. helped shape RFC 7719.
Additional people contributed to this document, including: John
Dickinson [[ MORE NAMES WILL 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
Dyn Dyn
150 Dow Street, Tower 2 150 Dow Street, Tower 2
 End of changes. 34 change blocks. 
55 lines changed or deleted 164 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/