draft-ietf-dnsext-dnssec-protocol-00.txt   draft-ietf-dnsext-dnssec-protocol-01.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Internet-Draft Telematica Instituut
Expires: April 25, 2003 M. Larson Expires: September 1, 2003 M. Larson
VeriSign VeriSign
R. Austein
ISC
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
October 25, 2002 March 3, 2003
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-00 draft-ietf-dnsext-dnssec-protocol-01
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 groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
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 April 25, 2003. This Internet-Draft will expire on September 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents that describe the This document is part of a family of documents which describes the
DNS Security Extensions (DNSSEC). The DNS Security Extensions are DNS Security Extensions (DNSSEC). The DNS Security Extensions are a
a collection of new resource records and protocol modifications collection of new resource records and protocol modifications which
that provide source authentication for the DNS. This document add data origin authentication and data integrity to the DNS. This
describes the DNSSEC protocol modifications. The concept of zone document describes the DNSSEC protocol modifications. This document
signing is introduced and the zone format is modified to include defines the concept of a signed zone, along with the requirements for
KEY, SIG, NXT, and DS resource records. If a resolver indicates serving and resolving using DNSSEC. These techniques allow a
support for DNSSEC, the response process is modified to include security-aware resolver to authenticate both DNS resource records and
the appropriate KEY, SIG, NXT, and DS resource records. These authoritative DNS error indications.
resource records are used by the resolver to authenticate the
response.
This document obsoletes RFC 2535 and incorporates changes from all This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535. updates to RFC 2535.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Background and Related Documents . . . . . . . . . . . . . . 4 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 5 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 and Zone Format . . . . . . . . . . . . . . . . 6 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Inclusion of KEY RRs in a Zone . . . . . . . . . . . . . . . 7 2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6
2.2 Inclusion of NXT RRs in a Zone . . . . . . . . . . . . . . . 7 2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7
2.3 Inclusion of SIG RRs in a Zone . . . . . . . . . . . . . . . 7 2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8
2.4 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
2.5 Inclusion of DS RRs in a Zone . . . . . . . . . . . . . . . 8 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
3. Constructing DNS Responses . . . . . . . . . . . . . . . . . 10 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Indicating Resolver Support for DNSSEC . . . . . . . . . . . 10 3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10
3.2 Inclusion of SIG RRs in a Response . . . . . . . . . . . . . 11 3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11
3.3 Inclusion of KEY RRs In a Response . . . . . . . . . . . . . 12 3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11
3.4 Inclusion of NXT RRs In a Response . . . . . . . . . . . . . 12 3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
3.4.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12
3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches . 13 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13
3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
3.5 Inclusion of DS RRs In a Response . . . . . . . . . . . . . 13 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
3.6 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15
3.7 Special Considerations for Recursive/Caching Servers . . . . 15 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15
3.8 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
3.9 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. Authenticating DNS Responses . . . . . . . . . . . . . . . . 17 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23
4.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 18 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 19 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
4.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 19 5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
4.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 20 5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27
4.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 22 5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27
4.2.4 Authenticating Wildcard Expanded RRset . . . . . . . . . . . 23 5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
4.3 Authenticated Denial of Existence . . . . . . . . . . . . . 23 5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31
4.4.1 Example of Re-Constructing the Original Name . . . . . . . . 24 5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . 27 5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33
References . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . 35
A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Statement . . . . . . . . . . . . . . . . . . 32 Normative References . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) modify several aspects of the The DNS Security Extensions (DNSSEC) modify several aspects of the
DNS protocol. The concept of zone signing is introduced and the DNS protocol. Section 2 defines the concept of a signed zone and
zone format is modified to include KEY, SIG, NXT, and DS resource lists the requirements for zone signing. Section 3 describes the
records as described in Section 2. If the resolver has indicated modifications to authoritative name server behavior necessary to
support for DNSSEC, the process of constructing a DNS response is handle signed zones. Section 4 describes the behavior of entities
also modified to include the appropriate KEY, SIG, NXT, and DS RR which include security-aware resolver functions Finally, Section 5
types. Section 3 defines how a resolver indicates support for defines how to use DNSSEC RRs to authenticate a response.
DNSSEC, describes how the DNSSEC RR types are included in a
response, and also describes the specgal processing rules required
to handle queries for the DS RR type. Finally, Section 4 defines
how a resolver uses the DNSSEC RRs to authenticate a response.
1.1 Background and Related Documents 1.1 Background and Related Documents
This document is part of a family of documents that define the DNS The reader is assumed to be familiar with the basic DNS concepts
security extensions. The DNS security extensions (DNSSEC) are a described in RFC1034 [1] and RFC1035 [2].
collection of resource records and DNS protocol modifications that
add source authentication the Domain Name System (DNS). An
introduction to DNSSEC and definition of common terms can be found
in [8]. A definition of the DNSSEC resource records can be found
in [9]. This document defines the DNSSEC protocol modificatinos.
The reader to assumed to be familiar with the basic DNS concepts This document is part of a family of documents which define the DNS
described in RFC1034 [1] and RFC1035 [2] and should also be security extensions (DNSSEC). The DNS Security Extensions are a
familiar with common DNSSEC terminology as defined in [8]. collection of new resource records and protocol modifications which
add data origin authentication and data integrity to the DNS. An
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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in RFC 2119. [4].
RFC 2119. [4].
1.3 Editors Notes 1.3 Editors' Notes
1.3.1 Open Technical Issues 1.3.1 Open Technical Issues
The use of the NXT record requires input from the working group. Use of NXT RRs throughout this document set will have to be modified
Although the opt-in issue is not resolved, progress on this if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT
document was still needed. This text describes the NXT record as record requires input from the working group. This text describes
it was defined in RFC 2535 and substantial portions of this the NXT record as it was defined in RFC 2535, and substantial
document would need to be updated to incorporate opt-in. The portions of this document would need to be updated to incorporate
updates will be made if opt-in is adopted. opt-in. The updates will be made if the WG adopts opt-in.
The use of the AD bit is described in section 3.8 and requires Use of the AD bit requires input from the working group. Since the
input from the working group. Since the AD bit usage is not AD bit usage is not resolved, this text attempts to capture current
resolved, this text attempts to capture current ideas and drafts, ideas and drafts, but further input from the working group is
but further input from the working group is required. required.
1.3.2 Technical Changes or Corrections 1.3.2 Technical Changes or Corrections
Please report technical corrections to dnssec- Please report technical corrections to dnssec-editors@east.isi.edu.
editors@east.isi.edu. To assist the editors, please indicate the
text in error and point out the RFC that defines the correct To assist the editors, please indicate the text in error and point
behavior. For a technical change where there is no RFC that out the RFC that defines the correct behavior. For a technical
defines the correct behavior (or RFCs provide conflicting change where no RFC that defines the correct behavior, or if there's
answers), please post the issue to namedroppers. more than one applicable RFC and the definitions conflict, please
post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This "DNSSEC RRs SHOULD be automatically returned in responses." This was
was true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
the DNSSEC RR types MUST NOT be included in responses unless the DNSSEC RR types MUST NOT be included in responses unless the resolver
resolver indicated support for DNSSEC. indicated support for DNSSEC.
1.3.3 Typos and Minor Corrections 1.3.3 Typos and Minor Corrections
Please report any typos corrections to dnssec- Please report any typos corrections to dnssec-editors@east.isi.edu.
editors@east.isi.edu. To assist the editors, please provide To assist the editors, please provide enough context for us to find
enough context for us to quickly find the incorrect text. 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 and Zone Format 2. Zone Signing
DNSSEC defines a new process called zone signing and adds the KEY,
SIG, NXT, and DS resource records to the zone format. The zone
signing process is the first step in enabling resource record
authentication for this zone. After a signed zone has been
created and loaded, the KEY, SIG, NXT, and DS resource records can
be included in responses (as decribed in Section 3) and can be
used by resolvers to authenticate responses (as describe in
Section 4). KEY, SIG, NXT, and DS RRs MUST NOT appear in unsigned
zones.
To sign a zone, the zone administrator generates one or more DNSSEC defines the concept of a signed zone. A signed zone includes
public/private key pairs. The zone's public key(s) are made KEY, SIG, NXT and (optionally) DS records according to the rules
available by storing them in KEY resource records. Other DNS specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4,
public keys, such as public keys used by TKEY and SIG(0), can also respectively. Any zone which does not include these records
be stored in KEY RRs. Once the KEY records have been added to the according to the rules in this section must be considered unsigned.
zone, the zone is sorted into a canonical form and NXT resource
records are added to enable authenticated denial of existence.
The zone administrator then signs every authoritative RRset in the
zone using the private key(s) and the signatures are stored in SIG
resource records. The resulting signed zone contains all data in
the original (unsigned) zone and also includes the new KEY, NXT,
and SIG RRs.
Section 2.1, Section 2.2, and Section 2.3 present the rules for Editors' note: Should this be "MUST be considered unsigned"?
the including the KEY, NXT, and SIG resource records in a zone
(respectively).
The zone signing process also requires a change in the definition DNSSEC requires a change to the definition of the CNAME resource
of the CNAME resource record and Section 2.4 changes the CNAME RR record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to
to allow SIG and NXT RRs to appear along with the CNAME RR. appear at the same owner name as a CNAME RR.
To enable authentication chains between DNS zones, a signed zone Section 2.6 shows a sample signed zone.
includes DS Resource Records for its signed delegations. Section
2.5 presents the rules for including DS resource records.
Note that if a resource record in a signed zone is added, 2.1 Including KEY RRs in a Zone
modified, or deleted, the signatures associaates with this RRset
MUST be updated and the NXT RR associated with the RRset's owner
name MUST also be updated. In addition, the zone MUST be
periodically resigned in order to maintain current SIG expiration
dates and the zone keys SHOULD change periodically. DNSSEC best
practices documents are encouraged to provide recommendations for
signature and key lifetimes.
2.1 Inclusion of KEY 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?
A zone administrator generates a set of public/private key pairs To sign a zone, the zone's administrator generates one or more
and uses the private key(s) to sign authoritative RRsets in the public/private key pairs and uses the private key(s) to sign
zone. For each private zone key used to create SIG RRs, there authoritative RRsets in the zone. For each private key used to
SHOULD be a corresponding public KEY RR stored at the zone apex create SIG RRs, there SHOULD be a corresponding KEY RR stored at the
and the corresponding KEY RR MUST have the Zone Key Flag (KEY zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone
RDATA Flag bit 7) set to 1. KEY RR's with Zone Flag set MUST only key KEY RR has the Zone Key bit of the Flags RDATA field set to one.
appear at the zone apex. See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the
zone apex.
A signed zone MUST have at least one zone KEY RR in its apex KEY A signed zone MUST have at least one zone key KEY RR in its apex KEY
set and the apex KEY set MUST be self-signed by at least one RRset. The KEY RRset at the zone apex MUST be self-signed by at
private key whose corresponding public zone KEY RR is stored in least one private key whose corresponding public key is a zone key
the apex KEY set. stored in the apex KEY RRset.
Other DNS public keys, such as those used by TKEY and SIG, can be Editors' note: The requirement listed in this paragraph may not be
stored in the zone using non-Zone KEY RR's (KEY RDATA Flag bit 7 necessary anymore, since the KEY RRset is self-signed anyway
set to 0). Non-zone KEY RR's MUST NOT appear at delegation names, (because the whole zone is signed). This is probably a pre-DS
but MAY appear at any other authoritative name in the zone. A relic, but we spotted this a few hours before the I-D deadline and
non-zone KEY RR SHOULD NOT appear at the apex name since this were too chicken to remove it on such short notice....
could lead to large apex KEY sets and requires added processing
time at resolvers.
2.2 Inclusion of NXT RRs in a Zone Other public keys associated with other DNS operations can be stored
in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs
MUST NOT appear at delegation names. Non-zone key KEY RRs also
SHOULD NOT appear at the zone apex, because large KEY RRsets add
processing time at resolvers. Non-zone key KEY RRs MAY appear at any
other name in the zone.
Each authoritative name in the zone MUST have an NXT resource 2.2 Including SIG RRs in a Zone
record. The NXT record indicates what are RR types are present at
that name and indicates the next authortitive name in the zone.
The collection of NXT or "next" resource records (RR) provide a
chain of all authoritative names and RRsets in the zone and are
used for authenticated denial of existence. The process for
constructing the NXT RR for a given name is described in [9].
2.3 Inclusion of SIG RRs in a Zone For each authoritative RRset in the zone (which excludes NS RRsets at
delegation points and glue RRsets), there MUST be at least one SIG
record that meets all of the following requirements:
For each authoritative RRset in the zone, there MUST be at least o The SIG owner name is equal to the RRset owner name;
one SIG record that meets all of the following requirements:
The SIG owner name is equal to the RRset owner name. o The SIG class is equal to the RRset class;
The SIG class is equal to the RRset class. o The SIG Type Covered field is equal to the RRset type;
The SIG Type Covered field is equal to the RRset type. o The SIG Original TTL field is equal to the TTL of the RRset;
The SIG Original TTL field is greater than or equal to the TTL o The SIG RR's TTL is equal to the TTL of the RRset;
of the RRset.
The SIG Labels field is equal to the number of labels in RRset o The SIG Labels field is equal to the number of labels in the RRset
owner name. owner name, not counting the null root label or any wildcard
label;
The SIG Signer's Name is equal to the name of the zone o The SIG Signer's Name field is equal to the name of the zone
containing the RRset. containing the RRset; and
The SIG Algorithm, Signer's Name, and Key Tag fields identify a o The SIG Algorithm, Signer's Name, and Key Tag fields identify a
zone KEY record at the zone apex. zone key KEY record at the zone apex.
The process for constructing the SIG RR for a given RRset is The process for constructing the SIG RR for a given RRset is
described in [9]. An RRset MAY have multiple SIG RR associated described in [10]. An RRset MAY have multiple SIG RRs associated
with it. with it.
The SIG RR itself MUST NOT be signed since signing a SIG RRset A SIG RR itself MUST NOT be signed, since signing a SIG RRset would
adds no value and creates a unterminated dependency loop in the add no value and would create an unterminated dependency loop in the
signing process. signing process.
The NS RRset that appears at the zone apex name MUST be signed, The NS RRset which appears at the zone apex name MUST be signed, but
but NS RRsets that appear at delegation owner names (child zones) the NS RRsets which appear at delegation points (that is, the NS
MUST NOT be signed and any glue address RRsets assoicated with RRsets in the parent zone which delegate the name to the child zone's
child delegations MUST NOT be signed. name servers) MUST NOT be signed. Glue address RRsets associated
with delegations MUST NOT be signed.
2.4 Changes to the CNAME Resource Record. The difference between the set of owner names which require SIG
records and the set of owner names which require NXT records is
subtle and worth highlighting. SIG records are present at the owner
names of all authoritative RRsets. NXT records are present at the
owner names of all names for which the signed zone is authoritative
and also at the owner names of delegations from the signed zone to
its children. Neither NXT nor SIG records are present (in the parent
zone) at the owner names of glue address RRsets. Note, however, that
this distinction is for the most part only visible during the zone
signing process, because NXT RRsets are authoritative data, and
therefore are signed, thus any owner name which has an NXT RRset will
have SIG RRs as well in the signed zone.
If a CNAME RR is present at a name, RRs other than the SIG and NXT 2.3 Including NXT RRs in a Zone
MUST NOT be present at that name.
The above is modification to the original CNAME definition given Each owner name in the zone MUST have an NXT resource record, except
in [1]. The original definition of CNAME did not allow any other for the owner names of any glue address RRsets. The process for
resource records to co-exist with a CNAME record, but the zone constructing the NXT RR for a given name is described in [10].
signing process associates NXT and SIG resource records with every
authorititative name. To resolve this conflict, the definition of
the CNAME resource record is modified to allow for the co-
existence of NXT and SIG RRs.
2.5 Inclusion of DS RRs in a Zone 2.4 Including DS RRs in a Zone
The DS resource record is used to establish authentication chains The DS resource record establishes authentication chains between DNS
between DNS zones. A signed delegation (child zone) SHOULD zones. A DS RRset SHOULD be present at a delegation point when the
provide its parent zone with a DS RR for the delegation. All DS child zone is signed. The DS RRset MAY contain multiple records,
RRsets stored in a zone MUST be signedx and DS RRsets MUST NOT each referencing a key used by the child zone to sign its apex KEY
appear at non-delegation points or at a zone's apex. 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.
The DS RR provided by the child SHOULD point to a KEY RR that is A DS RR SHOULD point to a KEY RR which is present in the child's apex
present in the child's apex KEY set and the child's apex KEY RRset KEY RRset, and the child's apex KEY RRset SHOULD be signed by the
SHOULD be signed by the corresponding private key. If the KEY RR corresponding private key.
is present in the child's apex KEY set, the KEY RR MUST have the
Zone Key Flag set.
Note that the process of providing a DS RR can be accomplished by Construction of a DS RR requires knowledge of the corresponding KEY
either directly sending the DS RR to the parent or by sending a RR in the child zone, which implies communication between the child
KEY RR to the parent and requesting that the parent construct a DS and parent zones. This communication is an operational matter not
RR for the given KEY RR. The parent/child communication needs to covered by this document.
be authenticated in order to prevent an adversary from inserting a
false DS RR. DNSSEC operational and best practices documents are 2.5 Changes to the CNAME Resource Record.
encouraged to provide guidelines for providing a DS RR.
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
be present at that name.
This is a modification to the original CNAME definition given in [1].
The original definition of the CNAME RR did not allow any other types
to co-exist with a CNAME record, but a signed zone requires NXT and
SIG RRsets for every authoritative name. To resolve this conflict,
the definition of the CNAME resource record is hereby modified to
allow for the co-existence of NXT and SIG RRsets.
2.6 Example of a Secure Zone 2.6 Example of a Secure Zone
secure zone {{secure zone here}}
The apex KEY set includes two KEY RRs and the KEY RDATA Flags 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 indicate that each of these KEY RRs is a zone key. The first zone
KEY is used to sign the apex KEY set and a DS record for this key 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 is provided to the parent zone. The second zone KEY is used to sign
sign all the other RRsets in the zone. A non-zone KEY RR is also all the other RRsets in the zone. A non-zone KEY RR is also stored
stored at host1.example.com and this KEY and might be used by at "host1.example.com"; this KEY might be used by SIG(0) to
SIG(0) to authenticate transactions from this host. authenticate transactions from this host.
The zone includes a wildcard entry *.a.example.com. Note the The zone includes a wildcard entry "*.a.example.com". Note that the
*.a.example.com name is used in constructing NXT chains and the "*.a.example.com" name is used in constructing NXT chains, and that
SIG covering the *.a.example.com MX RRset has a label count of 3. the SIG covering the "*.a.example.com" MX RRset has a label count of
3.
The zone also includes two delegations. The delegation to The zone also includes two delegations. The delegation to
unsecure.example.com includes an NS RRset, glue address records, "insecure.example.com" includes an NS RRset, glue address records,
and an NXT RR, but note that only the NXT RRset is signed. The and an NXT RR, but note that only the NXT RRset is signed. The
secure.example.com delegation has provided a DS RR and note that "secure.example.com" delegation provides a DS RR, and note that only
only NXT and DS RRsets are signed. NXT and DS RRsets are signed.
3. Constructing DNS Responses 3. Serving
Unless a resolver has indicated support for DNSSEC, no changes are This section describes the behavior of a security-aware authoritative
made to the standard (non-secure) DNS response and a server simply name server. A security-aware authoritative name server MUST support
behaves as if no DNSSEC RR types were present. This helps avoid the EDNS0 [6] message size extension, MUST support a message size of
backwards compatability issues and also avoids increasing the size at least 1220 octets, and SHOULD support a message size of 4000
of (non-secure) DNS responses. Servers MUST NOT include any octets [8]. Since functions specific to security-aware recursive
DNSSEC RR types (KEY NXT SIG DS) unless the resolver has indicated name servers included components of both resolving and serving,
support for DNSSEC using one of the mechanisms described in issues specific to security-aware recursive name servers are
Section 3.1. described in Section 4.
If a resolver has indicated support for DNSSEC: Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR
DO [7] bit set to one, a security-aware authoritative name server for
a signed zone MUST include additional SIG, NXT, and DS RRs according
to the following rules:
SIG RRs that can be used to authenticate a response are o SIG RRs which can be used to authenticate a response MUST be
automatically included in the response according to the rules included in the response automatically according to the rules in
in Section 3.2. Section 3.1;
NXT RRs that can be used to provide authenticated denial of o NXT RRs which can be used to provide authenticated denial of
existence are automatically included in the response according existence MUST be included in the response automatically according
to the rules in Section 3.4. to the rules in Section 3.3;
DS RRs (or an NXT RR if DS RRs are present) are automatically o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be
included in referals according to the rules in Section 3.5. included in referrals automatically according to the rules in
Section 3.4.
Since the DS RR is the only RR type that appears only on the DNSSEC does not change the DNS zone transfer protocol. Zone transfer
upper side of a delegation, any query for the DS RR type requirements are reviewed in Section 3.6.
requires special processing as described in Section 3.6.
Section 3.7 discusses how these changes impact caching servers and A security-aware name server which receives a DNS query which does
recursive servers. 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
RRset, and MUST NOT perform any of the additional processing
described above. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.5.
3.1 Indicating Resolver Support for DNSSEC 3.1 Including SIG RRs in a Response
A resolver has indicated it supports DNSSEC if any of the When a query has the DO bit set to one, the authoritative name server
following hold: SHOULD attempt to send SIG RRs which can be used to authenticate the
RRsets in the response. Inclusion of SIG RRs in a response is
subject to the following rules:
The query explictly requests a KEY, NXT, SIG, or DS RR type. o When a signed RRset is placed in the Answer section, its SIG RRs
are also placed in the Answer section. The SIG RRs have a higher
priority for inclusion than any other RRsets which may need to be
included. If space does not permit the inclusion of these SIG
RRs, the response MUST be considered truncated, and the TC bit
MUST be set.
The query implicitly requests a KEY, NXT, SIG, or DS by o When a signed RRset is placed in the Authority section, its SIG
requesting a meta-type that matches the KEY, SIG, NXT, or DS RRs are also placed in the Authority section. The SIG RRs have a
RRs. In particular, ANY, IXFR, and AFXR queries implictly higher priority for inclusion than any other RRsets that may need
match the DNSSEC RR types and DNSSEC RRs MUST be returned in to be included. If space does not permit the inclusion of these
response to a query for ANY, IFXR, or AXFR. SIG RRs, the response MUST be considered truncated, and the TC bit
MUST be set.
The resolver has explicity requested DNSSEC by setting the o When a signed RRset is placed in the Additional section, its SIG
DNSSEC OK bit in the ENDS0 header. RRs are also placed in the Additional section. If space does not
permit the inclusion of these SIG RRs, the response MUST NOT be
considered truncated just because these SIG RRs didn't fit.
The "DNSSEC OK" (D0) bit is used for explicit notification of 3.2 Including KEY RRs In a Response
DNSSEC support. The DO bit is defined in [9] and setting the DO
bit to one in a query indicates that the resolver is able to
accept DNSSEC security RRs. The DO bit cleared (set to zero)
indicates the resolver is unprepared to handle DNSSEC security RRs
and those RRs MUST NOT be returned in the response (unless DNSSEC
security RRs are explicitly requested in the query or implicitly
requested by the use a meta-RR type such as ANY, IXFR, or AFXR).
The DO bit of the query MUST be copied in the response.
In the event a server returns a NOTIMP, FORMERR or SERVFAIL When a query has the DO bit set to one and requests the SOA or NS RRs
response to a query that has the DO bit set, the resolver SHOULD at the apex of a signed zone, then a security-aware authoritative
NOT expect DNSSEC security RRs and SHOULD retry the query without name server for that zone SHOULD return the KEY RRset with the same
EDNS0 in accordance with Section 5.3 of RFC2671 [6]. name in the Additional section. If Additional section processing
results in more data than will fit in the response message, address
glue RRs have higher priority than KEY RRs. SIG RR(s) associated
with the KEY RRset SHOULD also be included in the Additional section
(see Section 3.1).
The absence of DNSSEC data in response to a query with the DO bit Editors' note: Didn't the WG decide that DS RR removes the need
set MUST NOT be taken to mean no security information is available for Additional section processing for KEY RRs? If so, this
for that zone since the response may have be forged or may be a subsection should be deleted.
non-forged response to an altered (DO bit cleared) query.
3.2 Inclusion of SIG RRs in a Response 3.3 Including NXT RRs In a Response
If the resolver has indicated support for DNSSEC, servers SHOULD Editors' note: This whole section uses the phrase "query name
attempt to send SIG RRs that can be used to authenticate the RR exists", which is somewhat ambiguous when discussing internal
sets in the response. The inclusion of SIG RRs in a response is nodes with no RRs. We are reasonably certain that, as used here,
subject to the following rules: the phrase only refers to names which are the owner name for least
one RR. Better phrasing needed.
When an signed RRset is placed in the answer section, its SIG When a query has the DO bit set to one, security-aware authoritative
RRs are also placed in the answer section. The SIG RRs have a name servers for a signed zone MUST include NXT RRs in each of the
higher priority for inclusion than any other RRsets that may following cases:
need to be included. If space does not permit the inclusion of
these SIG RRs, the response MUST be considered truncated.
When an signed RRset is placed in the authority section, its Case 1: The query name exists, but the requested RR type does not
SIG RRs are also placed in the authority section. The SIG RRs exist.
have a higher priority for inclusion than any other RRsets that
may need to be included. If space does not permit the
inclusion of these SIG RRs, the response MUST be considered
truncated.
When an signed RRset is placed in the additional section, its Case 2: The query name does not exist, and no wildcard can be
SIG RRs are also placed in the additional section. If space expanded to answer the query.
does not permit the inclusion of these SIG RRs, the response
MUST NOT be considered truncated.
3.3 Inclusion of KEY RRs In a Response Case 3: The query name does not exist, but a wildcard can be expanded
to positively answer the query.
If the resolver has indicated support for DNSSEC and the query Note that, in each case, a set of NXT RRs is included to provide
requests the SOA or NS RRs, then a server SHOULD return the KEY authenticated denial of existence.
RRset with the same name in the additional section. If not all
additional information will fit in the response, type A and AAAA
glue RRs have higher priority than KEY RRs. The SIG RR(s)
associated with the KEY RR set SHOULD also be included in the
additional section (see including SIG RRs in Section 3.2).
3.4 Inclusion of NXT RRs In a Response NXT RRs are also included in a referral response when no DS RR is
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.
If the resolver has indicated support for DNSSEC, the server MUST 3.3.1 Case 1: Query Name Exists, but RR Type Not Present
include NXT RRs in each of the following cases:
Case 1: the query name exists, but the requested RR type does If the query name exists but the requested RR type is not present at
not exist. the name, then the NXT RR associated with the query name MUST be
included in the Authority section. Any SIG(s) associated with the
NXT RRset are also included in the Authority section (see Section
3.1) If space does not permit the inclusion of the NXT RR (or its
associate SIG RRs), the response MUST be considered truncated and the
TC bit MUST be set.
Case 2: the query name does not exist and no wildcard can be Note that, since the query name exists, no wildcard expansion applies
expanded to answer the query. to this query, and a single NXT RR suffices to prove the requested
type does not exist.
Case 3: the query name does not exist, but a wildcard can be 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches
expanded to answer the query.
NXT RRs are also included in a referal response if no DS RR is If the query name does not exist, and no wildcard expansion matches
present. In this case, the NXT RR is used to prove no DS RR the query, then the Authority section of the response MUST include
exists for the delegation and referals are discussed in detail in the following NXT RRs:
Section 3.5.
Note that in every case the NXT RRs are included to provide o An NXT RR proving that there was no exact match for the name; and
authenticated denial of existence.
3.4.1 Case 1: Query Name Exists, but RR Type Not Present o An NXT RR proving that there was no wildcard which would have
matched the query.
If the query name exists but the requested RR type is not present If space does not permit the inclusion of these NXT RRs, the response
at the name, then the NXT RR associated with the query name MUST MUST be considered truncated, and the TC bit MUST be set. Any SIG(s)
be included in the authority section. Any SIG(s) associated with associated with the NXT RRsets MUST also be included in the Authority
the NXT RRset are also included in the authority section (see section (see Section 3.1).
including SIG RRs in Section 3.2) If space does not permit the
inclusion of the NXT RR (or its associate SIG RRs), the response
MUST be considered truncated.
Note that since the query name exists, an single NXT RR suffices Editors' note: Should lack of space to include the SIGs cause the
to prove the requested type does not exist. Since the name exists packet to be considered truncated?
in the zone, an NXT RR for that name also exists and lists RR
types present at the name. Since the query name exists, no
wildcard expansion applies to this query.
3.4.2 Case 2: Query Name Does Not Exist and No Wildcard Matches Appendix A provides an algorithm which computes the appropriate NXT
RRs to prove that no wildcard matches a given query name.
If the query name does not exist and no wildcard expansion matches 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches
the query, the authority section of the response MUST include an
NXT RR that proves there was no exact match for the name and MUST
also include NXT RRs that prove no wildcard would have matched the
query. Any SIG(s) associated with the NXT RRsets are also
included in the authority section (see including SIG RRs in
Section 3.2) If space does not permit the inclusion of these NXT
RRs, the response MUST be considered truncated.
Appendix A provides an algorithm for computing the appropriate NXT If the query name does not exist, but a wildcard expansion can be
RRs that prove no wildcard matches the query name. used to return a positive match to the query, then the wildcard-
expanded answer and any SIG RRs associated with the wildcard RR MUST
be returned in the Answer section. The Authority section of the
response MUST include the following NXT RRs:
3.4.3 Case 3: Query Name Does Not Exist, but Wildcard Matches o An NXT RR which proves that there were no exact matches for the
QNAME and QTYPE; and
If the query name does not exist and a wildcard expansion matches o An NXT RR which proves that there are no closer wildcard entries
the query, then the wildcard card expanded answer (and any SIG RRs which could have been expanded to match the query.
associated with the wildcard RR) are returned in the answer
section. The authority section of the response MUST include NXT
RRs that prove there were no exact matches for the name and MUST
also include NXT RRs to prove no closer wildcard entry would have
matched this query.
Appendix A provides an algorithm for computing the appropriate NXT If space does not permit inclusion of these NXT RRs, the response
RRs that prove no closer wildcard matches the query name. 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.
3.5 Inclusion of DS RRs In a Response Editors' note: Should lack of space to include the SIGs cause the
packet to be considered truncated?
If the resolver has indicated support for DNSSEC, a server Appendix A provides an algorithm which computes the appropriate NXT
returning a referral for the delegation MUST include both the NS RRs to prove that no closer wildcard matches the query name.
RRset and DS RRset if the DS RRset exists. The NS RRset MUST be
placed before the DS RRset (and its assoicated SIG RRs).
If the resolver has indicated support for DNSSEC, a server 3.4 Including DS RRs In a Response
returning a referral for the delegation MUST include both parent
NS RRset and the parent NXT RR if the DS RRset does not exist.
The NS RRset MUST be placed before the NXT RRset (and its
assoicated SIG RRs).
This increases the size of referral messages and may cause some or When a query has the DO bit set to one, and a DS RR exists at the
all glue RRs to be omitted. If space does not permit the query name, an authoritative security-aware name server returning a
inclusion of the DS RRset (NXT RRset) and its assoicated SIG RRs, referral for the delegation MUST include both the NS RRset and also
the response MUST be considered truncated. the DS RRset and its associated SIG RR(s). The NS RRset MUST be
placed before the DS RRset and its associated SIG RRs.
3.6 Responding to Queries for DS RRs 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
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
does not exist. The NS RRset MUST be placed before the NXT RRset and
its associated SIG RR(s).
The DS record is the first resource record that appears only on This increases the size of referral messages, and may cause some or
the upper side of a delegation. In other words, the DS record for all glue RRs to be omitted. If space does not permit the inclusion
zone "example.com" is only stored in the "com" zone (the parent/ of the DS or NXT RRset and associated SIG RRs, the response MUST be
upper side of the delegation). This introduces novel server considered truncated, and the TC bit MUST be set.
behavior since the child server is authoritative for the zone, but
the zone does not contain the DS RR. A server's response to a DS
query depends on whether the server is authoritative for the
parent and/or child zones as described below.
If a server is authoritative for the parent zone at a delegation 3.5 Responding to Queries for DS RRs
point and receives a query for the DS record at the delegation
name, then the server MUST return the DS RRset from the parent
zone. This is true regardless of whether or not the server is
also authoritative for the child zone.
If the server is authoritative for the child zone at a delegation The DS record is the first resource record type which appears only on
point and is not authoritative for the parent zone, there is no the parent zone's side of a zone cut. In other words, the DS record
natural response. The child zone is not authoritative for the DS for the delegation of "example.com" is only stored in the "com" zone.
record at the zone's apex and the DS RR is only stored at the This introduces novel name server behavior, since the name server for
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
response to a DS query depends on whether the name server is
authoritative for the parent zone, the child zone, or both, as
described below.
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
MUST return the DS RRset from the parent zone. This rule applies
regardless of whether or not the name server is also authoritative
for the child zone.
If the name server is authoritative for the child zone, is not
authoritative for the parent zone, and receives a query for the DS
record at the delegated name, there is no obvious response, because
the child zone is not authoritative for the DS record at the child
zone's apex, and the authoritative DS RR is only stored at the
parent. parent.
If the server allows recursion and the RD bit is set in the If the name server allows recursion, and the RD bit is set in the
query, the server MAY perform recursion to find the DS record query, the name server MAY perform recursion to find the DS record
at the delegation point and MAY return the DS record from its for the delegated name from the parent zone, and MAY return the DS
cache. In this case, the AA bit MUST NOT be set in the record from its cache. In this case, the AA bit MUST NOT be set in
response. the response.
If the server does not perform recursion to find the DS RR, If the name server does not perform recursion to find the DS RR, the
the 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 [+ SIG(SOA) + NXT + SIG(NXT)]
In other words, an authortative child server answers as if it is In other words, a name server which is authoritative for the child
authoritative for the zone and the DS record does not exist. Note zone but not for the parent zone answers as if the DS record does not
DS-aware recursive servers will query the parent zone at exist. Note that security-aware resolvers will query the parent zone
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 "example.com" is a delegation point and a For example, suppose that "example.com" is a delegation point, and a
query for the "example.com" DS RRset is received by a server. name server receives a query for the "example.com" DS RRset.
If the server is authoritative for "com", the server MUST o If the name server is authoritative for "com", the name server
reply with the "example.com" DS RRset from the "com" zone. MUST reply with the "example.com" DS RRset from the "com" zone.
If the server is authoritative for "example.com" and is not o If the name server is authoritative for "example.com", is not
authortative for "com", the server MAY perform recursion to authoritative for "com", and the RD bit is set to one in the
find the "example.com" DS record (provided the RD bit was set query, the name server MAY perform recursion to find the
in the query). If the server does not use recursion to obtain "example.com" DS record. If the name server does not use
the DS RR, the server MUST reply as though the DS RR did not recursion to obtain the DS RR, the name server MUST reply as
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 [+ SIG(SOA) + NXT + SIG(NXT)]
3.7 Special Considerations for Recursive/Caching Servers 3.6 Responding to Queries for Type AXFR or IXFR
A DNSSEC aware recursive server MUST set the DO bit on recursive DNSSEC does not change the DNS zone transfer process. A signed zone
requests, regardless of the status of the DO bit on the initiating will contain SIG, KEY, NXT, and DS resource records, but these
resolver request. If the initiating resolver request does not records have no special meaning with respect to a zone transfer
have the DO bit set, the recursive DNSSEC-aware server MUST remove operation, and these RRs are treated as any other resource record
any DNSSEC security RRs before returning the data to the client, type.
however cached data MUST NOT be modified.
A caching server SHOULD NOT attempt to answer a query by piecing An authoritative name server is not required to verify that a zone is
together the responses it has received previous from other queries properly signed before sending or accepting a zone transfer.
that requested different names or RR types. A cache typically However, an authoritative name server MAY choose to reject the entire
does not have access to the complete zone and thus it can be zone transfer if the zone fails meets any of the signing requirements
difficult for a caching server to determine the proper SIG, NXT, described in Section Section 2. The primary objective of a zone
KEY, and DS RRs for a given a query. A caching server SHOULD transfer to ensure that all authoritative name servers have identical
cache each response single atomic entry indexed by the question copies of the zone. An authoritative name server which chooses to
(including the response and the all the assoicated DNSSEC RR perform its own zone validation MUST NOT selectively reject some RRs
types). The cache SHOULD discard the entire entry when any RR in and accept others.
the response expires.
3.8 Setting the AD and CD Bits in a Response Note that the DS RR appears only in the parental side of a
delegation, and is authoritative data in the parent zone. For
example, the DS RR for "example.com" is stored in the "com" zone (the
parent zone) rather than in the "example.com" zone (the child zone).
As with any other authoritative RRset, the "example.com" DS RR MUST
be included the "com" zone transfer.
DNSSEC allocates two new bits in the DNS message header section: Note that authoritative NXT RRs appear in both the parent and child
The CD (checking disabled) bit and the AD (authentic data) bit. zones at a delegated name, and that the NXT RRs for the delegated
These bits are defined in [9] and their use is described below. 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
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
zone transfers of the child zone.
The CD bit is set by the resolver and MUST be copied in the 3.7 Setting the AD and CD Bits in a Response
response. If the CD bit is set to one, it indicates the resolver
is willing to perform authentication and the server need not
perform authentication on the RRsets in the response.
Regardless of the CD bit, the server MAY choose to perform Editors' note: This section seems a little lost here. Perhaps we
authentication (or choose not to perform authentication) according should rearrange the section ordering slightly, or provide a
to the local server policy. The CD bit MAY be used in pointer to this subsection at the beginning of Section 3.
constructing the local server policy. If local server policy does
perform authentication, any RRsets rejected by the local
authentication policy MUST NOT be returned in a response
(regardless of the CD bit).
The AD bit is set by the server and indicates the data in the DNSSEC allocates two new bits in the DNS message header: The CD
response has been authenticated by the server, according to the (Checking Disabled) bit and the AD (Authentic Data) bit.
local server policy. The AD bit MUST NOT be set on a response
unless all of the RRsets in the answer and authority sections have The CD bit is set in query messages by the resolver, and MUST be
met the servers local authentication policy. A resolver MUST NOT copied into the response. If the CD bit is set to one, it indicates
use the AD bit unless unless it communicates with the server over that the resolver is willing to perform authentication, and thus that
the name server need not perform authentication on the RRsets in the
response.
Regardless of the setting of the CD bit, the name server MAY choose
whether or not to perform authentication according to the local name
server policy. The CD bit MAY be used in constructing the local name
server policy. If local name server policy does perform
authentication, any RRsets rejected by the local authentication
policy MUST NOT be returned in a response (regardless of the CD bit).
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
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
met the name server's local authentication policy. A resolver MUST
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 server's policy. DNSSEC best practices documents are the name server's policy.
encouraged to provide server policy recommendations.
3.9 Example DNSSEC Responses 3.8 Example DNSSEC Responses
example of A and SIG The examples in this section use the following example zone to
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 is completely signed and has a full NXT chain.
example of apex KEY example.com. SOA (...)
SIG SOA ...
NS a.example.com.
NS b.example.com.
SIG NS ...
MX 10 a.example.com
SIG MX ...
KEY ...
SIG KEY ...
NXT *.example.com.
* MX 10 a.example.com.
SIG MX ...
NXT a.example.com.
a A 10.10.10.1
SIG A ...
NXT b.example.com.
b A 10.10.10.2
SIG A ...
NXT c.example.com.
c CNAME a.example.com.
SIG CNAME
NXT sub.example.com.
sub NS ns.sub.example.com.
SIG NS
DS ...
SIG DS
NXT *.example.com.
ns.sub A 10.10.10.3
sub-nosig NS ns.sub-nosig.example.com.
NXT example.com.
ns.sub-nosig A 10.10.10.4
A query to the authoritative name server for this zone for
QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:
example of signed delegation (DS) and unsigned delegation (NXT) Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000
QUERY:
c.example.com. IN A
ANSWER:
c.example.com. IN A a.example.com
IN SIG CNAME
a.example.com. IN A 10.10.10.1
IN SIG A
AUTHORITY:
example.com. IN NS a.example.com.
IN NS b.example.com.
IN SIG NS ...
ADDITIONAL:
a.example.com. IN A 10.10.10.1
IN SIG A ...
b.example.com. IN A 10.10.10.2
IN SIG A ...
example.com. IN KEY ...
IN SIG KEY ...
example of auth denial (includes NXT for wildcards) A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
4. Authenticating DNS Responses 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
with the hash of the "sub.example.com" zone key.
In order to use DNSSEC RRs for authentication, a resolver requires Flags: QR=1, AA=1, RCODE=0 (NOERROR)
some intial authenticated KEY RR. The process for obtaining and EDNS: DO=1, size=4000
authenticating this initial KEY RR is achieved via some external QUERY:
mechanism. For example, a resolver could use some off-line www.sub.example.com. IN A
authenticated exchange to obtain a zone's KEY RR or obtain a DS RR ANSWER:
that identifies and authenticates a zone's KEY RR. In the ;; empty
remainder of this section assumes the resolver has used some AUTHORITY:
unspecified off-line mechanism and obtained an initial set of sub.example.com. IN NS ns.sub.example.com.
IN DS ...
IN SIG DS ...
ADDITIONAL:
ns.sub.example.com. IN A 10.10.10.3
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
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
RRs are present in responses from "sub-nosig.example.com" name
servers, the resolver will not be able to construct a authentication
chain, since there is a break between "sub-nosig.example.com" and its
delegating parent zone.
Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000
QUERY:
www.sub-nosig.example.com. IN A
ANSWER:
;; empty
AUTHORITY:
sub-nosig.example.com. IN NS ns.sub-nosig.example.com.
IN NXT ;; (DS bit not set)
IN SIG NXT ...
ADDITIONAL:
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
error, because the name does not exist and is not covered by wildcard
expansion. Therefore, the name server must present proof that the
name does not exist, and that no wildcard expansion is present which
could have been used to answer the query.
Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN)
EDNS: DO=1, size=4000
QUERY:
f.example.com. IN A
ANSWER:
;; empty
AUTHORITY:
example.com. IN SOA ...
IN SIG SOA ...
c.example.com. IN NXT sub.example.com. ...
IN SIG NXT ...
*.example.com. IN NXT a.example.com. ...
IN SIG NXT ...
ADDITIONAL:
example.com. IN KEY ...
IN SIG KEY ...
A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
RR synthesized via wildcard expansion. The name server must prove
that no exact match exists.
Flags: QR=1, AA=1, RCODE=0 (NOERROR)
EDNS: DO=1, size=4000
QUERY:
f.example.com. IN MX
ANSWER:
f.example.com. IN MX 10 a.example.com.
IN SIG MX ...
AUTHORITY:
example.com. IN NS a.example.com.
IN NS b.example.com.
IN SIG NS ...
c.example.com. IN NXT sub.example.com.
IN SIG NXT ...
ADDITIONAL:
a.example.com. IN A 10.10.10.1
IN SIG A ...
b.example.com. IN A 10.10.10.2
IN SIG A ...
example.com. IN KEY ...
IN SIG KEY ...
If these responses came from a recursive name server which had all of
the necessary RRsets in its cache instead of from an authoritative
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
if) all the RRsets in a response passed the security policy checks of
the recursive name server.
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
security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements. Functions
specific to security-aware recursive name servers are described in a
separate subsection.
A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with
the DO [7] bit set to one when sending queries.
A security-aware resolver MUST support a message size of at least
1220 octets, SHOULD support a message size of 4000 octets, and MUST
advertise the supported message size using the "sender's UDP payload
size" field in the EDNS OPT pseudo-RR. A security-aware resolver
MUST handle fragmented UDP packets correctly regardless of whether
any such fragmented packets were received via IPv4 or IPv6. Please
see [8] for discussion of these requirements.
A security-aware resolver MUST support the signature verification
mechanisms described in Section 5, and MUST apply them to every
received response except when:
o The security-aware resolver is part of a security-aware recursive
name server, and the response is the result of recursion on behalf
of a query received with the CD bit set;
o The response is the result of a query generated directly via some
form of application interface which instructed the security-aware
resolver not to perform validation for this query; or
o Validation for this query has been disabled by local policy.
A security-aware resolver's support for signature verification MUST
include support for verification of wildcard owner names.
A security-aware resolver MUST attempt to retrieve missing DS, KEY,
or SIG RRs via explicit queries if the resolver needs these RRs in
order to perform signature verification.
A security-aware resolver MUST attempt to retrieve missing a NXT RR
which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NXT
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 resolver does know the name of the missing NXT RR, and must
therefore attempt to retrieve 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
security-aware resolver must be able to distinguish between three
cases:
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.
In this case, the RRset should be signed, and is subject to
signature validation as described above.
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
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
RRset may or may not be signed, but the resolver will not be able
to verify the signature.
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
able to obtain the necessary DNSSEC RRs. This can occur due when
the security-aware resolver is not able to contact security-aware
name servers for the relevant zones.
A security-aware resolver MUST be capable of being preconfigured with
at least one trusted public key, and SHOULD be capable of being
preconfigured with multiple trusted public keys. Since a security-
aware resolver will not be able to validate signatures without such a
preconfigured trusted key, the resolver SHOULD have 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
atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
single atomic entry containing the entire answer, including the named
RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire.
Editors' note: This is implementation advice which came out of
discussions at various workshops and investigations into possible
implementation issues with the (as yet unsettled) opt-in proposal.
All of this advice has been discussed in WG meetings, and as far
as the editors know these recommendations are not controversial,
but it is up to the WG to decide whether this sort of
implementation advice belongs in this document.
4.1 Recursive Name Servers
As explained in [9], a security-aware recursive name server is an
entity which acts in both the security-aware name server and
security-aware resolver roles. This section uses the terms "name
server side" and "resolver side" to refer to the code within a
security-aware recursive name server which implements the security-
aware name server role and the code which implements the security-
aware 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
query by piecing together cached data it received in response to
previous queries that requested different QNAMEs, QTYPEs, or
QCLASSes. A security-aware recursive name server SHOULD NOT use NXT
RRs from one negative response to synthesize a response for a
different query. A security-aware recursive name server SHOULD NOT
use a previous wildcard expansion to generate a response to a
different 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
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
whether or not it is required to verify the response data it returns
to the name server side.
Editors' note: What should a security-aware recursive name server
do if it receives a query with CD=1 and DO=0?
4.2 Stub resolvers
A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR
with the DO [7] bit set to one when sending queries.
A security-aware stub resolver MUST support a message size of at
least 1220 octets, SHOULD support a message size of 4000 octets, and
MUST advertise the supported message size using the "sender's UDP
payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
resolver MUST handle fragmented UDP packets correctly regardless of
whether any such fragmented packets were received via IPv4 or IPv6.
Please see [8] for discussion of these requirements.
A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they
contain DNSSEC RRs. A security-aware stub resolver MAY include the
DNSSEC RRs returned by a security-aware recursive name server as part
of the data that it the stub resolver hands back to the application
which invoked it, but is not required to do so.
A security-aware stub resolver SHOULD NOT set the CD bit when sending
queries, since, by definition, a security-aware stub resolver does
not validate signatures and thus depends on the security-aware
recursive name server to perform validation on its behalf.
Editors' note: Should this SHOULD NOT be a MUST NOT?
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
In order to use DNSSEC RRs for authentication, a security-aware
resolver requires preconfigured knowledge of at least one
authenticated KEY RR. The process for obtaining and authenticating
this initial KEY RR is achieved via some external mechanism. For
example, a resolver could use some off-line authenticated exchange to
obtain a zone's KEY RR or obtain a DS RR that identifies and
authenticates a zone's KEY RR. The remainder of this section assumes
that the resolver has somehow obtained an initial set of
authenticated KEY RRs. authenticated KEY RRs.
An initial KEY RR can be used to authenticate a zone's apex KEY An initial KEY RR can be used to authenticate a zone's apex KEY
RRset. To authenticate an apex KEY RRset using an initial key, RRset. To authenticate an apex KEY RRset using an initial key, the
the resolver MUST resolver MUST:
1. Verify the initial KEY RR appears in the apex KEY RRset and 1. Verify that the initial KEY RR appears in the apex KEY RRset, and
verify the KEY RR has the Zone Key Flag (KEY RDATA bit 7) set verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
to 1. set to one.
2. Verify there is some SIG RR that covers the apex KEY RRset 2. Verify that there is some SIG RR which covers the apex KEY RRset,
and the combination of the SIG RR and the initial KEY RR and that the combination of the SIG RR and the initial KEY RR
authenticate the KEY RRset. The process for using a SIG RR to authenticates the KEY RRset. The process for using a SIG RR to
authenticate an RRset is described in Section 4.2. authenticate an RRset is described in Section 5.2.
Once the apex KEY RRset has been authenticated using an initial Once the resolver has authenticated the apex KEY RRset using an
KEY RR, delegations from that zone can be authenticated using DS initial KEY RR, delegations from that zone can be authenticated using
RRs. This allows a resolver to start from an initial externally DS RRs. This allows a resolver to start from an initial key, and use
authenticated key, and use DS RRsets to recursively proceed down DS RRsets to proceed recursively down the DNS tree obtaining other
the DNS tree to obtain other apex KEY RRsets. If the resolver was apex KEY RRsets. If the resolver were preconfigured with a root KEY
initially configured with a root KEY RR and if every delegation RR, and if every delegation had a DS RR associated with it, then the
had a DS RR assoicated with it, the resolver could obtain any apex resolver could obtain any apex KEY RRset. The process of using DS
KEY RRset. The process of using DS RRs to authentic a referal is RRs to authenticate referrals is described in Section 5.1.
described in Section 4.1.
Once a zones apex KEY RRset has been authenticated, Section 4.2 Once the resolver has authenticated a zone's apex KEY RRset, Section
shows how the resolver can use KEY RRs in the apex KEY RRset and 5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and
SIG RRs from the zone to authenticate any other RRsets in the SIG RRs from the zone to authenticate any other RRsets in the zone.
zone. Section 4.3 shows how the resolver can use authenticated Section 5.3 shows how the resolver can use authenticated NXT RRsets
NXT RRsets from the zone to prove an RRset is not present in the from the zone to prove that an RRset is not present in the zone.
zone.
If the resolver has indicated support for DNSSEC, DNSSEC aware When a resolver indicates support for DNSSEC, a security-aware name
servers SHOULD attempt to provide the necessary KEY, SIG, NXT, and server should attempt to provide the necessary KEY, SIG, NXT, and DS
DS RRets in a response (see Section 3). However, a response that RRsets in a response (see Section 3). However, a security-aware
lacks the approriate DNSSEC RRs may result from configuration resolver may still receive a response which that lacks the
issues such as a non-DNSSEC aware cache that removes or fails appropriate DNSSEC RRs, whether due to configuration issues such as a
request DNSSEC RRs or may result from an intentional attack where security-oblivious recursive name server which accidently interfere
an adversary forges a response, strips DNSSEC RRs from a response with DNSSEC RRs or due to a deliberate attack in which an adversary
forges, or modifies the query so DNSSEC RRs appear not to be forges a response, strips DNSSEC RRs from a response, or modifies a
requested. The absence of DNSSEC data in response MUST NOT be query so that DNSSEC RRs appear not to be requested. The absence of
taken to mean that no authentication information is available. DNSSEC data in a response MUST NOT by itself be taken as an
indication that no authentication information exists.
A resolver SHOULD expect authentication information from signed A resolver SHOULD expect authentication information from signed
zones. A SHOULD believe a zone is signed if the resolver has been zones. A resolver SHOULD believe that a zone is signed if the
configured with public key information for the zone or if the resolver has been configured with public key information for the
zone's parent is signed and the delegation at the parent contains zone, or if the zone's parent is signed and the delegation from the
a DS RRset. DNSSEC best practices documents are encouraged to parent contains a DS RRset.
provide guidance on how a resolver responds if DNSSEC RRs are
expected, but can not be obtained. DNSSEC best practices
documents are also are encouraged to provide guidance on how a
resolver responds if the expected DNSSEC RRs are obtained but
appear invalid (e.g. all SIG RRs are expired).
4.1 Authenticating Referrals 5.1 Authenticating Referrals
Once the apex KEY RRset for a (parent) zone has been Once the apex KEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate a referal to authenticated, DS RRsets can be used to authenticate the delegation
a delegation (child zone). A DS RR identifies a KEY RR in the to a signed child zone. A DS RR identifies a KEY RR in the child
child's apex KEY RRset. The DS RR contains a digest of the zone's apex KEY RRset, and contains a cryptographic digest of the
child's KEY RR and a strong cryptographic digest algorithm ensures child zone's KEY RR. A strong cryptographic digest algorithm ensures
that an adversary can not easily generate a KEY RR that matches that an adversary can not easily generate a KEY RR that matches the
the digest. Thus authenticating the digest allows a resolver to digest. Thus, authenticating the digest allows a resolver to
safely declare the matching child KEY RR to is also authentic. authenticate the matching KEY RR. The resolver can then use this
This child KEY RR is then used to authenticate the entire child child KEY RR to authenticate the entire child apex KEY RRset.
apex KEY RRset.
Given a DS RR for a delegation (child zone), the delegation's Given a DS RR for a delegation, the child zone's apex KEY RRset can
(child zone's) apex KEY RRset is considered to be authentic if all be authenticated if all of the following hold:
of the following hold:
The DS RR has been authenticated using some KEY RR in the o The DS RR has been authenticated using some KEY RR in the parent's
parent's apex KEY RRset (see Section 4.2). apex KEY RRset (see Section 5.2);
The Algorithm, Key Tag, and Digest fields in the DS RR match o The Algorithm and Key Tag in the DS RR match the Algorithm field
the algorithm, key tag, and digest of a KEY RR present in the and the key tag of a KEY RR in the child zone's apex KEY RRset
child's apex KEY RRset. which, when hashed using the digest algorithm specified in the DS
RR's Digest Type field, results in a digest value which matches
the Digest field of the DS RR; and
The matching KEY RR in the child zone has the Zone Flag bit set o The matching KEY RR in the child zone has the Zone Flag bit set to
to one, the corresponding private key has signed the child apex one, the corresponding private key has signed the child zone's
KEY RRset, and the resulting SIG RR authenticates the child's apex KEY RRset, and the resulting SIG RR authenticates the child
apex KEY RRset. zone's apex KEY RRset.
If the referal from the parent zone did not contain a DS RRset, If the referral from the parent zone did not contain a DS RRset, the
the response SHOULD have included an NXT RRset that proves no DS response should have included a signed NXT RRset proving that no DS
RRset exists for the delegation name (see Section 3.5). A RRset exists for the delegated name (see Section 3.4). A security-
resolver SHOULD send the parent a query for the DS RRset if aware resolver MUST send the parent a query for the DS RRset if the
neither a DS RRset or NXT RRset is included in the referal. referral includes neither a DS RRset nor a NXT RRset proving the
nonexistence of the DS RRset (see Section 4).
If the resolver authenticates an NXT RRset that proves no DS RRset If the resolver authenticates an NXT RRset which proves that no DS
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 leading from the parent to the child. If the resolver has an initial
initial KEY RR that belongs to the child zone (or any delegation KEY RR which belongs to the child zone or to any delegation below the
below the child zone), this initial KEY RR MAY be used to re- child zone, this initial KEY RR MAY be used to re-establish an
establish an authentication path. If no such initial KEY RR authentication path. If no such initial KEY RR exists, the resolver
exists, the resolver can not authenticate RRsets at or below the can not authenticate RRsets at or below the child zone.
child zone.
Note for a signed delegation there are two NXT RRs associated with Note that, for a signed delegation, there are two NXT RRs associated
the delegation name. One NXT RR resides at the parent can be used with the delegated name. One NXT RR resides in the parent zone, and
to prove whether a DS RRset exists for the delegation name. A can be used to prove whether a DS RRset exists for the delegated
second NXT RR resides at the child zone and identifies which name. The second NXT RR resides in the child zone, and identifies
RRsets are present at the apex in the child zone. The parent NXT which RRsets are present at the apex of the child zone. The parent
RR and child NXT RR can always be distinguished since the only the NXT RR and child NXT RR can always be distinguished, since the SOA
child NXT RR will specify an SOA RR set exists at the name. A bit will be set in the child NXT RR and clear in the parent NXT RR.
resolver MUST only use the parent NXT RR when proving a DS RRset A security-aware resolver MUST use the parent NXT RR when attempting
does not exist. to prove that a DS RRset does not exist.
4.2 Authenticating an RRSet Using a SIG RR 5.2 Authenticating an RRSet Using a SIG RR
A SIG RR (and its corresponding KEY RR) is used by a resolver to A resolver can use a SIG RR and its corresponding KEY RR to attempt
authentic an RRset. The SIG RR is first checked to verify that it to authenticate RRsets. The resolver first checks the SIG RR to
covers the RRset, has a valid time interval, and identifies a verify that it covers the RRset, has a valid time interval, and
valid KEY RR. The signed data is then constructed by appending identifies a valid KEY RR. The resolver then constructs the
SIG RDATA (excluding the Signature Field) with the covered RRset canonical form of the signed data by appending the SIG RDATA
(in canonical form). Finally, the public key and signature and (excluding the Signature Field) with the canonical form of the
used to authenticate the signed data. Section 4.2.1, Section covered RRset. Finally, resolver uses the public key and signature
4.2.2, and Section 4.2.3 describe each step in detail. to authenticate the signed data. Section 5.2.1, Section 5.2.2, and
Section 5.2.3 describe each step in detail.
4.2.1 Checking the SIG RR Validity 5.2.1 Checking the SIG RR Validity
An SIG RR can be used to authenicate an RRset if all of the A security-aware resolver can use a SIG RR to authenticate an RRset
following conditions hold: if all of the following conditions hold:
The SIG RR and the RRset MUST have the same owner name and same o The SIG RR and the RRset MUST have the same owner name and the
class. same class;
The SIG RR's Signer's Name field MUST be the name of the zone o The SIG RR's Signer's Name field MUST be the name of the zone that
that contains the RRset. contains the RRset;
The SIG RR's Type Covered field MUST equal the RRset's type. o The SIG RR's Type Covered field MUST equal the RRset's type;
The number of labels in the RRset owner name MUST be greater o The number of labels in the RRset owner name MUST be greater than
than or equal to the value in the SIG RR's Labels field. or equal to the value in the SIG RR's Labels field;
The resolver's current time MUST be less than or equal to the o The resolver's notion of the current time MUST be less than or
time listed in the SIG RR's Expiration field. equal to the time listed in the SIG RR's Expiration field;
The resolver's current time MUST be greater than or equal to o The resolver's notion of the current time MUST be greater than or
the time listed in the SIG RR's Inception field. equal to the time listed in the SIG RR's Inception field;
The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST o The SIG 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 KEY RR in
the zone's apex KEY RRset. the zone's apex KEY RRset;
The matching KEY RR MUST be present in the zone's apex KEY o The matching KEY RR MUST be present in the zone's apex KEY RRset,
RRset and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one.
set to 1.
It is possible that more than one KEY RR matches the conditions It is possible for more than one KEY RR to match the conditions
above. In this case, the resolver can not determine which KEY RR above. In this case, the resolver can not predetermine which KEY RR
is used to authenticate the signature and the resolver MUST try to use to authenticate the signature, MUST try each matching KEY RR
each matching KEY RR until the resolver has either validated the until the resolver has either validated the signature or has run out
signature or all matching KEY RRs have failed. of matching keys to try.
Note that the authentication process is only meaningful if the Note that this authentication process is only meaningful if the
resolver first authenticates a KEY RR before using it to validate resolver authenticates the KEY RR before using it to validate
a signature. The matching KEY RR is considered to be authentic if signatures. The matching KEY RR is considered to be authentic if:
The apex KEY RRset containing the KEY RR is considered o The apex KEY RRset containing the KEY RR is considered authentic;
authentic or
The RRset covered by the SIG RR is the apex KEY RRset itself o The RRset covered by the SIG RR is the apex KEY RRset itself, and
and the KEY RR matches an authenticated DS RR from the parent the KEY RR either matches an authenticated DS RR from the parent
zone or matches some initial KEY RR/DS RR that is known to be zone or matches a DS RR or KEY RR which the resolver has been
authentic. preconfigured to believe to be authentic.
4.2.2 Reconstructing the Signed Data 5.2.2 Reconstructing the Signed Data
Once the SIG RR has met the validity requirements described in Once the SIG RR has met the validity requirements described in
Section 4.2.1, the original signed data needs to be reconstructed. Section 5.2.1, the resolver needs to reconstruct the original signed
The original signed data includes SIG RDATA (excluding the data. The original signed data includes SIG RDATA (excluding the
Signature field) and the RRset in cannonical order and might Signature field) and the canonical form of the RRset. Aside from
differ from the RRset received in the DNS response due to name being ordered, the canonical form of the RRset might also differ from
compression, TTL decrementing by a cache, or the RRset may be the the received RRset due to DNS name compression, decremented TTLs, or
result of wildcard expansion. The following algorithm is used to wildcard expansion. The resolver should use the following to
reconstuct the original signed data: reconstruct the original signed data:
signed_data = SIG_RDATA | RR(1) | RR(2)... where signed_data = SIG_RDATA | RR(1) | RR(2)... where
"|" denotes append "|" denotes concatenation
SIG_RDATA is the wire format of the SIG RDATA fields with SIG_RDATA is the wire format of the SIG RDATA fields with
the Signature field excluded. the Signature field excluded and the Signer's Name in
the Signer's Name in cannonical form. 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 SIG Original TTL field
All names in the RDATA field are in canonical form All names in the RDATA field are in canonical form
skipping to change at page 21, line 20 skipping to change at page 29, line 14
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 SIG 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 cannonical 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 sig_labels = the value of the SIG 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 sig_labels = fqdn_labels,
name = fqdn name = fqdn
if sig_labels < fqdn_labels, if sig_labels < fqdn_labels,
name = "*." | the leftmost sig_label labels of the fqdn name = "*." | the leftmost sig_label labels of the
fqdn
if sig_labels > fqdn if sig_labels > fqdn
the SIG 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 RRset. checks and MUST NOT be used to authenticate this
RRset.
An example of original name calculation is given in Section 4.4.1. Editors' note: The algorithm above needs to be cross-checked very
The canonical form for names and RRsets is defined in [9]. carefully against the definitions in [10].
NXT RRsets present at a delegaion name require special processing. Section 5.4.1 gives an example of original name calculation. The
There are two distinct NXT RRsets associated with a signed canonical forms for names and RRsets are defined in [10].
delegation name. One NXT RRset resides at the parent and
specifies which RRset are present at the parent. A second NXT
RRset resides 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 always be distinguished since only the child
NXT RRs will specify an SOA RR set exists at the name. When
constructing the original NXT RRset, the NXT RRs MUST NOT be
combined with NXT RRs from the child (and vice versa).
4.2.3 Checking the Signature NXT RRsets at a delegation boundary require special processing.
There are two distinct NXT RRsets associated with a signed delegated
name. One NXT RRset resides in the parent zone, and specifies which
RRset are present at the parent zone. The second NXT RRset resides
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
always be distinguished since only the child NXT RRs will specify an
SOA RRset exists at the name. When reconstructing the original NXT
RRset for the delegation from the parent zone, the NXT RRs MUST NOT
be combined with NXT RRs from the child zone, and when reconstructing
the original NXT RRset for the apex of the child zone, the NXT RRs
MUST NOT be combined with NXT RRs from the parent zone.
Once the SIG RR has met the validity requirements described in Note also that each of the two NXT RRsets at a delegation point has a
Section 4.2.1 and the original signed data has been reconstructed corresponding SIG RR with an owner name matching the delegated name,
as described in Section 4.2.2, the cryptographic signature is used and each of these SIG RRs is authoritative data associated with the
to authenticate the signed data (and thus authenticate the RRset). same zone which contains the corresponding NXT RRset. If necessary,
a resolver can tell these SIG RRs apart by checking the Signer's Name
field.
5.2.3 Checking the Signature
Once the resolver has validated the SIG RR as described in Section
5.2.1 and reconstructed the original signed data as described in
Section 5.2.2, the resolver can attempt to use the cryptographic
signature to authenticate the signed data, and thus (finally!)
authenticate the RRset.
The Algorithm field in the SIG RR identifies the cryptographic The Algorithm field in the SIG RR identifies the cryptographic
algorithm used to validate 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 public key contained in the Signature field of the SIG RDATA, and the public key
used to authenticate this signature is contained in the Public Key to used generate the signature is contained in the Public Key field
field of the matching KEY RR(s) (found in Section 4.2.1). [9] of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a
provides a list of algorithm types and provides pointers to the list of algorithm types, and provides pointers to the documents that
documents that define each algorithm's use. define each algorithm's use.
Note it is possible that more than one KEY RR matches the Note that it is possible for more than one KEY RR to match the
conditions in Section 4.2.1. In this case, the resolver can not conditions in Section 5.2.1. In this case, the resolver can only
determine which KEY RR is used to authenticate the signature and determine which KEY RR by trying each matching key until the resolver
the resolver MUST try each matching KEY RR until the resolver has either succeeds in validating the signature or runs out of keys to
either validated the signature or all matching KEY RRs have try.
failed.
If the SIG RR Labels field is not equal to the number of labels in If the Labels field of the SIG RR is not equal to the number of
the RRsets fully qualified domain name, then the RRset is a result labels in the RRset's fully qualified owner name, then the RRset is
of wildcard expansion. The resolver MUST verify the wildcard was either invalid or the result of wildcard expansion. The resolver
applied properly before the RRset is considered authentic. The MUST verify that wildcard expansion was applied properly before
RRset and SIG RR MUST be discarded if the resolver proves the considering the RRset to be authentic. Section 5.2.4 describes how
wildcard was applied improperly. Section 4.2.4 describes how to to determine whether a wildcard was applied properly.
determine whether a wildcard was applied properly.
If other SIG RRs also cover this SIG RR, the local resolver If other SIG RRs also cover this SIG RR, the local resolver security
security policy determines whether these SIG RRs need to be tested policy determines whether the resolver also needs to test these SIG
and determines how to resolve conflicts if these SIG RRs lead to RRs, and determines how to resolve conflicts if these SIG RRs lead to
differing results. differing results.
If the RRset is accepted as authentic, the SIG RR TTL and the TTL If the resolver accepts the RRset as authentic, the resolver MUST set
of each RR in the authenticated RRset MUST be set to the minimum the SIG RR's TTL and the TTL of each RR in the authenticated RRset to
of the minimum of:
the RR TTL received in the response
the value in the SIG RRs Original TTL field o The RRset's TTL as received in the response;
4.2.4 Authenticating Wildcard Expanded RRset
If a SIG RR's fully qualified domain name does not equal the o The SIG RR's TTL as received in the response; and
Labels field in the SIG RDATA, then SIG RR (and its covered RRset)
were created as a result of wildcard expansion. Once the
signature has been verified as described in Section 4.2,
additional steps are required to verify 1) no intermediate name
cancels the use of the wildcard and 2) no more specific wildcard
name could have been used to create this RRset.
Intermediate label names can be formed from the fully qualified o The value in the SIG RR's Original TTL field.
domain name by removing the rightmost labels and are used to prove
the wildcard was used properly. For example,
"www.a.b.c.example.com." has intermediate names of
"a.b.c.example.com", "b.c.example.com", "c.example.com",
"example.com", and "com". For each intermediate label name whose
label count is greater the SIG RR Labels field, the resolver MUST
obtain and authenticate NXT RRs that prove:
the intermediate label name does not exist (otherwise this 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response
label would cancel the wildcard)
the name "*.intermediate_label_name" does not exist (otherwise If the number of labels in an RRset's fully qualified domain name is
this wildcard would take precedence) greater than the Labels field in the covering SIG RDATA, then the
RRset and its covering SIG RR were created as a result of wildcard
expansion. Once the resolver has verified the signature as described
in Section 5.2, the resolver must take additional steps to verify the
non-existence of an exact match or closer wildcard match for the
query. Section 5.3 discusses these steps.
Note the response SHOULD include all NXT RRs needed to the Note that the response received by the resolver should include all
authenticate the response (see Section Section 3.4). NXT RRs needed to authenticate the response (see Section 3.3).
4.3 Authenticated Denial of Existence 5.3 Authenticated Denial of Existence
A resolver can use authenticated NXT RRs to prove that an RRset is A resolver can use authenticated NXT RRs to prove that an RRset is
not present in a signed zone. NXT RRsets SHOULD be automatically not present in a signed zone. Security-aware name servers should
included in the response, provided the zone is signed and the automatically include any necessary NXT RRs for signed zones in their
resolver has indicated support for DNSSEC. NXT RRsets are responses to security-aware resolvers.
authenticated according to standard RRset authentication rules
described in Section 4.2 and are applied as follows:
If the requested RR name matches the owner name of an Security-aware resolvers MUST first authenticate NXT RRsets according
authenticated NXT RR, then all RR types present at that owner to the standard RRset authentication rules described in Section 5.2,
name MUST be listed in the NXT RR's Type Bit Map field. A then apply the NXT RRsets as follows:
resolver can prove the requested RR type does not exist by
presenting checking for the RR type in NXT RR's Type Bit Map
field. Also, since owner name exists in the zone, no wildcard
expansion could be used to match the requested RR owner name and
type.
If the requested RR name logically appears after an authenticated o If the requested RR name matches the owner name of an
NXT RR owner name and logically appears before the name listed in authenticated NXT RR, then the NXT RR's type bit map field lists
that NXT RR's Next Domain Name field, then the requested RR name all RR types present at that owner name, and a resolver can prove
is not present in the zone. However, it is possible a wildcard that the requested RR type does not exist by checking for the RR
could be used to match the requested RR owner name and type type in the bit map. Since the existence of the authenticated NXT
RR proves that the owner name exists in the zone, wildcard
expansion could not have been used to match the requested RR owner
name and type.
Intermediate label names are used to prove no wildcard matches the o If the requested RR name would appear after an authenticated NXT
requested name. Intermediate label names are formed from the RR owner name and before the name listed in that NXT RR's Next
requested RR's fully qualified domain name by removing the Domain Name field according to the canonical DNS name order
rightmost labels from the name. For example, defined in [10], then no exact match for the requested RR name
"www.a.b.c.example.com." has intermediate names of exists in the zone. However, it is possible that a wildcard could
"a.b.c.example.com", "b.c.example.com", "c.example.com", be used to match the requested RR owner name and type, so proving
"example.com", and "com". To prove no wildcard matches, the that the requested RRset does not exist also requires proving that
resolver MUST start with the longest intermediate label name prove no possible wildcard exists which could have been used to generate
that: a positive response.
No wildcard exists at this intermediate label name. In other To prove non-existence of an RRset, the resolver must be able to
words, there is an authenticated NXT RR such the NXT RR's owner verify both that the queried RRset does not exist and that no
name logically appears before "*.intermediate_label_name" and relevant wildcard RRset exists. Proving this may require more than
the NXT RR's Next Domain field appears logically after one NXT RRset from the zone. If the complete set of necessary NXT
"*.intermediate_lable_name". RRsets is not present in a response (perhaps due to truncation), then
a security-aware resolver MUST resend the query in order to attempt
to obtain the full collection of NXT RRs necessary to verify non-
existence of the requested RRset. As with all DNS operations,
however, the resolver MUST bound the work it puts into answering any
particular query.
The resolver MUST continue testing intermediate label names until 5.4 Example
(in order of decreasing label count) until the intermediate label
name matches an authenticated NXT RR's owner name. Note that this
is guaranteed to occur since at some point the intermediate label
will equal the zone name and NXT RR exists at the zone name.
4.4 Example 5.4.1 Example of Re-Constructing the Original Owner Name
4.4.1 Example of Re-Constructing the Original Name 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".
This fully qualified domain name has 6 labels: "www", "a", "b", "c",
"example", and "com". What name the resolver should use when
reconstructing the original signed data depends on the value of the
SIG RR's Labels field.
Suppose the RRset owner name received in a response is If the value of the SIG RR's Labels field is 6, then the SIG RR's
"www.a.b.c.example.com.". This fully qualified domain name has 6 Labels field matches the number of labels in the owner name, and the
labels: "www", "a", "b", "c", "example", and "com". The name resolver should assume that this RRset is not the result of wildcard
used in reconstructing the original signed data depends on the expansion. The resolver should therefore use "www.a.b.c.example.com"
value of the SIG Labels. as the owner name when reconstructing the original signed data for
the signature check.
If the SIG Labels field is 6, then the SIG Labels field equals the If the value of the SIG RR's Labels field is less than 6, then the
number of labels in the RRsets fully qualified domain name. SIG RR's Labels count is less than the number of labels in the
Wildcard expansion was not used to construct this RRset and the RRset's owner name, and the resolver should assume that this RRset is
name "www.a.b.c.example.com." is used to construct the original the result of wildcard expansion. The resolver should therefore
signed data. reconstruct the original owner name by replacing the labels which
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
should reconstruct the original owner name by prepending "*." to the
last 3 labels of the owner name of the answer RRset. Thus, the
resolver should use "*.c.example.com" as the owner name when
reconstructing the original signed data.
If the SIG Labels field is 3, then the SIG Labels field is If the value of the SIG RR's Labels field is greater than 6, then
strictly less than number of labels in the RRset's fully qualified this SIG RR cannot possibly be valid for the answer RRset, and there
domain name. Wildcard expansion was used to construct this RRset is no point in attempting to validate the signature.
and the original wildcard owner name is constructed by appending
"*." to the last 3 labels in the owner name. The name
"*.c.example.com." is is used to construct the original signed
data.
authentication process for www.example.com starting from a initial 5.4.2 Examples of Authenticating a Response
root key
authentication process for non-existent www.a.b.c.example.com Editors' note: Eventually this will be an example of the
starting from a initial root key authentication process for "www.example.com", starting from an
5. IANA Considerations initial root key.
Editors' note: Eventually this will be an example of the
authentication process for non-existent "www.a.b.c.example.com",
starting from an initial root key.
6. IANA Considerations
This document introduces no IANA considerations. This document introduces no IANA considerations.
[9] contains a complete review of the IANA considerations [10] contains a complete review of the IANA considerations introduced
introduced by the DNSSEC. by DNSSEC.
6. Security Considerations Editors' note: This may not be true anymore, since the AD and CD
bit definitions are now in this document rather than in [10].
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 key cryptography to sign and authenticate DNS resource record sets.
sets.
At this time, at least two substantial elements of the DNSSEC At this time, at least two substantial elements of the DNSSEC
specification have yet to be decided by the working group. The specification have yet to be decided by the working group. The open
open opt-in issue would change elements such as what RRsets must opt-in issue would change elements such as what RRsets must be
be signed, would impact how wildcards are used, and would replace signed, would impact how wildcards are used, and would replace
authenticated denial of existence with authenticated denial of authenticated denial of existence with authenticated denial of
security. The ad-bit is also undecided. The ad bit (as security. Handling of the AD bit is also undecided. The AD bit (as
currently defined) is used to indicate the security status of currently defined) is used to indicate the security status of RRsets
RRsets in the response. These items clearly raise security in the response. These items clearly raise security considerations
considerations and will addressed here as these issues are and will be addressed here as these issues are resolved in the
resolved in the working group. working group.
DNSSEC introduces a number of denial of service issues. These DNSSEC introduces a number of denial of service issues. These issues
issues will also be addressed in the revised version of the will also be addressed in a future version of these security
security considerations. considerations.
7. Acknowledgements Please see [9] for general security considerations related to DNSSEC.
This document was created from the input and ideas of several 8. Acknowledgements
members 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 comments and suggestions received during the
revision of these security extension specifications.
References This document was created from the input and ideas of several members
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 comments and suggestions received during the revision of these
security extension specifications.
[1] Mockapetris, P., "Domain names - concepts and facilities", Normative References
STD 13, RFC 1034, November 1987.
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [2] 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, [3] 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 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Requirement Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Elz, R. and R. Bush, "Clarifications to the DNS [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
Specification", RFC 2181, July 1997. RFC 2181, July 1997.
[6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[7] Eastlake, D., "DNS Request and Transaction Signatures ( [7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
SIG(0)s)", RFC 2931, September 2000. December 2001.
[8] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC [8] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
Intro", October 2002. message size requirements", RFC 3226, December 2001.
[9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource [9] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
Records for the DNS Security Extensions", October 2002. "DNS Security Introduction and Requirements", draft-ietf-
dnsext-dnssec-intro-05 (work in progress), February 2003.
[10] 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), February 2003.
[11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.
Informative References
[12] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[14] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[15] Gudmundsson, O., "Delegation Signer Resource Record", draft-
ietf-dnsext-delegation-signer-12 (work in progress), December
2002.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Bankastraat 41-E Telematica Instituut
1094 EB Amsterdam Drienerlolaan 5
7522 NB Enschede
NL NL
EMail: roy@logmess.com EMail: roy.arends@telin.nl
Matt Larson Matt Larson
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Rob Austein
Internet Software Consortium
40 Gavin Circle
Reading, MA 01867
USA
EMail: sra@isc.org
Dan Massey Dan Massey
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive 3811 N. Fairfax Drive
Arlington, VA 22203 Arlington, VA 22203
USA USA
EMail: masseyd@isi.edu EMail: masseyd@isi.edu
Scott Rose Scott Rose
National Institute for Standards and Technology National Institute for Standards and Technology
skipping to change at page 31, line 4 skipping to change at page 40, line 4
EMail: masseyd@isi.edu EMail: masseyd@isi.edu
Scott Rose Scott Rose
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 NXT
RR set that proves no wildcard expansion matches N. The algorithm RRset that proves no wildcard expansion matches N. The algorithm was
was written for clarity not efficiency: (EDITORS NOTE: the written for clarity, not efficiency:
algorithm was really written on a redeye flight during dull movie
so it is unlikely to really achieve clarity :)
0. INPUT: a name (N) and a zone (Z). 0. INPUT: a name (N) and a zone (Z).
INIT: NXT_SET = NULL INIT: NXT_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
preceed N in S to NXT_SET. precede N in S to NXT_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
There is a 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 NXT for name that would immediately
preceed N in S to NXT_SET. precede N in S to NXT_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 an 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 NXT for N to NXT_SET and return NXT_SET.
Else Else
Goto Step 3 Goto Step 3
EndIf EndIf
Note: the algorithm is guaranteed to terminate since Note: the algorithm is guaranteed to terminate since
eventually there will be a match or N will be eventually there will be a match or N will be
reduced to zone name itself and the zone name reduced to zone name itself and the zone name
must exist in S. must exist in S.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished to
to others, and derivative works that comment on or otherwise others, and derivative works that comment on or otherwise explain it
explain it or assist in its implementation may be prepared, or assist in its implementation may be prepared, copied, published
copied, published and distributed, in whole or in part, without and distributed, in whole or in part, without restriction of any
restriction of any kind, provided that the above copyright notice kind, provided that the above copyright notice and this paragraph are
and this paragraph are included on all such copies and derivative included on all such copies and derivative works. However, this
works. However, this document itself may not be modified in any document itself may not be modified in any way, such as by removing
way, such as by removing the copyright notice or references to the the copyright notice or references to the Internet Society or other
Internet Society or other Internet organizations, except as needed Internet organizations, except as needed for the purpose of
for the purpose of developing Internet standards in which case the developing Internet standards in which case the procedures for
procedures for copyrights defined in the Internet Standards copyrights defined in the Internet Standards process must be
process must be followed, or as required to translate it into followed, or as required to translate it into languages other than
languages other than English. English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not be
be revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on an
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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