upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-03-16 15:44:00 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_2'.

Browse source
This commit is contained in:
cvs2git 2004-06-08 06:50:22 +00:00
commit e60f640ead
7 changed files with 11334 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

895
doc/draft/draft-ietf-dnsext-dns-threats-07.txt Normal file
View file

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

1513
doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt Normal file
View file

File diff suppressed because it is too large Load diff

3249
doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt Normal file
View file

File diff suppressed because it is too large Load diff

1961
doc/draft/draft-ietf-dnsext-dnssec-records-08.txt Normal file
View file

File diff suppressed because it is too large Load diff

1868
doc/draft/draft-ietf-dnsext-mdns-30.txt Normal file
View file

File diff suppressed because it is too large Load diff

504
doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt Normal file
View file

@ -0,0 +1,504 @@
DNS Extensions Working Group J. Schlyter, Ed.
Internet-Draft May 10, 2004
Updates: RFC 2535, RFC TCR (if approved)
Expires: November 8, 2004
DNSSEC NSEC RDATA Format
draft-ietf-dnsext-nsec-rdata-06.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document redefines the wire format of the "Type Bit Map" field
in the NSEC resource record RDATA format to cover the full RR type
space.
Schlyter Expires November 8, 2004 [Page 1]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
Normative References . . . . . . . . . . . . . . . . . . . . 6
Informational References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . 8
Schlyter Expires November 8, 2004 [Page 2]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
1. Introduction
The NSEC [5] Resource Record (RR) is used for authenticated proof of
the non-existence of DNS owner names and types. The NSEC RR is based
on the NXT RR as described in RFC 2535 [2], and is similar except for
the name and typecode. The RDATA format for the NXT RR has the
limitation in that the RDATA could only carry information about the
existence of the first 127 types. RFC 2535 did reserve a bit to
specify an extension mechanism, but the mechanism was never actually
defined.
In order to avoid the need to develop an extension mechanism into a
deployed base of DNSSEC aware servers and resolvers once the first
127 type codes are allocated, this document redefines the wire format
of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
type space.
This document introduces a new format for the type bit map. The
properties of the type bit map format are that it can cover the full
possible range of typecodes, that it is relatively economical in the
amount of space it uses for the common case of a few types with an
owner name, that it can represent owner names with all possible types
present in packets of approximately 8.5 kilobytes and that the
representation is simple to implement. Efficient searching of the
type bitmap for the presence of certain types is not a requirement.
For convenience and completeness this document presents the syntax
and semantics for the NSEC RR based on the specification in RFC 2535
[2] and as updated by RFC TCR [5], thereby not introducing changes
except for the syntax of the type bit map.
This document updates RFC 2535 [2] and RFC TCR [5].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2. The NSEC Resource Record
The NSEC resource record lists two separate things: the owner name of
the next RRset in the canonical ordering of the zone, and the set of
RR types present at the NSEC RR's owner name. The complete set of
NSEC RRs in a zone both indicate which RRsets exist in a zone and
also form a chain of owner names in the zone. This information is
used to provide authenticated denial of existence for DNS data, as
described in RFC 2535 [2].
The type value for the NSEC RR is 47.
Schlyter Expires November 8, 2004 [Page 3]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
The NSEC RR RDATA format is class independent and defined for all
classes.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [8].
2.1 NSEC RDATA Wire Format
The RDATA of the NSEC RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ List of Type Bit Map(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1 The Next Domain Name Field
The Next Domain Name field contains the owner name of the next RR in
the canonical ordering of the zone. The value of the Next Domain
Name field in the last NSEC record in the zone is the name of the
zone apex (the owner name of the zone's SOA RR).
A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR.
Owner names of RRsets not authoritative for the given zone (such as
glue records) MUST NOT be listed in the Next Domain Name unless at
least one authoritative RRset exists at the same owner name.
2.1.2 The List of Type Bit Map(s) Field
The RR type space is split into 256 window blocks, each representing
the low-order 8 bits of the 16-bit RR type space. Each block that has
at least one active RR type is encoded using a single octet window
number (from 0 to 255), a single octet bitmap length (from 1 to 32)
indicating the number of octets used for the window block's bitmap,
and up to 32 octets (256 bits) of bitmap.
Window blocks are present in the NSEC RR RDATA in increasing
numerical order.
"|" denotes concatenation
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
Schlyter Expires November 8, 2004 [Page 4]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
1, it indicates that an RRset of that type is present for the NSEC
RR's owner name. If a bit is set to 0, it indicates that no RRset of
that type is present for the NSEC RR's owner name.
Since bit 0 in window block 0 refers to the non-existing RR type 0,
it MUST be set to 0. After verification, the validator MUST ignore
the value of bit 0 in window block 0.
Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]
(section 3.1) or within the range reserved for assignment only to
QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
zone data. If encountered, they must be ignored upon reading.
Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block's
bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the
NSEC RR's owner name. Trailing zero octets not specified MUST be
interpretted as zero octets.
2.1.3 Inclusion of Wildcard Names in NSEC RDATA
If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other
owner name for purposes of generating NSEC RRs. Wildcard owner names
appear in the Next Domain Name field without any wildcard expansion.
RFC 2535 [2] describes the impact of wildcards on authenticated
denial of existence.
2.2 The NSEC RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Next Domain Name field is represented as a domain name.
The List of Type Bit Map(s) Field is represented as a sequence of RR
type mnemonics. When the mnemonic is not known, the TYPE
representation as described in RFC 3597 [4] (section 5) MUST be used.
2.3 NSEC RR Example
The following NSEC RR identifies the RRsets associated with
alfa.example.com. and identifies the next authoritative name after
Schlyter Expires November 8, 2004 [Page 5]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC
and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and
TYPE1234 RRsets associated with the name alfa.example.com.
The RDATA section of the NSEC RR above would be encoded as:
0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x20
Assuming that the resolver can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or could
be used to prove there is no AAAA record associated with
alfa.example.com. Authenticated denial of existence is discussed in
RFC 2535 [2].
3. IANA Considerations
This document introduces no new IANA considerations, because all of
the protocol parameters used in this document have already been
assigned by RFC TCR [5].
4. Security Considerations
The update of the RDATA format and encoding does not affect the
security of the use of NSEC RRs.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
System (DNS) IANA Considerations", BCP 42, RFC 2929, September
Schlyter Expires November 8, 2004 [Page 6]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
2000.
[4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
[5] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
in progress), October 2003.
Informational References
[6] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[7] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
2308, March 1998.
Author's Address
Jakob Schlyter (editor)
Karl Gustavsgatan 15
Goteborg SE-411 25
Sweden
EMail: jakob@schlyter.se
Appendix A. Acknowledgements
The encoding described in this document was initially proposed by
Mark Andrews. Other encodings where proposed by David Blacka and
Michael Graff.
Schlyter Expires November 8, 2004 [Page 7]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
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
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
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
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schlyter Expires November 8, 2004 [Page 8]
Internet-Draft DNSSEC NSEC RDATA Format May 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schlyter Expires November 8, 2004 [Page 9]

1344
doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt Normal file
View file

File diff suppressed because it is too large Load diff