draft-ietf-dnsext-dnssec-protocol-07.txt   draft-ietf-dnsext-dnssec-protocol-08.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: January 13, 2005 M. Larson Expires: March 21, 2005 M. Larson
VeriSign VeriSign
R. Austein R. Austein
ISC ISC
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
July 15, 2004 September 20, 2004
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-07 draft-ietf-dnsext-dnssec-protocol-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2005. This Internet-Draft will expire on March 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document is part of a family of documents which describe the DNS This document is part of a family of documents which describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of new resource records and protocol modifications which collection of new resource records and protocol modifications which
add data origin authentication and data integrity to the DNS. This add data origin authentication and data integrity to the DNS. This
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
security-aware resolver to authenticate both DNS resource records and security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications. authoritative DNS error indications.
skipping to change at page 2, line 25 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Background and Related Documents . . . . . . . . . . . . . 4 1.1 Background and Related Documents . . . . . . . . . . . . . 4
1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5
2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5
2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8
2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8
2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14
3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15
3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16
3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Signature Verification Support . . . . . . . . . . . . . . 19 4.2 Signature Verification Support . . . . . . . . . . . . . . 19
4.3 Determining Security Status of Data . . . . . . . . . . . 20 4.3 Determining Security Status of Data . . . . . . . . . . . 20
4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21
4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21
4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22
4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23
4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23
4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.1 Special Considerations for Islands of Security . . . . . . 26 5.1 Special Considerations for Islands of Security . . . . . . 26
skipping to change at page 3, line 23 skipping to change at page 3, line 25
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.4 Authenticating A Wildcard Expanded RRset Positive
Response . . . . . . . . . . . . . . . . . . . . . . . 31 Response . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31
5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32
5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 9.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45
B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
skipping to change at page 4, line 20 skipping to change at page 4, line 20
the DNSSEC protocol modifications. Section 2 of this document the DNSSEC protocol modifications. Section 2 of this document
defines the concept of a signed zone and lists the requirements for defines the concept of a signed zone and lists the requirements for
zone signing. Section 3 describes the modifications to authoritative zone signing. Section 3 describes the modifications to authoritative
name server behavior necessary to handle signed zones. Section 4 name server behavior necessary to handle signed zones. Section 4
describes the behavior of entities which include security-aware describes the behavior of entities which include security-aware
resolver functions. Finally, Section 5 defines how to use DNSSEC RRs resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
to authenticate a response. to authenticate a response.
1.1 Background and Related Documents 1.1 Background and Related Documents
The reader is assumed to be familiar with the basic DNS concepts This document is part of a family of documents that define DNSSEC,
described in [RFC1034] and [RFC1035]. which should be read together as a set.
This document is part of a family of documents that define DNSSEC. [I-D.ietf-dnsext-dnssec-intro] contains an introduction to DNSSEC and
An introduction to DNSSEC and definition of common terms can be found definitions of common terms; the reader is assumed to be familiar
in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be with this document. [I-D.ietf-dnsext-dnssec-intro] also contains a
familiar with this document. A definition of the DNSSEC resource list of other documents updated by and obsoleted by this document
records can be found in [I-D.ietf-dnsext-dnssec-records]. set.
[I-D.ietf-dnsext-dnssec-records] defines the DNSSEC resource records.
The reader is also assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that
update them, particularly [RFC2181] and [RFC2308].
This document defines the DNSSEC protocol operations.
1.2 Reserved Words 1.2 Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]. document are to be interpreted as described in RFC 2119. [RFC2119].
2. Zone Signing 2. Zone Signing
DNSSEC introduces the concept of signed zones. A signed zone DNSSEC introduces the concept of signed zones. A signed zone
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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 leftmost label if it 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. Note that, because RRSIG RRs
are closely tied to the RRsets whose signatures they contain, RRSIG
RRs, unlike all other DNS RR types, do not form RRsets. In
particular, the TTL values among RRSIG RRs with a common owner name
do not follow the RRset rules described in [RFC2181].
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 that 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 that 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 that 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 name servers) MUST NOT be signed. Glue address RRsets associated
with delegations MUST NOT be signed. with delegations MUST NOT be signed.
skipping to change at page 7, line 36 skipping to change at page 7, line 40
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 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. DS RRs which fail to meet these
conditions are not useful for validation, but since the DS RR and its
corresponding DNSKEY RR are in different zones, and since the DNS is
only loosely consistent, temporary mismatches can occur.
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
(that is, the NS RRset from the same zone containing the DS RRset). (that is, 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. A KEY RRset at that RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
name for secure dynamic update purposes is also allowed. Other types name for secure dynamic update purposes is also allowed ([RFC3007]).
MUST NOT be present at that name. 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 DNSSEC RR Types Appearing at Zone Cuts. 2.6 DNSSEC RR Types Appearing at Zone Cuts.
skipping to change at page 11, line 4 skipping to change at page 11, line 4
that 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 both the RRset and its If space does not permit inclusion of both the RRset and its
associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If associated RRSIG RRs, the name server MAY retain the RRset while
this happens, the name server MUST NOT set the TC bit solely dropping the RRSIG RRs. If this happens, the name server MUST NOT
because these RRSIG RRs didn't fit. set the TC bit 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 that has the DO bit set and that requests When responding to a query that has the DO bit set and that requests
the SOA or NS RRs at the apex of a signed zone, a security-aware the SOA or NS RRs at the apex of a signed zone, a security-aware
authoritative name server for that zone MAY return the zone apex authoritative name server for that zone MAY return the zone apex
DNSKEY RRset in the Additional section. In this situation, the DNSKEY RRset in the Additional section. In this situation, the
DNSKEY RRset and associated RRSIG RRs have lower priority than any DNSKEY RRset and associated RRSIG RRs have lower priority than any
other information that would be placed in the additional section. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 25
lookup algorithm described in Section 4.3.2 of [RFC1034]. lookup algorithm described in 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, a security-aware When responding to a query which has the DO bit set, a security-aware
authoritative name server returning a referral includes DNSSEC data authoritative name server returning a referral includes DNSSEC data
along with the NS RRset. 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) in the MUST return both the DS RRset and its associated RRSIG RR(s) in the
Authority section along with the NS RRset. The name server MUST Authority section along with the NS RRset.
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 16, line 15 skipping to change at page 16, line 13
the DS RRset, this is the parent zone. the DS RRset, this is the parent zone.
NSEC RRs appear in both the parent and child zones at a zone cut, and NSEC RRs appear in both the parent and child zones at a zone cut, and
are authoritative data in both the parent and child zones. The are authoritative data in both the parent and child zones. The
parental and child NSEC RRs at a zone cut are never identical to each parental and child NSEC RRs at a zone cut are never identical to each
other, since the NSEC RR in the child zone's apex will always other, since the NSEC RR in the child zone's apex will always
indicate the presence of the child zone's SOA RR while the parental indicate the presence of the child zone's SOA RR while the parental
NSEC RR at the zone cut will never indicate the presence of an SOA NSEC RR at the zone cut will never indicate the presence of an SOA
RR. As with any other authoritative RRs, NSEC RRs MUST be included RR. As with any other authoritative RRs, NSEC RRs MUST be included
in zone transfers of the zone in which they are authoritative data: in zone transfers of the zone in which they are authoritative data:
the parental NSEC RR at a zone cut MUST be included zone transfers of the parental NSEC RR at a zone cut MUST be included in zone transfers
the parent zone, while the NSEC at the zone apex of the child zone of the parent zone, while the NSEC at the zone apex of the child zone
MUST be included in zone transfers of the child zone. MUST be included in zone transfers of the child zone.
RRSIG RRs appear in both the parent and child zones at a zone cut, RRSIG RRs appear in both the parent and child zones at a zone cut,
and are authoritative in whichever zone contains the authoritative and are authoritative in whichever zone contains the authoritative
RRset for which the RRSIG RR provides the signature. That is, the RRset for which the RRSIG RR provides the signature. That is, the
RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
authoritative in the parent zone, while the RRSIG for any RRset in authoritative in the parent zone, while the RRSIG for any RRset in
the child zone's apex will be authoritative in the child zone. the child zone's apex will be authoritative in the child zone.
Parental and child RRSIG RRs at a zone cut will never be identical to Parental and child RRSIG RRs at a zone cut will never be identical to
each other, since the Signer's Name field of an RRSIG RR in the child each other, since the Signer's Name field of an RRSIG RR in the child
skipping to change at page 19, line 22 skipping to change at page 19, line 22
Section 3.2. Section 3.2.
4.1 EDNS Support 4.1 EDNS Support
A security-aware resolver MUST include an EDNS [RFC2671] OPT A security-aware resolver MUST include an EDNS [RFC2671] OPT
pseudo-RR with the DO [RFC3225] bit set when sending queries. pseudo-RR with the DO [RFC3225] bit set when sending queries.
A security-aware resolver MUST support a message size of at least A security-aware resolver MUST support a message size of at least
1220 octets, SHOULD support a message size of 4000 octets, and MUST 1220 octets, SHOULD support a message size of 4000 octets, and MUST
advertise the supported message size using the "sender's UDP payload advertise the supported message size using the "sender's UDP payload
size" field in the EDNS OPT pseudo-RR. A security-aware resolver size" field in the EDNS OPT pseudo-RR. A security-aware resolver's
MUST handle fragmented UDP packets correctly regardless of whether IP layer MUST handle fragmented UDP packets correctly regardless of
any such fragmented packets were received via IPv4 or IPv6. Please whether any such fragmented packets were received via IPv4 or IPv6.
see [RFC3226] for discussion of these requirements. Please see [RFC1122], [RFC2460] and [RFC3226] for discussion of these
requirements.
4.2 Signature Verification Support 4.2 Signature Verification Support
A security-aware resolver MUST support the signature verification A security-aware resolver MUST support the signature verification
mechanisms described in Section 5, and SHOULD apply them to every mechanisms described in Section 5, and SHOULD apply them to every
received response except when: received response except when:
o The security-aware resolver is part of a security-aware recursive o The security-aware resolver is part of a security-aware recursive
name server, and the response is the result of recursion on behalf name server, and the response is the result of recursion on behalf
of a query received with the CD bit set; of a query received with the CD bit set;
o The response is the result of a query generated directly via some o The response is the result of a query generated directly via some
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.
Security aware resolvers MAY query for missing security RRs in an Security aware resolvers MAY query for missing security RRs in an
attempt to perform validation; implementations that choose to do so attempt to perform validation; implementations that choose to do so
must be aware that the answers received may not be sufficient to must be aware that the answers received may not be sufficient to
validate the original response. validate the original response. For example, a zone update may have
changed (or deleted) the desired information between the original and
follow-up queries.
When attempting to retrieve missing NSEC RRs which reside on the When attempting to retrieve missing NSEC RRs which reside on the
parental side at a zone cut, a security-aware iterative-mode resolver parental side at a zone cut, a security-aware iterative-mode resolver
MUST query the name servers for the parent zone, not the child zone. MUST query the name servers for the parent zone, not the child zone.
When attempting to retrieve a missing DS, a security-aware When attempting to retrieve a missing DS, a security-aware
iterative-mode resolver MUST query the name servers for the parent iterative-mode resolver MUST query the name servers for the parent
zone, not the child zone. As explained in Section 3.1.4.1, zone, not the child zone. As explained in Section 3.1.4.1,
security-aware name servers need to apply special processing rules to security-aware name servers need to apply special processing rules to
handle the DS RR, and in some situations the resolver may also need handle the DS RR, and in some situations the resolver may also need
skipping to change at page 25, line 21 skipping to change at page 25, line 21
example, a resolver could use some off-line authenticated exchange to example, a resolver could use some off-line authenticated exchange to
obtain a zone's DNSKEY RR or obtain a DS RR that identifies and obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
authenticates a zone's DNSKEY RR. The remainder of this section authenticates a zone's DNSKEY RR. The remainder of this section
assumes that the resolver has somehow obtained an initial set of assumes that the resolver has somehow obtained an initial set of
trust anchors. trust anchors.
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 MUST have the Zone Key Flag RRset, and verify that the DNSKEY RR has the Zone Key Flag
(DNSKEY RDATA bit 7) set. (DNSKEY RDATA bit 7) set.
2. Verify that there is some RRSIG RR that 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
skipping to change at page 25, line 49 skipping to change at page 25, line 49
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 (by setting the DO bit), When a resolver indicates support for DNSSEC (by setting the DO bit),
a security-aware name server should attempt to provide the necessary a security-aware name server should attempt to provide the necessary
DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
However, a security-aware resolver may still receive a response that However, a security-aware resolver may still receive a response that
that lacks the appropriate DNSSEC RRs, whether due to configuration lacks the appropriate DNSSEC RRs, whether due to configuration issues
issues such as an upstream security-oblivious recursive name server such as an upstream security-oblivious recursive name server that
that accidentally interferes with DNSSEC RRs or due to a deliberate accidentally interferes with DNSSEC RRs or due to a deliberate attack
attack in which an adversary forges a response, strips DNSSEC RRs in which an adversary forges a response, strips DNSSEC RRs from a
from a response, or modifies a query so that DNSSEC RRs appear not to response, or modifies a query so that DNSSEC RRs appear not to be
be requested. The absence of DNSSEC data in a response MUST NOT by requested. The absence of DNSSEC data in a response MUST NOT by
itself be taken as an indication that no authentication information itself be taken as an indication that no authentication information
exists. 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
skipping to change at page 26, line 49 skipping to change at page 26, line 49
resolver to authenticate the matching DNSKEY RR. The resolver can resolver to authenticate the matching DNSKEY RR. The resolver can
then use this child DNSKEY RR to authenticate the entire child apex then use this child DNSKEY RR to authenticate the entire child apex
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 and, when hashed using the digest algorithm specified in the RRset and, when the DNSKEY RR's owner name and RDATA are hashed
DS RR's Digest Type field, results in a digest value that matches using the digest algorithm specified in the DS RR's Digest Type
the Digest field of the DS RR; and field, the resulting digest value matches the Digest field of the
DS RR; and
o The matching DNSKEY RR in the child zone has the Zone Flag bit o The matching DNSKEY RR in the child zone has the Zone Flag bit
set, the corresponding private key has signed the child zone's set, 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
skipping to change at page 34, line 11 skipping to change at page 34, line 11
[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
security considerations related to DNSSEC; see security considerations related to DNSSEC; see
[I-D.ietf-dnsext-dnssec-intro] for considerations specific to the [I-D.ietf-dnsext-dnssec-records] for considerations specific to the
DNSSEC resource record types. DNSSEC resource record types.
An active attacker who can set the CD bit in a DNS query message or An active attacker who can set the CD bit in a DNS query message or
the AD bit in a DNS response message can use these bits to defeat the the AD bit in a DNS response message can use these bits to defeat the
protection which DNSSEC attempts to provide to security-oblivious protection which DNSSEC attempts to provide to security-oblivious
recursive-mode resolvers. For this reason, use of these control bits recursive-mode resolvers. For this reason, use of these control bits
by a security-aware recursive-mode resolver requires a secure by a security-aware recursive-mode resolver requires a secure
channel. See Section 3.2.2 and Section 4.9 for further discussion. channel. See Section 3.2.2 and Section 4.9 for further discussion.
The protocol described in this document attempts to extend the The protocol described in this document attempts to extend the
skipping to change at page 36, line 27 skipping to change at page 36, line 27
Rose, "Resource Records for DNS Security Extensions", Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-08 (work in progress), draft-ietf-dnsext-dnssec-records-08 (work in progress),
May 2004. May 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999. 2672, August 1999.
[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.
9.2 Informative References 9.2 Informative References
[I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004.
[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.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003. Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003. (RR)", RFC 3658, December 2003.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Drienerlolaan 5
7522 NB Enschede 7522 NB Enschede
NL NL
EMail: roy.arends@telin.nl EMail: roy.arends@telin.nl
skipping to change at page 56, line 10 skipping to change at page 56, line 10
C.5 Referral to Unsigned Zone C.5 Referral to Unsigned Zone
The query in section Appendix B.5 returned a referral to an unsigned The query in section Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from "b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example" and the NSEC RR is authenticated in a manner "example" to "b.example" and the NSEC RR is authenticated in a manner
identical to that of the MX RRset discussed above. identical to that of the MX RRset discussed above.
C.6 Wildcard Expansion C.6 Wildcard Expansion
The query in section Appendix B.6 returned an answer that was The query in section Appendix B.6 returned an answer that was
produced as a result of wildcard expansion. The RRset expanded as produced as a result of wildcard expansion. The answer section
the similar to The corresponding RRSIG indicates the MX RRset was contains a wildcard RRset expanded as in a traditional DNS response
signed by an "example" DNSKEY with algorithm 5 and key tag 38519. and the corresponding RRSIG indicates that the expanded wildcard MX
The RRSIG indicates the original TTL of the MX RRset was 3600 and, RRset was signed by an "example" DNSKEY with algorithm 5 and key tag
for the purpose of authentication, the current TTL is replaced by 38519. The RRSIG indicates the original TTL of the MX RRset was 3600
3600. The RRSIG labels field value of 2 indicates the answer the and, for the purpose of authentication, the current TTL is replaced
by 3600. The RRSIG labels field value of 2 indicates the answer the
result of wildcard expansion since the "a.z.w.example" name contains result of wildcard expansion since the "a.z.w.example" name contains
4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
the MX RRset is placed in canonical form and, assuming the current the MX RRset is placed in canonical form and, assuming the current
time falls between the signature inception and expiration dates, the time falls between the signature inception and expiration dates, the
signature is authenticated. signature is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query and the NSEC RR must also be have been used to answer this query and the NSEC RR must also be
authenticated before the answer is considered valid. authenticated before the answer is considered valid.
 End of changes. 

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