This document introduces DNS security extensions and describes the
document set that contains the new security records and DNS protocol
modifications. The extensions provide data origin authentication and
data integrity using digital signatures over resource record sets.
This section discusses the limitations of these extensions.
In order for a security-aware resolver to validate a DNS response,
all zones along the path from the trusted starting point to the zone
containing the response zones must be signed, and all name servers
and resolvers involved in the resolution process must be
security-aware, as defined in this document set. A security-aware
resolver cannot verify responses originating from an unsigned zone,
from a zone not served by a security-aware name server, or for any
DNS data that the resolver is only able to obtain through a recursive
name server that is not security-aware. If there is a break in the
authentication chain such that a security-aware resolver cannot
obtain and validate the authentication keys it needs, then the
security-aware resolver cannot validate the affected DNS data.
This document briefly discusses other methods of adding security to a
DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism such as TSIG ([RFC2845]) or
SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
per se.
A non-validating security-aware stub resolver, by definition, does
not perform DNSSEC signature validation on its own and thus is
vulnerable both to attacks on (and by) the security-aware recursive
name servers that perform these checks on its behalf and to attacks
on its communication with those security-aware recursive name
servers. Non-validating security-aware stub resolvers should use
some form of channel security to defend against the latter threat.
The only known defense against the former threat would be for the
security-aware stub resolver to perform its own signature validation,
at which point, again by definition, it would no longer be a
non-validating security-aware stub resolver.
DNSSEC does not protect against denial of service attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks
based on cryptographic operations against security-aware resolvers
and security-aware name servers, as an attacker can attempt to use
DNSSEC mechanisms to consume a victim's resources. This class of
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to
consume resources in a security-aware name server that supports DNS
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary.
Due to a deliberate design choice, DNSSEC does not provide
confidentiality.
DNSSEC introduces the ability for a hostile party to enumerate all
the names in a zone by following the NSEC chain. NSEC RRs assert
which names do not exist in a zone by linking from existing name to
existing name along a canonical ordering of all the names within a
zone. Thus, an attacker can query these NSEC RRs in sequence to
obtain all the names in a zone. Although this is not an attack on
the DNS itself, it could allow an attacker to map network hosts or
other resources by enumerating the contents of a zone.
DNSSEC introduces significant additional complexity to the DNS and
thus introduces many new opportunities for implementation bugs and
misconfigured zones. In particular, enabling DNSSEC signature
validation in a resolver may cause entire legitimate zones to become
effectively unreachable due to DNSSEC configuration errors or bugs.
DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent
zone) are not signed. This does not pose a problem when validating
the authentication chain, but it does mean that the non-authoritative
data itself is vulnerable to tampering during zone transfer
operations. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
used to protect zone transfer operations.
Please see [RFC4034] and [RFC4035] for additional security
considerations.
