draft-ietf-dnsext-dnssec-protocol-06.txt   draft-ietf-dnsext-dnssec-protocol-07.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: November 15, 2004 M. Larson Expires: January 13, 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
May 17, 2004 July 15, 2004
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-06 draft-ietf-dnsext-dnssec-protocol-07
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
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 http:// The list of current Internet-Drafts can be accessed at
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 November 15, 2004. This Internet-Draft will expire on January 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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
skipping to change at page 2, line 17 skipping to change at page 2, line 20
authoritative DNS error indications. authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535. updates to RFC 2535.
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
1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . 4 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5
1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7
2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7
2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8
2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15
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.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . 18
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Signature Verification Support . . . . . . . . . . . . . . 20 4.2 Signature Verification Support . . . . . . . . . . . . . . 19
4.3 Determining Security Status of Data . . . . . . . . . . . 21 4.3 Determining Security Status of Data . . . . . . . . . . . 20
4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20
4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 24 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23
4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 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
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.4 Authenticating A Wildcard Expanded RRset Positive
Response . . . . . . . . . . . . . . . . . . . . . . . 31 Response . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 4, line 10 skipping to change at page 4, line 10
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . 57 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
the concept of a signed zone and lists the requirements for zone defines the concept of a signed zone and lists the requirements for
signing. Section 3 describes the modifications to authoritative name zone signing. Section 3 describes the modifications to authoritative
server behavior necessary to handle signed zones. Section 4 describes name server behavior necessary to handle signed zones. Section 4
the behavior of entities which include security-aware resolver describes the behavior of entities which include security-aware
functions. Finally, Section 5 defines how to use DNSSEC RRs to resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
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 The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034] and [RFC1035]. described in [RFC1034] and [RFC1035].
This document is part of a family of documents that define DNSSEC. This document is part of a family of documents that define DNSSEC.
An introduction to DNSSEC and definition of common terms can be found An introduction to DNSSEC and definition of common terms can be found
in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be
resource records can be found in [I-D.ietf-dnsext-dnssec-records]. familiar with this document. A definition of the DNSSEC resource
records can be found in [I-D.ietf-dnsext-dnssec-records].
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].
1.3 Editors' Notes
1.3.1 Open Technical Issues
1.3.2 Technical Changes or Corrections
Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical
change where no RFC that defines the correct behavior, or if there's
more than one applicable RFC and the definitions conflict, please
post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
DNSSEC RR types MUST NOT be included in responses unless the resolver
indicated support for DNSSEC.
1.3.3 Typos and Minor Corrections
Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to find
the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It
should read "over 10 years".
2. Zone Signing 2. Zone Signing
DNSSEC introduces the concept of signed zones. A signed zone DNSSEC introduces the concept of signed zones. A signed zone
includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to includes 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. A zone that does not include these Section 2.4, respectively. A zone that does not include these
records according to the rules in this section is an unsigned zone. records according to the rules in this section is an unsigned zone.
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
and NSEC RRs to appear at the same owner name as a CNAME RR. and NSEC RRs to appear at the same owner name as a CNAME RR.
DNSSEC specifies the placement of two new RR types, NSEC and DS,
which can be placed at the parental side of a zone cut (that is, at a
delegation point). This is an exception to the general prohibition
against putting data in the parent zone at a zone cut. Section 2.6
describes this change.
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 with create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
the public component stored in the zone. A zone key DNSKEY RR MUST containing the corresponding public key. A zone key DNSKEY RR MUST
have the Zone Key bit of the flags RDATA field set to one -- see have the Zone Key bit of the flags RDATA field set -- see Section
Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated
associated with other DNS operations MAY be stored in DNSKEY RRs that with other DNS operations MAY be stored in DNSKEY RRs that are not
are not marked as zone keys but MUST NOT be used to verify RRSIGs. 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 administrator intends a signed zone to be usable other
security, the zone MUST have at least one DNSKEY RR at the apex to than as an island of security, the zone apex MUST contain at least
act as a secure entry point into the zone. This DNSKEY would then be one DNSKEY RR to act as a secure entry point into the zone. This
used to generate a DS RR at the delegating parent (see secure entry point could then be used as the target of a secure
delegation via a corresponding DS RR in the parent zone (see
[I-D.ietf-dnsext-dnssec-records]). [I-D.ietf-dnsext-dnssec-records]).
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, there MUST be at least For each authoritative RRset in a signed zone, 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
skipping to change at page 7, line 16 skipping to change at page 6, line 21
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 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 with name servers) MUST NOT be signed. Glue address RRsets associated
delegations MUST NOT be signed. with delegations MUST NOT be signed.
There MUST be an RRSIG for each RRset using at least one DNSKEY of There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any). located at the delegating parent (if any).
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 format of NSEC RRs and the process for constructing the NSEC RR for a
[I-D.ietf-dnsext-dnssec-records]. given name is described in [I-D.ietf-dnsext-dnssec-records].
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
value field in the zone SOA RR. 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
RRset at any particular owner name. That is, the signing process RRset at any particular owner name. That is, the signing process
MUST NOT create NSEC or RRSIG RRs for owner names nodes which were MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
not the owner name of any RRset before the zone was signed. The main not the owner name of any RRset before the zone was signed. The main
reasons for this are a desire for namespace consistency between reasons for this are a desire for namespace consistency between
signed and unsigned versions of the same zone and a desire to reduce signed and unsigned versions of the same zone and a desire to reduce
skipping to change at page 8, line 13 skipping to change at page 7, line 20
authoritative and also at the owner names of delegations from the authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part is RRsets. Note, however, that this distinction is for the most part is
only visible during the zone signing process, because NSEC RRsets are only visible during the zone signing process, because NSEC RRsets are
authoritative data, and are therefore signed, thus any owner name authoritative data, and are therefore signed, thus any owner name
which has an NSEC RRset will have RRSIG RRs as well in the signed which has an NSEC RRset will have RRSIG RRs as well in the signed
zone. zone.
The bitmap for the NSEC RR at a delegation point requires special The bitmap for the NSEC RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and the RR attention. Bits corresponding to the delegation NS RRset and any
types for which the parent zone has authoritative data MUST be set to RRsets for which the parent zone has authoritative data MUST be set;
1; bits corresponding to any non-NS RRset for which the parent is not bits corresponding to any non-NS RRset for which the parent is not
authoritative MUST be set to 0. authoritative MUST be clear.
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 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 delegating NS RRset The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
(i.e., 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. Other types
MUST NOT be present at that name. 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 DNSSEC RR Types Appearing at Zone Cuts.
DNSSEC introduced two new RR types that are unusual in that they can
appear at the parental side of a zone cut. At the parental side of a
zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
the owner name. A DS RR could also be present if the zone being
delegated is signed and wishes to have a chain of authentication to
the parent zone. This is an exception to the original DNS
specification ([RFC1034]) which states that only NS RRsets could
appear at the parental side of a zone cut.
This specification updates the original DNS specification to allow
NSEC and DS RR types at the parent side of a zone cut. These RRsets
are authoritative for the parent when they appear at the parent side
of a zone cut.
2.7 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 that include This section describes the behavior of entities that include
security-aware name server functions. In many cases such functions security-aware name server functions. In many cases such functions
will be part of a security-aware recursive name server, but a will be part of a security-aware recursive name server, but a
security-aware authoritative name server has some of the same security-aware authoritative name server has some of the same
requirements. Functions specific to security-aware recursive name requirements. Functions specific to security-aware recursive name
servers are described in Section 3.2; functions specific to servers are described in Section 3.2; functions specific to
authoritative servers are described in Section 3.1. authoritative servers are described in Section 3.1.
The terms "SNAME", "SCLASS", and "STYPE" in the following discussion The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
are as used in [RFC1034]. are as used in [RFC1034].
A security-aware name server MUST support the EDNS0 [RFC2671] message A security-aware name server MUST support the EDNS0 [RFC2671] 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 that receives a DNS query that does not A security-aware name server which receives a DNS query that does not
include the EDNS OPT pseudo-RR or that has the DO bit set to zero include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
RRset, and MUST NOT perform any of the additional processing and MUST NOT perform any of the additional processing described
described below. Since the DS RR type has the peculiar property of below. Since the DS RR type has the peculiar property of only
only existing in the parent zone at delegation points, DS RRs always existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.1.4.1. require some special processing, as described in Section 3.1.4.1.
Security aware name servers that receive queries for security RR Security aware name servers that receive explicit queries for
types which match the content of more than one zone that it serves security RR types which match the content of more than one zone that
(e.g. NSEC and RRSIG RRs above and below a delegation point where the it serves (for example, NSEC and RRSIG RRs above and below a
server is authoritative for both zones) are encouraged to behave delegation point where the server is authoritative for both zones)
self-consistently. The name server MAY return one of the following: should behave self-consistently. The name server MAY return one of
the following:
o The above-delegation RRsets o The above-delegation RRsets
o The below-delegation RRsets o The below-delegation RRsets
o Both above and below-delegation RRsets o Both above and below-delegation RRsets
o Empty answer section (i.e. no records) o Empty answer section (no records)
o Some other response o Some other response
o An error o An error
As long as the response is always consistent for each query to the As long as the response is always consistent for each query to the
name server. name server.
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
skipping to change at page 11, line 12 skipping to change at page 10, line 12
Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
on the behavior of these bits. on the behavior of these bits.
A security aware name server which synthesizes CNAME RRs from DNAME A security aware name server which synthesizes CNAME RRs from DNAME
RRs as described in [RFC2672] SHOULD NOT generate signatures for the RRs as described in [RFC2672] SHOULD NOT generate signatures for the
synthesized CNAME RRs. synthesized CNAME RRs.
3.1 Authoritative Name Servers 3.1 Authoritative Name Servers
Upon receiving a relevant query that has the EDNS [RFC2671] OPT Upon receiving a relevant query that has the EDNS [RFC2671] OPT
pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name
name server for a signed zone MUST include additional RRSIG, NSEC, server for a signed zone MUST include additional RRSIG, NSEC, and DS
and DS RRs according to the following rules: RRs according to the following rules:
o RRSIG RRs that can be used to authenticate a response MUST be o RRSIG RRs that can be used to authenticate a response MUST be
included in the response according to the rules in Section 3.1.1; included in the response according to the rules in Section 3.1.1;
o NSEC RRs that can be used to provide authenticated denial of o NSEC RRs that can be used to provide authenticated denial of
existence MUST be included in the response automatically according existence MUST be included in the response automatically according
to the rules in Section 3.1.3; to the rules in Section 3.1.3;
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
be included in referrals automatically according to the rules in be included in referrals automatically according to the rules in
Section 3.1.4. Section 3.1.4.
These rules only apply to responses the semantics of which convey
information about the presence or absence of resource records. That
is, these rules are not intended to rule out responses such as RCODE
4 ("Not Implemented") or RCODE 5 ("Refused").
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 that has the DO bit set to one, a When responding to a query that has the DO bit set, a security-aware
security-aware authoritative name server SHOULD attempt to send RRSIG authoritative name server SHOULD attempt to send RRSIG RRs that a
RRs that a security-aware resolver can use to authenticate the RRsets security-aware resolver can use to authenticate the RRsets in the
in the response. A name server SHOULD make every attempt to keep the response. A name server SHOULD make every attempt to keep the RRset
RRset and its associated RRSIG(s) together in a response. Inclusion and its associated RRSIG(s) together in a response. Inclusion of
of RRSIG RRs in a response is subject to the following rules: RRSIG RRs in a response is subject to 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
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 drop the RRSIG RRs. If
this happens, the name server MUST NOT set the TC bit solely this happens, the name server MUST NOT set the TC bit solely
because these RRSIG RRs didn't fit. 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 to one and that When responding to a query that has the DO bit set and that requests
requests the SOA or NS RRs at the apex of a signed zone, a the SOA or NS RRs at the apex of a signed zone, a security-aware
security-aware authoritative name server for that zone MAY return the authoritative name server for that zone MAY return the zone apex
zone apex DNSKEY RRset in the Additional section. In this situation, DNSKEY RRset in the Additional section. In this situation, the
the DNSKEY RRset and associated RRSIG RRs have lower priority than DNSKEY RRset and associated RRSIG RRs have lower priority than any
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
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 that has the DO bit set to one, a When responding to a query that has the DO bit set, a security-aware
security-aware authoritative name server for a signed zone MUST authoritative name server for a signed zone MUST include NSEC RRs in
include NSEC RRs in each of the following cases: each of the following cases:
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>, No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
but does not contain any RRsets that exactly match <SNAME, SCLASS, but does not contain any RRsets that exactly match <SNAME, SCLASS,
STYPE>. STYPE>.
Name Error: The zone does not contain any RRsets that 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 that exactly Wildcard Answer: The zone does not contain any RRsets that exactly
match <SNAME, SCLASS> but does contain an RRset that matches match <SNAME, SCLASS> but does contain an RRset that matches
skipping to change at page 15, line 14 skipping to change at page 14, line 19
precisely the same as the algorithm for finding the NSEC RR which precisely the same as the algorithm for finding the NSEC RR which
proves that RRsets with any other owner name do not exist: the part proves that RRsets with any other owner name do not exist: the part
that's missing is how to determine the name of the nonexistent that's missing is how to determine the name of the nonexistent
applicable wildcard. In practice, this is easy, because the applicable wildcard. In practice, this is easy, because the
authoritative name server has already checked for the presence of authoritative name server has already checked for the presence of
precisely this wildcard name as part of step (1)(c) of the normal precisely this wildcard name as part of step (1)(c) of the normal
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 to one, a When responding to a query which has the DO bit set, a security-aware
security-aware authoritative name server returning a referral authoritative name server returning a referral includes DNSSEC data
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. The name server MUST
place the NS RRset before the DS RRset and its associated RRSIG place the NS RRset before the DS RRset and its associated RRSIG
RR(s). 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
skipping to change at page 17, line 20 skipping to change at page 16, line 24
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 zone transfers of
the parent zone, while the NSEC at the zone apex of the child zone 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. As the child zone's apex will be authoritative in the child zone.
with any other authoritative RRs, RRSIG RRs MUST be included in zone Parental and child RRSIG RRs at a zone cut will never be identical to
transfers of the zone in which they are authoritative data. each other, since the Signer's Name field of an RRSIG RR in the child
zone's apex will indicate a DNSKEY RR in the child zone's apex while
the same field of a parental RRSIG RR at the zone cut will indicate a
DNSKEY RR in the parent zone's apex. As with any other authoritative
RRs, RRSIG RRs MUST be included in zone transfers of the zone in
which they are authoritative data.
3.1.6 The AD and CD Bits in an Authoritative Response 3.1.6 The AD and CD Bits in an Authoritative Response
The CD and AD bits are designed for use in communication between The CD and AD bits are designed for use in communication between
security-aware resolvers and security-aware recursive name servers. security-aware resolvers and security-aware recursive name servers.
These bits are for the most part not relevant to query processing by These bits are for the most part not relevant to query processing by
security-aware authoritative name servers. security-aware authoritative name servers.
A security-aware name server does not perform signature validation A security-aware name server does not perform signature validation
for authoritative data during query processing even when the CD bit for authoritative data during query processing even when the CD bit
is set to zero. A security-aware name server SHOULD clear the CD bit is clear. A security-aware name server SHOULD clear the CD bit when
when composing an authoritative response. 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 and 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.
skipping to change at page 18, line 37 skipping to change at page 17, line 46
disable signature validation in a security-aware name server's disable signature validation in a security-aware name server's
processing of a particular query. processing of a particular query.
The name server side MUST copy the setting of the CD bit from a query The name server side MUST copy the setting of the CD bit from a query
to the corresponding response. to the corresponding response.
The name server side of a security-aware recursive name server MUST The name server side of a security-aware recursive name server MUST
pass the sense of the CD bit to the resolver side along with the rest pass the 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, 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 the recursive name server SHOULD,
SHOULD, if possible, return the requested data to the originating if possible, return the requested data to the originating resolver
resolver even if the recursive name server's local authentication even if the recursive name server's local authentication policy would
policy would reject the records in question. That is, by setting the reject the records in question. That is, by setting the CD bit, the
CD bit, the originating resolver has indicated that it takes originating resolver has indicated that it takes responsibility for
responsibility for performing its own authentication, and the performing its own authentication, and the recursive name server
recursive name server should not interfere. should not interfere.
If the resolver side implements a BAD cache (see Section 4.7) and the If the resolver side implements a BAD cache (see Section 4.7) and the
name server side receives a query which matches an entry in the name server side receives a query which matches an entry in the
resolver side's BAD cache, the name server side's response depends on resolver side's BAD cache, the name server side's response depends on
the sense of the CD bit in the original query. If the CD bit is set, the 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).
The intent of the above rule is to provide the raw data to clients The intent of the above rule is to provide the raw data to clients
skipping to change at page 20, line 17 skipping to change at page 19, line 17
This section describes the behavior of entities that include This section describes the behavior of entities that include
security-aware resolver functions. In many cases such functions will security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements. Functions security-aware resolver has many of the same requirements. Functions
specific to security-aware recursive name servers are described in specific to security-aware recursive name servers are described in
Section 3.2. Section 3.2.
4.1 EDNS Support 4.1 EDNS Support
A security-aware resolver MUST include an EDNS [RFC2671] OPT A security-aware resolver MUST include an EDNS [RFC2671] OPT
pseudo-RR with the DO [RFC3225] bit set to one 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 MUST size" field in the EDNS OPT pseudo-RR. A security-aware resolver
handle fragmented UDP packets correctly regardless of whether any MUST handle fragmented UDP packets correctly regardless of whether
such fragmented packets were received via IPv4 or IPv6. Please see any such fragmented packets were received via IPv4 or IPv6. Please
[RFC3226] for discussion of these requirements. see [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 MUST 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 of the fact that the answers received may not be must be aware that the answers received may not be sufficient to
sufficient to validate the original response. validate the original response.
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 22, line 28 skipping to change at page 21, line 28
A security-aware resolver SHOULD cache each response as a single A security-aware resolver SHOULD cache each response as a single
atomic entry containing the entire answer, including the named RRset atomic entry containing the entire answer, including the named RRset
and any associated DNSSEC RRs. The resolver SHOULD discard the 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. In
most cases the appropriate cache index for the atomic entry will be most cases the appropriate cache index for the atomic entry will be
the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response 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 form described in Section 3.1.3.2 the appropriate cache index will be
the double <QNAME,QCLASS>. the double <QNAME,QCLASS>.
The reason for these recommendations is that, between the initial
query and the expiration of the data from the cache, the
authoritative data might have been changed (for example, via dynamic
update).
There are two situations for which this is relevant:
1. By using the RRSIG record, it is possible to deduce that an
answer was synthesized from a wildcard. A security aware
recursive name server could store this wildcard data and use it
to generate positive responses to queries other than the name for
which the original answer was first received.
2. NSEC RRs received to prove the non-existence of a name could be
reused by a security aware resolver to prove the non-existence of
any name in the name range it spans.
In theory, a resolver could use wildcards or NSEC RRs to generate
positive and negative responses (respectively) until the TTL or
signatures on the records in question expire. However, it seems
prudent for resolvers to avoid blocking new authoritative data or
synthesizing new data on their own. Resolvers which follow this
recommendation will have a more consistent view of the namespace.
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 a query's CD bit in order to
order to indicate that the resolver takes responsibility for indicate that the resolver takes responsibility for performing
performing whatever authentication its local policy requires on the whatever authentication its local policy requires on the RRsets in
RRsets in the response. See Section 3.2 for the effect this bit has the response. See Section 3.2 for the effect this bit has on the
on the behavior of security-aware recursive name servers. behavior of security-aware recursive name servers.
A security-aware resolver MUST zero the AD bit when composing query A security-aware resolver MUST clear the AD bit when composing query
messages to protect against buggy name servers which blindly copy messages to protect against buggy name servers which blindly copy
header bits which they do not understand from the query message to header bits which they do not understand from the query message to
the response message. the response message.
A resolver MUST disregard the meaning of the CD and AD bits in a 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 response unless the response was obtained using a secure channel or
the resolver was specifically configured to regard the message header the resolver was specifically configured to regard the message header
bits without using a secure channel. bits without using a secure channel.
4.7 Caching BAD Data 4.7 Caching BAD Data
skipping to change at page 25, line 22 skipping to change at page 25, line 22
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 MUST have the Zone Key Flag
(DNSKEY RDATA bit 7) set to one. (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
other apex DNSKEY RRsets. If the resolver were configured with a other apex DNSKEY RRsets. If the resolver were configured with a
skipping to change at page 27, line 4 skipping to change at page 27, line 4
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 hashed using the digest algorithm specified in the
DS RR's Digest Type field, results in a digest value that matches DS RR's Digest Type field, results in a digest value that matches
the Digest field of the DS RR; and 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
to one, 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
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).
skipping to change at page 28, line 32 skipping to change at page 28, line 32
or equal to the value in the RRSIG RR's Labels field; or equal to the value in the RRSIG RR's Labels field;
o The validator's notion of the current time MUST be less than or o The validator's notion of the current time MUST be less than or
equal to the time listed in the RRSIG RR's Expiration field; equal to the time listed in the RRSIG RR's Expiration field;
o The validator's notion of the current time MUST be greater than or o The validator's notion of the current time MUST be greater than or
equal to the time listed in the RRSIG RR's Inception field; equal to the time listed in the RRSIG RR's Inception field;
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
match the owner name, algorithm, and key tag for some DNSKEY RR in match the owner name, algorithm, and key tag for some DNSKEY RR in
the zone's apex DNSKEY RRset; the zone's apex DNSKEY RRset;
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
set to one. set.
It is possible for more than one DNSKEY RR to match the conditions It is possible for more than one DNSKEY RR to match the conditions
above. In this case, the validator cannot predetermine which DNSKEY above. In this case, the validator cannot predetermine which DNSKEY
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 either the signature is validated or the validator DNSKEY RR until either the signature is validated or the validator
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
validator authenticates the DNSKEY RR before using it to validate validator 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:
skipping to change at page 31, line 46 skipping to change at page 31, line 46
Note that the response received by the resolver should include all Note that the response received by the resolver should include all
NSEC RRs needed to authenticate the response (see Section 3.1.3). NSEC RRs needed to authenticate the response (see Section 3.1.3).
5.4 Authenticated Denial of Existence 5.4 Authenticated Denial of Existence
A resolver can use authenticated NSEC RRs to prove that an RRset is A resolver can use authenticated NSEC RRs to prove that an RRset is
not present in a signed zone. Security-aware name servers should not present in a signed zone. Security-aware name servers should
automatically include any necessary NSEC RRs for signed zones in automatically include any necessary NSEC RRs for signed zones in
their responses to security-aware resolvers. their responses to security-aware resolvers.
Security-aware resolvers MUST first authenticate NSEC RRsets Denial of existence is determined by the following rules:
according to the standard RRset authentication rules described in
Section 5.3, then apply the NSEC RRsets as follows:
o If the requested RR name matches the owner name of an o If the requested RR name matches the owner name of an
authenticated NSEC RR, then the NSEC RR's type bit map field lists authenticated NSEC RR, then the NSEC RR's type bit map field lists
all RR types present at that owner name, and a resolver can prove all RR types present at that owner name, and a resolver can prove
that the requested RR type does not exist by checking for the RR that the requested RR type does not exist by checking for the RR
type in the bit map. If the number of labels in an authenticated type in the bit map. If the number of labels in an authenticated
NSEC RR's owner name equals the Labels field of the covering RRSIG NSEC RR's owner name equals the Labels field of the covering RRSIG
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 that could requires proving that no possible wildcard RRset exists that could
have been used to generate a positive response. have been used to generate a positive response.
In addition, security-aware resolvers MUST authenticate the NSEC
RRsets that comprise the non-existence proof as described in Section
5.3.
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
answering any particular query. answering any particular query.
skipping to change at page 36, line 51 skipping to change at page 36, line 51
[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] [I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "KEY RR Secure Entry Point Flag", Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-05 (work in progress), March draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004. 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.
skipping to change at page 47, line 28 skipping to change at page 47, line 28
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
jfFJ5arXf4nPxp/kEowGgBRzY/U= ) jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional ;; Additional
;; (empty) ;; (empty)
B.3 No Data Error B.3 No Data Error
A "NODATA" response. The NSEC RR proves that the name exists and A "no data" response. The NSEC RR proves that the name exists and
that the requested RR type does not. that the requested RR type does not.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
ns1.example. IN MX ns1.example. IN MX
;; Answer ;; Answer
;; (empty) ;; (empty)
skipping to change at page 51, line 42 skipping to change at page 51, line 42
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20040409183619 38519 example. 20040409183619 38519 example.
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
sZM6QjBBLmukH30+w1z3h8PUP2o= ) sZM6QjBBLmukH30+w1z3h8PUP2o= )
B.7 Wildcard No Data Error B.7 Wildcard No Data Error
A "NODATA" response for a name covered by a wildcard. The NSEC RRs A "no data" response for a name covered by a wildcard. The NSEC RRs
prove that the matching wildcard name does not have any RRs of the prove that the matching wildcard name does not have any RRs of the
requested type and that no closer match exists in the zone. requested type and that no closer match exists in the zone.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
a.z.w.example. IN AAAA a.z.w.example. IN AAAA
;; Answer ;; Answer
;; (empty) ;; (empty)
skipping to change at page 52, line 44 skipping to change at page 52, line 44
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
s1InQ2UoIv6tJEaaKkP701j8OLA= ) s1InQ2UoIv6tJEaaKkP701j8OLA= )
;; Additional ;; Additional
;; (empty) ;; (empty)
B.8 DS Child Zone No Data Error B.8 DS Child Zone No Data Error
A "NODATA" response for a QTYPE=DS query which was mistakenly sent to A "no data" response for a QTYPE=DS query which was mistakenly sent
a name server for the child zone. to a name server for the child zone.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
example. IN DS example. IN DS
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
skipping to change at page 55, line 10 skipping to change at page 55, line 10
Once the DS RRset has been authenticated using the root DNSKEY, the Once the DS RRset has been authenticated using the root DNSKEY, the
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY is found, the resolver checks this DNSKEY matching "example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "example" DNSKEY RRset and the signature lifetime RR has signed the "example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the "example" is valid. If all these conditions are met, all keys in the "example"
DNSKEY RRset are considered authenticated. DNSKEY RRset are considered authenticated.
Finally the resolver checks that some DNSKEY RR in the "example" Finally the resolver checks that some DNSKEY RR in the "example"
DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
is used to authenticated the RRSIG included in the response. If DNSKEY is used to authenticated the RRSIG included in the response.
multiple "example" DNSKEY RRs match this algorithm and key tag, then If multiple "example" DNSKEY RRs match this algorithm and key tag,
each DNSKEY RR is tried and the answer is authenticated if any of the then each DNSKEY RR is tried and the answer is authenticated if any
matching DNSKEY RRs validates the signature as described above. of the matching DNSKEY RRs validates the signature as described
above.
C.2 Name Error C.2 Name Error
The query in section Appendix B.2 returned NSEC RRs that prove the The query in section Appendix B.2 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed authenticated in a manner identical to that of the MX RRset discussed
above. above.
C.3 No Data Error C.3 No Data Error
skipping to change at page 56, line 9 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 the produced as a result of wildcard expansion. The RRset expanded as
similar to The corresponding RRSIG indicates the MX RRset was signed the similar to The corresponding RRSIG indicates the MX RRset was
by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
indicates the original TTL of the MX RRset was 3600 and, for the The RRSIG indicates the original TTL of the MX RRset was 3600 and,
purpose of authentication, the current TTL is replaced by 3600. The for the purpose of authentication, the current TTL is replaced by
RRSIG labels field value of 2 indicates the answer the result of 3600. The RRSIG labels field value of 2 indicates the answer the
wildcard expansion since the "a.z.w.example" name contains 4 labels. result of wildcard expansion since the "a.z.w.example" name contains
The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
is placed in canonical form and, assuming the current time falls the MX RRset is placed in canonical form and, assuming the current
between the signature inception and expiration dates, the signature time falls between the signature inception and expiration dates, the
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.
C.7 Wildcard No Data Error C.7 Wildcard No Data Error
The query in section Appendix B.7 returned NSEC RRs that prove the The query in section Appendix B.7 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. reply is authenticated by verifying both NSEC RRs.
skipping to change at page 57, line 8 skipping to change at page 57, line 8
The query in section Appendix B.8 returned NSEC RRs that shows the The query in section Appendix B.8 returned NSEC RRs that shows the
requested was answered by a child server ("example" server). The requested was answered by a child server ("example" server). The
NSEC RR indicates the presence of an SOA RR, showing the answer is NSEC RR indicates the presence of an SOA RR, showing the answer is
from the child . Queries for the "example" DS RRset should be sent from the child . Queries for the "example" DS RRset should be sent
to the parent servers ("root" servers). to the parent servers ("root" servers).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
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 that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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