< draft-ietf-dnsext-dnssec-protocol-05.txt   draft-ietf-dnsext-dnssec-protocol-06.txt >
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: August 16, 2004 M. Larson Expires: November 15, 2004 M. Larson
VeriSign VeriSign
R. Austein R. Austein
ISC ISC
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
February 16, 2004 May 17, 2004
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-05 draft-ietf-dnsext-dnssec-protocol-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2004. This Internet-Draft will expire on November 15, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents which describe the DNS This document is part of a family of documents which describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of new resource records and protocol modifications which collection of new resource records and protocol modifications which
skipping to change at page 2, line 14 skipping to change at page 2, line 14
defines the concept of a signed zone, along with the requirements for defines the concept of a signed zone, along with the requirements for
serving and resolving using DNSSEC. These techniques allow a serving and resolving using DNSSEC. These techniques allow a
security-aware resolver to authenticate both DNS resource records and security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications. authoritative DNS error indications.
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 . . . . . . . . . . . . . . 4 1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6
2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6
2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15
3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 16
3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 3.1.6 The AD and CD Bits in an Authoritative Response . . . 17
3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 4.2 Signature Verification Support . . . . . . . . . . . . . . 20
4.3 Determining Security Status of Data . . . . . . . . . . . . 21 4.3 Determining Security Status of Data . . . . . . . . . . . 21
4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21
4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22
4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22
4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24
4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24
5.1 Special Considerations for Islands of Security . . . . . . . 27 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27 5.1 Special Considerations for Islands of Security . . . . . . 26
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.4 Authenticating A Wildcard Expanded RRset Positive
5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32 Response . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . 35 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
Normative References . . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
Informative References . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36
B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48 B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49
C. Authentication Examples . . . . . . . . . . . . . . . . . . 54 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55 C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 57 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . 57
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) are a collection of new resource The DNS Security Extensions (DNSSEC) are a collection of new resource
records and protocol modifications which add data origin records and protocol modifications which add data origin
authentication and data integrity to the DNS. This document defines authentication and data integrity to the DNS. This document defines
the DNSSEC protocol modifications. Section 2 of this document defines the DNSSEC protocol modifications. Section 2 of this document defines
the concept of a signed zone and lists the requirements for zone the concept of a signed zone and lists the requirements for zone
signing. Section 3 describes the modifications to authoritative name signing. Section 3 describes the modifications to authoritative name
server behavior necessary to handle signed zones. Section 4 describes server behavior necessary to handle signed zones. Section 4 describes
the behavior of entities which include security-aware resolver the behavior of entities which include security-aware resolver
functions. Finally, Section 5 defines how to use DNSSEC RRs to functions. Finally, Section 5 defines how to use DNSSEC RRs to
authenticate a response. authenticate a response.
1.1 Background and Related Documents 1.1 Background and Related Documents
The reader is assumed to be familiar with the basic DNS concepts The reader is assumed to be familiar with the basic DNS concepts
described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. described in [RFC1034] and [RFC1035].
This document is part of a family of documents which define DNSSEC. This document is part of a family of documents that define DNSSEC.
An introduction to DNSSEC and definition of common terms can be found An introduction to DNSSEC and definition of common terms can be found
in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
resource records can be found in [I-D.ietf-dnsext-dnssec-records]. resource records can be found in [I-D.ietf-dnsext-dnssec-records].
1.2 Reserved Words 1.2 Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]. document are to be interpreted as described in RFC 2119. [RFC2119].
1.3 Editors' Notes 1.3 Editors' Notes
1.3.1 Open Technical Issues 1.3.1 Open Technical Issues
1.3.2 Technical Changes or Corrections 1.3.2 Technical Changes or Corrections
Please report technical corrections to dnssec-editors@east.isi.edu. Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical out the RFC that defines the correct behavior. For a technical
change where no RFC that defines the correct behavior, or if there's change where no RFC that defines the correct behavior, or if there's
more than one applicable RFC and the definitions conflict, please more than one applicable RFC and the definitions conflict, please
post the issue to namedroppers. post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was "DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
DNSSEC RR types MUST NOT be included in responses unless the resolver DNSSEC RR types MUST NOT be included in responses unless the resolver
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-editors@east.isi.edu. Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to find To assist the editors, please provide enough context for us to find
the incorrect text quickly. the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It DNSSEC standard has been in development for over 1 years". It
should read "over 10 years". should read "over 10 years".
2. Zone Signing 2. Zone Signing
DNSSEC introduces the concept of signed zones. A signed zone DNSSEC introduces the concept of signed zones. A signed zone
includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
the rules specified in Section 2.1, Section 2.2, Section 2.3 and the rules specified in Section 2.1, Section 2.2, Section 2.3 and
Section 2.4, respectively. A zone that does not include these Section 2.4, respectively. A zone that does not include these
records according to the rules in this section is an unsigned zone. records according to the rules in this section is an unsigned zone.
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
and NSEC RRs to appear at the same owner name as a CNAME RR. and NSEC RRs to appear at the same owner name as a CNAME RR.
2.1 Including DNSKEY RRs in a Zone 2.1 Including DNSKEY RRs in a Zone
To sign a zone, the zone's administrator generates one or more To sign a zone, the zone's administrator generates one or more
public/private key pairs and uses the private key(s) to sign public/private key pairs and uses the private key(s) to sign
authoritative RRsets in the zone. For each private key used to authoritative RRsets in the zone. For each private key used to
create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
the public component stored in the zone. A zone key DNSKEY RR MUST the public component stored in the zone. A zone key DNSKEY RR MUST
have the Zone Key bit of the flags RDATA field set to one -- see have the Zone Key bit of the flags RDATA field set to one -- see
Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys
associated with other DNS operations MAY be stored in DNSKEY RRs that associated with other DNS operations MAY be stored in DNSKEY RRs that
are not marked as zone keys but MUST NOT be used to verify RRSIGs. are not marked as zone keys but MUST NOT be used to verify RRSIGs.
If the zone is delegated and does not wish to act as an island of If the zone is delegated and does not wish to act as an island of
security, the zone MUST have at least one DNSKEY RR at the apex to security, the zone MUST have at least one DNSKEY RR at the apex to
act as a secure entry point into the zone. This DNSKEY would then be act as a secure entry point into the zone. This DNSKEY would then be
used to generate a DS RR at the delegating parent (see used to generate a DS RR at the delegating parent (see
[I-D.ietf-dnsext-dnssec-records]). [I-D.ietf-dnsext-dnssec-records]).
DNSKEY RRs MUST NOT appear at delegation points. DNSKEY RRs MUST NOT appear at delegation points.
2.2 Including RRSIG RRs in a Zone 2.2 Including RRSIG RRs in a Zone
For each authoritative RRset in a signed zone, there MUST be at least For each authoritative RRset in a signed zone, there MUST be at least
one RRSIG record that meets all of the following requirements: one RRSIG record that meets all of the following requirements:
o The RRSIG owner name is equal to the RRset owner name; o The RRSIG owner name is equal to the RRset owner name;
o The RRSIG class is equal to the RRset class; o The RRSIG class is equal to the RRset class;
o The RRSIG Type Covered field is equal to the RRset type; o The RRSIG Type Covered field is equal to the RRset type;
o The RRSIG Original TTL field is equal to the TTL of the RRset; o The RRSIG Original TTL field is equal to the TTL of the RRset;
o The RRSIG RR's TTL is equal to the TTL of the RRset; o The RRSIG RR's TTL is equal to the TTL of the RRset;
o The RRSIG Labels field is equal to the number of labels in the o The RRSIG Labels field is equal to the number of labels in the
RRset owner name, not counting the null root label and not RRset owner name, not counting the null root label and not
counting the leftmost label if it is a wildcard; counting the leftmost label if it is a wildcard;
o The RRSIG Signer's Name field is equal to the name of the zone o The RRSIG Signer's Name field is equal to the name of the zone
containing the RRset; and containing the RRset; and
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
zone key DNSKEY record at the zone apex. zone key DNSKEY record at the zone apex.
The process for constructing the RRSIG RR for a given RRset is The process for constructing the RRSIG RR for a given RRset is
described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
multiple RRSIG RRs associated with it. multiple RRSIG RRs associated with it.
An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
would add no value and would create an infinite loop in the signing would add no value and would create an infinite loop in the signing
process. process.
The NS RRset that appears at the zone apex name MUST be signed, but The NS RRset that appears at the zone apex name MUST be signed, but
the NS RRsets that appear at delegation points (that is, the NS the NS RRsets that appear at delegation points (that is, the NS
RRsets in the parent zone that delegate the name to the child zone's RRsets in the parent zone that delegate the name to the child zone's
name servers) MUST NOT be signed. Glue address RRsets associated with name servers) MUST NOT be signed. Glue address RRsets associated with
delegations MUST NOT be signed. delegations MUST NOT be signed.
There MUST be an RRSIG for each RRset using at least one DNSKEY of There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the parent zone's DS RRset and each additional each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset itself MUST be signed by each algorithm appearing in the DS RRset
itself MUST be signed by each algorithm appearing in the DS RRset. located at the delegating parent (if any).
2.3 Including NSEC RRs in a Zone 2.3 Including NSEC RRs in a Zone
Each owner name in the zone which has authoritative data or a Each owner name in the zone which has authoritative data or a
delegation point NS RRset MUST have an NSEC resource record. The delegation point NS RRset MUST have an NSEC resource record. The
process for constructing the NSEC RR for a given name is described in process for constructing the NSEC RR for a given name is described in
[I-D.ietf-dnsext-dnssec-records]. [I-D.ietf-dnsext-dnssec-records].
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
value field in the zone SOA RR. value field in the zone SOA RR.
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
RRset at any particular owner name. That is, the signing process RRset at any particular owner name. That is, the signing process
MUST NOT create NSEC or RRSIG RRs for owner names nodes which were MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
not the owner name of any RRset before the zone was signed. not the owner name of any RRset before the zone was signed. The main
reasons for this are a desire for namespace consistency between
signed and unsigned versions of the same zone and a desire to reduce
the risk of response inconsistency in security oblivious recursive
name servers.
The type bitmap of every NSEC resource record in a signed zone MUST The type bitmap of every NSEC resource record in a signed zone MUST
indicate the presence of both the NSEC record itself and its indicate the presence of both the NSEC record itself and its
corresponding RRSIG record. corresponding RRSIG record.
The difference between the set of owner names that require RRSIG The difference between the set of owner names that require RRSIG
records and the set of owner names that require NSEC records is records and the set of owner names that require NSEC records is
subtle and worth highlighting. RRSIG records are present at the subtle and worth highlighting. RRSIG records are present at the
owner names of all authoritative RRsets. NSEC records are present at owner names of all authoritative RRsets. NSEC records are present at
the owner names of all names for which the signed zone is the owner names of all names for which the signed zone is
authoritative and also at the owner names of delegations from the authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part is RRsets. Note, however, that this distinction is for the most part is
only visible during the zone signing process, because NSEC RRsets are only visible during the zone signing process, because NSEC RRsets are
authoritative data, and are therefore signed, thus any owner name authoritative data, and are therefore signed, thus any owner name
which has an NSEC RRset will have RRSIG RRs as well in the signed which has an NSEC RRset will have RRSIG RRs as well in the signed
zone. zone.
2.4 Including DS RRs in a Zone The bitmap for the NSEC RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and the RR
types for which the parent zone has authoritative data MUST be set to
1; bits corresponding to any non-NS RRset for which the parent is not
authoritative MUST be set to 0.
2.4 Including DS RRs in a Zone
The DS resource record establishes authentication chains between DNS The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records, child zone is signed. The DS RRset MAY contain multiple records,
each referencing a public key in the child zone used to verify the each referencing a public key in the child zone used to verify the
RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
RRsets MUST NOT appear at a zone's apex. RRsets MUST NOT appear at a zone's apex.
A DS RR SHOULD point to a DNSKEY RR which is present in the child's A DS RR SHOULD point to a DNSKEY RR which is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
by the corresponding private key. by the corresponding private key.
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
(i.e., the NS RRset from the same zone containing the DS RRset). (i.e., the NS RRset from the same zone containing the DS RRset).
Construction of a DS RR requires knowledge of the corresponding Construction of a DS RR requires knowledge of the corresponding
DNSKEY RR in the child zone, which implies communication between the DNSKEY RR in the child zone, which implies communication between the
child and parent zones. This communication is an operational matter child and parent zones. This communication is an operational matter
not covered by this document. not covered by this document.
2.5 Changes to the CNAME Resource Record. 2.5 Changes to the CNAME Resource Record.
If a CNAME RRset is present at a name in a signed zone, appropriate If a CNAME RRset is present at a name in a signed zone, appropriate
RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
name for secure dynamic update purposes is also allowed. Other types name for secure dynamic update purposes is also allowed. Other types
MUST NOT be present at that name. MUST NOT be present at that name.
This is a modification to the original CNAME definition given in This is a modification to the original CNAME definition given in
[RFC1034]. The original definition of the CNAME RR did not allow any [RFC1034]. The original definition of the CNAME RR did not allow any
other types to coexist with a CNAME record, but a signed zone other types to coexist with a CNAME record, but a signed zone
requires NSEC and RRSIG RRs for every authoritative name. To resolve requires NSEC and RRSIG RRs for every authoritative name. To resolve
this conflict, this specification modifies the definition of the this conflict, this specification modifies the definition of the
CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
2.6 Example of a Secure Zone 2.6 Example of a Secure Zone
Appendix A shows a complete example of a small signed zone. Appendix A shows a complete example of a small signed zone.
3. Serving 3. Serving
This section describes the behavior of entities that include This section describes the behavior of entities that include
security-aware name server functions. In many cases such functions security-aware name server functions. In many cases such functions
will be part of a security-aware recursive name server, but a will be part of a security-aware recursive name server, but a
security-aware authoritative name server has some of the same security-aware authoritative name server has some of the same
requirements as a security-aware recursive name server does. requirements. Functions specific to security-aware recursive name
Functions specific to security-aware recursive name servers are servers are described in Section 3.2; functions specific to
described in Section 3.2; functions specific to authoritative servers authoritative servers are described in Section 3.1.
are described in Section 3.1.
The terms "SNAME", "SCLASS", and "STYPE" in the following discussion The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
are as used in [RFC1034]. are as used in [RFC1034].
A security-aware name server MUST support the EDNS0 [RFC2671] message A security-aware name server MUST support the EDNS0 [RFC2671] message
size extension, MUST support a message size of at least 1220 octets, size extension, MUST support a message size of at least 1220 octets,
and SHOULD support a message size of 4000 octets [RFC3226]. and SHOULD support a message size of 4000 octets [RFC3226].
A security-aware name server that receives a DNS query that does not A security-aware name server that receives a DNS query that does not
include the EDNS OPT pseudo-RR or that has the DO bit set to zero include the EDNS OPT pseudo-RR or that has the DO bit set to zero
MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
RRset, and MUST NOT perform any of the additional processing RRset, and MUST NOT perform any of the additional processing
described below. Since the DS RR type has the peculiar property of described below. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always only existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.1.4.1. require some special processing, as described in Section 3.1.4.1.
Security aware name servers that receive queries for security RR
types which match the content of more than one zone that it serves
(e.g. NSEC and RRSIG RRs above and below a delegation point where the
server is authoritative for both zones) are encouraged to behave
self-consistently. The name server MAY return one of the following:
o The above-delegation RRsets
o The below-delegation RRsets
o Both above and below-delegation RRsets
o Empty answer section (i.e. no records)
o Some other response
o An error
As long as the response is always consistent for each query to the
name server.
DNSSEC allocates two new bits in the DNS message header: the CD DNSSEC allocates two new bits in the DNS message header: the CD
(Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
is controlled by resolvers; a security-aware name server MUST copy is controlled by resolvers; a security-aware name server MUST copy
the CD bit from a query into the corresponding response. The AD bit the CD bit from a query into the corresponding response. The AD bit
is controlled by name servers; a security-aware name server MUST is controlled by name servers; a security-aware name server MUST
ignore the setting of the AD bit in queries. See Section 3.1.6, ignore the setting of the AD bit in queries. See Section 3.1.6,
Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
on the behavior of these bits. on the behavior of these bits.
3.1 Authoritative Name Servers A security aware name server which synthesizes CNAME RRs from DNAME
RRs as described in [RFC2672] SHOULD NOT generate signatures for the
synthesized CNAME RRs.
3.1 Authoritative Name Servers
Upon receiving a relevant query that has the EDNS [RFC2671] OPT Upon receiving a relevant query that has the EDNS [RFC2671] OPT
pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
name server for a signed zone MUST include additional RRSIG, NSEC, name server for a signed zone MUST include additional RRSIG, NSEC,
and DS RRs according to the following rules: and DS RRs according to the following rules:
o RRSIG RRs that can be used to authenticate a response MUST be o RRSIG RRs that can be used to authenticate a response MUST be
included in the response according to the rules in Section 3.1.1; included in the response according to the rules in Section 3.1.1;
o NSEC RRs that can be used to provide authenticated denial of o NSEC RRs that can be used to provide authenticated denial of
existence MUST be included in the response automatically according existence MUST be included in the response automatically according
to the rules in Section 3.1.3; to the rules in Section 3.1.3;
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
be included in referrals automatically according to the rules in be included in referrals automatically according to the rules in
Section 3.1.4. Section 3.1.4.
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
discusses zone transfer requirements. discusses zone transfer requirements.
3.1.1 Including RRSIG RRs in a Response 3.1.1 Including RRSIG RRs in a Response
When responding to a query that has the DO bit set to one, a When responding to a query that has the DO bit set to one, a
security-aware authoritative name server SHOULD attempt to send RRSIG security-aware authoritative name server SHOULD attempt to send RRSIG
RRs that a security-aware resolver can use to authenticate the RRsets RRs that a security-aware resolver can use to authenticate the RRsets
in the response. Inclusion of RRSIG RRs in a response is subject to in the response. A name server SHOULD make every attempt to keep the
the following rules: RRset and its associated RRSIG(s) together in a response. Inclusion
of RRSIG RRs in a response is subject to the following rules:
o When placing a signed RRset in the Answer section, the name server o When placing a signed RRset in the Answer section, the name server
MUST also place its RRSIG RRs in the Answer section. The RRSIG MUST also place its RRSIG RRs in the Answer section. The RRSIG
RRs have a higher priority for inclusion than any other RRsets RRs have a higher priority for inclusion than any other RRsets
that may need to be included. If space does not permit inclusion that may need to be included. If space does not permit inclusion
of these RRSIG RRs, the name server MUST set the TC bit. of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Authority section, the name o When placing a signed RRset in the Authority section, the name
server MUST also place its RRSIG RRs in the Authority section. server MUST also place its RRSIG RRs in the Authority section.
The RRSIG RRs have a higher priority for inclusion than any other The RRSIG RRs have a higher priority for inclusion than any other
RRsets that may need to be included. If space does not permit RRsets that may need to be included. If space does not permit
inclusion of these RRSIG RRs, the name server MUST set the TC bit. inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Additional section, the name o When placing a signed RRset in the Additional section, the name
server MUST also place its RRSIG RRs in the Additional section. server MUST also place its RRSIG RRs in the Additional section.
If space does not permit inclusion of both the RRset and its If space does not permit inclusion of both the RRset and its
associated RRSIG RRs, the name server MUST NOT set the TC bit associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If
solely because these RRSIG RRs didn't fit. this happens, the name server MUST NOT set the TC bit solely
because these RRSIG RRs didn't fit.
3.1.2 Including DNSKEY RRs In a Response 3.1.2 Including DNSKEY RRs In a Response
When responding to a query that has the DO bit set to one and that When responding to a query that has the DO bit set to one and that
requests the SOA or NS RRs at the apex of a signed zone, a requests the SOA or NS RRs at the apex of a signed zone, a
security-aware authoritative name server for that zone MAY return the security-aware authoritative name server for that zone MAY return the
zone apex DNSKEY RRset in the Additional section. In this situation, zone apex DNSKEY RRset in the Additional section. In this situation,
the DNSKEY RRset and associated RRSIG RRs have lower priority than the DNSKEY RRset and associated RRSIG RRs have lower priority than
any other information that would be placed in the additional section. any other information that would be placed in the additional section.
The name server SHOULD NOT include the DNSKEY RRset unless there is The name server SHOULD NOT include the DNSKEY RRset unless there is
enough space in the response message for both the DNSKEY RRset and enough space in the response message for both the DNSKEY RRset and
its associated RRSIG RR(s). If there is not enough space to include its associated RRSIG RR(s). If there is not enough space to include
these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
NOT set the TC bit solely because these RRs didn't fit (see Section NOT set the TC bit solely because these RRs didn't fit (see Section
3.1.1). 3.1.1).
3.1.3 Including NSEC RRs In a Response 3.1.3 Including NSEC RRs In a Response
When responding to a query that has the DO bit set to one, a When responding to a query that has the DO bit set to one, a
security-aware authoritative name server for a signed zone MUST security-aware authoritative name server for a signed zone MUST
include NSEC RRs in each of the following cases: include NSEC RRs in each of the following cases:
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>, No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
but does not contain any RRsets that exactly match <SNAME, SCLASS, but does not contain any RRsets that exactly match <SNAME, SCLASS,
STYPE>. STYPE>.
Name Error: The zone does not contain any RRsets that match <SNAME, Name Error: The zone does not contain any RRsets that match <SNAME,
skipping to change at page 12, line 33 skipping to change at page 12, line 48
match <SNAME, SCLASS>, does contain one or more RRsets that match match <SNAME, SCLASS>, does contain one or more RRsets that match
<SNAME, SCLASS> via wildcard name expansion, but does not contain <SNAME, SCLASS> via wildcard name expansion, but does not contain
any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
expansion. expansion.
In each of these cases, the name server includes NSEC RRs in the In each of these cases, the name server includes NSEC RRs in the
response to prove that an exact match for <SNAME, SCLASS, STYPE> was response to prove that an exact match for <SNAME, SCLASS, STYPE> was
not present in the zone and that the response that the name server is not present in the zone and that the response that the name server is
returning is correct given the data that are in the zone. returning is correct given the data that are in the zone.
3.1.3.1 Including NSEC RRs: No Data Response 3.1.3.1 Including NSEC RRs: No Data Response
If the zone contains RRsets matching <SNAME, SCLASS> but contains no If the zone contains RRsets matching <SNAME, SCLASS> but contains no
RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
include the NSEC RR for <SNAME, SCLASS> along with its associated include the NSEC RR for <SNAME, SCLASS> along with its associated
RRSIG RR(s) in the Authority section of the response (see Section RRSIG RR(s) in the Authority section of the response (see Section
3.1.1). If space does not permit inclusion of the NSEC RR or its 3.1.1). If space does not permit inclusion of the NSEC RR or its
associated RRSIG RR(s), the name server MUST set the TC bit (see associated RRSIG RR(s), the name server MUST set the TC bit (see
Section 3.1.1). Section 3.1.1).
Since the search name exists, wildcard name expansion does not apply Since the search name exists, wildcard name expansion does not apply
to this query, and a single signed NSEC RR suffices to prove the to this query, and a single signed NSEC RR suffices to prove the
requested RR type does not exist. requested RR type does not exist.
3.1.3.2 Including NSEC RRs: Name Error Response 3.1.3.2 Including NSEC RRs: Name Error Response
If the zone does not contain any RRsets matching <SNAME, SCLASS> If the zone does not contain any RRsets matching <SNAME, SCLASS>
either exactly or via wildcard name expansion, then the name server either exactly or via wildcard name expansion, then the name server
MUST include the following NSEC RRs in the Authority section, along MUST include the following NSEC RRs in the Authority section, along
with their associated RRSIG RRs: with their associated RRSIG RRs:
o An NSEC RR proving that there is no exact match for <SNAME, o An NSEC RR proving that there is no exact match for <SNAME,
SCLASS>; and SCLASS>; and
o An NSEC RR proving that the zone contains no RRsets that would o An NSEC RR proving that the zone contains no RRsets that would
match <SNAME, SCLASS> via wildcard name expansion. match <SNAME, SCLASS> via wildcard name expansion.
In some cases a single NSEC RR may prove both of these points, in In some cases a single NSEC RR may prove both of these points, in
that case the name server SHOULD only include the NSEC RR and its that case the name server SHOULD only include the NSEC RR and its
RRSIG RR(s) once in the Authority section. RRSIG RR(s) once in the Authority section.
If space does not permit inclusion of these NSEC and RRSIG RRs, the If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1). name server MUST set the TC bit (see Section 3.1.1).
The owner names of these NSEC and RRSIG RRs are not subject to The owner names of these NSEC and RRSIG RRs are not subject to
wildcard name expansion when these RRs are included in the Authority wildcard name expansion when these RRs are included in the Authority
section of the response. section of the response.
Note that this form of response includes cases in which SNAME Note that this form of response includes cases in which SNAME
corresponds to an empty non-terminal name within the zone (a name corresponds to an empty non-terminal name within the zone (a name
which is not the owner name for any RRset but which is the parent which is not the owner name for any RRset but which is the parent
name of one or more RRsets). name of one or more RRsets).
3.1.3.3 Including NSEC RRs: Wildcard Answer Response 3.1.3.3 Including NSEC RRs: Wildcard Answer Response
If the zone does not contain any RRsets which exactly match <SNAME, If the zone does not contain any RRsets which exactly match <SNAME,
SCLASS> but does contain an RRset which matches <SNAME, SCLASS, SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
STYPE> via wildcard name expansion, the name server MUST include the STYPE> via wildcard name expansion, the name server MUST include the
wildcard-expanded answer and the corresponding wildcard-expanded wildcard-expanded answer and the corresponding wildcard-expanded
RRSIG RRs in the Answer section, and MUST include in the Authority RRSIG RRs in the Answer section, and MUST include in the Authority
section an NSEC RR and associated RRSIG RR(s) proving that the zone section an NSEC RR and associated RRSIG RR(s) proving that the zone
does not contain a closer match for <SNAME, SCLASS>. If space does does not contain a closer match for <SNAME, SCLASS>. If space does
not permit inclusion of the answer, NSEC and RRSIG RRs, the name not permit inclusion of the answer, NSEC and RRSIG RRs, the name
server MUST set the TC bit (see Section 3.1.1). server MUST set the TC bit (see Section 3.1.1).
3.1.3.4 Including NSEC RRs: Wildcard No Data Response 3.1.3.4 Including NSEC RRs: Wildcard No Data Response
This case is a combination of the previous cases. The zone does not This case is a combination of the previous cases. The zone does not
contain an exact match for <SNAME, SCLASS>, and while the zone does contain an exact match for <SNAME, SCLASS>, and while the zone does
contain RRsets which match <SNAME, SCLASS> via wildcard expansion, contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
none of those RRsets match STYPE. The name server MUST include the none of those RRsets match STYPE. The name server MUST include the
following NSEC RRs in the Authority section, along with their following NSEC RRs in the Authority section, along with their
associated RRSIG RRs: associated RRSIG RRs:
o An NSEC RR proving that there are no RRsets matching STYPE at the o An NSEC RR proving that there are no RRsets matching STYPE at the
wildcard owner name which matched <SNAME, SCLASS> via wildcard wildcard owner name which matched <SNAME, SCLASS> via wildcard
expansion; and expansion; and
o An NSEC RR proving that there are no RRsets in the zone which o An NSEC RR proving that there are no RRsets in the zone which
would have been a closer match for <SNAME, SCLASS>. would have been a closer match for <SNAME, SCLASS>.
In some cases a single NSEC RR may prove both of these points, in In some cases a single NSEC RR may prove both of these points, in
which case the name server SHOULD only include the NSEC RR and its which case the name server SHOULD only include the NSEC RR and its
RRSIG RR(s) once in the Authority section. RRSIG RR(s) once in the Authority section.
The owner names of these NSEC and RRSIG RRs are not subject to The owner names of these NSEC and RRSIG RRs are not subject to
wildcard name expansion when these RRs are included in the Authority wildcard name expansion when these RRs are included in the Authority
section of the response. section of the response.
If space does not permit inclusion of these NSEC and RRSIG RRs, the If space does not permit inclusion of these NSEC and RRSIG RRs, the
name server MUST set the TC bit (see Section 3.1.1). name server MUST set the TC bit (see Section 3.1.1).
3.1.3.5 Finding The Right NSEC RRs 3.1.3.5 Finding The Right NSEC RRs
As explained above, there are several situations in which a As explained above, there are several situations in which a
security-aware authoritative name server needs to locate an NSEC RR security-aware authoritative name server needs to locate an NSEC RR
which proves that a particular SNAME does not exist. Locating such which proves that no RRsets matching a particular SNAME exist.
an NSEC RR within an authoritative zone is relatively simple, at Locating such an NSEC RR within an authoritative zone is relatively
least in concept. The following discussion assumes that the name simple, at least in concept. The following discussion assumes that
server is authoritative for the zone which would have held the the name server is authoritative for the zone which would have held
nonexistent SNAME. The algorithm below is written for clarity, not the nonexistent RRsets matching SNAME. The algorithm below is
efficiency. written for clarity, not efficiency.
To find the NSEC which proves that name N does not exist in the zone To find the NSEC which proves that no RRsets matching name N exist in
Z which would have held it, construct sequence S consisting of every the zone Z which would have held them, construct sequence S
name in Z, sorted into canonical order consisting of the owner names of every RRset in Z, sorted into
[I-D.ietf-dnsext-dnssec-records]. Find the name M which would have canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
immediately preceded N in S if N had existed. M is the owner name of names. Find the name M which would have immediately preceded N in S
the NSEC RR which proves that N does not exist. if any RRsets with owner name N had existed. M is the owner name of
the NSEC RR which proves that no RRsets exist with owner name N.
The algorithm for finding the NSEC RR which proves that a given name The algorithm for finding the NSEC RR which proves that a given name
is not covered by any applicable wildcard is similar, but requires an is not covered by any applicable wildcard is similar, but requires an
extra step. More precisely, the algorithm for finding the NSEC extra step. More precisely, the algorithm for finding the NSEC
proving that the applicable wildcard name does not exist is precisely proving that no RRsets exist with the applicable wildcard name is
the same as the algorithm for finding the NSEC RR which proves that precisely the same as the algorithm for finding the NSEC RR which
any other name does not exist: the part that's missing is how to proves that RRsets with any other owner name do not exist: the part
determine the name of the nonexistent applicable wildcard. In that's missing is how to determine the name of the nonexistent
practice, this is easy, because the authoritative name server has applicable wildcard. In practice, this is easy, because the
already checked for the presence of precisely this wildcard name as authoritative name server has already checked for the presence of
part of step (1)(c) of the normal lookup algorithm described in precisely this wildcard name as part of step (1)(c) of the normal
Section 4.3.2 of [RFC1034]. lookup algorithm described in Section 4.3.2 of [RFC1034].
3.1.4 Including DS RRs In a Response 3.1.4 Including DS RRs In a Response
When responding to a query which has the DO bit set to one, a When responding to a query which has the DO bit set to one, a
security-aware authoritative name server returning a referral security-aware authoritative name server returning a referral
includes DNSSEC data along with the NS RRset. includes DNSSEC data along with the NS RRset.
If a DS RRset is present at the delegation point, the name server If a DS RRset is present at the delegation point, the name server
MUST return both the DS RRset and its associated RRSIG RR(s) in the MUST return both the DS RRset and its associated RRSIG RR(s) in the
Authority section along with the NS RRset. The name server MUST Authority section along with the NS RRset. The name server MUST
place the NS RRset before the DS RRset and its associated RRSIG place the NS RRset before the DS RRset and its associated RRSIG
RR(s). RR(s).
skipping to change at page 15, line 23 skipping to change at page 15, line 36
present and the NSEC RR's associated RRSIG RR(s) along with the NS present and the NSEC RR's associated RRSIG RR(s) along with the NS
RRset. The name server MUST place the NS RRset before the NSEC RRset RRset. The name server MUST place the NS RRset before the NSEC RRset
and its associated RRSIG RR(s). and its associated RRSIG RR(s).
Including these DS, NSEC, and RRSIG RRs increases the size of Including these DS, NSEC, and RRSIG RRs increases the size of
referral messages, and may cause some or all glue RRs to be omitted. referral messages, and may cause some or all glue RRs to be omitted.
If space does not permit inclusion of the DS or NSEC RRset and If space does not permit inclusion of the DS or NSEC RRset and
associated RRSIG RRs, the name server MUST set the TC bit (see associated RRSIG RRs, the name server MUST set the TC bit (see
Section 3.1.1). Section 3.1.1).
3.1.4.1 Responding to Queries for DS RRs 3.1.4.1 Responding to Queries for DS RRs
The DS resource record type is unusual in that it appears only on the The DS resource record type is unusual in that it appears only on the
parent zone's side of a zone cut. For example, the DS RRset for the parent zone's side of a zone cut. For example, the DS RRset for the
delegation of "foo.example" is stored in the "example" zone rather delegation of "foo.example" is stored in the "example" zone rather
than in the "foo.example" zone. This requires special processing than in the "foo.example" zone. This requires special processing
rules for both name servers and resolvers, since the name server for rules for both name servers and resolvers, since the name server for
the child zone is authoritative for the name at the zone cut by the the child zone is authoritative for the name at the zone cut by the
normal DNS rules but the child zone does not contain the DS RRset. normal DNS rules but the child zone does not contain the DS RRset.
A security-aware resolver sends queries to the parent zone when A security-aware resolver sends queries to the parent zone when
skipping to change at page 15, line 45 skipping to change at page 16, line 10
However, special rules are necessary to avoid confusing However, special rules are necessary to avoid confusing
security-oblivious resolvers which might become involved in security-oblivious resolvers which might become involved in
processing such a query (for example, in a network configuration that processing such a query (for example, in a network configuration that
forces a security-aware resolver to channel its queries through a forces a security-aware resolver to channel its queries through a
security-oblivious recursive name server). The rest of this section security-oblivious recursive name server). The rest of this section
describes how a security-aware name server processes DS queries in describes how a security-aware name server processes DS queries in
order to avoid this problem. order to avoid this problem.
The need for special processing by a security-aware name server only The need for special processing by a security-aware name server only
arises when all the following conditions are met: arises when all the following conditions are met:
o the name server has received a query for the DS RRset at a zone o the name server has received a query for the DS RRset at a zone
cut; and cut; and
o the name server is authoritative for the child zone; and o the name server is authoritative for the child zone; and
o the name server is not authoritative for the parent zone; and o the name server is not authoritative for the parent zone; and
o the name server does not offer recursion. o the name server does not offer recursion.
In all other cases, the name server either has some way of obtaining In all other cases, the name server either has some way of obtaining
the DS RRset or could not have been expected to have the DS RRset the DS RRset or could not have been expected to have the DS RRset
even by the pre-DNSSEC processing rules, so the name server can even by the pre-DNSSEC processing rules, so the name server can
return either the DS RRset or an error response according to the return either the DS RRset or an error response according to the
normal processing rules. normal processing rules.
If all of the above conditions are met, however, the name server is If all of the above conditions are met, however, the name server is
authoritative for SNAME but cannot supply the requested RRset. In authoritative for SNAME but cannot supply the requested RRset. In
this case, the name server MUST return an authoritative "no data" this case, the name server MUST return an authoritative "no data"
response showing that the DS RRset does not exist in the child zone's response showing that the DS RRset does not exist in the child zone's
apex. See Appendix B.8 for an example of such a response. apex. See Appendix B.8 for an example of such a response.
3.1.5 Responding to Queries for Type AXFR or IXFR 3.1.5 Responding to Queries for Type AXFR or IXFR
DNSSEC does not change the DNS zone transfer process. A signed zone DNSSEC does not change the DNS zone transfer process. A signed zone
will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
records have no special meaning with respect to a zone transfer records have no special meaning with respect to a zone transfer
operation, and these RRs are treated as any other resource record operation.
type.
An authoritative name server is not required to verify that a zone is An authoritative name server is not required to verify that a zone is
properly signed before sending or accepting a zone transfer. properly signed before sending or accepting a zone transfer.
However, an authoritative name server MAY choose to reject the entire However, an authoritative name server MAY choose to reject the entire
zone transfer if the zone fails meets any of the signing requirements zone transfer if the zone fails meets any of the signing requirements
described in Section 2. The primary objective of a zone transfer is described in Section 2. The primary objective of a zone transfer is
to ensure that all authoritative name servers have identical copies to ensure that all authoritative name servers have identical copies
of the zone. An authoritative name server which chooses to perform of the zone. An authoritative name server that chooses to perform
its own zone validation MUST NOT selectively reject some RRs and its own zone validation MUST NOT selectively reject some RRs and
accept others. accept others.
DS RRsets appear only on the parental side of a zone cut and are DS RRsets appear only on the parental side of a zone cut and are
authoritative data in the parent zone. As with any other authoritative data in the parent zone. As with any other
authoritative RRset, the DS RRset MUST be included in zone transfers authoritative RRset, the DS RRset MUST be included in zone transfers
of the zone in which the RRset is authoritative data: in the case of of the zone in which the RRset is authoritative data: in the case of
the DS RRset, this is the parent zone. the DS RRset, this is the parent zone.
NSEC RRs appear in both the parent and child zones at a zone cut, and NSEC RRs appear in both the parent and child zones at a zone cut, and
skipping to change at page 17, line 15 skipping to change at page 17, line 24
RRSIG RRs appear in both the parent and child zones at a zone cut, RRSIG RRs appear in both the parent and child zones at a zone cut,
and are authoritative in whichever zone contains the authoritative and are authoritative in whichever zone contains the authoritative
RRset for which the RRSIG RR provides the signature. That is, the RRset for which the RRSIG RR provides the signature. That is, the
RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
authoritative in the parent zone, while the RRSIG for any RRset in authoritative in the parent zone, while the RRSIG for any RRset in
the child zone's apex will be authoritative in the child zone. As the child zone's apex will be authoritative in the child zone. As
with any other authoritative RRs, RRSIG RRs MUST be included in zone with any other authoritative RRs, RRSIG RRs MUST be included in zone
transfers of the zone in which they are authoritative data. transfers of the zone in which they are authoritative data.
3.1.6 The AD and CD Bits in an Authoritative Response 3.1.6 The AD and CD Bits in an Authoritative Response
The CD and AD bits are designed to be used in communication between The CD and AD bits are designed for use in communication between
security-aware resolvers and security-aware recursive name servers. security-aware resolvers and security-aware recursive name servers.
This bits are for the most part not relevant to query processing by These bits are for the most part not relevant to query processing by
security-aware authoritative name servers. security-aware authoritative name servers.
Since a security-aware name server does not perform signature A security-aware name server does not perform signature validation
validation for authoritative data during query processing even when for authoritative data during query processing even when the CD bit
the CD bit is set to zero, a security-aware name server SHOULD ignore is set to zero. A security-aware name server SHOULD clear the CD bit
the setting of the CD bit when composing an authoritative response. when composing an authoritative response.
A security-aware name server MUST NOT set the AD bit in a response A security-aware name server MUST NOT set the AD bit in a response
unless the name server considers all RRsets in the Answer and unless the name server considers all RRsets in the Answer and
Authority sections of the response to be authentic. A security-aware Authority sections of the response to be authentic. A security-aware
name server's local policy MAY consider data from an authoritative name server's local policy MAY consider data from an authoritative
zone to be authentic without further validation, but the name server zone to be authentic without further validation, but the name server
MUST NOT do so unless the name server obtained the authoritative zone MUST NOT do so unless the name server obtained the authoritative zone
via secure means (such as a secure zone transfer mechanism), and MUST via secure means (such as a secure zone transfer mechanism), and MUST
NOT do so unless this behavior has been configured explicitly. NOT do so unless this behavior has been configured explicitly.
A security-aware name server which supports recursion MUST follow the A security-aware name server which supports recursion MUST follow the
rules for the CD and AD bits given in Section 3.2 when generating a rules for the CD and AD bits given in Section 3.2 when generating a
response that involves data obtained via recursion. response that involves data obtained via recursion.
3.2 Recursive Name Servers 3.2 Recursive Name Servers
As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
recursive name server is an entity which acts in both the recursive name server is an entity which acts in both the
security-aware name server and security-aware resolver roles. This security-aware name server and security-aware resolver roles. This
section uses the terms "name server side" and "resolver side" to section uses the terms "name server side" and "resolver side" to
refer to the code within a security-aware recursive name server which refer to the code within a security-aware recursive name server which
implements the security-aware name server role and the code which implements the security-aware name server role and the code which
implements the security-aware resolver role, respectively. implements the security-aware resolver role, respectively.
The resolver side follows the usual rules for caching and negative The resolver side follows the usual rules for caching and negative
caching which would apply to any security-aware resolver. caching which would apply to any security-aware resolver.
3.2.1 The DO bit 3.2.1 The DO bit
The resolver side of a security-aware recursive name server MUST set The resolver side of a security-aware recursive name server MUST set
the DO bit when sending requests, regardless of the state of the DO the DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If bit in the initiating request received by the name server side. If
the DO bit in an initiating query is not set, the name server side the DO bit in an initiating query is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response, but MUST MUST strip any authenticating DNSSEC RRs from the response, but MUST
NOT strip any DNSSEC RRs that the initiating query explicitly NOT strip any DNSSEC RR types that the initiating query explicitly
requested. requested.
3.2.2 The CD bit 3.2.2 The CD bit
The CD bit exists in order to allow a security-aware resolver to The CD bit exists in order to allow a security-aware resolver to
disable signature validation in a security-aware name server's disable signature validation in a security-aware name server's
processing of a particular query. processing of a particular query.
The name server side MUST copy the setting of the CD bit from a query The name server side MUST copy the setting of the CD bit from a query
to the corresponding response. to the corresponding response.
The name server side of a security-aware recursive name server MUST The name server side of a security-aware recursive name server MUST
pass the sense of the CD bit to the resolver side along with the rest pass the sense of the CD bit to the resolver side along with the rest
skipping to change at page 18, line 48 skipping to change at page 19, line 9
recursive name server should not interfere. recursive name server should not interfere.
If the resolver side implements a BAD cache (see Section 4.7) and the If the resolver side implements a BAD cache (see Section 4.7) and the
name server side receives a query which matches an entry in the name server side receives a query which matches an entry in the
resolver side's BAD cache, the name server side's response depends on resolver side's BAD cache, the name server side's response depends on
the sense of the CD bit in the original query. If the CD bit is set, the sense of the CD bit in the original query. If the CD bit is set,
the name server side SHOULD return the data from the BAD cache; if the name server side SHOULD return the data from the BAD cache; if
the CD bit is not set, the name server side MUST return RCODE 2 the CD bit is not set, the name server side MUST return RCODE 2
(server failure). (server failure).
3.2.3 The AD bit The intent of the above rule is to provide the raw data to clients
which are capable of performing their own signature verification
checks while protecting clients which depend on the resolver side of
a security-aware recursive name server to perform such checks.
Several of the possible reasons why signature validation might fail
involve conditions which may not apply equally to the recursive name
server and the client which invoked it: for example, the recursive
name server's clock may be set incorrectly, or the client may have
knowledge of a relevant island of security which the recursive name
server does not share. In such cases, "protecting" a client which is
capable of performing its own signature validation from ever seeing
the "bad" data does not help the client.
3.2.3 The AD bit
The name server side of a security-aware recursive name server MUST The name server side of a security-aware recursive name server MUST
NOT set the AD bit in a response unless the name server considers all NOT set the AD bit in a response unless the name server considers all
RRsets in the Answer and Authority sections of the response to be RRsets in the Answer and Authority sections of the response to be
authentic, and SHOULD set the AD bit if and only if the resolver side authentic. The name server side SHOULD set the AD bit if and only if
considers all RRsets in the Answer section and any relevant negative the resolver side considers all RRsets in the Answer section and any
response RRs in the Authority section to be authentic. The resolver relevant negative response RRs in the Authority section to be
side MUST follow the procedure described in Section 5 to determine authentic. The resolver side MUST follow the procedure described in
whether the RRs in question are authentic. Section 5 to determine whether the RRs in question are authentic.
However, for backwards compatibility, a recursive name server MAY set
the AD bit when a response includes unsigned CNAME RRs if those CNAME
RRs demonstrably could have been synthesized from an authentic DNAME
RR which is also included in the response according to the synthesis
rules described in [RFC2672].
3.3 Example DNSSEC Responses 3.3 Example DNSSEC Responses
See Appendix B for example response packets. See Appendix B for example response packets.
4. Resolving 4. Resolving
This section describes the behavior of entities which include This section describes the behavior of entities that include
security-aware resolver functions. In many cases such functions will security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements. Functions security-aware resolver has many of the same requirements. Functions
specific to security-aware recursive name servers are described in specific to security-aware recursive name servers are described in
Section 3.2. Section 3.2.
4.1 EDNS Support 4.1 EDNS Support
A security-aware resolver MUST include an EDNS [RFC2671] OPT A security-aware resolver MUST include an EDNS [RFC2671] OPT
pseudo-RR with the DO [RFC3225] bit set to one when sending queries. pseudo-RR with the DO [RFC3225] bit set to one when sending queries.
A security-aware resolver MUST support a message size of at least A security-aware resolver MUST support a message size of at least
1220 octets, SHOULD support a message size of 4000 octets, and MUST 1220 octets, SHOULD support a message size of 4000 octets, and MUST
advertise the supported message size using the "sender's UDP payload advertise the supported message size using the "sender's UDP payload
size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
handle fragmented UDP packets correctly regardless of whether any handle fragmented UDP packets correctly regardless of whether any
such fragmented packets were received via IPv4 or IPv6. Please see such fragmented packets were received via IPv4 or IPv6. Please see
[RFC3226] for discussion of these requirements. [RFC3226] for discussion of these requirements.
4.2 Signature Verification Support 4.2 Signature Verification Support
A security-aware resolver MUST support the signature verification A security-aware resolver MUST support the signature verification
mechanisms described in Section 5, and MUST apply them to every mechanisms described in Section 5, and MUST apply them to every
received response except when: received response except when:
o The security-aware resolver is part of a security-aware recursive o The security-aware resolver is part of a security-aware recursive
name server, and the response is the result of recursion on behalf name server, and the response is the result of recursion on behalf
of a query received with the CD bit set; of a query received with the CD bit set;
o The response is the result of a query generated directly via some o The response is the result of a query generated directly via some
form of application interface which instructed the security-aware form of application interface which instructed the security-aware
resolver not to perform validation for this query; or resolver not to perform validation for this query; or
o Validation for this query has been disabled by local policy. o Validation for this query has been disabled by local policy.
A security-aware resolver's support for signature verification MUST A security-aware resolver's support for signature verification MUST
include support for verification of wildcard owner names. include support for verification of wildcard owner names.
Editors' note: The rest of this section is expected to change once Security aware resolvers MAY query for missing security RRs in an
the WG reaches closure on Q-23. attempt to perform validation; implementations that choose to do so
must be aware of the fact that the answers received may not be
A security-aware resolver MUST attempt to retrieve missing DS, sufficient to validate the original response.
DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
RRs in order to perform signature verification.
A security-aware resolver MUST attempt to retrieve a missing NSEC RR
which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NSEC
RRs, since the resolver will have no way of knowing the owner name of
the missing NSEC RR, but in the specific case of a NODATA response,
the resolver may know the name of the missing NSEC RR, and in such
cases must therefore attempt to retrieve it.
When attempting to retrieve missing NSEC RRs which reside on the When attempting to retrieve missing NSEC RRs which reside on the
parental side at a zone cut, a security-aware iterative-mode resolver parental side at a zone cut, a security-aware iterative-mode resolver
MUST query the name servers for the parent zone, not the child zone. MUST query the name servers for the parent zone, not the child zone.
When attempting to retrieve a missing DS, a security-aware When attempting to retrieve a missing DS, a security-aware
iterative-mode resolver MUST query the name servers for the parent iterative-mode resolver MUST query the name servers for the parent
zone, not the child zone. As explained in Section 3.1.4.1, zone, not the child zone. As explained in Section 3.1.4.1,
security-aware name servers need to apply special processing rules to security-aware name servers need to apply special processing rules to
handle the DS RR, and in some situations the resolver may also need handle the DS RR, and in some situations the resolver may also need
to apply special rules to locate the name servers for the parent zone to apply special rules to locate the name servers for the parent zone
if the resolver does not already have the parent's NS RRset. To if the resolver does not already have the parent's NS RRset. To
locate the parent NS RRset, the resolver can start with the locate the parent NS RRset, the resolver can start with the
delegation name, strip off the leftmost label, and query for an NS delegation name, strip off the leftmost label, and query for an NS
RRset by that name; if no NS RRset is present at that name, the RRset by that name; if no NS RRset is present at that name, the
resolver then strips of the leftmost remaining label and retries the resolver then strips of the leftmost remaining label and retries the
query for that name, repeating this process of walking up the tree query for that name, repeating this process of walking up the tree
until it either finds the NS RRset or runs out of labels. until it either finds the NS RRset or runs out of labels.
Editors' note: This algorithm could easily be read as an 4.3 Determining Security Status of Data
invitation to careless implementors to hammer the root zone
servers. Better wording would be welcome.
4.3 Determining Security Status of Data
Editors' note: This section is waiting for resolution of Q-28.
A security-aware resolver MUST be able to determine whether or not it A security-aware resolver MUST be able to determine whether or not it
should expect a particular RRset to be signed. More precisely, a should expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between three security-aware resolver must be able to distinguish between four
cases: cases:
1. An RRset for which the resolver is able to build a chain of Secure: An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted security anchor to the signed DNSKEY and DS RRs from a trusted security anchor to the
RRset. In this case, the RRset should be signed, and is subject RRset. In this case, the RRset should be signed, and is subject
to signature validation as described above. to signature validation as described above.
2. An RRset for which the resolver knows that it has no chain of Insecure: An RRset for which the resolver knows that it has no chain
signed DNSKEY and DS RRs from any trusted starting point to the of signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able RRset may or may not be signed, but the resolver will not be able
to verify the signature. to verify the signature.
3. An RRset for which the resolver is not able to determine whether Bogus: An RRset for which the resolver believes that it ought to be
or not the RRset should be signed, because the resolver is not able to establish a chain of trust but is unable to do so, either
able to obtain the necessary DNSSEC RRs. This can occur when the due to signatures that for some reason fail to validate or due to
security-aware resolver is not able to contact security-aware missing data which the relevant DNSSEC RRs indicate should be
name servers for the relevant zones. present. This case may indicate an attack, but may also indicate
a configuration error or some form of data corruption.
4.4 Preconfigured Public Keys Indeterminate: 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 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 4.4 Configured Trust Anchors
at least one trusted public key or DS RR, and SHOULD be capable of
being preconfigured with multiple trusted public keys or DS RRs.
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; examples of such a mechanism would be some form of
non-volatile storage (such as a disk drive) or some form of trusted
local network configuration mechanism.
4.5 Response Caching A security-aware resolver MUST be capable of being configured with at
least one trusted public key or DS RR, and SHOULD be capable of being
configured with multiple trusted public keys or DS RRs. Since a
security-aware resolver will not be able to validate signatures
without such a configured trust anchor, the resolver SHOULD have some
reasonably robust mechanism for obtaining such keys when it boots;
examples of such a mechanism would be some form of non-volatile
storage (such as a disk drive) or some form of trusted local network
configuration mechanism.
Editors' note: RIPE "last call" workshop felt that the WG needs to Note that trust anchors also covers key material that is updated in a
reexamine and discuss this section. secure manner. This secure manner could be through physical media, a
key exchange protocol, or some other out of band means.
4.5 Response Caching
A security-aware resolver SHOULD cache each response as a single A security-aware resolver SHOULD cache each response as a single
atomic entry containing the entire answer, including the named RRset atomic entry containing the entire answer, including the named RRset
and any associated DNSSEC RRs. The resolver SHOULD discard the and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire. In entire atomic entry when any of the RRs contained in it expire. In
most cases the appropriate cache index for the atomic entry will be most cases the appropriate cache index for the atomic entry will be
the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
form described in Section 3.1.3.2 the appropriate cache index will be form described in Section 3.1.3.2 the appropriate cache index will be
the double <QNAME,QCLASS>. the double <QNAME,QCLASS>.
4.6 Handling of the CD and AD bits 4.6 Handling of the CD and AD bits
A security-aware resolver MAY set the CD bit in a query to one in A security-aware resolver MAY set the CD bit in a query to one in
order to indicate that the resolver takes responsibility for order to indicate that the resolver takes responsibility for
performing whatever authentication its local policy requires on the performing whatever authentication its local policy requires on the
RRsets in the response. See Section 3.2 for the effect this bit has RRsets in the response. See Section 3.2 for the effect this bit has
on the behavior of security-aware recursive name servers. on the behavior of security-aware recursive name servers.
A security-aware resolver MUST zero the AD bit when composing query A security-aware resolver MUST zero the AD bit when composing query
messages to protect against buggy name servers which blindly copy messages to protect against buggy name servers which blindly copy
header bits which they do not understand from the query message to header bits which they do not understand from the query message to
the response message. the response message.
A resolver MUST disregard the meaning of the CD and AD bits in a A resolver MUST disregard the meaning of the CD and AD bits in a
response unless the response was obtained using a secure channel or response unless the response was obtained using a secure channel or
the resolver was specifically configured to regard the message header the resolver was specifically configured to regard the message header
bits without using a secure channel. bits without using a secure channel.
4.7 Rate Limiting 4.7 Caching BAD Data
A security-aware resolver SHOULD NOT cache data with invalid While many validation errors will be transient, some are likely to be
signatures under normal circumstances. However, a security-aware more persistent, such as those caused by administrative error
resolver SHOULD take steps to rate limit the number of identical (failure to re-sign a zone, clock skew, and so forth). Since
queries that it generates if signature validation of the responses requerying will not help in these cases, validating resolvers might
fails repeatedly. generate a significant amount of unnecessary DNS traffic as a result
of repeated queries for RRsets with persistent validation failures.
Conceptually, this is similar in some respects to negative caching To prevent such unnecessary DNS traffic, security-aware resolvers MAY
[RFC2308], but since the resolver has no way of obtaining an cache data with invalid signatures, with some restrictions.
appropriate caching TTL from received data in this case, the TTL will Conceptually, caching such data is similar to negative caching
have to be set by the implementation. This document refers to the [RFC2308], except that instead of caching a valid negative response,
data retained as part of such a rate limiting mechanism as the "BAD the resolver is caching the fact that a particular answer failed to
cache". validate. This document refers to a cache of data with invalid
signatures as a "BAD cache".
A security-aware resolver MAY chose to retain RRsets for which Resolvers which implement a BAD cache MUST take steps to prevent the
signature validation has failed in its BAD cache, but MUST NOT return cache from being useful as a denial-of-service attack amplifier. In
such RRsets from its BAD cache unless both of the following particular:
conditions are met: o Since RRsets which fail to validate do not have trustworthy TTLs,
the implementation MUST assign a TTL. This TTL SHOULD be small,
in order to mitigate the effect of caching the results of an
attack.
o In order to prevent caching of a transient validation failure
(which might be the result of an attack), resolvers SHOULD track
queries that result in validation failures, and SHOULD only answer
from the BAD cache after the number of times that responses to
queries for that particular <QNAME, QTYPE, QCLASS> have failed to
validate exceeds a threshold value.
o The resolver has recently generated enough queries identical to Resolvers MUST NOT return RRsets from the BAD cache unless the
this one that the resolver is suppressing queries for this <QNAME, resolver is not required to validate the signatures of the RRsets in
QTYPE, QCLASS>; and question under the rules given in Section 4.2 of this document. See
Section 3.2.2 for discussion of how the responses returned by a
security-aware recursive name server interact with a BAD cache.
o The resolver is not required to validate the signatures of the 4.8 Synthesized CNAMEs
RRsets in question under the rules given in Section 4 of this
document.
The intent of the above rule is to provide the raw data to clients A validating security-aware resolver MUST treat the signature of a
which are capable of performing their own signature verification valid signed DNAME RR as also covering unsigned CNAME RRs which could
checks while protecting clients which depend on this resolver to have been synthesized from the DNAME RR as described in [RFC2672], at
perform such checks. Several of the possible reasons why signature least to the extent of not rejecting a response message solely
validation might fail involve conditions which may not apply equally because it contains such CNAME RRs. The resolver MAY retain such
to this resolver and the client which invoked it: for example, this CNAME RRs in its cache or in the answers it hands back, but is not
resolver's clock may be set incorrectly, or the client may have required to do so.
knowledge of a relevant island of security which this resolver does
not share. In such cases, "protecting" a client which is capable of
performing its own signature validation from ever seeing the "bad"
data does not help the client.
4.8 Stub resolvers 4.9 Stub resolvers
A security-aware stub resolver MUST support the DNSSEC RR types, at A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they least to the extent of not mishandling responses just because they
contain DNSSEC RRs. contain DNSSEC RRs.
4.8.1 Handling of the DO Bit 4.9.1 Handling of the DO Bit
A non-validating security-aware stub resolver MAY include the DNSSEC A non-validating security-aware stub resolver MAY include the DNSSEC
RRs returned by a security-aware recursive name server as part of the RRs returned by a security-aware recursive name server as part of the
data that the stub resolver hands back to the application which data that the stub resolver hands back to the application which
invoked it but is not required to do so. A non-validating stub invoked it but is not required to do so. A non-validating stub
resolver that wishes to do this will need to set the DO bit in resolver that wishes to do this will need to set the DO bit in
receive DNSSEC RRs from the recursive name server. receive DNSSEC RRs from the recursive name server.
A validating security-aware stub resolver MUST set the DO bit, since A validating security-aware stub resolver MUST set the DO bit, since
otherwise it will not receive the DNSSEC RRs it needs to perform otherwise it will not receive the DNSSEC RRs it needs to perform
signature validation. signature validation.
4.8.2 Handling of the CD Bit 4.9.2 Handling of the CD Bit
A non-validating security-aware stub resolver SHOULD NOT set the CD A non-validating security-aware stub resolver SHOULD NOT set the CD
bit when sending queries unless requested by the application layer, bit when sending queries unless requested by the application layer,
since by definition, a non-validating stub resolver depends on the since by definition, a non-validating stub resolver depends on the
security-aware recursive name server to perform validation on its security-aware recursive name server to perform validation on its
behalf. behalf.
A validating security-aware stub resolver SHOULD set the CD bit, A validating security-aware stub resolver SHOULD set the CD bit,
since otherwise the security-aware recursive name server will answer since otherwise the security-aware recursive name server will answer
the query using the name server's local policy, which may prevent the the query using the name server's local policy, which may prevent the
stub resolver from receiving data which would be acceptable to the stub resolver from receiving data which would be acceptable to the
stub resolver's local policy. stub resolver's local policy.
4.8.3 Handling of the AD Bit 4.9.3 Handling of the AD Bit
A non-validating security-aware stub resolver MAY chose to examine A non-validating security-aware stub resolver MAY chose to examine
the setting of the AD bit in response messages that it receives in the setting of the AD bit in response messages that it receives in
order to determine whether the security-aware recursive name server order to determine whether the security-aware recursive name server
which sent the response claims to have cryptographically verified the which sent the response claims to have cryptographically verified the
data in the Answer and Authority sections of the response message. data in the Answer and Authority sections of the response message.
Note, however, that the responses received by a security-aware stub Note, however, that the responses received by a security-aware stub
resolver are heavily dependent on the local policy of the resolver are heavily dependent on the local policy of the
security-aware recursive name server, so as a practical matter there security-aware recursive name server, so as a practical matter there
may be little practical value to checking the status of the AD bit may be little practical value to checking the status of the AD bit
skipping to change at page 26, line 5 skipping to change at page 25, line 5
stub resolver MUST NOT place any reliance on signature validation stub resolver MUST NOT place any reliance on signature validation
allegedly performed on its behalf except when the security-aware stub allegedly performed on its behalf except when the security-aware stub
resolver obtained the data in question from a trusted security-aware resolver obtained the data in question from a trusted security-aware
recursive name server via a secure channel. recursive name server via a secure channel.
A validating security-aware stub resolver SHOULD NOT examine the A validating security-aware stub resolver SHOULD NOT examine the
setting of the AD bit in response messages, since, by definition, the setting of the AD bit in response messages, since, by definition, the
stub resolver performs its own signature validation regardless of the stub resolver performs its own signature validation regardless of the
setting of the AD bit. setting of the AD bit.
5. Authenticating DNS Responses 5. Authenticating DNS Responses
In order to use DNSSEC RRs for authentication, a security-aware In order to use DNSSEC RRs for authentication, a security-aware
resolver requires preconfigured knowledge of at least one resolver requires configured knowledge of at least one authenticated
authenticated DNSKEY or DS RR. The process for obtaining and DNSKEY or DS RR. The process for obtaining and authenticating this
authenticating this initial DNSKEY or DS RR is achieved via some initial trust anchors is achieved via some external mechanism. For
external mechanism. For example, a resolver could use some off-line example, a resolver could use some off-line authenticated exchange to
authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
that identifies and authenticates a zone's DNSKEY RR. The remainder authenticates a zone's DNSKEY RR. The remainder of this section
of this section assumes that the resolver has somehow obtained an assumes that the resolver has somehow obtained an initial set of
initial set of authenticated DNSKEY RRs. trust anchors.
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
RRset. To authenticate an apex DNSKEY RRset using an initial key, RRset. To authenticate an apex DNSKEY RRset using an initial key,
the resolver MUST: the resolver MUST:
1. Verify that the initial DNSKEY RR appears in the apex DNSKEY 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
(DNSKEY RDATA bit 7) set to one. (DNSKEY RDATA bit 7) set to one.
2. Verify that there is some RRSIG RR that covers the apex DNSKEY 2. Verify that there is some RRSIG RR that covers the apex DNSKEY
RRset, and that the combination of the RRSIG RR and the initial RRset, and that the combination of the RRSIG RR and the initial
DNSKEY RR authenticates the DNSKEY RRset. The process for using DNSKEY RR authenticates the DNSKEY RRset. The process for using
an RRSIG RR to authenticate an RRset is described in Section 5.3. an RRSIG RR to authenticate an RRset is described in Section 5.3.
Once the resolver has authenticated the apex DNSKEY RRset using an Once the resolver has authenticated the apex DNSKEY RRset using an
initial DNSKEY RR, delegations from that zone can be authenticated initial DNSKEY RR, delegations from that zone can be authenticated
using DS RRs. This allows a resolver to start from an initial key, using DS RRs. This allows a resolver to start from an initial key,
and use DS RRsets to proceed recursively down the DNS tree obtaining and use DS RRsets to proceed recursively down the DNS tree obtaining
other apex DNSKEY RRsets. If the resolver were preconfigured with a other apex DNSKEY RRsets. If the resolver were configured with a
root DNSKEY RR, and if every delegation had a DS RR associated with root DNSKEY RR, and if every delegation had a DS RR associated with
it, then the resolver could obtain and validate any apex DNSKEY it, then the resolver could obtain and validate any apex DNSKEY
RRset. The process of using DS RRs to authenticate referrals is RRset. The process of using DS RRs to authenticate referrals is
described in Section 5.2. described in Section 5.2.
Once the resolver has authenticated a zone's apex DNSKEY RRset, Once the resolver has authenticated a zone's apex DNSKEY RRset,
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
DNSKEY RRset and RRSIG RRs from the zone to authenticate any other DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
RRsets in the zone. Section 5.4 shows how the resolver can use RRsets in the zone. Section 5.4 shows how the resolver can use
authenticated NSEC RRsets from the zone to prove that an RRset is not authenticated NSEC RRsets from the zone to prove that an RRset is not
present in the zone. present in the zone.
When a resolver indicates support for DNSSEC (by setting the DO bit), When a resolver indicates support for DNSSEC (by setting the DO bit),
a security-aware name server should attempt to provide the necessary a security-aware name server should attempt to provide the necessary
DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
However, a security-aware resolver may still receive a response that However, a security-aware resolver may still receive a response that
that lacks the appropriate DNSSEC RRs, whether due to configuration that lacks the appropriate DNSSEC RRs, whether due to configuration
issues such as a security-oblivious recursive name server that issues such as an upstream security-oblivious recursive name server
accidentally interfere with DNSSEC RRs or due to a deliberate attack that accidentally interferes with DNSSEC RRs or due to a deliberate
in which an adversary forges a response, strips DNSSEC RRs from a attack in which an adversary forges a response, strips DNSSEC RRs
response, or modifies a query so that DNSSEC RRs appear not to be from a response, or modifies a query so that DNSSEC RRs appear not to
requested. The absence of DNSSEC data in a response MUST NOT by be requested. The absence of DNSSEC data in a response MUST NOT by
itself be taken as an indication that no authentication information itself be taken as an indication that no authentication information
exists. exists.
A resolver SHOULD expect authentication information from signed A resolver SHOULD expect authentication information from signed
zones. A resolver SHOULD believe that a zone is signed if the zones. A resolver SHOULD believe that a zone is signed if the
resolver has been configured with public key information for the resolver has been configured with public key information for the
zone, or if the zone's parent is signed and the delegation from the zone, or if the zone's parent is signed and the delegation from the
parent contains a DS RRset. parent contains a DS RRset.
5.1 Special Considerations for Islands of Security 5.1 Special Considerations for Islands of Security
Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
zones for which it is not possible to construct an authentication zones for which it is not possible to construct an authentication
chain to the zone from its parent. Validating signatures within an chain to the zone from its parent. Validating signatures within an
island of security requires the validator to have some other means of island of security requires the validator to have some other means of
obtaining an initial authenticated zone key for the island. If a obtaining an initial authenticated zone key for the island. If a
validator cannot obtain such a key, it will have to choose whether to validator cannot obtain such a key, it SHOULD switch to operating as
accept the unvalidated responses or not based on local policy. if the zones in the island of security are unsigned.
All the normal processes for validating responses apply to islands of All the normal processes for validating responses apply to islands of
security. The only difference between normal validation and security. The only difference between normal validation and
validation within an island of security is in how the validator validation within an island of security is in how the validator
obtains a starting point for the authentication chain. obtains a trust anchor for the authentication chain.
5.2 Authenticating Referrals 5.2 Authenticating Referrals
Once the apex DNSKEY RRset for a signed parent zone has been Once the apex DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR identifies a DNSKEY RR in the child to a signed child zone. A DS RR identifies a DNSKEY RR in the child
zone's apex DNSKEY RRset, and contains a cryptographic digest of the zone's apex DNSKEY RRset, and contains a cryptographic digest of the
child zone's DNSKEY RR. A strong cryptographic digest algorithm child zone's DNSKEY RR. A strong cryptographic digest algorithm
ensures that an adversary can not easily generate a DNSKEY RR that ensures that an adversary can not easily generate a DNSKEY RR that
matches the digest. Thus, authenticating the digest allows a matches the digest. Thus, authenticating the digest allows a
resolver to authenticate the matching DNSKEY RR. The resolver can resolver to authenticate the matching DNSKEY RR. The resolver can
then use this child DNSKEY RR to authenticate the entire child apex then use this child DNSKEY RR to authenticate the entire child apex
skipping to change at page 27, line 47 skipping to change at page 26, line 45
zone's apex DNSKEY RRset, and contains a cryptographic digest of the zone's apex DNSKEY RRset, and contains a cryptographic digest of the
child zone's DNSKEY RR. A strong cryptographic digest algorithm child zone's DNSKEY RR. A strong cryptographic digest algorithm
ensures that an adversary can not easily generate a DNSKEY RR that ensures that an adversary can not easily generate a DNSKEY RR that
matches the digest. Thus, authenticating the digest allows a matches the digest. Thus, authenticating the digest allows a
resolver to authenticate the matching DNSKEY RR. The resolver can resolver to authenticate the matching DNSKEY RR. The resolver can
then use this child DNSKEY RR to authenticate the entire child apex then use this child DNSKEY RR to authenticate the entire child apex
DNSKEY RRset. DNSKEY RRset.
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
can be authenticated if all of the following hold: can be authenticated if all of the following hold:
o The DS RR has been authenticated using some DNSKEY RR in the o The DS RR has been authenticated using some DNSKEY RR in the
parent's apex DNSKEY RRset (see Section 5.3); parent's apex DNSKEY RRset (see Section 5.3);
o The Algorithm and Key Tag in the DS RR match the Algorithm field o The Algorithm and Key Tag in the DS RR match the Algorithm field
and the key tag of a DNSKEY RR in the child zone's apex DNSKEY and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
RRset that, when hashed using the digest algorithm specified in RRset and, when hashed using the digest algorithm specified in the
the DS RR's Digest Type field, results in a digest value that DS RR's Digest Type field, results in a digest value that matches
matches the Digest field of the DS RR; and the Digest field of the DS RR; and
o The matching DNSKEY RR in the child zone has the Zone Flag bit set o The matching DNSKEY RR in the child zone has the Zone Flag bit set
to one, the corresponding private key has signed the child zone's to one, the corresponding private key has signed the child zone's
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone's apex DNSKEY RRset. child zone's apex DNSKEY RRset.
If the referral from the parent zone did not contain a DS RRset, the If the referral from the parent zone did not contain a DS RRset, the
response should have included a signed NSEC RRset proving that no DS response should have included a signed NSEC RRset proving that no DS
RRset exists for the delegated name (see Section 3.1.4). A RRset exists for the delegated name (see Section 3.1.4). A
security-aware resolver MUST query the name servers for the parent security-aware resolver MUST query the name servers for the parent
zone for the DS RRset if the referral includes neither a DS RRset nor zone for the DS RRset if the referral includes neither a DS RRset nor
a NSEC RRset proving that the DS RRset does not exist (see Section a NSEC RRset proving that the DS RRset does not exist (see Section
4). 4).
If the resolver authenticates an NSEC RRset that proves that no DS If the validator authenticates an NSEC RRset that proves that no DS
RRset is present for this zone, then there is no authentication path RRset is present for this zone, then there is no authentication path
leading from the parent to the child. If the resolver has an initial leading from the parent to the child. If the resolver has an initial
DNSKEY or DS RR that belongs to the child zone or to any delegation DNSKEY or DS RR that belongs to the child zone or to any delegation
below the child zone, this initial DNSKEY or DS RR MAY be used to below the child zone, this initial DNSKEY or DS RR MAY be used to
re-establish an authentication path. If no such initial DNSKEY or DS re-establish an authentication path. If no such initial DNSKEY or DS
RR exists, the resolver can not authenticate RRsets in or below the RR exists, the validator can not authenticate RRsets in or below the
child zone. child zone.
If the validator does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
Note that, for a signed delegation, there are two NSEC RRs associated Note that, for a signed delegation, there are two NSEC RRs associated
with the delegated name. One NSEC RR resides in the parent zone, and with the delegated name. One NSEC RR resides in the parent zone, and
can be used to prove whether a DS RRset exists for the delegated can be used to prove whether a DS RRset exists for the delegated
name. The second NSEC RR resides in the child zone, and identifies name. The second NSEC RR resides in the child zone, and identifies
which RRsets are present at the apex of the child zone. The parent which RRsets are present at the apex of the child zone. The parent
NSEC RR and child NSEC RR can always be distinguished, since the SOA NSEC RR and child NSEC RR can always be distinguished, since the SOA
bit will be set in the child NSEC RR and clear in the parent NSEC RR. bit will be set in the child NSEC RR and clear in the parent NSEC RR.
A security-aware resolver MUST use the parent NSEC RR when attempting A security-aware resolver MUST use the parent NSEC RR when attempting
to prove that a DS RRset does not exist. to prove that a DS RRset does not exist.
If the resolver does not support any of the algorithms listed in an If the resolver does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver will not be able to verify authenticated DS RRset, then the resolver will not be able to verify
the authentication path to the child zone. In this case, the the authentication path to the child zone. In this case, the
resolver SHOULD treat the child zone as if it were unsigned. resolver SHOULD treat the child zone as if it were unsigned.
5.3 Authenticating an RRset Using an RRSIG RR 5.3 Authenticating an RRset Using an RRSIG RR
A resolver can use an RRSIG RR and its corresponding DNSKEY RR to A validator can use an RRSIG RR and its corresponding DNSKEY RR to
attempt to authenticate RRsets. The resolver first checks the RRSIG attempt to authenticate RRsets. The validator first checks the RRSIG
RR to verify that it covers the RRset, has a valid time interval, and RR to verify that it covers the RRset, has a valid time interval, and
identifies a valid DNSKEY RR. The resolver then constructs the identifies a valid DNSKEY RR. The validator then constructs the
canonical form of the signed data by appending the RRSIG RDATA canonical form of the signed data by appending the RRSIG RDATA
(excluding the Signature Field) with the canonical form of the (excluding the Signature Field) with the canonical form of the
covered RRset. Finally, resolver uses the public key and signature covered RRset. Finally, the validator uses the public key and
to authenticate the signed data. Section 5.3.1, Section 5.3.2, and signature to authenticate the signed data. Section 5.3.1, Section
Section 5.3.3 describe each step in detail. 5.3.2, and Section 5.3.3 describe each step in detail.
5.3.1 Checking the RRSIG RR Validity 5.3.1 Checking the RRSIG RR Validity
A security-aware resolver can use an RRSIG RR to authenticate an A security-aware resolver can use an RRSIG RR to authenticate an
RRset if all of the following conditions hold: RRset if all of the following conditions hold:
o The RRSIG RR and the RRset MUST have the same owner name and the o The RRSIG RR and the RRset MUST have the same owner name and the
same class; same class;
o The RRSIG RR's Signer's Name field MUST be the name of the zone o The RRSIG RR's Signer's Name field MUST be the name of the zone
that contains the RRset; that contains the RRset;
o The RRSIG RR's Type Covered field MUST equal the RRset's type; o The RRSIG RR's Type Covered field MUST equal the RRset's type;
o The number of labels in the RRset owner name MUST be greater than o The number of labels in the RRset owner name MUST be greater than
or equal to the value in the RRSIG RR's Labels field; or equal to the value in the RRSIG RR's Labels field;
o The validator's notion of the current time MUST be less than or
o The resolver's notion of the current time MUST be less than or
equal to the time listed in the RRSIG RR's Expiration field; equal to the time listed in the RRSIG RR's Expiration field;
o The validator's notion of the current time MUST be greater than or
o The resolver's notion of the current time MUST be greater than or
equal to the time listed in the RRSIG RR's Inception field; equal to the time listed in the RRSIG RR's Inception field;
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
match the owner name, algorithm, and key tag for some DNSKEY RR in match the owner name, algorithm, and key tag for some DNSKEY RR in
the zone's apex DNSKEY RRset; the zone's apex DNSKEY RRset;
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
set to one. set to one.
It is possible for more than one DNSKEY RR to match the conditions It is possible for more than one DNSKEY RR to match the conditions
above. In this case, the resolver can not predetermine which DNSKEY above. In this case, the validator cannot predetermine which DNSKEY
RR to use to authenticate the signature, MUST try each matching RR to use to authenticate the signature, MUST try each matching
DNSKEY RR until the resolver has either validated the signature or DNSKEY RR until either the signature is validated or the validator
has run out of matching public keys to try. has run out of matching public keys to try.
Note that this authentication process is only meaningful if the Note that this authentication process is only meaningful if the
resolver authenticates the DNSKEY RR before using it to validate validator authenticates the DNSKEY RR before using it to validate
signatures. The matching DNSKEY RR is considered to be authentic if: signatures. The matching DNSKEY RR is considered to be authentic if:
o The apex DNSKEY RRset containing the DNSKEY RR is considered o The apex DNSKEY RRset containing the DNSKEY RR is considered
authentic; or authentic; or
o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
and the DNSKEY RR either matches an authenticated DS RR from the and the DNSKEY RR either matches an authenticated DS RR from the
parent zone or matches a DS RR or DNSKEY RR that the resolver has parent zone or matches a trust anchor.
been preconfigured to believe to be authentic.
5.3.2 Reconstructing the Signed Data 5.3.2 Reconstructing the Signed Data
Once the RRSIG RR has met the validity requirements described in Once the RRSIG RR has met the validity requirements described in
Section 5.3.1, the resolver needs to reconstruct the original signed Section 5.3.1, the validator needs to reconstruct the original signed
data. The original signed data includes RRSIG RDATA (excluding the data. The original signed data includes RRSIG RDATA (excluding the
Signature field) and the canonical form of the RRset. Aside from Signature field) and the canonical form of the RRset. Aside from
being ordered, the canonical form of the RRset might also differ from being ordered, the canonical form of the RRset might also differ from
the received RRset due to DNS name compression, decremented TTLs, or the received RRset due to DNS name compression, decremented TTLs, or
wildcard expansion. The resolver should use the following to wildcard expansion. The validator should use the following to
reconstruct the original signed data: reconstruct the original signed data:
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
"|" denotes concatenation "|" denotes concatenation
RRSIG_RDATA is the wire format of the RRSIG RDATA fields RRSIG_RDATA is the wire format of the RRSIG RDATA fields
with the Signature field excluded and the Signer's Name with the Signature field excluded and the Signer's Name
in canonical form. in canonical form.
RR(i) = name | class | type | OrigTTL | RDATA length | RDATA RR(i) = name | type | class | 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 RRSIG Original TTL field OrigTTL is the value from the RRSIG Original TTL field
All names in the RDATA field are in canonical form All names in the RDATA field are in canonical form
skipping to change at page 31, line 39 skipping to change at page 30, line 30
zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
zone. zone.
Note also that each of the two NSEC RRsets at a delegation point has Note also that each of the two NSEC RRsets at a delegation point has
a corresponding RRSIG RR with an owner name matching the delegated a corresponding RRSIG RR with an owner name matching the delegated
name, and each of these RRSIG RRs is authoritative data associated name, and each of these RRSIG RRs is authoritative data associated
with the same zone that contains the corresponding NSEC RRset. If with the same zone that contains the corresponding NSEC RRset. If
necessary, a resolver can tell these RRSIG RRs apart by checking the necessary, a resolver can tell these RRSIG RRs apart by checking the
Signer's Name field. Signer's Name field.
5.3.3 Checking the Signature 5.3.3 Checking the Signature
Once the resolver has validated the RRSIG RR as described in Section Once the resolver has validated the RRSIG RR as described in Section
5.3.1 and reconstructed the original signed data as described in 5.3.1 and reconstructed the original signed data as described in
Section 5.3.2, the resolver can attempt to use the cryptographic Section 5.3.2, the validator can attempt to use the cryptographic
signature to authenticate the signed data, and thus (finally!) signature to authenticate the signed data, and thus (finally!)
authenticate the RRset. authenticate the RRset.
The Algorithm field in the RRSIG RR identifies the cryptographic The Algorithm field in the RRSIG RR identifies the cryptographic
algorithm used to generate the signature. The signature itself is algorithm used to generate the signature. The signature itself is
contained in the Signature field of the RRSIG RDATA, and the public contained in the Signature field of the RRSIG RDATA, and the public
key used to verify the signature is contained in the Public Key field key used to verify the signature is contained in the Public Key field
of the matching DNSKEY RR(s) (found in Section 5.3.1). of the matching DNSKEY RR(s) (found in Section 5.3.1).
[I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types
[I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
and provides pointers to the documents that define each algorithm's and provides pointers to the documents that define each algorithm's
use. use.
Note that it is possible for more than one DNSKEY RR to match the Note that it is possible for more than one DNSKEY RR to match the
conditions in Section 5.3.1. In this case, the resolver can only conditions in Section 5.3.1. In this case, the validator can only
determine which DNSKEY RR by trying each matching public key until determine which DNSKEY RR by trying each matching public key until
the resolver either succeeds in validating the signature or runs out the validator either succeeds in validating the signature or runs out
of keys to try. of keys to try.
If the Labels field of the RRSIG RR is not equal to the number of If the Labels field of the RRSIG RR is not equal to the number of
labels in the RRset's fully qualified owner name, then the RRset is labels in the RRset's fully qualified owner name, then the RRset is
either invalid or the result of wildcard expansion. The resolver either invalid or the result of wildcard expansion. The resolver
MUST verify that wildcard expansion was applied properly before MUST verify that wildcard expansion was applied properly before
considering the RRset to be authentic. Section 5.3.4 describes how considering the RRset to be authentic. Section 5.3.4 describes how
to determine whether a wildcard was applied properly. to determine whether a wildcard was applied properly.
If other RRSIG RRs also cover this RRset, the local resolver security If other RRSIG RRs also cover this RRset, the local resolver security
policy determines whether the resolver also needs to test these RRSIG policy determines whether the resolver also needs to test these RRSIG
RRs, and determines how to resolve conflicts if these RRSIG RRs lead RRs, and determines how to resolve conflicts if these RRSIG RRs lead
to differing results. to differing results.
If the resolver accepts the RRset as authentic, the resolver MUST set If the resolver accepts the RRset as authentic, the validator MUST
the TTL of the RRSIG RR and each RR in the authenticated RRset to a set the TTL of the RRSIG RR and each RR in the authenticated RRset to
value no greater than the minimum of: a value no greater than the minimum of:
o The RRset's TTL as received in the response; o The RRset's TTL as received in the response;
o The RRSIG RR's TTL as received in the response;
o The value in the RRSIG RR's Original TTL field; and
o The difference of the RRSIG RR's Signature Expiration time and the
current time.
o The RRSIG RR's TTL as received in the response; and 5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
o The value in the RRSIG RR's Original TTL field.
5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
If the number of labels in an RRset's owner name is greater than the If the number of labels in an RRset's owner name is greater than the
Labels field of the covering RRSIG RR, then the RRset and its Labels field of the covering RRSIG RR, then the RRset and its
covering RRSIG RR were created as a result of wildcard expansion. covering RRSIG RR were created as a result of wildcard expansion.
Once the resolver has verified the signature as described in Section Once the validator has verified the signature as described in Section
5.3, the resolver must take additional steps to verify the 5.3, it must take additional steps to verify the non-existence of an
non-existence of an exact match or closer wildcard match for the exact match or closer wildcard match for the query. Section 5.4
query. Section 5.4 discusses these steps. discusses these steps.
Note that the response received by the resolver should include all Note that the response received by the resolver should include all
NSEC RRs needed to authenticate the response (see Section 3.1.3). NSEC RRs needed to authenticate the response (see Section 3.1.3).
5.4 Authenticated Denial of Existence 5.4 Authenticated Denial of Existence
A resolver can use authenticated NSEC RRs to prove that an RRset is A resolver can use authenticated NSEC RRs to prove that an RRset is
not present in a signed zone. Security-aware name servers should not present in a signed zone. Security-aware name servers should
automatically include any necessary NSEC RRs for signed zones in automatically include any necessary NSEC RRs for signed zones in
their responses to security-aware resolvers. their responses to security-aware resolvers.
Security-aware resolvers MUST first authenticate NSEC RRsets Security-aware resolvers MUST first authenticate NSEC RRsets
according to the standard RRset authentication rules described in according to the standard RRset authentication rules described in
Section 5.3, then apply the NSEC RRsets as follows: Section 5.3, then apply the NSEC RRsets as follows:
o If the requested RR name matches the owner name of an o If the requested RR name matches the owner name of an
authenticated NSEC RR, then the NSEC RR's type bit map field lists authenticated NSEC RR, then the NSEC RR's type bit map field lists
all RR types present at that owner name, and a resolver can prove all RR types present at that owner name, and a resolver can prove
that the requested RR type does not exist by checking for the RR that the requested RR type does not exist by checking for the RR
type in the bit map. If the number of labels in an authenticated type in the bit map. If the number of labels in an authenticated
NSEC RR's owner name equals the Labels field of the covering RRSIG NSEC RR's owner name equals the Labels field of the covering RRSIG
RR, then the existence of the NSEC RR proves that wildcard RR, then the existence of the NSEC RR proves that wildcard
expansion could not have been used to match the request. expansion could not have been used to match the request.
o If the requested RR name would appear after an authenticated NSEC o If the requested RR name would appear after an authenticated NSEC
RR's owner name and before the name listed in that NSEC RR's Next RR's owner name and before the name listed in that NSEC RR's Next
Domain Name field according to the canonical DNS name order Domain Name field according to the canonical DNS name order
defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
the requested name exist in the zone. However, it is possible the requested name exist in the zone. However, it is possible
that a wildcard could be used to match the requested RR owner name that a wildcard could be used to match the requested RR owner name
and type, so proving that the requested RRset does not exist also and type, so proving that the requested RRset does not exist also
requires proving that no possible wildcard RRset exists that could requires proving that no possible wildcard RRset exists that could
have been used to generate a positive response. have been used to generate a positive response.
skipping to change at page 33, line 43 skipping to change at page 32, line 29
verify both that the queried RRset does not exist and that no verify both that the queried RRset does not exist and that no
relevant wildcard RRset exists. Proving this may require more than relevant wildcard RRset exists. Proving this may require more than
one NSEC RRset from the zone. If the complete set of necessary NSEC one NSEC RRset from the zone. If the complete set of necessary NSEC
RRsets is not present in a response (perhaps due to message RRsets is not present in a response (perhaps due to message
truncation), then a security-aware resolver MUST resend the query in truncation), then a security-aware resolver MUST resend the query in
order to attempt to obtain the full collection of NSEC RRs necessary order to attempt to obtain the full collection of NSEC RRs necessary
to verify non-existence of the requested RRset. As with all DNS to verify non-existence of the requested RRset. As with all DNS
operations, however, the resolver MUST bound the work it puts into operations, however, the resolver MUST bound the work it puts into
answering any particular query. answering any particular query.
Since a verified NSEC RR proves the existence of both itself and its Since a validated NSEC RR proves the existence of both itself and its
corresponding RRSIG RR, a verifier MUST ignore the settings of the corresponding RRSIG RR, a validator MUST ignore the settings of the
NSEC and RRSIG bits in an NSEC RR. NSEC and RRSIG bits in an NSEC RR.
5.5 Authentication Example 5.5 Resolver Behavior When Signatures Do Not Validate
If for whatever reason none of the RRSIGs can be validated, the
response SHOULD be considered BAD. If the validation was being done
to service a recursive query, the name server MUST return RCODE 2 to
the originating client. However, it MUST return the full response if
and only if the original query had the CD bit set. See also Section
4.7 on caching responses that do not validate.
5.6 Authentication Example
Appendix C shows an example the authentication process. Appendix C shows an example the authentication process.
6. IANA Considerations 6. IANA Considerations
[I-D.ietf-dnsext-dnssec-records] contains a review of the IANA [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
considerations introduced by DNSSEC. The additional IANA considerations introduced by DNSSEC. The additional IANA
considerations discussed in this document: considerations discussed in this document:
[RFC2535] reserved the CD and AD bits in the message header. The [RFC2535] reserved the CD and AD bits in the message header. The
meaning of the AD bit was redefined in [RFC3655] and the meaning of meaning of the AD bit was redefined in [RFC3655] and the meaning of
both the CD and AD bit are restated in this document. No new bits in both the CD and AD bit are restated in this document. No new bits in
the DNS message header are defined in this document. the DNS message header are defined in this document.
[RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
and defined its use. The use is restated but not altered in this and defined its use. The use is restated but not altered in this
document. document.
7. Security Considerations 7. Security Considerations
This document describes how the DNS security extensions use public This document describes how the DNS security extensions use public
key cryptography to sign and authenticate DNS resource record sets. key cryptography to sign and authenticate DNS resource record sets.
Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
security considerations related to DNSSEC; see security considerations related to DNSSEC; see
[I-D.ietf-dnsext-dnssec-intro] for considerations specific to the [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
DNSSEC resource record types. DNSSEC resource record types.
An active attacker who can set the CD bit in a DNS query message or An active attacker who can set the CD bit in a DNS query message or
the AD bit in a DNS response message can use these bits to defeat the the AD bit in a DNS response message can use these bits to defeat the
protection which DNSSEC attempts to provide to security-oblivious protection which DNSSEC attempts to provide to security-oblivious
recursive-mode resolvers. For this reason, use of these control bits recursive-mode resolvers. For this reason, use of these control bits
by a security-aware recursive-mode resolver requires a secure by a security-aware recursive-mode resolver requires a secure
channel. See Section 3.2.2 and Section 4.8 for further discussion. channel. See Section 3.2.2 and Section 4.9 for further discussion.
The protocol described in this document attempts to extend the The protocol described in this document attempts to extend the
benefits of DNSSEC to security-oblivious stub resolvers. However, benefits of DNSSEC to security-oblivious stub resolvers. However,
since recovery from validation failures is likely to be specific to since recovery from validation failures is likely to be specific to
particular applications, the facilities that DNSSEC provides for stub particular applications, the facilities that DNSSEC provides for stub
resolvers may prove inadequate. Operators of security-aware resolvers may prove inadequate. Operators of security-aware
recursive name servers will need to pay close attention to the recursive name servers will need to pay close attention to the
behavior of the applications which use their services when choosing a behavior of the applications which use their services when choosing a
local validation policy; failure to do so could easily result in the local validation policy; failure to do so could easily result in the
recursive name server accidently denying service to the clients it is recursive name server accidentally denying service to the clients it
intended to support. is intended to support.
8. Acknowledgements 8. Acknowledgements
This document was created from the input and ideas of the members of This document was created from the input and ideas of the members of
the DNS Extensions Working Group and working group mailing list. The the DNS Extensions Working Group and working group mailing list. The
editors would like to express their thanks for the comments and editors would like to express their thanks for the comments and
suggestions received during the revision of these security extension suggestions received during the revision of these security extension
specifications. While explicitly listing everyone who has specifications. While explicitly listing everyone who has
contributed during the decade during which DNSSEC has been under contributed during the decade during which DNSSEC has been under
development would be an impossible task, development would be an impossible task,
[I-D.ietf-dnsext-dnssec-intro] includes a list of some of the [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
participants who were kind enough to comment on these documents. participants who were kind enough to comment on these documents.
Normative References 9. References
9.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-08 (work in progress),
May 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001. message size requirements", RFC 3226, December 2001.
[I-D.ietf-dnsext-dnssec-intro] 9.2 Informative References
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-09 (work in progress),
February 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-07 (work in progress),
February 2004.
Informative References [I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "KEY RR Secure Entry Point Flag",
draft-ietf-dnsext-nsec-rdata-05 (work in progress), March
2004.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003. Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003. (RR)", RFC 3658, December 2003.
[I-D.ietf-dnsext-wcard-clarify]
Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
Domains in the Domain Name System",
draft-ietf-dnsext-wcard-clarify-02 (work in progress),
September 2003.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Drienerlolaan 5
7522 NB Enschede 7522 NB Enschede
NL NL
EMail: roy.arends@telin.nl EMail: roy.arends@telin.nl
skipping to change at page 39, line 4 skipping to change at page 37, line 41
EMail: roy.arends@telin.nl EMail: roy.arends@telin.nl
Matt Larson Matt Larson
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Rob Austein Rob Austein
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: sra@isc.org EMail: sra@isc.org
Dan Massey Dan Massey
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive 3811 N. Fairfax Drive
Arlington, VA 22203 Arlington, VA 22203
USA USA
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. Signed Zone Example Appendix A. Signed Zone Example
The following example shows a (small) complete signed zone. The following example shows a (small) complete signed zone.
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1071609350 1081539377
3600 3600
300 300
3600000 3600000
3600 3600
) )
3600 RRSIG SOA 5 1 3600 20040115201552 ( 3600 RRSIG SOA 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
owLe/OV+Qqqic7ShV/S9l2YJF9I= ) jV7j86HyQgM5e7+miRAz8V01b0I= )
3600 NS ns1.example. 3600 NS ns1.example.
3600 NS ns2.example. 3600 NS ns2.example.
3600 RRSIG NS 5 1 3600 20040115201552 ( 3600 RRSIG NS 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
FTVyQbVkcaxQ6U2FbZtMbfo//go= ) 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
3600 MX 1 xx.example. 3600 MX 1 xx.example.
3600 RRSIG MX 5 1 3600 20040115201552 ( 3600 RRSIG MX 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
7wxkDWyzgasGiMNIKgYrm9vXz04= ) W6OISukd1EQt7a0kygkg+PEDxdI= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
3600 RRSIG NSEC 5 1 3600 20040115201552 ( 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
7T/nOEOVZujD8IN/Utv+KUg+P6U= ) jfFJ5arXf4nPxp/kEowGgBRzY/U= )
3600 DNSKEY 256 3 5 ( 3600 DNSKEY 256 3 5 (
AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
) )
3600 DNSKEY 257 3 5 ( 3600 DNSKEY 257 3 5 (
AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
) )
3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 9465 example.
Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
PjJstq6fvRq8kX7TPJcljUmDFKM= ) NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
20031216201552 60717 example. 20040409183619 38519 example.
EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) 7z5OXogYVaFzHKillDt3HRxHIZM= )
a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns1.a.example.
3600 IN NS ns2.a.example. 3600 IN NS ns2.a.example.
3600 DS 48327 5 1 ( 3600 DS 57855 5 1 (
DFEB5E00E71A4DED5CABBBD7F15F24871983 B6DCD485719ADCA18E5F3D48A2331627FDD3
CAB7 ) 636B )
3600 RRSIG DS 5 2 3600 20040115201552 ( 3600 RRSIG DS 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
0yfe2uolEkeegjesDZuF+fC61Eg= ) Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
3600 NSEC ai.example. NS DS RRSIG NSEC 3600 NSEC ai.example. NS DS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
YgfAHJEJJj7K88QbKEK4/Je1hyk= ) sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
ns1.a.example. 3600 IN A 192.0.2.5 ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6 ns2.a.example. 3600 IN A 192.0.2.6
ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 IN A 192.0.2.9
3600 RRSIG A 5 2 3600 20040115201552 ( 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
sWifTxvcG5hv+A6TOd0O2xJYRik= ) 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
3600 HINFO "KLH-10" "ITS" 3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 5 2 3600 20040115201552 ( 3600 RRSIG HINFO 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
xo9NLoltg0GuwggZM240pRoTwO8= ) FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
3600 AAAA 2001:db8::f00:baa9 3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 5 2 3600 20040115201552 ( 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) sZM6QjBBLmukH30+w1z3h8PUP2o= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) AhS+JOVfDI/79QtyTI0SaDWcg8U= )
b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns1.b.example.
3600 IN NS ns2.b.example. 3600 IN NS ns2.b.example.
3600 NSEC ns1.example. NS RRSIG NSEC 3600 NSEC ns1.example. NS RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) vhRXgWT7OuFXldoCG6TfVFMs9xE= )
ns1.b.example. 3600 IN A 192.0.2.7 ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8 ns2.b.example. 3600 IN A 192.0.2.8
ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 IN A 192.0.2.1
3600 RRSIG A 5 2 3600 20040115201552 ( 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) v/iVXSYC0b7mPSU+EOlknFpVECs= )
3600 NSEC ns2.example. A RRSIG NSEC 3600 NSEC ns2.example. A RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
I2A5W86mMEbSgEF/pZHX/wi5FJI= ) IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 IN A 192.0.2.2
3600 RRSIG A 5 2 3600 20040115201552 ( 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
3600 NSEC *.w.example. A RRSIG NSEC 3600 NSEC *.w.example. A RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
*.w.example. 3600 IN MX 1 ai.example. *.w.example. 3600 IN MX 1 ai.example.
3600 RRSIG MX 5 2 3600 20040115201552 ( 3600 RRSIG MX 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
91Ena87PA2MvoOE+A3ZpEk8MjEE= ) 4kX18MMR34i8lC36SR5xBni8vHI= )
3600 NSEC x.w.example. MX RRSIG NSEC 3600 NSEC x.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
/RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) s1InQ2UoIv6tJEaaKkP701j8OLA= )
x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 5 3 3600 20040115201552 ( 3600 RRSIG MX 5 3 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
btznHMFDIbtuw/tAX7xXH2pDDHY= ) jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 NSEC x.y.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 3 3600 20040115201552 ( 3600 RRSIG NSEC 5 3 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
3lMXiX4KNWUhB87q/pT/5z+xrqY= ) IjgiM8PXkBQtxPq37wDKALkyn7Q= )
x.y.w.example. 3600 IN MX 1 xx.example. x.y.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 5 4 3600 20040115201552 ( 3600 RRSIG MX 5 4 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) +gLcMZBnHJ326nb/TOOmrqNmQQE= )
3600 NSEC xx.example. MX RRSIG NSEC 3600 NSEC xx.example. MX RRSIG NSEC
3600 RRSIG NSEC 5 4 3600 20040115201552 ( 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
viOQHZ6I4xoZQP5G7r98/PhlrLM= ) QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 IN A 192.0.2.10
3600 RRSIG A 5 2 3600 20040115201552 ( 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
0ToQVY81bPc3WXKZjRxQl3jiKtU= ) kbIDV6GPPSZVusnZU6OMgdgzHV4= )
3600 HINFO "KLH-10" "TOPS-20" 3600 HINFO "KLH-10" "TOPS-20"
3600 RRSIG HINFO 5 2 3600 20040115201552 ( 3600 RRSIG HINFO 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
EDXT07qFXtGntvBSpF9uQbEub6Y= ) RgNvuwbioFSEuv2pNlkq0goYxNY= )
3600 AAAA 2001:db8::f00:baaa 3600 AAAA 2001:db8::f00:baaa
3600 RRSIG AAAA 5 2 3600 20040115201552 ( 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
D4ZubIon0XGe9fIjLnmb3pX/FUk= ) xS9cL2QgW7FChw16mzlkH6/vsfs= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 NSEC example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 5 2 3600 20040115201552 ( 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
sSNF3PAC0HPadh7SdHmXlFQtQ44= ) GghLahumFIpg4MO3LS/prgzVVWo= )
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
Flags indicate that each of these DNSKEY RRs is a zone key. One of Flags indicate that each of these DNSKEY RRs is a zone key. One of
these DNSKEY RRs also has the SEP flag set and has been used to sign these DNSKEY RRs also has the SEP flag set and has been used to sign
the apex DNSKEY RRset; this is the key which should be hashed to the apex DNSKEY RRset; this is the key which should be hashed to
generate a DS record to be inserted into the parent zone. The other generate a DS record to be inserted into the parent zone. The other
DNSKEY is used to sign all the other RRsets in the zone. DNSKEY is used to sign all the other RRsets in the zone.
The zone includes a wildcard entry "*.w.example". Note that the name The zone includes a wildcard entry "*.w.example". Note that the name
"*.w.example" is used in constructing NSEC chains, and that the RRSIG "*.w.example" is used in constructing NSEC chains, and that the RRSIG
covering the "*.w.example" MX RRset has a label count of 2. covering the "*.w.example" MX RRset has a label count of 2.
The zone also includes two delegations. The delegation to The zone also includes two delegations. The delegation to
"b.example" includes an NS RRset, glue address records, and an NSEC "b.example" includes an NS RRset, glue address records, and an NSEC
RR; note that only the NSEC RRset is signed. The delegation to RR; note that only the NSEC RRset is signed. The delegation to
"a.example" provides a DS RR; note that only the NSEC and DS RRsets "a.example" provides a DS RR; note that only the NSEC and DS RRsets
are signed. are signed.
Appendix B. Example Responses Appendix B. Example Responses
The examples in this section show response messages using the signed The examples in this section show response messages using the signed
zone example in Appendix A. zone example in Appendix A.
B.1 Answer B.1 Answer
A successful query to an authoritative server. A successful query to an authoritative server.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
x.w.example. IN MX x.w.example. IN MX
;; Answer ;; Answer
x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 IN MX 1 xx.example.
x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
btznHMFDIbtuw/tAX7xXH2pDDHY= ) jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
;; Authority ;; Authority
example. 3600 NS ns1.example. example. 3600 NS ns1.example.
example. 3600 NS ns2.example. example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040115201552 ( example. 3600 RRSIG NS 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
FTVyQbVkcaxQ6U2FbZtMbfo//go= ) 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
;; Additional ;; Additional
xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 IN A 192.0.2.10
xx.example. 3600 RRSIG A 5 2 3600 20040115201552 ( xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
0ToQVY81bPc3WXKZjRxQl3jiKtU= ) kbIDV6GPPSZVusnZU6OMgdgzHV4= )
xx.example. 3600 AAAA 2001:db8::f00:baaa xx.example. 3600 AAAA 2001:db8::f00:baaa
xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
D4ZubIon0XGe9fIjLnmb3pX/FUk= ) xS9cL2QgW7FChw16mzlkH6/vsfs= )
ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 IN A 192.0.2.1
ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) v/iVXSYC0b7mPSU+EOlknFpVECs= )
ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 IN A 192.0.2.2
ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
B.2 Name Error B.2 Name Error
An authoritative name error. The NSEC RRs prove that the name does An authoritative name error. The NSEC RRs prove that the name does
not exist and that no covering wildcard exists. not exist and that no covering wildcard exists.
;; Header: QR AA DO RCODE=3 ;; Header: QR AA DO RCODE=3
;; ;;
;; Question ;; Question
ml.example. IN A ml.example. IN A
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1071609350 1081539377
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
owLe/OV+Qqqic7ShV/S9l2YJF9I= ) jV7j86HyQgM5e7+miRAz8V01b0I= )
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) vhRXgWT7OuFXldoCG6TfVFMs9xE= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
7T/nOEOVZujD8IN/Utv+KUg+P6U= ) jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional ;; Additional
;; (empty) ;; (empty)
B.3 No Data Error B.3 No Data Error
A "NODATA" response. The NSEC RR proves that the name exists and A "NODATA" response. The NSEC RR proves that the name exists and
that the requested RR type does not. that the requested RR type does not.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
ns1.example. IN MX ns1.example. IN MX
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1071609350 1081539377
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
owLe/OV+Qqqic7ShV/S9l2YJF9I= ) jV7j86HyQgM5e7+miRAz8V01b0I= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
I2A5W86mMEbSgEF/pZHX/wi5FJI= ) IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
;; Additional ;; Additional
;; (empty) ;; (empty)
B.4 Referral to Signed Zone B.4 Referral to Signed Zone
Referral to a signed zone. The DS RR contains the data which the Referral to a signed zone. The DS RR contains the data which the
resolver will need to validate the corresponding DNSKEY RR in the resolver will need to validate the corresponding DNSKEY RR in the
child zone's apex. child zone's apex.
;; Header: QR DO RCODE=0 ;; Header: QR DO RCODE=0
;; ;;
;; Question ;; Question
mc.a.example. IN MX mc.a.example. IN MX
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
a.example. 3600 IN NS ns1.a.example. a.example. 3600 IN NS ns1.a.example.
a.example. 3600 IN NS ns2.a.example. a.example. 3600 IN NS ns2.a.example.
a.example. 3600 DS 48327 5 1 ( a.example. 3600 DS 57855 5 1 (
DFEB5E00E71A4DED5CABBBD7F15F24871983 B6DCD485719ADCA18E5F3D48A2331627FDD3
CAB7 ) 636B )
a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
0yfe2uolEkeegjesDZuF+fC61Eg= ) Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
;; Additional ;; Additional
ns1.a.example. 3600 IN A 192.0.2.5 ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6 ns2.a.example. 3600 IN A 192.0.2.6
B.5 Referral to Unsigned Zone B.5 Referral to Unsigned Zone
Referral to an unsigned zone. The NSEC RR proves that no DS RR for Referral to an unsigned zone. The NSEC RR proves that no DS RR for
this delegation exists in the parent zone. this delegation exists in the parent zone.
;; Header: QR DO RCODE=0 ;; Header: QR DO RCODE=0
;; ;;
;; Question ;; Question
mc.b.example. IN MX mc.b.example. IN MX
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
b.example. 3600 IN NS ns1.b.example. b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example. b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) vhRXgWT7OuFXldoCG6TfVFMs9xE= )
;; Additional ;; Additional
ns1.b.example. 3600 IN A 192.0.2.7 ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8 ns2.b.example. 3600 IN A 192.0.2.8
B.6 Wildcard Expansion B.6 Wildcard Expansion
A successful query which was answered via wildcard expansion. The A successful query which was answered via wildcard expansion. The
label count in the answer's RRSIG RR indicates that a wildcard RRset label count in the answer's RRSIG RR indicates that a wildcard RRset
was expanded to produce this response, and the NSEC RR proves that no was expanded to produce this response, and the NSEC RR proves that no
closer match exists in the zone. closer match exists in the zone.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
a.z.w.example. IN MX a.z.w.example. IN MX
;; Answer ;; Answer
a.z.w.example. 3600 IN MX 1 ai.example. a.z.w.example. 3600 IN MX 1 ai.example.
a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
91Ena87PA2MvoOE+A3ZpEk8MjEE= ) 4kX18MMR34i8lC36SR5xBni8vHI= )
;; Authority ;; Authority
example. 3600 NS ns1.example. example. 3600 NS ns1.example.
example. 3600 NS ns2.example. example. 3600 NS ns2.example.
example. 3600 RRSIG NS 5 1 3600 20040115201552 ( example. 3600 RRSIG NS 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
FTVyQbVkcaxQ6U2FbZtMbfo//go= ) 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
viOQHZ6I4xoZQP5G7r98/PhlrLM= ) QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
;; Additional ;; Additional
ai.example. 3600 IN A 192.0.2.9 ai.example. 3600 IN A 192.0.2.9
ai.example. 3600 RRSIG A 5 2 3600 20040115201552 ( ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
sWifTxvcG5hv+A6TOd0O2xJYRik= ) 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) sZM6QjBBLmukH30+w1z3h8PUP2o= )
B.7 Wildcard No Data Error B.7 Wildcard No Data Error
A "NODATA" response for a name covered by a wildcard. The NSEC RRs A "NODATA" response for a name covered by a wildcard. The NSEC RRs
prove that the matching wildcard name does not have any RRs of the prove that the matching wildcard name does not have any RRs of the
requested type and that no closer match exists in the zone. requested type and that no closer match exists in the zone.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
a.z.w.example. IN AAAA a.z.w.example. IN AAAA
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1071609350 1081539377
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
owLe/OV+Qqqic7ShV/S9l2YJF9I= ) jV7j86HyQgM5e7+miRAz8V01b0I= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
viOQHZ6I4xoZQP5G7r98/PhlrLM= ) QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
/RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) s1InQ2UoIv6tJEaaKkP701j8OLA= )
;; Additional ;; Additional
;; (empty) ;; (empty)
B.8 DS Child Zone No Data Error B.8 DS Child Zone No Data Error
A "NODATA" response for a QTYPE=DS query which was mistakenly sent to A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
a name server for the child zone. a name server for the child zone.
;; Header: QR AA DO RCODE=0 ;; Header: QR AA DO RCODE=0
;; ;;
;; Question ;; Question
example. IN DS example. IN DS
;; Answer ;; Answer
;; (empty) ;; (empty)
;; Authority ;; Authority
example. 3600 IN SOA ns1.example. bugs.x.w.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1071609350 1081539377
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
owLe/OV+Qqqic7ShV/S9l2YJF9I= ) jV7j86HyQgM5e7+miRAz8V01b0I= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
20031216201552 41681 example. 20040409183619 38519 example.
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
7T/nOEOVZujD8IN/Utv+KUg+P6U= ) jfFJ5arXf4nPxp/kEowGgBRzY/U= )
;; Additional ;; Additional
;; (empty) ;; (empty)
Appendix C. Authentication Examples Appendix C. Authentication Examples
The examples in this section show how the response messages in The examples in this section show how the response messages in
Appendix B are authenticated. Appendix B are authenticated.
C.1 Authenticating An Answer C.1 Authenticating An Answer
The query in section Appendix B.1 returned an MX RRset for The query in section Appendix B.1 returned an MX RRset for
"x.w.example.com". The corresponding RRSIG indicates the MX RRset was "x.w.example.com". The corresponding RRSIG indicates the MX RRset
signed by an "example" DNSKEY with algorithm 5 and key tag 41681. was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
The resolver needs the corresponding DNSKEY RR in order to The resolver needs the corresponding DNSKEY RR in order to
authenticate this answer. The discussion below describes how a authenticate this answer. The discussion below describes how a
resolver might obtain this DNSKEY RR. resolver might obtain this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600 and, The RRSIG indicates the original TTL of the MX RRset was 3600 and,
for the purpose of authentication, the current TTL is replaced by for the purpose of authentication, the current TTL is replaced by
3600. The RRSIG labels field value of 3 indicates the answer was 3600. The RRSIG labels field value of 3 indicates the answer was not
not the result of wildcard expansion. The "x.w.example.com" MX RRset the result of wildcard expansion. The "x.w.example.com" MX RRset is
is placed in canonical form and, assuming the current time falls placed in canonical form and, assuming the current time falls between
between the signature inception and expiration dates, the signature the signature inception and expiration dates, the signature is
is authenticated. authenticated.
C.1.1 Authenticating the example DNSKEY RR C.1.1 Authenticating the example DNSKEY RR
This example shows the logical authentication process that starts This example shows the logical authentication process that starts
from the a preconfigured root DNSKEY (or DS RR) and moves down the from the a configured root DNSKEY (or DS RR) and moves down the tree
tree to authenticate the desired "example" DNSKEY RR. Note the to authenticate the desired "example" DNSKEY RR. Note the logical
logical order is presented for clarity and an implementation may order is presented for clarity and an implementation may choose to
choose to construct the authentication as referrals are received or construct the authentication as referrals are received or may choose
may choose to construct the authentication chain only after all to construct the authentication chain only after all RRsets have been
RRsets have been obtained, or in any other combination it sees fit. obtained, or in any other combination it sees fit. The example here
The example here demonstrates only the logical process and does not demonstrates only the logical process and does not dictate any
dictate any implementation rules. implementation rules.
We assume the resolver starts with an preconfigured DNSKEY RR for the We assume the resolver starts with an configured DNSKEY RR for the
root zone (or a preconfigured DS RR for the root zone). The resolver root zone (or a configured DS RR for the root zone). The resolver
checks this preconfigured DNSKEY RR is present in the root DNSKEY checks this configured DNSKEY RR is present in the root DNSKEY RRset
RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
this DNSKEY RR has signed the root DNSKEY RRset and the signature DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime
lifetime is valid. If all these conditions are met, all keys in the is valid. If all these conditions are met, all keys in the DNSKEY
DNSKEY RRset are considered authenticated. The resolver then uses RRset are considered authenticated. The resolver then uses one (or
one (or more) of the root DNSKEY RRs to authenticate the "example" DS more) of the root DNSKEY RRs to authenticate the "example" DS RRset.
RRset. Note the resolver may need to query the root zone to obtain Note the resolver may need to query the root zone to obtain the root
the root DNSKEY RRset and/or "example" DS RRset. DNSKEY RRset or "example" DS RRset.
Once the DS RRset has been authenticated using the root DNSKEY, the Once the DS RRset has been authenticated using the root DNSKEY, the
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY is found, the resolver checks this DNSKEY matching "example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "example" DNSKEY RRset and the signature lifetime RR has signed the "example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the "example" is valid. If all these conditions are met, all keys in the "example"
DNSKEY RRset are considered authenticated. DNSKEY RRset are considered authenticated.
Finally the resolver checks that some DNSKEY RR in the "example" Finally the resolver checks that some DNSKEY RR in the "example"
DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY
DNSKEY is used to authenticated the RRSIG included in the response. is used to authenticated the RRSIG included in the response. If
If multiple "example" DNSKEY RRs have algorithm 5 and key tag of multiple "example" DNSKEY RRs match this algorithm and key tag, then
41681, then each DNSKEY RR is tried and the answer is authenticated each DNSKEY RR is tried and the answer is authenticated if any of the
if either DNSKEY RR validates the signature as described above. matching DNSKEY RRs validates the signature as described above.
C.2 Name Error C.2 Name Error
The query in section Appendix B.2 returned NSEC RRs that prove the The query in section Appendix B.2 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed authenticated in a manner identical to that of the MX RRset discussed
above. above.
C.3 No Data Error C.3 No Data Error
The query in section Appendix B.3 returned an NSEC RR that proves the The query in section Appendix B.3 returned an NSEC RR that proves the
requested name exists, but the requested RR type does not exist. The requested name exists, but the requested RR type does not exist. The
negative reply is authenticated by verifying the NSEC RR. The NSEC negative reply is authenticated by verifying the NSEC RR. The NSEC
RR is authenticated in a manner identical to that of the MX RRset RR is authenticated in a manner identical to that of the MX RRset
discussed above. discussed above.
C.4 Referral to Signed Zone C.4 Referral to Signed Zone
The query in section Appendix B.4 returned a referral to the signed The query in section Appendix B.4 returned a referral to the signed
"a.example." zone. The DS RR is authenticated in a manner identical "a.example." zone. The DS RR is authenticated in a manner identical
to that of the MX RRset discussed above. This DS RR is used to to that of the MX RRset discussed above. This DS RR is used to
authenticate the "a.example" DNSKEY RRset. authenticate the "a.example" DNSKEY RRset.
Once the "a.example" DS RRset has been authenticated using the Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
for some "a.example" DNSKEY RR that matches the DS RR. If such a for some "a.example" DNSKEY RR that matches the DS RR. If such a
matching "a.example" DNSKEY is found, the resolver checks this DNSKEY matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "a.example" DNSKEY RRset and the signature lifetime RR has signed the "a.example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the is valid. If all these conditions are met, all keys in the
"a.example" DNSKEY RRset are considered authenticated. "a.example" DNSKEY RRset are considered authenticated.
C.5 Referral to Unsigned Zone C.5 Referral to Unsigned Zone
The query in section Appendix B.5 returned a referral to an unsigned The query in section Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from "b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example" and the NSEC RR is authenticated in a manner "example" to "b.example" and the NSEC RR is authenticated in a manner
identical to that of the MX RRset discussed above. identical to that of the MX RRset discussed above.
C.6 Wildcard Expansion C.6 Wildcard Expansion
The query in section Appendix B.6 returned an answer that was The query in section Appendix B.6 returned an answer that was
produced as a result of wildcard expansion. The RRset expanded as produced as a result of wildcard expansion. The RRset expanded as the
the similar to The corresponding RRSIG indicates the MX RRset was similar to The corresponding RRSIG indicates the MX RRset was signed
signed by an "example" DNSKEY with algorithm 5 and key tag 41681. by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG
The RRSIG indicates the original TTL of the MX RRset was 3600 and, indicates the original TTL of the MX RRset was 3600 and, for the
for the purpose of authentication, the current TTL is replaced by purpose of authentication, the current TTL is replaced by 3600. The
3600. The RRSIG labels field value of 2 indicates the answer the RRSIG labels field value of 2 indicates the answer the result of
result of wildcard expansion since the "a.z.w.example" name contains wildcard expansion since the "a.z.w.example" name contains 4 labels.
4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
the MX RRset is placed in canonical form and, assuming the current is placed in canonical form and, assuming the current time falls
time falls between the signature inception and expiration dates, the between the signature inception and expiration dates, the signature
signature is authenticated. is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query and the NSEC RR must also be have been used to answer this query and the NSEC RR must also be
authenticated before the answer is considered valid. authenticated before the answer is considered valid.
C.7 Wildcard No Data Error C.7 Wildcard No Data Error
The query in section Appendix B.7 returned NSEC RRs that prove the The query in section Appendix B.7 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. reply is authenticated by verifying both NSEC RRs.
C.8 DS Child Zone No Data Error C.8 DS Child Zone No Data Error
The query in section Appendix B.8 returned NSEC RRs that shows the The query in section Appendix B.8 returned NSEC RRs that shows the
requested was answered by a child server ("example" server). The requested was answered by a child server ("example" server). The
NSEC RR indicates the presence of an SOA RR, showing the answer is NSEC RR indicates the presence of an SOA RR, showing the answer is
from the child . Queries for the "example" DS RRset should be sent from the child . Queries for the "example" DS RRset should be sent
to the parent servers ("root" servers). to the parent servers ("root" servers).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
skipping to change at page 58, line 7 skipping to change at page 58, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 260 change blocks. 
827 lines changed or deleted 853 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/