draft-ietf-dnsext-dnssec-protocol-03.txt   draft-ietf-dnsext-dnssec-protocol-04.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: April 26, 2004 M. Larson Expires: June 16, 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
October 27, 2003 December 17, 2003
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-03 draft-ietf-dnsext-dnssec-protocol-04
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 April 26, 2004. This Internet-Draft will expire on June 16, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents which 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 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . 8 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 9 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 10 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 11 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14
3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 14 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16
3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 15 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17
3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 16 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 18 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 21 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 23 4.3 Determining Security Status of Data . . . . . . . . . . . . 21
5.1 Special Considerations for Islands of Security . . . . . . . 24 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 21
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 24 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 25 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 26 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 27 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 28 4.8.1 ENDS Support . . . . . . . . . . . . . . . . . . . . . . . . 23
4.8.2 Handling of the CD and AD Bits . . . . . . . . . . . . . . . 23
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
5.1 Special Considerations for Islands of Security . . . . . . . 26
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 27
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 28
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 29
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.4 Authenticating A Wildcard Expanded RRset Positive
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 29 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
Informative References . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 Informative References . . . . . . . . . . . . . . . . . . . 37
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37
B. Example Responses . . . . . . . . . . . . . . . . . . . . . 43 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 39
B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B. Example Responses . . . . . . . . . . . . . . . . . . . . . 45
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 44 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 45 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 46 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 47
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 47 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 48
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 47 B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 49
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 48 B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 49
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 49 B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 50
C. Authentication Examples . . . . . . . . . . . . . . . . . . 51 B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 51
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 51 C. Authentication Examples . . . . . . . . . . . . . . . . . . 53
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 51 C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 53
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 52 C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 53
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 52 C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 54
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 52 C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 54
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 52 C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 54
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 53 C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 54
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 53 C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 55
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 53 C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 54 C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56
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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
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. Any zone which does not include these Section 2.4, respectively. Any zone which does not include these
records according to the rules in this section MUST be considered records according to the rules in this section MUST be considered
unsigned for the purposes of the DNS security extensions. unsigned for the purposes of the DNS security extensions.
DNSSEC requires a change to the definition of the CNAME resource DNSSEC requires a change to the definition of the CNAME resource
record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs
to appear at the same owner name as a CNAME RR. to appear at the same owner name as a CNAME RR.
Section 2.6 shows a sample signed zone.
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 create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR
stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the
flags RDATA field set to one -- see Section 2.1.1 of flags RDATA field set to one -- see Section 2.1.1 of
[I-D.ietf-dnsext-dnssec-records]. Public keys associated with other [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other
DNS operations MAY be stored in DNSKEY RRs that are not marked as DNS operations MAY be stored in DNSKEY RRs that are not marked as
skipping to change at page 7, line 4 skipping to change at page 6, line 51
For each authoritative RRset in a signed zone (which excludes both NS For each authoritative RRset in a signed zone (which excludes both NS
RRsets at delegation points and glue RRsets), there MUST be at least RRsets at delegation points and glue RRsets), 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 wildcard label if the owner name is a wildcard; counting the wildcard label if the owner name 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
skipping to change at page 8, line 6 skipping to change at page 8, line 4
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 RRsets. Note, however, that this distinction is for the most part
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.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 MUST have an NSEC resource record, except delegation point NS RRset MUST have an NSEC resource record. The
for the owner names of any glue address RRsets. The process for process for constructing the NSEC RR for a given name is described in
constructing the NSEC RR for a given name is described in
[I-D.ietf-dnsext-dnssec-records]. [I-D.ietf-dnsext-dnssec-records].
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
RRsets at any particular owner name. That is, the signing process
MUST NOT create (or RRSIG) RRs for owner names nodes which were not
the owner name of any RRset before the zone was signed.
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.
2.4 Including DS RRs in a Zone 2.4 Including DS RRs in a Zone
The DS resource record establishes authentication chains between DNS The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records, child zone is signed. The DS RRset MAY contain multiple records,
each referencing a key used by the child zone to sign its apex DNSKEY each referencing a public key in the child zone used to verify the
RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
appear at non-delegation points nor at a zone's apex. RRsets MUST NOT appear at non-delegation points nor 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 corresponding NS The TTL of a DS RRset SHOULD match the TTL of the corresponding NS
RRset. 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
skipping to change at page 9, line 37 skipping to change at page 10, line 37
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.
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.2 for details Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details
on the behavior of these bits. on the behavior of these bits.
3.1 Authoritative Name Servers 3.1 Authoritative Name Servers
Upon receiving a relevant query which has the EDNS [RFC2671] OPT Upon receiving a relevant query which 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 which can be used to authenticate a response MUST be o RRSIG RRs which can be used to authenticate a response MUST be
skipping to change at page 12, line 18 skipping to change at page 13, line 18
o An NSEC RR proving that the zone contains no RRsets which would o An NSEC RR proving that the zone contains no RRsets which 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
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.
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
wildcard name expansion when these RRs are included in the Authority
section of the response.
Note that this form of response includes cases in which SNAME
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
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 these answer, NSEC and RRSIG RRs, the name not permit inclusion of these answer, NSEC and RRSIG RRs, the name
skipping to change at page 12, line 50 skipping to change at page 14, line 10
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
wildcard name expansion when these RRs are included in the Authority
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 a particular SNAME does not exist. Locating such
an NSEC RR within an authoritative zone is relatively simple, at an NSEC RR within an authoritative zone is relatively simple, at
least in concept. The following discussion assumes that the name least in concept. The following discussion assumes that the name
skipping to change at page 16, line 33 skipping to change at page 17, line 45
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.
A security-aware recursive name server MUST NOT attempt to answer a
query by piecing together cached data it received in response to
previous queries that requested different QNAMEs, QTYPEs, or
QCLASSes. A security-aware recursive name server MUST NOT use NSEC
RRs from one negative response to synthesize a response for a
different query. A security-aware recursive name server MUST NOT use
a previous wildcard expansion to generate a response to a different
query.
The resolver side MUST follow the usual rules for caching and The resolver side MUST follow the usual rules for caching and
negative caching which would apply to any security-aware resolver. negative 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 but MUST strip any authenticating DNSSEC RRs from the response, but but
skipping to change at page 17, line 48 skipping to change at page 19, line 5
its local policy requires, thus the resolver side of the recursive its local policy requires, thus the resolver side of the recursive
name server need not perform authentication on the RRsets in the name server need not perform authentication on the RRsets in the
response. When the CD bit is set to one the recursive name server response. When the CD bit is set to one the recursive name server
SHOULD, if possible, return the requested data to the originating SHOULD, if possible, return the requested data to the originating
resolver even if the recursive name server's local authentication resolver even if the recursive name server's local authentication
policy would reject the records in question. That is, by setting the policy would reject the records in question. That is, by setting the
CD bit, the originating resolver has indicated that it takes CD bit, the originating resolver has indicated that it takes
responsibility for performing its own authentication, and the responsibility for performing its own authentication, and the
recursive name server should not interfere. recursive name server should not interfere.
If the resolver side implements a BAD cache (see Section 4.1) 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 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
skipping to change at page 19, line 14 skipping to change at page 20, line 14
4. Resolving 4. Resolving
This section describes the behavior of entities which include This section describes the behavior of entities which include
security-aware resolver functions. In many cases such functions will security-aware resolver functions. In many cases such functions will
be part of a security-aware recursive name server, but a stand-alone be part of a security-aware recursive name server, but a stand-alone
security-aware resolver has many of the same requirements. Functions security-aware resolver has many of the same requirements. Functions
specific to security-aware recursive name servers are described in specific to security-aware recursive name servers are described in
Section 3.2. Section 3.2.
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
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
skipping to change at page 20, line 10 skipping to change at page 21, line 14
RRs, since the resolver will have no way of knowing the owner name of RRs, since the resolver will have no way of knowing the owner name of
the missing NSEC RR, but in the specific case of a NODATA response, the missing NSEC RR, but in the specific case of a NODATA response,
the resolver does know the name of the missing NSEC RR, and must the resolver does know the name of the missing NSEC RR, and must
therefore attempt to retrieve it. therefore attempt to retrieve it.
When attempting to retrieve missing NSEC or DS RRs which reside on When attempting to retrieve missing NSEC or DS RRs which reside on
the parental side at a zone cut, a security-aware iterative-mode the parental side at a zone cut, a security-aware iterative-mode
resolver MUST query the name servers for the parent zone, not the resolver MUST query the name servers for the parent zone, not the
child zone. child zone.
4.3 Determining Security Status of Data
A security-aware resolver MUST be able to determine whether or not it A security-aware resolver MUST be able to determine whether or not it
should expect a particular RRset to be signed. More precisely, a should expect a particular RRset to be signed. More precisely, a
security-aware resolver must be able to distinguish between three security-aware resolver must be able to distinguish between three
cases: cases:
1. An RRset for which the resolver is able to build a chain of 1. An RRset for which the resolver is able to build a chain of
signed DNSKEY and DS RRs from a trusted starting point 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 2. An RRset for which the resolver knows that it has no chain of
signed DNSKEY and DS RRs from any trusted starting point to the signed DNSKEY and DS RRs from any trusted starting point to the
RRset. This can occur when the target RRset lies in an unsigned RRset. This can occur when the target RRset lies in an unsigned
zone or in a descendent of an unsigned zone. In this case, the zone or in a descendent of an unsigned zone. In this case, the
RRset may or may not be signed, but the resolver will not be able RRset may or may not be signed, but the resolver will not be able
to verify the signature. to verify the signature.
3. An RRset for which the resolver is not able to determine whether 3. An RRset for which the resolver is not able to determine whether
or not the RRset should be signed, because the resolver is not or not the RRset should be signed, because the resolver is not
able to obtain the necessary DNSSEC RRs. This can occur when the able to obtain the necessary DNSSEC RRs. This can occur when the
security-aware resolver is not able to contact security-aware security-aware resolver is not able to contact security-aware
name servers for the relevant zones. name servers for the relevant zones.
4.4 Preconfigured Public Keys
A security-aware resolver MUST be capable of being preconfigured with A security-aware resolver MUST be capable of being preconfigured with
at least one trusted public key, and MUST be capable of being at least one trusted public key, and SHOULD be capable of being
preconfigured with multiple trusted public keys or DS RRs. Since a preconfigured with multiple trusted public keys or DS RRs. Since a
security-aware resolver will not be able to validate signatures security-aware resolver will not be able to validate signatures
without such a preconfigured trusted key, the resolver SHOULD have without such a preconfigured trusted key, the resolver SHOULD have
some reasonably robust mechanism for obtaining such keys when it some reasonably robust mechanism for obtaining such keys when it
boots. boots.
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, indexed by the triple <QNAME, QTYPE, QCLASS>, with the atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
single atomic entry containing the entire answer, including the named single atomic entry containing the entire answer, including the named
RRset and any associated DNSSEC RRs. The resolver SHOULD discard the RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
entire atomic entry when any of the RRs contained in it expire. entire atomic entry when any of the RRs contained in it expire.
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. messages.
4.1 Rate Limiting 4.7 Rate Limiting
A security-aware resolver SHOULD NOT cache data with invalid A security-aware resolver SHOULD NOT cache data with invalid
signatures under normal circumstances. However, a security-aware signatures under normal circumstances. However, a security-aware
resolver SHOULD take steps to rate limit the number of identical resolver SHOULD take steps to rate limit the number of identical
queries that it generates if signature validation of the responses queries that it generates if signature validation of the responses
fails repeatedly. fails repeatedly.
Conceptually, this is similar in some respects to negative caching Conceptually, this is similar in some respects to negative caching
[RFC2308], but since the resolver has no way of obtaining an [RFC2308], but since the resolver has no way of obtaining an
appropriate caching TTL from received data in this case, the TTL will appropriate caching TTL from received data in this case, the TTL will
skipping to change at page 21, line 48 skipping to change at page 23, line 13
checks while protecting clients which depend on this resolver to checks while protecting clients which depend on this resolver to
perform such checks. Several of the possible reasons why signature perform such checks. Several of the possible reasons why signature
validation might fail involve conditions which may not apply equally validation might fail involve conditions which may not apply equally
to this resolver and the client which invoked it: for example, this to this resolver and the client which invoked it: for example, this
resolver's clock may be set incorrectly, or the client may have resolver's clock may be set incorrectly, or the client may have
knowledge of a relevant island of security which this resolver does knowledge of a relevant island of security which this resolver does
not share. In such cases, "protecting" a client which is capable of not share. In such cases, "protecting" a client which is capable of
performing its own signature validation from ever seeing the "bad" performing its own signature validation from ever seeing the "bad"
data does not help the client. data does not help the client.
4.2 Stub resolvers 4.8 Stub resolvers
4.8.1 ENDS Support
A security-aware stub resolver MUST include an EDNS [RFC2671] OPT A security-aware stub 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 stub resolver MUST support a message size of at A security-aware stub resolver MUST support a message size of at
least 1220 octets, SHOULD support a message size of 4000 octets, and least 1220 octets, SHOULD support a message size of 4000 octets, and
MUST advertise the supported message size using the "sender's UDP MUST advertise the supported message size using the "sender's UDP
payload size" field in the EDNS OPT pseudo-RR. A security-aware stub payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
resolver MUST handle fragmented UDP packets correctly regardless of resolver MUST handle fragmented UDP packets correctly regardless of
whether any such fragmented packets were received via IPv4 or IPv6. whether any such fragmented packets were received via IPv4 or IPv6.
Please see [RFC3226] for discussion of these requirements. Please see [RFC3226] for discussion of these requirements.
A security-aware stub resolver MUST support the DNSSEC RR types, at A security-aware stub resolver MUST support the DNSSEC RR types, at
least to the extent of not mishandling responses just because they least to the extent of not mishandling responses just because they
contain DNSSEC RRs. A security-aware stub resolver MAY include the contain DNSSEC RRs. A security-aware stub resolver MAY include the
DNSSEC RRs returned by a security-aware recursive name server as part DNSSEC RRs returned by a security-aware recursive name server as part
of the data that it the stub resolver hands back to the application of the data that it the stub resolver hands back to the application
which invoked it but is not required to do so. which invoked it but is not required to do so.
4.8.2 Handling of the CD and AD Bits
A security-aware stub resolver SHOULD NOT set the CD bit when sending A security-aware stub resolver SHOULD NOT set the CD bit when sending
queries, since, by definition, a security-aware stub resolver does queries unless requested by the application layer, since by
not validate signatures and thus depends on the security-aware definition, a security-aware stub resolver does not validate
recursive name server to perform validation on its behalf. signatures and thus depends on the security-aware recursive name
server to perform validation on its behalf.
A security-aware stub resolver MAY chose to examine the setting of A security-aware stub resolver MAY chose to examine the setting of
the AD bit in response messages that it receives in order to the AD bit in response messages that it receives in order to
determine whether the security-aware recursive name server which sent determine whether the security-aware recursive name server which sent
the response claims to have cryptographically verified the data in the response claims to have cryptographically verified the data in
the Answer and Authority sections of the response message. Note, the Answer and Authority sections of the response message. Note,
however, that the responses received by a security-aware stub 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 39 skipping to change at page 28, line 39
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 resolver can not 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 the resolver has either validated the signature or
has run out of matching 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 resolver 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
skipping to change at page 28, line 42 skipping to change at page 30, line 42
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 resolver can attempt to use the cryptographic
signature to authenticate the signed data, and thus (finally!) signature to authenticate the signed data, and thus (finally!)
authenticate the RRset. authenticate the RRset.
The Algorithm field in the RRSIG RR identifies the cryptographic The Algorithm field in the RRSIG RR identifies the cryptographic
algorithm 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 to used generate the signature is contained in the Public Key key used to verify the signature is contained in the Public Key field
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 resolver can only
determine which DNSKEY RR by trying each matching key until the determine which DNSKEY RR by trying each matching public key until
resolver either succeeds in validating the signature or runs out of the resolver either succeeds in validating the signature or runs out
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 RRSIG RR, the local resolver If other RRSIG RRs also cover this RRset, the local resolver security
security policy determines whether the resolver also needs to test policy determines whether the resolver also needs to test these RRSIG
these RRSIG RRs, and determines how to resolve conflicts if these RRs, and determines how to resolve conflicts if these RRSIG RRs lead
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 resolver MUST set
the TTL of the RRSIG RR and each RR in the authenticated RRset to a the TTL of the RRSIG RR and each RR in the authenticated RRset to a
value no greater than the minimum of: value no greater than the minimum of:
o The RRset's TTL as received in the response; o The RRset's TTL as received in the response;
o The RRSIG RR's TTL as received in the response; and o The RRSIG RR's TTL as received in the response; and
o The value in the RRSIG RR's Original TTL field. o The value in the RRSIG RR's Original TTL field.
5.3.4 Authenticating A Wildcard Expanded RRset Positive Response 5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
If the number of labels in an RRset's fully qualified domain name is If the number of labels in an RRset's owner name is greater than the
greater than the Labels field in the covering RRSIG RDATA, then the Labels field of the covering RRSIG RR, then the RRset and its
RRset and its covering RRSIG RR were created as a result of wildcard covering RRSIG RR were created as a result of wildcard expansion.
expansion. Once the resolver has verified the signature as described Once the resolver has verified the signature as described in Section
in Section 5.3, the resolver must take additional steps to verify the 5.3, the resolver must take additional steps to verify the
non-existence of an exact match or closer wildcard match for the non-existence of an exact match or closer wildcard match for the
query. Section 5.4 discusses these steps. query. Section 5.4 discusses these steps.
Note that the response received by the resolver should include all Note that the response received by the resolver should include all
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
skipping to change at page 30, line 11 skipping to change at page 32, line 11
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. Since the existence of the authenticated type in the bit map. If the number of labels in an authenticated
NSEC RR proves that the owner name exists in the zone, wildcard NSEC RR's owner name equals the Labels field of the covering RRSIG
expansion could not have been used to match the requested RR owner RR, then the existence of the NSEC RR proves that wildcard
name and type. 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 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 exact match defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
for the requested RR name exists in the zone. However, it is the requested name exist in the zone. However, it is possible
possible that a wildcard could be used to match the requested RR that a wildcard could be used to match the requested RR owner name
owner name and type, so proving that the requested RRset does not and type, so proving that the requested RRset does not exist also
exist also requires proving that no possible wildcard exists which requires proving that no possible wildcard RRset exists which
could have been used to generate a positive response. could have been used to generate a positive response.
To prove non-existence of an RRset, the resolver must be able to To prove non-existence of an RRset, the resolver must be able to
verify both that the queried RRset does not exist and that no verify both that the queried RRset does not exist and that no
relevant wildcard RRset exists. Proving this may require more than relevant wildcard RRset exists. Proving this may require more than
one 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 truncation), then RRsets is not present in a response (perhaps due to message
a security-aware resolver MUST resend the query in order to attempt truncation), then a security-aware resolver MUST resend the query in
to obtain the full collection of NSEC RRs necessary to verify order to attempt to obtain the full collection of NSEC RRs necessary
non-existence of the requested RRset. As with all DNS operations, to verify non-existence of the requested RRset. As with all DNS
however, the resolver MUST bound the work it puts into answering any operations, however, the resolver MUST bound the work it puts into
particular query. answering any particular query.
Since a verified NSEC RR proves the existence of both itself and its Since a verified 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 verifier MUST ignore the settings of the
NSEC and RRSIG bits in an NSEC RR. NSEC and RRSIG bits in an NSEC RR.
Authentication examples are given in Section Appendix C. 5.5 Authentication Example
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 [I-D.ietf-dnsext-ad-is-secure] meaning of the AD bit was redefined in [I-D.ietf-dnsext-ad-is-secure]
and the meaning of both the CD and AD bit are restated in this and the meaning of both the CD and AD bit are restated in this
skipping to change at page 32, line 10 skipping to change at page 34, line 10
[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. security considerations related to DNSSEC; see
[I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
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.2 for further discussion. channel. See Section 3.2.2 and Section 4.8 for further discussion.
DNSSEC introduces a number of denial of service issues. These issues The protocol described in this document attempts to extend the
will also be addressed in a future version of these security benefits of DNSSEC to security-oblivious stub resolvers. However,
considerations. since recovery from validation failures is likely to be specific to
particular applications, the facilities that DNSSEC provides for stub
resolvers may prove inadequate. Operators of security-aware
recursive name servers will need to pay close attention to the
behavior of the applications which use their services when choosing a
local validation policy; failure to do so could easily result in the
recursive name server accidently denying service to the clients it is
intended to support.
8. Acknowledgements 8. Acknowledgements
This document was created from the input and ideas of several members This document was created from the input and ideas of the members of
of the DNS Extensions Working Group and working group mailing list. the DNS Extensions Working Group and working group mailing list. The
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. specifications. While explicitly listing everyone who has
contributed during the decade during which DNSSEC has been under
development would be an impossible task,
[I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
participants who were kind enough to comment on these documents.
Normative References Normative References
[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,
skipping to change at page 37, line 9 skipping to change at page 39, line 9
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.ns1.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1065745538 1071609350
3600 3600
300 300
3600000 3600000
3600 3600
) )
3600 RRSIG SOA 1 1 3600 20031108232541 ( 3600 RRSIG SOA 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) owLe/OV+Qqqic7ShV/S9l2YJF9I= )
3600 NS ns1.example. 3600 NS ns1.example.
3600 NS ns2.example. 3600 NS ns2.example.
3600 RRSIG NS 1 1 3600 20031108232541 ( 3600 RRSIG NS 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) FTVyQbVkcaxQ6U2FbZtMbfo//go= )
3600 MX 1 xx.example. 3600 MX 1 xx.example.
3600 RRSIG MX 1 1 3600 20031108232541 ( 3600 RRSIG MX 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
CSB4g+vSxyrfsfycsZwAx2hKhwK/x7GAIY0p JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18
MLBgAA/USiiMben0II4aYf5lybs0NINnFDju 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe
2Kc78M8t9zBGeJcZCZEs9mKiXhW8WJanvIjg IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+
BwJgWXwAnVnq20TXlsHiuwuhmtrb76/Avl4i M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q
lnX6XA3eeDlQlOTuPe0B91MCuow= ) 7wxkDWyzgasGiMNIKgYrm9vXz04= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
3600 RRSIG NSEC 1 1 3600 20031108232541 ( 3600 RRSIG NSEC 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
3600 DNSKEY 256 3 1 ( 3600 DNSKEY 256 3 5 (
AQPdhnap0Oj2jUq74g+vel5cukdH+wpzjiH8 AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH
ZOQSOHrw+s3TmbhyqXbZ/j5Uu9p65ARoevvG UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV
yv459dxxZCKZ4wftXe5BUkJvZVf8HnhYW5R+ fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv
kQduVeqGVlkBarL5haKX28Pxvs8tV7CyY/Rd BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO
cfnJlZyJcfwY0ETo4P2gntVMERZuJQ== 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q==
) )
3600 DNSKEY 257 3 1 ( 3600 DNSKEY 257 3 5 (
AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U
qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv
pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE
jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT
oNqpieIQd2t+rd/oF8/++DRtzF0toQ== nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ==
) )
3600 RRSIG DNSKEY 1 1 3600 20031108232541 ( 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
EtFrBqs8i80Ath+xOtjPHcepV/cjATf2E1fo Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU
+fhSggjw2vAXDY4Sygk2tKZ9Tvhahmw1rRC3 pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5
CnApLvsjQ9qmnYAvkZdMILw9gPx1rBaq9d7H YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc
nt7mPc/LFrO4G9JS6JNwBCnjwcxro8kNYLo6 tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG
97FCO3y4T7y9Hb80OvCZ36cNdps= ) PjJstq6fvRq8kX7TPJcljUmDFKM= )
3600 RRSIG DNSKEY 1 1 3600 20031108232541 ( 3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
20031009232541 23853 example. 20031216201552 60717 example.
VseD0IGDKqJXiZMJnRNuq89ibF5g8VGPmMJS EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/
h/hS8+nu5vLiyEObJcVxfanslAlBQSGHmJsM C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK
AvXpeJUrT/zOyZ8vfy/igMhd25rnSxAD6uhl L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY
4ohJiiPtFvHgLEvT0QZHizrP4wMvpXvfwn03 J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34
1/VEFzXZ0rULlTdWjoNzSMIYBwg= ) Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= )
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 42939 1 1 ( 3600 DS 48327 5 1 (
4BA08982E5739A60E02B69409B0927F9524E DFEB5E00E71A4DED5CABBBD7F15F24871983
3494 ) CAB7 )
3600 RRSIG DS 1 2 3600 20031108232541 ( 3600 RRSIG DS 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/ wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
iHQEOrm7yXIHwnrre1iuzMZn1jY= ) 0yfe2uolEkeegjesDZuF+fC61Eg= )
3600 NSEC ai.example. NS DS RRSIG NSEC 3600 NSEC ai.example. NS DS RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
mhov2WXDa2Swk/7/VQoI36e5OKvd/0CmMWdi iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb
+3k/+i7mo9omz854ZBFMLaQzFvaS7Cn//I/H RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1
7tYSY/fScUrs/UfB7le0DzdocsoaMYtexSS1 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O
KA7ofbPdYpBHngIGbO5EHaGrqbKGY61fIQ/g ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf
/WvT0KXnoX+v31Oq3VstBoWmizo= ) YgfAHJEJJj7K88QbKEK4/Je1hyk= )
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 1 2 3600 20031108232541 ( 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
UU/kYIPkm9qpSE3wtELJEq2cNsU= ) sWifTxvcG5hv+A6TOd0O2xJYRik= )
3600 HINFO "KLH-10" "ITS" 3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 1 2 3600 20031108232541 ( 3600 RRSIG HINFO 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
jDn/zgIqY5ucajWNW333u+KfxORI55wvnZDs 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C
pCHZQ9ISjWNT7467wUcfJKBaG+alNlCOJExg hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2
z8yUS5NwySlrFtGL/CBCxmrSVioKMMetg7gP KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2
Qb6x5A53OhsQAGT6azS9bdBM2RFbqBkeZkXA Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92
8mJ/QOldXdH5iPpmZb2Pn47x7V4= ) xo9NLoltg0GuwggZM240pRoTwO8= )
3600 AAAA 2001:db8::f00:baa9 3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 1 2 3600 20031108232541 ( 3600 RRSIG AAAA 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1 oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
8gB4wQFPYoozOQYTprwGtIHR2k8= ) zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
W3fFJqdRtmpz9QikpK+v5rL+Y5iNpx5H7X7c Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE
1yPMlcaS0nhowHGjCPnNbCP28Ktv9I5eqhO1 ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y
N/A75FLTOe9L5Qzetb/C3/ME8D46apKLBEv5 ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU
0GWsJqTsijj4dAjup60yeLPXTWxIdO6RNdfe 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR
Qd56t0fY79/kd25RzRCFGs2qHXs= ) ovChG5Ih3TOa8Qnch4IJQVfSFNU= )
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 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
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 1 2 3600 20031108232541 ( 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
+ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
Oett68JnQVQq2l/DhWsJSjuIFBQ= ) WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
3600 NSEC ns2.example. A RRSIG NSEC 3600 NSEC ns2.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= ) I2A5W86mMEbSgEF/pZHX/wi5FJI= )
ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 IN A 192.0.2.2
3600 RRSIG A 1 2 3600 20031108232541 ( 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4 xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9 HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
+huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
8Ic8f9zHwZmCUc0wnxX6x+422PM= ) wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
3600 NSEC *.w.example. A RRSIG NSEC 3600 NSEC *.w.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
kkYPMaBn4zJM/iQAOO9i81X57MMCQnzk+pch Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb
6tWUFF/D1ZFZf8QY2MzwDA5Bv/1DluWVbo3x IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b
WjzyUV7fn77k9QKLQseUSXGnpyL2HR1hGfBV f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J
6ZHAqJc99t5+5vjyiflLtOpA0+Ri46SlQGZf aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl
IZ4X2Ksgn+hpIu77NRQMdmh59M8= ) yCup5bk/Dr47eU2/6+lqrBTOV8Q= )
*.w.example. 3600 IN MX 1 ai.example. *.w.example. 3600 IN MX 1 ai.example.
3600 RRSIG MX 1 2 3600 20031108232541 ( 3600 RRSIG MX 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/ Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
+T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20 n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
FxfIqrcIL24dO4Ytdz2ifqvJmuM= ) 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
3600 NSEC x.w.example. MX RRSIG NSEC 3600 NSEC x.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9 OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
vOHmndDhRTDwVCg179qlrEIsOgE= ) ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 1 3 3600 20031108232541 ( 3600 RRSIG MX 5 3 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5 ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
IKZXg2219TD4UqJuRATLhxZj2fU= ) btznHMFDIbtuw/tAX7xXH2pDDHY= )
3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 NSEC x.y.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 3 3600 20031108232541 ( 3600 RRSIG NSEC 5 3 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
VTRE+Bu91QK7dBiMshr04tE/I5HCvSrjqDv+ zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia
b4tlUqUqkv4MoxfoceUwavMkdLm9Pi/aYUrS CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA
m6XVGBDAjpDmjivlMKNkME8c0f7oQ3E1CtHS EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA
pPLjTcB9WfxEOzjJJGK5BDDT6A56P4eibLiw aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT
+bNx4OGknGvVqhg9pu5qEWi814s= ) 3lMXiX4KNWUhB87q/pT/5z+xrqY= )
x.y.w.example. 3600 IN MX 1 xx.example. x.y.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 1 4 3600 20031108232541 ( 3600 RRSIG MX 5 4 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
yDPXa5Osa4r1AF0AjKWOo87kGNDlnVPmCbIi slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD
MPvBpzJ91d5TFtEZWYJpYv+eGWZCJhK7SsnL v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE
Zbbjthkn7YmX1tReDQhn8aCQ6DyrIU6wZpj5 unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK
ywBx0z3HGcqoYmv+AiFtcYVPxG0elsrakIwG Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk
/e+CPi2yE2c9M+NnwMxhpEFVGRs= ) Iykd5UmaTO5j4LlRnAvF8Z1m9/k= )
3600 NSEC xx.example. MX RRSIG NSEC 3600 NSEC xx.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 4 3600 20031108232541 ( 3600 RRSIG NSEC 5 4 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
66FPTb3/hhrHYkMneBO2Yvfvpj8= ) viOQHZ6I4xoZQP5G7r98/PhlrLM= )
xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 IN A 192.0.2.10
3600 RRSIG A 1 2 3600 20031108232541 ( 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
+N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4 KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
aI16ggg9/UEWRbvn+7tp2UfMYSw= ) 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
3600 HINFO "KLH-10" "TOPS-20" 3600 HINFO "KLH-10" "TOPS-20"
3600 RRSIG HINFO 1 2 3600 20031108232541 ( 3600 RRSIG HINFO 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw
6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA
qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/
EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp
AAwDzum3fUKzVM274T9O8ggeXgE= ) EDXT07qFXtGntvBSpF9uQbEub6Y= )
3600 AAAA 2001:db8::f00:baaa 3600 AAAA 2001:db8::f00:baaa
3600 RRSIG AAAA 1 2 3600 20031108232541 ( 3600 RRSIG AAAA 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
GxlD/3EneV4+IIIv0hekxzpR8Qs= ) D4ZubIon0XGe9fIjLnmb3pX/FUk= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 NSEC example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031108232541 ( 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
cKkFJS6Em56M0XCjMma4zFzy5ylHh2ma62oe sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn
yHrqkMYS+QVUuJ8yfAoXoFbok/kDLN3rsCKK uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE
ICJl1dFA3fvJnMejg0JVabQHShO2W1LmWegr NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a
dh251WZQVtJHDRY8/ltYB+GHUuFpZ1CF4m+c 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187
6EPqS1uLrFpRg3k4BV5y6146nZ8= ) sSNF3PAC0HPadh7SdHmXlFQtQ44= )
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
skipping to change at page 43, line 21 skipping to change at page 45, line 21
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 1 3 3600 20031108232541 ( x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5 ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
IKZXg2219TD4UqJuRATLhxZj2fU= ) btznHMFDIbtuw/tAX7xXH2pDDHY= )
;; 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 1 1 3600 20031108232541 ( example. 3600 RRSIG NS 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) FTVyQbVkcaxQ6U2FbZtMbfo//go= )
;; 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 1 2 3600 20031108232541 ( xx.example. 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
+N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4 KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
aI16ggg9/UEWRbvn+7tp2UfMYSw= ) 0ToQVY81bPc3WXKZjRxQl3jiKtU= )
xx.example. 3600 AAAA 2001:db8::f00:baaa xx.example. 3600 AAAA 2001:db8::f00:baaa
xx.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 ( xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
GxlD/3EneV4+IIIv0hekxzpR8Qs= ) D4ZubIon0XGe9fIjLnmb3pX/FUk= )
ns1.example. 3600 IN A 192.0.2.1 ns1.example. 3600 IN A 192.0.2.1
ns1.example. 3600 RRSIG A 1 2 3600 20031108232541 ( ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
+ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
Oett68JnQVQq2l/DhWsJSjuIFBQ= ) WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 IN A 192.0.2.2
ns2.example. 3600 RRSIG A 1 2 3600 20031108232541 ( ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4 xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9 HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
+huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
8Ic8f9zHwZmCUc0wnxX6x+422PM= ) wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
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.ns1.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1065745538 1071609350
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) owLe/OV+Qqqic7ShV/S9l2YJF9I= )
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 ( b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
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 1 1 3600 20031108232541 ( example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
;; 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.ns1.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1065745538 1071609350
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) owLe/OV+Qqqic7ShV/S9l2YJF9I= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
ns1.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 ( ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= ) I2A5W86mMEbSgEF/pZHX/wi5FJI= )
;; 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.
skipping to change at page 46, line 36 skipping to change at page 48, line 36
;; ;;
;; 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 42939 1 1 ( a.example. 3600 DS 48327 5 1 (
4BA08982E5739A60E02B69409B0927F9524E DFEB5E00E71A4DED5CABBBD7F15F24871983
3494 ) CAB7 )
a.example. 3600 RRSIG DS 1 2 3600 20031108232541 ( a.example. 3600 RRSIG DS 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/ wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
iHQEOrm7yXIHwnrre1iuzMZn1jY= ) 0yfe2uolEkeegjesDZuF+fC61Eg= )
;; 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.
skipping to change at page 47, line 22 skipping to change at page 49, line 22
;; 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 1 2 3600 20031108232541 ( b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
;; 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 1 2 3600 20031108232541 ( a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/ Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
+T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20 n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
FxfIqrcIL24dO4Ytdz2ifqvJmuM= ) 91Ena87PA2MvoOE+A3ZpEk8MjEE= )
;; 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 1 1 3600 20031108232541 ( example. 3600 RRSIG NS 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) FTVyQbVkcaxQ6U2FbZtMbfo//go= )
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 1 4 3600 20031108232541 ( x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
66FPTb3/hhrHYkMneBO2Yvfvpj8= ) viOQHZ6I4xoZQP5G7r98/PhlrLM= )
;; 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 1 2 3600 20031108232541 ( ai.example. 3600 RRSIG A 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
UU/kYIPkm9qpSE3wtELJEq2cNsU= ) sWifTxvcG5hv+A6TOd0O2xJYRik= )
ai.example. 3600 AAAA 2001:db8::f00:baa9 ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 ( ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1 oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
8gB4wQFPYoozOQYTprwGtIHR2k8= ) zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
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.ns1.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1065745538 1071609350
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) owLe/OV+Qqqic7ShV/S9l2YJF9I= )
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 1 4 3600 20031108232541 ( x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
66FPTb3/hhrHYkMneBO2Yvfvpj8= ) viOQHZ6I4xoZQP5G7r98/PhlrLM= )
*.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 1 2 3600 20031108232541 ( *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9 OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
vOHmndDhRTDwVCg179qlrEIsOgE= ) ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
;; 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.ns1.example. ( example. 3600 IN SOA ns1.example. bugs.x.w.example. (
1065745538 1071609350
3600 3600
300 300
3600000 3600000
3600 3600
) )
example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) owLe/OV+Qqqic7ShV/S9l2YJF9I= )
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 1 1 3600 20031108232541 ( example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
20031009232541 5742 example. 20031216201552 41681 example.
10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) 7T/nOEOVZujD8IN/Utv+KUg+P6U= )
;; 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 was
signed by an "example" DNSKEY with algorithm 1 and key tag 5742. The signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
resolver needs the corresponding DNSKEY RR in order to authenticate The resolver needs the corresponding DNSKEY RR in order to
this answer. The discussion below describes how a resolver might authenticate this answer. The discussion below describes how a
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 the result of wildcard expansion. The "x.w.example.com" MX RRset not the result of wildcard expansion. The "x.w.example.com" MX RRset
is placed in canonical form and, assuming the current time falls is placed in canonical form and, assuming the current time falls
between the signature inception and expiration dates, the signature between the signature inception and expiration dates, the signature
is authenticated. is authenticated.
C.1.1 Authenticating the example DNSKEY RR C.1.1 Authenticating the example DNSKEY RR
skipping to change at page 52, line 10 skipping to change at page 54, line 10
Once the DS RRset has been authenticated using the root DNSKEY, the Once the DS RRset has been authenticated using the root DNSKEY, the
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY is found, the resolver checks this DNSKEY matching "example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "example" DNSKEY RRset and the signature lifetime RR has signed the "example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the "example" is valid. If all these conditions are met, all keys in the "example"
DNSKEY RRset are considered authenticated. DNSKEY RRset are considered authenticated.
Finally the resolver checks that some DNSKEY RR in the "example" Finally the resolver checks that some DNSKEY RR in the "example"
DNSKEY RRset uses algorithm 1 and has a key tag of 5742. This DNSKEY DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This
is used to authenticated the RRSIG included in the response. If DNSKEY is used to authenticated the RRSIG included in the response.
multiple "example" DNSKEY RRs have algorithm 1 and key tag of 5742, If multiple "example" DNSKEY RRs have algorithm 5 and key tag of
then each DNSKEY RR is tried and the answer is authenticated if 41681, then each DNSKEY RR is tried and the answer is authenticated
either DNSKEY RR validates the signature as described above. if either DNSKEY RR validates the signature as described above.
C.2 Name Error C.2 Name Error
The query in section Appendix B.2 returned NSEC RRs that prove the The query in section Appendix B.2 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed authenticated in a manner identical to that of the MX RRset discussed
above. above.
C.3 No Data Error C.3 No Data Error
skipping to change at page 53, line 11 skipping to change at page 55, line 11
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 similar to The corresponding RRSIG indicates the MX RRset was the similar to The corresponding RRSIG indicates the MX RRset was
signed by an "example" DNSKEY with algorithm 1 and key tag 5742. The signed by an "example" DNSKEY with algorithm 5 and key tag 41681.
RRSIG indicates the original TTL of the MX RRset was 3600 and, for The RRSIG indicates the original TTL of the MX RRset was 3600 and,
the purpose of authentication, the current TTL is replaced by 3600. for the purpose of authentication, the current TTL is replaced by
The RRSIG labels field value of 2 indicates the answer the result of 3600. The RRSIG labels field value of 2 indicates the answer the
wildcard expansion since the "a.z.w.example" name contains 4 labels. result of wildcard expansion since the "a.z.w.example" name contains
The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
is placed in canonical form and, assuming the current time falls the MX RRset is placed in canonical form and, assuming the current
between the signature inception and expiration dates, the signature time falls between the signature inception and expiration dates, the
is authenticated. signature is authenticated.
The NSEC proves that no closer match (exact or closer wildcard) could The NSEC proves that no closer match (exact or closer wildcard) could
have been used to answer this query and the NSEC RR must also be have been used to answer this query and the NSEC RR must also be
authenticated before the answer is considered valid. authenticated before the answer is considered valid.
C.7 Wildcard No Data Error C.7 Wildcard No Data Error
The query in section Appendix B.7 returned NSEC RRs that prove the The query in section Appendix B.7 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. reply is authenticated by verifying both NSEC RRs.
 End of changes. 

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