draft-ietf-dnsext-dnssec-protocol-01.txt   draft-ietf-dnsext-dnssec-protocol-02.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: September 1, 2003 M. Larson Expires: March 30, 2004 M. Larson
VeriSign VeriSign
R. Austein R. Austein
ISC ISC
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
March 3, 2003 September 30, 2003
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-01 draft-ietf-dnsext-dnssec-protocol-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
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 http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 1, 2003. This Internet-Draft will expire on March 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents which describes the This document is part of a family of documents which describes the
DNS Security Extensions (DNSSEC). The DNS Security Extensions are a DNS 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 23 skipping to change at page 2, line 22
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 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6
2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6
2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10 3.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 9
3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11 3.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10
3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11 3.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10
3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not
3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12 Present . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11
3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . . 11
3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 12
3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 12
3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 13
3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 14
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15
4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 21
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 24
5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27 5.1 Special Considerations for Islands of Security . . . . . . . 25
5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 25
5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 26
5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27
5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29
5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.4 Authenticating A Wildcard Expanded RRset Positive
5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 5.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . 35 5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 5.5.2 Examples of Authenticating a Response . . . . . . . . . . . 32
Normative References . . . . . . . . . . . . . . . . . . . . 37 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
Informative References . . . . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40 Normative References . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 39
B. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 46
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) modify several aspects of the The DNS Security Extensions (DNSSEC) are a collection of new resource
DNS protocol. Section 2 defines the concept of a signed zone and records and protocol modifications which add data origin
lists the requirements for zone signing. Section 3 describes the authentication and data integrity to the DNS. This document defines
modifications to authoritative name server behavior necessary to the DNSSEC protocol modifications. Section 2 of this document defines
handle signed zones. Section 4 describes the behavior of entities the concept of a signed zone and lists the requirements for zone
which include security-aware resolver functions Finally, Section 5 signing. Section 3 describes the modifications to authoritative name
defines how to use DNSSEC RRs to authenticate a response. server behavior necessary to handle signed zones. Section 4 describes
the behavior of entities which include security-aware resolver
functions. Finally, Section 5 defines how to use DNSSEC RRs 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 [1] and RFC1035 [2]. described in RFC1034 [RFC1034] and RFC1035 [RFC1035].
This document is part of a family of documents which define the DNS This document is part of a family of documents which define DNSSEC.
security extensions (DNSSEC). The DNS Security Extensions are a An introduction to DNSSEC and definition of common terms can be found
collection of new resource records and protocol modifications which in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
add data origin authentication and data integrity to the DNS. An resource records can be found in [I-D.ietf-dnsext-dnssec-records].
introduction to DNSSEC and definition of common terms can be found in
[9]. A definition of the DNSSEC resource records can be found in
[10]. This document defines the DNSSEC protocol modifications.
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. [4]. document are to be interpreted as described in RFC 2119. [RFC2119].
1.3 Editors' Notes 1.3 Editors' Notes
1.3.1 Open Technical Issues 1.3.1 Open Technical Issues
Use of NXT RRs throughout this document set will have to be modified
if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT
record requires input from the working group. This text describes
the NXT record as it was defined in RFC 2535, and substantial
portions of this document would need to be updated to incorporate
opt-in. The updates will be made if the WG adopts opt-in.
Use of the AD bit requires input from the working group. Since the
AD bit usage is not resolved, this text attempts to capture current
ideas and drafts, but further input from the working group is
required.
1.3.2 Technical Changes or Corrections 1.3.2 Technical Changes or Corrections
Please report technical corrections to dnssec-editors@east.isi.edu. Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical out the RFC that defines the correct behavior. For a technical
change where no RFC that defines the correct behavior, or if there's change where no RFC that defines the correct behavior, or if there's
more than one applicable RFC and the definitions conflict, please more than one applicable RFC and the definitions conflict, please
post the issue to namedroppers. post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was "DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 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 DNSSEC RR types MUST NOT be included in responses unless the resolver
skipping to change at page 6, line 7 skipping to change at page 6, line 7
Please report any typos corrections to dnssec-editors@east.isi.edu. Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to find To assist the editors, please provide enough context for us to find
the incorrect text quickly. the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It DNSSEC standard has been in development for over 1 years". It
should read "over 10 years". should read "over 10 years".
2. Zone Signing 2. Zone Signing
DNSSEC defines the concept of a signed zone. A signed zone includes DNSSEC is built around the concept of signed zones. A signed zone
KEY, SIG, NXT and (optionally) DS records according to the rules includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4, the rules specified in Section 2.1, Section 2.2, Section 2.3 and
respectively. Any zone which does not include these records Section 2.4, respectively. Any zone which does not include these
according to the rules in this section must be considered unsigned. records according to the rules in this section MUST be considered
unsigned for the purposes of the DNS security extensions.
Editors' note: Should this be "MUST be considered unsigned"?
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs
appear at the same owner name as a CNAME RR. to appear at the same owner name as a CNAME RR.
Section 2.6 shows a sample signed zone. Section 2.6 shows a sample signed zone.
2.1 Including KEY RRs in a Zone 2.1 Including DNSKEY RRs in a Zone
Editors' note: Unresolved inconsistency between paragraphs in this
section, regarding non-zone KEY RRs at the zone apex. SHOULD NOT,
or MUST NOT?
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 SIG RRs, there SHOULD be a corresponding KEY RR stored at the create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR
zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the
key KEY RR has the Zone Key bit of the Flags RDATA field set to one. flags RDATA field set to one -- see Section 2.1.1 of
See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other
zone apex. DNS operations MAY be stored in DNSKEY RRs that are not marked as
zone keys.
A signed zone MUST have at least one zone key KEY RR in its apex KEY
RRset. The KEY RRset at the zone apex MUST be self-signed by at
least one private key whose corresponding public key is a zone key
stored in the apex KEY RRset.
Editors' note: The requirement listed in this paragraph may not be
necessary anymore, since the KEY RRset is self-signed anyway
(because the whole zone is signed). This is probably a pre-DS
relic, but we spotted this a few hours before the I-D deadline and
were too chicken to remove it on such short notice....
Other public keys associated with other DNS operations can be stored If the zone is delegated and does not wish to act as an island of
in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs security, the zone MUST have at least one DNSKEY RR at the apex to
MUST NOT appear at delegation names. Non-zone key KEY RRs also act as a secure entry point into the zone. This DNSKEY would then be
SHOULD NOT appear at the zone apex, because large KEY RRsets add used to generate a DS RR at the delegating parent (see
processing time at resolvers. Non-zone key KEY RRs MAY appear at any [I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a
other name in the zone. zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
for definition). The DNSKEY RRset at the zone apex MUST be signed by
at least one zone signing or DNSKEY signing private key.
2.2 Including SIG RRs in a Zone DNSKEY RRs MUST NOT appear at delegation points.
For each authoritative RRset in the zone (which excludes NS RRsets at 2.2 Including RRSIG RRs in a Zone
delegation points and glue RRsets), there MUST be at least one SIG
record that meets all of the following requirements:
o The SIG owner name is equal to the RRset owner name; For each authoritative RRset in a signed zone (which excludes both NS
RRsets at delegation points and glue RRsets), there MUST be at least
one RRSIG record that meets all of the following requirements:
o The SIG class is equal to the RRset class; o The RRSIG owner name is equal to the RRset owner name;
o The SIG Type Covered field is equal to the RRset type; o The RRSIG class is equal to the RRset class;
o The RRSIG Type Covered field is equal to the RRset type;
o The SIG 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 SIG 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 SIG Labels field is equal to the number of labels in the RRset o The RRSIG Labels field is equal to the number of labels in the
owner name, not counting the null root label or any wildcard RRset owner name, not counting the null root label and not
label; counting the wildcard label if the owner name is a wildcard;
o The SIG 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 SIG 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 KEY record at the zone apex. zone key DNSKEY record at the zone apex.
The process for constructing the SIG RR for a given RRset is The process for constructing the RRSIG RR for a given RRset is
described in [10]. An RRset MAY have multiple SIG RRs associated described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
with it. multiple RRSIG RRs associated with it.
A SIG RR itself MUST NOT be signed, since signing a SIG RRset would An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
add no value and would create an unterminated dependency loop in the would add no value and would create an infinite loop in the signing
signing process. process.
The NS RRset which appears at the zone apex name MUST be signed, but The NS RRset which appears at the zone apex name MUST be signed, but
the NS RRsets which appear at delegation points (that is, the NS the NS RRsets which appear at delegation points (that is, the NS
RRsets in the parent zone which delegate the name to the child zone's RRsets in the parent zone which 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
with delegations MUST NOT be signed. delegations MUST NOT be signed.
The difference between the set of owner names which require SIG The difference between the set of owner names which require RRSIG
records and the set of owner names which require NXT records is records and the set of owner names which require NSEC records is
subtle and worth highlighting. SIG records are present at the owner subtle and worth highlighting. RRSIG records are present at the
names of all authoritative RRsets. NXT records are present at the owner names of all authoritative RRsets. NSEC records are present at
owner names of all names for which the signed zone is authoritative the owner names of all names for which the signed zone is
and also at the owner names of delegations from the signed zone to authoritative and also at the owner names of delegations from the
its children. Neither NXT nor SIG records are present (in the parent signed zone to its children. Neither NSEC nor RRSIG records are
zone) at the owner names of glue address RRsets. Note, however, that present (in the parent zone) at the owner names of glue address
this distinction is for the most part only visible during the zone RRsets. Note, however, that this distinction is for the most part
signing process, because NXT RRsets are authoritative data, and only visible during the zone signing process, because NSEC RRsets are
therefore are signed, thus any owner name which has an NXT RRset will authoritative data, and are therefore signed, thus any owner name
have SIG RRs as well in the signed zone. which has an NSEC RRset will have RRSIG RRs as well in the signed
zone.
2.3 Including NXT RRs in a Zone 2.3 Including NSEC RRs in a Zone
Each owner name in the zone MUST have an NXT resource record, except Each owner name in the zone MUST have an NSEC resource record, except
for the owner names of any glue address RRsets. The process for for the owner names of any glue address RRsets. The process for
constructing the NXT RR for a given name is described in [10]. constructing the NSEC RR for a given name is described in
[I-D.ietf-dnsext-dnssec-records].
The type bitmap of every NSEC resource record in a signed zone MUST
indicate the presence of both the NSEC record itself and its
corresponding RRSIG record.
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 key used by the child zone to sign its apex KEY each referencing a key used by the child zone to sign its apex DNSKEY
RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
appear at non-delegation points nor at a zone's apex. appear at non-delegation points nor at a zone's apex.
A DS RR SHOULD point to a KEY RR which is present in the child's apex A DS RR SHOULD point to a DNSKEY RR which is present in the child's
KEY RRset, and the child's apex KEY RRset SHOULD be signed by the apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
corresponding private key. by the corresponding private key.
Construction of a DS RR requires knowledge of the corresponding KEY Construction of a DS RR requires knowledge of the corresponding
RR in the child zone, which implies communication between the child DNSKEY RR in the child zone, which implies communication between the
and parent zones. This communication is an operational matter not child and parent zones. This communication is an operational matter
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
SIG and NXT RRsets are REQUIRED at that name. Other types MUST NOT RRSIG and NSEC RRsets are REQUIRED at that name. Other types MUST NOT
be present at that name. be present at that name.
This is a modification to the original CNAME definition given in [1]. This is a modification to the original CNAME definition given in
The original definition of the CNAME RR did not allow any other types [RFC1034]. The original definition of the CNAME RR did not allow any
to co-exist with a CNAME record, but a signed zone requires NXT and other types to co-exist with a CNAME record, but a signed zone
SIG RRsets for every authoritative name. To resolve this conflict, requires NSEC and RRSIG RRs for every authoritative name. To resolve
the definition of the CNAME resource record is hereby modified to this conflict, this specification modifies the definition of the
allow for the co-existence of NXT and SIG RRsets. CNAME resource record to allow it to co-exist with NSEC and RRSIG
RRs.
2.6 Example of a Secure Zone 2.6 Example of a Secure Zone
{{secure zone here}} Appendix B shows a complete example of a small signed zone.
Editors' note: Zone file example deferred pending hackery to add
zone files in a format usable by xml2rfc. Goal here is to show a
(small) complete signed zone.
The apex KEY set includes two KEY RRs, and the KEY RDATA Flags
indicate that each of these KEY RRs is a zone key. The first zone
KEY is used to sign the apex KEY RRset, and a DS record for this key
is provided to the parent zone. The second zone KEY is used to sign
all the other RRsets in the zone. A non-zone KEY RR is also stored
at "host1.example.com"; this KEY might be used by SIG(0) to
authenticate transactions from this host.
The zone includes a wildcard entry "*.a.example.com". Note that the
"*.a.example.com" name is used in constructing NXT chains, and that
the SIG covering the "*.a.example.com" MX RRset has a label count of
3.
The zone also includes two delegations. The delegation to
"insecure.example.com" includes an NS RRset, glue address records,
and an NXT RR, but note that only the NXT RRset is signed. The
"secure.example.com" delegation provides a DS RR, and note that only
NXT and DS RRsets are signed.
3. Serving 3. Serving
This section describes the behavior of a security-aware authoritative This section describes the behavior of a security-aware authoritative
name server. A security-aware authoritative name server MUST support name server. A security-aware authoritative name server MUST support
the EDNS0 [6] message size extension, MUST support a message size of the EDNS0 [RFC2671] message size extension, MUST support a message
at least 1220 octets, and SHOULD support a message size of 4000 size of at least 1220 octets, and SHOULD support a message size of
octets [8]. Since functions specific to security-aware recursive 4000 octets [RFC3226]. Since functions specific to security-aware
name servers included components of both resolving and serving, recursive name servers included components of both resolving and
issues specific to security-aware recursive name servers are serving, issues specific to security-aware recursive name servers are
described in Section 4. described in Section 4.
Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR Upon receiving a relevant query which has the EDNS [RFC2671] OPT
DO [7] bit set to one, a security-aware authoritative name server for pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
a signed zone MUST include additional SIG, NXT, and DS RRs according name server for a signed zone MUST include additional RRSIG, NSEC,
to the following rules: and DS RRs according to the following rules:
o SIG RRs which can be used to authenticate a response MUST be o RRSIG RRs which can be used to authenticate a response MUST be
included in the response automatically according to the rules in included in the response according to the rules in Section 3.1;
Section 3.1;
o NXT RRs which can be used to provide authenticated denial of o NSEC RRs which 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.3; to the rules in Section 3.3;
o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be o Either DS RRs or an NSEC RR proving that no DS RRs exist MUST be
included in referrals automatically according to the rules in included in referrals automatically according to the rules in
Section 3.4. Section 3.4.
DNSSEC does not change the DNS zone transfer protocol. Zone transfer DNSSEC does not change the DNS zone transfer protocol. Zone transfer
requirements are reviewed in Section 3.6. requirements are reviewed in Section 3.6.
A security-aware name server which receives a DNS query which does A security-aware name server which receives a DNS query which does
not include the EDNS OPT pseudo-RR, or which has the DO bit set to not include the EDNS OPT pseudo-RR or which has the DO bit set to
zero, MUST treat the SIG, KEY, and NXT RRs as it would any other zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
RRset, and MUST NOT perform any of the additional processing RRset, and MUST NOT perform any of the additional processing
described above. Since the DS RR type has the peculiar property of described above. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always only existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.5. require some special processing, as described in Section 3.5.
3.1 Including SIG RRs in a Response 3.1 Including RRSIG RRs in a Response
When a query has the DO bit set to one, the authoritative name server When a query has the DO bit set to one, the authoritative name server
SHOULD attempt to send SIG RRs which can be used to authenticate the SHOULD attempt to send RRSIG RRs which can be used to authenticate
RRsets in the response. Inclusion of SIG RRs in a response is the RRsets in the response. Inclusion of RRSIG RRs in a response is
subject to the following rules: subject to the following rules:
o When a signed RRset is placed in the Answer section, its SIG RRs o When placing a signed RRset in the Answer section, the name server
are also placed in the Answer section. The SIG RRs have a higher MUST also place its RRSIG RRs in the Answer section. The RRSIG
priority for inclusion than any other RRsets which may need to be RRs have a higher priority for inclusion than any other RRsets
included. If space does not permit the inclusion of these SIG which may need to be included. If space does not permit inclusion
RRs, the response MUST be considered truncated, and the TC bit of these RRSIG RRs, the name server MUST set the TC bit.
MUST be set.
o When a signed RRset is placed in the Authority section, its SIG o When placing a signed RRset in the Authority section, the name
RRs are also placed in the Authority section. The SIG RRs have a server MUST also place its RRSIG RRs in the Authority section.
higher priority for inclusion than any other RRsets that may need The RRSIG RRs have a higher priority for inclusion than any other
to be included. If space does not permit the inclusion of these RRsets that may need to be included. If space does not permit
SIG RRs, the response MUST be considered truncated, and the TC bit inclusion of these RRSIG RRs, the name server MUST set the TC bit.
MUST be set.
o When a signed RRset is placed in the Additional section, its SIG o When placing a signed RRset in the Additional section, the name
RRs are also placed in the Additional section. If space does not server MUST also place its RRSIG RRs in the Additional section.
permit the inclusion of these SIG RRs, the response MUST NOT be If space does not permit inclusion of these RRSIG RRs, the name
considered truncated just because these SIG RRs didn't fit. server MUST NOT set the TC bit solely because these RRSIG RRs
didn't fit.
3.2 Including KEY RRs In a Response 3.2 Including DNSKEY RRs In a Response
When a query has the DO bit set to one and requests the SOA or NS RRs When a query has the DO bit set to one and requests the SOA or NS RRs
at the apex of a signed zone, then a security-aware authoritative at the apex of a signed zone, a security-aware authoritative name
name server for that zone SHOULD return the KEY RRset with the same server for that zone MAY return the DNSKEY RRset with the same name
name in the Additional section. If Additional section processing in the Additional section. In this situation, the DNSKEY RR set and
results in more data than will fit in the response message, address associated RRSIG RRs have lower priority than any other information
glue RRs have higher priority than KEY RRs. SIG RR(s) associated that would be placed in the additional section. The name server
with the KEY RRset SHOULD also be included in the Additional section should include the DNSKEY RRset if and only if there is enough space
(see Section 3.1). in the response for both the DNSKEY RRset and associated RRSIG RR(s).
If there is not enough space to include these DNSKEY and RRSIG RRs,
Editors' note: Didn't the WG decide that DS RR removes the need the name server MUST omit them and MUST NOT set the TC bit solely
for Additional section processing for KEY RRs? If so, this because these RRs didn't fit.
subsection should be deleted.
3.3 Including NXT RRs In a Response
Editors' note: This whole section uses the phrase "query name 3.3 Including NSEC RRs In a Response
exists", which is somewhat ambiguous when discussing internal
nodes with no RRs. We are reasonably certain that, as used here,
the phrase only refers to names which are the owner name for least
one RR. Better phrasing needed.
When a query has the DO bit set to one, security-aware authoritative When a query has the DO bit set to one, security-aware authoritative
name servers for a signed zone MUST include NXT RRs in each of the name servers for a signed zone MUST include NSEC RRs in each of the
following cases: following cases:
Case 1: The query name exists, but the requested RR type does not Case 1: The QNAME has RRsets associated with it in the zone, but the
exist. requested RR type does not exist.
Case 2: The query name does not exist, and no wildcard can be Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and no
expanded to answer the query. wildcard can be expanded to answer the query.
Case 3: The query name does not exist, but a wildcard can be expanded Case 3: The QNAME (or search name) does not exist, but a wildcard can
to positively answer the query. be expanded to positively answer the query.
Note that, in each case, a set of NXT RRs is included to provide Note that, in each case, a set of NSEC RRs is included to provide
authenticated denial of existence. authenticated denial of existence.
NXT RRs are also included in a referral response when no DS RR is 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present
present; in this case, the NXT RR proves that no DS RR exists for the
delegation. Referrals are discussed in more detail in Section 3.4.
3.3.1 Case 1: Query Name Exists, but RR Type Not Present
If the query name exists but the requested RR type is not present at If there are RR types associated with a given QNAME, but the
the name, then the NXT RR associated with the query name MUST be requested RR type is not present at the name, then the name server
included in the Authority section. Any SIG(s) associated with the MUST include the NSEC RR associated with the query name and any RRSIG
NXT RRset are also included in the Authority section (see Section RRs associated with the NSEC RR in the Authority section (see Section
3.1) If space does not permit the inclusion of the NXT RR (or its 3.1). If space does not permit inclusion of the NSEC RR or its
associate SIG RRs), the response MUST be considered truncated and the associated RRSIG RRs, the name server MUST set the TC bit.
TC bit MUST be set.
Note that, since the query name exists, no wildcard expansion applies Note that, since the query name exists, no wildcard expansion applies
to this query, and a single NXT RR suffices to prove the requested to this query, and a single NSEC RR suffices to prove the requested
type does not exist. RR type does not exist.
3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches
If the query name does not exist, and no wildcard expansion matches 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches
the query, then the Authority section of the response MUST include
the following NXT RRs:
o An NXT RR proving that there was no exact match for the name; and If the query name does not exist in the zone, and no wildcard
expansion matches both the query name and the query type, the name
server MUST include the following NSEC RRs in the Authority section,
along with their associated RRSIG RRs:
o An NXT RR proving that there was no wildcard which would have o An NSEC RR proving that there was no exact match for the name; and
matched the query.
If space does not permit the inclusion of these NXT RRs, the response o An NSEC RR combination proving that there was no wildcard which
MUST be considered truncated, and the TC bit MUST be set. Any SIG(s) would have matched the query. See [I-D.ietf-dnsext-wcard-clarify]
associated with the NXT RRsets MUST also be included in the Authority for further information on NSEC coverage.
section (see Section 3.1).
Editors' note: Should lack of space to include the SIGs cause the If space does not permit inclusion of these NSEC and RRSIG RRs, the
packet to be considered truncated? name server MUST set the TC bit (see Section 3.1).
Appendix A provides an algorithm which computes the appropriate NXT Appendix A provides an algorithm which computes the appropriate NSEC
RRs to prove that no wildcard matches a given query name. RRs to prove that no wildcard matches a given query name.
3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches
If the query name does not exist, but a wildcard expansion can be If the query name does not exist, but a wildcard expansion can be
used to return a positive match to the query, then the wildcard- used to return a positive match to the query, the name server MUST
expanded answer and any SIG RRs associated with the wildcard RR MUST include the wildcard-expanded answer and the corresponding
be returned in the Answer section. The Authority section of the wildcard-expanded RRSIG RRs in the Answer section. The Authority
response MUST include the following NXT RRs: section of the response MUST include the following NSEC RRs along
with their corresponding RRSIG RRs:
o An NXT RR which proves that there were no exact matches for the o An NSEC RR which proves that there were no exact matches for the
QNAME and QTYPE; and QNAME and QTYPE; and
o An NXT RR which proves that there are no closer wildcard entries o An NSEC RR combination which proves that there are no closer
which could have been expanded to match the query. wildcard entries which could have been expanded to match the
query. See [I-D.ietf-dnsext-wcard-clarify] for further
If space does not permit inclusion of these NXT RRs, the response information on NSEC coverage.
MUST be considered truncated, and the TC bit MUST be set. Any SIG
RRs associated with the NXT RRsets MUST also be included in the
response.
Editors' note: Should lack of space to include the SIGs cause the If space does not permit inclusion of these NSEC and RRSIG RRs, the
packet to be considered truncated? name server MUST set the TC bit (see Section 3.1).
Appendix A provides an algorithm which computes the appropriate NXT Appendix A provides an algorithm which computes the appropriate NSEC
RRs to prove that no closer wildcard matches the query name. RRs to prove that no closer wildcard matches the query name.
3.4 Including DS RRs In a Response 3.4 Including DS RRs In a Response
When a query has the DO bit set to one, and a DS RR exists at the When a query has the DO bit set to one, and a DS RR exists at the
query name, an authoritative security-aware name server returning a query name, an authoritative security-aware name server returning a
referral for the delegation MUST include both the NS RRset and also referral for the delegation MUST include both the NS RRset and also
the DS RRset and its associated SIG RR(s). The NS RRset MUST be the DS RRset and its associated RRSIG RR(s). The name server MUST
placed before the DS RRset and its associated SIG RRs. place the NS RRset before the DS RRset and its associated RRSIG RRs.
When a query has the DO bit set to one, and no DS RR exists at the When a query has the DO bit set to one, and no DS RR exists at the
query name, an authoritative security-aware name server returning a query name, an authoritative security-aware name server returning a
referral for the delegation MUST include both the NS RRset and also referral for the delegation MUST include both the NS RRset and also
the NXT RR and associated SIG RR(s) which proves that the DS RRset the NSEC RR and associated RRSIG RR(s) which proves that the DS RRset
does not exist. The NS RRset MUST be placed before the NXT RRset and does not exist. The name server MUST place the NS RRset before the
its associated SIG RR(s). NSEC RRset and its associated RRSIG RR(s).
This increases the size of referral messages, and may cause some or Including these DS and RRSIG RRs increases the size of referral
all glue RRs to be omitted. If space does not permit the inclusion messages, and may cause some or all glue RRs to be omitted. If space
of the DS or NXT RRset and associated SIG RRs, the response MUST be does not permit inclusion of the DS or NSEC RRset and associated
considered truncated, and the TC bit MUST be set. RRSIG RRs, the name server MUST set the TC bit.
Security-aware name servers also include NSEC RRs in a referral
response when no DS RR is present; in this case, the NSEC RR proves
that no DS RR exists for the delegation. Section 3.4 discusses
referrals in more detail.
3.5 Responding to Queries for DS RRs 3.5 Responding to Queries for DS RRs
The DS record is the first resource record type which appears only on The DS resource record type is unusual in that it appears only on the
the parent zone's side of a zone cut. In other words, the DS record parent zone's side of a zone cut. In other words, the DS record for
for the delegation of "example.com" is only stored in the "com" zone. the delegation of "example.com" is only stored in the "com" zone.
This introduces novel name server behavior, since the name server for This introduces novel name server behavior, since the name server for
the child zone is authoritative for the name by the normal DNS rules the child zone is authoritative for the name by the normal DNS rules
but the child zone does not contain the DS RR. A name server's but the child zone does not contain the DS RR. An authoritative name
response to a DS query depends on whether the name server is server's response to a DS query depends on whether the name server is
authoritative for the parent zone, the child zone, or both, as authoritative for the parent zone, the child zone, or both, as
described below. described below.
If a name server is authoritative for the parent zone, and receives a If a name server is authoritative for the parent zone, and receives a
query for the DS record at the delegated name, then the name server query for the DS record at the delegated name, then the name server
MUST return the DS RRset from the parent zone. This rule applies MUST return the DS RRset from the parent zone. This rule applies
regardless of whether or not the name server is also authoritative regardless of whether or not the name server is also authoritative
for the child zone. for the child zone.
If the name server is authoritative for the child zone, is not If the name server is authoritative for the child zone, is not
skipping to change at page 14, line 38 skipping to change at page 13, line 24
for the delegated name from the parent zone, and MAY return the DS for the delegated name from the parent zone, and MAY return the DS
record from its cache. In this case, the AA bit MUST NOT be set in record from its cache. In this case, the AA bit MUST NOT be set in
the response. the response.
If the name server does not perform recursion to find the DS RR, the If the name server does not perform recursion to find the DS RR, the
name server MUST reply with: name server MUST reply with:
RCODE: NOERROR RCODE: NOERROR
AA bit: set AA bit: set
Answer Section: Empty Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]
In other words, a name server which is authoritative for the child In other words, a name server which is authoritative for the child
zone but not for the parent zone answers as if the DS record does not zone but not for the parent zone answers as if the DS record does not
exist. Note that security-aware resolvers will query the parent zone exist. Note that security-aware resolvers will query the parent zone
at delegation points, and thus will not be affected by this behavior. at delegation points, and thus will not be affected by this behavior.
For example, suppose that "example.com" is a delegation point, and a For example, suppose that "example.com" is a delegation point, and a
name server receives a query for the "example.com" DS RRset. name server receives a query for the "example.com" DS RRset.
o If the name server is authoritative for "com", the name server o If the name server is authoritative for "com", the name server
skipping to change at page 15, line 13 skipping to change at page 13, line 47
o If the name server is authoritative for "example.com", is not o If the name server is authoritative for "example.com", is not
authoritative for "com", and the RD bit is set to one in the authoritative for "com", and the RD bit is set to one in the
query, the name server MAY perform recursion to find the query, the name server MAY perform recursion to find the
"example.com" DS record. If the name server does not use "example.com" DS record. If the name server does not use
recursion to obtain the DS RR, the name server MUST reply as recursion to obtain the DS RR, the name server MUST reply as
though the DS RR did not exist: though the DS RR did not exist:
RCODE: NOERROR RCODE: NOERROR
AA bit: set AA bit: set
Answer Section: Empty Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]
3.6 Responding to Queries for Type AXFR or IXFR 3.6 Responding to Queries for Type AXFR or IXFR
DNSSEC does not change the DNS zone transfer process. A signed zone DNSSEC does not change the DNS zone transfer process. A signed zone
will contain SIG, KEY, NXT, and DS resource records, but these will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
records have no special meaning with respect to a zone transfer records have no special meaning with respect to a zone transfer
operation, and these RRs are treated as any other resource record operation, and these RRs are treated as any other resource record
type. type.
An authoritative name server is not required to verify that a zone is An authoritative name server is not required to verify that a zone is
properly signed before sending or accepting a zone transfer. properly signed before sending or accepting a zone transfer.
However, an authoritative name server MAY choose to reject the entire However, an authoritative name server MAY choose to reject the entire
zone transfer if the zone fails meets any of the signing requirements zone transfer if the zone fails meets any of the signing requirements
described in Section Section 2. The primary objective of a zone described in Section 2. The primary objective of a zone transfer is
transfer to ensure that all authoritative name servers have identical to ensure that all authoritative name servers have identical copies
copies of the zone. An authoritative name server which chooses to of the zone. An authoritative name server which chooses to perform
perform its own zone validation MUST NOT selectively reject some RRs its own zone validation MUST NOT selectively reject some RRs and
and accept others. accept others.
Note that the DS RR appears only in the parental side of a Note that the DS RR appears only in the parental side of a delegation
delegation, and is authoritative data in the parent zone. For and is authoritative data in the parent zone. For example, the DS RR
example, the DS RR for "example.com" is stored in the "com" zone (the for "example.com" is stored in the "com" zone (the parent zone)
parent zone) rather than in the "example.com" zone (the child zone). rather than in the "example.com" zone (the child zone). As with any
As with any other authoritative RRset, the "example.com" DS RR MUST other authoritative RRset, the "example.com" DS RR MUST be included
be included the "com" zone transfer. the "com" zone transfer.
Note that authoritative NXT RRs appear in both the parent and child Note that authoritative NSEC RRs appear in both the parent and child
zones at a delegated name, and that the NXT RRs for the delegated zones at a delegated name, and that the NSEC RRs for the delegated
name in the parent and child zones are never identical to each other. name in the parent and child zones are never identical to each other.
As with any other authoritative RRset, the parental NXT RR at a As with any other authoritative RRset, the parental NSEC RR at a
delegated name MUST be included zone transfers of the parent zone, delegated name MUST be included zone transfers of the parent zone,
while the NXT at the zone apex of the child zone MUST be included in while the NSEC at the zone apex of the child zone MUST be included in
zone transfers of the child zone. zone transfers of the child zone.
3.7 Setting the AD and CD Bits in a Response 3.7 Setting the AD and CD Bits in a Response
Editors' note: This section seems a little lost here. Perhaps we Editors' note: This section seems a little lost here. Perhaps we
should rearrange the section ordering slightly, or provide a should rearrange the section ordering slightly, or provide a
pointer to this subsection at the beginning of Section 3. pointer to this subsection at the beginning of Section 3.
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. (Checking Disabled) bit and the AD (Authentic Data) bit.
The CD bit is set in query messages by the resolver, and MUST be The CD bit is set in query messages by the resolver, and MUST be
copied into the response. If the CD bit is set to one, it indicates copied into the response by the name server. If the CD bit is set to
that the resolver is willing to perform authentication, and thus that one, it indicates that the resolver is willing to perform whatever
the name server need not perform authentication on the RRsets in the authentication its local policy requires, and thus that the name
response. server need not perform authentication on the RRsets in the response.
Regardless of the setting of the CD bit, the name server MAY choose Regardless of the setting of the CD bit, the name server MAY choose
whether or not to perform authentication according to the local name whether or not to perform authentication according to its own local
server policy. The CD bit MAY be used in constructing the local name name server policy, and the name server MAY use the CD bit as input
server policy. If local name server policy does perform to its own local policy. However, if the resolver has set the CD
authentication, any RRsets rejected by the local authentication bit, a name server SHOULD, if possible, return the requested data to
policy MUST NOT be returned in a response (regardless of the CD bit). the resolver even if the name server's local authentication policy
would reject the records in question. That is, by setting the CD
bit, the resolver has taken responsibility for performing its own
authentication, and the name server should not interfere in this
case.
The AD bit is set by name servers, and indicates the data in the The AD bit is set by name servers, and indicates the data in the
response has been authenticated by the name server, according to the response has been authenticated by the name server, according to the
local name server policy. The AD bit MUST NOT be set on a response local name server policy. The AD bit MUST NOT be set on a response
unless all of the RRsets in the Answer and Authority sections have unless all of the RRsets in the Answer and Authority sections have
met the name server's local authentication policy. A resolver MUST met the name server's local authentication policy. A resolver MUST
NOT trust the AD bit unless it communicates with the name server over NOT trust the AD bit unless it communicates with the name server over
a secure transport mechanism and is explicitly configured to trust a secure transport mechanism and is explicitly configured to trust
the name server's policy. the name server's policy.
3.8 Example DNSSEC Responses 3.8 Example DNSSEC Responses
Editors' note: these examples probably ought to move to an
appendix and probably ought to use the "real" signed example zone
that's already in an appendix.
The examples in this section use the following example zone to The examples in this section use the following example zone to
demonstrate the formation of replies by an authoritative name server. demonstrate the formation of replies by an authoritative name server.
The zone has two name servers, a single child, and a wildcard MX RR. The zone has two name servers, a single child, and a wildcard MX RR.
The zone is completely signed and has a full NXT chain. The zone is completely signed and has a full NSEC chain.
example.com. SOA (...) example.com. SOA (...)
SIG SOA ... RRSIG SOA ...
NS a.example.com. NS a.example.com.
NS b.example.com. NS b.example.com.
SIG NS ... RRSIG NS ...
MX 10 a.example.com MX 10 a.example.com
SIG MX ... RRSIG MX ...
KEY ... DNSKEY ...
SIG KEY ... RRSIG DNSKEY ...
NXT *.example.com. NSEC *.example.com.
* MX 10 a.example.com. * MX 10 a.example.com.
SIG MX ... RRSIG MX ...
NXT a.example.com. NSEC a.example.com.
a A 10.10.10.1 a A 10.10.10.1
SIG A ... RRSIG A ...
NXT b.example.com. NSEC b.example.com.
b A 10.10.10.2 b A 10.10.10.2
SIG A ... RRSIG A ...
NXT c.example.com. NSEC c.example.com.
c CNAME a.example.com. c CNAME a.example.com.
SIG CNAME
NXT sub.example.com. RRSIG CNAME
NSEC sub.example.com.
sub NS ns.sub.example.com. sub NS ns.sub.example.com.
SIG NS RRSIG NS
DS ... DS ...
SIG DS RRSIG DS
NXT *.example.com. NSEC *.example.com.
ns.sub A 10.10.10.3 ns.sub A 10.10.10.3
sub-nosig NS ns.sub-nosig.example.com. sub-nosig NS ns.sub-nosig.example.com.
NXT example.com. NSEC example.com.
ns.sub-nosig A 10.10.10.4 ns.sub-nosig A 10.10.10.4
A query to the authoritative name server for this zone for A query to the authoritative name server for this zone for
QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:
Flags: QR=1, AA=1, RCODE=0 (NOERROR) Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000 EDNS: DO=1, size=4000
QUERY: QUERY:
c.example.com. IN A c.example.com. IN A
ANSWER: ANSWER:
c.example.com. IN A a.example.com c.example.com. IN A a.example.com
IN SIG CNAME IN RRSIG CNAME
a.example.com. IN A 10.10.10.1 a.example.com. IN A 10.10.10.1
IN SIG A IN RRSIG A
AUTHORITY: AUTHORITY:
example.com. IN NS a.example.com. example.com. IN NS a.example.com.
IN NS b.example.com. IN NS b.example.com.
IN SIG NS ... IN RRSIG NS ...
ADDITIONAL: ADDITIONAL:
a.example.com. IN A 10.10.10.1 a.example.com. IN A 10.10.10.1
IN SIG A ... IN RRSIG A ...
b.example.com. IN A 10.10.10.2 b.example.com. IN A 10.10.10.2
IN SIG A ... IN RRSIG A ...
example.com. IN KEY ...
IN SIG KEY ...
A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
results in a referral to a signed zone. The resolver can determine results in a referral to a signed zone. The resolver can determine
that "sub.example.com" is signed because of the presence of the DS RR that "sub.example.com" is signed because of the presence of the DS RR
with the hash of the "sub.example.com" zone key. with the hash of the "sub.example.com" zone key.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000 EDNS: DO=1, size=4000
QUERY: QUERY:
www.sub.example.com. IN A www.sub.example.com. IN A
ANSWER: ANSWER:
;; empty ;; empty
AUTHORITY: AUTHORITY:
sub.example.com. IN NS ns.sub.example.com. sub.example.com. IN NS ns.sub.example.com.
IN DS ... IN DS ...
IN SIG DS ...
IN RRSIG DS ...
ADDITIONAL: ADDITIONAL:
ns.sub.example.com. IN A 10.10.10.3 ns.sub.example.com. IN A 10.10.10.3
A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
would result in a referral to an unsigned zone. The resolver knows would result in a referral to an unsigned zone. The resolver knows
not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
bit in the NXT RR bitmap in the referral is not set. Even if DNSSEC bit in the NSEC RR bitmap in the referral is not set. Even if DNSSEC
RRs are present in responses from "sub-nosig.example.com" name RRs are present in responses from "sub-nosig.example.com" name
servers, the resolver will not be able to construct a authentication servers, the resolver will not be able to construct a authentication
chain, since there is a break between "sub-nosig.example.com" and its chain, since there is a break between "sub-nosig.example.com" and its
delegating parent zone. delegating parent zone.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000 EDNS: DO=1, size=4000
QUERY: QUERY:
www.sub-nosig.example.com. IN A www.sub-nosig.example.com. IN A
ANSWER: ANSWER:
;; empty ;; empty
AUTHORITY: AUTHORITY:
sub-nosig.example.com. IN NS ns.sub-nosig.example.com. sub-nosig.example.com. IN NS ns.sub-nosig.example.com.
IN NXT ;; (DS bit not set) IN NSEC ;; (DS bit not set)
IN SIG NXT ... IN RRSIG NSEC ...
ADDITIONAL: ADDITIONAL:
ns.sub-nosig.example.com. IN A 10.10.10.4 ns.sub-nosig.example.com. IN A 10.10.10.4
A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name
error, because the name does not exist and is not covered by wildcard error, because the name does not exist and is not covered by wildcard
expansion. Therefore, the name server must present proof that the expansion. Therefore, the name server must present proof that the
name does not exist, and that no wildcard expansion is present which name does not exist, and that no wildcard expansion is present which
could have been used to answer the query. could have been used to answer the query.
Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN)
EDNS: DO=1, size=4000 EDNS: DO=1, size=4000
QUERY: QUERY:
f.example.com. IN A f.example.com. IN A
ANSWER: ANSWER:
;; empty ;; empty
AUTHORITY: AUTHORITY:
example.com. IN SOA ... example.com. IN SOA ...
IN SIG SOA ... IN RRSIG SOA ...
c.example.com. IN NXT sub.example.com. ... c.example.com. IN NSEC sub.example.com. ...
IN SIG NXT ... IN RRSIG NSEC ...
*.example.com. IN NXT a.example.com. ... *.example.com. IN NSEC a.example.com. ...
IN SIG NXT ... IN RRSIG NSEC ...
ADDITIONAL: ADDITIONAL:
example.com. IN KEY ... example.com. IN DNSKEY ...
IN SIG KEY ... IN RRSIG DNSKEY ...
A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
RR synthesized via wildcard expansion. The name server must prove RR synthesized via wildcard expansion. The name server must prove
that no exact match exists. that no exact match exists.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000 EDNS: DO=1, size=4000
QUERY: QUERY:
f.example.com. IN MX f.example.com. IN MX
ANSWER: ANSWER:
f.example.com. IN MX 10 a.example.com. f.example.com. IN MX 10 a.example.com.
IN SIG MX ... IN RRSIG MX ...
AUTHORITY: AUTHORITY:
example.com. IN NS a.example.com. example.com. IN NS a.example.com.
IN NS b.example.com. IN NS b.example.com.
IN SIG NS ... IN RRSIG NS ...
c.example.com. IN NXT sub.example.com. c.example.com. IN NSEC sub.example.com.
IN SIG NXT ... IN RRSIG NSEC ...
ADDITIONAL: ADDITIONAL:
a.example.com. IN A 10.10.10.1 a.example.com. IN A 10.10.10.1
IN SIG A ... IN RRSIG A ...
b.example.com. IN A 10.10.10.2 b.example.com. IN A 10.10.10.2
IN SIG A ... IN RRSIG A ...
example.com. IN KEY ...
IN SIG KEY ...
If these responses came from a recursive name server which had all of If these responses came from a recursive name server which had all of
the necessary RRsets in its cache instead of from an authoritative the necessary RRsets in its cache instead of from an authoritative
server, the only differences would be the TTLs and the header flags. server, the only differences would be the TTLs and the header flags.
The AA bit would not be set, and the AD bit would be set if (and only The AA bit would not be set, and the AD bit would be set if (and only
if) all the RRsets in a response passed the security policy checks of if) all the RRsets in a response passed the security policy checks of
the recursive name server. the recursive name server.
4. Resolving 4. Resolving
Editors' note: This section is still very rough, and some of the
text here duplicates text from other portions of this document.
This needs to be fixed (one way or another) during final editing.
Suggestions for better text would be welcome.
This section describes the behavior of entities which include This section describes the behavior of entities which 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 a specific to security-aware recursive name servers are described in a
separate subsection. separate subsection.
A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with A security-aware resolver MUST include an EDNS [RFC2671] OPT
the DO [7] bit set to one when sending queries. pseudo-RR with the DO [RFC3225] bit set to one 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 MUST
MUST handle fragmented UDP packets correctly regardless of whether handle fragmented UDP packets correctly regardless of whether any
any such fragmented packets were received via IPv4 or IPv6. Please such fragmented packets were received via IPv4 or IPv6. Please see
see [8] for discussion of these requirements. [RFC3226] for discussion of these requirements.
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 MUST 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.
A security-aware resolver MUST attempt to retrieve missing DS, KEY, A security-aware resolver MUST attempt to retrieve missing DS,
or SIG RRs via explicit queries if the resolver needs these RRs in DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
order to perform signature verification. RRs in order to perform signature verification.
A security-aware resolver MUST attempt to retrieve missing a NXT RR A security-aware resolver MUST attempt to retrieve missing a NSEC RR
which the resolver needs to authenticate a NODATA response. In which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NXT general it is not possible for a resolver to retrieve missing NSEC
RRs, since the resolver will have no way of knowing the owner name of RRs, since the resolver will have no way of knowing the owner name of
the missing NXT RR, but in the specific case of a NODATA response, the missing NSEC RR, but in the specific case of a NODATA response,
the resolver does know the name of the missing NXT RR, and must the resolver does know the name of the missing NSEC RR, and must
therefore attempt to retrieve it. therefore attempt to retrieve it.
A security-aware resolver MUST be able to determine whether or not it A security-aware resolver MUST be able to determine whether or not it
should expect a particular RRset to be signed. More precisely, a should expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between three security-aware resolver must be able to distinguish between three
cases: cases:
1. An RRset for which the resolver is able to build a chain of 1. An RRset for which the resolver is able to build a chain of
signed KEY and DS RRs from a trusted starting point to the RRset. signed DNSKEY and DS RRs from a trusted starting point to the
In this case, the RRset should be signed, and is subject to RRset. In this case, the RRset should be signed, and is subject
signature validation as described above. to signature validation as described above.
2. An RRset for which the resolver knows that it has no chain of 2. An RRset for which the resolver knows that it has no chain of
signed KEY and DS RRs from any trusted starting point to the signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able RRset may or may not be signed, but the resolver will not be able
to verify the signature. to verify the signature.
3. An RRset for which the resolver is not able to determine whether 3. An RRset for which the resolver is not able to determine whether
or not the RRset should be signed, because the resolver is not or not the RRset should be signed, because the resolver is not
able to obtain the necessary DNSSEC RRs. This can occur due when able to obtain the necessary DNSSEC RRs. This can occur when the
the security-aware resolver is not able to contact security-aware security-aware resolver is not able to contact security-aware
name servers for the relevant zones. name servers for the relevant zones.
A security-aware resolver MUST be capable of being preconfigured with A security-aware resolver MUST be capable of being preconfigured with
at least one trusted public key, and SHOULD be capable of being at least one trusted public key, and MUST be capable of being
preconfigured with multiple trusted public keys. Since a security- preconfigured with multiple trusted public keys or DS RRs. Since a
aware resolver will not be able to validate signatures without such a security-aware resolver will not be able to validate signatures
preconfigured trusted key, the resolver SHOULD have some reasonably without such a preconfigured trusted key, the resolver SHOULD have
robust mechanism for obtaining such keys when it boots. some reasonably robust mechanism for obtaining such keys when it
boots.
Editors' note: Should support for multiple public keys be a MUST
rather than a SHOULD?
A security-aware resolver SHOULD cache each response as a single A security-aware resolver SHOULD cache each response as a single
atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
single atomic entry containing the entire answer, including the named single atomic entry containing the entire answer, including the named
RRset and any associated DNSSEC RRs. The resolver SHOULD discard the RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire. entire atomic entry when any of the RRs contained in it expire.
Editors' note: This is implementation advice which came out of A security-aware resolver SHOULD NOT cache data with invalid
discussions at various workshops and investigations into possible signatures under normal circumstances. However, a security-aware
implementation issues with the (as yet unsettled) opt-in proposal. resolver SHOULD take steps to rate limit the number of identical
queries it generates, which may require the resolver to retain some
All of this advice has been discussed in WG meetings, and as far data about recently generated queries. Conceptually, this is similar
as the editors know these recommendations are not controversial, to negative caching [RFC2308], but since the resolver has no way of
but it is up to the WG to decide whether this sort of obtaining the appropriate caching TTL from received data in this
implementation advice belongs in this document. case, the TTL will have to be set by the implementation. This
document refers data retained as part of such a rate limiting
mechanism as the "BAD cache".
4.1 Recursive Name Servers 4.1 Recursive Name Servers
As explained in [9], a security-aware recursive name server is an As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
entity which acts in both the security-aware name server and recursive name server is an entity which acts in both the
security-aware resolver roles. This section uses the terms "name security-aware name server and security-aware resolver roles. This
server side" and "resolver side" to refer to the code within a section uses the terms "name server side" and "resolver side" to
security-aware recursive name server which implements the security- refer to the code within a security-aware recursive name server which
aware name server role and the code which implements the security- implements the security-aware name server role and the code which
aware resolver role, respectively. implements the security-aware resolver role, respectively.
The resolver side of a security-aware recursive name server MUST set
the DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If
the initiating request does not have the DO bit set, the name server
side MUST remove any DNSSEC RRs from the response sent to the
initiating resolver, but the resolver side MUST follow the usual
rules for caching which would apply to any security-aware resolver.
A security-aware recursive name server SHOULD NOT attempt to answer a A security-aware recursive name server MUST NOT attempt to answer a
query by piecing together cached data it received in response to query by piecing together cached data it received in response to
previous queries that requested different QNAMEs, QTYPEs, or previous queries that requested different QNAMEs, QTYPEs, or
QCLASSes. A security-aware recursive name server SHOULD NOT use NXT QCLASSes. A security-aware recursive name server MUST NOT use NSEC
RRs from one negative response to synthesize a response for a RRs from one negative response to synthesize a response for a
different query. A security-aware recursive name server SHOULD NOT different query. A security-aware recursive name server MUST NOT use
use a previous wildcard expansion to generate a response to a a previous wildcard expansion to generate a response to a different
different query. query.
Editors' note: Should any of the SHOULD NOTs in this paragraph be
MUST NOTs instead?
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
whether or not it is required to verify the response data it returns whether or not it is required to verify the response data it returns
to the name server side. to the name server side.
Editors' note: What should a security-aware recursive name server The resolver side of a security-aware recursive name server MUST set
do if it receives a query with CD=1 and DO=0? the DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If
the DO bit in an initiating query is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response, but but
MUST NOT strip any DNSSEC RRs that the initiating query explicitly
requested.
The resolver side MUST follow the usual rules for caching and
negative caching which would apply to any security-aware resolver.
If 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 the setting 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 CD bit is not set, the name server side SHOULD
return RCODE 2 (server failure).
The name server side of a security-aware recursive name server MUST
NOT set the AD bit in a response unless the name server considers all
RRsets in the Answer or Authority sections of the response to be
authentic, and SHOULD set the AD bit if and only if the name server
considers all RRsets in the Answer section and any relevant negative
response RRs in the Authority section to be authentic. How the name
server side of a security-aware recursive name server determines
whether an RRset is authentic depends on the origin of the RRset. If
the RRset came from the resolver side of the recursive name server
(the normal case), recursive name server MUST follow the procedure
described in Section 5. If the RRset came from a zone for which the
name server side of the recursive name server is authoritative, local
policy MAY consider the RRset to be authentic without further
verification simply because the RRset came from an authoritative
zone, but the name server SHOULD NOT do so unless the it obtained the
authoritative zone via secure means (such as a secure zone transfer
mechanism), and MUST NOT do so unless this behavior has been
configured explicitly.
4.2 Stub resolvers 4.2 Stub resolvers
A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR A security-aware stub resolver MUST include an EDNS [RFC2671] OPT
with the DO [7] bit set to one when sending queries. pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
A security-aware stub resolver MUST support a message size of at A security-aware stub resolver MUST support a message size of at
least 1220 octets, SHOULD support a message size of 4000 octets, and least 1220 octets, SHOULD support a message size of 4000 octets, and
MUST advertise the supported message size using the "sender's UDP MUST advertise the supported message size using the "sender's UDP
payload size" field in the EDNS OPT pseudo-RR. A security-aware stub payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
resolver MUST handle fragmented UDP packets correctly regardless of resolver MUST handle fragmented UDP packets correctly regardless of
whether any such fragmented packets were received via IPv4 or IPv6. whether any such fragmented packets were received via IPv4 or IPv6.
Please see [8] for discussion of these requirements. Please see [RFC3226] for discussion of these requirements.
A security-aware stub resolver MUST support the DNSSEC RR types, at A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they least to the extent of not mishandling responses just because they
contain DNSSEC RRs. A security-aware stub resolver MAY include the contain DNSSEC RRs. A security-aware stub resolver MAY include the
DNSSEC RRs returned by a security-aware recursive name server as part DNSSEC RRs returned by a security-aware recursive name server as part
of the data that it the stub resolver hands back to the application of the data that it the stub resolver hands back to the application
which invoked it, but is not required to do so. which invoked it but is not required to do so.
A security-aware stub resolver SHOULD NOT set the CD bit when sending A security-aware stub resolver SHOULD NOT set the CD bit when sending
queries, since, by definition, a security-aware stub resolver does queries, since, by definition, a security-aware stub resolver does
not validate signatures and thus depends on the security-aware not validate signatures and thus depends on the security-aware
recursive name server to perform validation on its behalf. recursive name server to perform validation on its behalf.
Editors' note: Should this SHOULD NOT be a MUST NOT? A security-aware stub resolver MAY chose to examine the setting of
the AD bit in response messages that it receives in order to
A security-aware stub resolver MUST NOT place any reliance on determine whether the security-aware recursive name server which sent
signature validation allegedly performed on its behalf except when the response claims to have cryptographically verified the data in
the security-aware stub resolver obtained the data in question from a the Answer and Authority sections of the response message. Note,
trusted security-aware recursive name server via a secure channel. however, that the responses received by a security-aware stub
resolver are heavily dependent on the local policy of the
security-aware recursive name server, so as a practical matter there
may be little practical value to checking the status of the AD bit
except perhaps as a debugging aid. In any case, a security-aware
stub resolver MUST NOT place any reliance on signature validation
allegedly performed on its behalf except when the security-aware stub
resolver obtained the data in question from a trusted security-aware
recursive name server via a secure channel.
5. Authenticating DNS Responses 5. Authenticating DNS Responses
In order to use DNSSEC RRs for authentication, a security-aware In order to use DNSSEC RRs for authentication, a security-aware
resolver requires preconfigured knowledge of at least one resolver requires preconfigured knowledge of at least one
authenticated KEY RR. The process for obtaining and authenticating authenticated DNSKEY or DS RR. The process for obtaining and
this initial KEY RR is achieved via some external mechanism. For authenticating this initial DNSKEY or DS RR is achieved via some
example, a resolver could use some off-line authenticated exchange to external mechanism. For example, a resolver could use some off-line
obtain a zone's KEY RR or obtain a DS RR that identifies and authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
authenticates a zone's KEY RR. The remainder of this section assumes that identifies and authenticates a zone's DNSKEY RR. The remainder
that the resolver has somehow obtained an initial set of of this section assumes that the resolver has somehow obtained an
authenticated KEY RRs. initial set of authenticated DNSKEY RRs.
An initial KEY RR can be used to authenticate a zone's apex KEY An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
RRset. To authenticate an apex KEY RRset using an initial key, the RRset. To authenticate an apex DNSKEY RRset using an initial key,
resolver MUST: the resolver MUST:
1. Verify that the initial KEY RR appears in the apex KEY RRset, and 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) RRset, and verify that the DNSKEY RR has the Zone Key Flag
set to one. (DNSKEY RDATA bit 7) set to one.
2. Verify that there is some SIG RR which covers the apex KEY RRset, 2. Verify that there is some RRSIG RR which covers the apex DNSKEY
and that the combination of the SIG RR and the initial KEY RR RRset, and that the combination of the RRSIG RR and the initial
authenticates the KEY RRset. The process for using a SIG RR to DNSKEY RR authenticates the DNSKEY RRset. The process for using
authenticate an RRset is described in Section 5.2. an RRSIG RR to authenticate an RRset is described in Section 5.3.
Once the resolver has authenticated the apex KEY RRset using an Once the resolver has authenticated the apex DNSKEY RRset using an
initial KEY RR, delegations from that zone can be authenticated using initial DNSKEY RR, delegations from that zone can be authenticated
DS RRs. This allows a resolver to start from an initial key, and use using DS RRs. This allows a resolver to start from an initial key,
DS RRsets to proceed recursively down the DNS tree obtaining other and use DS RRsets to proceed recursively down the DNS tree obtaining
apex KEY RRsets. If the resolver were preconfigured with a root KEY other apex DNSKEY RRsets. If the resolver were preconfigured with a
RR, and if every delegation had a DS RR associated with it, then the root DNSKEY RR, and if every delegation had a DS RR associated with
resolver could obtain any apex KEY RRset. The process of using DS it, then the resolver could obtain and validate any apex DNSKEY
RRs to authenticate referrals is described in Section 5.1. RRset. The process of using DS RRs to authenticate referrals is
described in Section 5.2.
Once the resolver has authenticated a zone's apex KEY RRset, Section Once the resolver has authenticated a zone's apex DNSKEY RRset,
5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
SIG RRs from the zone to authenticate any other RRsets in the zone. DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
Section 5.3 shows how the resolver can use authenticated NXT RRsets RRsets in the zone. Section 5.4 shows how the resolver can use
from the zone to prove that an RRset is not present in the zone. authenticated NSEC RRsets from the zone to prove that an RRset is not
present in the zone.
When a resolver indicates support for DNSSEC, a security-aware name When a resolver indicates support for DNSSEC, a security-aware name
server should attempt to provide the necessary KEY, SIG, NXT, and DS server should attempt to provide the necessary DNSKEY, RRSIG, NSEC,
RRsets in a response (see Section 3). However, a security-aware and DS RRsets in a response (see Section 3). However, a
resolver may still receive a response which that lacks the security-aware resolver may still receive a response which that lacks
appropriate DNSSEC RRs, whether due to configuration issues such as a the appropriate DNSSEC RRs, whether due to configuration issues such
security-oblivious recursive name server which accidently interfere as a security-oblivious recursive name server which accidentally
with DNSSEC RRs or due to a deliberate attack in which an adversary interfere with DNSSEC RRs or due to a deliberate attack in which an
forges a response, strips DNSSEC RRs from a response, or modifies a adversary forges a response, strips DNSSEC RRs from a response, or
query so that DNSSEC RRs appear not to be requested. The absence of modifies a query so that DNSSEC RRs appear not to be requested. The
DNSSEC data in a response MUST NOT by itself be taken as an absence of DNSSEC data in a response MUST NOT by itself be taken as
indication that no authentication information exists. an indication that no authentication information exists.
A resolver SHOULD expect authentication information from signed A resolver SHOULD expect authentication information from signed
zones. A resolver SHOULD believe that a zone is signed if the zones. A resolver SHOULD believe that a zone is signed if the
resolver has been configured with public key information for the resolver has been configured with public key information for the
zone, or if the zone's parent is signed and the delegation from the zone, or if the zone's parent is signed and the delegation from the
parent contains a DS RRset. parent contains a DS RRset.
5.1 Authenticating Referrals 5.1 Special Considerations for Islands of Security
Once the apex KEY RRset for a signed parent zone has been Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
zones for which it is not possible to construct an authentication
chain to the zone from its parent. Validating signatures within an
island of security requires the validator to have some other means of
obtaining a trusted zone key. If a validator cannot obtain such a
key, it will have to choose whether to accept the unvalidated
responses or not based on local policy.
All the normal processes for validating responses apply to islands of
security. The only difference between normal validation and
validation within an island of security is in how the validator
obtains a trusted starting point for the authentication chain.
5.2 Authenticating Referrals
Once the apex DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR identifies a KEY RR in the child to a signed child zone. A DS RR identifies a DNSKEY RR in the child
zone's apex KEY RRset, and contains a cryptographic digest of the zone's apex DNSKEY RRset, and contains a cryptographic digest of the
child zone's KEY RR. A strong cryptographic digest algorithm ensures child zone's DNSKEY RR. A strong cryptographic digest algorithm
that an adversary can not easily generate a KEY RR that matches the ensures that an adversary can not easily generate a DNSKEY RR that
digest. Thus, authenticating the digest allows a resolver to matches the digest. Thus, authenticating the digest allows a
authenticate the matching KEY RR. The resolver can then use this resolver to authenticate the matching DNSKEY RR. The resolver can
child KEY RR to authenticate the entire child apex KEY RRset. then use this child DNSKEY RR to authenticate the entire child apex
DNSKEY RRset.
Given a DS RR for a delegation, the child zone's apex KEY RRset can Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
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 KEY RR in the parent's o The DS RR has been authenticated using some DNSKEY RR in the
apex KEY RRset (see Section 5.2); 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 KEY RR in the child zone's apex KEY RRset and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
which, when hashed using the digest algorithm specified in the DS RRset which, when hashed using the digest algorithm specified in
RR's Digest Type field, results in a digest value which matches the DS RR's Digest Type field, results in a digest value which
the Digest field of the DS RR; and matches the Digest field of the DS RR; and
o The matching KEY RR in the child zone has the Zone Flag bit set to o The matching DNSKEY RR in the child zone has the Zone Flag bit set
one, the corresponding private key has signed the child zone's to one, the corresponding private key has signed the child zone's
apex KEY RRset, and the resulting SIG RR authenticates the child apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
zone's apex KEY 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 NXT 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.4). A security- RRset exists for the delegated name (see Section 3.4). A
aware resolver MUST send the parent a query for the DS RRset if the security-aware resolver MUST query the name servers for the parent
referral includes neither a DS RRset nor a NXT RRset proving the zone for the DS RRset if the referral includes neither a DS RRset nor
nonexistence of the DS RRset (see Section 4). a NSEC RRset proving that the DS RRset does not exist (see Section
4).
If the resolver authenticates an NXT RRset which proves that no DS If the resolver authenticates an NSEC RRset which proves that no DS
RRset is present for this zone, then there is no authentication path RRset is present for this zone, then there is no authentication path
leading from the parent to the child. If the resolver has an initial leading from the parent to the child. If the resolver has an initial
KEY RR which belongs to the child zone or to any delegation below the DNSKEY or DS RR which belongs to the child zone or to any delegation
child zone, this initial KEY RR MAY be used to re-establish an below the child zone, this initial DNSKEY or DS RR MAY be used to
authentication path. If no such initial KEY RR exists, the resolver re-establish an authentication path. If no such initial DNSKEY or DS
can not authenticate RRsets at or below the child zone. RR exists, the resolver can not authenticate RRsets in or below the
child zone.
Note that, for a signed delegation, there are two NXT RRs associated Note that, for a signed delegation, there are two NSEC RRs associated
with the delegated name. One NXT RR resides in the parent zone, and with the delegated name. One NSEC RR resides in the parent zone, and
can be used to prove whether a DS RRset exists for the delegated can be used to prove whether a DS RRset exists for the delegated
name. The second NXT RR resides in the child zone, and identifies name. The second NSEC RR resides in the child zone, and identifies
which RRsets are present at the apex of the child zone. The parent which RRsets are present at the apex of the child zone. The parent
NXT RR and child NXT RR can always be distinguished, since the SOA NSEC RR and child NSEC RR can always be distinguished, since the SOA
bit will be set in the child NXT RR and clear in the parent NXT RR. bit will be set in the child NSEC RR and clear in the parent NSEC RR.
A security-aware resolver MUST use the parent NXT RR when attempting A security-aware resolver MUST use the parent NSEC RR when attempting
to prove that a DS RRset does not exist. to prove that a DS RRset does not exist.
5.2 Authenticating an RRSet Using a SIG RR 5.3 Authenticating an RRset Using an RRSIG RR
A resolver can use a SIG RR and its corresponding KEY RR to attempt A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
to authenticate RRsets. The resolver first checks the SIG RR to attempt to authenticate RRsets. The resolver first checks the RRSIG
verify that it covers the RRset, has a valid time interval, and RR to verify that it covers the RRset, has a valid time interval, and
identifies a valid KEY RR. The resolver then constructs the identifies a valid DNSKEY RR. The resolver then constructs the
canonical form of the signed data by appending the SIG RDATA canonical form of the signed data by appending the RRSIG RDATA
(excluding the Signature Field) with the canonical form of the (excluding the Signature Field) with the canonical form of the
covered RRset. Finally, resolver uses the public key and signature covered RRset. Finally, resolver uses the public key and signature
to authenticate the signed data. Section 5.2.1, Section 5.2.2, and to authenticate the signed data. Section 5.3.1, Section 5.3.2, and
Section 5.2.3 describe each step in detail. Section 5.3.3 describe each step in detail.
5.2.1 Checking the SIG RR Validity 5.3.1 Checking the RRSIG RR Validity
A security-aware resolver can use a SIG RR to authenticate an RRset A security-aware resolver can use an RRSIG RR to authenticate an
if all of the following conditions hold: RRset if all of the following conditions hold:
o The SIG RR and the RRset MUST have the same owner name and the o The RRSIG RR and the RRset MUST have the same owner name and the
same class; same class;
o The SIG RR's Signer's Name field MUST be the name of the zone that o The RRSIG RR's Signer's Name field MUST be the name of the zone
contains the RRset; that contains the RRset;
o The SIG RR's Type Covered field MUST equal the RRset's type; o The RRSIG RR's Type Covered field MUST equal the RRset's type;
o The number of labels in the RRset owner name MUST be greater than o The number of labels in the RRset owner name MUST be greater than
or equal to the value in the SIG RR's Labels field; or equal to the value in the RRSIG RR's Labels field;
o The resolver's notion of the current time MUST be less than or o The resolver's notion of the current time MUST be less than or
equal to the time listed in the SIG RR's Expiration field; equal to the time listed in the RRSIG RR's Expiration field;
o The resolver's notion of the current time MUST be greater than or o The resolver's notion of the current time MUST be greater than or
equal to the time listed in the SIG RR's Inception field; equal to the time listed in the RRSIG RR's Inception field;
o The SIG 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 KEY RR in match the owner name, algorithm, and key tag for some DNSKEY RR in
the zone's apex KEY RRset; the zone's apex DNSKEY RRset;
o The matching KEY RR MUST be present in the zone's apex KEY RRset, o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one. RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
set to one.
It is possible for more than one KEY RR to match the conditions It is possible for more than one DNSKEY RR to match the conditions
above. In this case, the resolver can not predetermine which KEY RR above. In this case, the resolver can not predetermine which DNSKEY
to use to authenticate the signature, MUST try each matching KEY RR RR to use to authenticate the signature, MUST try each matching
until the resolver has either validated the signature or has run out DNSKEY RR until the resolver has either validated the signature or
of matching keys to try. has run out of matching keys to try.
Note that this authentication process is only meaningful if the Note that this authentication process is only meaningful if the
resolver authenticates the KEY RR before using it to validate resolver authenticates the DNSKEY RR before using it to validate
signatures. The matching KEY RR is considered to be authentic if: signatures. The matching DNSKEY RR is considered to be authentic if:
o The apex KEY RRset containing the KEY RR is considered authentic; o The apex DNSKEY RRset containing the DNSKEY RR is considered
or authentic; or
o The RRset covered by the SIG RR is the apex KEY RRset itself, and o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
the KEY RR either matches an authenticated DS RR from the parent and the DNSKEY RR either matches an authenticated DS RR from the
zone or matches a DS RR or KEY RR which the resolver has been parent zone or matches a DS RR or DNSKEY RR which the resolver has
preconfigured to believe to be authentic. been preconfigured to believe to be authentic.
5.2.2 Reconstructing the Signed Data 5.3.2 Reconstructing the Signed Data
Once the SIG RR has met the validity requirements described in Once the RRSIG RR has met the validity requirements described in
Section 5.2.1, the resolver needs to reconstruct the original signed Section 5.3.1, the resolver needs to reconstruct the original signed
data. The original signed data includes SIG RDATA (excluding the data. The original signed data includes RRSIG RDATA (excluding the
Signature field) and the canonical form of the RRset. Aside from Signature field) and the canonical form of the RRset. Aside from
being ordered, the canonical form of the RRset might also differ from being ordered, the canonical form of the RRset might also differ from
the received RRset due to DNS name compression, decremented TTLs, or the received RRset due to DNS name compression, decremented TTLs, or
wildcard expansion. The resolver should use the following to wildcard expansion. The resolver should use the following to
reconstruct the original signed data: reconstruct the original signed data:
signed_data = SIG_RDATA | RR(1) | RR(2)... where signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" denotes concatenation "|" denotes concatenation
SIG_RDATA is the wire format of the SIG RDATA fields with RRSIG_RDATA is the wire format of the RRSIG RDATA fields
the Signature field excluded and the Signer's Name in with the Signature field excluded and the Signer's Name
canonical form. in canonical form.
RR(i) = name | class | type | OrigTTL | RDATA length | RDATA RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
name is calculated according to the function below name is calculated according to the function below
class is the RRset's class class is the RRset's class
type is the RRset type and all RRs in the class type is the RRset type and all RRs in the class
OrigTTL is the value from the SIG Original TTL field OrigTTL is the value from the RRSIG Original TTL field
All names in the RDATA field are in canonical form All names in the RDATA field are in canonical form
The set of all RR(i) is sorted into canonical order. The set of all RR(i) is sorted into canonical order.
To calculate the name: To calculate the name:
let sig_labels = the value of the SIG Labels field let rrsig_labels = the value of the RRSIG Labels field
let fqdn = RRset's fully qualified domain name in let fqdn = RRset's fully qualified domain name in
canonical form canonical form
let fqdn_labels = RRset's fully qualified domain name in let fqdn_labels = RRset's fully qualified domain name in
canonical form canonical form
if sig_labels = fqdn_labels, if rrsig_labels = fqdn_labels,
name = fqdn name = fqdn
if sig_labels < fqdn_labels, if rrsig_labels < fqdn_labels,
name = "*." | the leftmost sig_label labels of the name = "*." | the leftmost rrsig_label labels of the
fqdn fqdn
if rrsig_labels > fqdn
if sig_labels > fqdn the RRSIG RR did not pass the necessary validation
the SIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this checks and MUST NOT be used to authenticate this
RRset. RRset.
Editors' note: The algorithm above needs to be cross-checked very Section 5.5.1 gives an example of original name calculation. The
carefully against the definitions in [10]. canonical forms for names and RRsets are defined in
[I-D.ietf-dnsext-dnssec-records].
Section 5.4.1 gives an example of original name calculation. The
canonical forms for names and RRsets are defined in [10].
NXT RRsets at a delegation boundary require special processing. NSEC RRsets at a delegation boundary require special processing.
There are two distinct NXT RRsets associated with a signed delegated There are two distinct NSEC RRsets associated with a signed delegated
name. One NXT RRset resides in the parent zone, and specifies which name. One NSEC RRset resides in the parent zone, and specifies which
RRset are present at the parent zone. The second NXT RRset resides RRset are present at the parent zone. The second NSEC RRset resides
at the child zone, and identifies which RRsets are present at the at the child zone, and identifies which RRsets are present at the
apex in the child zone. The parent NXT RRset and child NXT RRset can apex in the child zone. The parent NSEC RRset and child NSEC RRset
always be distinguished since only the child NXT RRs will specify an can always be distinguished since only the child NSEC RRs will
SOA RRset exists at the name. When reconstructing the original NXT specify an SOA RRset exists at the name. When reconstructing the
RRset for the delegation from the parent zone, the NXT RRs MUST NOT original NSEC RRset for the delegation from the parent zone, the NSEC
be combined with NXT RRs from the child zone, and when reconstructing RRs MUST NOT be combined with NSEC RRs from the child zone, and when
the original NXT RRset for the apex of the child zone, the NXT RRs reconstructing the original NSEC RRset for the apex of the child
MUST NOT be combined with NXT RRs from the parent zone. zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
zone.
Note also that each of the two NXT RRsets at a delegation point has a Note also that each of the two NSEC RRsets at a delegation point has
corresponding SIG RR with an owner name matching the delegated name, a corresponding RRSIG RR with an owner name matching the delegated
and each of these SIG RRs is authoritative data associated with the name, and each of these RRSIG RRs is authoritative data associated
same zone which contains the corresponding NXT RRset. If necessary, with the same zone which contains the corresponding NSEC RRset. If
a resolver can tell these SIG RRs apart by checking the Signer's Name necessary, a resolver can tell these RRSIG RRs apart by checking the
field. Signer's Name field.
5.2.3 Checking the Signature 5.3.3 Checking the Signature
Once the resolver has validated the SIG RR as described in Section Once the resolver has validated the RRSIG RR as described in Section
5.2.1 and reconstructed the original signed data as described in 5.3.1 and reconstructed the original signed data as described in
Section 5.2.2, the resolver can attempt to use the cryptographic Section 5.3.2, the resolver can attempt to use the cryptographic
signature to authenticate the signed data, and thus (finally!) signature to authenticate the signed data, and thus (finally!)
authenticate the RRset. authenticate the RRset.
The Algorithm field in the SIG RR identifies the cryptographic The Algorithm field in the RRSIG RR identifies the cryptographic
algorithm to generate the signature. The signature itself is algorithm to generate the signature. The signature itself is
contained in the Signature field of the SIG RDATA, and the public key contained in the Signature field of the RRSIG RDATA, and the public
to used generate the signature is contained in the Public Key field key to used generate the signature is contained in the Public Key
of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a field of the matching DNSKEY RR(s) (found in Section 5.3.1).
list of algorithm types, and provides pointers to the documents that [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
define each algorithm's use. and provides pointers to the documents that define each algorithm's
use.
Note that it is possible for more than one KEY RR to match the Note that it is possible for more than one DNSKEY RR to match the
conditions in Section 5.2.1. In this case, the resolver can only conditions in Section 5.3.1. In this case, the resolver can only
determine which KEY RR by trying each matching key until the resolver determine which DNSKEY RR by trying each matching key until the
either succeeds in validating the signature or runs out of keys to resolver either succeeds in validating the signature or runs out of
try. keys to try.
If the Labels field of the SIG RR is not equal to the number of If the Labels field of the RRSIG RR is not equal to the number of
labels in the RRset's fully qualified owner name, then the RRset is labels in the RRset's fully qualified owner name, then the RRset is
either invalid or the result of wildcard expansion. The resolver either invalid or the result of wildcard expansion. The resolver
MUST verify that wildcard expansion was applied properly before MUST verify that wildcard expansion was applied properly before
considering the RRset to be authentic. Section 5.2.4 describes how considering the RRset to be authentic. Section 5.3.4 describes how
to determine whether a wildcard was applied properly. to determine whether a wildcard was applied properly.
If other SIG RRs also cover this SIG RR, the local resolver security If other RRSIG RRs also cover this RRSIG RR, the local resolver
policy determines whether the resolver also needs to test these SIG security policy determines whether the resolver also needs to test
RRs, and determines how to resolve conflicts if these SIG RRs lead to these RRSIG RRs, and determines how to resolve conflicts if these
differing results. RRSIG RRs lead to differing results.
If the resolver accepts the RRset as authentic, the resolver MUST set If the resolver accepts the RRset as authentic, the resolver MUST set
the SIG RR's TTL and the TTL of each RR in the authenticated RRset to the TTL of the RRSIG RR and each RR in the authenticated RRset to a
the minimum of: value no greater than the minimum of:
o The RRset's TTL as received in the response; o The RRset's TTL as received in the response;
o The SIG RR's TTL as received in the response; and o The RRSIG RR's TTL as received in the response; and
o The value in the SIG RR's Original TTL field. o The value in the RRSIG RR's Original TTL field.
5.2.4 Authenticating A Wildcard Expanded RRset Positive Response 5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
If the number of labels in an RRset's fully qualified domain name is If the number of labels in an RRset's fully qualified domain name is
greater than the Labels field in the covering SIG RDATA, then the greater than the Labels field in the covering RRSIG RDATA, then the
RRset and its covering SIG RR were created as a result of wildcard RRset and its covering RRSIG RR were created as a result of wildcard
expansion. Once the resolver has verified the signature as described expansion. Once the resolver has verified the signature as described
in Section 5.2, the resolver must take additional steps to verify the in Section 5.3, the resolver must take additional steps to verify the
non-existence of an exact match or closer wildcard match for the non-existence of an exact match or closer wildcard match for the
query. Section 5.3 discusses these steps. query. Section 5.4 discusses these steps.
Note that the response received by the resolver should include all Note that the response received by the resolver should include all
NXT RRs needed to authenticate the response (see Section 3.3). NSEC RRs needed to authenticate the response (see Section 3.3).
5.3 Authenticated Denial of Existence 5.4 Authenticated Denial of Existence
A resolver can use authenticated NXT 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 NXT RRs for signed zones in their automatically include any necessary NSEC RRs for signed zones in
responses to security-aware resolvers. their responses to security-aware resolvers.
Security-aware resolvers MUST first authenticate NXT RRsets according Security-aware resolvers MUST first authenticate NSEC RRsets
to the standard RRset authentication rules described in Section 5.2, according to the standard RRset authentication rules described in
then apply the NXT RRsets as follows: 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 NXT RR, then the NXT 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. Since the existence of the authenticated NXT type in the bit map. Since the existence of the authenticated
RR proves that the owner name exists in the zone, wildcard NSEC RR proves that the owner name exists in the zone, wildcard
expansion could not have been used to match the requested RR owner expansion could not have been used to match the requested RR owner
name and type. name and type.
o If the requested RR name would appear after an authenticated NXT o If the requested RR name would appear after an authenticated NSEC
RR owner name and before the name listed in that NXT RR's Next RR 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 [10], then no exact match for the requested RR name defined in [I-D.ietf-dnsext-dnssec-records], then no exact match
exists in the zone. However, it is possible that a wildcard could for the requested RR name exists in the zone. However, it is
be used to match the requested RR owner name and type, so proving possible that a wildcard could be used to match the requested RR
that the requested RRset does not exist also requires proving that owner name and type, so proving that the requested RRset does not
no possible wildcard exists which could have been used to generate exist also requires proving that no possible wildcard exists which
a positive response. could have been used to generate a positive response.
To prove non-existence of an RRset, the resolver must be able to To prove non-existence of an RRset, the resolver must be able to
verify both that the queried RRset does not exist and that no verify both that the queried RRset does not exist and that no
relevant wildcard RRset exists. Proving this may require more than relevant wildcard RRset exists. Proving this may require more than
one NXT RRset from the zone. If the complete set of necessary NXT one NSEC RRset from the zone. If the complete set of necessary NSEC
RRsets is not present in a response (perhaps due to truncation), then RRsets is not present in a response (perhaps due to truncation), then
a security-aware resolver MUST resend the query in order to attempt a security-aware resolver MUST resend the query in order to attempt
to obtain the full collection of NXT RRs necessary to verify non- to obtain the full collection of NSEC RRs necessary to verify
existence of the requested RRset. As with all DNS operations, non-existence of the requested RRset. As with all DNS operations,
however, the resolver MUST bound the work it puts into answering any however, the resolver MUST bound the work it puts into answering any
particular query. particular query.
5.4 Example Since a verified NSEC RR proves the existance of both itself and its
corresponding RRSIG RR, a verifier MUST ignore the settings of the
NSEC and RRSIG bits in an NSEC RR.
5.4.1 Example of Re-Constructing the Original Owner Name 5.5 Examples
Editors' note: perhaps all of this should move to an appendix?
5.5.1 Example of Re-Constructing the Original Owner Name
Suppose that a security-aware resolver receives a response containing Suppose that a security-aware resolver receives a response containing
an answer RRset with an owner name of is "www.a.b.c.example.com". an answer RRset with an owner name of is "www.a.b.c.example.com".
This fully qualified domain name has 6 labels: "www", "a", "b", "c", This fully qualified domain name has 6 labels: "www", "a", "b", "c",
"example", and "com". What name the resolver should use when "example", and "com". What name the resolver should use when
reconstructing the original signed data depends on the value of the reconstructing the original signed data depends on the value of the
SIG RR's Labels field. RRSIG RR's Labels field.
If the value of the SIG RR's Labels field is 6, then the SIG RR's If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's
Labels field matches the number of labels in the owner name, and the Labels field matches the number of labels in the owner name, and the
resolver should assume that this RRset is not the result of wildcard resolver should assume that this RRset is not the result of wildcard
expansion. The resolver should therefore use "www.a.b.c.example.com" expansion. The resolver should therefore use "www.a.b.c.example.com"
as the owner name when reconstructing the original signed data for as the owner name when reconstructing the original signed data for
the signature check. the signature check.
If the value of the SIG RR's Labels field is less than 6, then the If the value of the RRSIG RR's Labels field is less than 6, then the
SIG RR's Labels count is less than the number of labels in the RRSIG RR's Labels count is less than the number of labels in the
RRset's owner name, and the resolver should assume that this RRset is RRset's owner name, and the resolver should assume that this RRset is
the result of wildcard expansion. The resolver should therefore the result of wildcard expansion. The resolver should therefore
reconstruct the original owner name by replacing the labels which reconstruct the original owner name by replacing the labels which
appear to be the result of wildcard expansion with a single "*." appear to be the result of wildcard expansion with a single "*."
label. For example, if the SIG RR's Labels field is 3, the resolver label. For example, if the RRSIG RR's Labels field is 3, the
should reconstruct the original owner name by prepending "*." to the resolver should reconstruct the original owner name by prepending
last 3 labels of the owner name of the answer RRset. Thus, the "*." to the last 3 labels of the owner name of the answer RRset.
resolver should use "*.c.example.com" as the owner name when Thus, the resolver should use "*.c.example.com" as the owner name
reconstructing the original signed data. when reconstructing the original signed data.
If the value of the SIG RR's Labels field is greater than 6, then If the value of the RRSIG RR's Labels field is greater than 6, then
this SIG RR cannot possibly be valid for the answer RRset, and there this RRSIG RR cannot possibly be valid for the answer RRset, and
is no point in attempting to validate the signature. there is no point in attempting to validate the signature.
5.4.2 Examples of Authenticating a Response 5.5.2 Examples of Authenticating a Response
Editors' note: Eventually this will be an example of the Editors' note: Eventually this will be an example of the
authentication process for "www.example.com", starting from an authentication process for "www.example.com", starting from an
initial root key. initial root key.
Editors' note: Eventually this will be an example of the Editors' note: Eventually this will be an example of the
authentication process for non-existent "www.a.b.c.example.com", authentication process for non-existent "www.a.b.c.example.com",
starting from an initial root key. starting from an initial root key.
6. IANA Considerations 6. IANA Considerations
This document introduces no IANA considerations. [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
considerations introduced by DNSSEC. The additional IANA
considerations discussed in this document:
[10] contains a complete review of the IANA considerations introduced [RFC2535] reserved the CD and AD bits in the message header. The
by DNSSEC. meaning of the AD bit was redefined in [I-D.ietf-dnsext-ad-is-secure]
and the meaning of both the CD and AD bit are restated in this
document. No new bits in the DNS message header are defined in this
document.
Editors' note: This may not be true anymore, since the AD and CD [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
bit definitions are now in this document rather than in [10]. and defined its use. The use is restated but not altered in this
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.
At this time, at least two substantial elements of the DNSSEC
specification have yet to be decided by the working group. The open
opt-in issue would change elements such as what RRsets must be
signed, would impact how wildcards are used, and would replace
authenticated denial of existence with authenticated denial of
security. Handling of the AD bit is also undecided. The AD bit (as
currently defined) is used to indicate the security status of RRsets
in the response. These items clearly raise security considerations
and will be addressed here as these issues are resolved in the
working group.
DNSSEC introduces a number of denial of service issues. These issues DNSSEC introduces a number of denial of service issues. These issues
will also be addressed in a future version of these security will also be addressed in a future version of these security
considerations. considerations.
Please see [9] for general security considerations related to DNSSEC. Please see [I-D.ietf-dnsext-dnssec-intro] for general security
considerations related to DNSSEC.
8. Acknowledgements 8. Acknowledgements
This document was created from the input and ideas of several members This document was created from the input and ideas of several members
of the DNS Extensions Working Group and working group mailing list. of the DNS Extensions Working Group and working group mailing list.
The co-authors of this draft would like to express their thanks for The co-authors of this draft would like to express their thanks for
the comments and suggestions received during the revision of these the comments and suggestions received during the revision of these
security extension specifications. security extension specifications.
Normative References Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[2] 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.
[3] 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.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
August 1999. 2671, August 1999.
[7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
December 2001. 3225, December 2001.
[8] 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] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, [I-D.ietf-dnsext-dnssec-intro]
"DNS Security Introduction and Requirements", draft-ietf- Arends, R., Austein, R., Larson, M., Massey, D. and S.
dnsext-dnssec-intro-05 (work in progress), February 2003. Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-06 (work in progress),
[10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, September 2003.
"Resource Records for DNS Security Extensions", draft-ietf-
dnsext-dnssec-records-04 (work in progress), February 2003.
[11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- [I-D.ietf-dnsext-dnssec-records]
ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-04 (work in progress),
September 2003.
Informative References Informative References
[12] Eastlake, D., "Domain Name System Security Extensions", RFC [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
2535, March 1999. NCACHE)", RFC 2308, March 1998.
[13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
2930, September 2000. RFC 2535, March 1999.
[14] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[15] Gudmundsson, O., "Delegation Signer Resource Record", draft- [I-D.ietf-dnsext-delegation-signer]
ietf-dnsext-delegation-signer-12 (work in progress), December Gudmundsson, O., "Delegation Signer Resource Record",
2002. draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003.
[I-D.ietf-dnsext-wcard-clarify]
Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
Domains in the Domain Name System",
draft-ietf-dnsext-wcard-clarify-01 (work in progress),
August 2003.
[I-D.ietf-dnsext-ad-is-secure]
Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD
bit", draft-ietf-dnsext-ad-is-secure-06 (work in
progress), June 2002.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Drienerlolaan 5
7522 NB Enschede 7522 NB Enschede
NL NL
EMail: roy.arends@telin.nl EMail: roy.arends@telin.nl
skipping to change at page 40, line 8 skipping to change at page 39, line 8
National Institute for Standards and Technology National Institute for Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899-8920 Gaithersburg, MD 20899-8920
USA USA
EMail: scott.rose@nist.gov EMail: scott.rose@nist.gov
Appendix A. Algorithm For Handling Wildcard Expansion Appendix A. Algorithm For Handling Wildcard Expansion
For zone (Z) and a name (N) that may occur in Z, the following For zone (Z) and a name (N) that may occur in Z, the following
algorithm finds all wildcard RRsets that match N or returns an NXT algorithm finds all wildcard RRsets that match N or returns an NSEC
RRset that proves no wildcard expansion matches N. The algorithm was RRset that proves no wildcard expansion matches N. The algorithm was
written for clarity, not efficiency: written for clarity, not efficiency:
0. INPUT: a name (N) and a zone (Z). 0. INPUT: a name (N) and a zone (Z).
INIT: NXT_SET = NULL INIT: NSEC_SET = NULL
1. Construct S = sequence of all names in Z, sorted 1. Construct S = sequence of all names in Z, sorted
into canonical order. into canonical order.
2. If N exists in S 2. If N exists in S
There is an exact match for N. There is an exact match for N.
Return all RRsets associated with N Return all RRsets associated with N
Else Else
Add the name that would immediately Add the name that would immediately
precede N in S to NXT_SET. precede N in S to NSEC_SET.
EndIf EndIf
3. Replace the leftmost label of N with * 3. Replace the leftmost label of N with *
4. If N exists in S 4. If N exists in S and answers the query
There is a positive wildcard match for N. There is a positive wildcard match for N.
Return all RRsets associated with N Return all RRsets associated with N
Else Else
Add the NXT for name that would immediately Add the NSEC for name that would immediately
precede N in S to NXT_SET. precede N in S to NSEC_SET.
Return the NSEC_SET.
EndIf EndIf
5. Remove the leading * from N. 5. Remove the leading * from N.
6. If N exists in S 6. If N exists in S
There is a name that terminates the wildcard search. There is a name that terminates the wildcard search.
Add the NXT for N to NXT_SET and return NXT_SET. Add the NSEC for N to NSEC_SET and return NSEC_SET.
Else Else
Goto Step 3 Add the NSEC for name that would immediately
precede N in S to NSEC_SET.
Return the NSEC_SET.
EndIf EndIf
Note: the algorithm is guaranteed to terminate since Appendix B. Signed Zone Example
eventually there will be a match or N will be
reduced to zone name itself and the zone name The following example shows a (small) complete signed zone.
must exist in S.
example. 3600 IN SOA ns1.example. bugs.ns1.example. (
1064876255
3600
300
3600000
3600
)
3600 RRSIG SOA 1 1 3600 20031029215736 (
20030929215736 4638 example.
Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA
KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE
v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ
h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal
ahgGvtiSMzzSS7n65xfxc1X78Nw= )
3600 NS ns1.example.
3600 NS ns2.example.
3600 RRSIG NS 1 1 3600 20031029215736 (
20030929215736 4638 example.
WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd
wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh
YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3
DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i
TYq3Ed0R9VStJwtiKmoXqubFAr0= )
3600 MX 1 xx.example.
3600 RRSIG MX 1 1 3600 20031029215736 (
20030929215736 4638 example.
eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9
Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo
djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW
BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM
5gmIc/F6gzUL3/KyJA8zPF2fUVA= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC
3600 RRSIG NSEC 1 1 3600 20031029215736 (
20030929215736 4638 example.
t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2
D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/
XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX
ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x
DBRONckIWXn2chGDeicQuEHjhfQ= )
3600 DNSKEY 256 3 1 (
AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO
G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3
LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd
kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG
mK5G3NeHjqssh1AujDaqHFf5IRIeQQ==
)
3600 DNSKEY 257 3 1 (
AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq
SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g
TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR
+6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO
rsSftzmRYHou70oVQ7aBjd9ePPCOVw==
)
3600 RRSIG DNSKEY 1 1 3600 20031029215736 (
20030929215736 4638 example.
GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk
4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF
kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2
lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx
lOyOxNDJPATE3Wm+AX0SmQSJ3XY= )
a.example. 3600 IN NS ns1.a.example.
3600 IN NS ns2.a.example.
3600 DS 23677 1 1 (
F248F32298280A061736C93FB078A51C17CC
C291 )
3600 RRSIG DS 1 2 3600 20031029215736 (
20030929215736 4638 example.
k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa
8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB
SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH
FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz
YJs3G/9tNte9i25YtAuLHbD2UqY= )
3600 NSEC ai.example. NS DS RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs
T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By
d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6
iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9
gURpK8RlfEPb7O98rrYLWZbzg3o= )
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
ai.example. 3600 IN A 192.0.2.9
3600 RRSIG A 1 2 3600 20031029215736 (
20030929215736 4638 example.
UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY
RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM
OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t
5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ
vVNUzslGEBlQ0SJZkWJcCtRDo5c= )
3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 1 2 3600 20031029215736 (
20030929215736 4638 example.
CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2
jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP
NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9
uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT
6IAiGfqY/zYFXWSIsmJr0875PQ0= )
3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 1 2 3600 20031029215736 (
20030929215736 4638 example.
VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG
zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU
Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4
esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH
KI0DhRWJC/iKs6J963WLNdPnwKk= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM
J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ
U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji
qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL
SpV8hBOC+EAcLjnuAi5DJJlONmc= )
b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ
dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7
YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX
N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH
u2x/e3zoBQdHAId3LCOO9jYDzCc= )
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1
3600 RRSIG A 1 2 3600 20031029215736 (
20030929215736 4638 example.
u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ
x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b
JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb
MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c
fdZ587NLR1Ns2GraGTztUDMSK/A= )
3600 NSEC ns2.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey
jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs
nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi
Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome
I2mIq/WvuXTr2XKcJDbxYIdSyss= )
ns2.example. 3600 IN A 192.0.2.2
3600 RRSIG A 1 2 3600 20031029215736 (
20030929215736 4638 example.
mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq
DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz
S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr
PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW
IGUMRh8nFi+wnG09+OH46IlkB9s= )
3600 NSEC *.w.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3
pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ
64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs
n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/
2aw1RkmYb4LbuhP0uwN/lZqQVik= )
*.w.example. 3600 IN MX 1 ai.example.
3600 RRSIG MX 1 2 3600 20031029215736 (
20030929215736 4638 example.
MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm
TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+
FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi
EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi
G7zd/X4PmuWIIYG+5IAzmtB2UJs= )
3600 NSEC x.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
tXBqjlbdFl70S+dzovir86EQBHavroozeo4f
Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog
0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y
H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK
w1LXOATBvP/kCRgmq4KdFNwTiBc= )
x.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 1 3 3600 20031029215736 (
20030929215736 4638 example.
p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP
rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE
LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl
QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC
+tqUhrmtTxtItfpV/8Q7i6+B2bY= )
3600 NSEC x.y.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 3 3600 20031029215736 (
20030929215736 4638 example.
c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4
EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP
M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi
lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29
IgHVoBYahu8hE0DycgzLredhC5A= )
x.y.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 1 4 3600 20031029215736 (
20030929215736 4638 example.
nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg
Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk
h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7
CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD
JYEmK1UOpYTDRx+lKLRI5tLzKmc= )
3600 NSEC xx.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 4 3600 20031029215736 (
20030929215736 4638 example.
UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By
vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG
ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ
ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27
rKbS4qvhL+dfOnPBPNI099W7EAw= )
xx.example. 3600 IN A 192.0.2.10
3600 RRSIG A 1 2 3600 20031029215736 (
20030929215736 4638 example.
irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d
foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h
aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN
fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN
zJKlxAUeVRQ2ufYCoSY7wa6cIV4= )
3600 HINFO "KLH-10" "TOPS-20"
3600 RRSIG HINFO 1 2 3600 20031029215736 (
20030929215736 4638 example.
NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61
DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9
5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA
opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq
hjNlRggyhvEmSNw4kvl5w99jqKg= )
3600 AAAA 2001:db8::f00:baaa
3600 RRSIG AAAA 1 2 3600 20031029215736 (
20030929215736 4638 example.
wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ
yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j
AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y
bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq
ndtF5V/pM6xI0tiE51KudVttsJI= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 (
20030929215736 4638 example.
fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34
k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI
AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu
YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0
fQ5nfoBQ++eHo+IEohbqrwnE60E= )
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
Flags indicate that each of these DNSKEY RRs is a zone key. One of
these DNSKEY RRs also has the SEP flag set and has been used to sign
the apex DNSKEY RRset; this is the key which should be hashed to
generate a DS record to be inserted into the parent zone. The other
DNSKEY is used to sign all the other RRsets in the zone.
The zone includes a wildcard entry "*.w.example". Note that the name
"*.w.example" is used in constructing NSEC chains, and that the RRSIG
covering the "*.w.example" MX RRset has a label count of 2.
The zone also includes two delegations. The delegation to
"b.example" includes an NS RRset, glue address records, and an NSEC
RR; note that only the NSEC RRset is signed. The delegation to
"a.example" provides a DS RR; note that only the NSEC and DS RRsets
are signed.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

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