draft-ietf-dnsext-dnssec-protocol-04.txt   draft-ietf-dnsext-dnssec-protocol-05.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: June 16, 2004 M. Larson Expires: August 16, 2004 M. Larson
VeriSign VeriSign
R. Austein R. Austein
ISC ISC
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
December 17, 2003 February 16, 2004
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-04 draft-ietf-dnsext-dnssec-protocol-05
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 June 16, 2004. This Internet-Draft will expire on August 16, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
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
document describes the DNSSEC protocol modifications. This document document describes the DNSSEC protocol modifications. This document
defines the concept of a signed zone, along with the requirements for defines the concept of a signed zone, along with the requirements for
serving and resolving using DNSSEC. These techniques allow a serving and resolving using DNSSEC. These techniques allow a
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . 12 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
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 . . . . . . . . 16 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16
3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20
4.3 Determining Security Status of Data . . . . . . . . . . . . 21 4.3 Determining Security Status of Data . . . . . . . . . . . . 21
4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 21 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 22
4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 22 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23
4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 23 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
4.8.1 ENDS Support . . . . . . . . . . . . . . . . . . . . . . . . 23 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24
4.8.2 Handling of the CD and AD Bits . . . . . . . . . . . . . . . 23 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24
5.1 Special Considerations for Islands of Security . . . . . . . 26 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 5.1 Special Considerations for Islands of Security . . . . . . . 27
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 27 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 28 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 29 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 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 Authentication Example . . . . . . . . . . . . . . . . . . . 32 5.5 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
Normative References . . . . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . 37 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 . . . . . . . . . . . . . . . . . . . . . 49 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 50 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 51 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52
C. Authentication Examples . . . . . . . . . . . . . . . . . . 53 C. Authentication Examples . . . . . . . . . . . . . . . . . . 54
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 53 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 53 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 54 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 54 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 54 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 54 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 55 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 55 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 55 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . 57
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 defines the DNSSEC protocol modifications. Section 2 of this document defines
the concept of a signed zone and lists the requirements for zone the concept of a signed zone and lists the requirements for zone
signing. Section 3 describes the modifications to authoritative name signing. Section 3 describes the modifications to authoritative name
server behavior necessary to handle signed zones. Section 4 describes server behavior necessary to handle signed zones. Section 4 describes
skipping to change at page 6, line 7 skipping to change at page 6, line 7
Please report any typos corrections to dnssec-editors@east.isi.edu. Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to find To assist the editors, please provide enough context for us to find
the incorrect text quickly. the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It DNSSEC standard has been in development for over 1 years". It
should read "over 10 years". should read "over 10 years".
2. Zone Signing 2. Zone Signing
DNSSEC is built around 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 DNSKEY, RRSIG, NSEC and (optionally) DS records according to
the rules specified in Section 2.1, Section 2.2, Section 2.3 and the rules specified in Section 2.1, Section 2.2, Section 2.3 and
Section 2.4, respectively. Any zone which does not include these Section 2.4, respectively. A zone that does not include these
records according to the rules in this section MUST be considered records according to the rules in this section is an unsigned zone.
unsigned for the purposes of the DNS security extensions.
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
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.
2.1 Including DNSKEY RRs in a Zone 2.1 Including DNSKEY RRs in a Zone
To sign a zone, the zone's administrator generates one or more To sign a zone, the zone's administrator generates one or more
public/private key pairs and uses the private key(s) to sign public/private key pairs and uses the private key(s) to sign
authoritative RRsets in the zone. For each private key used to authoritative RRsets in the zone. For each private key used to
create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the the public component stored in the zone. A zone key DNSKEY RR MUST
flags RDATA field set to one -- see Section 2.1.1 of have the Zone Key bit of the flags RDATA field set to one -- see
[I-D.ietf-dnsext-dnssec-records]. Public keys associated with other Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys
DNS operations MAY be stored in DNSKEY RRs that are not marked as associated with other DNS operations MAY be stored in DNSKEY RRs that
zone keys. are not marked as zone keys but MUST NOT be used to verify RRSIGs.
If the zone is delegated and does not wish to act as an island of If the zone is delegated and does not wish to act as an island of
security, the zone MUST have at least one DNSKEY RR at the apex to security, the zone MUST have at least one DNSKEY RR at the apex to
act as a secure entry point into the zone. This DNSKEY would then be act as a secure entry point into the zone. This DNSKEY would then be
used to generate a DS RR at the delegating parent (see used to generate a DS RR at the delegating parent (see
[I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a [I-D.ietf-dnsext-dnssec-records]).
zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
for definition).
DNSKEY RRs MUST NOT appear at delegation points. DNSKEY RRs MUST NOT appear at delegation points.
2.2 Including RRSIG RRs in a Zone 2.2 Including RRSIG RRs in a Zone
For each authoritative RRset in a signed zone (which excludes both NS For each authoritative RRset in a signed zone, there MUST be at least
RRsets at delegation points and glue RRsets), there MUST be at least
one RRSIG record that meets all of the following requirements: one RRSIG record that meets all of the following requirements:
o The RRSIG owner name is equal to the RRset owner name; o The RRSIG owner name is equal to the RRset owner name;
o The RRSIG class is equal to the RRset class; o The RRSIG class is equal to the RRset class;
o The RRSIG Type Covered field is equal to the RRset type; o The RRSIG Type Covered field is equal to the RRset type;
o The RRSIG Original TTL field is equal to the TTL of the RRset; o The RRSIG Original TTL field is equal to the TTL of the RRset;
o The RRSIG RR's TTL is equal to the TTL of the RRset; o The RRSIG RR's TTL is equal to the TTL of the RRset;
o The RRSIG Labels field is equal to the number of labels in the o The RRSIG Labels field is equal to the number of labels in the
RRset owner name, not counting the null root label and not RRset owner name, not counting the null root label and not
counting the wildcard label if the owner name is a wildcard; counting the leftmost label if it is a wildcard;
o The RRSIG Signer's Name field is equal to the name of the zone o The RRSIG Signer's Name field is equal to the name of the zone
containing the RRset; and containing the RRset; and
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
zone key DNSKEY record at the zone apex. zone key DNSKEY record at the zone apex.
The process for constructing the RRSIG RR for a given RRset is The process for constructing the RRSIG RR for a given RRset is
described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
multiple RRSIG RRs associated with it. multiple RRSIG RRs associated with it.
An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
would add no value and would create an infinite loop in the signing would add no value and would create an infinite loop in the signing
process. process.
The NS RRset which appears at the zone apex name MUST be signed, but The NS RRset that appears at the zone apex name MUST be signed, but
the NS RRsets which appear at delegation points (that is, the NS the NS RRsets that appear at delegation points (that is, the NS
RRsets in the parent zone which delegate the name to the child zone's RRsets in the parent zone that delegate the name to the child zone's
name servers) MUST NOT be signed. Glue address RRsets associated with name servers) MUST NOT be signed. Glue address RRsets associated with
delegations MUST NOT be signed. delegations MUST NOT be signed.
There MUST be an RRSIG for each RRset generated using at least one There MUST be an RRSIG for each RRset using at least one DNSKEY of
DNSKEY of each algorithm in the parent zone's DS RRset and each each algorithm in the parent zone's DS RRset and each additional
additional algorithm, if any, in the apex DNSKEY RRset. The apex algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset
DNSKEY RRset itself MUST be signed by each algorithm appearing in the itself MUST be signed by each algorithm appearing in the DS RRset.
DS RRset.
The difference between the set of owner names which require RRSIG
records and the set of owner names which require NSEC records is
subtle and worth highlighting. RRSIG records are present at the
owner names of all authoritative RRsets. NSEC records are present at
the owner names of all names for which the signed zone is
authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part
only visible during the zone signing process, because NSEC RRsets are
authoritative data, and are therefore signed, thus any owner name
which has an NSEC RRset will have RRSIG RRs as well in the signed
zone.
2.3 Including NSEC RRs in a Zone 2.3 Including NSEC RRs in a Zone
Each owner name in the zone which has authoritative data or a Each owner name in the zone which has authoritative data or a
delegation point NS RRset MUST have an NSEC resource record. The delegation point NS RRset MUST have an NSEC resource record. The
process for constructing the NSEC RR for a given name is described in process for constructing the NSEC RR for a given name is described in
[I-D.ietf-dnsext-dnssec-records]. [I-D.ietf-dnsext-dnssec-records].
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
value field in the zone SOA RR.
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
RRsets at any particular owner name. That is, the signing process RRset at any particular owner name. That is, the signing process
MUST NOT create (or RRSIG) RRs for owner names nodes which were not MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
the owner name of any RRset before the zone was signed. not the owner name of any RRset before the zone was signed.
The type bitmap of every NSEC resource record in a signed zone MUST The type bitmap of every NSEC resource record in a signed zone MUST
indicate the presence of both the NSEC record itself and its indicate the presence of both the NSEC record itself and its
corresponding RRSIG record. corresponding RRSIG record.
The difference between the set of owner names that require RRSIG
records and the set of owner names that require NSEC records is
subtle and worth highlighting. RRSIG records are present at the
owner names of all authoritative RRsets. NSEC records are present at
the owner names of all names for which the signed zone is
authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part is
only visible during the zone signing process, because NSEC RRsets are
authoritative data, and are therefore signed, thus any owner name
which has an NSEC RRset will have RRSIG RRs as well in the signed
zone.
2.4 Including DS RRs in a Zone 2.4 Including DS RRs in a Zone
The DS resource record establishes authentication chains between DNS The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records, child zone is signed. The DS RRset MAY contain multiple records,
each referencing a public key in the child zone used to verify the each referencing a public key in the child zone used to verify the
RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
RRsets MUST NOT appear at non-delegation points nor at a zone's apex. RRsets MUST NOT appear at a zone's apex.
A DS RR SHOULD point to a DNSKEY RR which is present in the child's A DS RR SHOULD point to a DNSKEY RR which is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
by the corresponding private key. by the corresponding private key.
The TTL of a DS RRset SHOULD match the TTL of the corresponding NS The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
RRset. (i.e., the NS RRset from the same zone containing the DS RRset).
Construction of a DS RR requires knowledge of the corresponding Construction of a DS RR requires knowledge of the corresponding
DNSKEY RR in the child zone, which implies communication between the DNSKEY RR in the child zone, which implies communication between the
child and parent zones. This communication is an operational matter child and parent zones. This communication is an operational matter
not covered by this document. not covered by this document.
2.5 Changes to the CNAME Resource Record. 2.5 Changes to the CNAME Resource Record.
If a CNAME RRset is present at a name in a signed zone, appropriate If a CNAME RRset is present at a name in a signed zone, appropriate
RRSIG and NSEC RRsets are REQUIRED at that name. Other types MUST NOT RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
be present at that name. name for secure dynamic update purposes is also allowed. Other types
MUST NOT be present at that name.
This is a modification to the original CNAME definition given in This is a modification to the original CNAME definition given in
[RFC1034]. The original definition of the CNAME RR did not allow any [RFC1034]. The original definition of the CNAME RR did not allow any
other types to coexist with a CNAME record, but a signed zone other types to coexist with a CNAME record, but a signed zone
requires NSEC and RRSIG RRs for every authoritative name. To resolve requires NSEC and RRSIG RRs for every authoritative name. To resolve
this conflict, this specification modifies the definition of the this conflict, this specification modifies the definition of the
CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
2.6 Example of a Secure Zone 2.6 Example of a Secure Zone
Appendix A shows a complete example of a small signed zone. Appendix A shows a complete example of a small signed zone.
3. Serving 3. Serving
This section describes the behavior of entities which include This section describes the behavior of entities that include
security-aware name functions. In many cases such functions will be security-aware name server functions. In many cases such functions
part of a security-aware recursive name server, but a security-aware will be part of a security-aware recursive name server, but a
authoritative name server has some of the same requirements as a security-aware authoritative name server has some of the same
security-aware recursive name server does. Functions specific to requirements as a security-aware recursive name server does.
security-aware recursive name servers are described in Section 3.2; Functions specific to security-aware recursive name servers are
functions specific to authoritative servers are described in Section described in Section 3.2; functions specific to authoritative servers
3.1. 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] message
size extension, MUST support a message size of at least 1220 octets, size extension, MUST support a message size of at least 1220 octets,
and SHOULD support a message size of 4000 octets [RFC3226]. and SHOULD support a message size of 4000 octets [RFC3226].
A security-aware name server which receives a DNS query which does A security-aware name server that receives a DNS query that does not
not include the EDNS OPT pseudo-RR or which has the DO bit set to include the EDNS OPT pseudo-RR or that has the DO bit set to zero
zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
RRset, and MUST NOT perform any of the additional processing RRset, and MUST NOT perform any of the additional processing
described below. Since the DS RR type has the peculiar property of described below. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always only 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.
DNSSEC allocates two new bits in the DNS message header: the CD DNSSEC allocates two new bits in the DNS message header: the CD
(Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
is controlled by resolvers; a security-aware name server MUST copy is controlled by resolvers; a security-aware name server MUST copy
the CD bit from a query into the corresponding response. The AD bit the CD bit from a query into the corresponding response. The AD bit
is controlled by name servers; a security-aware name server MUST is controlled by name servers; a security-aware name server MUST
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.8 for details Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details
on the behavior of these bits. on the behavior of these bits.
3.1 Authoritative Name Servers 3.1 Authoritative Name Servers
Upon receiving a relevant query which has the EDNS [RFC2671] OPT Upon receiving a relevant query that has the EDNS [RFC2671] OPT
pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
name server for a signed zone MUST include additional RRSIG, NSEC, name server for a signed zone MUST include additional RRSIG, NSEC,
and DS RRs according to the following rules: and DS RRs according to the following rules:
o RRSIG RRs which 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 which 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.
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
discusses zone transfer requirements. discusses zone transfer requirements.
3.1.1 Including RRSIG RRs in a Response 3.1.1 Including RRSIG RRs in a Response
When responding to a query which has the DO bit set to one, a When responding to a query that has the DO bit set to one, a
security-aware authoritative name server SHOULD attempt to send RRSIG security-aware authoritative name server SHOULD attempt to send RRSIG
RRs which a security-aware resolver can use to authenticate the RRs that a security-aware resolver can use to authenticate the RRsets
RRsets in the response. Inclusion of RRSIG RRs in a response is in the response. Inclusion of RRSIG RRs in a response is subject to
subject to the following rules: the following rules:
o When placing a signed RRset in the Answer section, the name server o When placing a signed RRset in the Answer section, the name server
MUST also place its RRSIG RRs in the Answer section. The RRSIG MUST also place its RRSIG RRs in the Answer section. The RRSIG
RRs have a higher priority for inclusion than any other RRsets RRs have a higher priority for inclusion than any other RRsets
which may need to be included. If space does not permit inclusion that may need to be included. If space does not permit inclusion
of these RRSIG RRs, the name server MUST set the TC bit. of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Authority section, the name o When placing a signed RRset in the Authority section, the name
server MUST also place its RRSIG RRs in the Authority section. server MUST also place its RRSIG RRs in the Authority section.
The RRSIG RRs have a higher priority for inclusion than any other The RRSIG RRs have a higher priority for inclusion than any other
RRsets that may need to be included. If space does not permit RRsets that may need to be included. If space does not permit
inclusion of these RRSIG RRs, the name server MUST set the TC bit. inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Additional section, the name o When placing a signed RRset in the Additional section, the name
server MUST also place its RRSIG RRs in the Additional section. server MUST also place its RRSIG RRs in the Additional section.
If space does not permit inclusion of these RRSIG RRs, the name If space does not permit inclusion of both the RRset and its
server MUST NOT set the TC bit solely because these RRSIG RRs associated RRSIG RRs, the name server MUST NOT set the TC bit
didn't fit. solely because these RRSIG RRs didn't fit.
3.1.2 Including DNSKEY RRs In a Response 3.1.2 Including DNSKEY RRs In a Response
When responding to a query which has the DO bit set to one and which When responding to a query that has the DO bit set to one and that
requests the SOA or NS RRs at the apex of a signed zone, a requests the SOA or NS RRs at the apex of a signed zone, a
security-aware authoritative name server for that zone MAY return the security-aware authoritative name server for that zone MAY return the
zone apex DNSKEY RRset in the Additional section. In this situation, zone apex DNSKEY RRset in the Additional section. In this situation,
the DNSKEY RRset and associated RRSIG RRs have lower priority than the DNSKEY RRset and associated RRSIG RRs have lower priority than
any other information that would be placed in the additional section. any other information that would be placed in the additional section.
The name server SHOULD NOT include the DNSKEY RRset unless there is The name server SHOULD NOT include the DNSKEY RRset unless there is
enough space in the response message for both the DNSKEY RRset and enough space in the response message for both the DNSKEY RRset and
its associated RRSIG RR(s). If there is not enough space to include its associated RRSIG RR(s). If there is not enough space to include
these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
NOT set the TC bit solely because these RRs didn't fit (see Section NOT set the TC bit solely because these RRs didn't fit (see Section
3.1.1). 3.1.1).
3.1.3 Including NSEC RRs In a Response 3.1.3 Including NSEC RRs In a Response
When responding to a query which has the DO bit set to one, a When responding to a query that has the DO bit set to one, a
security-aware authoritative name server for a signed zone MUST security-aware authoritative name server for a signed zone MUST
include NSEC RRs in each of the following cases: include NSEC RRs in each of the following cases:
No Data: The zone contains RRsets which exactly match <SNAME, No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
SCLASS>, but does not contain any RRsets which exactly match but does not contain any RRsets that exactly match <SNAME, SCLASS,
<SNAME, SCLASS, STYPE>. STYPE>.
Name Error: The zone does not contain any RRsets which match <SNAME, Name Error: The zone does not contain any RRsets that match <SNAME,
SCLASS> either exactly or via wildcard name expansion. SCLASS> either exactly or via wildcard name expansion.
Wildcard Answer: The zone does not contain any RRsets which exactly Wildcard Answer: The zone does not contain any RRsets that exactly
match <SNAME, SCLASS> but does contain an RRset which matches match <SNAME, SCLASS> but does contain an RRset that matches
<SNAME, SCLASS, STYPE> via wildcard name expansion. <SNAME, SCLASS, STYPE> via wildcard name expansion.
Wildcard No Data: The zone does not contain any RRsets which exactly Wildcard No Data: The zone does not contain any RRsets that exactly
match <SNAME, SCLASS>, does contain one or more RRsets which match <SNAME, SCLASS>, does contain one or more RRsets that match
matches <SNAME, SCLASS> via wildcard name expansion, but does not <SNAME, SCLASS> via wildcard name expansion, but does not contain
contain any RRsets which match <SNAME, SCLASS, STYPE> via wildcard any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
name expansion. expansion.
In each of these cases, the name server includes NSEC RRs in the In each of these cases, the name server includes NSEC RRs in the
response to prove that an exact match for <SNAME, SCLASS, STYPE> was response to prove that an exact match for <SNAME, SCLASS, STYPE> was
not present in the zone and that the response which the name server not present in the zone and that the response that the name server is
is returning is correct given the data which are in the zone. returning is correct given the data that are in the zone.
3.1.3.1 Including NSEC RRs: No Data Response 3.1.3.1 Including NSEC RRs: No Data Response
If the zone contains RRsets matching <SNAME, SCLASS> but contains no If the zone contains RRsets matching <SNAME, SCLASS> but contains no
RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
include the NSEC RR for <SNAME, SCLASS> along with its associated include the NSEC RR for <SNAME, SCLASS> along with its associated
RRSIG RR(s) in the Authority section of the response (see Section RRSIG RR(s) in the Authority section of the response (see Section
3.1.1). If space does not permit inclusion of the NSEC RR or its 3.1.1). If space does not permit inclusion of the NSEC RR or its
associated RRSIG RR(s), the name server MUST set the TC bit (see associated RRSIG RR(s), the name server MUST set the TC bit (see
Section 3.1.1). Section 3.1.1).
skipping to change at page 13, line 8 skipping to change at page 13, line 8
3.1.3.2 Including NSEC RRs: Name Error Response 3.1.3.2 Including NSEC RRs: Name Error Response
If the zone does not contain any RRsets matching <SNAME, SCLASS> If the zone does not contain any RRsets matching <SNAME, SCLASS>
either exactly or via wildcard name expansion, then the name server either exactly or via wildcard name expansion, then the name server
MUST include the following NSEC RRs in the Authority section, along MUST include the following NSEC RRs in the Authority section, along
with their associated RRSIG RRs: with their associated RRSIG RRs:
o An NSEC RR proving that there is no exact match for <SNAME, o An NSEC RR proving that there is no exact match for <SNAME,
SCLASS>; and SCLASS>; and
o An NSEC RR proving that the zone contains no RRsets which would o An NSEC RR proving that the zone contains no RRsets that would
match <SNAME, SCLASS> via wildcard name expansion. match <SNAME, SCLASS> via wildcard name expansion.
In some cases a single NSEC RR may prove both of these points, in In some cases a single NSEC RR may prove both of these points, in
which case the name server SHOULD only include the NSEC RR and its that case the name server SHOULD only include the NSEC RR and its
RRSIG RR(s) once in the Authority section. RRSIG RR(s) once in the Authority section.
If space does not permit inclusion of these NSEC and RRSIG RRs, the If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1). name server MUST set the TC bit (see Section 3.1.1).
The owner names of these NSEC and RRSIG RRs are not subject to The owner names of these NSEC and RRSIG RRs are not subject to
wildcard name expansion when these RRs are included in the Authority wildcard name expansion when these RRs are included in the Authority
section of the response. section of the response.
Note that this form of response includes cases in which SNAME Note that this form of response includes cases in which SNAME
skipping to change at page 13, line 36 skipping to change at page 13, line 36
3.1.3.3 Including NSEC RRs: Wildcard Answer Response 3.1.3.3 Including NSEC RRs: Wildcard Answer Response
If the zone does not contain any RRsets which exactly match <SNAME, If the zone does not contain any RRsets which exactly match <SNAME,
SCLASS> but does contain an RRset which matches <SNAME, SCLASS, SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
STYPE> via wildcard name expansion, the name server MUST include the STYPE> via wildcard name expansion, the name server MUST include the
wildcard-expanded answer and the corresponding wildcard-expanded wildcard-expanded answer and the corresponding wildcard-expanded
RRSIG RRs in the Answer section, and MUST include in the Authority RRSIG RRs in the Answer section, and MUST include in the Authority
section an NSEC RR and associated RRSIG RR(s) proving that the zone section an NSEC RR and associated RRSIG RR(s) proving that the zone
does not contain a closer match for <SNAME, SCLASS>. If space does does not contain a closer match for <SNAME, SCLASS>. If space does
not permit inclusion of these answer, NSEC and RRSIG RRs, the name not permit inclusion of the answer, NSEC and RRSIG RRs, the name
server MUST set the TC bit (see Section 3.1.1). server MUST set the TC bit (see Section 3.1.1).
3.1.3.4 Including NSEC RRs: Wildcard No Data Response 3.1.3.4 Including NSEC RRs: Wildcard No Data Response
This case is a combination of the previous cases. The zone does not This case is a combination of the previous cases. The zone does not
contain an exact match for <SNAME, SCLASS>, and while the zone does contain an exact match for <SNAME, SCLASS>, and while the zone does
contain RRsets which match <SNAME, SCLASS> via wildcard name contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
expansion, none of those RRsets match STYPE. The name server MUST none of those RRsets match STYPE. The name server MUST include the
include the following NSEC RRs in the Authority section, along with following NSEC RRs in the Authority section, along with their
their associated RRSIG RRs: associated RRSIG RRs:
o An NSEC RR proving that there are no RRsets matching STYPE at the o An NSEC RR proving that there are no RRsets matching STYPE at the
wildcard owner name which matched <SNAME, SCLASS> via wildcard wildcard owner name which matched <SNAME, SCLASS> via wildcard
expansion; and expansion; and
o An NSEC RR proving that there are no RRsets in the zone which o An NSEC RR proving that there are no RRsets in the zone which
would have been a closer match for <SNAME, SCLASS>. would have been a closer match for <SNAME, SCLASS>.
In some cases a single NSEC RR may prove both of these points, in In some cases a single NSEC RR may prove both of these points, in
which case the name server SHOULD only include the NSEC RR and its which case the name server SHOULD only include the NSEC RR and its
skipping to change at page 14, line 30 skipping to change at page 14, line 30
security-aware authoritative name server needs to locate an NSEC RR security-aware authoritative name server needs to locate an NSEC RR
which proves that a particular SNAME does not exist. Locating such which proves that a particular SNAME does not exist. Locating such
an NSEC RR within an authoritative zone is relatively simple, at an NSEC RR within an authoritative zone is relatively simple, at
least in concept. The following discussion assumes that the name least in concept. The following discussion assumes that the name
server is authoritative for the zone which would have held the server is authoritative for the zone which would have held the
nonexistent SNAME. The algorithm below is written for clarity, not nonexistent SNAME. The algorithm below is written for clarity, not
efficiency. efficiency.
To find the NSEC which proves that name N does not exist in the zone To find the NSEC which proves that name N does not exist in the zone
Z which would have held it, construct sequence S consisting of every Z which would have held it, construct sequence S consisting of every
name in Z, sorted into canonical order. Find the name M which would name in Z, sorted into canonical order
have immediately preceded N in S if N had existed. M is the owner [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have
name of the NSEC RR which proves that N does not exist. immediately preceded N in S if N had existed. M is the owner name of
the NSEC RR which proves that N does not exist.
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 the applicable wildcard name does not exist is precisely proving that the applicable wildcard name does not exist is precisely
the same as the algorithm for finding the NSEC RR which proves that the same as the algorithm for finding the NSEC RR which proves that
any other name does not exist: the part that's missing is how to any other name does not exist: the part that's missing is how to
determine the name of the nonexistent applicable wildcard. In determine the name of the nonexistent applicable wildcard. In
practice, this is easy, because the authoritative name server has practice, this is easy, because the authoritative name server has
already checked for the presence of precisely this wildcard name as already checked for the presence of precisely this wildcard name as
part of step (1)(c) of the normal lookup algorithm described in part of step (1)(c) of the normal lookup algorithm described in
Section 4.3.2 of [RFC1034]. Section 4.3.2 of [RFC1034].
3.1.4 Including DS RRs In a Response 3.1.4 Including DS RRs In a Response
When responding to a query which has the DO bit set to one, a When responding to a query which has the DO bit set to one, a
security-aware authoritative name server returning a referral security-aware authoritative name server returning a referral
includes DNSSEC data along with the NS RRset. includes DNSSEC data along with the NS RRset.
If a DS RRset is present at the delegation point, the name server If a DS RRset is present at the delegation point, the name server
MUST return both the DS RRset and its associated RRSIG RR(s) along MUST return both the DS RRset and its associated RRSIG RR(s) in the
with the NS RRset. The name server MUST place the NS RRset before Authority section along with the NS RRset. The name server MUST
the DS RRset and its associated RRSIG RR(s). place the NS RRset before the DS RRset and its associated RRSIG
RR(s).
If no DS RRset is present at the delegation point, the name server If no DS RRset is present at the delegation point, the name server
MUST return both the NSEC RR which proves that the DS RRset is not MUST return both the NSEC RR which proves that the DS RRset is not
present and the NSEC RR's associated RRSIG RR(s) along with the NS present and the NSEC RR's associated RRSIG RR(s) along with the NS
RRset. The name server MUST place the NS RRset before the NSEC RRset RRset. The name server MUST place the NS RRset before the NSEC RRset
and its associated RRSIG RR(s). and its associated RRSIG RR(s).
Including these DS, NSEC, and RRSIG RRs increases the size of Including these DS, NSEC, and RRSIG RRs increases the size of
referral messages, and may cause some or all glue RRs to be omitted. referral messages, and may cause some or all glue RRs to be omitted.
If space does not permit inclusion of the DS or NSEC RRset and If space does not permit inclusion of the DS or NSEC RRset and
skipping to change at page 15, line 32 skipping to change at page 15, line 33
3.1.4.1 Responding to Queries for DS RRs 3.1.4.1 Responding to Queries for DS RRs
The DS resource record type is unusual in that it appears only on the The DS resource record type is unusual in that it appears only on the
parent zone's side of a zone cut. For example, the DS RRset for the parent zone's side of a zone cut. For example, the DS RRset for the
delegation of "foo.example" is stored in the "example" zone rather delegation of "foo.example" is stored in the "example" zone rather
than in the "foo.example" zone. This requires special processing than in the "foo.example" zone. This requires special processing
rules for both name servers and resolvers, since the name server for rules for both name servers and resolvers, since the name server for
the child zone is authoritative for the name at the zone cut by the the child zone is authoritative for the name at the zone cut by the
normal DNS rules but the child zone does not contain the DS RRset. normal DNS rules but the child zone does not contain the DS RRset.
A security-aware resolver will send queries to the parent zone when A security-aware resolver sends queries to the parent zone when
looking for a DS RRset at a delegation point, and thus will never looking for a needed DS RR at a delegation point (see Section 4.2).
trigger the corresponding special processing in a security-aware name However, special rules are necessary to avoid confusing
server. The rest of this section describes how a security-aware security-oblivious resolvers which might become involved in
recursive name server processes a misdirected DS query. processing such a query (for example, in a network configuration that
forces a security-aware resolver to channel its queries through a
security-oblivious recursive name server). The rest of this section
describes how a security-aware name server processes DS queries in
order to avoid this problem.
The need for special processing by a security-aware name server only The need for special processing by a security-aware name server only
arises when: arises when all the following conditions are met:
o the name server has received a query for the DS RRset at a zone o the name server has received a query for the DS RRset at a zone
cut; cut; and
o the name server is authoritative for the child zone; o the name server is authoritative for the child zone; and
o the name server is not authoritative for the parent zone; and o the name server is not authoritative for the parent zone; and
o the name server does not offer recursion. o the name server does not offer recursion.
In all other cases, the name server either has some way of obtaining In all other cases, the name server either has some way of obtaining
the DS RRset or could not have been expected to have the DS RRset the DS RRset or could not have been expected to have the DS RRset
even by the pre-DNSSEC processing rules, so the name server can even by the pre-DNSSEC processing rules, so the name server can
return either the DS RRset or an error response according to the return either the DS RRset or an error response according to the
normal processing rules. normal processing rules.
If all of the above conditions are met, however, the name server is If all of the above conditions are met, however, the name server is
authoritative for SNAME but cannot supply the requested RRset. In authoritative for SNAME but cannot supply the requested RRset. In
skipping to change at page 17, line 23 skipping to change at page 17, line 28
security-aware resolvers and security-aware recursive name servers. security-aware resolvers and security-aware recursive name servers.
This bits are for the most part not relevant to query processing by This bits are for the most part not relevant to query processing by
security-aware authoritative name servers. security-aware authoritative name servers.
Since a security-aware name server does not perform signature Since a security-aware name server does not perform signature
validation for authoritative data during query processing even when validation for authoritative data during query processing even when
the CD bit is set to zero, a security-aware name server SHOULD ignore the CD bit is set to zero, a security-aware name server SHOULD ignore
the setting of the CD bit when composing an authoritative response. the setting of the CD bit when composing an authoritative response.
A security-aware name server MUST NOT set the AD bit in a response A security-aware name server MUST NOT set the AD bit in a response
unless the name server considers all RRsets in the Answer or unless the name server considers all RRsets in the Answer and
Authority sections of the response to be authentic. A security-aware Authority sections of the response to be authentic. A security-aware
name server's local policy MAY consider data from an authoritative name server's local policy MAY consider data from an authoritative
zone to be authentic without further validation, but the name server zone to be authentic without further validation, but the name server
MUST NOT do so unless the name server obtained the authoritative zone MUST NOT do so unless the name server obtained the authoritative zone
via secure means (such as a secure zone transfer mechanism), and MUST via secure means (such as a secure zone transfer mechanism), and MUST
NOT do so unless this behavior has been configured explicitly. NOT do so unless this behavior has been configured explicitly.
A security-aware name server which supports recursion MUST follow the A security-aware name server which supports recursion MUST follow the
rules for the CD and AD bits given in Section 3.2 when generating a rules for the CD and AD bits given in Section 3.2 when generating a
response that involves data obtained via recursion. response that involves data obtained via recursion.
skipping to change at page 17, line 45 skipping to change at page 17, line 50
3.2 Recursive Name Servers 3.2 Recursive Name Servers
As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
recursive name server is an entity which acts in both the recursive name server is an entity which acts in both the
security-aware name server and security-aware resolver roles. This security-aware name server and security-aware resolver roles. This
section uses the terms "name server side" and "resolver side" to section uses the terms "name server side" and "resolver side" to
refer to the code within a security-aware recursive name server which refer to the code within a security-aware recursive name server which
implements the security-aware name server role and the code which implements the security-aware name server role and the code which
implements the security-aware resolver role, respectively. implements the security-aware resolver role, respectively.
The resolver side MUST follow the usual rules for caching and The resolver side follows the usual rules for caching and negative
negative caching which would apply to any security-aware resolver. caching which would apply to any security-aware resolver.
3.2.1 The DO bit 3.2.1 The DO bit
The resolver side of a security-aware recursive name server MUST set The resolver side of a security-aware recursive name server MUST set
the DO bit when sending requests, regardless of the state of the DO the DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If bit in the initiating request received by the name server side. If
the DO bit in an initiating query is not set, the name server side the DO bit in an initiating query is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response, but but MUST strip any authenticating DNSSEC RRs from the response, but MUST
MUST NOT strip any DNSSEC RRs that the initiating query explicitly NOT strip any DNSSEC RRs that the initiating query explicitly
requested. requested.
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. This is a useful but somewhat processing of a particular query.
dangerous capability that requires careful handling by security-aware
recursive name servers.
A security-aware recursive name server MUST disregard the CD bit and
perform normal signature validation unless:
o the name server side received that query via a secure channel; or
o the recursive name server's local policy dictates that the
recursive name server honor the CD bit even when received via an
insecure channel.
Discussion of cases in which the CD bit is set to one in the rest of The name server side MUST copy the setting of the CD bit from a query
this section assumes that one or both of the above conditions applies to the corresponding response.
to the query being processed. If neither condition applies, the
recursive name server MUST process the query as if the CD bit were
set to zero. Note, however, that the name server side MUST always
copy the setting of the CD bit from a query to the corresponding
response, regardless of whether or not the recursive name server
trusts the setting of the CD bit.
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 sense 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 to one, it indicates that the name server side. If the CD bit is set to one, 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 to one the recursive name server response. When the CD bit is set to one the recursive name server
skipping to change at page 19, line 17 skipping to change at page 18, line 52
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 sense 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).
3.2.3 The AD bit 3.2.3 The AD bit
The name server side of a security-aware recursive name server MUST The name server side of a security-aware recursive name server MUST
NOT set the AD bit in a response unless the name server considers all NOT set the AD bit in a response unless the name server considers all
RRsets in the Answer or Authority sections of the response to be RRsets in the Answer and Authority sections of the response to be
authentic, and SHOULD set the AD bit if and only if the resolver side authentic, and SHOULD set the AD bit if and only if the resolver side
considers all RRsets in the Answer section and any relevant negative considers all RRsets in the Answer section and any relevant negative
response RRs in the Authority section to be authentic. The resolver response RRs in the Authority section to be authentic. The resolver
side MUST follow the procedure described in Section 5 to determine side MUST follow the procedure described in Section 5 to determine
whether the RRs in question are authentic. whether the RRs in question are authentic.
3.3 Example DNSSEC Responses 3.3 Example DNSSEC Responses
See Appendix B for example response packets. See Appendix B for example response packets.
skipping to change at page 20, line 46 skipping to change at page 20, line 46
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
form of application interface which instructed the security-aware form of application interface which instructed the security-aware
resolver not to perform validation for this query; or resolver not to perform validation for this query; or
o Validation for this query has been disabled by local policy. o Validation for this query has been disabled by local policy.
A security-aware resolver's support for signature verification MUST A security-aware resolver's support for signature verification MUST
include support for verification of wildcard owner names. include support for verification of wildcard owner names.
Editors' note: The rest of this section is expected to change once
the WG reaches closure on Q-23.
A security-aware resolver MUST attempt to retrieve missing DS, A security-aware resolver MUST attempt to retrieve missing DS,
DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
RRs in order to perform signature verification. RRs in order to perform signature verification.
A security-aware resolver MUST attempt to retrieve a missing NSEC RR A security-aware resolver MUST attempt to retrieve a missing NSEC RR
which the resolver needs to authenticate a NODATA response. In which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NSEC general it is not possible for a resolver to retrieve missing NSEC
RRs, since the resolver will have no way of knowing the owner name of RRs, since the resolver will have no way of knowing the owner name of
the missing NSEC RR, but in the specific case of a NODATA response, the missing NSEC RR, but in the specific case of a NODATA response,
the resolver does know the name of the missing NSEC RR, and must the resolver may know the name of the missing NSEC RR, and in such
therefore attempt to retrieve it. cases must therefore attempt to retrieve it.
When attempting to retrieve missing NSEC or DS RRs which reside on When attempting to retrieve missing NSEC RRs which reside on the
the parental side at a zone cut, a security-aware iterative-mode parental side at a zone cut, a security-aware iterative-mode resolver
resolver MUST query the name servers for the parent zone, not the MUST query the name servers for the parent zone, not the child zone.
child zone.
When attempting to retrieve a missing DS, a security-aware
iterative-mode resolver MUST query the name servers for the parent
zone, not the child zone. As explained in Section 3.1.4.1,
security-aware name servers need to apply special processing rules to
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
if the resolver does not already have the parent's NS RRset. To
locate the parent NS RRset, the resolver can start with the
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
resolver then strips of the leftmost remaining label and retries the
query for that name, repeating this process of walking up the tree
until it either finds the NS RRset or runs out of labels.
Editors' note: This algorithm could easily be read as an
invitation to careless implementors to hammer the root zone
servers. Better wording would be welcome.
4.3 Determining Security Status of Data 4.3 Determining Security Status of Data
Editors' note: This section is waiting for resolution of Q-28.
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 three security-aware resolver must be able to distinguish between three
cases: cases:
1. An RRset for which the resolver is able to build a chain of 1. An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed, and is subject RRset. In this case, the RRset should be signed, and is subject
to signature validation as described above. to signature validation as described above.
skipping to change at page 21, line 42 skipping to change at page 22, line 17
3. An RRset for which the resolver is not able to determine whether 3. An RRset for which the resolver is not able to determine whether
or not the RRset should be signed, because the resolver is not or not the RRset should be signed, because the resolver is not
able to obtain the necessary DNSSEC RRs. This can occur when the able to obtain the necessary DNSSEC RRs. This can occur when the
security-aware resolver is not able to contact security-aware security-aware resolver is not able to contact security-aware
name servers for the relevant zones. name servers for the relevant zones.
4.4 Preconfigured Public Keys 4.4 Preconfigured Public Keys
A security-aware resolver MUST be capable of being preconfigured with A security-aware resolver MUST be capable of being preconfigured with
at least one trusted public key, and SHOULD be capable of being at least one trusted public key or DS RR, and SHOULD be capable of
preconfigured with multiple trusted public keys or DS RRs. Since a being preconfigured with multiple trusted public keys or DS RRs.
security-aware resolver will not be able to validate signatures Since a security-aware resolver will not be able to validate
without such a preconfigured trusted key, the resolver SHOULD have signatures without such a preconfigured trusted key, the resolver
some reasonably robust mechanism for obtaining such keys when it SHOULD have some reasonably robust mechanism for obtaining such keys
boots. when it boots; examples of such a mechanism would be some form of
non-volatile storage (such as a disk drive) or some form of trusted
local network configuration mechanism.
4.5 Response Caching 4.5 Response Caching
Editors' note: RIPE "last call" workshop felt that the WG needs to
reexamine and discuss this section.
A security-aware resolver SHOULD cache each response as a single A security-aware resolver SHOULD cache each response as a single
atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the atomic entry containing the entire answer, including the named RRset
single atomic entry containing the entire answer, including the named and any associated DNSSEC RRs. The resolver SHOULD discard the
RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In
entire atomic entry when any of the RRs contained in it expire. most cases the appropriate cache index for the atomic entry will be
the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
form described in Section 3.1.3.2 the appropriate cache index will be
the double <QNAME,QCLASS>.
4.6 Handling of the CD and AD bits 4.6 Handling of the CD and AD bits
A security-aware resolver MAY set the CD bit in a query to one in A security-aware resolver MAY set the CD bit in a query to one in
order to indicate that the resolver takes responsibility for order to indicate that the resolver takes responsibility for
performing whatever authentication its local policy requires on the performing whatever authentication its local policy requires on the
RRsets in the response. See Section 3.2 for the effect this bit has RRsets in the response. See Section 3.2 for the effect this bit has
on the behavior of security-aware recursive name servers. on the behavior of security-aware recursive name servers.
A security-aware resolver MUST zero the AD bit when composing query A security-aware resolver MUST zero the AD bit when composing query
messages. messages to protect against buggy name servers which blindly copy
header bits which they do not understand from the query message to
the response message.
A resolver MUST disregard the meaning of the CD and AD bits in a
response unless the response was obtained using a secure channel or
the resolver was specifically configured to regard the message header
bits without using a secure channel.
4.7 Rate Limiting 4.7 Rate Limiting
A security-aware resolver SHOULD NOT cache data with invalid A security-aware resolver SHOULD NOT cache data with invalid
signatures under normal circumstances. However, a security-aware signatures under normal circumstances. However, a security-aware
resolver SHOULD take steps to rate limit the number of identical resolver SHOULD take steps to rate limit the number of identical
queries that it generates if signature validation of the responses queries that it generates if signature validation of the responses
fails repeatedly. fails repeatedly.
Conceptually, this is similar in some respects to negative caching Conceptually, this is similar in some respects to negative caching
skipping to change at page 23, line 15 skipping to change at page 24, line 7
validation might fail involve conditions which may not apply equally validation might fail involve conditions which may not apply equally
to this resolver and the client which invoked it: for example, this to this resolver and the client which invoked it: for example, this
resolver's clock may be set incorrectly, or the client may have resolver's clock may be set incorrectly, or the client may have
knowledge of a relevant island of security which this resolver does knowledge of a relevant island of security which this resolver does
not share. In such cases, "protecting" a client which is capable of not share. In such cases, "protecting" a client which is capable of
performing its own signature validation from ever seeing the "bad" performing its own signature validation from ever seeing the "bad"
data does not help the client. data does not help the client.
4.8 Stub resolvers 4.8 Stub resolvers
4.8.1 ENDS Support A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they
contain DNSSEC RRs.
A security-aware stub resolver MUST include an EDNS [RFC2671] OPT 4.8.1 Handling of the DO Bit
pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
A security-aware stub resolver MUST support a message size of at A non-validating security-aware stub resolver MAY include the DNSSEC
least 1220 octets, SHOULD support a message size of 4000 octets, and RRs returned by a security-aware recursive name server as part of the
MUST advertise the supported message size using the "sender's UDP data that the stub resolver hands back to the application which
payload size" field in the EDNS OPT pseudo-RR. A security-aware stub invoked it but is not required to do so. A non-validating stub
resolver MUST handle fragmented UDP packets correctly regardless of resolver that wishes to do this will need to set the DO bit in
whether any such fragmented packets were received via IPv4 or IPv6. receive DNSSEC RRs from the recursive name server.
Please see [RFC3226] for discussion of these requirements.
A security-aware stub resolver MUST support the DNSSEC RR types, at A validating security-aware stub resolver MUST set the DO bit, since
least to the extent of not mishandling responses just because they otherwise it will not receive the DNSSEC RRs it needs to perform
contain DNSSEC RRs. A security-aware stub resolver MAY include the signature validation.
DNSSEC RRs returned by a security-aware recursive name server as part
of the data that it the stub resolver hands back to the application
which invoked it but is not required to do so.
4.8.2 Handling of the CD and AD Bits 4.8.2 Handling of the CD Bit
A security-aware stub resolver SHOULD NOT set the CD bit when sending A non-validating security-aware stub resolver SHOULD NOT set the CD
queries unless requested by the application layer, since by bit when sending queries unless requested by the application layer,
definition, a security-aware stub resolver does not validate since by definition, a non-validating stub resolver depends on the
signatures and thus depends on the security-aware recursive name security-aware recursive name server to perform validation on its
server to perform validation on its behalf. behalf.
A security-aware stub resolver MAY chose to examine the setting of A validating security-aware stub resolver SHOULD set the CD bit,
the AD bit in response messages that it receives in order to since otherwise the security-aware recursive name server will answer
determine whether the security-aware recursive name server which sent the query using the name server's local policy, which may prevent the
the response claims to have cryptographically verified the data in stub resolver from receiving data which would be acceptable to the
the Answer and Authority sections of the response message. Note, stub resolver's local policy.
however, that the responses received by a security-aware stub
4.8.3 Handling of the AD Bit
A non-validating security-aware stub resolver MAY chose to examine
the setting of the AD bit in response messages that it receives in
order to determine whether the security-aware recursive name server
which sent the response claims to have cryptographically verified the
data in the Answer and Authority sections of the response message.
Note, however, that the responses received by a security-aware stub
resolver are heavily dependent on the local policy of the resolver are heavily dependent on the local policy of the
security-aware recursive name server, so as a practical matter there security-aware recursive name server, so as a practical matter there
may be little practical value to checking the status of the AD bit may be little practical value to checking the status of the AD bit
except perhaps as a debugging aid. In any case, a security-aware except perhaps as a debugging aid. In any case, a security-aware
stub resolver MUST NOT place any reliance on signature validation stub resolver MUST NOT place any reliance on signature validation
allegedly performed on its behalf except when the security-aware stub allegedly performed on its behalf except when the security-aware stub
resolver obtained the data in question from a trusted security-aware resolver obtained the data in question from a trusted security-aware
recursive name server via a secure channel. recursive name server via a secure channel.
A validating security-aware stub resolver SHOULD NOT examine the
setting of the AD bit in response messages, since, by definition, the
stub resolver performs its own signature validation regardless of the
setting of the AD bit.
5. Authenticating DNS Responses 5. Authenticating DNS Responses
In order to use DNSSEC RRs for authentication, a security-aware In order to use DNSSEC RRs for authentication, a security-aware
resolver requires preconfigured knowledge of at least one resolver requires preconfigured knowledge of at least one
authenticated DNSKEY or DS RR. The process for obtaining and authenticated DNSKEY or DS RR. The process for obtaining and
authenticating this initial DNSKEY or DS RR is achieved via some authenticating this initial DNSKEY or DS RR is achieved via some
external mechanism. For example, a resolver could use some off-line external mechanism. For example, a resolver could use some off-line
authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
that identifies and authenticates a zone's DNSKEY RR. The remainder that identifies and authenticates a zone's DNSKEY RR. The remainder
of this section assumes that the resolver has somehow obtained an of this section assumes that the resolver has somehow obtained an
initial set of authenticated DNSKEY RRs. initial set of authenticated DNSKEY RRs.
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
RRset. To authenticate an apex DNSKEY RRset using an initial key, RRset. To authenticate an apex DNSKEY RRset using an initial key,
the resolver MUST: the resolver MUST:
1. Verify that the initial DNSKEY RR appears in the apex DNSKEY 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
RRset, and verify that the DNSKEY RR has the Zone Key Flag RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
(DNSKEY RDATA bit 7) set to one. (DNSKEY RDATA bit 7) set to one.
2. Verify that there is some RRSIG RR which covers the apex DNSKEY 2. Verify that there is some RRSIG RR that covers the apex DNSKEY
RRset, and that the combination of the RRSIG RR and the initial RRset, and that the combination of the RRSIG RR and the initial
DNSKEY RR authenticates the DNSKEY RRset. The process for using DNSKEY RR authenticates the DNSKEY RRset. The process for using
an RRSIG RR to authenticate an RRset is described in Section 5.3. an RRSIG RR to authenticate an RRset is described in Section 5.3.
Once the resolver has authenticated the apex DNSKEY RRset using an Once the resolver has authenticated the apex DNSKEY RRset using an
initial DNSKEY RR, delegations from that zone can be authenticated initial DNSKEY RR, delegations from that zone can be authenticated
using DS RRs. This allows a resolver to start from an initial key, using DS RRs. This allows a resolver to start from an initial key,
and use DS RRsets to proceed recursively down the DNS tree obtaining and use DS RRsets to proceed recursively down the DNS tree obtaining
other apex DNSKEY RRsets. If the resolver were preconfigured with a other apex DNSKEY RRsets. If the resolver were preconfigured with a
root DNSKEY RR, and if every delegation had a DS RR associated with root DNSKEY RR, and if every delegation had a DS RR associated with
skipping to change at page 25, line 47 skipping to change at page 26, line 47
RRset. The process of using DS RRs to authenticate referrals is RRset. The process of using DS RRs to authenticate referrals is
described in Section 5.2. described in Section 5.2.
Once the resolver has authenticated a zone's apex DNSKEY RRset, Once the resolver has authenticated a zone's apex DNSKEY RRset,
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
DNSKEY RRset and RRSIG RRs from the zone to authenticate any other DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
RRsets in the zone. Section 5.4 shows how the resolver can use RRsets in the zone. Section 5.4 shows how the resolver can use
authenticated NSEC RRsets from the zone to prove that an RRset is not authenticated NSEC RRsets from the zone to prove that an RRset is not
present in the zone. present in the zone.
When a resolver indicates support for DNSSEC, a security-aware name When a resolver indicates support for DNSSEC (by setting the DO bit),
server should attempt to provide the necessary DNSKEY, RRSIG, NSEC, a security-aware name server should attempt to provide the necessary
and DS RRsets in a response (see Section 3). However, a DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
security-aware resolver may still receive a response which that lacks However, a security-aware resolver may still receive a response that
the appropriate DNSSEC RRs, whether due to configuration issues such that lacks the appropriate DNSSEC RRs, whether due to configuration
as a security-oblivious recursive name server which accidentally issues such as a security-oblivious recursive name server that
interfere with DNSSEC RRs or due to a deliberate attack in which an accidentally interfere with DNSSEC RRs or due to a deliberate attack
adversary forges a response, strips DNSSEC RRs from a response, or in which an adversary forges a response, strips DNSSEC RRs from a
modifies a query so that DNSSEC RRs appear not to be requested. The response, or modifies a query so that DNSSEC RRs appear not to be
absence of DNSSEC data in a response MUST NOT by itself be taken as requested. The absence of DNSSEC data in a response MUST NOT by
an indication that no authentication information exists. itself be taken as an indication that no authentication information
exists.
A resolver SHOULD expect authentication information from signed A resolver SHOULD expect authentication information from signed
zones. A resolver SHOULD believe that a zone is signed if the zones. A resolver SHOULD believe that a zone is signed if the
resolver has been configured with public key information for the resolver has been configured with public key information for the
zone, or if the zone's parent is signed and the delegation from the zone, or if the zone's parent is signed and the delegation from the
parent contains a DS RRset. parent contains a DS RRset.
5.1 Special Considerations for Islands of Security 5.1 Special Considerations for Islands of Security
Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
skipping to change at page 27, line 4 skipping to change at page 28, line 5
DNSKEY RRset. 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 which, when hashed using the digest algorithm specified in RRset that, when hashed using the digest algorithm specified in
the DS RR's Digest Type field, results in a digest value which the DS RR's Digest Type field, results in a digest value that
matches the Digest field of the DS RR; and matches the Digest field of the DS RR; and
o The matching DNSKEY RR in the child zone has the Zone Flag bit set o The matching DNSKEY RR in the child zone has the Zone Flag bit set
to one, the corresponding private key has signed the child zone's to one, the corresponding private key has signed the child zone's
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone's apex DNSKEY RRset. child zone's apex DNSKEY RRset.
If the referral from the parent zone did not contain a DS RRset, the If the referral from the parent zone did not contain a DS RRset, the
response should have included a signed NSEC RRset proving that no DS response should have included a signed NSEC RRset proving that no DS
RRset exists for the delegated name (see Section 3.1.4). A RRset exists for the delegated name (see Section 3.1.4). A
security-aware resolver MUST query the name servers for the parent security-aware resolver MUST query the name servers for the parent
zone for the DS RRset if the referral includes neither a DS RRset nor zone for the DS RRset if the referral includes neither a DS RRset nor
a NSEC RRset proving that the DS RRset does not exist (see Section a NSEC RRset proving that the DS RRset does not exist (see Section
4). 4).
If the resolver authenticates an NSEC RRset which proves that no DS If the resolver authenticates an NSEC RRset that proves that no DS
RRset is present for this zone, then there is no authentication path RRset is present for this zone, then there is no authentication path
leading from the parent to the child. If the resolver has an initial leading from the parent to the child. If the resolver has an initial
DNSKEY or DS RR which belongs to the child zone or to any delegation DNSKEY or DS RR that belongs to the child zone or to any delegation
below the child zone, this initial DNSKEY or DS RR MAY be used to below the child zone, this initial DNSKEY or DS RR MAY be used to
re-establish an authentication path. If no such initial DNSKEY or DS re-establish an authentication path. If no such initial DNSKEY or DS
RR exists, the resolver can not authenticate RRsets in or below the RR exists, the resolver can not authenticate RRsets in or below the
child zone. child zone.
Note that, for a signed delegation, there are two NSEC RRs associated Note that, for a signed delegation, there are two NSEC RRs associated
with the delegated name. One NSEC RR resides in the parent zone, and with the delegated name. One NSEC RR resides in the parent zone, and
can be used to prove whether a DS RRset exists for the delegated can be used to prove whether a DS RRset exists for the delegated
name. The second NSEC RR resides in the child zone, and identifies name. The second NSEC RR resides in the child zone, and identifies
which RRsets are present at the apex of the child zone. The parent which RRsets are present at the apex of the child zone. The parent
NSEC RR and child NSEC RR can always be distinguished, since the SOA NSEC RR and child NSEC RR can always be distinguished, since the SOA
bit will be set in the child NSEC RR and clear in the parent NSEC RR. bit will be set in the child NSEC RR and clear in the parent NSEC RR.
A security-aware resolver MUST use the parent NSEC RR when attempting A security-aware resolver MUST use the parent NSEC RR when attempting
to prove that a DS RRset does not exist. to prove that a DS RRset does not exist.
If the resolver does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver will not be able to verify
the authentication path to the child zone. In this case, the
resolver SHOULD treat the child zone as if it were unsigned.
5.3 Authenticating an RRset Using an RRSIG RR 5.3 Authenticating an RRset Using an RRSIG RR
A resolver can use an RRSIG RR and its corresponding DNSKEY RR to A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
attempt to authenticate RRsets. The resolver first checks the RRSIG attempt to authenticate RRsets. The resolver first checks the RRSIG
RR to verify that it covers the RRset, has a valid time interval, and RR to verify that it covers the RRset, has a valid time interval, and
identifies a valid DNSKEY RR. The resolver then constructs the identifies a valid DNSKEY RR. The resolver then constructs the
canonical form of the signed data by appending the RRSIG RDATA canonical form of the signed data by appending the RRSIG RDATA
(excluding the Signature Field) with the canonical form of the (excluding the Signature Field) with the canonical form of the
covered RRset. Finally, resolver uses the public key and signature covered RRset. Finally, resolver uses the public key and signature
to authenticate the signed data. Section 5.3.1, Section 5.3.2, and to authenticate the signed data. Section 5.3.1, Section 5.3.2, and
skipping to change at page 28, line 47 skipping to change at page 30, line 4
RR to use to authenticate the signature, MUST try each matching RR to use to authenticate the signature, MUST try each matching
DNSKEY RR until the resolver has either validated the signature or DNSKEY RR until the resolver has either validated the signature or
has run out of matching public keys to try. has run out of matching public keys to try.
Note that this authentication process is only meaningful if the Note that this authentication process is only meaningful if the
resolver authenticates the DNSKEY RR before using it to validate resolver authenticates the DNSKEY RR before using it to validate
signatures. The matching DNSKEY RR is considered to be authentic if: signatures. The matching DNSKEY RR is considered to be authentic if:
o The apex DNSKEY RRset containing the DNSKEY RR is considered o The apex DNSKEY RRset containing the DNSKEY RR is considered
authentic; or authentic; or
o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
and the DNSKEY RR either matches an authenticated DS RR from the and the DNSKEY RR either matches an authenticated DS RR from the
parent zone or matches a DS RR or DNSKEY RR which the resolver has parent zone or matches a DS RR or DNSKEY RR that the resolver has
been preconfigured to believe to be authentic. been preconfigured to believe to be authentic.
5.3.2 Reconstructing the Signed Data 5.3.2 Reconstructing the Signed Data
Once the RRSIG RR has met the validity requirements described in Once the RRSIG RR has met the validity requirements described in
Section 5.3.1, the resolver needs to reconstruct the original signed Section 5.3.1, the resolver needs to reconstruct the original signed
data. The original signed data includes RRSIG RDATA (excluding the data. The original signed data includes RRSIG RDATA (excluding the
Signature field) and the canonical form of the RRset. Aside from Signature field) and the canonical form of the RRset. Aside from
being ordered, the canonical form of the RRset might also differ from being ordered, the canonical form of the RRset might also differ from
the received RRset due to DNS name compression, decremented TTLs, or the received RRset due to DNS name compression, decremented TTLs, or
skipping to change at page 29, line 44 skipping to change at page 30, line 48
All names in the RDATA field are in canonical form All names in the RDATA field are in canonical form
The set of all RR(i) is sorted into canonical order. The set of all RR(i) is sorted into canonical order.
To calculate the name: To calculate the name:
let rrsig_labels = the value of the RRSIG Labels field let rrsig_labels = the value of the RRSIG Labels field
let fqdn = RRset's fully qualified domain name in let fqdn = RRset's fully qualified domain name in
canonical form canonical form
let fqdn_labels = RRset's fully qualified domain name in let fqdn_labels = Label count of the fqdn above.
canonical form
if rrsig_labels = fqdn_labels, if rrsig_labels = fqdn_labels,
name = fqdn name = fqdn
if rrsig_labels < fqdn_labels, if rrsig_labels < fqdn_labels,
name = "*." | the leftmost rrsig_label labels of the name = "*." | the rightmost rrsig_label labels of the
fqdn fqdn
if rrsig_labels > fqdn
if rrsig_labels > fqdn_labels
the RRSIG RR did not pass the necessary validation the RRSIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this checks and MUST NOT be used to authenticate this
RRset. RRset.
The canonical forms for names and RRsets are defined in The canonical forms for names and RRsets are defined in
[I-D.ietf-dnsext-dnssec-records]. [I-D.ietf-dnsext-dnssec-records].
NSEC RRsets at a delegation boundary require special processing. NSEC RRsets at a delegation boundary require special processing.
There are two distinct NSEC RRsets associated with a signed delegated There are two distinct NSEC RRsets associated with a signed delegated
name. One NSEC RRset resides in the parent zone, and specifies which name. One NSEC RRset resides in the parent zone, and specifies which
skipping to change at page 30, line 29 skipping to change at page 31, line 35
specify an SOA RRset exists at the name. When reconstructing the specify an SOA RRset exists at the name. When reconstructing the
original NSEC RRset for the delegation from the parent zone, the NSEC original NSEC RRset for the delegation from the parent zone, the NSEC
RRs MUST NOT be combined with NSEC RRs from the child zone, and when RRs MUST NOT be combined with NSEC RRs from the child zone, and when
reconstructing the original NSEC RRset for the apex of the child reconstructing the original NSEC RRset for the apex of the child
zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
zone. zone.
Note also that each of the two NSEC RRsets at a delegation point has Note also that each of the two NSEC RRsets at a delegation point has
a corresponding RRSIG RR with an owner name matching the delegated a corresponding RRSIG RR with an owner name matching the delegated
name, and each of these RRSIG RRs is authoritative data associated name, and each of these RRSIG RRs is authoritative data associated
with the same zone which contains the corresponding NSEC RRset. If with the same zone that contains the corresponding NSEC RRset. If
necessary, a resolver can tell these RRSIG RRs apart by checking the necessary, a resolver can tell these RRSIG RRs apart by checking the
Signer's Name field. Signer's Name field.
5.3.3 Checking the Signature 5.3.3 Checking the Signature
Once the resolver has validated the RRSIG RR as described in Section Once the resolver has validated the RRSIG RR as described in Section
5.3.1 and reconstructed the original signed data as described in 5.3.1 and reconstructed the original signed data as described in
Section 5.3.2, the resolver can attempt to use the cryptographic Section 5.3.2, the resolver can attempt to use the cryptographic
signature to authenticate the signed data, and thus (finally!) signature to authenticate the signed data, and thus (finally!)
authenticate the RRset. authenticate the RRset.
skipping to change at page 32, line 23 skipping to change at page 33, line 29
RR, then the existence of the NSEC RR proves that wildcard RR, then the existence of the NSEC RR proves that wildcard
expansion could not have been used to match the request. expansion could not have been used to match the request.
o If the requested RR name would appear after an authenticated NSEC o If the requested RR name would appear after an authenticated NSEC
RR's owner name and before the name listed in that NSEC RR's Next RR's owner name and before the name listed in that NSEC RR's Next
Domain Name field according to the canonical DNS name order Domain Name field according to the canonical DNS name order
defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
the requested name exist in the zone. However, it is possible the requested name exist in the zone. However, it is possible
that a wildcard could be used to match the requested RR owner name that a wildcard could be used to match the requested RR owner name
and type, so proving that the requested RRset does not exist also and type, so proving that the requested RRset does not exist also
requires proving that no possible wildcard RRset exists which requires proving that no possible wildcard RRset exists that could
could have been used to generate a positive response. have been used to generate a positive response.
To prove non-existence of an RRset, the resolver must be able to To prove non-existence of an RRset, the resolver must be able to
verify both that the queried RRset does not exist and that no verify both that the queried RRset does not exist and that no
relevant wildcard RRset exists. Proving this may require more than relevant wildcard RRset exists. Proving this may require more than
one NSEC RRset from the zone. If the complete set of necessary NSEC one NSEC RRset from the zone. If the complete set of necessary NSEC
RRsets is not present in a response (perhaps due to message RRsets is not present in a response (perhaps due to message
truncation), then a security-aware resolver MUST resend the query in truncation), then a security-aware resolver MUST resend the query in
order to attempt to obtain the full collection of NSEC RRs necessary order to attempt to obtain the full collection of NSEC RRs necessary
to verify non-existence of the requested RRset. As with all DNS to verify non-existence of the requested RRset. As with all DNS
operations, however, the resolver MUST bound the work it puts into operations, however, the resolver MUST bound the work it puts into
skipping to change at page 33, line 12 skipping to change at page 34, line 12
Appendix C shows an example the authentication process. Appendix C shows an example 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 [I-D.ietf-dnsext-ad-is-secure] meaning of the AD bit was redefined in [RFC3655] and the meaning of
and the meaning of both the CD and AD bit are restated in this both the CD and AD bit are restated in this document. No new bits in
document. No new bits in the DNS message header are defined in this the DNS message header are defined in this document.
document.
[RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
and defined its use. The use is restated but not altered in this and defined its use. The use is restated but not altered in this
document. document.
7. Security Considerations 7. Security Considerations
This document describes how the DNS security extensions use public This document describes how the DNS security extensions use public
key cryptography to sign and authenticate DNS resource record sets. key cryptography to sign and authenticate DNS resource record sets.
Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
skipping to change at page 36, line 34 skipping to change at page 37, line 34
[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.
[I-D.ietf-dnsext-dnssec-intro] [I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-07 (work in progress), draft-ietf-dnsext-dnssec-intro-09 (work in progress),
October 2003. February 2004.
[I-D.ietf-dnsext-dnssec-records] [I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions", Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-05 (work in progress), draft-ietf-dnsext-dnssec-records-07 (work in progress),
October 2003. February 2004.
Informative References Informative References
[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.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[I-D.ietf-dnsext-delegation-signer] [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Gudmundsson, O., "Delegation Signer Resource Record", Authenticated Data (AD) bit", RFC 3655, November 2003.
draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003. [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[I-D.ietf-dnsext-wcard-clarify] [I-D.ietf-dnsext-wcard-clarify]
Halley, B. and E. Lewis, "Clarifying the Role of Wild Card Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
Domains in the Domain Name System", Domains in the Domain Name System",
draft-ietf-dnsext-wcard-clarify-02 (work in progress), draft-ietf-dnsext-wcard-clarify-02 (work in progress),
September 2003. September 2003.
[I-D.ietf-dnsext-ad-is-secure]
Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD
bit", draft-ietf-dnsext-ad-is-secure-06 (work in
progress), June 2002.
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 Matt Larson
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Rob Austein Rob Austein
Internet Software Consortium Internet Systems Consortium
40 Gavin Circle 950 Charter Street
Reading, MA 01867 Redwood City, CA 94063
USA USA
EMail: sra@isc.org EMail: sra@isc.org
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
skipping to change at page 56, line 29 skipping to change at page 57, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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