DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: April 26, 2004 R. Austein
ISC
M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
October 27, 2003
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-07
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 April 26, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The Domain Name System Security Extensions (DNSSEC) adds data origin
authentication and data integrity to the Domain Name System. This
document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the
services that the DNS security extensions do and do not provide.
Arends, et al. Expires April 26, 2004 [Page 1]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Last, this document describes the interrelationships between the
group of documents that collectively describe DNSSEC.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . . 7
3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7
3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8
4. Services Not Provided by DNS Security . . . . . . . . . . . . 10
5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11
6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12
7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13
7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15
9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 15
9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Arends, et al. Expires April 26, 2004 [Page 2]
Internet-Draft DNSSEC Introduction and Requirements October 2003
1. Introduction
This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and its two companion documents
([I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
security extensions defined in RFC 2535 [RFC2535] and its
predecessors. These security extensions consist of a set of new
resource record types and modifications to the existing DNS protocol
[RFC1035]. The new records and protocol modifications are not fully
described in this document, but are described in a family of
documents outlined in Section 9. Section 3 and Section 4 describe the
capabilities and limitations of the security extensions in greater
detail. Section 5, Section 6, Section 7, and Section 8 discuss the
effect that these security extensions will have on resolvers, stub
resolvers, zones and name servers.
This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445
[RFC3445], as well as several works in progress: "Redefinition of the
AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver
Compatibility for Delegation Signer"
[I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer
Resource Record" [I-D.ietf-dnsext-delegation-signer].
The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key
distribution. These extensions do not provide confidentiality.
Arends, et al. Expires April 26, 2004 [Page 3]
Internet-Draft DNSSEC Introduction and Requirements October 2003
2. Definitions of Important DNSSEC Terms
authentication chain: an alternating succession of DNSKEY RRsets and
DS RRs forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to check the signature
covering a DS RR and allows the DS RR to be authenticated. The DS
RR contains a hash of another DNSKEY RR and this new DNSKEY RR is
authenticated by matching the hash in the DS RR. This new DNSKEY
RR in turn authenticates another DNSKEY RRset and, in turn, some
DNSKEY RR in this set may be used to authenticate another DS RR
and so forth until the chain finally ends with a DNSKEY RR which
signs the desired DNS data. For example, the root DNSKEY can be
used to authenticated the DS RR for "example." The "example." DS
RR contains a hash that matches some "example." DNSKEY and this
DNSKEY signs the "example." DNSKEY RRset. Keys in the "example."
DNSKEY RRset sign data records such as "www.example." as well as
DS RRs for delegations such as "subzone.example."
authentication key: A public key which a security-aware resolver has
verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally preconfigured to know
about at least one public key. This preconfigured data is either
the public key itself, or a hash of the key as found in the DS RR.
Second, the resolver may use an authenticated public key to verify
a DS RR and its associated DNSKEY RR. Third, the resolver may be
able to determine that a new key has been signed by another key
which the resolver has verified. Note that the resolver must
always be guided by local policy when deciding whether to
authenticate a new key, even if the local policy is simply to
authenticate any new key for which the resolver is able verify the
signature.
island of security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating
parent. That is, there is no DS RR with the island's key in its
delegating parent zone (see [I-D.ietf-dnsext-dnssec-records]). An
island of security is served by a security-aware nameserver and
may provide authentication chains to any delegated child zones.
Responses from an island of security or its descendents can only
be validated if its zone key can be obtained by some trusted means
out of band from the DNS protocol.
key signing key: An authentication key which is used to sign one or
more other authentication keys. Typically, a key signing key will
sign a zone signing key, which in turn will sign other zone data.
Local policy may require the zone signing key to be changed
frequently, while the key signing key may have a longer validity
Arends, et al. Expires April 26, 2004 [Page 4]
Internet-Draft DNSSEC Introduction and Requirements October 2003
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC validation does not
distinguish between key signing keys and other DNSSEC
authentication keys. Key signing keys are discussed in more
detail in [I-D.ietf-dnsext-keyrr-key-signing-flag].
security-aware name server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) which understands the
DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity which
receives DNS queries, sends DNS responses, supports the EDNS0
[RFC2671] message size extension and the DO bit [RFC3225], and
supports the RR types and message header bits defined in this
document set.
security-aware recursive name server: An entity which acts in both
the security-aware name server and security-aware resolver roles.
A more cumbersome equivalent phrase would be "a security-aware
name server which offers recursive service".
security-aware resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular,
a security-aware resolver is an entity which sends DNS queries,
receives DNS responses, supports the EDNS0 [RFC2671] message size
extension and the DO bit [RFC3225], and is capable of using the RR
types and message header bits defined in this document set to
provide DNSSEC services.
security-aware stub resolver: An entity acting in the role of a
resolver (defined in section 2.4 of [RFC1034]) which has at least
a minimal understanding the DNS security extensions defined in
this document set, but which trusts one or more security-aware
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.
Arends, et al. Expires April 26, 2004 [Page 5]
Internet-Draft DNSSEC Introduction and Requirements October 2003
security-oblivious (server or resolver): The opposite of
"security-aware".
signed zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records.
unsigned zone: The opposite of a "signed zone".
zone signing key: An authentication key which is used to sign a zone.
See key signing key, above. Typically a zone signing key will be
part of the same DNSKEY RRset as the key signing key which signs
it, but is used for a slightly different purpose and may differ
from the key signing key in other ways, such as validity lifetime.
Arends, et al. Expires April 26, 2004 [Page 6]
Internet-Draft DNSSEC Introduction and Requirements October 2003
3. Services Provided by DNS Security
The Domain Name System (DNS) security extensions provide origin
authentication and integrity assurance services for DNS data,
including mechanisms for authenticated denial of existence of DNS
data. These mechanisms are described below.
These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
new message header bits (CD and AD). In order to support the larger
DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
for the DO bit [RFC3225], so that a security-aware resolver can
indicate in its queries that it wishes to receive DNSSEC RRs in
response messages.
These services protect against most of the threats to the Domain Name
System described in [I-D.ietf-dnsext-dns-threats].
3.1 Data Origin Authentication and Data Integrity
DNSSEC provides authentication by associating cryptographically
generated digital signatures with DNS RRsets. These digital
signatures are stored in a new resource record, the RRSIG record.
Typically, there will be a single private key that signs a zone's
data, but multiple keys are possible: for example, there may be keys
for each of several different digital signature algorithms. If a
security-aware resolver reliably learns a zone's public key, it can
authenticate that zone's signed data. An important DNSSEC concept is
that the key that signs a zone's data is associated with the zone
itself and not with the zone's authoritative name servers (public
keys for DNS transaction authentication mechanisms may also appear in
zones, as described in [RFC2931], but DNSSEC itself is concerned with
object security of DNS data, not channel security of DNS
transactions).
A security-aware resolver can learn a zone's public key either by
having the key preconfigured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new
type of resource record, the DNSKEY RR. Note that the private keys
used to sign zone data must be kept secure, and should be stored
offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by
either a preconfigured authentication key or another key that has
been authenticated previously. Security-aware resolvers authenticate
zone information by forming an authentication chain from a newly
learned public key back to a previously known authentication public
key, which in turn either must have been preconfigured into the
Arends, et al. Expires April 26, 2004 [Page 7]
Internet-Draft DNSSEC Introduction and Requirements October 2003
resolver or must have been learned and verified previously.
Therefore, the resolver must be configured with at least one public
key or hash of a public key: if the preconfigured key is a zone
signing key, then it will authenticate the associated zone; if the
preconfigured key is a key signing key, it will authenticate a zone
signing key. If the resolver has been preconfigured with the hash of
a key rather than the key itself, the resolver may need to obtain the
key via a DNS query. To help security-aware resolvers establish this
authentication chain, security-aware name servers attempt to send the
signature(s) needed to authenticate a zone's public key in the DNS
reply message along with the public key itself, provided there is
space available in the message.
The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across
organizational boundaries. The DS RRset resides at a delegation
point in a parent zone and indicates the key or keys used by the
delegated child zone to self-sign the DNSKEY RRset at the child
zone's apex. The child zone, in turn, uses one or more of the keys
in this DNSKEY RRset to sign its zone data. The authentication chain
is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or
more DS->DNSKEY subchains.
A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based
on preconfigured knowledge of the public key for the root. Local
policy, however, may also allow a security-aware resolver to use one
or more preconfigured keys (or key hashes) other than the root key,
or may not provide preconfigured knowledge of the root key, or may
prevent the resolver from using particular keys for arbitrary reasons
even if those keys are properly signed with verifiable signatures.
DNSSEC provides mechanisms by which a security-aware resolver can
determine whether an RRset's signature is "valid" within the meaning
of DNSSEC. In the final analysis however, authenticating both DNS
keys and data is a matter of local policy, which may extend or even
override the protocol extensions defined in this document set.
3.2 Authenticating Name and Type Non-Existence
The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity
requires the use of another new resource record type, the NSEC
record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence
via the same mechanisms used to authenticate other DNS replies. Use
of NSEC records require a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe
Arends, et al. Expires April 26, 2004 [Page 8]
Internet-Draft DNSSEC Introduction and Requirements October 2003
the gaps, or "empty space", between domain names in a zone, as well
as listing the types of RRsets present at existing names. Each NSEC
record is signed and authenticated using the mechanisms described in
Section 3.1.
Arends, et al. Expires April 26, 2004 [Page 9]
Internet-Draft DNSSEC Introduction and Requirements October 2003
4. Services Not Provided by DNS Security
DNS was originally designed with the assumptions that the DNS will
return the same answer to any given query regardless of who may have
issued the query, and that all data in the DNS is thus visible.
Accordingly, DNSSEC is not designed to provide confidentiality,
access control lists, or other means of differentiating between
inquirers.
DNSSEC provides no protection against denial of service attacks.
Security-aware resolvers and security-aware name servers are
vulnerable to an additional class of denial of service attacks based
on cryptographic operations. Please see Section 11 for details.
The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above extend no protection to
operations such as zone transfers and dynamic update [RFC3007].
Message authentication schemes described in [RFC2845] and [RFC2931]
address security operations that pertain to these transactions.
Arends, et al. Expires April 26, 2004 [Page 10]
Internet-Draft DNSSEC Introduction and Requirements October 2003
5. Resolver Considerations
A security-aware resolver needs to be able to perform cryptographic
functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithms. Security-aware resolvers must
also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to
obtain necessary DNSKEY, DS and RRSIG records. A security-aware
resolver should be configured with at least one authentication key or
a key's DS RR hash as the starting point from which it will attempt
to establish authentication chains.
If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver
may not be able to operate in a secure mode. For example, if a
security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or
impossible to obtain or validate signed DNS data.
If a security-aware resolver must rely on an unsigned zone or a name
server that is not security aware, the resolver may not be able to
validate DNS responses, and will need a local policy on whether to
accept unverified responses.
A security-aware resolver should take a signature's validation period
into consideration when determining the TTL of data in its cache, to
avoid caching signed data beyond the validity period of the
signature, but should also allow for the possibility that the
security-aware resolver's own clock is wrong. Thus, a security-aware
resolver which is part of a security-aware recursive name server will
need to pay careful attention to the DNSSEC "checking disabled" (CD)
bit [I-D.ietf-dnsext-dnssec-records] in order to avoid blocking valid
signatures from getting through to other security-aware resolvers
which are clients of this recursive name server and which are capable
of performing their own DNSSEC validity checks. See
[I-D.ietf-dnsext-dnssec-protocol] for how a secure recursive server
handles queries with the CD bit set.
Arends, et al. Expires April 26, 2004 [Page 11]
Internet-Draft DNSSEC Introduction and Requirements October 2003
6. Stub Resolver Considerations
Although not strictly required to do so by the protocol, most DNS
queries originate from stub resolvers. Stub resolvers, by
definition, are minimal DNS resolvers which use recursive query mode
to offload most of the work of DNS resolution to a recursive name
server. Given the widespread use of stub resolvers, the DNSSEC
architecture has to take stub resolvers into account, but the
security features needed in a stub resolver differ in some respects
from those needed in a full security-aware resolver.
Even an unaugmented stub resolver may get some benefit from DNSSEC if
the recursive name servers it uses are security-aware, but for the
stub resolver to place any real reliance on DNSSEC services, the stub
resolver must trust both the recursive name servers in question and
the communication channels between itself and those name servers.
The first of these issues is a local policy issue: in essence, a stub
resolver has no real choice but to place itself at the mercy of the
recursive name servers that it uses, since it does not perform DNSSEC
validity checks on its own. The second issue requires some kind of
channel security mechanism; proper use of DNS transaction
authentication mechanisms such as SIG(0) or TSIG would suffice, as
would appropriate use of IPsec, and particular implementations may
have other choices available, such as operating system specific
interprocess communication mechanisms. Confidentiality is not needed
for this channel, but data integrity and message authentication are.
A security-aware stub resolver which does trust both its recursive
name servers and its communication channel to them may choose to
examine the setting of the AD bit in the message header of the
response messages it receives. The stub resolver can use this flag
bit as a hint to find out whether the recursive name server was able
to validate signatures for all of the data in the Answer and
Authority sections of the response.
There is one more step which a security-aware stub resolver can take
if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers which it uses: it can
perform its own signature validation, by setting the Checking
Disabled (CD) bit in its query messages. Upon taking this step, the
resolver is no longer really a stub resolver at all anymore (in the
terminology used in this document set, anyway), and is now a
security-aware resolver with somewhat limited functionality.
Arends, et al. Expires April 26, 2004 [Page 12]
Internet-Draft DNSSEC Introduction and Requirements October 2003
7. Zone Considerations
There are several differences between signed and unsigned zones. A
signed zone will contain additional security-related records (RRSIG,
DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
generated by a signing process prior to serving the zone. The RRSIG
records that accompany zone data have defined inception and
expiration times, which establish a validity period for the
signatures and the zone data the signatures cover.
7.1 TTL values vs. RRSIG validity period
It is important to note the distinction between a RRset's TTL value
and the signature validity period specified by the RRSIG RR covering
that RRset. DNSSEC does not change the definition or function of the
TTL value, which is intended to maintain database coherency in
caches. A caching resolver purges RRsets from its cache no later than
the end of the time period specified by the TTL fields of those
RRsets, regardless of whether or not the resolver is security-aware.
The inception and expiration fields in the RRSIG RR
[I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
period during which the signature can be used to validate the RRset
that it covers. The signatures associated with signed zone data are
only valid for the time period specified by these fields in the RRSIG
RRs in question. TTL values cannot extend the validity period of
signed RRsets in a resolver's cache, but the resolver may use the
time remaining before expiration of the signature validity period of
a signed RRset as an upper bound for the TTL of the signed RRset and
its associated RRSIG RR in the resolver's cache.
7.2 New Temporal Dependency Issues for Zones
Information in a signed zone has a temporal dependency which did not
exist in the original DNS protocol. A signed zone requires regular
maintenance to ensure that each RRset in the zone has a current valid
RRSIG RR. The signature validity period of an RRSIG RR is an
interval during which the signature for one particular signed RRset
can be considered valid, and the signatures of different RRsets in a
zone may expire at different times. Re-signing one or more RRsets in
a zone will change one or more RRSIG RRs, which in turn will require
incrementing the zone's SOA serial number to indicate that a zone
change has occurred and re-signing the SOA RRset itself. Thus,
re-signing any RRset in a zone may also trigger DNS NOTIFY messages
and zone transfers operations.
Arends, et al. Expires April 26, 2004 [Page 13]
Internet-Draft DNSSEC Introduction and Requirements October 2003
8. Name Server Considerations
A security-aware name server should include the appropriate DNSSEC
records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message
size limitations. For this reason a security-aware name server must
support the EDNS mechanism size extension, since otherwise inclusion
of DNSSEC RRs could easily cause UDP message truncation and fallback
to TCP.
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
dynamic update has been enabled. In the dynamic update case, the
primary master server for the zone will have to re-sign the zone when
updated, so the private half of the zone signing key will have to be
kept online. This is an example of a situation where the ability to
separate the zone's DNSKEY RRset into zone signing key(s) and key
signing key(s) may be useful, since the key singing key(s) in such a
case can still be kept offline.
DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone
contains some unsigned data if the zone has any children, so zone
maintenance operations will require some additional mechanisms (most
likely some form of channel security, such as TSIG, SIG(0), or
IPsec).
Arends, et al. Expires April 26, 2004 [Page 14]
Internet-Draft DNSSEC Introduction and Requirements October 2003
9. DNS Security Document Family
The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All of these documents are in turn under
the larger umbrella of the DNS base protocol documents.
9.1 DNS Security Document Roadmap
+----------------------------------+
| Base DNS Protocol Documents |
| [RFC1035, RFC2181, et sequentia] |
+----------------------------------+
|
|
+-----------+ +----------+
| DNSSEC | | New |
| Protocol |--------->| Security |
| Documents | | Uses |
+-----------+ +----------+
|
|
+---------------- - - - - - - -+
| .
| .
+------------------+ .
| Digital | +------------------+
| Signature | | Transaction |
| Algorithm | | Authentication |
| Implementations | | Implementations |
+------------------+ +------------------+
9.2 Categories of DNS Security Documents
The "DNSSEC protocol document set" refers to the three documents
which form the core of the DNS security extensions:
1. DNS Security Introduction and Requirements (this document)
2. Resource Records for DNS Security Extensions
[I-D.ietf-dnsext-dnssec-records]
3. Protocol Modifications for the DNS Security Extensions
[I-D.ietf-dnsext-dnssec-protocol]
The "Digital Signature Algorithm Implementations" document set refers
to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource
Arends, et al. Expires April 26, 2004 [Page 15]
Internet-Draft DNSSEC Introduction and Requirements October 2003
record format. Each of these documents deals with a specific digital
signature algorithm.
The "Transaction Authentication Implementations" document set refers
to the group of documents that deal with DNS message authentication,
including secret key establishment and verification. While not
strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted to show its relationship to DNSSEC.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. DNSSEC does not provide any direct security for
these new uses, but may be used to support them. Documents that fall
in this category include the use of DNS in the storage and
distribution of certificates [RFC2538].
Arends, et al. Expires April 26, 2004 [Page 16]
Internet-Draft DNSSEC Introduction and Requirements October 2003
10. IANA Considerations
This overview document introduces no new IANA considerations. Please
see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
IANA considerations introduced by DNSSEC.
Arends, et al. Expires April 26, 2004 [Page 17]
Internet-Draft DNSSEC Introduction and Requirements October 2003
11. Security Considerations
This document introduces the DNS security extensions and describes
the document set that contains the new security records and DNS
protocol modifications. This document discusses the capabilities and
limitations of these extensions. The extensions provide data origin
authentication and data integrity using digital signatures over
resource record sets.
In order for a security-aware resolver to validate a DNS response,
all of the intermediate zones must be signed, and all of the
intermediate name servers must be security-aware, as defined in this
document set. A security-aware resolver cannot verify responses
originating from an unsigned zone, from a zone not served by a
security-aware name server, or for any DNS data which the resolver is
only able to obtain through a recursive name server which is not
security-aware. If there is a break in the authentication chain such
that a security-aware resolver cannot obtain and validate the
authentication keys it needs, then the security-aware resolver cannot
validate the affected DNS data.
This document briefly discusses other methods of adding security to a
DNS query, such as using a channel secured by IPsec or using a DNS
transaction authentication mechanism, but transaction security is not
part of DNSSEC per se.
A security-aware stub resolver, by definition, does not perform
DNSSEC signature validation on its own, and thus is vulnerable both
to attacks on (and by) the security-aware recursive name servers
which perform these checks on its behalf and also to attacks on its
communication with those security-aware recursive name servers.
Security-aware stub resolvers should use some form of channel
security to defend against the latter threat. The only known defense
against the former threat would be for the security-aware stub
resolver to perform its own signature validation, at which point,
again by definition, it would no longer be a security-aware stub
resolver.
DNSSEC does not protect against denial of service attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks
based on cryptographic operations against security-aware resolvers
and security-aware name servers, since an attacker can attempt to use
DNSSEC mechanisms to consume a victim's resources. This class of
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with RRSIG RRs in response messages or by constructing
needlessly complex signature chains. An attacker may also be able to
consume resources in a security-aware name server which supports DNS
Arends, et al. Expires April 26, 2004 [Page 18]
Internet-Draft DNSSEC Introduction and Requirements October 2003
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary.
DNSSEC introduces the ability for a hostile party to enumerate all
the names in a zone by following the NSEC chain. NSEC RRs assert
which names do not exist in a zone by linking from existing name to
existing name along a canonical ordering of all the names within a
zone. Thus, an attacker can query these NSEC RRs in sequence to
obtain all the names in a zone. While not an attack on the DNS
itself, this could allow an attacker to map network hosts or other
resources by enumerating the contents of a zone. There are non-DNS
protocol means of limiting this attack such as limiting the number of
NSEC queries from a single host, use of intrusion detection tools,
etc.
DNSSEC does not provide confidentiality, due to a deliberate design
choice.
DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent
zone) are not signed. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer
operations.
Arends, et al. Expires April 26, 2004 [Page 19]
Internet-Draft DNSSEC Introduction and Requirements October 2003
12. Acknowledgements
This document was created from the input and ideas of several members
of the DNS Extensions Working Group. The editors would like to
acknowledge (in alphabetical order) the following people for their
contributions and comments on this document: Derek Atkins, Donald
Eastlake, Miek Gieben, Olafur Gudmundsson, Olaf Kolkman, Ed Lewis,
Ted Lindgreen, Bill Manning, and Brian Wellington.
Arends, et al. Expires April 26, 2004 [Page 20]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-05 (work in progress),
October 2003.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in
progress), October 2003.
Arends, et al. Expires April 26, 2004 [Page 21]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Informative References
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[I-D.ietf-dnsext-dns-threats]
Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Name System", draft-ietf-dnsext-dns-threats-04 (work in
progress), October 2003.
[I-D.ietf-dnsext-ad-is-secure]
Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD
bit", draft-ietf-dnsext-ad-is-secure-06 (work in
progress), June 2002.
[I-D.ietf-dnsext-delegation-signer]
Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
[I-D.ietf-dnsext-dnssec-2535typecode-change]
Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05
(work in progress), October 2003.
[I-D.ietf-dnsext-keyrr-key-signing-flag]
Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag",
draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in
progress), October 2003.
Arends, et al. Expires April 26, 2004 [Page 22]
Internet-Draft DNSSEC Introduction and Requirements October 2003
Authors' Addresses
Roy Arends
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Software Consortium
40 Gavin Circle
Reading, MA 01867
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
USC Information Sciences Institute
3811 N. Fairfax Drive
Arlington, VA 22203
USA
EMail: masseyd@isi.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Arends, et al. Expires April 26, 2004 [Page 23]
Internet-Draft DNSSEC Introduction and Requirements October 2003
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 (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 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
Arends, et al. Expires April 26, 2004 [Page 24]
Internet-Draft DNSSEC Introduction and Requirements October 2003
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.
Arends, et al. Expires April 26, 2004 [Page 25]
