draft-ietf-dnsext-dnssec-protocol-08.txt   draft-ietf-dnsext-dnssec-protocol-09.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: March 21, 2005 M. Larson Expires: April 10, 2005 R. Austein
VeriSign
R. Austein
ISC ISC
M. Larson
VeriSign
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
September 20, 2004 October 10, 2004
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-08 draft-ietf-dnsext-dnssec-protocol-09
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 March 21, 2005. This Internet-Draft will expire on April 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
This document is part of a family of documents which describe the DNS This document is part of a family of documents which describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of new resource records and protocol modifications which collection of new resource records and protocol modifications which
add data origin authentication and data integrity to the DNS. This add data origin authentication and data integrity to the DNS. This
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14
3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15
3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16
3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Signature Verification Support . . . . . . . . . . . . . . 19 4.2 Signature Verification Support . . . . . . . . . . . . . . 20
4.3 Determining Security Status of Data . . . . . . . . . . . 20 4.3 Determining Security Status of Data . . . . . . . . . . . 21
4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 22
4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22
4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 23
4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 23
4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 24
4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 24
4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24
4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24
4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 25
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 26
5.1 Special Considerations for Islands of Security . . . . . . 26 5.1 Special Considerations for Islands of Security . . . . . . 27
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 27
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 28
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 29
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 29
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 31
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.4 Authenticating A Wildcard Expanded RRset Positive
Response . . . . . . . . . . . . . . . . . . . . . . . 31 Response . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 32
5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 33
5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 37
9.2 Informative References . . . . . . . . . . . . . . . . . . . 37 9.2 Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 40
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 46
B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 48
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 49
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 50
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 51
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 52
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 53
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 55
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 55
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 55
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 56
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 56
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 56
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 56
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 57
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 57
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . 57 Intellectual Property and Copyright Statements . . . . . . . . 58
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) are a collection of new resource The DNS Security Extensions (DNSSEC) are a collection of new resource
records and protocol modifications which add data origin records and protocol modifications which add data origin
authentication and data integrity to the DNS. This document defines authentication and data integrity to the DNS. This document defines
the DNSSEC protocol modifications. Section 2 of this document the DNSSEC protocol modifications. Section 2 of this document
defines the concept of a signed zone and lists the requirements for defines the concept of a signed zone and lists the requirements for
zone signing. Section 3 describes the modifications to authoritative zone signing. Section 3 describes the modifications to authoritative
name server behavior necessary to handle signed zones. Section 4 name server behavior necessary to handle signed zones. Section 4
skipping to change at page 5, line 8 skipping to change at page 5, line 8
1.2 Reserved Words 1.2 Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]. document are to be interpreted as described in RFC 2119. [RFC2119].
2. Zone Signing 2. Zone Signing
DNSSEC introduces the concept of signed zones. A signed zone DNSSEC introduces the concept of signed zones. A signed zone
includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
the rules specified in Section 2.1, Section 2.2, Section 2.3 and Next Secure (NSEC) and (optionally) Delegation Signer (DS) records
Section 2.4, respectively. A zone that does not include these according to the rules specified in Section 2.1, Section 2.2, Section
records according to the rules in this section is an unsigned zone. 2.3 and Section 2.4, respectively. A zone that does not include
these records according to the rules in this section is an unsigned
zone.
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG
and NSEC RRs to appear at the same owner name as a CNAME RR. and NSEC RRs to appear at the same owner name as a CNAME RR.
DNSSEC specifies the placement of two new RR types, NSEC and DS, DNSSEC specifies the placement of two new RR types, NSEC and DS,
which can be placed at the parental side of a zone cut (that is, at a which can be placed at the parental side of a zone cut (that is, at a
delegation point). This is an exception to the general prohibition delegation point). This is an exception to the general prohibition
against putting data in the parent zone at a zone cut. Section 2.6 against putting data in the parent zone at a zone cut. Section 2.6
describes this change. describes this change.
2.1 Including DNSKEY RRs in a Zone 2.1 Including DNSKEY RRs in a Zone
skipping to change at page 9, line 18 skipping to change at page 9, line 18
security-aware name server functions. In many cases such functions security-aware name server functions. In many cases such functions
will be part of a security-aware recursive name server, but a will be part of a security-aware recursive name server, but a
security-aware authoritative name server has some of the same security-aware authoritative name server has some of the same
requirements. Functions specific to security-aware recursive name requirements. Functions specific to security-aware recursive name
servers are described in Section 3.2; functions specific to servers are described in Section 3.2; functions specific to
authoritative servers are described in Section 3.1. authoritative servers are described in Section 3.1.
The terms "SNAME", "SCLASS", and "STYPE" in the following discussion The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
are as used in [RFC1034]. are as used in [RFC1034].
A security-aware name server MUST support the EDNS0 [RFC2671] message A security-aware name server MUST support the EDNS0 ([RFC2671])
size extension, MUST support a message size of at least 1220 octets, message size extension, MUST support a message size of at least 1220
and SHOULD support a message size of 4000 octets [RFC3226]. octets, and SHOULD support a message size of 4000 octets. Since IPv6
packets can only be fragmented by the source host, a security aware
name server SHOULD take steps to ensure that UDP datagrams it
transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
and [RFC3226] for further discussion of packet size and fragmentation
issues.
A security-aware name server which receives a DNS query that does not A security-aware name server which receives a DNS query that does not
include the EDNS OPT pseudo-RR or that has the DO bit clear MUST include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
and MUST NOT perform any of the additional processing described and MUST NOT perform any of the additional processing described
below. Since the DS RR type has the peculiar property of only below. Since the DS RR type has the peculiar property of only
existing in the parent zone at delegation points, DS RRs always existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.1.4.1. require some special processing, as described in Section 3.1.4.1.
Security aware name servers that receive explicit queries for Security aware name servers that receive explicit queries for
skipping to change at page 10, line 11 skipping to change at page 10, line 17
ignore the setting of the AD bit in queries. See Section 3.1.6, ignore the setting of the AD bit in queries. See Section 3.1.6,
Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
on the behavior of these bits. on the behavior of these bits.
A security aware name server which synthesizes CNAME RRs from DNAME A security aware name server which synthesizes CNAME RRs from DNAME
RRs as described in [RFC2672] SHOULD NOT generate signatures for the RRs as described in [RFC2672] SHOULD NOT generate signatures for the
synthesized CNAME RRs. synthesized CNAME RRs.
3.1 Authoritative Name Servers 3.1 Authoritative Name Servers
Upon receiving a relevant query that has the EDNS [RFC2671] OPT Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
server for a signed zone MUST include additional RRSIG, NSEC, and DS server for a signed zone MUST include additional RRSIG, NSEC, and DS
RRs according to the following rules: RRs according to the following rules:
o RRSIG RRs that can be used to authenticate a response MUST be o RRSIG RRs that can be used to authenticate a response MUST be
included in the response according to the rules in Section 3.1.1; included in the response according to the rules in Section 3.1.1;
o NSEC RRs that can be used to provide authenticated denial of o NSEC RRs that can be used to provide authenticated denial of
existence MUST be included in the response automatically according existence MUST be included in the response automatically according
to the rules in Section 3.1.3; to the rules in Section 3.1.3;
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
be included in referrals automatically according to the rules in be included in referrals automatically according to the rules in
Section 3.1.4. Section 3.1.4.
skipping to change at page 13, line 48 skipping to change at page 14, line 8
which proves that no RRsets matching a particular SNAME exist. which proves that no RRsets matching a particular SNAME exist.
Locating such an NSEC RR within an authoritative zone is relatively Locating such an NSEC RR within an authoritative zone is relatively
simple, at least in concept. The following discussion assumes that simple, at least in concept. The following discussion assumes that
the name server is authoritative for the zone which would have held the name server is authoritative for the zone which would have held
the nonexistent RRsets matching SNAME. The algorithm below is the nonexistent RRsets matching SNAME. The algorithm below is
written for clarity, not efficiency. written for clarity, not efficiency.
To find the NSEC which proves that no RRsets matching name N exist in To find the NSEC which proves that no RRsets matching name N exist in
the zone Z which would have held them, construct sequence S the zone Z which would have held them, construct sequence S
consisting of the owner names of every RRset in Z, sorted into consisting of the owner names of every RRset in Z, sorted into
canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate canonical order ([I-D.ietf-dnsext-dnssec-records]), with no duplicate
names. Find the name M which would have immediately preceded N in S names. Find the name M which would have immediately preceded N in S
if any RRsets with owner name N had existed. M is the owner name of if any RRsets with owner name N had existed. M is the owner name of
the NSEC RR which proves that no RRsets exist with owner name N. the NSEC RR which proves that no RRsets exist with owner name N.
The algorithm for finding the NSEC RR which proves that a given name The algorithm for finding the NSEC RR which proves that a given name
is not covered by any applicable wildcard is similar, but requires an is not covered by any applicable wildcard is similar, but requires an
extra step. More precisely, the algorithm for finding the NSEC extra step. More precisely, the algorithm for finding the NSEC
proving that no RRsets exist with the applicable wildcard name is proving that no RRsets exist with the applicable wildcard name is
precisely the same as the algorithm for finding the NSEC RR which precisely the same as the algorithm for finding the NSEC RR which
proves that RRsets with any other owner name do not exist: the part proves that RRsets with any other owner name do not exist: the part
skipping to change at page 17, line 40 skipping to change at page 17, line 49
3.2.2 The CD bit 3.2.2 The CD bit
The CD bit exists in order to allow a security-aware resolver to The CD bit exists in order to allow a security-aware resolver to
disable signature validation in a security-aware name server's disable signature validation in a security-aware name server's
processing of a particular query. processing of a particular query.
The name server side MUST copy the setting of the CD bit from a query The name server side MUST copy the setting of the CD bit from a query
to the corresponding response. to the corresponding response.
The name server side of a security-aware recursive name server MUST The name server side of a security-aware recursive name server MUST
pass the sense of the CD bit to the resolver side along with the rest pass the state of the CD bit to the resolver side along with the rest
of an initiating query, so that the resolver side will know whether of an initiating query, so that the resolver side will know whether
or not it is required to verify the response data it returns to the or not it is required to verify the response data it returns to the
name server side. If the CD bit is set, it indicates that the name server side. If the CD bit is set, it indicates that the
originating resolver is willing to perform whatever authentication originating resolver is willing to perform whatever authentication
its local policy requires, thus the resolver side of the recursive its local policy requires, thus the resolver side of the recursive
name server need not perform authentication on the RRsets in the name server need not perform authentication on the RRsets in the
response. When the CD bit is set the recursive name server SHOULD, response. When the CD bit is set the recursive name server SHOULD,
if possible, return the requested data to the originating resolver if possible, return the requested data to the originating resolver
even if the recursive name server's local authentication policy would even if the recursive name server's local authentication policy would
reject the records in question. That is, by setting the CD bit, the reject the records in question. That is, by setting the CD bit, the
originating resolver has indicated that it takes responsibility for originating resolver has indicated that it takes responsibility for
performing its own authentication, and the recursive name server performing its own authentication, and the recursive name server
should not interfere. should not interfere.
If the resolver side implements a BAD cache (see Section 4.7) and the If the resolver side implements a BAD cache (see Section 4.7) and the
name server side receives a query which matches an entry in the name server side receives a query which matches an entry in the
resolver side's BAD cache, the name server side's response depends on resolver side's BAD cache, the name server side's response depends on
the sense of the CD bit in the original query. If the CD bit is set, the state of the CD bit in the original query. If the CD bit is set,
the name server side SHOULD return the data from the BAD cache; if the name server side SHOULD return the data from the BAD cache; if
the CD bit is not set, the name server side MUST return RCODE 2 the CD bit is not set, the name server side MUST return RCODE 2
(server failure). (server failure).
The intent of the above rule is to provide the raw data to clients The intent of the above rule is to provide the raw data to clients
which are capable of performing their own signature verification which are capable of performing their own signature verification
checks while protecting clients which depend on the resolver side of checks while protecting clients which depend on the resolver side of
a security-aware recursive name server to perform such checks. a security-aware recursive name server to perform such checks.
Several of the possible reasons why signature validation might fail Several of the possible reasons why signature validation might fail
involve conditions which may not apply equally to the recursive name involve conditions which may not apply equally to the recursive name
skipping to change at page 19, line 16 skipping to change at page 20, line 16
This section describes the behavior of entities that include This section describes the behavior of entities that include
security-aware resolver functions. In many cases such functions will security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements. Functions security-aware resolver has many of the same requirements. Functions
specific to security-aware recursive name servers are described in specific to security-aware recursive name servers are described in
Section 3.2. Section 3.2.
4.1 EDNS Support 4.1 EDNS Support
A security-aware resolver MUST include an EDNS [RFC2671] OPT A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
pseudo-RR with the DO [RFC3225] bit set when sending queries. pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
A security-aware resolver MUST support a message size of at least A security-aware resolver MUST support a message size of at least
1220 octets, SHOULD support a message size of 4000 octets, and MUST 1220 octets, SHOULD support a message size of 4000 octets, and MUST
advertise the supported message size using the "sender's UDP payload advertise the message size it's willing to accept using the "sender's
size" field in the EDNS OPT pseudo-RR. A security-aware resolver's UDP payload size" field in the EDNS OPT pseudo-RR. A security-aware
IP layer MUST handle fragmented UDP packets correctly regardless of resolver's IP layer MUST handle fragmented UDP packets correctly
whether any such fragmented packets were received via IPv4 or IPv6. regardless of whether any such fragmented packets were received via
Please see [RFC1122], [RFC2460] and [RFC3226] for discussion of these IPv4 or IPv6. Please see [RFC1122], [RFC2460] and [RFC3226] for
requirements. discussion of these requirements.
4.2 Signature Verification Support 4.2 Signature Verification Support
A security-aware resolver MUST support the signature verification A security-aware resolver MUST support the signature verification
mechanisms described in Section 5, and SHOULD apply them to every mechanisms described in Section 5, and SHOULD apply them to every
received response except when: received response except when:
o The security-aware resolver is part of a security-aware recursive o The security-aware resolver is part of a security-aware recursive
name server, and the response is the result of recursion on behalf name server, and the response is the result of recursion on behalf
of a query received with the CD bit set; of a query received with the CD bit set;
o The response is the result of a query generated directly via some o The response is the result of a query generated directly via some
skipping to change at page 20, line 16 skipping to change at page 21, line 16
When attempting to retrieve a missing DS, a security-aware When attempting to retrieve a missing DS, a security-aware
iterative-mode resolver MUST query the name servers for the parent iterative-mode resolver MUST query the name servers for the parent
zone, not the child zone. As explained in Section 3.1.4.1, zone, not the child zone. As explained in Section 3.1.4.1,
security-aware name servers need to apply special processing rules to security-aware name servers need to apply special processing rules to
handle the DS RR, and in some situations the resolver may also need handle the DS RR, and in some situations the resolver may also need
to apply special rules to locate the name servers for the parent zone to apply special rules to locate the name servers for the parent zone
if the resolver does not already have the parent's NS RRset. To if the resolver does not already have the parent's NS RRset. To
locate the parent NS RRset, the resolver can start with the locate the parent NS RRset, the resolver can start with the
delegation name, strip off the leftmost label, and query for an NS delegation name, strip off the leftmost label, and query for an NS
RRset by that name; if no NS RRset is present at that name, the RRset by that name; if no NS RRset is present at that name, the
resolver then strips of the leftmost remaining label and retries the resolver then strips off the leftmost remaining label and retries the
query for that name, repeating this process of walking up the tree query for that name, repeating this process of walking up the tree
until it either finds the NS RRset or runs out of labels. until it either finds the NS RRset or runs out of labels.
4.3 Determining Security Status of Data 4.3 Determining Security Status of Data
A security-aware resolver MUST be able to determine whether or not it A security-aware resolver MUST be able to determine whether or not it
should expect a particular RRset to be signed. More precisely, a should expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between four security-aware resolver must be able to distinguish between four
cases: cases:
skipping to change at page 22, line 35 skipping to change at page 23, line 35
While many validation errors will be transient, some are likely to be While many validation errors will be transient, some are likely to be
more persistent, such as those caused by administrative error more persistent, such as those caused by administrative error
(failure to re-sign a zone, clock skew, and so forth). Since (failure to re-sign a zone, clock skew, and so forth). Since
requerying will not help in these cases, validating resolvers might requerying will not help in these cases, validating resolvers might
generate a significant amount of unnecessary DNS traffic as a result generate a significant amount of unnecessary DNS traffic as a result
of repeated queries for RRsets with persistent validation failures. of repeated queries for RRsets with persistent validation failures.
To prevent such unnecessary DNS traffic, security-aware resolvers MAY To prevent such unnecessary DNS traffic, security-aware resolvers MAY
cache data with invalid signatures, with some restrictions. cache data with invalid signatures, with some restrictions.
Conceptually, caching such data is similar to negative caching Conceptually, caching such data is similar to negative caching
[RFC2308], except that instead of caching a valid negative response, ([RFC2308]), except that instead of caching a valid negative
the resolver is caching the fact that a particular answer failed to response, the resolver is caching the fact that a particular answer
validate. This document refers to a cache of data with invalid failed to validate. This document refers to a cache of data with
signatures as a "BAD cache". invalid signatures as a "BAD cache".
Resolvers which implement a BAD cache MUST take steps to prevent the Resolvers which implement a BAD cache MUST take steps to prevent the
cache from being useful as a denial-of-service attack amplifier. In cache from being useful as a denial-of-service attack amplifier. In
particular: particular:
o Since RRsets which fail to validate do not have trustworthy TTLs, o Since RRsets which fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL SHOULD be small, the implementation MUST assign a TTL. This TTL SHOULD be small,
in order to mitigate the effect of caching the results of an in order to mitigate the effect of caching the results of an
attack. attack.
o In order to prevent caching of a transient validation failure o In order to prevent caching of a transient validation failure
(which might be the result of an attack), resolvers SHOULD track (which might be the result of an attack), resolvers SHOULD track
skipping to change at page 26, line 36 skipping to change at page 27, line 36
security. The only difference between normal validation and security. The only difference between normal validation and
validation within an island of security is in how the validator validation within an island of security is in how the validator
obtains a trust anchor for the authentication chain. obtains a trust anchor for the authentication chain.
5.2 Authenticating Referrals 5.2 Authenticating Referrals
Once the apex DNSKEY RRset for a signed parent zone has been Once the apex DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR identifies a DNSKEY RR in the child to a signed child zone. A DS RR identifies a DNSKEY RR in the child
zone's apex DNSKEY RRset, and contains a cryptographic digest of the zone's apex DNSKEY RRset, and contains a cryptographic digest of the
child zone's DNSKEY RR. A strong cryptographic digest algorithm child zone's DNSKEY RR. Use of a strong cryptographic digest
ensures that an adversary can not easily generate a DNSKEY RR that algorithm ensures that it is computationally infeasible for an
matches the digest. Thus, authenticating the digest allows a adversary to generate a DNSKEY RR that matches the digest. Thus,
resolver to authenticate the matching DNSKEY RR. The resolver can authenticating the digest allows a resolver to authenticate the
then use this child DNSKEY RR to authenticate the entire child apex matching DNSKEY RR. The resolver can then use this child DNSKEY RR
DNSKEY RRset. to authenticate the entire child apex DNSKEY RRset.
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
can be authenticated if all of the following hold: can be authenticated if all of the following hold:
o The DS RR has been authenticated using some DNSKEY RR in the o The DS RR has been authenticated using some DNSKEY RR in the
parent's apex DNSKEY RRset (see Section 5.3); parent's apex DNSKEY RRset (see Section 5.3);
o The Algorithm and Key Tag in the DS RR match the Algorithm field o The Algorithm and Key Tag in the DS RR match the Algorithm field
and the key tag of a DNSKEY RR in the child zone's apex DNSKEY and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
RRset and, when the DNSKEY RR's owner name and RDATA are hashed RRset and, when the DNSKEY RR's owner name and RDATA are hashed
using the digest algorithm specified in the DS RR's Digest Type using the digest algorithm specified in the DS RR's Digest Type
field, the resulting digest value matches the Digest field of the field, the resulting digest value matches the Digest field of the
skipping to change at page 32, line 48 skipping to change at page 33, line 48
If for whatever reason none of the RRSIGs can be validated, the If for whatever reason none of the RRSIGs can be validated, the
response SHOULD be considered BAD. If the validation was being done response SHOULD be considered BAD. If the validation was being done
to service a recursive query, the name server MUST return RCODE 2 to to service a recursive query, the name server MUST return RCODE 2 to
the originating client. However, it MUST return the full response if the originating client. However, it MUST return the full response if
and only if the original query had the CD bit set. See also Section and only if the original query had the CD bit set. See also Section
4.7 on caching responses that do not validate. 4.7 on caching responses that do not validate.
5.6 Authentication Example 5.6 Authentication Example
Appendix C shows an example the authentication process. Appendix C shows an example of the authentication process.
6. IANA Considerations 6. IANA Considerations
[I-D.ietf-dnsext-dnssec-records] contains a review of the IANA [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
considerations introduced by DNSSEC. The additional IANA considerations introduced by DNSSEC. The additional IANA
considerations discussed in this document: considerations discussed in this document:
[RFC2535] reserved the CD and AD bits in the message header. The [RFC2535] reserved the CD and AD bits in the message header. The
meaning of the AD bit was redefined in [RFC3655] and the meaning of meaning of the AD bit was redefined in [RFC3655] and the meaning of
both the CD and AD bit are restated in this document. No new bits in both the CD and AD bit are restated in this document. No new bits in
skipping to change at page 37, line 41 skipping to change at page 38, line 41
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
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Rob Austein Rob Austein
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: sra@isc.org EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey Dan Massey
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive 3811 N. Fairfax Drive
Arlington, VA 22203 Arlington, VA 22203
USA USA
EMail: masseyd@isi.edu EMail: masseyd@isi.edu
Scott Rose Scott Rose
skipping to change at page 54, line 12 skipping to change at page 55, line 12
;; Additional ;; Additional
;; (empty) ;; (empty)
Appendix C. Authentication Examples Appendix C. Authentication Examples
The examples in this section show how the response messages in The examples in this section show how the response messages in
Appendix B are authenticated. Appendix B are authenticated.
C.1 Authenticating An Answer C.1 Authenticating An Answer
The query in section Appendix B.1 returned an MX RRset for The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
"x.w.example.com". The corresponding RRSIG indicates the MX RRset The corresponding RRSIG indicates the MX RRset was signed by an
was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. "example" DNSKEY with algorithm 5 and key tag 38519. The resolver
The resolver needs the corresponding DNSKEY RR in order to needs the corresponding DNSKEY RR in order to authenticate this
authenticate this answer. The discussion below describes how a answer. The discussion below describes how a resolver might obtain
resolver might obtain this DNSKEY RR. this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600 and, The RRSIG indicates the original TTL of the MX RRset was 3600 and,
for the purpose of authentication, the current TTL is replaced by for the purpose of authentication, the current TTL is replaced by
3600. The RRSIG labels field value of 3 indicates the answer was not 3600. The RRSIG labels field value of 3 indicates the answer was not
the result of wildcard expansion. The "x.w.example.com" MX RRset is the result of wildcard expansion. The "x.w.example.com" MX RRset is
placed in canonical form and, assuming the current time falls between placed in canonical form and, assuming the current time falls between
the signature inception and expiration dates, the signature is the signature inception and expiration dates, the signature is
authenticated. authenticated.
C.1.1 Authenticating the example DNSKEY RR C.1.1 Authenticating the example DNSKEY RR
skipping to change at page 55, line 19 skipping to change at page 56, line 19
Finally the resolver checks that some DNSKEY RR in the "example" Finally the resolver checks that some DNSKEY RR in the "example"
DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
DNSKEY is used to authenticated the RRSIG included in the response. DNSKEY is used to authenticated the RRSIG included in the response.
If multiple "example" DNSKEY RRs match this algorithm and key tag, If multiple "example" DNSKEY RRs match this algorithm and key tag,
then each DNSKEY RR is tried and the answer is authenticated if any then each DNSKEY RR is tried and the answer is authenticated if any
of the matching DNSKEY RRs validates the signature as described of the matching DNSKEY RRs validates the signature as described
above. above.
C.2 Name Error C.2 Name Error
The query in section Appendix B.2 returned NSEC RRs that prove the The query in Appendix B.2 returned NSEC RRs that prove the requested
requested data does not exist and no wildcard applies. The negative data does not exist and no wildcard applies. The negative reply is
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed authenticated in a manner identical to that of the MX RRset discussed
above. above.
C.3 No Data Error C.3 No Data Error
The query in section Appendix B.3 returned an NSEC RR that proves the The query in Appendix B.3 returned an NSEC RR that proves the
requested name exists, but the requested RR type does not exist. The requested name exists, but the requested RR type does not exist. The
negative reply is authenticated by verifying the NSEC RR. The NSEC negative reply is authenticated by verifying the NSEC RR. The NSEC
RR is authenticated in a manner identical to that of the MX RRset RR is authenticated in a manner identical to that of the MX RRset
discussed above. discussed above.
C.4 Referral to Signed Zone C.4 Referral to Signed Zone
The query in section Appendix B.4 returned a referral to the signed The query in Appendix B.4 returned a referral to the signed
"a.example." zone. The DS RR is authenticated in a manner identical "a.example." zone. The DS RR is authenticated in a manner identical
to that of the MX RRset discussed above. This DS RR is used to to that of the MX RRset discussed above. This DS RR is used to
authenticate the "a.example" DNSKEY RRset. authenticate the "a.example" DNSKEY RRset.
Once the "a.example" DS RRset has been authenticated using the Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
for some "a.example" DNSKEY RR that matches the DS RR. If such a for some "a.example" DNSKEY RR that matches the DS RR. If such a
matching "a.example" DNSKEY is found, the resolver checks this DNSKEY matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "a.example" DNSKEY RRset and the signature lifetime RR has signed the "a.example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the is valid. If all these conditions are met, all keys in the
"a.example" DNSKEY RRset are considered authenticated. "a.example" DNSKEY RRset are considered authenticated.
C.5 Referral to Unsigned Zone C.5 Referral to Unsigned Zone
The query in section Appendix B.5 returned a referral to an unsigned The query in Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from "b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example" and the NSEC RR is authenticated in a manner "example" to "b.example" and the NSEC RR is authenticated in a manner
identical to that of the MX RRset discussed above. identical to that of the MX RRset discussed above.
C.6 Wildcard Expansion C.6 Wildcard Expansion
The query in section Appendix B.6 returned an answer that was The query in Appendix B.6 returned an answer that was produced as a
produced as a result of wildcard expansion. The answer section result of wildcard expansion. The answer section contains a wildcard
contains a wildcard RRset expanded as in a traditional DNS response RRset expanded as in a traditional DNS response and the corresponding
and the corresponding RRSIG indicates that the expanded wildcard MX RRSIG indicates that the expanded wildcard MX RRset was signed by an
RRset was signed by an "example" DNSKEY with algorithm 5 and key tag "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG
38519. The RRSIG indicates the original TTL of the MX RRset was 3600 indicates the original TTL of the MX RRset was 3600 and, for the
and, for the purpose of authentication, the current TTL is replaced purpose of authentication, the current TTL is replaced by 3600. The
by 3600. The RRSIG labels field value of 2 indicates the answer the RRSIG labels field value of 2 indicates the answer the result of
result of wildcard expansion since the "a.z.w.example" name contains wildcard expansion since the "a.z.w.example" name contains 4 labels.
4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
the MX RRset is placed in canonical form and, assuming the current is placed in canonical form and, assuming the current time falls
time falls between the signature inception and expiration dates, the between the signature inception and expiration dates, the signature
signature is authenticated. is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query and the NSEC RR must also be have been used to answer this query and the NSEC RR must also be
authenticated before the answer is considered valid. authenticated before the answer is considered valid.
C.7 Wildcard No Data Error C.7 Wildcard No Data Error
The query in section Appendix B.7 returned NSEC RRs that prove the The query in Appendix B.7 returned NSEC RRs that prove the requested
requested data does not exist and no wildcard applies. The negative data does not exist and no wildcard applies. The negative reply is
reply is authenticated by verifying both NSEC RRs. authenticated by verifying both NSEC RRs.
C.8 DS Child Zone No Data Error C.8 DS Child Zone No Data Error
The query in section Appendix B.8 returned NSEC RRs that shows the The query in Appendix B.8 returned NSEC RRs that shows the requested
requested was answered by a child server ("example" server). The was answered by a child server ("example" server). The NSEC RR
NSEC RR indicates the presence of an SOA RR, showing the answer is indicates the presence of an SOA RR, showing the answer is from the
from the child . Queries for the "example" DS RRset should be sent child . Queries for the "example" DS RRset should be sent to the
to the parent servers ("root" servers). parent servers ("root" servers).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/