draft-ietf-dnsop-terminology-bis-02.txt   draft-ietf-dnsop-terminology-bis-03.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: February 5, 2017 K. Fujiwara Expires: May 4, 2017 K. Fujiwara
JPRS JPRS
August 4, 2016 October 31, 2016
DNS Terminology DNS Terminology
draft-ietf-dnsop-terminology-bis-02 draft-ietf-dnsop-terminology-bis-03
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 February 5, 2017. This Internet-Draft will expire on May 4, 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . 17 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 18
8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 19
9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 22 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Definitions Updated by this Document . . . . . . . . 29 Appendix A. Definitions Updated by this Document . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 13, line 20 skipping to change at page 13, line 20
available for them at what times in the past. Passive DNS available for them at what times in the past. Passive DNS
databases allow searching of the stored records on keys other than databases allow searching of the stored records on keys other than
just the name, such as "find all names which have A records of a just the name, such as "find all names which have A records of a
particular value". particular value".
Anycast: "The practice of making a particular service address Anycast: "The practice of making a particular service address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations." datagrams sent are routed to one of several available locations."
(Quoted from [RFC4786], Section 2) (Quoted from [RFC4786], Section 2)
Split DNS: "Where a corporate network serves up partly or completely
different DNS inside and outside its firewall. There are many
possible variants on this; the basic point is that the
correspondence between a given FQDN (fully qualified domain name)
and a given IPv4 address is no longer universal and stable over
long periods." (Quoted from [RFC2775], Section 3.8)
6. Zones 6. Zones
This section defines terms that are used when discussing zones that This section defines terms that are used when discussing zones that
are being served or retrieved. are being served or retrieved.
Zone: "Authoritative information is organized into units called Zone: "Authoritative information is organized into units called
'zones', and these zones can be automatically distributed to the 'zones', and these zones can be automatically distributed to the
name servers which provide redundant service for the data in a name servers which provide redundant service for the data in a
zone." (Quoted from [RFC1034], Section 2.4) zone." (Quoted from [RFC1034], Section 2.4)
skipping to change at page 19, line 29 skipping to change at page 19, line 37
in the zone are signed. Nevertheless, if a zone that should be in the zone are signed. Nevertheless, if a zone that should be
signed contains any RRsets that are not signed (or opted out), signed contains any RRsets that are not signed (or opted out),
those RRsets will be treated as bogus, so the whole zone needs to those RRsets will be treated as bogus, so the whole zone needs to
be handled in some way. be handled in some way.
It should also be noted that, since the publication of [RFC6840], It should also be noted that, since the publication of [RFC6840],
NSEC records are no longer required for signed zones: a signed NSEC records are no longer required for signed zones: a signed
zone might include NSEC3 records instead. [RFC7129] provides zone might include NSEC3 records instead. [RFC7129] provides
additional background commentary and some context for the NSEC and additional background commentary and some context for the NSEC and
NSEC3 mechanisms used by DNSSEC to provide authenticated denial- NSEC3 mechanisms used by DNSSEC to provide authenticated denial-
of-existence responses. of-existence responses. NSEC and NSEC3 are described below.
Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that
is not signed". Section 2 of [RFC4035] defines this as "A zone is not signed". Section 2 of [RFC4035] defines this as "A zone
that does not include these records [properly constructed DNSKEY, that does not include these records [properly constructed DNSKEY,
Resource Record Signature (RRSIG), Next Secure (NSEC), and Resource Record Signature (RRSIG), Next Secure (NSEC), and
(optionally) DS records] according to the rules in this section". (optionally) DS records] according to the rules in this section".
There is an important note at the end of Section 5.2 of [RFC4035] There is an important note at the end of Section 5.2 of [RFC4035]
that defines an additional situation in which a zone is considered that defines an additional situation in which a zone is considered
unsigned: "If the resolver does not support any of the algorithms unsigned: "If the resolver does not support any of the algorithms
listed in an authenticated DS RRset, then the resolver will not be listed in an authenticated DS RRset, then the resolver will not be
skipping to change at page 20, line 9 skipping to change at page 20, line 19
NSEC record provides authenticated denial of existence. NSEC record provides authenticated denial of existence.
"The NSEC resource record lists two separate things: the next "The NSEC resource record lists two separate things: the next
owner name (in the canonical ordering of the zone) that contains owner name (in the canonical ordering of the zone) that contains
authoritative data or a delegation point NS RRset, and the set of authoritative data or a delegation point NS RRset, and the set of
RR types present at the NSEC RR's owner name." (Quoted from RR types present at the NSEC RR's owner name." (Quoted from
Section 4 of RFC 4034) Section 4 of RFC 4034)
NSEC3: Like the NSEC record, the NSEC3 record also provides NSEC3: Like the NSEC record, the NSEC3 record also provides
authenticated denial of existence; however, NSEC3 records mitigate authenticated denial of existence; however, NSEC3 records mitigate
against zone enumeration and support Opt-Out. NSEC3 resource against zone enumeration and support Opt-Out. NSEC resource
records are defined in [RFC5155]. records require associated NSEC3PARAM resource records. NSEC3 and
NSEC3PARAM resource records are defined in [RFC5155].
Note that [RFC6840] says that [RFC5155] "is now considered part of Note that [RFC6840] says that [RFC5155] "is now considered part of
the DNS Security Document Family as described by Section 10 of the DNS Security Document Family as described by Section 10 of
[RFC4033]". This means that some of the definitions from earlier [RFC4033]". This means that some of the definitions from earlier
RFCs that only talk about NSEC records should probably be RFCs that only talk about NSEC records should probably be
considered to be talking about both NSEC and NSEC3. considered to be talking about both NSEC and NSEC3.
Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.) unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.)
Opt-out tackles the high costs of securing a delegation to an Opt-out tackles the high costs of securing a delegation to an
skipping to change at page 22, line 5 skipping to change at page 22, line 11
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)
Hardware security module (HSM): A specialized piece of hardware that
is used to create keys for signatures and to sign messages. In
DNSSEC, HSMs are often used to hold the private keys for KSKs and
ZSKs and to create the RRSIG records at periodic intervals.
Signing software: Authoritative DNS servers that supports DNSSEC
often contains software that facilitates the creation and
maintenance of DNSSEC signatures in zones. There is also stand-
alone software that can be used to sign a zone regardless of
whether the authoritative server itself supports signing.
Sometimes signing software can support particular HSMs as part of
the signing process.
9. DNSSEC States 9. DNSSEC States
A validating resolver can determine that a response is in one of four A validating resolver can determine that a response is in one of four
states: secure, insecure, bogus, or indeterminate. These states are states: secure, insecure, bogus, or indeterminate. These states are
defined in [RFC4033] and [RFC4035], although the two definitions defined in [RFC4033] and [RFC4035], although the two definitions
differ a bit. This document makes no effort to reconcile the two differ a bit. This document makes no effort to reconcile the two
definitions, and takes no position as to whether they need to be definitions, and takes no position as to whether they need to be
reconciled. reconciled.
Section 5 of [RFC4033] says: Section 5 of [RFC4033] says:
skipping to change at page 27, line 5 skipping to change at page 28, line 5
[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>.
[RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2133, "Basic Socket Interface Extensions for IPv6", RFC 2133,
DOI 10.17487/RFC2133, April 1997, DOI 10.17487/RFC2133, April 1997,
<http://www.rfc-editor.org/info/rfc2133>. <http://www.rfc-editor.org/info/rfc2133>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000,
<http://www.rfc-editor.org/info/rfc2775>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
September 2001, <http://www.rfc-editor.org/info/rfc3172>. September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April
2004, <http://www.rfc-editor.org/info/rfc3757>. 2004, <http://www.rfc-editor.org/info/rfc3757>.
 End of changes. 11 change blocks. 
17 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/