mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-01 15:05:23 +00:00
Code Issues Releases Wiki Activity

3833: Threat Analysis of the Domain Name System (DNS)

Browse Source
This commit is contained in:
Mark Andrews
2004-08-25 00:53:36 +00:00
parent 326449ec24
commit d4cefad19e
2 changed files with 325 additions and 320 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/rfc/index
View File

@@ -90,4 +90,5 @@
Secret Key Transaction Authentication for DNS (GSS-TSIG) Secret Key Transaction Authentication for DNS (GSS-TSIG)
3655: Redefinition of DNS Authenticated Data (AD) bit 3655: Redefinition of DNS Authenticated Data (AD) bit
3658: Delegation Signer (DS) Resource Record (RR) 3658: Delegation Signer (DS) Resource Record (RR)
3833: Threat Analysis of the Domain Name System (DNS)
3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format 3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format

644
doc/draft/draft-ietf-dnsext-dns-threats-07.txt → doc/rfc/rfc3833.txt
View File

@@ -1,38 +1,27 @@
Network Working Group D. Atkins Network Working Group D. Atkins
draft-ietf-dnsext-dns-threats-07.txt IHTFP Consulting Request for Comments: 3833 IHTFP Consulting
R. Austein Category: Informational R. Austein
ISC ISC
April 2004 August 2004
Threat Analysis of the Domain Name System Threat Analysis of the Domain Name System (DNS)
Status of this Memo
Status of this document This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This document is an Internet-Draft and is in full conformance with Copyright Notice
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Copyright (C) The Internet Society (2004).
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>
The list of Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>
Distribution of this document is unlimited. Please send comments to
the Namedroppers mailing list <namedroppers@ops.ietf.org>.
Abstract Abstract
@@ -46,16 +35,6 @@ Abstract
doing so, attempts to measure to what extent (if any) DNSSEC is a doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats. useful tool in defending against these threats.
Atkins & Austein Expires 9 October 2004 [Page 1]
draft-ietf-dnsext-dns-threats-07.txt April 2004
1. Introduction 1. Introduction
The earliest organized work on DNSSEC within the IETF was an open The earliest organized work on DNSSEC within the IETF was an open
@@ -74,6 +53,13 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
authentication of DNS clients and servers as a basis for access authentication of DNS clients and servers as a basis for access
control, this work was also ruled out of scope for DNSSEC per se. 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 - Backwards compatibility and co-existence with "insecure DNS" was
listed as an explicit requirement. listed as an explicit requirement.
@@ -98,20 +84,12 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
While it may seem a bit strange to publish the threat analysis a While it may seem a bit strange to publish the threat analysis a
decade after starting work on the protocol designed to defend against decade after starting work on the protocol designed to defend against
it, that is nevertheless what this note attempts to do. Better late it, that is, nevertheless, what this note attempts to do. Better
than never. late than never.
This note assumes that the reader is familiar with both the DNS and 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. with DNSSEC, and does not attempt to provide a tutorial on either.
The DNS documents most relevant to the subject of this note are: The DNS documents most relevant to the subject of this note are:
Atkins & Austein Expires 9 October 2004 [Page 2]
draft-ietf-dnsext-dns-threats-07.txt April 2004
[RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
[RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
@@ -127,6 +105,17 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
as zone transfers and dynamic update requests), and perhaps should be as zone transfers and dynamic update requests), and perhaps should be
changed in a future revision of this note. changed in a future revision of this note.
Atkins & Austein Informational [Page 2]
RFC 3833 DNS Threat Analysis August 2004
2. Known Threats 2. Known Threats
There are several distinct classes of threats to the DNS, most of There are several distinct classes of threats to the DNS, most of
@@ -150,37 +139,39 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
may just be a means to an end for the attacker: the attacker might 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 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 reply message while using other parts of the message to set the stage
for something more complicated, for example, a name-based attack (see for something more complicated, for example, a name chaining attack
below). (see section 2.3).
While it certainly would be possible to sign DNS messages using a While it certainly would be possible to sign DNS messages using a
channel security mechanism such as TSIG or IPsec, or even to encrypt channel security mechanism such as TSIG or IPsec, or even to encrypt
them using IPsec, this would not be a very good solution. First, them using IPsec, this would not be a very good solution for
this approach would impose a fairly high processing cost per DNS interception attacks. First, this approach would impose a fairly
message, as well as a very high cost associated with establishing and high processing cost per DNS message, as well as a very high cost
maintaining bilateral trust relationships between all the parties associated with establishing and maintaining bilateral trust
that might be involved in resolving any particular query. For 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
Atkins & Austein Expires 9 October 2004 [Page 3] 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
draft-ietf-dnsext-dns-threats-07.txt April 2004 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).
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 By contrast, DNSSEC (when used properly) does provide an end-to-end
data integrity check, and is thus a much better solution for this data integrity check, and is thus a much better solution for this
class of problems during basic DNS lookup operations. 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 TSIG does have its place in corners of the DNS protocol where there's
a specific trust relationship between a particular client and a a specific trust relationship between a particular client and a
particular server, such as zone transfer, dynamic update, or a particular server, such as zone transfer, dynamic update, or a
@@ -216,14 +207,6 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
By itself, ID guessing is not enough to allow an attacker to inject By itself, ID guessing is not enough to allow an attacker to inject
bogus data, but combined with knowledge (or guesses) about QNAMEs and bogus data, but combined with knowledge (or guesses) about QNAMEs and
Atkins & Austein Expires 9 October 2004 [Page 4]
draft-ietf-dnsext-dns-threats-07.txt April 2004
QTYPEs for which a resolver might be querying, this leaves the QTYPEs for which a resolver might be querying, this leaves the
resolver only weakly defended against injection of bogus responses. resolver only weakly defended against injection of bogus responses.
@@ -234,6 +217,17 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
because the victim is responding (in a predictable way) to some third because the victim is responding (in a predictable way) to some third
party action known to the attacker. 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 This attack is both more and less difficult for the attacker than the
simple interception attack described above: more difficult, because simple interception attack described above: more difficult, because
the attack only works when the attacker guesses correctly; less the attack only works when the attacker guesses correctly; less
@@ -242,29 +236,29 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
In most other respects, this attack is similar to a packet In most other respects, this attack is similar to a packet
interception attack. A resolver that checks DNSSEC signatures will interception attack. A resolver that checks DNSSEC signatures will
be able to detect the forged response; resolvers that do not be able to detect the forged response; resolvers that do not perform
themselves perform DNSSEC signature checking should use TSIG or some DNSSEC signature checking themselves should use TSIG or some
equivalent mechanism to ensure the integrity of their communication equivalent mechanism to ensure the integrity of their communication
with a recursing name server that does perform DNSSEC signature with a recursive name server that does perform DNSSEC signature
checking. checking.
2.3. Name Chaining 2.3. Name Chaining
Perhaps the most interesting class of DNS-specific threats are the Perhaps the most interesting class of DNS-specific threats are the
name chaining attacks. These are a subset of a larger class of name- name chaining attacks. These are a subset of a larger class of
based attacks, sometimes called "cache poisoning" attacks. Most name-based attacks, sometimes called "cache poisoning" attacks. Most
name-based attacks can be at least partially mitigated by the long- name-based attacks can be partially mitigated by the long-standing
standing defense of checking RRs in response messages for relevance defense of checking RRs in response messages for relevance to the
to the original query, but such defenses do not catch name chaining original query, but such defenses do not catch name chaining attacks.
attacks. There are several variations on the basic attack, but what There are several variations on the basic attack, but what they all
they all have in common is that they all involve DNS RRs whose RDATA have in common is that they all involve DNS RRs whose RDATA portion
portion (right hand side) includes a DNS name (or, in a few cases, (right hand side) includes a DNS name (or, in a few cases, something
something that is not a DNS name but which directly maps to a DNS that is not a DNS name but which directly maps to a DNS name). Any
name). Any such RR is, at least in principle, a hook that lets an such RR is, at least in principle, a hook that lets an attacker feed
attacker feed bad data into a victim's cache, thus potentially bad data into a victim's cache, thus potentially subverting
subverting subsequent decisions based on DNS names. subsequent decisions based on DNS names.
The worst examples in this class of RRs are CNAME, NS, and DNAME RRs, 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 because they can redirect a victim's query to a location of the
attacker's choosing. RRs like MX and SRV are somewhat less attacker's choosing. RRs like MX and SRV are somewhat less
dangerous, but in principle they can also be used to trigger further dangerous, but in principle they can also be used to trigger further
@@ -272,14 +266,6 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
such as A or AAAA don't have DNS names in their RDATA, but since the 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 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 IPv4 and IPv6 addresses, these record types can also be used in a
Atkins & Austein Expires 9 October 2004 [Page 5]
draft-ietf-dnsext-dns-threats-07.txt April 2004
name chaining attack. name chaining attack.
The general form of a name chaining attack is something like this: The general form of a name chaining attack is something like this:
@@ -290,6 +276,14 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
using this query as a means to inject false information about some using this query as a means to inject false information about some
other name). other name).
Atkins & Austein Informational [Page 5]
RFC 3833 DNS Threat Analysis August 2004
- Attacker injects response, whether via packet interception, query - Attacker injects response, whether via packet interception, query
guessing, or by being a legitimate name server that's involved at guessing, or by being a legitimate name server that's involved at
some point in the process of answering the query that the victim some point in the process of answering the query that the victim
@@ -328,25 +322,27 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail 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 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 follow such a link, the result will be a DNS query for a name chosen
Atkins & Austein Expires 9 October 2004 [Page 6]
draft-ietf-dnsext-dns-threats-07.txt April 2004
by the attacker. by the attacker.
DNSSEC should provide a good defense against most (all?) variations DNSSEC should provide a good defense against most (all?) variations
on this class of attack. By checking signatures, a resolver can on this class of attack. By checking signatures, a resolver can
determine whether the data associated with a name really was inserted determine whether the data associated with a name really was inserted
by the delegated authority for that portion of the DNS name space by the delegated authority for that portion of the DNS name space.
(more precisely, a resolver can determine whether the entity that More precisely, a resolver can determine whether the entity that
injected the data had access to an allegedly secret key whose 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 corresponding public key appears at an expected location in the DNS
name space with an expected chain of parental signatures that start name space with an expected chain of parental signatures that start
with a public key of which the resolver has prior knowledge). with a public key of which the resolver has prior knowledge.
DNSSEC signatures do not cover glue records, so there's still a DNSSEC signatures do not cover glue records, so there's still a
possibility of a name chaining attack involving glue, but with DNSSEC possibility of a name chaining attack involving glue, but with DNSSEC
@@ -365,15 +361,16 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
PPP options. Besides accidental betrayal of this trust relationship PPP options. Besides accidental betrayal of this trust relationship
(via server bugs, successful server break-ins, etc), the server (via server bugs, successful server break-ins, etc), the server
itself may be configured to give back answers that are not what the 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 user would expect, whether in an honest attempt to help the user or
to further some other goal such as furthering a business partnership to promote some other goal such as furthering a business partnership
between the ISP and some third party). between the ISP and some third party.
This problem is particularly acute for frequent travelers who carry This problem is particularly acute for frequent travelers who carry
their own equipment and expect it to work in much the same way no their own equipment and expect it to work in much the same way
matter which network it's plugged into at any given moment (and no wherever they go. Such travelers need trustworthy DNS service
matter what brand of middle boxes a particular hotel chain might have without regard to who operates the network into which their equipment
installed when adding network drops in every guest room...). 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 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 choose a more trustworthy server, in practice this may not be an
@@ -384,14 +381,6 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
prevent the client host from being able to run an iterative resolver 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. 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 Thus, while the initial source of this problem is not a DNS protocol
Atkins & Austein Expires 9 October 2004 [Page 7]
draft-ietf-dnsext-dns-threats-07.txt April 2004
attack per se, this sort of betrayal is a threat to DNS clients, and 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 simply switching to a different recursive name server is not an
adequate defense. adequate defense.
@@ -399,6 +388,14 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
Viewed strictly from the DNS protocol standpoint, the only difference Viewed strictly from the DNS protocol standpoint, the only difference
between this sort of betrayal and a packet interception attack is between this sort of betrayal and a packet interception attack is
that in this case the client has voluntarily sent its request to the 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 attacker. The defense against this is the same as with a packet
interception attack: the resolver must either check DNSSEC signatures interception attack: the resolver must either check DNSSEC signatures
itself or use TSIG (or equivalent) to authenticate the server that it itself or use TSIG (or equivalent) to authenticate the server that it
@@ -413,8 +410,8 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
that is doing work on its behalf and wants to check the DNSSEC that is doing work on its behalf and wants to check the DNSSEC
signatures itself, the resolver really does need to have independent signatures itself, the resolver really does need to have independent
knowledge of the DNSSEC public key(s) it needs in order to perform knowledge of the DNSSEC public key(s) it needs in order to perform
the check (usually the public key for the root zone, but in some the check. Usually the public key for the root zone is enough, but
cases knowledge of additional keys may also be appropriate). in some cases knowledge of additional keys may also be appropriate.
It is difficult to escape the conclusion that a properly paranoid It is difficult to escape the conclusion that a properly paranoid
resolver must always perform its own signature checking, and that resolver must always perform its own signature checking, and that
@@ -440,27 +437,26 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
Much discussion has taken place over the question of authenticated Much discussion has taken place over the question of authenticated
denial of domain names. The particular question is whether there is denial of domain names. The particular question is whether there is
a requirement for authenticating the non-existence of a name. The a requirement for authenticating the non-existence of a name. The
Atkins & Austein Expires 9 October 2004 [Page 8]
draft-ietf-dnsext-dns-threats-07.txt April 2004
issue is whether the resolver should be able to detect when an issue is whether the resolver should be able to detect when an
attacker removes RRs from a response. attacker removes RRs from a response.
General paranoia aside, the existence of RR types whose absence General paranoia aside, the existence of RR types whose absence
causes an action other than immediate failure (such as missing MX and causes an action other than immediate failure (such as missing MX and
SRV RRs, which fail over to A RRs) constitutes a real threat. SRV RRs, which fail over to A RRs) constitutes a real threat.
Arguably, in some cases, even the immediate failure of a missing RR Arguably, in some cases, even the absence of an RR might be
might be 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 Atkins & Austein Informational [Page 8]
attack today. This implies that some mitigation of this risk is
required. 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 Note that it's necessary to prove the non-existence of applicable
wildcard RRs as part of the authenticated denial mechanism, and that, wildcard RRs as part of the authenticated denial mechanism, and that,
@@ -496,25 +492,27 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
applicable). applicable).
Note that this makes the wildcard mechanisms dependent upon the Note that this makes the wildcard mechanisms dependent upon the
Atkins & Austein Expires 9 October 2004 [Page 9]
draft-ietf-dnsext-dns-threats-07.txt April 2004
authenticated denial mechanism described in the previous section. authenticated denial mechanism described in the previous section.
DNSSEC includes mechanisms along the lines described above, which DNSSEC includes mechanisms along the lines described above, which
make it possible for a resolver to verify that a name server applied make it possible for a resolver to verify that a name server applied
the wildcard expansion rules correctly when generating an answer. 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 3. Weaknesses of DNSSEC
DNSSEC has some problems of its own: DNSSEC has some problems of its own:
- DNSSEC is complex to implement, and includes some nasty edge cases - DNSSEC is complex to implement and includes some nasty edge cases
at the zone cuts that require very careful coding. Testbed at the zone cuts that require very careful coding. Testbed
experience to date suggests that trivial zone configuration errors experience to date suggests that trivial zone configuration errors
or expired keys can cause serious problems for a DNSSEC-aware or expired keys can cause serious problems for a DNSSEC-aware
@@ -530,10 +528,10 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
and in some cases will also need to issue further queries. This and in some cases will also need to issue further queries. This
increased workload will also increase the time it takes to get an increased workload will also increase the time it takes to get an
answer back to the original DNS client, which is likely to trigger answer back to the original DNS client, which is likely to trigger
both timeouts and re-queries in some cases. (Arguably, many both timeouts and re-queries in some cases. Arguably, many current
current DNS clients are already too impatient even before taking DNS clients are already too impatient even before taking the
the further delays that DNSSEC will impose into account, but that's further delays that DNSSEC will impose into account, but that topic
a separate topic for another document....) is beyond the scope of this note.
- Like DNS itself, DNSSEC's trust model is almost totally - Like DNS itself, DNSSEC's trust model is almost totally
hierarchical. While DNSSEC does allow resolvers to have special hierarchical. While DNSSEC does allow resolvers to have special
@@ -552,20 +550,20 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
the validating resolver and the entity creating the DNSSEC the validating resolver and the entity creating the DNSSEC
signatures. Prior to DNSSEC, all time-related actions in DNS could signatures. Prior to DNSSEC, all time-related actions in DNS could
be performed by a machine that only knew about "elapsed" or be performed by a machine that only knew about "elapsed" or
Atkins & Austein Expires 9 October 2004 [Page 10]
draft-ietf-dnsext-dns-threats-07.txt April 2004
"relative" time. Because the validity period of a DNSSEC signature "relative" time. Because the validity period of a DNSSEC signature
is based on "absolute" time, a validating resolver must have the is based on "absolute" time, a validating resolver must have the
same concept of absolute time as the zone signer in order to same concept of absolute time as the zone signer in order to
determine whether the signature is within its validity period or determine whether the signature is within its validity period or
has expired. An attacker that can change a resolver's opinion of has expired. An attacker that can change a resolver's opinion of
the current absolute time can fool the resolver using expired 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 signatures. An attacker that can change the zone signer's opinion
of the current absolute time can fool the zone signer into of the current absolute time can fool the zone signer into
generating signatures whose validity period does not match what the generating signatures whose validity period does not match what the
@@ -578,24 +576,23 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
to whether the authenticated denial mechanism is completely to whether the authenticated denial mechanism is completely
airtight and whether it would be worthwhile to optimize the airtight and whether it would be worthwhile to optimize the
authenticated denial mechanism for the common case in which authenticated denial mechanism for the common case in which
wildcards are not present in a zone, but the main problem is just wildcards are not present in a zone. However, the main problem is
the inherent complexity of the wildcard mechanism itself. This just the inherent complexity of the wildcard mechanism itself.
complexity probably makes the code for generating and checking This complexity probably makes the code for generating and checking
authenticated denial attestations somewhat fragile, but since the authenticated denial attestations somewhat fragile, but since the
alternative of giving up wildcards entirely is not practical due to alternative of giving up wildcards entirely is not practical due to
widespread use, we are going to have to live with wildcards, and widespread use, we are going to have to live with wildcards. The
the question just becomes one of whether or not the proposed question just becomes one of whether or not the proposed
optimizations would make DNSSEC's mechanisms more or less fragile. optimizations would make DNSSEC's mechanisms more or less fragile.
- Even with DNSSEC, the class of attacks discussed in section 2.4 is - 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 not easy to defeat. In order for DNSSEC to be effective in this
case, it must be possible to configure the resolver to expect case, it must be possible to configure the resolver to expect
certain categories of DNS records to be signed, which may require certain categories of DNS records to be signed. This may require
manual configuration of the resolver, especially during the initial manual configuration of the resolver, especially during the initial
DNSSEC rollout period when the resolver cannot reasonably expect DNSSEC rollout period when the resolver cannot reasonably expect
the root and TLD zones to be signed. the root and TLD zones to be signed.
4. Topics for Future Work 4. Topics for Future Work
This section lists a few subjects not covered above which probably This section lists a few subjects not covered above which probably
@@ -604,17 +601,10 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
4.1. Interactions With Other Protocols 4.1. Interactions With Other Protocols
The above discussion has concentrated exclusively on attacks within The above discussion has concentrated exclusively on attacks within
the boundaries of the DNS protocol itself, since those are the the boundaries of the DNS protocol itself, since those are (some of)
problems against (some of) which DNSSEC was intended to protect. the problems against which DNSSEC was intended to protect. There
There are, however, other potential problems at the boundaries where are, however, other potential problems at the boundaries where DNS
DNS interacts with other protocols. interacts with other protocols.
Atkins & Austein Expires 9 October 2004 [Page 11]
draft-ietf-dnsext-dns-threats-07.txt April 2004
4.2. Securing DNS Dynamic Update 4.2. Securing DNS Dynamic Update
@@ -622,6 +612,14 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
with DNSSEC. Dynamic update of a non-secure zone can use TSIG to with DNSSEC. Dynamic update of a non-secure zone can use TSIG to
authenticate the updating client to the server. While TSIG does not authenticate the updating client to the server. While TSIG does not
scale very well (it requires manual configuration of shared keys 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 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 limited or closed environment such as a DHCP server updating a local
DNS name server. DNS name server.
@@ -634,10 +632,10 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
the changes to the zone. This means that either: the changes to the zone. This means that either:
a) The updating client must have access to a zone-signing key in 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 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 b) The DNS name server must have access to an online zone-signing key
in order to sign the update. in order to sign the update.
In either case, a zone-signing key must be available to create signed 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 RRsets to place in the updated zone. The fact that this key must be
@@ -661,17 +659,6 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
Scaling properties of the key management problem here are a Scaling properties of the key management problem here are a
particular concern that needs more study. particular concern that needs more study.
Atkins & Austein Expires 9 October 2004 [Page 12]
draft-ietf-dnsext-dns-threats-07.txt April 2004
4.3. Securing DNS Zone Replication 4.3. Securing DNS Zone Replication
As discussed in previous sections, DNSSEC per se attempts to provide As discussed in previous sections, DNSSEC per se attempts to provide
@@ -681,19 +668,27 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
protocol. For purposes of replicating entire DNS zones, however, protocol. For purposes of replicating entire DNS zones, however,
DNSSEC does not provide object security, because zones include DNSSEC does not provide object security, because zones include
unsigned NS RRs and glue at delegation points. Use of TSIG to 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 protect zone transfer (AXFR or IXFR) operations provides "channel
security", but still does not provide object security for complete security", but still does not provide object security for complete
zones, so the trust relationships involved in zone transfer are still zones. The trust relationships involved in zone transfer are still
very much a hop-by-hop matter of name server operators trusting other 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 name server operators rather than an end-to-end matter of name server
server operators trusting zone administrators. operators trusting zone administrators.
Zone object security was not an explicit design goal of DNSSEC, so Zone object security was not an explicit design goal of DNSSEC, so
failure to provide this service should not be a surprise. failure to provide this service should not be a surprise.
Nevertheless, there are some zone replication scenarios for which Nevertheless, there are some zone replication scenarios for which
this would be a very useful additional service, so this seems like a 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 useful area for future work. In theory it should not be difficult to
zone object security as a backwards compatible enhancement to the add zone object security as a backwards compatible enhancement to the
existing DNSSEC model, but the DNSEXT WG has not yet discussed either existing DNSSEC model, but the DNSEXT WG has not yet discussed either
the desirability of or the requirements for such an enhancement. the desirability of or the requirements for such an enhancement.
@@ -708,29 +703,38 @@ Security Considerations
The authors believe that deploying DNSSEC will help to address some, The authors believe that deploying DNSSEC will help to address some,
but not all, of the known threats to the DNS. but not all, of the known threats to the DNS.
IANA Considerations
None.
Acknowledgments Acknowledgments
This note is based both previous published works by others and on a This note is based both on previous published works by others and on
number of discussions both public and private over a period of many a number of discussions both public and private over a period of many
years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin, years, but particular thanks go to
Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ
Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten Jaap Akkerhuis,
Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other 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 Expires 9 October 2004 [Page 13] Atkins & Austein Informational [Page 13]
draft-ietf-dnsext-dns-threats-07.txt April 2004 RFC 3833 DNS Threat Analysis August 2004
members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
names and contributions the authors have forgotten, none of whom are groups whose names and contributions the authors have forgotten, none
responsible for what the authors did with their ideas. 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 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. that we are standing on the toes of those who have gone before us.
@@ -739,139 +743,144 @@ draft-ietf-dnsext-dns-threats-07.txt April 2004
Normative References Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and
RFC 1034, November 1987. facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., Editor, "Requirements for Internet Hosts - [RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October 1989. Application and Support", STD 3, RFC 1123, October 1989.
[RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification" RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for
(TSIG)" RFC 2845, May 2000. DNS (TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS
RFC 2930, September 2000. (TKEY RR)", RFC 2930, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update" RFC 3007, November 2000. 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
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
Informative References Informative References
[RFC3552] Rescorla, E., Korver, B., and the Internet Architecture [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Board, "Guidelines for Writing RFC Text on Security Text on Security Considerations", BCP 72, RFC 3552, July
Considerations", RFC 3552, July 2003. 2003.
Atkins & Austein Expires 9 October 2004 [Page 14]
draft-ietf-dnsext-dns-threats-07.txt April 2004
[Bellovin95] Bellovin, S., "Using the Domain Name System for System [Bellovin95] Bellovin, S., "Using the Domain Name System for System
Break-Ins", Proceedings of the Fifth Usenix Unix Security Break-Ins", Proceedings of the Fifth Usenix Unix
Symposium, June 1995. Security Symposium, June 1995.
[Galvin93] Design team meeting summary message posted to dns- [Galvin93] Design team meeting summary message posted to dns-
security@tis.com mailing list by Jim Galvin on 19 November 1993. security@tis.com mailing list by Jim Galvin on 19
November 1993.
[Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name
System Protocol", Master's thesis, Purdue University Department System Protocol", Master's thesis, Purdue University
of Computer Sciences, August 1993. Department of Computer Sciences, August 1993.
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995. the Fifth Usenix Unix Security Symposium, June 1995.
Authors' addresses: Authors' Addresses
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 Somerville, MA 02144
USA USA
Email: derek@ihtfp.com EMail: derek@ihtfp.com
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
Email: sra@isc.org Rob Austein
Intellectual Property Statement Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
The IETF takes no position regarding the validity or scope of any EMail: sra@isc.org
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
Atkins & Austein Expires 9 October 2004 [Page 15]
Atkins & Austein Informational [Page 15]
draft-ietf-dnsext-dns-threats-07.txt April 2004 RFC 3833 DNS Threat Analysis August 2004
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. 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 translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Intellectual Property
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an The IETF takes no position regarding the validity or scope of any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Intellectual Property Rights or other rights that might be claimed to
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING pertain to the implementation or use of the technology described in
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION this document or the extent to which any license under such rights
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF might or might not be available; nor does it represent that it has
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 Acknowledgement
@@ -886,10 +895,5 @@ Acknowledgement
Atkins & Austein Informational [Page 16]
Atkins & Austein Expires 9 October 2004 [Page 16]