< draft-ietf-dnsext-dnssec-intro-09.txt   draft-ietf-dnsext-dnssec-intro-10.txt >
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: August 16, 2004 R. Austein Expires: November 15, 2004 R. Austein
ISC ISC
M. Larson M. Larson
VeriSign VeriSign
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
February 16, 2004 May 17, 2004
DNS Security Introduction and Requirements DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-09 draft-ietf-dnsext-dnssec-intro-10
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2004. This Internet-Draft will expire on November 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The Domain Name System Security Extensions (DNSSEC) add data origin The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This authentication and data integrity to the Domain Name System. This
document introduces these extensions, and describes their document introduces these extensions, and describes their
capabilities and limitations. This document also discusses the capabilities and limitations. This document also discusses the
services that the DNS security extensions do and do not provide. services that the DNS security extensions do and do not provide.
Last, this document describes the interrelationships between the Last, this document describes the interrelationships between the
group of documents that collectively describe DNSSEC. group of documents that collectively describe DNSSEC.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . . 7 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7 3.1 Data Origin Authentication and Data Integrity . . . . . . 8
3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . . 10 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16
8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16
9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 20 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
Informative References . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 26
1. Introduction 1. Introduction
This document introduces the Domain Name System Security Extensions This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and its two companion documents (DNSSEC). This document and its two companion documents
([I-D.ietf-dnsext-dnssec-records] and ([I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
security extensions defined in RFC 2535 [RFC2535] and its security extensions defined in RFC 2535 [RFC2535] and its
predecessors. These security extensions consist of a set of new predecessors. These security extensions consist of a set of new
resource record types and modifications to the existing DNS protocol resource record types and modifications to the existing DNS protocol
[RFC1035]. The new records and protocol modifications are not fully [RFC1035]. The new records and protocol modifications are not fully
described in this document, but are described in a family of described in this document, but are described in a family of
documents outlined in Section 9. Section 3 and Section 4 describe the documents outlined in Section 10. Section 3 and Section 4 describe
capabilities and limitations of the security extensions in greater the capabilities and limitations of the security extensions in
detail. Section 5, Section 6, Section 7, and Section 8 discuss the greater detail. Section 5 discusses the scope of the document set.
effect that these security extensions will have on resolvers, stub Section 6, Section 7, Section 8, and Section 9 discuss the effect
that these security extensions will have on resolvers, stub
resolvers, zones and name servers. resolvers, zones and name servers.
This document and its two companions update and obsolete RFCs 2535 This document and its two companions update and obsolete RFCs 2535
[RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
[RFC3445], as well as several works in progress: "Redefinition of the [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
Signer Resource Record" [RFC3658]. This document set also updates, [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 of 3226 [RFC3226] (dealing with DNSSEC).
[RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597].
The DNS security extensions provide origin authentication and The DNS security extensions provide origin authentication and
integrity protection for DNS data, as well as a means of public key integrity protection for DNS data, as well as a means of public key
distribution. These extensions do not provide confidentiality. distribution. These extensions do not provide confidentiality.
2. Definitions of Important DNSSEC Terms 2. Definitions of Important DNSSEC Terms
This section defines a number of terms used in this document set. This section defines a number of terms used in this document set.
Since this is intended to be useful as a reference while reading the Since this is intended to be useful as a reference while reading the
rest of the document set, first-time readers may wish to skim this rest of the document set, first-time readers may wish to skim this
section quickly, read the rest of this document, then come back to section quickly, read the rest of this document, then come back to
this section. this section.
authentication chain: an alternating sequence of DNSKEY RRsets and DS Authentication Chain: An alternating sequence of DNSKEY RRsets and DS
RRsets forms a chain of signed data, with each link in the chain RRsets forms a chain of signed data, with each link in the chain
vouching for the next. A DNSKEY RR is used to verify the vouching for the next. A DNSKEY RR is used to verify the
signature covering a DS RR and allows the DS RR to be signature covering a DS RR and allows the DS RR to be
authenticated. The DS RR contains a hash of another DNSKEY RR and 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 this new DNSKEY RR is authenticated by matching the hash in the DS
RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
and, in turn, some DNSKEY RR in this set may be used to and, in turn, some DNSKEY RR in this set may be used to
authenticate another DS RR and so forth until the chain finally authenticate another DS RR and so forth until the chain finally
ends with a DNSKEY RR which signs the desired DNS data. For ends with a DNSKEY RR whose corresponding private key signs the
example, the root DNSKEY RRset can be used to authenticate the DS desired DNS data. For example, the root DNSKEY RRset can be used
RRset for "example." The "example." DS RRset contains a hash that to authenticate the DS RRset for "example." The "example." DS
matches some "example." DNSKEY and this DNSKEY signs the RRset contains a hash that matches some "example." DNSKEY, and
"example." DNSKEY RRset. Private key counterparts of the this DNSKEY's corresponding private key signs the "example."
"example." DNSKEY RRset sign data records such as "www.example." DNSKEY RRset. Private key counterparts of the "example." DNSKEY
as well as DS RRs for delegations such as "subzone.example." 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 Authentication Key: A public key that a security-aware resolver has
verified and can therefore use to authenticate data. A verified and can therefore use to authenticate data. A
security-aware resolver can obtain authentication keys in three security-aware resolver can obtain authentication keys in three
ways. First, the resolver is generally preconfigured to know ways. First, the resolver is generally configured to know about
about at least one public key. This preconfigured data is usually at least one public key; this configured data is usually either
either the public key itself or a hash of the key as found in the the public key itself or a hash of the public key as found in the
DS RR. Second, the resolver may use an authenticated public key DS RR (see "trust anchor"). Second, the resolver may use an
to verify a DS RR and its associated DNSKEY RR. Third, the authenticated public key to verify a DS RR and its associated
resolver may be able to determine that a new key has been signed DNSKEY RR. Third, the resolver may be able to determine that a
by another key which the resolver has verified. Note that the new public key has been signed by the private key corresponding to
another public key which the resolver has verified. Note that the
resolver must always be guided by local policy when deciding resolver must always be guided by local policy when deciding
whether to authenticate a new key, even if the local policy is whether to authenticate a new public key, even if the local policy
simply to authenticate any new key for which the resolver is able is simply to authenticate any new public key for which the
verify the signature. resolver is able verify the signature.
delegation point: Term used to describe the name at the parental side Delegation Point: Term used to describe the name at the parental side
of a zone cut. That is, the delegation point for "foo.example" of a zone cut. That is, the delegation point for "foo.example"
would be the foo.example node in the "example" zone (as opposed to would be the foo.example node in the "example" zone (as opposed to
the zone apex of the "foo.example" zone). the zone apex of the "foo.example" zone).
island of security: Term used to describe a signed, delegated zone Island of Security: Term used to describe a signed, delegated zone
that does not have an authentication chain from its delegating that does not have an authentication chain from its delegating
parent. That is, there is no DS RR with the island's public key parent. That is, there is no DS RR containing a hash of a DNSKEY
in its delegating parent zone (see RR for the island in its delegating parent zone (see
[I-D.ietf-dnsext-dnssec-records]). An island of security is served [I-D.ietf-dnsext-dnssec-records]). An island of security is served
by a security-aware nameserver and may provide authentication by security-aware name servers and may provide authentication
chains to any delegated child zones. Responses from an island of chains to any delegated child zones. Responses from an island of
security or its descendents can only be authenticated if its zone security or its descendents can only be authenticated if its
key can be authenticated by some trusted means out of band from authentication keys can be authenticated by some trusted means out
the DNS protocol. of band from the DNS protocol.
key signing key: An authentication key which is used to sign one or Key Signing Key: An authentication key that corresponds to a private
more other authentication keys for a given zone. Typically, a key key used to sign one or more other authentication keys for a given
signing key will sign a zone signing key, which in turn will sign zone. Typically, the private key corresponding to a key signing
other zone data. Local policy may require the zone signing key to key will sign a zone signing key, which in turn has a
be changed frequently, while the key signing key may have a longer corresponding private key which will sign other zone data. Local
validity period in order to provide a more stable secure entry policy may require the zone signing key to be changed frequently,
point into the zone. Designating an authentication key as a key while the key signing key may have a longer validity period in
signing key is purely an operational issue: DNSSEC validation does order to provide a more stable secure entry point into the zone.
not distinguish between key signing keys and other DNSSEC Designating an authentication key as a key signing key is purely
authentication keys. Key signing keys are discussed in more an operational issue: DNSSEC validation does not distinguish
detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone between key signing keys and other DNSSEC authentication keys, and
signing key. it is possible to use a single key as both a key signing key and a
zone signing key. Key signing keys are discussed in more detail
in [RFC3757]. Also see: zone signing key.
non-validating security-aware stub resolver: A security-aware stub Non-Validating Security-Aware Stub Resolver: A security-aware stub
resolver which trusts one or more security-aware recursive name resolver which trusts one or more security-aware recursive name
servers to perform most of the tasks discussed in this document servers to perform most of the tasks discussed in this document
set on its behalf. In particular, a non-validating security-aware set on its behalf. In particular, a non-validating security-aware
stub resolver is an entity which sends DNS queries, receives DNS stub resolver is an entity which sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub provide these services on behalf of the security-aware stub
resolver. See also: security-aware stub resolver, validating resolver. See also: security-aware stub resolver, validating
security-aware stub resolver. security-aware stub resolver.
non-validating stub resolver: A less tedious term for a Non-Validating Stub Resolver: A less tedious term for a
non-validating security-aware stub resolver. non-validating security-aware stub resolver.
security-aware name server: An entity acting in the role of a name Security-Aware Name Server: An entity acting in the role of a name
server (defined in section 2.4 of [RFC1034]) which understands the server (defined in section 2.4 of [RFC1034]) that understands the
DNS security extensions defined in this document set. In DNS security extensions defined in this document set. In
particular, a security-aware name server is an entity which particular, a security-aware name server is an entity which
receives DNS queries, sends DNS responses, supports the EDNS0 receives DNS queries, sends DNS responses, supports the EDNS0
[RFC2671] message size extension and the DO bit [RFC3225], and [RFC2671] message size extension and the DO bit [RFC3225], and
supports the RR types and message header bits defined in this supports the RR types and message header bits defined in this
document set. document set.
security-aware recursive name server: An entity which acts in both Security-Aware Recursive Name Server: An entity which acts in both
the security-aware name server and security-aware resolver roles. the security-aware name server and security-aware resolver roles.
A more cumbersome equivalent phrase would be "a security-aware A more cumbersome equivalent phrase would be "a security-aware
name server which offers recursive service". name server which offers recursive service".
security-aware resolver: An entity acting in the role of a resolver Security-Aware Resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [RFC1034]) which understands the DNS (defined in section 2.4 of [RFC1034]) which understands the DNS
security extensions defined in this document set. In particular, security extensions defined in this document set. In particular,
a security-aware resolver is an entity which sends DNS queries, a security-aware resolver is an entity which sends DNS queries,
receives DNS responses, supports the EDNS0 [RFC2671] message size receives DNS responses, supports the EDNS0 [RFC2671] message size
extension and the DO bit [RFC3225], and is capable of using the RR extension and the DO bit [RFC3225], and is capable of using the RR
types and message header bits defined in this document set to types and message header bits defined in this document set to
provide DNSSEC services. provide DNSSEC services.
security-aware stub resolver: An entity acting in the role of a stub Security-Aware Stub Resolver: An entity acting in the role of a stub
resolver (defined in section 5.3.1 of [RFC1034]) which has enough resolver (defined in section 5.3.1 of [RFC1034]) which has enough
of an understanding the DNS security extensions defined in this of an understanding the DNS security extensions defined in this
document set to provide additional services not available from a document set to provide additional services not available from a
security-oblivious stub resolver. Security-aware stub resolvers security-oblivious stub resolver. Security-aware stub resolvers
may be either "validating" or "non-validating" depending on may be either "validating" or "non-validating" depending on
whether the stub resolver attempts to verify DNSSEC signatures on whether the stub resolver attempts to verify DNSSEC signatures on
its own or trusts a friendly security-aware name server to do so. its own or trusts a friendly security-aware name server to do so.
See also: validating stub resolver, non-validating stub resolver. See also: validating stub resolver, non-validating stub resolver.
security-oblivious <anything>: An <anything> which is not Security-Oblivious <anything>: An <anything> that is not
"security-aware". "security-aware".
signed zone: A zone whose RRsets are signed and which contains Signed Zone: A zone whose RRsets are signed and which contains
properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
records. records.
unsigned zone: A zone which is not signed. Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
validating security-aware resolver uses this public key or hash as
a starting point for building the authentication chain to a signed
DNS response. In general, a validating resolver will need to
obtain the initial values of its trust anchors via some secure or
trusted means outside the DNS protocol. Presence of a trust
anchor also implies that the resolver should expect the zone to
which the trust anchor points to be signed
validating security-aware stub resolver: A security-aware resolver Unsigned Zone: A zone that is not signed.
which operates sends queries in recursive mode but which performs
signature validation on its own rather than just blindly trusting Validating Security-Aware Stub Resolver: A security-aware resolver
a friendly security-aware recursive name server. See also: that sends queries in recursive mode but which performs signature
validation on its own rather than just blindly trusting an
upstream security-aware recursive name server. See also:
security-aware stub resolver, non-validating security-aware stub security-aware stub resolver, non-validating security-aware stub
resolver. resolver.
validating stub resolver: A less tedious term for a validating Validating Stub Resolver: A less tedious term for a validating
security-aware stub resolver. security-aware stub resolver.
zone signing key: An authentication key which is used to sign a zone. Zone Signing Key: An authentication key that corresponds to a private
See key signing key, above. Typically a zone signing key will be key used to sign a zone. Typically a zone signing key will be
part of the same DNSKEY RRset as the key signing key which signs part of the same DNSKEY RRset as the key signing key whose
it, but is used for a slightly different purpose and may differ corresponding private key signs this DNSKEY RRset, but the zone
from the key signing key in other ways, such as validity lifetime. signing key is used for a slightly different purpose, and may
Designating an authentication key as a zone signing key is purely differ from the key signing key in other ways, such as validity
an operational issue: DNSSEC validation does not distinguish lifetime. Designating an authentication key as a zone signing key
between zone signing keys and other DNSSEC authentication keys. is purely an operational issue: DNSSEC validation does not
See also: key signing key. distinguish between zone signing keys and other DNSSEC
authentication keys, and it is possible to use a single key as
both a key signing key and a zone signing key. See also: key
signing key.
3. Services Provided by DNS Security 3. Services Provided by DNS Security
The Domain Name System (DNS) security extensions provide origin The Domain Name System (DNS) security extensions provide origin
authentication and integrity assurance services for DNS data, authentication and integrity assurance services for DNS data,
including mechanisms for authenticated denial of existence of DNS including mechanisms for authenticated denial of existence of DNS
data. These mechanisms are described below. data. These mechanisms are described below.
These mechanisms require changes to the DNS protocol. DNSSEC adds These mechanisms require changes to the DNS protocol. DNSSEC adds
four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two 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 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 DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
for the DO bit [RFC3225], so that a security-aware resolver can for the DO bit [RFC3225], so that a security-aware resolver can
indicate in its queries that it wishes to receive DNSSEC RRs in indicate in its queries that it wishes to receive DNSSEC RRs in
response messages. response messages.
These services protect against most of the threats to the Domain Name These services protect against most of the threats to the Domain Name
System described in [I-D.ietf-dnsext-dns-threats]. System described in [I-D.ietf-dnsext-dns-threats].
3.1 Data Origin Authentication and Data Integrity 3.1 Data Origin Authentication and Data Integrity
DNSSEC provides authentication by associating cryptographically DNSSEC provides authentication by associating cryptographically
generated digital signatures with DNS RRsets. These digital generated digital signatures with DNS RRsets. These digital
signatures are stored in a new resource record, the RRSIG record. signatures are stored in a new resource record, the RRSIG record.
Typically, there will be a single private key that signs a zone's 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 data, but multiple keys are possible: for example, there may be keys
for each of several different digital signature algorithms. If a for each of several different digital signature algorithms. If a
security-aware resolver reliably learns a zone's public key, it can security-aware resolver reliably learns a zone's public key, it can
authenticate that zone's signed data. An important DNSSEC concept is 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 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 itself and not with the zone's authoritative name servers (public
keys for DNS transaction authentication mechanisms may also appear in keys for DNS transaction authentication mechanisms may also appear in
zones, as described in [RFC2931], but DNSSEC itself is concerned with zones, as described in [RFC2931], but DNSSEC itself is concerned with
object security of DNS data, not channel security of DNS object security of DNS data, not channel security of DNS
transactions). transactions).
A security-aware resolver can learn a zone's public key either by A security-aware resolver can learn a zone's public key either by
having the key preconfigured into the resolver or by normal DNS having a trust anchor configured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new resolution. To allow the latter, public keys are stored in a new
type of resource record, the DNSKEY RR. Note that the private keys 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 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 offline when practical to do so. To discover a public key reliably
via DNS resolution, the target key itself needs to be signed by via DNS resolution, the target key itself needs to be signed by
either a preconfigured authentication key or another key that has either a configured authentication key or another key that has been
been authenticated previously. Security-aware resolvers authenticate authenticated previously. Security-aware resolvers authenticate zone
zone information by forming an authentication chain from a newly information by forming an authentication chain from a newly learned
learned public key back to a previously known authentication public public key back to a previously known authentication public key,
key, which in turn either must have been preconfigured into the which in turn either has been configured into the resolver or must
resolver or must have been learned and verified previously. have been learned and verified previously. Therefore, the resolver
Therefore, the resolver must be configured with at least one public must be configured with at least one trust anchor. If the configured
key or hash of a public key: if the preconfigured key is a zone key is a zone signing key, then it will authenticate the associated
signing key, then it will authenticate the associated zone; if the zone; if the configured key is a key signing key, it will
preconfigured key is a key signing key, it will authenticate a zone authenticate a zone signing key. If the resolver has been configured
signing key. If the resolver has been preconfigured with the hash of with the hash of a key rather than the key itself, the resolver may
a key rather than the key itself, the resolver may need to obtain the need to obtain the key via a DNS query. To help security-aware
key via a DNS query. To help security-aware resolvers establish this resolvers establish this authentication chain, security-aware name
authentication chain, security-aware name servers attempt to send the servers attempt to send the signature(s) needed to authenticate a
signature(s) needed to authenticate a zone's public key in the DNS zone's public key(s) in the DNS reply message along with the public
reply message along with the public key itself, provided there is key itself, provided there is space available in the message.
space available in the message.
The Delegation Signer (DS) RR type simplifies some of the The Delegation Signer (DS) RR type simplifies some of the
administrative tasks involved in signing delegations across administrative tasks involved in signing delegations across
organizational boundaries. The DS RRset resides at a delegation organizational boundaries. The DS RRset resides at a delegation
point in a parent zone and indicates the key or keys used by the point in a parent zone and indicates the public key(s) corresponding
delegated child zone to self-sign the DNSKEY RRset at the child to the private key(s) used to self-sign the DNSKEY RRset at the
zone's apex. The child zone, in turn, uses one or more of the keys delegated child zone's apex. The administrator of the child zone, in
in this DNSKEY RRset to sign its zone data. The typical turn, uses the private key(s) corresponding to one or more of the
authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where public keys in this DNSKEY RRset to sign the child zone's data. The
"*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more typical authentication chain is therefore
complex authentication chains, such as additional layers of DNSKEY DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
RRs signing other DNSKEY RRs within a zone. DS->DNSKEY subchains. DNSSEC permits more complex authentication
chains, such as additional layers of DNSKEY RRs signing other DNSKEY
RRs within a zone.
A security-aware resolver normally constructs this authentication A security-aware resolver normally constructs this authentication
chain from the root of the DNS hierarchy down to the leaf zones based chain from the root of the DNS hierarchy down to the leaf zones based
on preconfigured knowledge of the public key for the root. Local on configured knowledge of the public key for the root. Local
policy, however, may also allow a security-aware resolver to use one 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 more configured public keys (or hashes of public keys) other than
or may not provide preconfigured knowledge of the root key, or may the root public key, or may not provide configured knowledge of the
prevent the resolver from using particular keys for arbitrary reasons root public key, or may prevent the resolver from using particular
even if those keys are properly signed with verifiable signatures. public keys for arbitrary reasons even if those public keys are
DNSSEC provides mechanisms by which a security-aware resolver can properly signed with verifiable signatures. DNSSEC provides
determine whether an RRset's signature is "valid" within the meaning mechanisms by which a security-aware resolver can determine whether
of DNSSEC. In the final analysis however, authenticating both DNS an RRset's signature is "valid" within the meaning of DNSSEC. In the
keys and data is a matter of local policy, which may extend or even final analysis however, authenticating both DNS keys and data is a
override the protocol extensions defined in this document set. matter of local policy, which may extend or even override the
protocol extensions defined in this document set. See for further
discussion.
3.2 Authenticating Name and Type Non-Existence 3.2 Authenticating Name and Type Non-Existence
The security mechanism described in Section 3.1 only provides a way The security mechanism described in Section 3.1 only provides a way
to sign existing RRsets in a zone. The problem of providing negative to sign existing RRsets in a zone. The problem of providing negative
responses with the same level of authentication and integrity responses with the same level of authentication and integrity
requires the use of another new resource record type, the NSEC requires the use of another new resource record type, the NSEC
record. The NSEC record allows a security-aware resolver to record. The NSEC record allows a security-aware resolver to
authenticate a negative reply for either name or type non-existence authenticate a negative reply for either name or type non-existence
via the same mechanisms used to authenticate other DNS replies. Use via the same mechanisms used to authenticate other DNS replies. Use
of NSEC records requires a canonical representation and ordering for of NSEC records requires a canonical representation and ordering for
domain names in zones. Chains of NSEC records explicitly describe domain names in zones. Chains of NSEC records explicitly describe
the gaps, or "empty space", between domain names in a zone, as well the gaps, or "empty space", between domain names in a zone, as well
as listing the types of RRsets present at existing names. Each NSEC as listing the types of RRsets present at existing names. Each NSEC
record is signed and authenticated using the mechanisms described in record is signed and authenticated using the mechanisms described in
Section 3.1. Section 3.1.
4. Services Not Provided by DNS Security 4. Services Not Provided by DNS Security
DNS was originally designed with the assumptions that the DNS will DNS was originally designed with the assumptions that the DNS will
return the same answer to any given query regardless of who may have 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. issued the query, and that all data in the DNS is thus visible.
Accordingly, DNSSEC is not designed to provide confidentiality, Accordingly, DNSSEC is not designed to provide confidentiality,
access control lists, or other means of differentiating between access control lists, or other means of differentiating between
inquirers. inquirers.
DNSSEC provides no protection against denial of service attacks. DNSSEC provides no protection against denial of service attacks.
Security-aware resolvers and security-aware name servers are Security-aware resolvers and security-aware name servers are
vulnerable to an additional class of denial of service attacks based vulnerable to an additional class of denial of service attacks based
on cryptographic operations. Please see Section 11 for details. on cryptographic operations. Please see Section 12 for details.
The DNS security extensions provide data and origin authentication The DNS security extensions provide data and origin authentication
for DNS data. The mechanisms outlined above are not designed to for DNS data. The mechanisms outlined above are not designed to
protect operations such as zone transfers and dynamic update protect operations such as zone transfers and dynamic update
[RFC3007]. Message authentication schemes described in [RFC2845] and [RFC3007]. Message authentication schemes described in [RFC2845] and
[RFC2931] address security operations that pertain to these [RFC2931] address security operations that pertain to these
transactions. transactions.
5. Resolver Considerations 5. Scope of the DNSSEC Document Set and Last Hop Issues
The specification in this document set defines the behavior for zone
signers and security-aware name servers and resolvers in such a way
that the validating entities can unambiguously determine the state of
the data.
A validating resolver can determine these 4 states:
Secure: The validating resolver has a trust anchor, a chain of trust
and is able to verify all the signatures in the response.
Insecure: The validating resolver has a trust anchor, a chain of
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. That indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have local policy to mark parts of the domain space as
insecure.
Bogus: The validating resolver has a trust anchor and there is a
secure delegation which is indicating that subsidiary data will be
signed, but the response fails to validate due to one or more
reasons: missing signatures, expired signatures, signatures with
unsupported algorithms, data missing which the relevant NSEC RR
says should be present, and so forth.
Indeterminate: There is no trust anchor which would indicate that a
specific portion of the tree is secure. This is the default
operation mode.
This specification only defines how security aware name servers can
signal non-validating stub resolvers that data was found to be bogus
(using RCODE=2, "Server Failure" -- see
[I-D.ietf-dnsext-dnssec-protocol]).
There is a mechanism for security aware name servers to signal
security-aware stub resolvers that data was found to be secure (using
the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
This specification does not define a format for communicating why
responses were found to be bogus or marked as insecure. The current
signaling mechanism does not distinguish between indeterminate and
insecure.
A method for signaling advanced error codes and policy between a
security aware stub resolver and security aware recursive nameservers
is a topic for future work, as is the interface between a security
aware resolver and the applications that use it. Note, however, that
the lack of the specification of such communication does not prohibit
deployment of signed zones or the deployment of security aware
recursive name servers that prohibit propagation of bogus data to the
applications.
6. Resolver Considerations
A security-aware resolver needs to be able to perform cryptographic A security-aware resolver needs to be able to perform cryptographic
functions necessary to verify digital signatures using at least the functions necessary to verify digital signatures using at least the
mandatory-to-implement algorithm(s). Security-aware resolvers must mandatory-to-implement algorithm(s). Security-aware resolvers must
also be capable of forming an authentication chain from a newly also be capable of forming an authentication chain from a newly
learned zone back to an authentication key, as described above. This learned zone back to an authentication key, as described above. This
process might require additional queries to intermediate DNS zones to process might require additional queries to intermediate DNS zones to
obtain necessary DNSKEY, DS and RRSIG records. A security-aware obtain necessary DNSKEY, DS and RRSIG records. A security-aware
resolver should be configured with at least one authentication key or resolver should be configured with at least one trust anchor as the
a key's DS RR hash as the starting point from which it will attempt starting point from which it will attempt to establish authentication
to establish authentication chains. chains.
If a security-aware resolver is separated from the relevant If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver server or proxy is not security-aware, the security-aware resolver
may not be capable of operating in a secure mode. For example, if a may not be capable of operating in a secure mode. For example, if a
security-aware resolver's packets are routed through a network security-aware resolver's packets are routed through a network
address translation device that includes a DNS proxy which is not address translation device that includes a DNS proxy which is not
security-aware, the security-aware resolver may find it difficult or security-aware, the security-aware resolver may find it difficult or
impossible to obtain or validate signed DNS data. impossible to obtain or validate signed DNS data.
skipping to change at page 12, line 5 skipping to change at page 15, line 5
signature, but should also allow for the possibility that the signature, but should also allow for the possibility that the
security-aware resolver's own clock is wrong. Thus, a security-aware security-aware resolver's own clock is wrong. Thus, a security-aware
resolver which is part of a security-aware recursive name server will resolver which is part of a security-aware recursive name server will
need to pay careful attention to the DNSSEC "checking disabled" (CD) need to pay careful attention to the DNSSEC "checking disabled" (CD)
bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid
blocking valid signatures from getting through to other blocking valid signatures from getting through to other
security-aware resolvers which are clients of this recursive name security-aware resolvers which are clients of this recursive name
server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure
recursive server handles queries with the CD bit set. recursive server handles queries with the CD bit set.
6. Stub Resolver Considerations 7. Stub Resolver Considerations
Although not strictly required to do so by the protocol, most DNS Although not strictly required to do so by the protocol, most DNS
queries originate from stub resolvers. Stub resolvers, by queries originate from stub resolvers. Stub resolvers, by
definition, are minimal DNS resolvers which use recursive query mode definition, are minimal DNS resolvers which use recursive query mode
to offload most of the work of DNS resolution to a recursive name to offload most of the work of DNS resolution to a recursive name
server. Given the widespread use of stub resolvers, the DNSSEC server. Given the widespread use of stub resolvers, the DNSSEC
architecture has to take stub resolvers into account, but the architecture has to take stub resolvers into account, but the
security features needed in a stub resolver differ in some respects security features needed in a stub resolver differ in some respects
from those needed in a full security-aware resolver. from those needed in a full security-aware resolver.
Even an unaugmented stub resolver may get some benefit from DNSSEC if Even a security-oblivious stub resolver may get some benefit from
the recursive name servers it uses are security-aware, but for the DNSSEC if the recursive name servers it uses are security-aware, but
stub resolver to place any real reliance on DNSSEC services, the stub for the stub resolver to place any real reliance on DNSSEC services,
resolver must trust both the recursive name servers in question and the stub resolver must trust both the recursive name servers in
the communication channels between itself and those name servers. question and the communication channels between itself and those name
The first of these issues is a local policy issue: in essence, a servers. The first of these issues is a local policy issue: in
security-oblivious stub resolver has no real choice but to place essence, a security-oblivious stub resolver has no real choice but to
itself at the mercy of the recursive name servers that it uses, since place itself at the mercy of the recursive name servers that it uses,
it does not perform DNSSEC validity checks on its own. The second since it does not perform DNSSEC validity checks on its own. The
issue requires some kind of channel security mechanism; proper use of second issue requires some kind of channel security mechanism; proper
DNS transaction authentication mechanisms such as SIG(0) or TSIG use of DNS transaction authentication mechanisms such as SIG(0) or
would suffice, as would appropriate use of IPsec, and particular TSIG would suffice, as would appropriate use of IPsec, and particular
implementations may have other choices available, such as operating implementations may have other choices available, such as operating
system specific interprocess communication mechanisms. system specific interprocess communication mechanisms.
Confidentiality is not needed for this channel, but data integrity Confidentiality is not needed for this channel, but data integrity
and message authentication are. and message authentication are.
A security-aware stub resolver which does trust both its recursive A security-aware stub resolver that does trust both its recursive
name servers and its communication channel to them may choose to name servers and its communication channel to them may choose to
examine the setting of the AD bit in the message header of the examine the setting of the AD bit in the message header of the
response messages it receives. The stub resolver can use this flag 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 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 to validate signatures for all of the data in the Answer and
Authority sections of the response. Authority sections of the response.
There is one more step which a security-aware stub resolver can take There is one more step that a security-aware stub resolver can take
if, for whatever reason, it is not able to establish a useful trust if, for whatever reason, it is not able to establish a useful trust
relationship with the recursive name servers which it uses: it can relationship with the recursive name servers which it uses: it can
perform its own signature validation, by setting the Checking perform its own signature validation, by setting the Checking
Disabled (CD) bit in its query messages. A validating stub resolver Disabled (CD) bit in its query messages. A validating stub resolver
is thus able to treat the DNSSEC signatures as a trust relationship is thus able to treat the DNSSEC signatures as a trust relationship
between the zone administrator and the stub resolver itself. between the zone administrator and the stub resolver itself.
7. Zone Considerations 8. Zone Considerations
There are several differences between signed and unsigned zones. A There are several differences between signed and unsigned zones. A
signed zone will contain additional security-related records (RRSIG, signed zone will contain additional security-related records (RRSIG,
DNSKEY, DS and NSEC records). RRSIG and NSEC records may be DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
generated by a signing process prior to serving the zone. The RRSIG generated by a signing process prior to serving the zone. The RRSIG
records that accompany zone data have defined inception and records that accompany zone data have defined inception and
expiration times, which establish a validity period for the expiration times, which establish a validity period for the
signatures and the zone data the signatures cover. signatures and the zone data the signatures cover.
7.1 TTL values vs. RRSIG validity period 8.1 TTL values vs. RRSIG validity period
It is important to note the distinction between a RRset's TTL value It is important to note the distinction between a RRset's TTL value
and the signature validity period specified by the RRSIG RR covering and the signature validity period specified by the RRSIG RR covering
that RRset. DNSSEC does not change the definition or function of the that RRset. DNSSEC does not change the definition or function of the
TTL value, which is intended to maintain database coherency in TTL value, which is intended to maintain database coherency in
caches. A caching resolver purges RRsets from its cache no later than 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 the end of the time period specified by the TTL fields of those
RRsets, regardless of whether or not the resolver is security-aware. RRsets, regardless of whether or not the resolver is security-aware.
The inception and expiration fields in the RRSIG RR The inception and expiration fields in the RRSIG RR
[I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time [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 period during which the signature can be used to validate the covered
that it covers. The signatures associated with signed zone data are RRset. The signatures associated with signed zone data are only
only valid for the time period specified by these fields in the RRSIG valid for the time period specified by these fields in the RRSIG RRs
RRs in question. TTL values cannot extend the validity period of in question. TTL values cannot extend the validity period of signed
signed RRsets in a resolver's cache, but the resolver may use the RRsets in a resolver's cache, but the resolver may use the time
time remaining before expiration of the signature validity period of remaining before expiration of the signature validity period of a
a signed RRset as an upper bound for the TTL of the signed RRset and signed RRset as an upper bound for the TTL of the signed RRset and
its associated RRSIG RR in the resolver's cache. its associated RRSIG RR in the resolver's cache.
7.2 New Temporal Dependency Issues for Zones 8.2 New Temporal Dependency Issues for Zones
Information in a signed zone has a temporal dependency which did not Information in a signed zone has a temporal dependency which did not
exist in the original DNS protocol. A signed zone requires regular exist in the original DNS protocol. A signed zone requires regular
maintenance to ensure that each RRset in the zone has a current valid 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 RRSIG RR. The signature validity period of an RRSIG RR is an
interval during which the signature for one particular signed RRset interval during which the signature for one particular signed RRset
can be considered valid, and the signatures of different RRsets in a 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 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 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 incrementing the zone's SOA serial number to indicate that a zone
change has occurred and re-signing the SOA RRset itself. Thus, change has occurred and re-signing the SOA RRset itself. Thus,
re-signing any RRset in a zone may also trigger DNS NOTIFY messages re-signing any RRset in a zone may also trigger DNS NOTIFY messages
and zone transfers operations. and zone transfers operations.
8. Name Server Considerations 9. Name Server Considerations
A security-aware name server should include the appropriate DNSSEC A security-aware name server should include the appropriate DNSSEC
records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
resolvers which have signaled their willingness to receive such resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message records via use of the DO bit in the EDNS header, subject to message
size limitations. Since inclusion of these DNSSEC RRs could easily size limitations. Since inclusion of these DNSSEC RRs could easily
cause UDP message truncation and fallback to TCP, a security-aware cause UDP message truncation and fallback to TCP, a security-aware
name server must also support the EDNS "sender's UDP payload" name server must also support the EDNS "sender's UDP payload"
mechanism. mechanism.
If possible, the private half of each DNSSEC key pair should be kept If possible, the private half of each DNSSEC key pair should be kept
offline, but this will not be possible for a zone for which DNS offline, but this will not be possible for a zone for which DNS
dynamic update has been enabled. In the dynamic update case, the 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 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 updated, so the private key corresponding to the zone signing key
kept online. This is an example of a situation where the ability to will have to be kept online. This is an example of a situation where
separate the zone's DNSKEY RRset into zone signing key(s) and key the ability to separate the zone's DNSKEY RRset into zone signing
signing key(s) may be useful, since the key signing key(s) in such a key(s) and key signing key(s) may be useful, since the key signing
case can still be kept offline. key(s) in such a case can still be kept offline and may have a longer
useful lifetime than the zone signing key(s).
DNSSEC, by itself, is not enough to protect the integrity of an DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone entire zone during zone transfer operations, since even a signed zone
contains some unsigned, nonauthoritative data if the zone has any contains some unsigned, nonauthoritative data if the zone has any
children, so zone maintenance operations will require some additional children. Therefore, zone maintenance operations will require some
mechanisms (most likely some form of channel security, such as TSIG, additional mechanisms (most likely some form of channel security,
SIG(0), or IPsec). such as TSIG, SIG(0), or IPsec).
9. DNS Security Document Family 10. DNS Security Document Family
The DNSSEC document set can be partitioned into several main groups, The DNSSEC document set can be partitioned into several main groups,
under the larger umbrella of the DNS base protocol documents. under the larger umbrella of the DNS base protocol documents.
The "DNSSEC protocol document set" refers to the three documents The "DNSSEC protocol document set" refers to the three documents
which form the core of the DNS security extensions: which form the core of the DNS security extensions:
1. DNS Security Introduction and Requirements (this document) 1. DNS Security Introduction and Requirements (this document)
2. Resource Records for DNS Security Extensions 2. Resource Records for DNS Security Extensions
[I-D.ietf-dnsext-dnssec-records] [I-D.ietf-dnsext-dnssec-records]
3. Protocol Modifications for the DNS Security Extensions 3. Protocol Modifications for the DNS Security Extensions
[I-D.ietf-dnsext-dnssec-protocol] [I-D.ietf-dnsext-dnssec-protocol]
Additionally, any document that would add to, or change the core DNS
Security extensions would fall into this category. This includes any
future work on the communication between security-aware stub
resolvers and upstream security-aware recursive name servers.
The "Digital Signature Algorithm Specification" document set refers The "Digital Signature Algorithm Specification" document set refers
to the group of documents that describe how specific digital to the group of documents that describe how specific digital
signature algorithms should be implemented to fit the DNSSEC resource signature algorithms should be implemented to fit the DNSSEC resource
record format. Each of these documents deals with a specific digital record format. Each document in this set deals with a specific
signature algorithm. digital signature algorithm.
The "Transaction Authentication Protocol" document set refers to the The "Transaction Authentication Protocol" document set refers to the
group of documents that deal with DNS message authentication, group of documents that deal with DNS message authentication,
including secret key establishment and verification. While not including secret key establishment and verification. While not
strictly part of the DNSSEC specification as defined in this set of strictly part of the DNSSEC specification as defined in this set of
documents, this group is noted to show its relationship to DNSSEC. documents, this group is noted because of its relationship to DNSSEC.
The final document set, "New Security Uses", refers to documents that The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security seek to use proposed DNS Security extensions for other security
related purposes. DNSSEC does not provide any direct security for related purposes. DNSSEC does not provide any direct security for
these new uses, but may be used to support them. Documents that fall 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 in this category include the use of DNS in the storage and
distribution of certificates [RFC2538]. distribution of certificates [RFC2538].
10. IANA Considerations 11. IANA Considerations
This overview document introduces no new IANA considerations. Please This overview document introduces no new IANA considerations. Please
see [I-D.ietf-dnsext-dnssec-records] for a complete review of the see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
IANA considerations introduced by DNSSEC. IANA considerations introduced by DNSSEC.
11. Security Considerations 12. Security Considerations
This document introduces the DNS security extensions and describes This document introduces the DNS security extensions and describes
the document set that contains the new security records and DNS the document set that contains the new security records and DNS
protocol modifications. This document discusses the capabilities and protocol modifications. The extensions provide data origin
limitations of these extensions. The extensions provide data origin
authentication and data integrity using digital signatures over authentication and data integrity using digital signatures over
resource record sets. resource record sets.This document discusses the capabilities and
limitations of these extensions.
In order for a security-aware resolver to validate a DNS response, In order for a security-aware resolver to validate a DNS response,
all zones along the path from the trusted starting point to the zone all zones along the path from the trusted starting point to the zone
containing the response zones must be signed, and all name servers containing the response zones must be signed, and all name servers
and resolvers involved in the resolution process must be and resolvers involved in the resolution process must be
security-aware, as defined in this document set. A security-aware security-aware, as defined in this document set. A security-aware
resolver cannot verify responses originating from an unsigned zone, resolver cannot verify responses originating from an unsigned zone,
from a zone not served by a security-aware name server, or for any 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 DNS data which the resolver is only able to obtain through a
recursive name server which is not security-aware. If there is a recursive name server which is not security-aware. If there is a
skipping to change at page 19, line 5 skipping to change at page 22, line 5
data itself is vulnerable to tampering during zone transfer data itself is vulnerable to tampering during zone transfer
operations. Thus, while DNSSEC can provide data origin operations. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer zones, and other mechanisms must be used to protect zone transfer
operations. operations.
Please see [I-D.ietf-dnsext-dnssec-records] and Please see [I-D.ietf-dnsext-dnssec-records] and
[I-D.ietf-dnsext-dnssec-protocol] for additional security [I-D.ietf-dnsext-dnssec-protocol] for additional security
considerations. considerations.
12. Acknowledgements 13. Acknowledgements
This document was created from the input and ideas of the members of This document was created from the input and ideas of the members of
the DNS Extensions Working Group. While explicitly listing everyone the DNS Extensions Working Group. While explicitly listing everyone
who has contributed during the decade during which DNSSEC has been who has contributed during the decade during which DNSSEC has been
under development would be an impossible task, the editors would under development would be an impossible task, the editors would
particularly like to thank the following people for their particularly like to thank the following people for their
contributions to and comments on this document set: Mark Andrews, contributions to and comments on this document set: Mark Andrews,
Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney,
Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael
Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip
Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf
Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted
Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson,
Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik
Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and
Wellington. Brian Wellington.
No doubt the above is an incomplete list. We apologize to anyone we No doubt the above list is incomplete. We apologize to anyone we
left out. left out.
Normative References 14. References
14.1 Normative References
[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-06 (work in
progress), May 2004.
[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-08 (work in progress),
May 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
skipping to change at page 20, line 28 skipping to change at page 23, line 42
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001. message size requirements", RFC 3226, December 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[I-D.ietf-dnsext-dnssec-records] 14.2 Informative References
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-07 (work in progress),
February 2004.
[I-D.ietf-dnsext-dnssec-protocol] [I-D.ietf-dnsext-dns-threats]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Atkins, D. and R. Austein, "Threat Analysis Of The Domain
Rose, "Protocol Modifications for the DNS Security Name System", draft-ietf-dnsext-dns-threats-07 (work in
Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in progress), April 2004.
progress), February 2004.
Informative References [I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "KEY RR Secure Entry Point Flag",
draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
2004.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
skipping to change at page 21, line 45 skipping to change at page 24, line 43
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003. Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003. (RR)", RFC 3658, December 2003.
[I-D.ietf-dnsext-dns-threats] [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Atkins, D. and R. Austein, "Threat Analysis Of The Domain Signer", RFC 3755, April 2004.
Name System", draft-ietf-dnsext-dns-threats-05 (work in
progress), November 2003.
[I-D.ietf-dnsext-dnssec-2535typecode-change]
Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06
(work in progress), December 2003.
[I-D.ietf-dnsext-keyrr-key-signing-flag] [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Entry Point Flag", RFC 3757, April 2004.
Entry Point Flag",
draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in
progress), December 2003.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Drienerlolaan 5
7522 NB Enschede 7522 NB Enschede
NL NL
EMail: roy.arends@telin.nl EMail: roy.arends@telin.nl
skipping to change at page 25, line 7 skipping to change at page 27, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 76 change blocks. 
220 lines changed or deleted 299 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/