Summary: The memo discusses the development and threats related to DNS Security Extensions (DNSSEC). It outlines the history, known threats (such as packet interception, denial of service attacks, and name chaining), weaknesses of DNSSEC, and the importance of end-to-end data integrity checks. DNSSEC aims to protect DNS data and provide authentication.
This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. (View Highlight)
the design team made an explicit decision that “DNS data is ‘public’” (View Highlight)
Backwards compatibility and co-existence with “insecure DNS” was listed as an explicit requirement. (View Highlight)
The resulting list of desired security services was 1) data integrity, and 2) data origin authentication. (View Highlight)
a digital signature mechanism would support the desired services (View Highlight)
Some of the simplest threats against DNS are various forms of packet interception: (View Highlight)
DNS’s usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network. (View Highlight)
New highlights added March 24, 2024 at 2:44 PM
DNSSEC (when used properly) does provide an end-to-end data integrity check, (View Highlight)
Since DNS is for the most part used over UDP/IP, it is relatively easy for an attacker to generate packets which will match the transport protocol parameters. (View Highlight)
combined with knowledge (or guesses) about QNAMEs and QTYPEs for which a resolver might be querying, this leaves the resolver only weakly defended against injection of bogus responses. (View Highlight)
There are several variations on the basic attack, but what they all have in common is that they all involve DNS RRs whose RDATA portion (right hand side) includes a DNS name (or, in a few cases, something that is not a DNS name but which directly maps to a DNS name). Any such RR is, at least in principle, a hook that lets an attacker feed bad data into a victim’s cache, thus potentially subverting subsequent decisions based on DNS names. (View Highlight)
The common thread in all of the name chaining attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker’s choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks. (View Highlight)
By checking signatures, a resolver can determine whether the data associated with a name really was inserted by the delegated authority for that portion of the DNS name space. (View Highlight)
Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent. (View Highlight)
As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks. (View Highlight)
Conceptually, RRs with wildcard names are patterns for synthesizing RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the unwary zone administrator, it’s clear that a number of sites make heavy use of wildcard RRs, particularly wildcard MX RRs. (View Highlight)
Testbed experience to date suggests that trivial zone configuration errors or expired keys can cause serious problems for a DNSSEC-aware resolver, (View Highlight)
DNSSEC significantly increases the size of DNS response packets; among other issues, this makes DNSSEC-aware DNS servers even more effective as denial of service amplifiers. (View Highlight)
Like DNS itself, DNSSEC’s trust model is almost totally hierarchical. (View Highlight)
The possible existence of wildcard RRs in a zone complicates the authenticated denial mechanism considerably. (View Highlight)
