mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2004-02-18 19:37:25 +00:00
parent 6c09e435c8
commit d8bc95509a
3 changed files with 1709 additions and 512 deletions
Download Patch File Download Diff File Expand all files Collapse all files

479
doc/draft/draft-ietf-dnsext-dns-threats-05.txt → doc/draft/draft-ietf-dnsext-dns-threats-06.txt
View File

@@ -1,16 +1,13 @@
Network Working Group D. Atkins
draft-ietf-dnsext-dns-threats-05.txt IHTFP Consulting
draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting
R. Austein
Grunchweather Associates
November 2003
ISC
February 2004
Threat Analysis Of The Domain Name System
Threat Analysis of the Domain Name System
Status of this document
@@ -54,9 +51,9 @@ Abstract
Atkins & Austein Expires 26 May 2004 [Page 1]
Atkins & Austein Expires 21 August 2004 [Page 1]
draft-ietf-dnsext-dns-threats-05.txt November 2003
draft-ietf-dnsext-dns-threats-06.txt February 2004
1. Introduction
@@ -106,25 +103,29 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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:
Atkins & Austein Expires 26 May 2004 [Page 2]
Atkins & Austein Expires 21 August 2004 [Page 2]
draft-ietf-dnsext-dns-threats-05.txt November 2003
draft-ietf-dnsext-dns-threats-06.txt February 2004
[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 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 transaction model for
certain operations), and perhaps should be changed in a future
revision of this note.
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.
2. Known Threats
@@ -147,33 +148,34 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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 chose 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
for something more complicated, for example, a name-based attack (see
below).
While it certainly would be possible to sign DNS messages using TSIG
or IPsec, or even to encrypt them using IPsec, this would not be a
very good solution. 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
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. 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
Atkins & Austein Expires 26 May 2004 [Page 3]
Atkins & Austein Expires 21 August 2004 [Page 3]
draft-ietf-dnsext-dns-threats-05.txt November 2003
draft-ietf-dnsext-dns-threats-06.txt February 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
data integrity check, and is thus a much better solution for this
@@ -190,7 +192,7 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
- Perform all of the DNSSEC signature checking on its own,
- Use TSIG (or some equivalent mechanism) to insure the integrity of
- Use TSIG (or some equivalent mechanism) to ensure the integrity of
its communication with whatever name servers it chooses to trust,
or
@@ -205,28 +207,28 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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 proof 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.
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
Atkins & Austein Expires 21 August 2004 [Page 4]
draft-ietf-dnsext-dns-threats-06.txt February 2004
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,
Atkins & Austein Expires 26 May 2004 [Page 4]
draft-ietf-dnsext-dns-threats-05.txt November 2003
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
@@ -242,7 +244,7 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
interception attack. A resolver that checks DNSSEC signatures will
be able to detect the forged response; resolvers that do not
themselves perform DNSSEC signature checking should use TSIG or some
equivalent mechanism to insure the integrity of their communication
equivalent mechanism to ensure the integrity of their communication
with a recursing name server that does perform DNSSEC signature
checking.
@@ -271,18 +273,18 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
using this query as a means to inject false information about some
other name).
Atkins & Austein Expires 21 August 2004 [Page 5]
draft-ietf-dnsext-dns-threats-06.txt February 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.
Atkins & Austein Expires 26 May 2004 [Page 5]
draft-ietf-dnsext-dns-threats-05.txt November 2003
- 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
@@ -326,19 +328,19 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
injected the data had access to an allegedly secret key whose
corresponding public key appears at an expected location in the DNS
name space with an expected chain of parental signatures that start
Atkins & Austein Expires 21 August 2004 [Page 6]
draft-ietf-dnsext-dns-threats-06.txt February 2004
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-based attack involving glue, but with DNSSEC it
is possible to detect the attack by temporarily accepting the glue in
Atkins & Austein Expires 26 May 2004 [Page 6]
draft-ietf-dnsext-dns-threats-05.txt November 2003
order to fetch the signed authoritative version of the same data,
then checking the signatures on the authoritative version.
@@ -364,17 +366,17 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
installed when adding network drops in every guest room...).
While the obvious solution to this problem would be for the client to
chose a more trustworthy server, in practice this may not be an
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 server from which to chose,
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.
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
@@ -382,27 +384,27 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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
Atkins & Austein Expires 21 August 2004 [Page 7]
draft-ietf-dnsext-dns-threats-06.txt February 2004
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
Atkins & Austein Expires 26 May 2004 [Page 7]
draft-ietf-dnsext-dns-threats-05.txt November 2003
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 to perform the check
(usually the public key for the root zone, but in some cases
knowledge of additional keys may also be appropriate).
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
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
@@ -438,22 +440,27 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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,
Atkins & Austein Expires 21 August 2004 [Page 8]
draft-ietf-dnsext-dns-threats-06.txt February 2004
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-existance of applicable
Atkins & Austein Expires 26 May 2004 [Page 8]
draft-ietf-dnsext-dns-threats-05.txt November 2003
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-existance of multiple discrete sets of wildcard RRs.
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
@@ -467,26 +474,36 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
heavy use of wildcard RRs, particularly wildcard MX RRs.
In order to provide the desired services for wildcard RRs, we need to
prove two things:
do two things:
- We need to prove the existance of the wildcard RR itself (that is,
we need to prove that the synthesis rule exists), and
- 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 to prove the non-existance of any RRs which, if they
existed, would make the wildcard RR irrelevant according to the
synthesis rules the way in which wildcards are used (that is, we
need to prove that the synthesis rule is applicable).
- 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 proof mechanism dependent upon the
Note that this makes the wildcard mechanisms dependent upon the
authenticated denial mechanism described in the previous section.
DNSSEC does include mechanisms by which it is possible to furnish
wildcard proofs along the lines described above.
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.
3. Weaknesses of DNSSEC
DNSSEC has some problems of its own:
Atkins & Austein Expires 21 August 2004 [Page 9]
draft-ietf-dnsext-dns-threats-06.txt February 2004
- 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
@@ -499,22 +516,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
effective as denial of service amplifiers.
- DNSSEC answer validation increases the resolver's work load, since
Atkins & Austein Expires 26 May 2004 [Page 9]
draft-ietf-dnsext-dns-threats-05.txt November 2003
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 will almost certainly
trigger both timeouts and re-queries. (Arguably, many current DNS
clients are already too impatient even before taking the further
delays that DNSSEC will impose into account, but that's a separate
topic for another document....)
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's
a separate topic for another document....)
- Like DNS itself, DNSSEC's trust model is almost totally
hierarchical. While DNSSEC does allow resolvers to have special
@@ -522,48 +531,58 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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 really a change, since
insecure DNS has essentially the same problem, but it's not good
either.
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 resolver and the host 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 resolver must have the same concept of absolute time 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 signatures. An attacker that can change the zone signer's
opinion of the current absolute time can fool the zone signer into
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
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 mechanism for wildcard proofs in DNSSEC is fairly painful. At
various times there have been questions as to whether the proof
mechanism is completely airtight and whether it would be worthwhile
to optimize the wildcard proof mechanism for the common case in
which wildcards do not exist, but the main problem is just the
inherent complexity of the wildcard mechanism itself. This
complexity probably makes the code for generating and checking
wildcard proofs 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, and the question
just becomes one of whether or not the proposed optimizations would
Atkins & Austein Expires 26 May 2004 [Page 10]
Atkins & Austein Expires 21 August 2004 [Page 10]
draft-ietf-dnsext-dns-threats-05.txt November 2003
draft-ietf-dnsext-dns-threats-06.txt February 2004
make DNSSEC's wildcard proof mechanisms more or less fragile.
- 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, but 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, and
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, which 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
@@ -589,6 +608,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
limited or closed environment such as a DHCP server updating a local
DNS name server.
Atkins & Austein Expires 21 August 2004 [Page 11]
draft-ietf-dnsext-dns-threats-06.txt February 2004
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
@@ -611,18 +638,10 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
the above options, but in practice (a) would almost certainly be
extremely fragile, so (b) is the only workable mechanism.
Atkins & Austein Expires 26 May 2004 [Page 11]
draft-ietf-dnsext-dns-threats-05.txt November 2003
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 find-grained access to updating DNS zone information
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
@@ -636,8 +655,8 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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 [SEC-
CONS], DNSSEC provides "object security" for the normal DNS query
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
@@ -645,6 +664,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
security", but still does not provide object security for complete
zones, so the trust relationships involved in zone transfer are still
very much a hop-by-hop matter of name server operators trusting other
Atkins & Austein Expires 21 August 2004 [Page 12]
draft-ietf-dnsext-dns-threats-06.txt February 2004
name server operators, rather than an end-to-end matter of name
server operators trusting zone administrators.
@@ -668,13 +695,6 @@ Security Considerations
The authors believe that deploying DNSSEC will help to address some,
but not all, of the known threats to the DNS.
Atkins & Austein Expires 26 May 2004 [Page 12]
draft-ietf-dnsext-dns-threats-05.txt November 2003
IANA Considerations
None.
@@ -684,56 +704,61 @@ Acknowledgments
This note is based both 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, Olafur Gudmundsson, Rip Loomis, Allison
Mankin, Paul Mockapetris, Mans Nilsson, Paul Vixie, Xunhua Wang, 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.
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, 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
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet
Hosts - Application and Support", RFC 1123, October 1989.
[DNS-CLARIFY] Elz, R., and R. Bush, "Clarifications to the DNS
Atkins & Austein Expires 21 August 2004 [Page 13]
draft-ietf-dnsext-dns-threats-06.txt February 2004
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987.
[RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", RFC 1123, October 1989.
[RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS
Specification" RFC 2181, July 1997.
[NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)"
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)"
RFC 2308, March 1998.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845,
May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)" RFC 2845, May 2000.
[TKEY] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" RFC
2930, September 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)"
RFC 2930, September 2000.
[SECURE-UPDATE] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update" RFC 3007, November 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update" RFC 3007, November 2000.
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
Atkins & Austein Expires 26 May 2004 [Page 13]
draft-ietf-dnsext-dns-threats-05.txt November 2003
Informative References
[SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture
[RFC3552] Rescorla, E., Korver, B., and the Internet Architecture
Board, "Guidelines for Writing RFC Text on Security
Considerations", RFC 3552, July 2003.
@@ -751,7 +776,15 @@ Informative References
[Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of
the Fifth Usenix Unix Security Symposium, June 1995.
Author's addresses:
Atkins & Austein Expires 21 August 2004 [Page 14]
draft-ietf-dnsext-dns-threats-06.txt February 2004
Authors' addresses:
Derek Atkins
IHTFP Consulting, Inc.
@@ -762,10 +795,12 @@ Author's addresses:
Email: derek@ihtfp.com
Rob Austein
Grunchweather Associates
Email: sra@hactrn.net
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
Email: sra@isc.org
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
@@ -779,14 +814,6 @@ Intellectual Property Statement
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
Atkins & Austein Expires 26 May 2004 [Page 14]
draft-ietf-dnsext-dns-threats-05.txt November 2003
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
@@ -805,6 +832,14 @@ Full Copyright Statement
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
Atkins & Austein Expires 21 August 2004 [Page 15]
draft-ietf-dnsext-dns-threats-06.txt February 2004
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
@@ -838,5 +873,23 @@ Acknowledgement
Atkins & Austein Expires 26 May 2004 [Page 15]
Atkins & Austein Expires 21 August 2004 [Page 16]

542
doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt → doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt
View File

@@ -2,7 +2,7 @@
DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: June 16, 2004 R. Austein
Expires: August 16, 2004 R. Austein
ISC
M. Larson
VeriSign
@@ -10,11 +10,11 @@ Expires: June 16, 2004 R. Austein
USC/ISI
S. Rose
NIST
December 17, 2003
February 16, 2004
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-08
draft-ietf-dnsext-dnssec-intro-09
Status of this Memo
@@ -36,15 +36,15 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2004.
This Internet-Draft will expire on August 16, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Domain Name System Security Extensions (DNSSEC) adds data origin
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the
@@ -52,9 +52,9 @@ Abstract
Arends, et al. Expires June 16, 2004 [Page 1]
Arends, et al. Expires August 16, 2004 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
Last, this document describes the interrelationships between the
@@ -75,15 +75,13 @@ Table of Contents
7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15
9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 15
9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . . 20
Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 24
@@ -108,9 +106,11 @@ Table of Contents
Arends, et al. Expires June 16, 2004 [Page 2]
Arends, et al. Expires August 16, 2004 [Page 2]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
1. Introduction
@@ -133,13 +133,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445
[RFC3445], as well as several works in progress: "Redefinition of the
AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver
Compatibility for Delegation Signer"
[I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer
Resource Record" [I-D.ietf-dnsext-delegation-signer]. This document
set also updates, but does not obsolete, RFCs 1034 [RFC1034], 1035
[RFC1035], 2136 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597
[RFC3597].
AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation
Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation
Signer Resource Record" [RFC3658]. This document set also updates,
but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
[RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597].
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
@@ -164,9 +162,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 3]
Arends, et al. Expires August 16, 2004 [Page 3]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
2. Definitions of Important DNSSEC Terms
@@ -178,36 +178,36 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
this section.
authentication chain: an alternating sequence of DNSKEY RRsets and DS
RRs forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to check the signature
covering a DS RR and allows the DS RR to be authenticated. The DS
RR contains a hash of another DNSKEY RR and this new DNSKEY RR is
authenticated by matching the hash in the DS RR. This new DNSKEY
RR in turn authenticates another DNSKEY RRset and, in turn, some
DNSKEY RR in this set may be used to authenticate another DS RR
and so forth until the chain finally ends with a DNSKEY RR which
signs the desired DNS data. For example, the root DNSKEY can be
used to authenticated the DS RR for "example." The "example." DS
RR contains a hash that matches some "example." DNSKEY and this
DNSKEY signs the "example." DNSKEY RRset. Private key
counterparts in the "example." DNSKEY RRset sign data records such
as "www.example." as well as DS RRs for delegations such as
"subzone.example."
RRsets forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to verify the
signature covering a DS RR and allows the DS RR to be
authenticated. The DS RR contains a hash of another DNSKEY RR and
this new DNSKEY RR is authenticated by matching the hash in the DS
RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
and, in turn, some DNSKEY RR in this set may be used to
authenticate another DS RR and so forth until the chain finally
ends with a DNSKEY RR which signs the desired DNS data. For
example, the root DNSKEY RRset can be used to authenticate the DS
RRset for "example." The "example." DS RRset contains a hash that
matches some "example." DNSKEY and this DNSKEY signs the
"example." DNSKEY RRset. Private key counterparts of the
"example." DNSKEY RRset sign data records such as "www.example."
as well as DS RRs for delegations such as "subzone.example."
authentication key: A public key which a security-aware resolver has
verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally preconfigured to know
about at least one public key. This preconfigured data is either
the public key itself, or a hash of the key as found in the DS RR.
Second, the resolver may use an authenticated public key to verify
a DS RR and its associated DNSKEY RR. Third, the resolver may be
able to determine that a new key has been signed by another key
which the resolver has verified. Note that the resolver must
always be guided by local policy when deciding whether to
authenticate a new key, even if the local policy is simply to
authenticate any new key for which the resolver is able verify the
signature.
about at least one public key. This preconfigured data is usually
either the public key itself or a hash of the key as found in the
DS RR. Second, the resolver may use an authenticated public key
to verify a DS RR and its associated DNSKEY RR. Third, the
resolver may be able to determine that a new key has been signed
by another key which the resolver has verified. Note that the
resolver must always be guided by local policy when deciding
whether to authenticate a new key, even if the local policy is
simply to authenticate any new key for which the resolver is able
verify the signature.
delegation point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example"
@@ -220,32 +220,46 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 4]
Arends, et al. Expires August 16, 2004 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
in its delegating parent zone (see
[I-D.ietf-dnsext-dnssec-records]). An island of security is served
by a security-aware nameserver and may provide authentication
chains to any delegated child zones. Responses from an island of
security or its descendents can only be validated if its zone key
can be obtained by some trusted means out of band from the DNS
protocol.
security or its descendents can only be authenticated if its zone
key can be authenticated by some trusted means out of band from
the DNS protocol.
key signing key: An authentication key which is used to sign one or
more other authentication keys. Typically, a key signing key will
sign a zone signing key, which in turn will sign other zone data.
Local policy may require the zone signing key to be changed
frequently, while the key signing key may have a longer validity
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
more other authentication keys for a given zone. Typically, a key
signing key will sign a zone signing key, which in turn will sign
other zone data. Local policy may require the zone signing key to
be changed frequently, while the key signing key may have a longer
validity period in order to provide a more stable secure entry
point into the zone. Designating an authentication key as a key
signing key is purely an operational issue: DNSSEC validation does
not distinguish between key signing keys and other DNSSEC
authentication keys. Key signing keys are discussed in more
detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone
signing key.
non-validating security-aware stub resolver: A security-aware stub
resolver which trusts one or more security-aware recursive name
servers to perform most of the tasks discussed in this document
set on its behalf. In particular, a non-validating security-aware
stub resolver is an entity which sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub
resolver. See also: security-aware stub resolver, validating
security-aware stub resolver.
non-validating stub resolver: A less tedious term for a
non-validating security-aware stub resolver.
security-aware name server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) which understands the
DNS security extensions defined in this document set. In
@@ -260,6 +274,13 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
A more cumbersome equivalent phrase would be "a security-aware
name server which offers recursive service".
Arends, et al. Expires August 16, 2004 [Page 5]
Internet-Draft DNSSEC Introduction and Requirements February 2004
security-aware resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular,
@@ -269,72 +290,51 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
types and message header bits defined in this document set to
provide DNSSEC services.
security-aware stub resolver: An entity acting in the role of a
resolver (defined in section 2.4 of [RFC1034]) which has at least
a minimal understanding the DNS security extensions defined in
this document set, but which trusts one or more security-aware
security-aware stub resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) which has enough
of an understanding the DNS security extensions defined in this
document set to provide additional services not available from a
security-oblivious stub resolver. Security-aware stub resolvers
may be either "validating" or "non-validating" depending on
whether the stub resolver attempts to verify DNSSEC signatures on
its own or trusts a friendly security-aware name server to do so.
See also: validating stub resolver, non-validating stub resolver.
Arends, et al. Expires June 16, 2004 [Page 5]
Internet-Draft DNSSEC Introduction and Requirements December 2003
recursive name servers to perform most of the tasks discussed in
this document set on its behalf. In particular, a security-aware
stub resolver is an entity which sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub
resolver. Note that the distinction between security-aware
resolvers and security-aware stub resolvers is different from the
distinction between iterative-mode and recursive-mode resolvers in
the base DNS specification: a particular security-aware resolver
may operate exclusively in recursive mode, but still perform its
own DNSSEC signature validity checks, while a security-aware stub
resolver does not, by definition.
security-oblivious (server or resolver): The opposite of
security-oblivious <anything>: An <anything> which is not
"security-aware".
signed zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records.
unsigned zone: The opposite of a "signed zone".
unsigned zone: A zone which is not signed.
validating security-aware stub resolver: A security-aware resolver
which operates sends queries in recursive mode but which performs
signature validation on its own rather than just blindly trusting
a friendly security-aware recursive name server. See also:
security-aware stub resolver, non-validating security-aware stub
resolver.
validating stub resolver: A less tedious term for a validating
security-aware stub resolver.
zone signing key: An authentication key which is used to sign a zone.
See key signing key, above. Typically a zone signing key will be
part of the same DNSKEY RRset as the key signing key which signs
it, but is used for a slightly different purpose and may differ
from the key signing key in other ways, such as validity lifetime.
Designating an authentication key as a zone signing key is purely
an operational issue: DNSSEC validation does not distinguish
between zone signing keys and other DNSSEC authentication keys.
See also: key signing key.
Arends, et al. Expires June 16, 2004 [Page 6]
Arends, et al. Expires August 16, 2004 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
3. Services Provided by DNS Security
@@ -381,16 +381,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by
either a preconfigured authentication key or another key that has
been authenticated previously. Security-aware resolvers authenticate
been authenticated previously. Security-aware resolvers authenticate
zone information by forming an authentication chain from a newly
learned public key back to a previously known authentication public
key, which in turn either must have been preconfigured into the
Arends, et al. Expires June 16, 2004 [Page 7]
Arends, et al. Expires August 16, 2004 [Page 7]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
resolver or must have been learned and verified previously.
@@ -412,9 +412,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
point in a parent zone and indicates the key or keys used by the
delegated child zone to self-sign the DNSKEY RRset at the child
zone's apex. The child zone, in turn, uses one or more of the keys
in this DNSKEY RRset to sign its zone data. The authentication chain
is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or
more DS->DNSKEY subchains.
in this DNSKEY RRset to sign its zone data. The typical
authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where
"*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more
complex authentication chains, such as additional layers of DNSKEY
RRs signing other DNSKEY RRs within a zone.
A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based
@@ -439,16 +441,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence
via the same mechanisms used to authenticate other DNS replies. Use
of NSEC records require a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
Arends, et al. Expires June 16, 2004 [Page 8]
Arends, et al. Expires August 16, 2004 [Page 8]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
of NSEC records requires a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
the gaps, or "empty space", between domain names in a zone, as well
as listing the types of RRsets present at existing names. Each NSEC
record is signed and authenticated using the mechanisms described in
@@ -498,11 +500,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 9]
Arends, et al. Expires August 16, 2004 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
4. Services Not Provided by DNS Security
@@ -520,10 +520,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
on cryptographic operations. Please see Section 11 for details.
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above extend no protection to
operations such as zone transfers and dynamic update [RFC3007].
Message authentication schemes described in [RFC2845] and [RFC2931]
address security operations that pertain to these transactions.
for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update
[RFC3007]. Message authentication schemes described in [RFC2845] and
[RFC2931] address security operations that pertain to these
transactions.
@@ -555,17 +556,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 10]
Arends, et al. Expires August 16, 2004 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
5. Resolver Considerations
A security-aware resolver needs to be able to perform cryptographic
functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithms. Security-aware resolvers must
mandatory-to-implement algorithm(s). Security-aware resolvers must
also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to
@@ -578,7 +578,7 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver
may not be able to operate in a secure mode. For example, if a
may not be capable of operating in a secure mode. For example, if a
security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or
@@ -612,9 +612,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 11]
Arends, et al. Expires August 16, 2004 [Page 11]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
6. Stub Resolver Considerations
@@ -657,10 +657,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers which it uses: it can
perform its own signature validation, by setting the Checking
Disabled (CD) bit in its query messages. Upon taking this step, the
resolver is no longer really a stub resolver at all anymore (in the
terminology used in this document set, anyway), and is now a
security-aware resolver with somewhat limited functionality.
Disabled (CD) bit in its query messages. A validating stub resolver
is thus able to treat the DNSSEC signatures as a trust relationship
between the zone administrator and the stub resolver itself.
@@ -668,9 +667,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 12]
Arends, et al. Expires August 16, 2004 [Page 12]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
7. Zone Considerations
@@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 13]
Arends, et al. Expires August 16, 2004 [Page 13]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
8. Name Server Considerations
@@ -735,10 +735,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message
size limitations. For this reason a security-aware name server must
support the EDNS mechanism size extension, since otherwise inclusion
of DNSSEC RRs could easily cause UDP message truncation and fallback
to TCP.
size limitations. Since inclusion of these DNSSEC RRs could easily
cause UDP message truncation and fallback to TCP, a security-aware
name server must also support the EDNS "sender's UDP payload"
mechanism.
If possible, the private half of each DNSSEC key pair should be kept
offline, but this will not be possible for a zone for which DNS
@@ -752,10 +752,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone
contains some unsigned data if the zone has any children, so zone
maintenance operations will require some additional mechanisms (most
likely some form of channel security, such as TSIG, SIG(0), or
IPsec).
contains some unsigned, nonauthoritative data if the zone has any
children, so zone maintenance operations will require some additional
mechanisms (most likely some form of channel security, such as TSIG,
SIG(0), or IPsec).
@@ -780,44 +780,15 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 14]
Arends, et al. Expires August 16, 2004 [Page 14]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
9. DNS Security Document Family
The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All of these documents are in turn under
the larger umbrella of the DNS base protocol documents.
9.1 DNS Security Document Roadmap
+----------------------------------+
| Base DNS Protocol Documents |
| [RFC1035, RFC2181, et sequentia] |
+----------------------------------+
|
|
+-----------+ +----------+
| DNSSEC | | New |
| Protocol |--------->| Security |
| Documents | | Uses |
+-----------+ +----------+
|
|
+---------------- - - - - - - -+
| .
| .
+------------------+ .
| Digital | +------------------+
| Signature | | Transaction |
| Algorithm | | Authentication |
| Implementations | | Implementations |
+------------------+ +------------------+
9.2 Categories of DNS Security Documents
The DNSSEC document set can be partitioned into several main groups,
under the larger umbrella of the DNS base protocol documents.
The "DNSSEC protocol document set" refers to the three documents
which form the core of the DNS security extensions:
@@ -830,22 +801,14 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
3. Protocol Modifications for the DNS Security Extensions
[I-D.ietf-dnsext-dnssec-protocol]
The "Digital Signature Algorithm Implementations" document set refers
The "Digital Signature Algorithm Specification" document set refers
to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource
Arends, et al. Expires June 16, 2004 [Page 15]
Internet-Draft DNSSEC Introduction and Requirements December 2003
record format. Each of these documents deals with a specific digital
signature algorithm.
The "Transaction Authentication Implementations" document set refers
to the group of documents that deal with DNS message authentication,
The "Transaction Authentication Protocol" document set refers to the
group of documents that deal with DNS message authentication,
including secret key establishment and verification. While not
strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted to show its relationship to DNSSEC.
@@ -873,28 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 16]
Arends, et al. Expires August 16, 2004 [Page 15]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
10. IANA Considerations
@@ -948,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 17]
Arends, et al. Expires August 16, 2004 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
11. Security Considerations
@@ -963,33 +907,34 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
resource record sets.
In order for a security-aware resolver to validate a DNS response,
all of the intermediate zones must be signed, and all of the
intermediate name servers 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 which the resolver is
only able to obtain through a recursive name server which 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.
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 which the resolver is only able to obtain through a
recursive name server which 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, but transaction security is not
part of DNSSEC per se.
A 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
which perform these checks on its behalf and also to attacks on its
communication with those security-aware recursive name servers.
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 security-aware stub
resolver.
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 which perform these checks on its behalf and also 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
@@ -1000,15 +945,15 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
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 which supports DNS
Arends, et al. Expires June 16, 2004 [Page 18]
Arends, et al. Expires August 16, 2004 [Page 17]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
consume resources in a security-aware name server which 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.
@@ -1021,20 +966,24 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
obtain all the names in a zone. While not an attack on the DNS
itself, this could allow an attacker to map network hosts or other
resources by enumerating the contents of a zone. There are non-DNS
protocol means of limiting this attack such as limiting the number of
NSEC queries from a single host, use of intrusion detection tools,
etc.
protocol means of detecting and limiting this attack beyond the scope
of this document set.
DNSSEC introduces significant additional complexity to the DNS, and
thus introduces many new opportunities for implementation bugs and
misconfigured zones.
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 provide confidentiality, due to a deliberate design
choice.
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. Thus, while DNSSEC can provide data origin
zone) are not signed. This does not pose a problem when validating
the authentication chain, but 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 must be used to protect zone transfer
operations.
@@ -1055,14 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 19]
Arends, et al. Expires August 16, 2004 [Page 18]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
12. Acknowledgements
@@ -1116,9 +1060,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 20]
Arends, et al. Expires August 16, 2004 [Page 19]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
Normative References
@@ -1147,14 +1091,14 @@ Normative References
[I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-05 (work in progress),
October 2003.
draft-ietf-dnsext-dnssec-records-07 (work in progress),
February 2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in
progress), October 2003.
Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
progress), February 2004.
@@ -1172,9 +1116,9 @@ Normative References
Arends, et al. Expires June 16, 2004 [Page 21]
Arends, et al. Expires August 16, 2004 [Page 20]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
Informative References
@@ -1211,38 +1155,35 @@ Informative References
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-04 (work in
progress), October 2003.
[I-D.ietf-dnsext-ad-is-secure]
Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD
bit", draft-ietf-dnsext-ad-is-secure-06 (work in
progress), June 2002.
[I-D.ietf-dnsext-delegation-signer]
Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
Arends, et al. Expires June 16, 2004 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Name System", draft-ietf-dnsext-dns-threats-05 (work in
progress), November 2003.
[I-D.ietf-dnsext-dnssec-2535typecode-change]
Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05
(work in progress), October 2003.
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
Arends, et al. Expires August 16, 2004 [Page 21]
Internet-Draft DNSSEC Introduction and Requirements February 2004
(work in progress), December 2003.
[I-D.ietf-dnsext-keyrr-key-signing-flag]
Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag",
draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in
progress), October 2003.
draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
progress), December 2003.
Authors' Addresses
@@ -1257,9 +1198,9 @@ Authors' Addresses
Rob Austein
Internet Software Consortium
40 Gavin Circle
Reading, MA 01867
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
@@ -1284,9 +1225,12 @@ Authors' Addresses
Arends, et al. Expires June 16, 2004 [Page 23]
Arends, et al. Expires August 16, 2004 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
Scott Rose
@@ -1340,9 +1284,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires June 16, 2004 [Page 24]
Arends, et al. Expires August 16, 2004 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
Intellectual Property Statement
@@ -1370,7 +1314,7 @@ Intellectual Property Statement
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
@@ -1396,9 +1340,9 @@ Full Copyright Statement
Arends, et al. Expires June 16, 2004 [Page 25]
Arends, et al. Expires August 16, 2004 [Page 24]
Internet-Draft DNSSEC Introduction and Requirements December 2003
Internet-Draft DNSSEC Introduction and Requirements February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
@@ -1452,6 +1396,6 @@ Acknowledgement
Arends, et al. Expires June 16, 2004 [Page 26]
Arends, et al. Expires August 16, 2004 [Page 25]

1200
doc/draft/draft-ietf-ipv6-node-requirements-08.txt Normal file
View File

File diff suppressed because it is too large Load Diff