draft-ietf-dnsop-dns-terminology-04.txt   draft-ietf-dnsop-dns-terminology-05.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Informational A. Sullivan Intended status: Informational A. Sullivan
Expires: March 3, 2016 Dyn Expires: March 27, 2016 Dyn
K. Fujiwara K. Fujiwara
JPRS JPRS
August 31, 2015 September 24, 2015
DNS Terminology DNS Terminology
draft-ietf-dnsop-dns-terminology-04 draft-ietf-dnsop-dns-terminology-05
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 38 skipping to change at page 1, line 38
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 March 3, 2016. This Internet-Draft will expire on March 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 42 skipping to change at page 2, line 42
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.
Most of the definitions here are believed to be the consensus Most of the definitions here are the consensus definition of the DNS
definition of the DNS community - both protocol developers and community - both protocol developers and operators. Some of the
operators. Some of the definitions differ from earlier RFCs, and definitions differ from earlier RFCs, and those differences are
those differences are noted. In this document, where the consensus noted. In this document, where the consensus definition is the same
definition is the same as the one in an RFC, that RFC is quoted. as the one in an RFC, that RFC is quoted. Where the consensus
Where the consensus definition has changed somewhat, the RFC is definition has changed somewhat, the RFC is mentioned but the new
mentioned but the new stand-alone definition is given. stand-alone definition is given.
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, the authors intend to follow this document with a
substantial revision in the not-distant future. That revision will substantial revision in the not-distant future. That revision will
probably have more in-depth discussion of some terms as well as new 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. terms; it will also update some of the RFCs with new definitions.
skipping to change at page 5, line 49 skipping to change at page 5, line 49
can only be determined by outside means. In fact, both a domain can only be determined by outside means. In fact, both a domain
and a subdomain of that domain can be public suffixes. At the and a subdomain of that domain can be public suffixes. At the
time this document is published, the IETF DBOUND Working Group time this document is published, the IETF DBOUND Working Group
[DBOUND] is dealing with issues concerning public suffixes. [DBOUND] is dealing with issues concerning public suffixes.
There is nothing inherent in a domain name to indicate whether it There is nothing inherent in a domain name to indicate whether it
is a public suffix. One resource for identifying public suffixes is a public suffix. One resource for identifying public suffixes
is the Public Suffix List (PSL) maintained by Mozilla is the Public Suffix List (PSL) maintained by Mozilla
(http://publicsuffix.org/). (http://publicsuffix.org/).
For example, at the time this document is published, the "au" TLD For example, at the time this document is published, the "com.au"
is not considered a public suffix, but the "com.au" domain is. domain is listed as a public suffix in the PSL. (Note that this
(Note that this example might change in the future.) example might change in the future.)
Note that the term "public suffix" is controversial in the DNS Note that the term "public suffix" is controversial in the DNS
community for many reasons, and may be significantly changed in community for many reasons, and may be significantly changed in
the future. One example of the difficulty of calling a domain a the future. One example of the difficulty of calling a domain a
public suffix is that designation can change over time as the public suffix is that designation can change over time as the
registration policy for the zone changes, such as the case of the registration policy for the zone changes, such as the case of the
"uk" TLD around the time this document is published. "uk" TLD around the time this document is published.
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is the first 12 octets. Many of the The header of a DNS message is the first 12 octets. Many of the
skipping to change at page 8, line 28 skipping to change at page 8, line 28
before it should be discarded". (Quoted from [RFC1035], section before it should be discarded". (Quoted from [RFC1035], section
4.1.3). Despite being defined for a resource record, the TTL of 4.1.3). Despite being defined for a resource record, the TTL of
every resource record in an RRset is required to be the same every resource record in an RRset is required to be the same
([RFC2181], section 5.2). ([RFC2181], section 5.2).
The reason that the TTL is the maximum time to live is that a The reason that the TTL is the maximum time to live is that a
cache operator might decide to shorten the time to live for cache operator might decide to shorten the time to live for
operational purposes, such as if there is a policy to not allow operational purposes, such as if there is a policy to not allow
TTL values over a certain number. Also, if a value is flushed TTL values over a certain number. Also, if a value is flushed
from the cache when its value is still positive, the value from the cache when its value is still positive, the value
effectively becomes zero. Some servers do not honor the TTL on an effectively becomes zero.
RRset from the authoritative servers, such as when the Some servers are known to ignore the TTL on some RRsets (such as
authoritative data has a very short TTL. when the authoritative data has a very short TTL) even though this
is against the advice in RFC 1035.
There is also the concept of a "default TTL" for a zone, which can There is also the concept of a "default TTL" for a zone, which can
be a configuration parameter in the server software. This is be a configuration parameter in the server software. This is
often expressed by a default for the entire server, and a default often expressed by a default for the entire server, and a default
for a zone using the $TTL directive in a zone file. The $TTL for a zone using the $TTL directive in a zone file. The $TTL
directive was added to the master file format by [RFC2308]. directive was added to the master file format by [RFC2308].
Class independent: A resource record type whose syntax and semantics Class independent: A resource record type whose syntax and semantics
are the same for every DNS class. A resource record type that is are the same for every DNS class. A resource record type that is
not class independent has different meanings depending on the DNS not class independent has different meanings depending on the DNS
skipping to change at page 17, line 23 skipping to change at page 17, line 23
they may use a third-party operator. For some zones, the registry they may use a third-party operator. For some zones, the registry
function is performed by the DNS operator plus other entities who function is performed by the DNS operator plus other entities who
decide about the allowed contents of the zone. decide about the allowed contents of the zone.
8. General DNSSEC 8. General DNSSEC
Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
[RFC5155]. The terms that have caused confusion in the DNS community [RFC5155]. The terms that have caused confusion in the DNS community
are highlighted here. are highlighted here.
DNSSEC-aware and DNSSEC-unaware: Section 2 of [RFC4033] defines many DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
types of resolvers and validators, including "non-validating some RFCs, have not been formally defined. However, Section 2 of
security-aware stub resolver", "non-validating stub resolver", [RFC4033] defines many types of resolvers and validators,
"security-aware name server", "security-aware recursive name including "non-validating security-aware stub resolver", "non-
server", "security-aware resolver", "security-aware stub validating stub resolver", "security-aware name server",
resolver", and "security-oblivious 'anything'". However, "DNSSEC- "security-aware recursive name server", "security-aware resolver",
aware" and "DNSSEC-unaware" are used in later RFCs, but never "security-aware stub resolver", and "security-oblivious
formally defined. (Note that the term "validating resolver", 'anything'". (Note that the term "validating resolver", which is
which is used in some places in those documents, is nevertheless used in some places in DNSSEC-related documents, is also not
not defined in that section.) defined.)
Signed zone: A zone whose RRsets are signed and that contains Signed zone: A zone whose RRsets are signed and that contains
properly constructed DNSKEY, Resource Record Signature (RRSIG), properly constructed DNSKEY, Resource Record Signature (RRSIG),
Next Secure (NSEC), and (optionally) DS records. (Quoted from Next Secure (NSEC), and (optionally) DS records. (Quoted from
[RFC4033], section 2.) It has been noted in other contexts that [RFC4033], section 2.) It has been noted in other contexts that
the zone itself is not really signed, but all the relevant RRsets the zone itself is not really signed, but all the relevant RRsets
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.
 End of changes. 8 change blocks. 
27 lines changed or deleted 28 lines changed or added

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