Request for Comments: 4033 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
DNS Security Introduction and Requirements
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
document introduces these extensions and describes their capabilities
and limitations. This document also discusses the services that the
DNS security extensions do and do not provide. Last, this document
describes the interrelationships between the documents that
collectively describe DNSSEC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
3. Services Provided by DNS Security . . . . . . . . . . . . . 7
3.1. Data Origin Authentication and Data Integrity . . . . 7
3.2. Authenticating Name and Type Non-Existence . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . 9
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . 18
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and its two companion documents ([RFC4034]
and [RFC4035]) update, clarify, and refine the security extensions
defined in [RFC2535] and its predecessors. These security extensions
consist of a set of new resource record types and modifications to
the existing DNS protocol ([RFC1035]). The new records and protocol
modifications are not fully described in this document, but are
described in a family of documents outlined in Section 10. Sections
3 and 4 describe the capabilities and limitations of the security
extensions in greater detail. Section 5 discusses the scope of the
document set. Sections 6, 7, 8, and 9 discuss the effect that these
security extensions will have on resolvers, stub resolvers, zones,
and name servers.
This document and its two companions obsolete [RFC2535], [RFC3008],
[RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
[RFC3845]. This document set also updates but does not obsolete
[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
[RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
DNSSEC.
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
distribution. These extensions do not provide confidentiality.
2. Definitions of Important DNSSEC Terms
This section defines a number of terms used in this document set.
Because this is intended to be useful as a reference while reading
the rest of the document set, first-time readers may wish to skim
this section quickly, read the rest of this document, and then come
back to this section.
Authentication Chain: An alternating sequence of DNS public key
(DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
signed data, with each link in the chain vouching for the next. A
DNSKEY RR is used to verify the signature covering a DS RR and
allows the DS RR to be authenticated. The DS RR contains a hash
of another DNSKEY RR and this new DNSKEY RR is authenticated by
matching the hash in the DS RR. This new DNSKEY RR in turn
authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
this set may be used to authenticate another DS RR, and so forth
until the chain finally ends with a DNSKEY RR whose corresponding
private key signs the desired DNS data. For example, the root
DNSKEY RRset can be used to authenticate the DS RRset for
"example." The "example." DS RRset contains a hash that matches
some "example." DNSKEY, and this DNSKEY’s corresponding private
key signs the "example." DNSKEY RRset. Private key counterparts
of the "example." DNSKEY RRset sign data records such as
"www.example." and DS RRs for delegations such as
"subzone.example."
Authentication Key: A public key that a security-aware resolver has
verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally configured to know about
at least one public key; this configured data is usually either
the public key itself or a hash of the public key as found in the
DS RR (see "trust anchor"). Second, the resolver may use an
authenticated public key to verify a DS RR and the DNSKEY RR to
which the DS RR refers. Third, the resolver may be able to
determine that a new public key has been signed by the private key
corresponding to another public key that the resolver has
verified. Note that the resolver must always be guided by local
policy when deciding whether to authenticate a new public key,
even if the local policy is simply to authenticate any new public
key for which the resolver is able verify the signature.
Authoritative RRset: Within the context of a particular zone, an
RRset is "authoritative" if and only if the owner name of the
RRset lies within the subset of the name space that is at or below
the zone apex and at or above the cuts that separate the zone from
its children, if any. All RRsets at the zone apex are
authoritative, except for certain RRsets at this domain name that,
if present, belong to this zone’s parent. These RRset could
include a DS RRset, the NSEC RRset referencing this DS RRset (the
"parental NSEC"), and RRSIG RRs associated with these RRsets, all
of which are authoritative in the parent zone. Similarly, if this
zone contains any delegation points, only the parental NSEC RRset,
DS RRsets, and any RRSIG RRs associated with these RRsets are
authoritative for this zone.
Delegation Point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example"
would be the foo.example node in the "example" zone (as opposed to
the zone apex of the "foo.example" zone). See also zone apex.
Island of Security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
parent. That is, there is no DS RR containing a hash of a DNSKEY
RR for the island in its delegating parent zone (see [RFC4034]).
An island of security is served by security-aware name servers and
may provide authentication chains to any delegated child zones.
Responses from an island of security or its descendents can only
be authenticated if its authentication keys can be authenticated
by some trusted means out of band from the DNS protocol.
Key Signing Key (KSK): An authentication key that corresponds to a
private key used to sign one or more other authentication keys for
a given zone. Typically, the private key corresponding to a key
signing key will sign a zone signing key, which in turn has a
corresponding private key that will sign other zone data. Local
policy may require that the zone signing key be changed
frequently, while the key signing key may have a longer validity
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. Key signing keys
are discussed in more detail in [RFC3757]. Also see zone signing
key.
Non-Validating Security-Aware Stub Resolver: A security-aware stub
resolver that trusts one or more security-aware recursive name
servers to perform most of the tasks discussed in this document
set on its behalf. In particular, a non-validating security-aware
stub resolver is an entity that sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server that will
provide these services on behalf of the security-aware stub
resolver. See also security-aware stub resolver, validating
security-aware stub resolver.
Non-Validating Stub Resolver: A less tedious term for a
non-validating security-aware stub resolver.
Security-Aware Name Server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) that understands the
DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity that
receives DNS queries, sends DNS responses, supports the EDNS0
([RFC2671]) message size extension and the DO bit ([RFC3225]), and
supports the RR types and message header bits defined in this
document set.
Security-Aware Recursive Name Server: An entity that acts in both the
security-aware name server and security-aware resolver roles. A
more cumbersome but equivalent phrase would be "a security-aware
name server that offers recursive service".
Security-Aware Resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) that understands the DNS
security extensions defined in this document set. In particular,
a security-aware resolver is an entity that sends DNS queries,
receives DNS responses, supports the EDNS0 ([RFC2671]) message
size extension and the DO bit ([RFC3225]), and is capable of using
the RR types and message header bits defined in this document set
to provide DNSSEC services.
Security-Aware Stub Resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) that has enough
of an understanding the DNS security extensions defined in this
document set to provide additional services not available from a
security-oblivious stub resolver. Security-aware stub resolvers
may be either "validating" or "non-validating", depending on
whether the stub resolver attempts to verify DNSSEC signatures on
its own or trusts a friendly security-aware name server to do so.
See also validating stub resolver, non-validating stub resolver.
Security-Oblivious <anything>: An <anything> that is not
"security-aware".
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.
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. In general, a validating resolver will have to
obtain the initial values of its trust anchors via some secure or
trusted means outside the DNS protocol. Presence of a trust
anchor also implies that the resolver should expect the zone to
which the trust anchor points to be signed.
Unsigned Zone: A zone that is not signed.
Validating Security-Aware Stub Resolver: A security-aware resolver
that sends queries in recursive mode but that performs signature
validation on its own rather than just blindly trusting an
upstream security-aware recursive name server. See also
security-aware stub resolver, non-validating security-aware stub
resolver.
Validating Stub Resolver: A less tedious term for a validating
security-aware stub resolver.
Zone Apex: Term used to describe the name at the child’s side of a
zone cut. See also delegation point.
Zone Signing Key (ZSK): An authentication key that corresponds to a
private key used to sign a zone. Typically, a zone signing key
will be part of the same DNSKEY RRset as the key signing key whose
corresponding private key signs this DNSKEY RRset, but the zone
signing key is used for a slightly different purpose and may
differ from the key signing key in other ways, such as validity
lifetime. Designating an authentication key as a zone signing key
is purely an operational issue; DNSSEC validation does not
distinguish between zone signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. See also key
signing key.
3. Services Provided by DNS Security
The Domain Name System (DNS) security extensions provide origin
authentication and integrity assurance services for DNS data,
including mechanisms for authenticated denial of existence of DNS
data. These mechanisms are described below.
These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types: Resource Record Signature (RRSIG),
DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
(NSEC). It also adds two new message header bits: Checking Disabled
(CD) and Authenticated Data (AD). In order to support the larger DNS
message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support
for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
security-aware resolver can indicate in its queries that it wishes to
receive DNSSEC RRs in response messages.
These services protect against most of the threats to the Domain Name
System described in [RFC3833]. Please see Section 12 for a
discussion of the limitations of these extensions.
3.1. Data Origin Authentication and Data Integrity
DNSSEC provides authentication by associating cryptographically
generated digital signatures with DNS RRsets. These digital
signatures are stored in a new resource record, the RRSIG record.
Typically, there will be a single private key that signs a zone’s
data, but multiple keys are possible. For example, there may be keys
for each of several different digital signature algorithms. If a
security-aware resolver reliably learns a zone’s public key, it can
authenticate that zone’s signed data. An important DNSSEC concept is
that the key that signs a zone’s data is associated with the zone
itself and not with the zone’s authoritative name servers. (Public
keys for DNS transaction authentication mechanisms may also appear in
zones, as described in [RFC2931], but DNSSEC itself is concerned with
object security of DNS data, not channel security of DNS
transactions. The keys associated with transaction security may be
stored in different RR types. See [RFC3755] for details.)
A security-aware resolver can learn a zone’s public key either by
having a trust anchor configured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new
type of resource record, the DNSKEY RR. Note that the private keys
used to sign zone data must be kept secure and should be stored
offline when practical. To discover a public key reliably via DNS
resolution, the target key itself has to be signed by either a
configured authentication key or another key that has been
authenticated previously. Security-aware resolvers authenticate zone
information by forming an authentication chain from a newly learned
public key back to a previously known authentication public key,
which in turn either has been configured into the resolver or must
have been learned and verified previously. Therefore, the resolver
must be configured with at least one trust anchor.
If the configured trust anchor is a zone signing key, then it will
authenticate the associated zone; if the configured key is a key
signing key, it will authenticate a zone signing key. If the
configured trust anchor is the hash of a key rather than the key
itself, the resolver may have to obtain the key via a DNS query. To
help security-aware resolvers establish this authentication chain,
security-aware name servers attempt to send the signature(s) needed
to authenticate a zone’s public key(s) in the DNS reply message along
with the public key itself, provided that there is space available in
the message.
The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across
organizational boundaries. The DS RRset resides at a delegation
point in a parent zone and indicates the public key(s) corresponding
to the private key(s) used to self-sign the DNSKEY RRset at the
delegated child zone’s apex. The administrator of the child zone, in
turn, uses the private key(s) corresponding to one or more of the
public keys in this DNSKEY RRset to sign the child zone’s data. The
typical authentication chain is therefore
DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
DS->DNSKEY subchains. DNSSEC permits more complex authentication
chains, such as additional layers of DNSKEY RRs signing other DNSKEY
RRs within a zone.
A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based
on configured knowledge of the public key for the root. Local
policy, however, may also allow a security-aware resolver to use one
or more configured public keys (or hashes of public keys) other than
the root public key, may not provide configured knowledge of the root
public key, or may prevent the resolver from using particular public
keys for arbitrary reasons, even if those public keys are properly
signed with verifiable signatures. DNSSEC provides mechanisms by
which a security-aware resolver can determine whether an RRset’s
signature is "valid" within the meaning of DNSSEC. In the final
analysis, however, authenticating both DNS keys and data is a matter
of local policy, which may extend or even override the protocol
extensions defined in this document set. See Section 5 for further
discussion.
3.2. Authenticating Name and Type Non-Existence
The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity
requires the use of another new resource record type, the NSEC
record. 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. Use
of NSEC records requires a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
the gaps, or "empty space", between domain names in a zone and list
the types of RRsets present at existing names. Each NSEC record is
signed and authenticated using the mechanisms described in Section
3.1.
4. Services Not Provided by DNS Security
DNS was originally designed with the assumptions that the DNS will
return the same answer to any given query regardless of who may have
issued the query, and that all data in the DNS is thus visible.
Accordingly, DNSSEC is not designed to provide confidentiality,
access control lists, or other means of differentiating between
inquirers.
DNSSEC provides no protection against denial of service attacks.
Security-aware resolvers and security-aware name servers are
vulnerable to an additional class of denial of service attacks based
on cryptographic operations. Please see Section 12 for details.
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update