7. Registration Model
Registry: The administrative operation of a zone that allows
registration of names within that zone. People often use this
term to refer only to those organizations that perform
registration in large delegation-centric zones (such as TLDs); but
formally, whoever decides what data goes into a zone is the
registry for that zone. This definition of "registry" is from a
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
registry operator.
Registrant: An individual or organization on whose behalf a name in
a zone is registered by the registry. In many zones, the registry
and the registrant may be the same entity, but in TLDs they often
are not.
Registrar: A service provider that acts as a go-between for
registrants and registries. Not all registrations require a
registrar, though it is common to have registrars involved in
registrations in TLDs.
EPP: The Extensible Provisioning Protocol (EPP), which is commonly
used for communication of registration information between
registries and registrars. EPP is defined in [RFC5730].
WHOIS: A protocol specified in [RFC3912], often used for querying
registry databases. WHOIS data is frequently used to associate
registration data (such as zone management contacts) with domain
names. The term "WHOIS data" is often used as a synonym for the
registry database, even though that database may be served by
different protocols, particularly RDAP. The WHOIS protocol is
also used with IP address registry data.
RDAP: The Registration Data Access Protocol, defined in [RFC7480],
[RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The
RDAP protocol and data format are meant as a replacement for
WHOIS.
DNS operator: An entity responsible for running DNS servers. For a
zone's authoritative servers, the registrant may act as their own
DNS operator, or their registrar may do it on their behalf, or
they may use a third-party operator. For some zones, the registry
function is performed by the DNS operator plus other entities who
decide about the allowed contents of the zone.
8. General DNSSEC
Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
[RFC5155]. The terms that have caused confusion in the DNS community
are highlighted here.
DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
some RFCs, have not been formally defined. However, Section 2 of
[RFC4033] defines many types of resolvers and validators,
including "non-validating security-aware stub resolver", "non-
validating stub resolver", "security-aware name server",
"security-aware recursive name server", "security-aware resolver",
"security-aware stub resolver", and "security-oblivious
'anything'". (Note that the term "validating resolver", which is
used in some places in DNSSEC-related documents, is also not
defined.)
Signed zone: "A zone whose RRsets are signed and that contains
properly constructed DNSKEY, Resource Record Signature (RRSIG),
Next Secure (NSEC), and (optionally) DS records." (Quoted from
[RFC4033], Section 2.) It has been noted in other contexts that
the zone itself is not really signed, but all the relevant RRsets
in the zone are signed. Nevertheless, if a zone that should be
signed contains any RRsets that are not signed (or opted out),
those RRsets will be treated as bogus, so the whole zone needs to
be handled in some way.
It should also be noted that, since the publication of [RFC6840],
NSEC records are no longer required for signed zones: a signed
zone might include NSEC3 records instead. [RFC7129] provides
additional background commentary and some context for the NSEC and
NSEC3 mechanisms used by DNSSEC to provide authenticated denial-
of-existence responses.
Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that
is not signed". Section 2 of [RFC4035] defines this as "A zone
that does not include these records [properly constructed DNSKEY,
Resource Record Signature (RRSIG), Next Secure (NSEC), and
(optionally) DS records] according to the rules in this section".
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
unsigned: "If the resolver does not support any of the algorithms
listed in an authenticated DS RRset, then the resolver will not be
able to verify the authentication path to the child zone. In this
case, the resolver SHOULD treat the child zone as if it were
unsigned."
NSEC: "The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-
existence with the same mechanisms used to authenticate other DNS
replies." (Quoted from [RFC4033], Section 3.2.) In short, an
NSEC record provides authenticated denial of existence.
"The NSEC resource record lists two separate things: the next
owner name (in the canonical ordering of the zone) that contains
authoritative data or a delegation point NS RRset, and the set of
RR types present at the NSEC RR's owner name." (Quoted from
Section 4 of RFC 4034)
NSEC3: Like the NSEC record, the NSEC3 record also provides
authenticated denial of existence; however, NSEC3 records mitigate
against zone enumeration and support Opt-Out. NSEC3 resource
records are defined in [RFC5155].
Note that [RFC6840] says that [RFC5155] "is now considered part of
the DNS Security Document Family as described by Section 10 of
[RFC4033]". This means that some of the definitions from earlier
RFCs that only talk about NSEC records should probably be
considered to be talking about both NSEC and NSEC3.
Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.)
Opt-out tackles the high costs of securing a delegation to an
insecure zone. When using Opt-Out, names that are an insecure
delegation (and empty non-terminals that are only derived from
insecure delegations) don't require an NSEC3 record or its
corresponding RRSIG records. Opt-Out NSEC3 records are not able
to prove or deny the existence of the insecure delegations.
(Adapted from [RFC7129], Section 5.1)
Zone enumeration: "The practice of discovering the full content of a
zone via successive queries." (Quoted from [RFC5155],
Section 1.3.) This is also sometimes called "zone walking". Zone
enumeration is different from zone content guessing where the
guesser uses a large dictionary of possible labels and sends
successive queries for them, or matches the contents of NSEC3
records against such a dictionary.
Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
RRset in a zone."(Quoted from [RFC6781], Section 3.1)
Zone signing key (ZSK): "DNSSEC keys that can be used to sign all
the RRsets in a zone that require signatures, other than the apex
DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the
roles KSK and ZSK are not mutually exclusive: a single key can be
both KSK and ZSK at the same time. Also note that a ZSK is
sometimes used to sign the apex DNSKEY RRset.
Combined signing key (CSK): "In cases where the differentiation
between the KSK and ZSK is not made, i.e., where keys have the
role of both KSK and ZSK, we talk about a Single-Type Signing
Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes
called a "combined signing key" or CSK. It is operational
practice, not protocol, that determines whether a particular key
is a ZSK, a KSK, or a CSK.
Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be
used to distinguish between keys that are intended to be used as
the secure entry point into the zone when building chains of
trust, i.e., they are (to be) pointed to by parental DS RRs or
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
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
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
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
validation.
DNSSEC Policy (DP): A statement that "sets forth the security
requirements and standards to be implemented for a DNSSEC-signed
zone." (Quoted from [RFC6841], Section 2)
DNSSEC Practice Statement (DPS): "A practices disclosure document
that may support and be a supplemental document to the DNSSEC
Policy (if such exists), and it states how the management of a
given zone implements procedures and controls at a high level."
(Quoted from [RFC6841], Section 2)
9. DNSSEC States
A validating resolver can determine that a response is in one of four
states: secure, insecure, bogus, or indeterminate. These states are
defined in [RFC4033] and [RFC4035], although the two definitions
differ a bit. This document makes no effort to reconcile the two
definitions, and takes no position as to whether they need to be
reconciled.
Section 5 of [RFC4033] says:
A validating resolver can determine the following 4 states:
Secure: The validating resolver has a trust anchor, has a chain
of trust, and is able to verify all the signatures in the
response.
Insecure: The validating resolver has a trust anchor, a chain
of trust, and, at some delegation point, signed proof of the
non-existence of a DS record. This indicates that subsequent
branches in the tree are provably insecure. A validating
resolver may have a local policy to mark parts of the domain
space as insecure.
Bogus: The validating resolver has a trust anchor and a secure
delegation indicating that subsidiary data is signed, but
the response fails to validate for some reason: missing
signatures, expired signatures, signatures with unsupported
algorithms, data missing that the relevant NSEC RR says
should be present, and so forth.
Indeterminate: There is no trust anchor that would indicate that a
specific portion of the tree is secure. This is the default
operation mode.
Section 4.3 of [RFC4035] says:
A security-aware resolver must be able to distinguish between four
cases:
Secure: An RRset for which the resolver is able to build a chain
of signed DNSKEY and DS RRs from a trusted security anchor to
the RRset. In this case, the RRset should be signed and is
subject to signature validation, as described above.
Insecure: An RRset for which the resolver knows that it has no
chain of signed DNSKEY and DS RRs from any trusted starting
point to the RRset. This can occur when the target RRset lies
in an unsigned zone or in a descendent [sic] of an unsigned
zone. In this case, the RRset may or may not be signed, but
the resolver will not be able to verify the signature.
Bogus: An RRset for which the resolver believes that it ought to
be able to establish a chain of trust but for which it is
unable to do so, either due to signatures that for some reason
fail to validate or due to missing data that the relevant
DNSSEC RRs indicate should be present. This case may indicate
an attack but may also indicate a configuration error or some
form of data corruption.
Indeterminate: An RRset for which the resolver is not able to
determine whether the RRset should be signed, as the resolver
is not able to obtain the necessary DNSSEC RRs. This can occur
when the security-aware resolver is not able to contact
security-aware name servers for the relevant zones.
10. Security Considerations
These definitions do not change any security considerations for the
DNS.
11. References
11.1. Normative References
[RFC882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <http://www.rfc-editor.org/info/rfc1996>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
"Inventory and Analysis of WHOIS Registration Objects",
RFC 7485, DOI 10.17487/RFC7485, March 2015,
<http://www.rfc-editor.org/info/rfc7485>.
Acknowledgements
The authors gratefully acknowledge all of the authors of DNS-related
RFCs that proceed this one. Comments from Tony Finch, Stephane
Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
John Klensin, David Black, and many others in the DNSOP Working Group
have helped shape this document.
Authors' Addresses
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
Andrew Sullivan
Dyn
150 Dow Street, Tower 2
Manchester, NH 03101
United States
Email: asullivan@dyn.com
Kazunori Fujiwara
Japan Registry Services Co., Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Phone: +81 3 5215 8451
Email: fujiwara@jprs.co.jp
