draft-ietf-dnsop-terminology-bis-01.txt   draft-ietf-dnsop-terminology-bis-02.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: January 9, 2017 K. Fujiwara Expires: February 5, 2017 K. Fujiwara
JPRS JPRS
July 8, 2016 August 4, 2016
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-01 draft-ietf-dnsop-terminology-bis-02
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.
of the original RFCs.
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 January 9, 2017. This Internet-Draft will expire on February 5, 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 22 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . 17 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 17
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 21 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Definitions Updated by this Document . . . . . . . . 29
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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.
skipping to change at page 2, line 51 skipping to change at page 3, line 4
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
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. During the progression of this stand-alone definition is given. See Appendix A for a list of the
draft, it is expected that, where the consensus definition is definitions that this document updates.
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, 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
skipping to change at page 10, line 21 skipping to change at page 10, line 16
Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this 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 term to mean a resolver that acts in recursive mode with a cache
(and meets other requirements). (and meets other requirements).
Priming: The mechanism used by a resolver to determine where to send Priming: The mechanism used by a resolver to determine where to send
queries before there is anything in the resolver's cache. Priming queries before there is anything in the resolver's cache. Priming
is most often done from a configuration setting that contains a is most often done from a configuration setting that contains a
list of authoritative servers for the root zone. list of authoritative servers for the root zone.
Root hints: "Operators who manage a DNS recursive resolver typically
need to configure a 'root hints file'. This file contains the
names and IP addresses of the authoritative name servers for the
root zone, so the software can bootstrap the DNS resolution
process. For many pieces of software, this list comes built into
the software." (Quoted from [IANA_RootFiles])
Negative caching: "The storage of knowledge that something does not Negative caching: "The storage of knowledge that something does not
exist, cannot give an answer, or does not give an answer." exist, cannot give an answer, or does not give an answer."
(Quoted from [RFC2308], Section 1) (Quoted from [RFC2308], Section 1)
Authoritative server: "A server that knows the content of a DNS zone Authoritative server: "A server that knows the content of a DNS zone
from local knowledge, and thus can answer queries about that zone from local knowledge, and thus can answer queries about that zone
without needing to query other servers." (Quoted from [RFC2182], without needing to query other servers." (Quoted from [RFC2182],
Section 2.) It is a system that responds to DNS queries with Section 2.) It is a system that responds to DNS queries with
information about zones for which it has been configured to answer information about zones for which it has been configured to answer
with the AA flag in the response header set to 1. It is a server with the AA flag in the response header set to 1. It is a server
skipping to change at page 16, line 46 skipping to change at page 16, line 46
Section 1.3) Section 1.3)
Next closer name: "The name one label longer than the closest Next closer name: "The name one label longer than the closest
provable encloser of a name." (Quoted from [RFC5155], provable encloser of a name." (Quoted from [RFC5155],
Section 1.3) Section 1.3)
Source of Synthesis: "The source of synthesis is defined in the Source of Synthesis: "The source of synthesis is defined in the
context of a query process as that wildcard domain name context of a query process as that wildcard domain name
immediately descending from the closest encloser, provided that immediately descending from the closest encloser, provided that
this wildcard domain name exists. 'Immediately descending' means this wildcard domain name exists. 'Immediately descending' means
that the source of synthesis has a name of the form: >asterisk that the source of synthesis has a name of the form: <asterisk
label<.>closest encloser<." (Quoted from [RFC4592], Section 3.3.1) 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 21, line 21 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 The original defintion 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.
A validating security-aware resolver uses this public key or hash
as a starting point for building the authentication chain to a
signed DNS response." (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 23, line 47 skipping to change at page 23, line 47
DNS. DNS.
11. IANA Considerations 11. IANA Considerations
None. None.
12. References 12. References
12.1. Normative References 12.1. Normative References
[IANA_RootFiles]
Internet Assigned Numbers Authority, "IANA Root Files",
2016, <http://www.iana.org/domains/root/files>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>. <http://www.rfc-editor.org/info/rfc882>.
[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,
skipping to change at page 26, line 26 skipping to change at page 26, line 26
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 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 [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", 2015, [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, [RFC0799] Mills, D., "Internet name domains", RFC 799,
DOI 10.17487/RFC0799, September 1981, DOI 10.17487/RFC0799, September 1981,
<http://www.rfc-editor.org/info/rfc799>. <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, 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>.
skipping to change at page 29, line 24 skipping to change at page 29, line 24
[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>.
Appendix A. Definitions Updated by this Document
The following definitions from RFCs are updated by this document:
o Forwarder in [RFC2308]
o Secure Entry Point (SEP) in [RFC3757]
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: John Additional people contributed to this document, including: John
Dickinson [[ MORE NAMES WILL APPEAR HERE AS FOLKS CONTRIBUTE]]. Dickinson, Bob Harold, [[ 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
Manchester, NH 03101 Manchester, NH 03101
United States United States
Email: asullivan@dyn.com Email: asullivan@dyn.com
Kazunori Fujiwara Kazunori Fujiwara
Japan Registry Services Co., Ltd. Japan Registry Services Co., Ltd.
 End of changes. 19 change blocks. 
18 lines changed or deleted 42 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/