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.
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.
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.
