mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-09-02 15:45:25 +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 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 R. Austein
Grunchweather Associates ISC
November 2003 February 2004
Threat Analysis Of The Domain Name System Threat Analysis of the Domain Name System
Status of this document 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 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 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:
Atkins & Austein Expires 21 August 2004 [Page 2]
Atkins & Austein Expires 26 May 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 For purposes of discussion, this note uses the term "DNSSEC" to refer
to the core hierarchical public key and signature mechanism specified to the core hierarchical public key and signature mechanism specified
in the DNSSEC documents, and refers to TKEY and TSIG as separate in the DNSSEC documents, and refers to TKEY and TSIG as separate
mechanisms, even though TKEY and TSIG are also part of the larger mechanisms, even though channel security mechanisms such as TKEY and
problem of "securing DNS" and thus are often considered part of the TSIG are also part of the larger problem of "securing DNS" and thus
overall set of "DNS security extensions". This is an arbitrary are often considered part of the overall set of "DNS security
distinction that in part reflects the way in which the protocol has extensions". This is an arbitrary distinction that in part reflects
evolved (introduction of a putatively simpler transaction model for the way in which the protocol has evolved (introduction of a
certain operations), and perhaps should be changed in a future putatively simpler channel security model for certain operations such
revision of this note. as zone transfers and dynamic update requests), and perhaps should be
changed in a future revision of this note.
2. Known Threats 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 To further complicate things, the DNS query the attacker intercepts
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 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 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-based attack (see
below). below).
While it certainly would be possible to sign DNS messages using TSIG While it certainly would be possible to sign DNS messages using a
or IPsec, or even to encrypt them using IPsec, this would not be a channel security mechanism such as TSIG or IPsec, or even to encrypt
very good solution. First, this approach would impose a fairly high them using IPsec, this would not be a very good solution. First,
processing cost per DNS message, as well as a very high cost this approach would impose a fairly high processing cost per DNS
associated with establishing and maintaining bilateral trust message, as well as a very high cost associated with establishing and
relationships between all the parties that might be involved in maintaining bilateral trust relationships between all the parties
resolving any particular query. For heavily used name servers (such that might be involved in resolving any particular query. For
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
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 heavily used name servers (such as the servers for the root zone),
the producer of DNS data (the zone administrator) and the consumer of this cost would almost certainly be prohibitively high. Even more
DNS data (the application that triggered the query). 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
@@ -190,7 +192,7 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
- Perform all of the DNSSEC signature checking on its own, - 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, its communication with whatever name servers it chooses to trust,
or 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 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 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 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 particularly large range, and is not sufficient to protect against a
search; furthermore, in practice both the client UDP port and the ID brute force search; furthermore, in practice both the client UDP port
can often be predicted from previous traffic, and it is not uncommon and the ID can often be predicted from previous traffic, and it is
for the client port to be a known fixed value as well (due to not uncommon for the client port to be a known fixed value as well
firewalls or other restrictions), thus frequently reducing the search (due to firewalls or other restrictions), thus frequently reducing
space to a range smaller than 2**16. the search space to a range smaller than 2**16.
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 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 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.
Since this attack relies on predicting a resolver's behavior, it's 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, 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 whether because the victim rebooted recently, or because the victim's
behavior has been influenced by some other action by the attacker, or behavior has been influenced by some other action by the attacker, or
because the victim is responding (in a predictable way) to some third 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 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
themselves perform DNSSEC signature checking should use TSIG or some 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 with a recursing name server that does perform DNSSEC signature
checking. 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 using this query as a means to inject false information about some
other name). 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 - 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
issued. 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 - Attacker's response includes one or more RRs with DNS names in
their RDATA; depending on which particular form this attack takes, their RDATA; depending on which particular form this attack takes,
the object may be to inject false data associated with those names 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 injected the data had access to an allegedly secret key whose
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
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). 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-based attack involving glue, but with DNSSEC it possibility of a name-based attack involving glue, but with DNSSEC it
is possible to detect the attack by temporarily accepting the glue in 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, order to fetch the signed authoritative version of the same data,
then checking the signatures on the authoritative version. 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...). installed when adding network drops in every guest room...).
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
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 option for the client. In many network environments a client machine
has only a limited set of recursive name server from which to chose, has only a limited set of recursive name servers from which to
and none of them may be particularly trustworthy. In extreme cases, choose, and none of them may be particularly trustworthy. In extreme
port filtering or other forms of packet interception may prevent the cases, port filtering or other forms of packet interception may
client host from being able to run an iterative resolver even if the prevent the client host from being able to run an iterative resolver
owner of the client machine is willing and able to do so. Thus, even if the owner of the client machine is willing and able to do so.
while the initial source of this problem is not a DNS protocol attack Thus, while the initial source of this problem is not a DNS protocol
per se, this sort of betrayal is a threat to DNS clients, and simply attack per se, this sort of betrayal is a threat to DNS clients, and
switching to a different recursive name server is not an adequate simply switching to a different recursive name server is not an
defense. adequate defense.
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
@@ -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 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
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 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 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 is help a resolver protect its communication with a name server that
it has already decided to trust for other reasons. Protecting a it has already decided to trust for other reasons. Protecting a
resolver's communication with a server that's giving out bogus 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. answers is not particularly useful.
Also note that if the stub resolver does not trust the name server 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 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 to perform the check knowledge of the DNSSEC public key(s) it needs in order to perform
(usually the public key for the root zone, but in some cases the check (usually the public key for the root zone, but in some
knowledge of additional keys may also be appropriate). 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
@@ -438,22 +440,27 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
might be considered a problem. The question remains: how serious is might be considered a problem. The question remains: how serious is
this threat? Clearly the threat does exist; general paranoia says this threat? Clearly the threat does exist; general paranoia says
that some day it'll be on the front page of some major newspaper, 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 even if we cannot conceive of a plausible scenario involving this
attack today. This implies that some mitigation of this risk is attack today. This implies that some mitigation of this risk is
required. required.
Note that it's necessary to prove the non-existance of applicable Note that it's necessary to prove the non-existence of applicable
Atkins & Austein Expires 26 May 2004 [Page 8]
draft-ietf-dnsext-dns-threats-05.txt November 2003
wildcard RRs as part of the authenticated denial mechanism, and that, 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 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 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. heavy use of wildcard RRs, particularly wildcard MX RRs.
In order to provide the desired services for wildcard RRs, we need to 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 a way to attest to the existence of the wildcard RR itself
we need to prove that the synthesis rule exists), and (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 - We need a way to attest to the non-existence of any RRs which, if
existed, would make the wildcard RR irrelevant according to the they existed, would make the wildcard RR irrelevant according to
synthesis rules the way in which wildcards are used (that is, we the synthesis rules that govern the way in which wildcard RRs are
need to prove that the synthesis rule is applicable). 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. authenticated denial mechanism described in the previous section.
DNSSEC does include mechanisms by which it is possible to furnish DNSSEC includes mechanisms along the lines described above, which
wildcard proofs along the lines described above. 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 3. Weaknesses of DNSSEC
DNSSEC has some problems of its own: 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 - 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
@@ -499,22 +516,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
effective as denial of service amplifiers. effective as denial of service amplifiers.
- DNSSEC answer validation increases the resolver's work load, since - 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 a DNSSEC-aware resolver will need to perform signature validation
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 will almost certainly answer back to the original DNS client, which is likely to trigger
trigger both timeouts and re-queries. (Arguably, many current DNS both timeouts and re-queries in some cases. (Arguably, many
clients are already too impatient even before taking the further current DNS clients are already too impatient even before taking
delays that DNSSEC will impose into account, but that's a separate the further delays that DNSSEC will impose into account, but that's
topic for another document....) a separate topic for another document....)
- 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
@@ -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 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 compromise in any of the zones between the root and a particular
target name can damage DNSSEC's ability to protect the integrity of 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 data owned by that target name. This is not a change, since
insecure DNS has essentially the same problem, but it's not good insecure DNS has the same model.
either.
- Key rollover at the root is really hard. Work to date has not even - 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 come close to adequately specifying how the root key rolls over, or
even how it's configured in the first place. even how it's configured in the first place.
- DNSSEC creates a requirement of loose time synchronization between - DNSSEC creates a requirement of loose time synchronization between
the resolver and the host creating the DNSSEC signatures. Prior to the validating resolver and the entity creating the DNSSEC
DNSSEC, all time-related actions in DNS could be performed by a signatures. Prior to DNSSEC, all time-related actions in DNS could
machine that only knew about "elapsed" or "relative" time. Because be performed by a machine that only knew about "elapsed" or
the validity period of a DNSSEC signature is based on "absolute" "relative" time. Because the validity period of a DNSSEC signature
time, a resolver must have the same concept of absolute time in is based on "absolute" time, a validating resolver must have the
order to determine whether the signature is within its validity same concept of absolute time as the zone signer in order to
period or has expired. An attacker that can change a resolver's determine whether the signature is within its validity period or
opinion of the current absolute time can fool the resolver using has expired. An attacker that can change a resolver's opinion of
expired signatures. An attacker that can change the zone signer's the current absolute time can fool the resolver using expired
opinion of the current absolute time can fool the zone signer into 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 generating signatures whose validity period does not match what the
signer intended. 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 21 August 2004 [Page 10]
Atkins & Austein Expires 26 May 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 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 limited or closed environment such as a DHCP server updating a local
DNS name server. 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 Major issues arise when trying to use dynamic update on a secure
zone. TSIG can similarly be used in a limited fashion to zone. TSIG can similarly be used in a limited fashion to
authenticate the client to the server, but TSIG only protects DNS 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 the above options, but in practice (a) would almost certainly be
extremely fragile, so (b) is the only workable mechanism. 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 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 make what changes to which RRsets in the zone. The current access
control scheme in Secure Dynamic Update is fairly limited. There is 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 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 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 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 As discussed in previous sections, DNSSEC per se attempts to provide
data integrity and data origin authentication services on top of the data integrity and data origin authentication services on top of the
normal DNS query protocol. Using the terminology discussed in [SEC- normal DNS query protocol. Using the terminology discussed in
CONS], DNSSEC provides "object security" for the normal DNS query [RFC3552], DNSSEC provides "object security" for the normal DNS query
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
@@ -645,6 +664,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003
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, so 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
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 name server operators, rather than an end-to-end matter of name
server operators trusting zone administrators. server operators trusting zone administrators.
@@ -668,13 +695,6 @@ 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.
Atkins & Austein Expires 26 May 2004 [Page 12]
draft-ietf-dnsext-dns-threats-05.txt November 2003
IANA Considerations IANA Considerations
None. None.
@@ -684,56 +704,61 @@ Acknowledgments
This note is based both previous published works by others and on a 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 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 Jaap Akkerhuis, Steve Bellovin,
Dan Bernstein, Randy Bush, Olafur Gudmundsson, Rip Loomis, Allison Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ
Mankin, Paul Mockapetris, Mans Nilsson, Paul Vixie, Xunhua Wang, and Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten
any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other
groups whose names and contributions the authors have forgotten, none members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose
of whom are responsible for what the authors did with their ideas. 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 Normative References
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
facilities", RFC 1034, November 1987. 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. 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. RFC 2308, March 1998.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
August 1999. 2671, August 1999.
[TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
"Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845, Wellington, "Secret Key Transaction Authentication for DNS
May 2000. (TSIG)" RFC 2845, May 2000.
[TKEY] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" RFC [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)"
2930, September 2000. RFC 2930, September 2000.
[SECURE-UPDATE] Wellington, B., "Secure Domain Name System (DNS) [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Dynamic Update" RFC 3007, November 2000. 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. 2535, March 1999.
Atkins & Austein Expires 26 May 2004 [Page 13]
draft-ietf-dnsext-dns-threats-05.txt November 2003
Informative References 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 Board, "Guidelines for Writing RFC Text on Security
Considerations", RFC 3552, July 2003. Considerations", RFC 3552, July 2003.
@@ -751,7 +776,15 @@ Informative References
[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.
Author's addresses:
Atkins & Austein Expires 21 August 2004 [Page 14]
draft-ietf-dnsext-dns-threats-06.txt February 2004
Authors' addresses:
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
@@ -762,10 +795,12 @@ Author's addresses:
Email: derek@ihtfp.com Email: derek@ihtfp.com
Rob Austein Rob Austein
Grunchweather Associates Internet Systems Consortium
950 Charter Street
Email: sra@hactrn.net Redwood City, CA 94063
USA
Email: sra@isc.org
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any 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 claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such 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 proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
@@ -805,6 +832,14 @@ Full Copyright Statement
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are 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 included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other 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 DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: June 16, 2004 R. Austein Expires: August 16, 2004 R. Austein
ISC ISC
M. Larson M. Larson
VeriSign VeriSign
@@ -10,11 +10,11 @@ Expires: June 16, 2004 R. Austein
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
December 17, 2003 February 16, 2004
DNS Security Introduction and Requirements DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-08 draft-ietf-dnsext-dnssec-intro-09
Status of this Memo Status of this Memo
@@ -36,15 +36,15 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 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 authentication and data integrity to the Domain Name System. This
document introduces these extensions, and describes their document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the 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 Last, this document describes the interrelationships between the
@@ -75,15 +75,13 @@ Table of Contents
7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15
9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . 21
Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Informative References . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
@@ -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 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 This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445
[RFC3445], as well as several works in progress: "Redefinition of the [RFC3445], as well as several works in progress: "Redefinition of the
AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation
Compatibility for Delegation Signer" Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation
[I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer Signer Resource Record" [RFC3658]. This document set also updates,
Resource Record" [I-D.ietf-dnsext-delegation-signer]. This document but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
set also updates, but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597].
[RFC1035], 2136 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597
[RFC3597].
The DNS security extensions provide origin authentication and The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key 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 2. Definitions of Important DNSSEC Terms
@@ -178,36 +178,36 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
this section. this section.
authentication chain: an alternating sequence of DNSKEY RRsets and DS authentication chain: an alternating sequence of DNSKEY RRsets and DS
RRs forms a chain of signed data, with each link in the chain RRsets 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 vouching for the next. A DNSKEY RR is used to verify the
covering a DS RR and allows the DS RR to be authenticated. The DS signature covering a DS RR and allows the DS RR to be
RR contains a hash of another DNSKEY RR and this new DNSKEY RR is authenticated. The DS RR contains a hash of another DNSKEY RR and
authenticated by matching the hash in the DS RR. This new DNSKEY this new DNSKEY RR is authenticated by matching the hash in the DS
RR in turn authenticates another DNSKEY RRset and, in turn, some RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
DNSKEY RR in this set may be used to authenticate another DS RR and, in turn, some DNSKEY RR in this set may be used to
and so forth until the chain finally ends with a DNSKEY RR which authenticate another DS RR and so forth until the chain finally
signs the desired DNS data. For example, the root DNSKEY can be ends with a DNSKEY RR which signs the desired DNS data. For
used to authenticated the DS RR for "example." The "example." DS example, the root DNSKEY RRset can be used to authenticate the DS
RR contains a hash that matches some "example." DNSKEY and this RRset for "example." The "example." DS RRset contains a hash that
DNSKEY signs the "example." DNSKEY RRset. Private key matches some "example." DNSKEY and this DNSKEY signs the
counterparts in the "example." DNSKEY RRset sign data records such "example." DNSKEY RRset. Private key counterparts of the
as "www.example." as well as DS RRs for delegations such as "example." DNSKEY RRset sign data records such as "www.example."
"subzone.example." as well as DS RRs for delegations such as "subzone.example."
authentication key: A public key which a security-aware resolver has authentication key: A public key which a security-aware resolver has
verified and can therefore use to authenticate data. A verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally preconfigured to know ways. First, the resolver is generally preconfigured to know
about at least one public key. This preconfigured data is either about at least one public key. This preconfigured data is usually
the public key itself, or a hash of the key as found in the DS RR. either the public key itself or a hash of the key as found in the
Second, the resolver may use an authenticated public key to verify DS RR. Second, the resolver may use an authenticated public key
a DS RR and its associated DNSKEY RR. Third, the resolver may be to verify a DS RR and its associated DNSKEY RR. Third, the
able to determine that a new key has been signed by another key resolver may be able to determine that a new key has been signed
which the resolver has verified. Note that the resolver must by another key which the resolver has verified. Note that the
always be guided by local policy when deciding whether to resolver must always be guided by local policy when deciding
authenticate a new key, even if the local policy is simply to whether to authenticate a new key, even if the local policy is
authenticate any new key for which the resolver is able verify the simply to authenticate any new key for which the resolver is able
signature. verify the signature.
delegation point: Term used to describe the name at the parental side delegation point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example" 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 in its delegating parent zone (see
[I-D.ietf-dnsext-dnssec-records]). An island of security is served [I-D.ietf-dnsext-dnssec-records]). An island of security is served
by a security-aware nameserver and may provide authentication by a security-aware nameserver and may provide authentication
chains to any delegated child zones. Responses from an island of chains to any delegated child zones. Responses from an island of
security or its descendents can only be validated if its zone key security or its descendents can only be authenticated if its zone
can be obtained by some trusted means out of band from the DNS key can be authenticated by some trusted means out of band from
protocol. the DNS protocol.
key signing key: An authentication key which is used to sign one or key signing key: An authentication key which is used to sign one or
more other authentication keys. Typically, a key signing key will more other authentication keys for a given zone. Typically, a key
sign a zone signing key, which in turn will sign other zone data. signing key will sign a zone signing key, which in turn will sign
Local policy may require the zone signing key to be changed other zone data. Local policy may require the zone signing key to
frequently, while the key signing key may have a longer validity be changed frequently, while the key signing key may have a longer
period in order to provide a more stable secure entry point into validity period in order to provide a more stable secure entry
the zone. Designating an authentication key as a key signing key point into the zone. Designating an authentication key as a key
is purely an operational issue: DNSSEC validation does not signing key is purely an operational issue: DNSSEC validation does
distinguish between key signing keys and other DNSSEC not distinguish between key signing keys and other DNSSEC
authentication keys. Key signing keys are discussed in more authentication keys. Key signing keys are discussed in more
detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone
signing key. 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 security-aware name server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) which understands the server (defined in section 2.4 of [RFC1034]) which understands the
DNS security extensions defined in this document set. In 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 A more cumbersome equivalent phrase would be "a security-aware
name server which offers recursive service". 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 security-aware resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) which understands the DNS (defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular, 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 types and message header bits defined in this document set to
provide DNSSEC services. provide DNSSEC services.
security-aware stub resolver: An entity acting in the role of a security-aware stub resolver: An entity acting in the role of a stub
resolver (defined in section 2.4 of [RFC1034]) which has at least resolver (defined in section 5.3.1 of [RFC1034]) which has enough
a minimal understanding the DNS security extensions defined in of an understanding the DNS security extensions defined in this
this document set, but which trusts one or more security-aware 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.
security-oblivious <anything>: An <anything> which is not
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-aware". "security-aware".
signed zone: A zone whose RRsets are signed and which contains signed zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records. 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. 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 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 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 it, but is used for a slightly different purpose and may differ
from the key signing key in other ways, such as validity lifetime. 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. See also: key signing key.
Arends, et al. Expires August 16, 2004 [Page 6]
Arends, et al. Expires June 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 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 offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by via DNS resolution, the target key itself needs to be signed by
either a preconfigured authentication key or another key that has 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 zone information by forming an authentication chain from a newly
learned public key back to a previously known authentication public learned public key back to a previously known authentication public
key, which in turn either must have been preconfigured into the 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. 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 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 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 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 in this DNSKEY RRset to sign its zone data. The typical
is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where
more DS->DNSKEY subchains. "*" 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 A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based 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 record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence authenticate a negative reply for either name or type non-existence
via the same mechanisms used to authenticate other DNS replies. Use 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 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 as listing the types of RRsets present at existing names. Each NSEC
record is signed and authenticated using the mechanisms described in 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 August 16, 2004 [Page 9]
Arends, et al. Expires June 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 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. on cryptographic operations. Please see Section 11 for details.
The DNS security extensions provide data and origin authentication The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above extend no protection to for DNS data. The mechanisms outlined above are not designed to
operations such as zone transfers and dynamic update [RFC3007]. protect operations such as zone transfers and dynamic update
Message authentication schemes described in [RFC2845] and [RFC2931] [RFC3007]. Message authentication schemes described in [RFC2845] and
address security operations that pertain to these transactions. [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 August 16, 2004 [Page 10]
Arends, et al. Expires June 16, 2004 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements December 2003 Internet-Draft DNSSEC Introduction and Requirements February 2004
5. Resolver Considerations 5. Resolver Considerations
A security-aware resolver needs to be able to perform cryptographic A security-aware resolver needs to be able to perform cryptographic
functions necessary to verify digital signatures using at least the 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 also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to 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 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 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 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 security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or 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 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 if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers which it uses: it can relationship with the recursive name servers which it uses: it can
perform its own signature validation, by setting the Checking perform its own signature validation, by setting the Checking
Disabled (CD) bit in its query messages. Upon taking this step, the Disabled (CD) bit in its query messages. A validating stub resolver
resolver is no longer really a stub resolver at all anymore (in the is thus able to treat the DNSSEC signatures as a trust relationship
terminology used in this document set, anyway), and is now a between the zone administrator and the stub resolver itself.
security-aware resolver with somewhat limited functionality.
@@ -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 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 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 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
resolvers which have signaled their willingness to receive such resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message 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 size limitations. Since inclusion of these DNSSEC RRs could easily
support the EDNS mechanism size extension, since otherwise inclusion cause UDP message truncation and fallback to TCP, a security-aware
of DNSSEC RRs could easily cause UDP message truncation and fallback name server must also support the EDNS "sender's UDP payload"
to TCP. mechanism.
If possible, the private half of each DNSSEC key pair should be kept 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 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 DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone entire zone during zone transfer operations, since even a signed zone
contains some unsigned data if the zone has any children, so zone contains some unsigned, nonauthoritative data if the zone has any
maintenance operations will require some additional mechanisms (most children, so zone maintenance operations will require some additional
likely some form of channel security, such as TSIG, SIG(0), or mechanisms (most likely some form of channel security, such as TSIG,
IPsec). 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 9. DNS Security Document Family
The DNSSEC set of documents can be partitioned into five main groups The DNSSEC document set can be partitioned into several main groups,
as depicted in Figure 1. All of these documents are in turn under under the larger umbrella of the DNS base protocol documents.
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 protocol document set" refers to the three documents The "DNSSEC protocol document set" refers to the three documents
which form the core of the DNS security extensions: 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 3. Protocol Modifications for the DNS Security Extensions
[I-D.ietf-dnsext-dnssec-protocol] [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 to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource 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 record format. Each of these documents deals with a specific digital
signature algorithm. signature algorithm.
The "Transaction Authentication Implementations" document set refers The "Transaction Authentication Protocol" document set refers to the
to the group of documents that deal with DNS message authentication, group of documents that deal with DNS message authentication,
including secret key establishment and verification. While not including secret key establishment and verification. While not
strictly part of the DNSSEC specification as defined in this set of strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted to show its relationship to DNSSEC. 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 August 16, 2004 [Page 15]
Arends, et al. Expires June 16, 2004 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements December 2003 Internet-Draft DNSSEC Introduction and Requirements February 2004
10. IANA Considerations 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 11. Security Considerations
@@ -963,33 +907,34 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
resource record sets. resource record sets.
In order for a security-aware resolver to validate a DNS response, In order for a security-aware resolver to validate a DNS response,
all of the intermediate zones must be signed, and all of the all zones along the path from the trusted starting point to the zone
intermediate name servers must be security-aware, as defined in this containing the response zones must be signed, and all name servers
document set. A security-aware resolver cannot verify responses and resolvers involved in the resolution process must be
originating from an unsigned zone, from a zone not served by a security-aware, as defined in this document set. A security-aware
security-aware name server, or for any DNS data which the resolver is resolver cannot verify responses originating from an unsigned zone,
only able to obtain through a recursive name server which is not from a zone not served by a security-aware name server, or for any
security-aware. If there is a break in the authentication chain such DNS data which the resolver is only able to obtain through a
that a security-aware resolver cannot obtain and validate the recursive name server which is not security-aware. If there is a
authentication keys it needs, then the security-aware resolver cannot break in the authentication chain such that a security-aware resolver
validate the affected DNS data. 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 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 DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism, but transaction security is not transaction authentication mechanism, but transaction security is not
part of DNSSEC per se. part of DNSSEC per se.
A security-aware stub resolver, by definition, does not perform A non-validating security-aware stub resolver, by definition, does
DNSSEC signature validation on its own, and thus is vulnerable both not perform DNSSEC signature validation on its own, and thus is
to attacks on (and by) the security-aware recursive name servers vulnerable both to attacks on (and by) the security-aware recursive
which perform these checks on its behalf and also to attacks on its name servers which perform these checks on its behalf and also to
communication with those security-aware recursive name servers. attacks on its communication with those security-aware recursive name
Security-aware stub resolvers should use some form of channel servers. Non-validating security-aware stub resolvers should use some
security to defend against the latter threat. The only known defense form of channel security to defend against the latter threat. The
against the former threat would be for the security-aware stub only known defense against the former threat would be for the
resolver to perform its own signature validation, at which point, security-aware stub resolver to perform its own signature validation,
again by definition, it would no longer be a security-aware stub at which point, again by definition, it would no longer be a
resolver. non-validating security-aware stub resolver.
DNSSEC does not protect against denial of service attacks. DNSSEC DNSSEC does not protect against denial of service attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks 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 resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to 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 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 security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary. 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 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 itself, this could allow an attacker to map network hosts or other
resources by enumerating the contents of a zone. There are non-DNS resources by enumerating the contents of a zone. There are non-DNS
protocol means of limiting this attack such as limiting the number of protocol means of detecting and limiting this attack beyond the scope
NSEC queries from a single host, use of intrusion detection tools, of this document set.
etc.
DNSSEC introduces significant additional complexity to the DNS, and DNSSEC introduces significant additional complexity to the DNS, and
thus introduces many new opportunities for implementation bugs 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 DNSSEC does not provide confidentiality, due to a deliberate design
choice. choice.
DNSSEC does not protect against tampering with unsigned zone data. DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent 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 authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer zones, and other mechanisms must be used to protect zone transfer
operations. operations.
@@ -1055,14 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003
Arends, et al. Expires August 16, 2004 [Page 18]
Arends, et al. Expires June 16, 2004 [Page 19]
Internet-Draft DNSSEC Introduction and Requirements December 2003 Internet-Draft DNSSEC Introduction and Requirements February 2004
12. Acknowledgements 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 Normative References
@@ -1147,14 +1091,14 @@ Normative References
[I-D.ietf-dnsext-dnssec-records] [I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions", Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-05 (work in progress), draft-ietf-dnsext-dnssec-records-07 (work in progress),
October 2003. February 2004.
[I-D.ietf-dnsext-dnssec-protocol] [I-D.ietf-dnsext-dnssec-protocol]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in
progress), October 2003. 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 Informative References
@@ -1211,38 +1155,35 @@ Informative References
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (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] [I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-04 (work in Name System", draft-ietf-dnsext-dns-threats-05 (work in
progress), October 2003. progress), November 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
[I-D.ietf-dnsext-dnssec-2535typecode-change] [I-D.ietf-dnsext-dnssec-2535typecode-change]
Weiler, S., "Legacy Resolver Compatibility for Delegation Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
(work in progress), October 2003.
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] [I-D.ietf-dnsext-keyrr-key-signing-flag]
Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag", Entry Point Flag",
draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
progress), October 2003. progress), December 2003.
Authors' Addresses Authors' Addresses
@@ -1257,9 +1198,9 @@ Authors' Addresses
Rob Austein Rob Austein
Internet Software Consortium Internet Systems Consortium
40 Gavin Circle 950 Charter Street
Reading, MA 01867 Redwood City, CA 94063
USA USA
EMail: sra@isc.org 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 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 Intellectual Property Statement
@@ -1370,7 +1314,7 @@ Intellectual Property Statement
Full Copyright 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 This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it 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 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