900 lines
38 KiB
Plaintext
900 lines
38 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group D. Atkins
|
||
Request for Comments: 3833 IHTFP Consulting
|
||
Category: Informational R. Austein
|
||
ISC
|
||
August 2004
|
||
|
||
|
||
Threat Analysis of the Domain Name System (DNS)
|
||
|
||
Status of this Memo
|
||
|
||
This memo provides information for the Internet community. It does
|
||
not specify an Internet standard of any kind. Distribution of this
|
||
memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004).
|
||
|
||
Abstract
|
||
|
||
Although the DNS Security Extensions (DNSSEC) have been under
|
||
development for most of the last decade, the IETF has never written
|
||
down the specific set of threats against which DNSSEC is designed to
|
||
protect. Among other drawbacks, this cart-before-the-horse situation
|
||
has made it difficult to determine whether DNSSEC meets its design
|
||
goals, since its design goals are not well specified. 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.
|
||
|
||
1. Introduction
|
||
|
||
The earliest organized work on DNSSEC within the IETF was an open
|
||
design team meeting organized by members of the DNS working group in
|
||
November 1993 at the 28th IETF meeting in Houston. The broad
|
||
outlines of DNSSEC as we know it today are already clear in Jim
|
||
Galvin's summary of the results of that meeting [Galvin93]:
|
||
|
||
- While some participants in the meeting were interested in
|
||
protecting against disclosure of DNS data to unauthorized parties,
|
||
the design team made an explicit decision that "DNS data is
|
||
`public'", and ruled all threats of data disclosure explicitly out
|
||
of scope for DNSSEC.
|
||
|
||
- While some participants in the meeting were interested in
|
||
authentication of DNS clients and servers as a basis for access
|
||
control, this work was also ruled out of scope for DNSSEC per se.
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 1]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
- Backwards compatibility and co-existence with "insecure DNS" was
|
||
listed as an explicit requirement.
|
||
|
||
- The resulting list of desired security services was
|
||
1) data integrity, and
|
||
2) data origin authentication.
|
||
|
||
- The design team noted that a digital signature mechanism would
|
||
support the desired services.
|
||
|
||
While a number of detail decisions were yet to be made (and in some
|
||
cases remade after implementation experience) over the subsequent
|
||
decade, the basic model and design goals have remained fixed.
|
||
|
||
Nowhere, however, does any of the DNSSEC work attempt to specify in
|
||
any detail the sorts of attacks against which DNSSEC is intended to
|
||
protect, or the reasons behind the list of desired security services
|
||
that came out of the Houston meeting. For that, we have to go back
|
||
to a paper originally written by Steve Bellovin in 1990 but not
|
||
published until 1995, for reasons that Bellovin explained in the
|
||
paper's epilogue [Bellovin95].
|
||
|
||
While it may seem a bit strange to publish the threat analysis a
|
||
decade after starting work on the protocol designed to defend against
|
||
it, that is, nevertheless, what this note attempts to do. Better
|
||
late than never.
|
||
|
||
This note assumes that the reader is familiar with both the DNS and
|
||
with DNSSEC, and does not attempt to provide a tutorial on either.
|
||
The DNS documents most relevant to the subject of this note are:
|
||
[RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
|
||
[RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
|
||
|
||
For purposes of discussion, this note uses the term "DNSSEC" to refer
|
||
to the core hierarchical public key and signature mechanism specified
|
||
in the DNSSEC documents, and refers to TKEY and TSIG as separate
|
||
mechanisms, even though channel security mechanisms such as TKEY and
|
||
TSIG are also part of the larger problem of "securing DNS" and thus
|
||
are often considered part of the overall set of "DNS security
|
||
extensions". This is an arbitrary distinction that in part reflects
|
||
the way in which the protocol has evolved (introduction of a
|
||
putatively simpler channel security model for certain operations such
|
||
as zone transfers and dynamic update requests), and perhaps should be
|
||
changed in a future revision of this note.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 2]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
2. Known Threats
|
||
|
||
There are several distinct classes of threats to the DNS, most of
|
||
which are DNS-related instances of more general problems, but a few
|
||
of which are specific to peculiarities of the DNS protocol.
|
||
|
||
2.1. Packet Interception
|
||
|
||
Some of the simplest threats against DNS are various forms of packet
|
||
interception: monkey-in-the-middle attacks, eavesdropping on requests
|
||
combined with spoofed responses that beat the real response back to
|
||
the resolver, and so forth. In any of these scenarios, the attacker
|
||
can simply tell either party (usually the resolver) whatever it wants
|
||
that party to believe. While packet interception attacks are far
|
||
from unique to DNS, 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.
|
||
|
||
To further complicate things, the DNS query the attacker intercepts
|
||
may just be a means to an end for the attacker: the attacker might
|
||
even choose to return the correct result in the answer section of a
|
||
reply message while using other parts of the message to set the stage
|
||
for something more complicated, for example, a name chaining attack
|
||
(see section 2.3).
|
||
|
||
While it certainly would be possible to sign DNS messages using a
|
||
channel security mechanism such as TSIG or IPsec, or even to encrypt
|
||
them using IPsec, this would not be a very good solution for
|
||
interception attacks. First, this approach would impose a fairly
|
||
high processing cost per DNS message, as well as a very high cost
|
||
associated with establishing and maintaining bilateral trust
|
||
relationships between all the parties that might be involved in
|
||
resolving any particular query. For heavily used name servers (such
|
||
as the servers for the root zone), this cost would almost certainly
|
||
be prohibitively high. Even more important, however, is that the
|
||
underlying trust model in such a design would be wrong, since at best
|
||
it would only provide a hop-by-hop integrity check on DNS messages
|
||
and would not provide any sort of end-to-end integrity check between
|
||
the producer of DNS data (the zone administrator) and the consumer of
|
||
DNS data (the application that triggered the query).
|
||
|
||
By contrast, DNSSEC (when used properly) does provide an end-to-end
|
||
data integrity check, and is thus a much better solution for this
|
||
class of problems during basic DNS lookup operations.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 3]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
TSIG does have its place in corners of the DNS protocol where there's
|
||
a specific trust relationship between a particular client and a
|
||
particular server, such as zone transfer, dynamic update, or a
|
||
resolver (stub or otherwise) that is not going to check all the
|
||
DNSSEC signatures itself.
|
||
|
||
Note that DNSSEC does not provide any protection against modification
|
||
of the DNS message header, so any properly paranoid resolver must:
|
||
|
||
- Perform all of the DNSSEC signature checking on its own,
|
||
|
||
- Use TSIG (or some equivalent mechanism) to ensure the integrity of
|
||
its communication with whatever name servers it chooses to trust,
|
||
or
|
||
|
||
- Resign itself to the possibility of being attacked via packet
|
||
interception (and via other techniques discussed below).
|
||
|
||
2.2. ID Guessing and Query Prediction
|
||
|
||
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. The ID field in the DNS header is
|
||
only a 16-bit field and the server UDP port associated with DNS is a
|
||
well-known value, so there are only 2**32 possible combinations of ID
|
||
and client UDP port for a given client and server. This is not a
|
||
particularly large range, and is not sufficient to protect against a
|
||
brute force search; furthermore, in practice both the client UDP port
|
||
and the ID can often be predicted from previous traffic, and it is
|
||
not uncommon for the client port to be a known fixed value as well
|
||
(due to firewalls or other restrictions), thus frequently reducing
|
||
the search space to a range smaller than 2**16.
|
||
|
||
By itself, ID guessing is not enough to allow an attacker to inject
|
||
bogus data, but 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.
|
||
|
||
Since this attack relies on predicting a resolver's behavior, it's
|
||
most likely to be successful when the victim is in a known state,
|
||
whether because the victim rebooted recently, or because the victim's
|
||
behavior has been influenced by some other action by the attacker, or
|
||
because the victim is responding (in a predictable way) to some third
|
||
party action known to the attacker.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 4]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
This attack is both more and less difficult for the attacker than the
|
||
simple interception attack described above: more difficult, because
|
||
the attack only works when the attacker guesses correctly; less
|
||
difficult, because the attacker doesn't need to be on a transit or
|
||
shared network.
|
||
|
||
In most other respects, this attack is similar to a packet
|
||
interception attack. A resolver that checks DNSSEC signatures will
|
||
be able to detect the forged response; resolvers that do not perform
|
||
DNSSEC signature checking themselves should use TSIG or some
|
||
equivalent mechanism to ensure the integrity of their communication
|
||
with a recursive name server that does perform DNSSEC signature
|
||
checking.
|
||
|
||
2.3. Name Chaining
|
||
|
||
Perhaps the most interesting class of DNS-specific threats are the
|
||
name chaining attacks. These are a subset of a larger class of
|
||
name-based attacks, sometimes called "cache poisoning" attacks. Most
|
||
name-based attacks can be partially mitigated by the long-standing
|
||
defense of checking RRs in response messages for relevance to the
|
||
original query, but such defenses do not catch name chaining attacks.
|
||
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.
|
||
|
||
The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
|
||
because they can redirect a victim's query to a location of the
|
||
attacker's choosing. RRs like MX and SRV are somewhat less
|
||
dangerous, but in principle they can also be used to trigger further
|
||
lookups at a location of the attacker's choosing. Address RR types
|
||
such as A or AAAA don't have DNS names in their RDATA, but since the
|
||
IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
|
||
IPv4 and IPv6 addresses, these record types can also be used in a
|
||
name chaining attack.
|
||
|
||
The general form of a name chaining attack is something like this:
|
||
|
||
- Victim issues a query, perhaps at the instigation of the attacker
|
||
or some third party; in some cases the query itself may be
|
||
unrelated to the name under attack (that is, the attacker is just
|
||
using this query as a means to inject false information about some
|
||
other name).
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 5]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
- Attacker injects response, whether via packet interception, query
|
||
guessing, or by being a legitimate name server that's involved at
|
||
some point in the process of answering the query that the victim
|
||
issued.
|
||
|
||
- Attacker's response includes one or more RRs with DNS names in
|
||
their RDATA; depending on which particular form this attack takes,
|
||
the object may be to inject false data associated with those names
|
||
into the victim's cache via the Additional section of this
|
||
response, or may be to redirect the next stage of the query to a
|
||
server of the attacker's choosing (in order to inject more complex
|
||
lies into the victim's cache than will fit easily into a single
|
||
response, or in order to place the lies in the Authority or Answer
|
||
section of a response where they will have a better chance of
|
||
sneaking past a resolver's defenses).
|
||
|
||
Any attacker who can insert resource records into a victim's cache
|
||
can almost certainly do some kind of damage, so there are cache
|
||
poisoning attacks which are not name chaining attacks in the sense
|
||
discussed here. However, in the case of name chaining attacks, the
|
||
cause and effect relationship between the initial attack and the
|
||
eventual result may be significantly more complex than in the other
|
||
forms of cache poisoning, so name chaining attacks merit special
|
||
attention.
|
||
|
||
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.
|
||
|
||
This class of attack is particularly insidious given that it's quite
|
||
easy for an attacker to provoke a victim into querying for a
|
||
particular name of the attacker's choosing, for example, by embedding
|
||
a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
|
||
to the victim. If the victim's mail reading program attempts to
|
||
follow such a link, the result will be a DNS query for a name chosen
|
||
by the attacker.
|
||
|
||
DNSSEC should provide a good defense against most (all?) variations
|
||
on this class of attack. 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.
|
||
More precisely, a resolver can determine whether the entity that
|
||
injected the data had access to an allegedly secret key whose
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 6]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
corresponding public key appears at an expected location in the DNS
|
||
name space with an expected chain of parental signatures that start
|
||
with a public key of which the resolver has prior knowledge.
|
||
|
||
DNSSEC signatures do not cover glue records, so there's still a
|
||
possibility of a name chaining attack involving glue, but with DNSSEC
|
||
it is possible to detect the attack by temporarily accepting the glue
|
||
in order to fetch the signed authoritative version of the same data,
|
||
then checking the signatures on the authoritative version.
|
||
|
||
2.4. Betrayal By Trusted Server
|
||
|
||
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. Many client machines are only configured with stub
|
||
resolvers, and use trusted servers to perform all of their DNS
|
||
queries on their behalf. In many cases the trusted server is
|
||
furnished by the user's ISP and advertised to the client via DHCP or
|
||
PPP options. Besides accidental betrayal of this trust relationship
|
||
(via server bugs, successful server break-ins, etc), the server
|
||
itself may be configured to give back answers that are not what the
|
||
user would expect, whether in an honest attempt to help the user or
|
||
to promote some other goal such as furthering a business partnership
|
||
between the ISP and some third party.
|
||
|
||
This problem is particularly acute for frequent travelers who carry
|
||
their own equipment and expect it to work in much the same way
|
||
wherever they go. Such travelers need trustworthy DNS service
|
||
without regard to who operates the network into which their equipment
|
||
is currently plugged or what brand of middle boxes the local
|
||
infrastructure might use.
|
||
|
||
While the obvious solution to this problem would be for the client to
|
||
choose a more trustworthy server, in practice this may not be an
|
||
option for the client. In many network environments a client machine
|
||
has only a limited set of recursive name servers from which to
|
||
choose, and none of them may be particularly trustworthy. In extreme
|
||
cases, port filtering or other forms of packet interception may
|
||
prevent the client host from being able to run an iterative resolver
|
||
even if the owner of the client machine is willing and able to do so.
|
||
Thus, while the initial source of this problem is not a DNS protocol
|
||
attack per se, this sort of betrayal is a threat to DNS clients, and
|
||
simply switching to a different recursive name server is not an
|
||
adequate defense.
|
||
|
||
Viewed strictly from the DNS protocol standpoint, the only difference
|
||
between this sort of betrayal and a packet interception attack is
|
||
that in this case the client has voluntarily sent its request to the
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 7]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
attacker. The defense against this is the same as with a packet
|
||
interception attack: the resolver must either check DNSSEC signatures
|
||
itself or use TSIG (or equivalent) to authenticate the server that it
|
||
has chosen to trust. Note that use of TSIG does not by itself
|
||
guarantee that a name server is at all trustworthy: all TSIG can do
|
||
is help a resolver protect its communication with a name server that
|
||
it has already decided to trust for other reasons. Protecting a
|
||
resolver's communication with a server that's giving out bogus
|
||
answers is not particularly useful.
|
||
|
||
Also note that if the stub resolver does not trust the name server
|
||
that is doing work on its behalf and wants to check the DNSSEC
|
||
signatures itself, the resolver really does need to have independent
|
||
knowledge of the DNSSEC public key(s) it needs in order to perform
|
||
the check. Usually the public key for the root zone is enough, but
|
||
in some cases knowledge of additional keys may also be appropriate.
|
||
|
||
It is difficult to escape the conclusion that a properly paranoid
|
||
resolver must always perform its own signature checking, and that
|
||
this rule even applies to stub resolvers.
|
||
|
||
2.5. Denial of Service
|
||
|
||
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. DNSSEC does not help this, and may in fact make the
|
||
problem worse for resolvers that check signatures, since checking
|
||
signatures both increases the processing cost per DNS message and in
|
||
some cases can also increase the number of messages needed to answer
|
||
a query. TSIG (and similar mechanisms) have equivalent problems.
|
||
|
||
DNS servers are also at risk of being used as denial of service
|
||
amplifiers, since DNS response packets tend to be significantly
|
||
longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help
|
||
here either.
|
||
|
||
2.6. Authenticated Denial of Domain Names
|
||
|
||
Much discussion has taken place over the question of authenticated
|
||
denial of domain names. The particular question is whether there is
|
||
a requirement for authenticating the non-existence of a name. The
|
||
issue is whether the resolver should be able to detect when an
|
||
attacker removes RRs from a response.
|
||
|
||
General paranoia aside, the existence of RR types whose absence
|
||
causes an action other than immediate failure (such as missing MX and
|
||
SRV RRs, which fail over to A RRs) constitutes a real threat.
|
||
Arguably, in some cases, even the absence of an RR might be
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 8]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
considered a problem. The question remains: how serious is this
|
||
threat? Clearly the threat does exist; general paranoia says that
|
||
some day it'll be on the front page of some major newspaper, even if
|
||
we cannot conceive of a plausible scenario involving this attack
|
||
today. This implies that some mitigation of this risk is required.
|
||
|
||
Note that it's necessary to prove the non-existence of applicable
|
||
wildcard RRs as part of the authenticated denial mechanism, and that,
|
||
in a zone that is more than one label deep, such a proof may require
|
||
proving the non-existence of multiple discrete sets of wildcard RRs.
|
||
|
||
DNSSEC does include mechanisms which make it possible to determine
|
||
which authoritative names exist in a zone, and which authoritative
|
||
resource record types exist at those names. The DNSSEC protections
|
||
do not cover non-authoritative data such as glue records.
|
||
|
||
2.7. Wildcards
|
||
|
||
Much discussion has taken place over whether and how to provide data
|
||
integrity and data origin authentication for "wildcard" DNS names.
|
||
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.
|
||
|
||
In order to provide the desired services for wildcard RRs, we need to
|
||
do two things:
|
||
|
||
- We need a way to attest to the existence of the wildcard RR itself
|
||
(that is, we need to show that the synthesis rule exists), and
|
||
|
||
- We need a way to attest to the non-existence of any RRs which, if
|
||
they existed, would make the wildcard RR irrelevant according to
|
||
the synthesis rules that govern the way in which wildcard RRs are
|
||
used (that is, we need to show that the synthesis rule is
|
||
applicable).
|
||
|
||
Note that this makes the wildcard mechanisms dependent upon the
|
||
authenticated denial mechanism described in the previous section.
|
||
|
||
DNSSEC includes mechanisms along the lines described above, which
|
||
make it possible for a resolver to verify that a name server applied
|
||
the wildcard expansion rules correctly when generating an answer.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 9]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
3. Weaknesses of DNSSEC
|
||
|
||
DNSSEC has some problems of its own:
|
||
|
||
- DNSSEC is complex to implement and includes some nasty edge cases
|
||
at the zone cuts that require very careful coding. Testbed
|
||
experience to date suggests that trivial zone configuration errors
|
||
or expired keys can cause serious problems for a DNSSEC-aware
|
||
resolver, and that the current protocol's error reporting
|
||
capabilities may leave something to be desired.
|
||
|
||
- 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.
|
||
|
||
- DNSSEC answer validation increases the resolver's work load, since
|
||
a DNSSEC-aware resolver will need to perform signature validation
|
||
and in some cases will also need to issue further queries. This
|
||
increased workload will also increase the time it takes to get an
|
||
answer back to the original DNS client, which is likely to trigger
|
||
both timeouts and re-queries in some cases. Arguably, many current
|
||
DNS clients are already too impatient even before taking the
|
||
further delays that DNSSEC will impose into account, but that topic
|
||
is beyond the scope of this note.
|
||
|
||
- Like DNS itself, DNSSEC's trust model is almost totally
|
||
hierarchical. While DNSSEC does allow resolvers to have special
|
||
additional knowledge of public keys beyond those for the root, in
|
||
the general case the root key is the one that matters. Thus any
|
||
compromise in any of the zones between the root and a particular
|
||
target name can damage DNSSEC's ability to protect the integrity of
|
||
data owned by that target name. This is not a change, since
|
||
insecure DNS has the same model.
|
||
|
||
- Key rollover at the root is really hard. Work to date has not even
|
||
come close to adequately specifying how the root key rolls over, or
|
||
even how it's configured in the first place.
|
||
|
||
- DNSSEC creates a requirement of loose time synchronization between
|
||
the validating resolver and the entity creating the DNSSEC
|
||
signatures. Prior to DNSSEC, all time-related actions in DNS could
|
||
be performed by a machine that only knew about "elapsed" or
|
||
"relative" time. Because the validity period of a DNSSEC signature
|
||
is based on "absolute" time, a validating resolver must have the
|
||
same concept of absolute time as the zone signer in order to
|
||
determine whether the signature is within its validity period or
|
||
has expired. An attacker that can change a resolver's opinion of
|
||
the current absolute time can fool the resolver using expired
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 10]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
signatures. An attacker that can change the zone signer's opinion
|
||
of the current absolute time can fool the zone signer into
|
||
generating signatures whose validity period does not match what the
|
||
signer intended.
|
||
|
||
- The possible existence of wildcard RRs in a zone complicates the
|
||
authenticated denial mechanism considerably. For most of the
|
||
decade that DNSSEC has been under development these issues were
|
||
poorly understood. At various times there have been questions as
|
||
to whether the authenticated denial mechanism is completely
|
||
airtight and whether it would be worthwhile to optimize the
|
||
authenticated denial mechanism for the common case in which
|
||
wildcards are not present in a zone. However, the main problem is
|
||
just the inherent complexity of the wildcard mechanism itself.
|
||
This complexity probably makes the code for generating and checking
|
||
authenticated denial attestations somewhat fragile, but since the
|
||
alternative of giving up wildcards entirely is not practical due to
|
||
widespread use, we are going to have to live with wildcards. The
|
||
question just becomes one of whether or not the proposed
|
||
optimizations would make DNSSEC's mechanisms more or less fragile.
|
||
|
||
- Even with DNSSEC, the class of attacks discussed in section 2.4 is
|
||
not easy to defeat. In order for DNSSEC to be effective in this
|
||
case, it must be possible to configure the resolver to expect
|
||
certain categories of DNS records to be signed. This may require
|
||
manual configuration of the resolver, especially during the initial
|
||
DNSSEC rollout period when the resolver cannot reasonably expect
|
||
the root and TLD zones to be signed.
|
||
|
||
4. Topics for Future Work
|
||
|
||
This section lists a few subjects not covered above which probably
|
||
need additional study, additional mechanisms, or both.
|
||
|
||
4.1. Interactions With Other Protocols
|
||
|
||
The above discussion has concentrated exclusively on attacks within
|
||
the boundaries of the DNS protocol itself, since those are (some of)
|
||
the problems against which DNSSEC was intended to protect. There
|
||
are, however, other potential problems at the boundaries where DNS
|
||
interacts with other protocols.
|
||
|
||
4.2. Securing DNS Dynamic Update
|
||
|
||
DNS dynamic update opens a number of potential problems when combined
|
||
with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
|
||
authenticate the updating client to the server. While TSIG does not
|
||
scale very well (it requires manual configuration of shared keys
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 11]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
between the DNS name server and each TSIG client), it works well in a
|
||
limited or closed environment such as a DHCP server updating a local
|
||
DNS name server.
|
||
|
||
Major issues arise when trying to use dynamic update on a secure
|
||
zone. TSIG can similarly be used in a limited fashion to
|
||
authenticate the client to the server, but TSIG only protects DNS
|
||
transactions, not the actual data, and the TSIG is not inserted into
|
||
the DNS zone, so resolvers cannot use the TSIG as a way of verifying
|
||
the changes to the zone. This means that either:
|
||
|
||
a) The updating client must have access to a zone-signing key in
|
||
order to sign the update before sending it to the server, or
|
||
|
||
b) The DNS name server must have access to an online zone-signing key
|
||
in order to sign the update.
|
||
|
||
In either case, a zone-signing key must be available to create signed
|
||
RRsets to place in the updated zone. The fact that this key must be
|
||
online (or at least available) is a potential security risk.
|
||
|
||
Dynamic update also requires an update to the SERIAL field of the
|
||
zone's SOA RR. In theory, this could also be handled via either of
|
||
the above options, but in practice (a) would almost certainly be
|
||
extremely fragile, so (b) is the only workable mechanism.
|
||
|
||
There are other threats in terms of describing the policy of who can
|
||
make what changes to which RRsets in the zone. The current access
|
||
control scheme in Secure Dynamic Update is fairly limited. There is
|
||
no way to give fine-grained access to updating DNS zone information
|
||
to multiple entities, each of whom may require different kinds of
|
||
access. For example, Alice may need to be able to add new nodes to
|
||
the zone or change existing nodes, but not remove them; Bob may need
|
||
to be able to remove zones but not add them; Carol may need to be
|
||
able to add, remove, or modify nodes, but only A records.
|
||
|
||
Scaling properties of the key management problem here are a
|
||
particular concern that needs more study.
|
||
|
||
4.3. Securing DNS Zone Replication
|
||
|
||
As discussed in previous sections, DNSSEC per se attempts to provide
|
||
data integrity and data origin authentication services on top of the
|
||
normal DNS query protocol. Using the terminology discussed in
|
||
[RFC3552], DNSSEC provides "object security" for the normal DNS query
|
||
protocol. For purposes of replicating entire DNS zones, however,
|
||
DNSSEC does not provide object security, because zones include
|
||
unsigned NS RRs and glue at delegation points. Use of TSIG to
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 12]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
protect zone transfer (AXFR or IXFR) operations provides "channel
|
||
security", but still does not provide object security for complete
|
||
zones. The trust relationships involved in zone transfer are still
|
||
very much a hop-by-hop matter of name server operators trusting other
|
||
name server operators rather than an end-to-end matter of name server
|
||
operators trusting zone administrators.
|
||
|
||
Zone object security was not an explicit design goal of DNSSEC, so
|
||
failure to provide this service should not be a surprise.
|
||
Nevertheless, there are some zone replication scenarios for which
|
||
this would be a very useful additional service, so this seems like a
|
||
useful area for future work. In theory it should not be difficult to
|
||
add zone object security as a backwards compatible enhancement to the
|
||
existing DNSSEC model, but the DNSEXT WG has not yet discussed either
|
||
the desirability of or the requirements for such an enhancement.
|
||
|
||
5. Conclusion
|
||
|
||
Based on the above analysis, the DNSSEC extensions do appear to solve
|
||
a set of problems that do need to be solved, and are worth deploying.
|
||
|
||
Security Considerations
|
||
|
||
This entire document is about security considerations of the DNS.
|
||
The authors believe that deploying DNSSEC will help to address some,
|
||
but not all, of the known threats to the DNS.
|
||
|
||
Acknowledgments
|
||
|
||
This note is based both on previous published works by others and on
|
||
a number of discussions both public and private over a period of many
|
||
years, but particular thanks go to
|
||
|
||
Jaap Akkerhuis,
|
||
Steve Bellovin,
|
||
Dan Bernstein,
|
||
Randy Bush,
|
||
Steve Crocker,
|
||
Olafur Gudmundsson,
|
||
Russ Housley,
|
||
Rip Loomis,
|
||
Allison Mankin,
|
||
Paul Mockapetris,
|
||
Thomas Narten
|
||
Mans Nilsson,
|
||
Pekka Savola,
|
||
Paul Vixie,
|
||
Xunhua Wang,
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 13]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
|
||
groups whose names and contributions the authors have forgotten, none
|
||
of whom are responsible for what the authors did with their ideas.
|
||
|
||
As with any work of this nature, the authors of this note acknowledge
|
||
that we are standing on the toes of those who have gone before us.
|
||
Readers interested in this subject may also wish to read
|
||
[Bellovin95], [Schuba93], and [Vixie95].
|
||
|
||
Normative References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and
|
||
facilities", STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC1123] Braden, R., "Requirements for Internet Hosts -
|
||
Application and Support", STD 3, RFC 1123, October 1989.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
|
||
NCACHE)", RFC 2308, March 1998.
|
||
|
||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||
2671, August 1999.
|
||
|
||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
|
||
Wellington, "Secret Key Transaction Authentication for
|
||
DNS (TSIG)", RFC 2845, May 2000.
|
||
|
||
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
|
||
(TKEY RR)", RFC 2930, September 2000.
|
||
|
||
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||
Update", RFC 3007, November 2000.
|
||
|
||
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
|
||
Extensions", RFC 2535, March 1999.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 14]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
Informative References
|
||
|
||
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
|
||
Text on Security Considerations", BCP 72, RFC 3552, July
|
||
2003.
|
||
|
||
[Bellovin95] Bellovin, S., "Using the Domain Name System for System
|
||
Break-Ins", Proceedings of the Fifth Usenix Unix
|
||
Security Symposium, June 1995.
|
||
|
||
[Galvin93] Design team meeting summary message posted to dns-
|
||
security@tis.com mailing list by Jim Galvin on 19
|
||
November 1993.
|
||
|
||
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
|
||
System Protocol", Master's thesis, Purdue University
|
||
Department of Computer Sciences, August 1993.
|
||
|
||
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
|
||
the Fifth Usenix Unix Security Symposium, June 1995.
|
||
|
||
Authors' Addresses
|
||
|
||
Derek Atkins
|
||
IHTFP Consulting, Inc.
|
||
6 Farragut Ave
|
||
Somerville, MA 02144
|
||
USA
|
||
|
||
EMail: derek@ihtfp.com
|
||
|
||
|
||
Rob Austein
|
||
Internet Systems Consortium
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
USA
|
||
|
||
EMail: sra@isc.org
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 15]
|
||
|
||
RFC 3833 DNS Threat Analysis August 2004
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2004). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78, and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at ietf-
|
||
ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Atkins & Austein Informational [Page 16]
|
||
|