draft-ietf-dnsext-dnssec-protocol-02.txt   draft-ietf-dnsext-dnssec-protocol-03.txt 
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: March 30, 2004 M. Larson Expires: April 26, 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
September 30, 2003 October 27, 2003
Protocol Modifications for the DNS Security Extensions Protocol Modifications for the DNS Security Extensions
draft-ietf-dnsext-dnssec-protocol-02 draft-ietf-dnsext-dnssec-protocol-03
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 March 30, 2004. This Internet-Draft will expire on April 26, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents which describes the This document is part of a family of documents which describe the DNS
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
add data origin authentication and data integrity to the DNS. This add data origin authentication and data integrity to the DNS. This
document describes the DNSSEC protocol modifications. This document document describes the DNSSEC protocol modifications. This document
defines the concept of a signed zone, along with the requirements for defines the concept of a signed zone, along with the requirements for
serving and resolving using DNSSEC. These techniques allow a serving and resolving using DNSSEC. These techniques allow a
security-aware resolver to authenticate both DNS resource records and security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications. authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535. updates to RFC 2535.
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 . . . . . . . . . . . . . . . . 7 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 8
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 9 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 9
3.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 10
3.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10
3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 11
Present . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 14
3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . . 11 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 15
3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 12 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 16
3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 12 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 13 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 14 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 18
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 21 4.1 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 21
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 24 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 23
5.1 Special Considerations for Islands of Security . . . . . . . 25 5.1 Special Considerations for Islands of Security . . . . . . . 24
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 25 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 24
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 26 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 25
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 26
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 27
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 28
5.3.4 Authenticating A Wildcard Expanded RRset Positive 5.3.4 Authenticating A Wildcard Expanded RRset Positive
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 30 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 29
5.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . 32
5.5.2 Examples of Authenticating a Response . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 Normative References . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . 34 Informative References . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35
Normative References . . . . . . . . . . . . . . . . . . . . 36 A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 37
Informative References . . . . . . . . . . . . . . . . . . . 37 B. Example Responses . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 39 B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 44
B. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46 B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 46
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 47
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 47
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 48
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 49
C. Authentication Examples . . . . . . . . . . . . . . . . . . 51
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 51
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 51
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 52
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 52
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 52
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 52
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 53
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 53
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . 54
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 38 skipping to change at page 6, line 38
[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
zone keys. zone keys.
If the zone is delegated and does not wish to act as an island of If the zone is delegated and does not wish to act as an island of
security, the zone MUST have at least one DNSKEY RR at the apex to security, the zone MUST have at least one DNSKEY RR at the apex to
act as a secure entry point into the zone. This DNSKEY would then be act as a secure entry point into the zone. This DNSKEY would then be
used to generate a DS RR at the delegating parent (see used to generate a DS RR at the delegating parent (see
[I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a [I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a
zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro] zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro]
for definition). The DNSKEY RRset at the zone apex MUST be signed by for definition).
at least one zone signing or DNSKEY signing private key.
DNSKEY RRs MUST NOT appear at delegation points. DNSKEY RRs MUST NOT appear at delegation points.
2.2 Including RRSIG RRs in a Zone 2.2 Including RRSIG RRs in a Zone
For each authoritative RRset in a signed zone (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
skipping to change at page 7, line 34 skipping to change at page 7, line 32
An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
would add no value and would create an infinite loop in the signing would add no value and would create an infinite loop in the signing
process. process.
The NS RRset which appears at the zone apex name MUST be signed, but The NS RRset which appears at the zone apex name MUST be signed, but
the NS RRsets which appear at delegation points (that is, the NS the NS RRsets which appear at delegation points (that is, the NS
RRsets in the parent zone which delegate the name to the child zone's RRsets in the parent zone which delegate the name to the child zone's
name servers) MUST NOT be signed. Glue address RRsets associated with name servers) MUST NOT be signed. Glue address RRsets associated with
delegations MUST NOT be signed. delegations MUST NOT be signed.
There MUST be an RRSIG for each RRset generated using at least one
DNSKEY of each algorithm in the parent zone's DS RRset and each
additional algorithm, if any, in the apex DNSKEY RRset. The apex
DNSKEY RRset itself MUST be signed by each algorithm appearing in the
DS RRset.
The difference between the set of owner names which require RRSIG The difference between the set of owner names which require RRSIG
records and the set of owner names which require NSEC records is records and the set of owner names which require NSEC records is
subtle and worth highlighting. RRSIG records are present at the subtle and worth highlighting. RRSIG records are present at the
owner names of all authoritative RRsets. NSEC records are present at owner names of all authoritative RRsets. NSEC records are present at
the owner names of all names for which the signed zone is the owner names of all names for which the signed zone is
authoritative and also at the owner names of delegations from the authoritative and also at the owner names of delegations from the
signed zone to its children. Neither NSEC nor RRSIG records are signed zone to its children. Neither NSEC nor RRSIG records are
present (in the parent zone) at the owner names of glue address present (in the parent zone) at the owner names of glue address
RRsets. Note, however, that this distinction is for the most part 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
skipping to change at page 8, line 24 skipping to change at page 8, line 29
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 key used by the child zone to sign its apex DNSKEY
RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
appear at non-delegation points nor at a zone's apex. appear at non-delegation points nor at a zone's apex.
A DS RR SHOULD point to a 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
RRset.
Construction of a DS RR requires knowledge of the corresponding Construction of a DS RR requires knowledge of the corresponding
DNSKEY RR in the child zone, which implies communication between the DNSKEY RR in the child zone, which implies communication between the
child and parent zones. This communication is an operational matter child and parent zones. This communication is an operational matter
not covered by this document. not covered by this document.
2.5 Changes to the CNAME Resource Record. 2.5 Changes to the CNAME Resource Record.
If a CNAME RRset is present at a name in a signed zone, appropriate If a CNAME RRset is present at a name in a signed zone, appropriate
RRSIG and NSEC RRsets are REQUIRED at that name. Other types MUST NOT RRSIG and NSEC RRsets are REQUIRED at that name. Other types MUST NOT
be present at that name. be present at that name.
This is a modification to the original CNAME definition given in This is a modification to the original CNAME definition given in
[RFC1034]. The original definition of the CNAME RR did not allow any [RFC1034]. The original definition of the CNAME RR did not allow any
other types to co-exist with a CNAME record, but a signed zone other types to coexist with a CNAME record, but a signed zone
requires NSEC and RRSIG RRs for every authoritative name. To resolve requires NSEC and RRSIG RRs for every authoritative name. To resolve
this conflict, this specification modifies the definition of the this conflict, this specification modifies the definition of the
CNAME resource record to allow it to co-exist with NSEC and RRSIG CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
RRs.
2.6 Example of a Secure Zone 2.6 Example of a Secure Zone
Appendix B shows a complete example of a small signed zone. Appendix A shows a complete example of a small signed zone.
3. Serving 3. Serving
This section describes the behavior of a security-aware authoritative This section describes the behavior of entities which include
name server. A security-aware authoritative name server MUST support security-aware name functions. In many cases such functions will be
the EDNS0 [RFC2671] message size extension, MUST support a message part of a security-aware recursive name server, but a security-aware
size of at least 1220 octets, and SHOULD support a message size of authoritative name server has some of the same requirements as a
4000 octets [RFC3226]. Since functions specific to security-aware security-aware recursive name server does. Functions specific to
recursive name servers included components of both resolving and security-aware recursive name servers are described in Section 3.2;
serving, issues specific to security-aware recursive name servers are functions specific to authoritative servers are described in Section
described in Section 4. 3.1.
The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
are as used in [RFC1034].
A security-aware name server MUST support the EDNS0 [RFC2671] message
size extension, MUST support a message size of at least 1220 octets,
and SHOULD support a message size of 4000 octets [RFC3226].
A security-aware name server which receives a DNS query which does
not include the EDNS OPT pseudo-RR or which has the DO bit set to
zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
RRset, and MUST NOT perform any of the additional processing
described below. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.1.4.1.
DNSSEC allocates two new bits in the DNS message header: the CD
(Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
is controlled by resolvers; a security-aware name server MUST copy
the CD bit from a query into the corresponding response. The AD bit
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,
Section 3.2.2, Section 3.2.3, Section 4, and Section 4.2 for details
on the behavior of these bits.
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
included in the response according to the rules in Section 3.1; included in the response according to the rules in Section 3.1.1;
o NSEC RRs which can be used to provide authenticated denial of o NSEC RRs which can be used to provide authenticated denial of
existence MUST be included in the response automatically according existence MUST be included in the response automatically according
to the rules in Section 3.3; to the rules in Section 3.1.3;
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
o Either DS RRs or an NSEC RR proving that no DS RRs exist MUST be be included in referrals automatically according to the rules in
included in referrals automatically according to the rules in Section 3.1.4.
Section 3.4.
DNSSEC does not change the DNS zone transfer protocol. Zone transfer
requirements are reviewed in Section 3.6.
A security-aware name server which receives a DNS query which does DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
not include the EDNS OPT pseudo-RR or which has the DO bit set to discusses zone transfer requirements.
zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
RRset, and MUST NOT perform any of the additional processing
described above. Since the DS RR type has the peculiar property of
only existing in the parent zone at delegation points, DS RRs always
require some special processing, as described in Section 3.5.
3.1 Including RRSIG RRs in a Response 3.1.1 Including RRSIG RRs in a Response
When a query has the DO bit set to one, the authoritative name server When responding to a query which has the DO bit set to one, a
SHOULD attempt to send RRSIG RRs which can be used to authenticate security-aware authoritative name server SHOULD attempt to send RRSIG
the RRsets in the response. Inclusion of RRSIG RRs in a response is RRs which a security-aware resolver can use to authenticate the
RRsets in the response. Inclusion of RRSIG RRs in a response is
subject to the following rules: subject to the following rules:
o When placing a signed RRset in the Answer section, the name server o When placing a signed RRset in the Answer section, the name server
MUST also place its RRSIG RRs in the Answer section. The RRSIG MUST also place its RRSIG RRs in the Answer section. The RRSIG
RRs have a higher priority for inclusion than any other RRsets RRs have a higher priority for inclusion than any other RRsets
which may need to be included. If space does not permit inclusion which may need to be included. If space does not permit inclusion
of these RRSIG RRs, the name server MUST set the TC bit. of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Authority section, the name o When placing a signed RRset in the Authority section, the name
server MUST also place its RRSIG RRs in the Authority section. server MUST also place its RRSIG RRs in the Authority section.
The RRSIG RRs have a higher priority for inclusion than any other The RRSIG RRs have a higher priority for inclusion than any other
RRsets that may need to be included. If space does not permit RRsets that may need to be included. If space does not permit
inclusion of these RRSIG RRs, the name server MUST set the TC bit. inclusion of these RRSIG RRs, the name server MUST set the TC bit.
o When placing a signed RRset in the Additional section, the name o When placing a signed RRset in the Additional section, the name
server MUST also place its RRSIG RRs in the Additional section. server MUST also place its RRSIG RRs in the Additional section.
If space does not permit inclusion of these RRSIG RRs, the name If space does not permit inclusion of these RRSIG RRs, the name
server MUST NOT set the TC bit solely because these RRSIG RRs server MUST NOT set the TC bit solely because these RRSIG RRs
didn't fit. didn't fit.
3.2 Including DNSKEY RRs In a Response 3.1.2 Including DNSKEY RRs In a Response
When a query has the DO bit set to one and requests the SOA or NS RRs When responding to a query which has the DO bit set to one and which
at the apex of a signed zone, a security-aware authoritative name requests the SOA or NS RRs at the apex of a signed zone, a
server for that zone MAY return the DNSKEY RRset with the same name security-aware authoritative name server for that zone MAY return the
in the Additional section. In this situation, the DNSKEY RR set and zone apex DNSKEY RRset in the Additional section. In this situation,
associated RRSIG RRs have lower priority than any other information the DNSKEY RRset and associated RRSIG RRs have lower priority than
that would be placed in the additional section. The name server any other information that would be placed in the additional section.
should include the DNSKEY RRset if and only if there is enough space The name server SHOULD NOT include the DNSKEY RRset unless there is
in the response for both the DNSKEY RRset and associated RRSIG RR(s). enough space in the response message for both the DNSKEY RRset and
If there is not enough space to include these DNSKEY and RRSIG RRs, its associated RRSIG RR(s). If there is not enough space to include
the name server MUST omit them and MUST NOT set the TC bit solely these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
because these RRs didn't fit. NOT set the TC bit solely because these RRs didn't fit (see Section
3.1.1).
3.3 Including NSEC RRs In a Response 3.1.3 Including NSEC RRs In a Response
When a query has the DO bit set to one, security-aware authoritative When responding to a query which has the DO bit set to one, a
name servers for a signed zone MUST include NSEC RRs in each of the security-aware authoritative name server for a signed zone MUST
following cases: include NSEC RRs in each of the following cases:
Case 1: The QNAME has RRsets associated with it in the zone, but the No Data: The zone contains RRsets which exactly match <SNAME,
requested RR type does not exist. SCLASS>, but does not contain any RRsets which exactly match
<SNAME, SCLASS, STYPE>.
Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and no Name Error: The zone does not contain any RRsets which match <SNAME,
wildcard can be expanded to answer the query. SCLASS> either exactly or via wildcard name expansion.
Case 3: The QNAME (or search name) does not exist, but a wildcard can Wildcard Answer: The zone does not contain any RRsets which exactly
be expanded to positively answer the query. match <SNAME, SCLASS> but does contain an RRset which matches
<SNAME, SCLASS, STYPE> via wildcard name expansion.
Note that, in each case, a set of NSEC RRs is included to provide Wildcard No Data: The zone does not contain any RRsets which exactly
authenticated denial of existence. match <SNAME, SCLASS>, does contain one or more RRsets which
matches <SNAME, SCLASS> via wildcard name expansion, but does not
contain any RRsets which match <SNAME, SCLASS, STYPE> via wildcard
name expansion.
3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present In each of these cases, the name server includes NSEC RRs in the
response to prove that an exact match for <SNAME, SCLASS, STYPE> was
not present in the zone and that the response which the name server
is returning is correct given the data which are in the zone.
If there are RR types associated with a given QNAME, but the 3.1.3.1 Including NSEC RRs: No Data Response
requested RR type is not present at the name, then the name server
MUST include the NSEC RR associated with the query name and any RRSIG
RRs associated with the NSEC RR in the Authority section (see Section
3.1). If space does not permit inclusion of the NSEC RR or its
associated RRSIG RRs, the name server MUST set the TC bit.
Note that, since the query name exists, no wildcard expansion applies If the zone contains RRsets matching <SNAME, SCLASS> but contains no
to this query, and a single NSEC RR suffices to prove the requested RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
RR type does not exist. include the NSEC RR for <SNAME, SCLASS> along with its associated
RRSIG RR(s) in the Authority section of the response (see Section
3.1.1). If space does not permit inclusion of the NSEC RR or its
associated RRSIG RR(s), the name server MUST set the TC bit (see
Section 3.1.1).
3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches Since the search name exists, wildcard name expansion does not apply
to this query, and a single signed NSEC RR suffices to prove the
requested RR type does not exist.
If the query name does not exist in the zone, and no wildcard 3.1.3.2 Including NSEC RRs: Name Error Response
expansion matches both the query name and the query type, the name
server MUST include the following NSEC RRs in the Authority section,
along with their associated RRSIG RRs:
o An NSEC RR proving that there was no exact match for the name; and If the zone does not contain any RRsets matching <SNAME, SCLASS>
either exactly or via wildcard name expansion, then the name server
MUST include the following NSEC RRs in the Authority section, along
with their associated RRSIG RRs:
o An NSEC RR combination proving that there was no wildcard which o An NSEC RR proving that there is no exact match for <SNAME,
would have matched the query. See [I-D.ietf-dnsext-wcard-clarify] SCLASS>; and
for further information on NSEC coverage.
o An NSEC RR proving that the zone contains no RRsets which would
match <SNAME, SCLASS> via wildcard name expansion.
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
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). name server MUST set the TC bit (see Section 3.1.1).
Appendix A provides an algorithm which computes the appropriate NSEC 3.1.3.3 Including NSEC RRs: Wildcard Answer Response
RRs to prove that no wildcard matches a given query name.
3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches If the zone does not contain any RRsets which exactly match <SNAME,
SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
STYPE> via wildcard name expansion, the name server MUST include the
wildcard-expanded answer and the corresponding wildcard-expanded
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
does not contain a closer match for <SNAME, SCLASS>. If space does
not permit inclusion of these answer, NSEC and RRSIG RRs, the name
server MUST set the TC bit (see Section 3.1.1).
If the query name does not exist, but a wildcard expansion can be 3.1.3.4 Including NSEC RRs: Wildcard No Data Response
used to return a positive match to the query, the name server MUST
include the wildcard-expanded answer and the corresponding
wildcard-expanded RRSIG RRs in the Answer section. The Authority
section of the response MUST include the following NSEC RRs along
with their corresponding RRSIG RRs:
o An NSEC RR which proves that there were no exact matches for the This case is a combination of the previous cases. The zone does not
QNAME and QTYPE; and contain an exact match for <SNAME, SCLASS>, and while the zone does
contain RRsets which match <SNAME, SCLASS> via wildcard name
expansion, none of those RRsets match STYPE. The name server MUST
include the following NSEC RRs in the Authority section, along with
their associated RRSIG RRs:
o An NSEC RR combination which proves that there are no closer o An NSEC RR proving that there are no RRsets matching STYPE at the
wildcard entries which could have been expanded to match the wildcard owner name which matched <SNAME, SCLASS> via wildcard
query. See [I-D.ietf-dnsext-wcard-clarify] for further expansion; and
information on NSEC coverage.
o An NSEC RR proving that there are no RRsets in the zone which
would have been a closer match for <SNAME, SCLASS>.
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
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). name server MUST set the TC bit (see Section 3.1.1).
Appendix A provides an algorithm which computes the appropriate NSEC 3.1.3.5 Finding The Right NSEC RRs
RRs to prove that no closer wildcard matches the query name.
3.4 Including DS RRs In a Response As explained above, there are several situations in which a
security-aware authoritative name server needs to locate an NSEC RR
which proves that a particular SNAME does not exist. Locating such
an NSEC RR within an authoritative zone is relatively simple, at
least in concept. The following discussion assumes that the name
server is authoritative for the zone which would have held the
nonexistent SNAME. The algorithm below is written for clarity, not
efficiency.
When a query has the DO bit set to one, and a DS RR exists at the To find the NSEC which proves that name N does not exist in the zone
query name, an authoritative security-aware name server returning a Z which would have held it, construct sequence S consisting of every
referral for the delegation MUST include both the NS RRset and also name in Z, sorted into canonical order. Find the name M which would
the DS RRset and its associated RRSIG RR(s). The name server MUST have immediately preceded N in S if N had existed. M is the owner
place the NS RRset before the DS RRset and its associated RRSIG RRs. name of the NSEC RR which proves that N does not exist.
When a query has the DO bit set to one, and no DS RR exists at the The algorithm for finding the NSEC RR which proves that a given name
query name, an authoritative security-aware name server returning a is not covered by any applicable wildcard is similar, but requires an
referral for the delegation MUST include both the NS RRset and also extra step. More precisely, the algorithm for finding the NSEC
the NSEC RR and associated RRSIG RR(s) which proves that the DS RRset proving that the applicable wildcard name does not exist is precisely
does not exist. The name server MUST place the NS RRset before the the same as the algorithm for finding the NSEC RR which proves that
NSEC RRset and its associated RRSIG RR(s). any other name does not exist: the part that's missing is how to
determine the name of the nonexistent applicable wildcard. In
practice, this is easy, because the authoritative name server has
already checked for the presence of precisely this wildcard name as
part of step (1)(c) of the normal lookup algorithm described in
Section 4.3.2 of [RFC1034].
Including these DS and RRSIG RRs increases the size of referral 3.1.4 Including DS RRs In a Response
messages, and may cause some or all glue RRs to be omitted. If space
does not permit inclusion of the DS or NSEC RRset and associated
RRSIG RRs, the name server MUST set the TC bit.
Security-aware name servers also include NSEC RRs in a referral When responding to a query which has the DO bit set to one, a
response when no DS RR is present; in this case, the NSEC RR proves security-aware authoritative name server returning a referral
that no DS RR exists for the delegation. Section 3.4 discusses includes DNSSEC data along with the NS RRset.
referrals in more detail.
3.5 Responding to Queries for DS RRs If a DS RRset is present at the delegation point, the name server
MUST return both the DS RRset and its associated RRSIG RR(s) along
with the NS RRset. The name server MUST place the NS RRset before
the DS RRset and its associated RRSIG RR(s).
The DS resource record type is unusual in that it appears only on the If no DS RRset is present at the delegation point, the name server
parent zone's side of a zone cut. In other words, the DS record for MUST return both the NSEC RR which proves that the DS RRset is not
the delegation of "example.com" is only stored in the "com" zone. present and the NSEC RR's associated RRSIG RR(s) along with the NS
This introduces novel name server behavior, since the name server for RRset. The name server MUST place the NS RRset before the NSEC RRset
the child zone is authoritative for the name by the normal DNS rules and its associated RRSIG RR(s).
but the child zone does not contain the DS RR. An authoritative name
server's response to a DS query depends on whether the name server is
authoritative for the parent zone, the child zone, or both, as
described below.
If a name server is authoritative for the parent zone, and receives a Including these DS, NSEC, and RRSIG RRs increases the size of
query for the DS record at the delegated name, then the name server referral messages, and may cause some or all glue RRs to be omitted.
MUST return the DS RRset from the parent zone. This rule applies
regardless of whether or not the name server is also authoritative
for the child zone.
If the name server is authoritative for the child zone, is not If space does not permit inclusion of the DS or NSEC RRset and
authoritative for the parent zone, and receives a query for the DS associated RRSIG RRs, the name server MUST set the TC bit (see
record at the delegated name, there is no obvious response, because Section 3.1.1).
the child zone is not authoritative for the DS record at the child
zone's apex, and the authoritative DS RR is only stored at the
parent.
If the name server allows recursion, and the RD bit is set in the 3.1.4.1 Responding to Queries for DS RRs
query, the name server MAY perform recursion to find the DS record
for the delegated name from the parent zone, and MAY return the DS
record from its cache. In this case, the AA bit MUST NOT be set in
the response.
If the name server does not perform recursion to find the DS RR, the The DS resource record type is unusual in that it appears only on the
name server MUST reply with: parent zone's side of a zone cut. For example, the DS RRset for the
delegation of "foo.example" is stored in the "example" zone rather
than in the "foo.example" zone. This requires special processing
rules for both name servers and resolvers, since the name server for
the child zone is authoritative for the name at the zone cut by the
normal DNS rules but the child zone does not contain the DS RRset.
RCODE: NOERROR A security-aware resolver will send queries to the parent zone when
AA bit: set looking for a DS RRset at a delegation point, and thus will never
Answer Section: Empty trigger the corresponding special processing in a security-aware name
Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)] server. The rest of this section describes how a security-aware
recursive name server processes a misdirected DS query.
In other words, a name server which is authoritative for the child The need for special processing by a security-aware name server only
zone but not for the parent zone answers as if the DS record does not arises when:
exist. Note that security-aware resolvers will query the parent zone
at delegation points, and thus will not be affected by this behavior.
For example, suppose that "example.com" is a delegation point, and a o the name server has received a query for the DS RRset at a zone
name server receives a query for the "example.com" DS RRset. cut;
o If the name server is authoritative for "com", the name server o the name server is authoritative for the child zone;
MUST reply with the "example.com" DS RRset from the "com" zone.
o If the name server is authoritative for "example.com", is not o the name server is not authoritative for the parent zone; and
authoritative for "com", and the RD bit is set to one in the
query, the name server MAY perform recursion to find the
"example.com" DS record. If the name server does not use
recursion to obtain the DS RR, the name server MUST reply as
though the DS RR did not exist:
RCODE: NOERROR o the name server does not offer recursion.
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)]
3.6 Responding to Queries for Type AXFR or IXFR In all other cases, the name server either has some way of obtaining
the DS RRset or could not have been expected to have the DS RRset
even by the pre-DNSSEC processing rules, so the name server can
return either the DS RRset or an error response according to the
normal processing rules.
If all of the above conditions are met, however, the name server is
authoritative for SNAME but cannot supply the requested RRset. In
this case, the name server MUST return an authoritative "no data"
response showing that the DS RRset does not exist in the child zone's
apex. See Appendix B.8 for an example of such a response.
3.1.5 Responding to Queries for Type AXFR or IXFR
DNSSEC does not change the DNS zone transfer process. A signed zone DNSSEC does not change the DNS zone transfer process. A signed zone
will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
records have no special meaning with respect to a zone transfer records have no special meaning with respect to a zone transfer
operation, and these RRs are treated as any other resource record operation, and these RRs are treated as any other resource record
type. type.
An authoritative name server is not required to verify that a zone is An authoritative name server is not required to verify that a zone is
properly signed before sending or accepting a zone transfer. properly signed before sending or accepting a zone transfer.
However, an authoritative name server MAY choose to reject the entire However, an authoritative name server MAY choose to reject the entire
zone transfer if the zone fails meets any of the signing requirements zone transfer if the zone fails meets any of the signing requirements
described in Section 2. The primary objective of a zone transfer is described in Section 2. The primary objective of a zone transfer is
to ensure that all authoritative name servers have identical copies to ensure that all authoritative name servers have identical copies
of the zone. An authoritative name server which chooses to perform of the zone. An authoritative name server which chooses to perform
its own zone validation MUST NOT selectively reject some RRs and its own zone validation MUST NOT selectively reject some RRs and
accept others. accept others.
Note that the DS RR appears only in the parental side of a delegation DS RRsets appear only on the parental side of a zone cut and are
and is authoritative data in the parent zone. For example, the DS RR authoritative data in the parent zone. As with any other
for "example.com" is stored in the "com" zone (the parent zone) authoritative RRset, the DS RRset MUST be included in zone transfers
rather than in the "example.com" zone (the child zone). As with any of the zone in which the RRset is authoritative data: in the case of
other authoritative RRset, the "example.com" DS RR MUST be included the DS RRset, this is the parent zone.
the "com" zone transfer.
Note that authoritative NSEC RRs appear in both the parent and child NSEC RRs appear in both the parent and child zones at a zone cut, and
zones at a delegated name, and that the NSEC RRs for the delegated are authoritative data in both the parent and child zones. The
name in the parent and child zones are never identical to each other. parental and child NSEC RRs at a zone cut are never identical to each
As with any other authoritative RRset, the parental NSEC RR at a other, since the NSEC RR in the child zone's apex will always
delegated name MUST be included zone transfers of the parent zone, indicate the presence of the child zone's SOA RR while the parental
while the NSEC at the zone apex of the child zone MUST be included in NSEC RR at the zone cut will never indicate the presence of an SOA
zone transfers of the child zone. RR. As with any other authoritative RRs, NSEC RRs MUST be included
in zone transfers of the zone in which they are authoritative data:
the parental NSEC RR at a zone cut MUST be included zone transfers of
the parent zone, while the NSEC at the zone apex of the child zone
MUST be included in zone transfers of the child zone.
3.7 Setting the AD and CD Bits in a Response RRSIG RRs appear in both the parent and child zones at a zone cut,
and are authoritative in whichever zone contains the authoritative
RRset for which the RRSIG RR provides the signature. That is, the
RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
authoritative in the parent zone, while the RRSIG for any RRset in
the child zone's apex will be authoritative in the child zone. As
with any other authoritative RRs, RRSIG RRs MUST be included in zone
transfers of the zone in which they are authoritative data.
Editors' note: This section seems a little lost here. Perhaps we 3.1.6 The AD and CD Bits in an Authoritative Response
should rearrange the section ordering slightly, or provide a
pointer to this subsection at the beginning of Section 3.
DNSSEC allocates two new bits in the DNS message header: The CD The CD and AD bits are designed to be used in communication between
(Checking Disabled) bit and the AD (Authentic Data) bit. security-aware resolvers and security-aware recursive name servers.
This bits are for the most part not relevant to query processing by
security-aware authoritative name servers.
The CD bit is set in query messages by the resolver, and MUST be Since a security-aware name server does not perform signature
copied into the response by the name server. If the CD bit is set to validation for authoritative data during query processing even when
one, it indicates that the resolver is willing to perform whatever the CD bit is set to zero, a security-aware name server SHOULD ignore
authentication its local policy requires, and thus that the name the setting of the CD bit when composing an authoritative response.
server need not perform authentication on the RRsets in the response.
Regardless of the setting of the CD bit, the name server MAY choose A security-aware name server MUST NOT set the AD bit in a response
whether or not to perform authentication according to its own local unless the name server considers all RRsets in the Answer or
name server policy, and the name server MAY use the CD bit as input Authority sections of the response to be authentic. A security-aware
to its own local policy. However, if the resolver has set the CD name server's local policy MAY consider data from an authoritative
bit, a name server SHOULD, if possible, return the requested data to zone to be authentic without further validation, but the name server
the resolver even if the name server's local authentication policy MUST NOT do so unless the name server obtained the authoritative zone
would reject the records in question. That is, by setting the CD via secure means (such as a secure zone transfer mechanism), and MUST
bit, the resolver has taken responsibility for performing its own NOT do so unless this behavior has been configured explicitly.
authentication, and the name server should not interfere in this
case.
The AD bit is set by name servers, and indicates the data in the A security-aware name server which supports recursion MUST follow the
response has been authenticated by the name server, according to the rules for the CD and AD bits given in Section 3.2 when generating a
local name server policy. The AD bit MUST NOT be set on a response response that involves data obtained via recursion.
unless all of the RRsets in the Answer and Authority sections have
met the name server's local authentication policy. A resolver MUST
NOT trust the AD bit unless it communicates with the name server over
a secure transport mechanism and is explicitly configured to trust
the name server's policy.
3.8 Example DNSSEC Responses 3.2 Recursive Name Servers
Editors' note: these examples probably ought to move to an As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
appendix and probably ought to use the "real" signed example zone recursive name server is an entity which acts in both the
that's already in an appendix. security-aware name server and security-aware resolver roles. This
section uses the terms "name server side" and "resolver side" to
refer to the code within a security-aware recursive name server which
implements the security-aware name server role and the code which
implements the security-aware resolver role, respectively.
The examples in this section use the following example zone to A security-aware recursive name server MUST NOT attempt to answer a
demonstrate the formation of replies by an authoritative name server. query by piecing together cached data it received in response to
The zone has two name servers, a single child, and a wildcard MX RR. previous queries that requested different QNAMEs, QTYPEs, or
The zone is completely signed and has a full NSEC chain. 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.
example.com. SOA (...) The resolver side MUST follow the usual rules for caching and
RRSIG SOA ... negative caching which would apply to any security-aware resolver.
NS a.example.com.
NS b.example.com.
RRSIG NS ...
MX 10 a.example.com
RRSIG MX ...
DNSKEY ...
RRSIG DNSKEY ...
NSEC *.example.com.
* MX 10 a.example.com.
RRSIG MX ...
NSEC a.example.com.
a A 10.10.10.1
RRSIG A ...
NSEC b.example.com.
b A 10.10.10.2
RRSIG A ...
NSEC c.example.com.
c CNAME a.example.com.
RRSIG CNAME 3.2.1 The DO bit
NSEC sub.example.com.
sub NS ns.sub.example.com.
RRSIG NS
DS ...
RRSIG DS
NSEC *.example.com.
ns.sub A 10.10.10.3
sub-nosig NS ns.sub-nosig.example.com.
NSEC example.com.
ns.sub-nosig A 10.10.10.4
A query to the authoritative name server for this zone for The resolver side of a security-aware recursive name server MUST set
QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: the DO bit when sending requests, regardless of the state of the DO
bit in the initiating request received by the name server side. If
the DO bit in an initiating query is not set, the name server side
MUST strip any authenticating DNSSEC RRs from the response, but but
MUST NOT strip any DNSSEC RRs that the initiating query explicitly
requested.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) 3.2.2 The CD bit
EDNS: DO=1, size=4000
QUERY:
c.example.com. IN A
ANSWER:
c.example.com. IN A a.example.com
IN RRSIG CNAME
a.example.com. IN A 10.10.10.1
IN RRSIG A
AUTHORITY:
example.com. IN NS a.example.com.
IN NS b.example.com.
IN RRSIG NS ...
ADDITIONAL:
a.example.com. IN A 10.10.10.1
IN RRSIG A ...
b.example.com. IN A 10.10.10.2
IN RRSIG A ...
A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would The CD bit exists in order to allow a security-aware resolver to
results in a referral to a signed zone. The resolver can determine disable signature validation in a security-aware name server's
that "sub.example.com" is signed because of the presence of the DS RR processing of a particular query. This is a useful but somewhat
with the hash of the "sub.example.com" zone key. dangerous capability that requires careful handling by security-aware
recursive name servers.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) A security-aware recursive name server MUST disregard the CD bit and
EDNS: DO=1, size=4000 perform normal signature validation unless:
QUERY:
www.sub.example.com. IN A
ANSWER:
;; empty
AUTHORITY:
sub.example.com. IN NS ns.sub.example.com.
IN DS ...
IN RRSIG DS ... o the name server side received that query via a secure channel; or
ADDITIONAL:
ns.sub.example.com. IN A 10.10.10.3
A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A o the recursive name server's local policy dictates that the
would result in a referral to an unsigned zone. The resolver knows recursive name server honor the CD bit even when received via an
not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS insecure channel.
bit in the NSEC RR bitmap in the referral is not set. Even if DNSSEC
RRs are present in responses from "sub-nosig.example.com" name
servers, the resolver will not be able to construct a authentication
chain, since there is a break between "sub-nosig.example.com" and its
delegating parent zone.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) Discussion of cases in which the CD bit is set to one in the rest of
EDNS: DO=1, size=4000 this section assumes that one or both of the above conditions applies
QUERY: to the query being processed. If neither condition applies, the
www.sub-nosig.example.com. IN A recursive name server MUST process the query as if the CD bit were
ANSWER: set to zero. Note, however, that the name server side MUST always
;; empty copy the setting of the CD bit from a query to the corresponding
AUTHORITY: response, regardless of whether or not the recursive name server
sub-nosig.example.com. IN NS ns.sub-nosig.example.com. trusts the setting of the CD bit.
IN NSEC ;; (DS bit not set)
IN RRSIG NSEC ...
ADDITIONAL:
ns.sub-nosig.example.com. IN A 10.10.10.4
A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name The name server side of a security-aware recursive name server MUST
error, because the name does not exist and is not covered by wildcard pass the sense of the CD bit to the resolver side along with the rest
expansion. Therefore, the name server must present proof that the of an initiating query, so that the resolver side will know whether
name does not exist, and that no wildcard expansion is present which or not it is required to verify the response data it returns to the
could have been used to answer the query. name server side. If the CD bit is set to one, it indicates that the
originating resolver is willing to perform whatever authentication
its local policy requires, thus the resolver side of the recursive
name server need not perform authentication on the RRsets in the
response. When the CD bit is set to one the recursive name server
SHOULD, if possible, return the requested data to the originating
resolver even if the recursive name server's local authentication
policy would reject the records in question. That is, by setting the
CD bit, the originating resolver has indicated that it takes
responsibility for performing its own authentication, and the
recursive name server should not interfere.
Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) If the resolver side implements a BAD cache (see Section 4.1) and the
EDNS: DO=1, size=4000 name server side receives a query which matches an entry in the
QUERY: resolver side's BAD cache, the name server side's response depends on
f.example.com. IN A the sense of the CD bit in the original query. If the CD bit is set,
ANSWER: the name server side SHOULD return the data from the BAD cache; if
;; empty the CD bit is not set, the name server side MUST return RCODE 2
AUTHORITY: (server failure).
example.com. IN SOA ...
IN RRSIG SOA ...
c.example.com. IN NSEC sub.example.com. ...
IN RRSIG NSEC ...
*.example.com. IN NSEC a.example.com. ...
IN RRSIG NSEC ...
ADDITIONAL:
example.com. IN DNSKEY ...
IN RRSIG DNSKEY ...
A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX 3.2.3 The AD bit
RR synthesized via wildcard expansion. The name server must prove
that no exact match exists.
Flags: QR=1, AA=1, RCODE=0 (NOERROR) The name server side of a security-aware recursive name server MUST
EDNS: DO=1, size=4000 NOT set the AD bit in a response unless the name server considers all
QUERY: RRsets in the Answer or Authority sections of the response to be
f.example.com. IN MX authentic, and SHOULD set the AD bit if and only if the resolver side
ANSWER: considers all RRsets in the Answer section and any relevant negative
f.example.com. IN MX 10 a.example.com. response RRs in the Authority section to be authentic. The resolver
IN RRSIG MX ... side MUST follow the procedure described in Section 5 to determine
AUTHORITY: whether the RRs in question are authentic.
example.com. IN NS a.example.com.
IN NS b.example.com.
IN RRSIG NS ...
c.example.com. IN NSEC sub.example.com.
IN RRSIG NSEC ...
ADDITIONAL:
a.example.com. IN A 10.10.10.1
IN RRSIG A ...
b.example.com. IN A 10.10.10.2
IN RRSIG A ...
If these responses came from a recursive name server which had all of 3.3 Example DNSSEC Responses
the necessary RRsets in its cache instead of from an authoritative
server, the only differences would be the TTLs and the header flags. See Appendix B for example response packets.
The AA bit would not be set, and the AD bit would be set if (and only
if) all the RRsets in a response passed the security policy checks of
the recursive name server.
4. Resolving 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 a specific to security-aware recursive name servers are described in
separate subsection. Section 3.2.
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
skipping to change at page 19, line 46 skipping to change at page 19, line 46
o Validation for this query has been disabled by local policy. o Validation for this query has been disabled by local policy.
A security-aware resolver's support for signature verification MUST A security-aware resolver's support for signature verification MUST
include support for verification of wildcard owner names. include support for verification of wildcard owner names.
A security-aware resolver MUST attempt to retrieve missing DS, A security-aware resolver MUST attempt to retrieve missing DS,
DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
RRs in order to perform signature verification. RRs in order to perform signature verification.
A security-aware resolver MUST attempt to retrieve missing a NSEC RR A security-aware resolver MUST attempt to retrieve a missing NSEC RR
which the resolver needs to authenticate a NODATA response. In which the resolver needs to authenticate a NODATA response. In
general it is not possible for a resolver to retrieve missing NSEC general it is not possible for a resolver to retrieve missing NSEC
RRs, since the resolver will have no way of knowing the owner name of RRs, since the resolver will have no way of knowing the owner name of
the missing 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
the parental side at a zone cut, a security-aware iterative-mode
resolver MUST query the name servers for the parent zone, not the
child zone.
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 starting point 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.
skipping to change at page 20, line 42 skipping to change at page 20, line 47
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.
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.
A security-aware resolver SHOULD NOT cache data with invalid A security-aware resolver MAY set the CD bit in a query to one in
signatures under normal circumstances. However, a security-aware order to indicate that the resolver takes responsibility for
resolver SHOULD take steps to rate limit the number of identical performing whatever authentication its local policy requires on the
queries it generates, which may require the resolver to retain some RRsets in the response. See Section 3.2 for the effect this bit has
data about recently generated queries. Conceptually, this is similar on the behavior of security-aware recursive name servers.
to negative caching [RFC2308], but since the resolver has no way of
obtaining the appropriate caching TTL from received data in this
case, the TTL will have to be set by the implementation. This
document refers data retained as part of such a rate limiting
mechanism as the "BAD cache".
4.1 Recursive Name Servers A security-aware resolver MUST zero the AD bit when composing query
messages.
As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware 4.1 Rate Limiting
recursive name server is an entity which acts in both the
security-aware name server and security-aware resolver roles. This
section uses the terms "name server side" and "resolver side" to
refer to the code within a security-aware recursive name server which
implements the security-aware name server role and the code which
implements the security-aware resolver role, respectively.
A security-aware recursive name server MUST NOT attempt to answer a A security-aware resolver SHOULD NOT cache data with invalid
query by piecing together cached data it received in response to signatures under normal circumstances. However, a security-aware
previous queries that requested different QNAMEs, QTYPEs, or resolver SHOULD take steps to rate limit the number of identical
QCLASSes. A security-aware recursive name server MUST NOT use NSEC queries that it generates if signature validation of the responses
RRs from one negative response to synthesize a response for a fails repeatedly.
different query. A security-aware recursive name server MUST NOT use
a previous wildcard expansion to generate a response to a different
query.
The name server side of a security-aware recursive name server MUST Conceptually, this is similar in some respects to negative caching
pass the sense of the CD bit to the resolver side along with the rest [RFC2308], but since the resolver has no way of obtaining an
of an initiating query, so that the resolver side will know whether appropriate caching TTL from received data in this case, the TTL will
whether or not it is required to verify the response data it returns have to be set by the implementation. This document refers to the
to the name server side. data retained as part of such a rate limiting mechanism as the "BAD
cache".
The resolver side of a security-aware recursive name server MUST set A security-aware resolver MAY chose to retain RRsets for which
the DO bit when sending requests, regardless of the state of the DO signature validation has failed in its BAD cache, but MUST NOT return
bit in the initiating request received by the name server side. If such RRsets from its BAD cache unless both of the following
the DO bit in an initiating query is not set, the name server side conditions are met:
MUST strip any authenticating DNSSEC RRs from the response, but but
MUST NOT strip any DNSSEC RRs that the initiating query explicitly
requested.
The resolver side MUST follow the usual rules for caching and o The resolver has recently generated enough queries identical to
negative caching which would apply to any security-aware resolver. this one that the resolver is suppressing queries for this <QNAME,
QTYPE, QCLASS>; and
If the name server side receives a query which matches an entry in o The resolver is not required to validate the signatures of the
the resolver side's BAD cache, the name server side's response RRsets in question under the rules given in Section 4 of this
depends on the setting of the CD bit in the original query. If the document.
CD bit is set, the name server side SHOULD return the data from the
BAD cache; if the CD bit is not set, the name server side SHOULD
return RCODE 2 (server failure).
The name server side of a security-aware recursive name server MUST The intent of the above rule is to provide the raw data to clients
NOT set the AD bit in a response unless the name server considers all which are capable of performing their own signature verification
RRsets in the Answer or Authority sections of the response to be checks while protecting clients which depend on this resolver to
authentic, and SHOULD set the AD bit if and only if the name server perform such checks. Several of the possible reasons why signature
considers all RRsets in the Answer section and any relevant negative validation might fail involve conditions which may not apply equally
response RRs in the Authority section to be authentic. How the name to this resolver and the client which invoked it: for example, this
server side of a security-aware recursive name server determines resolver's clock may be set incorrectly, or the client may have
whether an RRset is authentic depends on the origin of the RRset. If knowledge of a relevant island of security which this resolver does
the RRset came from the resolver side of the recursive name server not share. In such cases, "protecting" a client which is capable of
(the normal case), recursive name server MUST follow the procedure performing its own signature validation from ever seeing the "bad"
described in Section 5. If the RRset came from a zone for which the data does not help the client.
name server side of the recursive name server is authoritative, local
policy MAY consider the RRset to be authentic without further
verification simply because the RRset came from an authoritative
zone, but the name server SHOULD NOT do so unless the it obtained the
authoritative zone via secure means (such as a secure zone transfer
mechanism), and MUST NOT do so unless this behavior has been
configured explicitly.
4.2 Stub resolvers 4.2 Stub resolvers
A security-aware stub resolver MUST include an EDNS [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
skipping to change at page 25, line 22 skipping to change at page 24, line 22
resolver has been configured with public key information for the resolver has been configured with public key information for the
zone, or if the zone's parent is signed and the delegation from the zone, or if the zone's parent is signed and the delegation from the
parent contains a DS RRset. parent contains a DS RRset.
5.1 Special Considerations for Islands of Security 5.1 Special Considerations for Islands of Security
Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
zones for which it is not possible to construct an authentication zones for which it is not possible to construct an authentication
chain to the zone from its parent. Validating signatures within an chain to the zone from its parent. Validating signatures within an
island of security requires the validator to have some other means of island of security requires the validator to have some other means of
obtaining a trusted zone key. If a validator cannot obtain such a obtaining an initial authenticated zone key for the island. If a
key, it will have to choose whether to accept the unvalidated validator cannot obtain such a key, it will have to choose whether to
responses or not based on local policy. accept the unvalidated responses or not based on local policy.
All the normal processes for validating responses apply to islands of All the normal processes for validating responses apply to islands of
security. The only difference between normal validation and security. The only difference between normal validation and
validation within an island of security is in how the validator validation within an island of security is in how the validator
obtains a trusted starting point for the authentication chain. obtains a starting point for the authentication chain.
5.2 Authenticating Referrals 5.2 Authenticating Referrals
Once the apex DNSKEY RRset for a signed parent zone has been Once the apex DNSKEY RRset for a signed parent zone has been
authenticated, DS RRsets can be used to authenticate the delegation authenticated, DS RRsets can be used to authenticate the delegation
to a signed child zone. A DS RR identifies a DNSKEY RR in the child to a signed child zone. A DS RR identifies a DNSKEY RR in the child
zone's apex DNSKEY RRset, and contains a cryptographic digest of the zone's apex DNSKEY RRset, and contains a cryptographic digest of the
child zone's DNSKEY RR. A strong cryptographic digest algorithm child zone's DNSKEY RR. A strong cryptographic digest algorithm
ensures that an adversary can not easily generate a DNSKEY RR that ensures that an adversary can not easily generate a DNSKEY RR that
matches the digest. Thus, authenticating the digest allows a matches the digest. Thus, authenticating the digest allows a
skipping to change at page 26, line 15 skipping to change at page 25, line 15
the DS RR's Digest Type field, results in a digest value which the DS RR's Digest Type field, results in a digest value which
matches the Digest field of the DS RR; and matches the Digest field of the DS RR; and
o The matching DNSKEY RR in the child zone has the Zone Flag bit set o The matching DNSKEY RR in the child zone has the Zone Flag bit set
to one, the corresponding private key has signed the child zone's to one, the corresponding private key has signed the child zone's
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
child zone's apex DNSKEY RRset. child zone's apex DNSKEY RRset.
If the referral from the parent zone did not contain a DS RRset, the If the referral from the parent zone did not contain a DS RRset, the
response should have included a signed NSEC RRset proving that no DS response should have included a signed NSEC RRset proving that no DS
RRset exists for the delegated name (see Section 3.4). A RRset exists for the delegated name (see Section 3.1.4). A
security-aware resolver MUST query the name servers for the parent security-aware resolver MUST query the name servers for the parent
zone for the DS RRset if the referral includes neither a DS RRset nor zone for the DS RRset if the referral includes neither a DS RRset nor
a NSEC RRset proving that the DS RRset does not exist (see Section a NSEC RRset proving that the DS RRset does not exist (see Section
4). 4).
If the resolver authenticates an NSEC RRset which proves that no DS If the resolver authenticates an NSEC RRset which proves that no DS
RRset is present for this zone, then there is no authentication path RRset is present for this zone, then there is no authentication path
leading from the parent to the child. If the resolver has an initial leading from the parent to the child. If the resolver has an initial
DNSKEY or DS RR which belongs to the child zone or to any delegation DNSKEY or DS RR which belongs to the child zone or to any delegation
below the child zone, this initial DNSKEY or DS RR MAY be used to below the child zone, this initial DNSKEY or DS RR MAY be used to
skipping to change at page 29, line 9 skipping to change at page 28, line 9
name = fqdn name = fqdn
if rrsig_labels < fqdn_labels, if rrsig_labels < fqdn_labels,
name = "*." | the leftmost rrsig_label labels of the name = "*." | the leftmost rrsig_label labels of the
fqdn fqdn
if rrsig_labels > fqdn if rrsig_labels > fqdn
the RRSIG RR did not pass the necessary validation the RRSIG RR did not pass the necessary validation
checks and MUST NOT be used to authenticate this checks and MUST NOT be used to authenticate this
RRset. RRset.
Section 5.5.1 gives an example of original name calculation. The The canonical forms for names and RRsets are defined in
canonical forms for names and RRsets are defined in
[I-D.ietf-dnsext-dnssec-records]. [I-D.ietf-dnsext-dnssec-records].
NSEC RRsets at a delegation boundary require special processing. NSEC RRsets at a delegation boundary require special processing.
There are two distinct NSEC RRsets associated with a signed delegated There are two distinct NSEC RRsets associated with a signed delegated
name. One NSEC RRset resides in the parent zone, and specifies which name. One NSEC RRset resides in the parent zone, and specifies which
RRset are present at the parent zone. The second NSEC RRset resides RRset are present at the parent zone. The second NSEC RRset resides
at the child zone, and identifies which RRsets are present at the at the child zone, and identifies which RRsets are present at the
apex in the child zone. The parent NSEC RRset and child NSEC RRset apex in the child zone. The parent NSEC RRset and child NSEC RRset
can always be distinguished since only the child NSEC RRs will can always be distinguished since only the child NSEC RRs will
specify an SOA RRset exists at the name. When reconstructing the specify an SOA RRset exists at the name. When reconstructing the
skipping to change at page 30, line 42 skipping to change at page 29, line 41
If the number of labels in an RRset's fully qualified domain name is If the number of labels in an RRset's fully qualified domain name is
greater than the Labels field in the covering RRSIG RDATA, then the greater than the Labels field in the covering RRSIG RDATA, then the
RRset and its covering RRSIG RR were created as a result of wildcard RRset and its covering RRSIG RR were created as a result of wildcard
expansion. Once the resolver has verified the signature as described expansion. Once the resolver has verified the signature as described
in Section 5.3, the resolver must take additional steps to verify the in Section 5.3, the resolver must take additional steps to verify the
non-existence of an exact match or closer wildcard match for the non-existence of an exact match or closer wildcard match for the
query. Section 5.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.3). NSEC RRs needed to authenticate the response (see Section 3.1.3).
5.4 Authenticated Denial of Existence 5.4 Authenticated Denial of Existence
A resolver can use authenticated NSEC RRs to prove that an RRset is A resolver can use authenticated NSEC RRs to prove that an RRset is
not present in a signed zone. Security-aware name servers should not present in a signed zone. Security-aware name servers should
automatically include any necessary NSEC RRs for signed zones in automatically include any necessary NSEC RRs for signed zones in
their responses to security-aware resolvers. their responses to security-aware resolvers.
Security-aware resolvers MUST first authenticate NSEC RRsets Security-aware resolvers MUST first authenticate NSEC RRsets
according to the standard RRset authentication rules described in according to the standard RRset authentication rules described in
skipping to change at page 31, line 39 skipping to change at page 30, line 37
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 truncation), then
a security-aware resolver MUST resend the query in order to attempt a security-aware resolver MUST resend the query in order to attempt
to obtain the full collection of NSEC RRs necessary to verify to obtain the full collection of NSEC RRs necessary to verify
non-existence of the requested RRset. As with all DNS operations, non-existence of the requested RRset. As with all DNS operations,
however, the resolver MUST bound the work it puts into answering any however, the resolver MUST bound the work it puts into answering any
particular query. particular query.
Since a verified NSEC RR proves the existance 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.
5.5 Examples Authentication examples are given in Section Appendix C.
Editors' note: perhaps all of this should move to an appendix?
5.5.1 Example of Re-Constructing the Original Owner Name
Suppose that a security-aware resolver receives a response containing
an answer RRset with an owner name of is "www.a.b.c.example.com".
This fully qualified domain name has 6 labels: "www", "a", "b", "c",
"example", and "com". What name the resolver should use when
reconstructing the original signed data depends on the value of the
RRSIG RR's Labels field.
If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's
Labels field matches the number of labels in the owner name, and the
resolver should assume that this RRset is not the result of wildcard
expansion. The resolver should therefore use "www.a.b.c.example.com"
as the owner name when reconstructing the original signed data for
the signature check.
If the value of the RRSIG RR's Labels field is less than 6, then the
RRSIG RR's Labels count is less than the number of labels in the
RRset's owner name, and the resolver should assume that this RRset is
the result of wildcard expansion. The resolver should therefore
reconstruct the original owner name by replacing the labels which
appear to be the result of wildcard expansion with a single "*."
label. For example, if the RRSIG RR's Labels field is 3, the
resolver should reconstruct the original owner name by prepending
"*." to the last 3 labels of the owner name of the answer RRset.
Thus, the resolver should use "*.c.example.com" as the owner name
when reconstructing the original signed data.
If the value of the RRSIG RR's Labels field is greater than 6, then
this RRSIG RR cannot possibly be valid for the answer RRset, and
there is no point in attempting to validate the signature.
5.5.2 Examples of Authenticating a Response
Editors' note: Eventually this will be an example of the
authentication process for "www.example.com", starting from an
initial root key.
Editors' note: Eventually this will be an example of the
authentication process for non-existent "www.a.b.c.example.com",
starting from an initial root key.
6. IANA Considerations 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 34, line 9 skipping to change at page 32, line 9
document. document.
[RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
and defined its use. The use is restated but not altered in this and defined its use. The use is restated but not altered in this
document. document.
7. Security Considerations 7. Security Considerations
This document describes how the DNS security extensions use public This document describes how the DNS security extensions use public
key cryptography to sign and authenticate DNS resource record sets. key cryptography to sign and authenticate DNS resource record sets.
Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
security considerations related to DNSSEC.
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
protection which DNSSEC attempts to provide to security-oblivious
recursive-mode resolvers. For this reason, use of these control bits
by a security-aware recursive-mode resolver requires a secure
channel. See Section 3.2.2 and Section 4.2 for further discussion.
DNSSEC introduces a number of denial of service issues. These issues DNSSEC introduces a number of denial of service issues. These issues
will also be addressed in a future version of these security will also be addressed in a future version of these security
considerations. considerations.
Please see [I-D.ietf-dnsext-dnssec-intro] for general security
considerations related to DNSSEC.
8. Acknowledgements 8. Acknowledgements
This document was created from the input and ideas of several members This document was created from the input and ideas of several members
of the DNS Extensions Working Group and working group mailing list. of the DNS Extensions Working Group and working group mailing list.
The co-authors of this draft would like to express their thanks for The editors would like to express their thanks for the comments and
the comments and suggestions received during the revision of these suggestions received during the revision of these security extension
security extension specifications. specifications.
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 36, line 34 skipping to change at page 34, line 34
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001. message size requirements", RFC 3226, December 2001.
[I-D.ietf-dnsext-dnssec-intro] [I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-06 (work in progress), draft-ietf-dnsext-dnssec-intro-07 (work in progress),
September 2003. October 2003.
[I-D.ietf-dnsext-dnssec-records] [I-D.ietf-dnsext-dnssec-records]
Arends, R., Austein, R., Larson, M., Massey, D. and S. Arends, R., Austein, R., Larson, M., Massey, D. and S.
Rose, "Resource Records for DNS Security Extensions", Rose, "Resource Records for DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-04 (work in progress), draft-ietf-dnsext-dnssec-records-05 (work in progress),
September 2003. October 2003.
Informative References Informative References
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998. NCACHE)", RFC 2308, March 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
skipping to change at page 37, line 27 skipping to change at page 35, line 27
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[I-D.ietf-dnsext-delegation-signer] [I-D.ietf-dnsext-delegation-signer]
Gudmundsson, O., "Delegation Signer Resource Record", Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-15 (work in progress), draft-ietf-dnsext-delegation-signer-15 (work in progress),
June 2003. June 2003.
[I-D.ietf-dnsext-wcard-clarify] [I-D.ietf-dnsext-wcard-clarify]
Halley, B. and E. Lewis, "Clarifying the Role of Wild Card Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
Domains in the Domain Name System", Domains in the Domain Name System",
draft-ietf-dnsext-wcard-clarify-01 (work in progress), draft-ietf-dnsext-wcard-clarify-02 (work in progress),
August 2003. September 2003.
[I-D.ietf-dnsext-ad-is-secure] [I-D.ietf-dnsext-ad-is-secure]
Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD
bit", draft-ietf-dnsext-ad-is-secure-06 (work in bit", draft-ietf-dnsext-ad-is-secure-06 (work in
progress), June 2002. progress), June 2002.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
Drienerlolaan 5 Drienerlolaan 5
7522 NB Enschede 7522 NB Enschede
NL NL
skipping to change at page 39, line 5 skipping to change at page 37, line 5
EMail: masseyd@isi.edu EMail: masseyd@isi.edu
Scott Rose Scott Rose
National Institute for Standards and Technology National Institute for Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899-8920 Gaithersburg, MD 20899-8920
USA USA
EMail: scott.rose@nist.gov EMail: scott.rose@nist.gov
Appendix A. Algorithm For Handling Wildcard Expansion Appendix A. Signed Zone Example
For zone (Z) and a name (N) that may occur in Z, the following
algorithm finds all wildcard RRsets that match N or returns an NSEC
RRset that proves no wildcard expansion matches N. The algorithm was
written for clarity, not efficiency:
0. INPUT: a name (N) and a zone (Z).
INIT: NSEC_SET = NULL
1. Construct S = sequence of all names in Z, sorted
into canonical order.
2. If N exists in S
There is an exact match for N.
Return all RRsets associated with N
Else
Add the name that would immediately
precede N in S to NSEC_SET.
EndIf
3. Replace the leftmost label of N with *
4. If N exists in S and answers the query
There is a positive wildcard match for N.
Return all RRsets associated with N
Else
Add the NSEC for name that would immediately
precede N in S to NSEC_SET.
Return the NSEC_SET.
EndIf
5. Remove the leading * from N.
6. If N exists in S
There is a name that terminates the wildcard search.
Add the NSEC for N to NSEC_SET and return NSEC_SET.
Else
Add the NSEC for name that would immediately
precede N in S to NSEC_SET.
Return the NSEC_SET.
EndIf
Appendix B. 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.ns1.example. (
1064876255 1065745538
3600 3600
300 300
3600000 3600000
3600 3600
) )
3600 RRSIG SOA 1 1 3600 20031029215736 ( 3600 RRSIG SOA 1 1 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
ahgGvtiSMzzSS7n65xfxc1X78Nw= ) LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
3600 NS ns1.example. 3600 NS ns1.example.
3600 NS ns2.example. 3600 NS ns2.example.
3600 RRSIG NS 1 1 3600 20031029215736 ( 3600 RRSIG NS 1 1 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3 exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
TYq3Ed0R9VStJwtiKmoXqubFAr0= ) BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
3600 MX 1 xx.example. 3600 MX 1 xx.example.
3600 RRSIG MX 1 1 3600 20031029215736 ( 3600 RRSIG MX 1 1 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9 CSB4g+vSxyrfsfycsZwAx2hKhwK/x7GAIY0p
Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo MLBgAA/USiiMben0II4aYf5lybs0NINnFDju
djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW 2Kc78M8t9zBGeJcZCZEs9mKiXhW8WJanvIjg
BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM BwJgWXwAnVnq20TXlsHiuwuhmtrb76/Avl4i
5gmIc/F6gzUL3/KyJA8zPF2fUVA= ) lnX6XA3eeDlQlOTuPe0B91MCuow= )
3600 NSEC a.example. NS SOA MX RRSIG NSEC 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
3600 RRSIG NSEC 1 1 3600 20031029215736 ( 3600 RRSIG NSEC 1 1 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/ krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
DBRONckIWXn2chGDeicQuEHjhfQ= ) 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
3600 DNSKEY 256 3 1 ( 3600 DNSKEY 256 3 1 (
AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO AQPdhnap0Oj2jUq74g+vel5cukdH+wpzjiH8
G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3 ZOQSOHrw+s3TmbhyqXbZ/j5Uu9p65ARoevvG
LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd yv459dxxZCKZ4wftXe5BUkJvZVf8HnhYW5R+
kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG kQduVeqGVlkBarL5haKX28Pxvs8tV7CyY/Rd
mK5G3NeHjqssh1AujDaqHFf5IRIeQQ== cfnJlZyJcfwY0ETo4P2gntVMERZuJQ==
) )
3600 DNSKEY 257 3 1 ( 3600 DNSKEY 257 3 1 (
AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb
SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ
TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm
+6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL
rsSftzmRYHou70oVQ7aBjd9ePPCOVw== oNqpieIQd2t+rd/oF8/++DRtzF0toQ==
) )
3600 RRSIG DNSKEY 1 1 3600 20031029215736 ( 3600 RRSIG DNSKEY 1 1 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk EtFrBqs8i80Ath+xOtjPHcepV/cjATf2E1fo
4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF +fhSggjw2vAXDY4Sygk2tKZ9Tvhahmw1rRC3
kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2 CnApLvsjQ9qmnYAvkZdMILw9gPx1rBaq9d7H
lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx nt7mPc/LFrO4G9JS6JNwBCnjwcxro8kNYLo6
lOyOxNDJPATE3Wm+AX0SmQSJ3XY= ) 97FCO3y4T7y9Hb80OvCZ36cNdps= )
3600 RRSIG DNSKEY 1 1 3600 20031108232541 (
20031009232541 23853 example.
VseD0IGDKqJXiZMJnRNuq89ibF5g8VGPmMJS
h/hS8+nu5vLiyEObJcVxfanslAlBQSGHmJsM
AvXpeJUrT/zOyZ8vfy/igMhd25rnSxAD6uhl
4ohJiiPtFvHgLEvT0QZHizrP4wMvpXvfwn03
1/VEFzXZ0rULlTdWjoNzSMIYBwg= )
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 23677 1 1 ( 3600 DS 42939 1 1 (
F248F32298280A061736C93FB078A51C17CC 4BA08982E5739A60E02B69409B0927F9524E
C291 ) 3494 )
3600 RRSIG DS 1 2 3600 20031029215736 ( 3600 RRSIG DS 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
YJs3G/9tNte9i25YtAuLHbD2UqY= ) iHQEOrm7yXIHwnrre1iuzMZn1jY= )
3600 NSEC ai.example. NS DS RRSIG NSEC 3600 NSEC ai.example. NS DS RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs mhov2WXDa2Swk/7/VQoI36e5OKvd/0CmMWdi
T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By +3k/+i7mo9omz854ZBFMLaQzFvaS7Cn//I/H
d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6 7tYSY/fScUrs/UfB7le0DzdocsoaMYtexSS1
iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9 KA7ofbPdYpBHngIGbO5EHaGrqbKGY61fIQ/g
gURpK8RlfEPb7O98rrYLWZbzg3o= ) /WvT0KXnoX+v31Oq3VstBoWmizo= )
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 20031029215736 ( 3600 RRSIG A 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY
RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
vVNUzslGEBlQ0SJZkWJcCtRDo5c= ) 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
UU/kYIPkm9qpSE3wtELJEq2cNsU= )
3600 HINFO "KLH-10" "ITS" 3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 1 2 3600 20031029215736 ( 3600 RRSIG HINFO 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2 jDn/zgIqY5ucajWNW333u+KfxORI55wvnZDs
jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP pCHZQ9ISjWNT7467wUcfJKBaG+alNlCOJExg
NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9 z8yUS5NwySlrFtGL/CBCxmrSVioKMMetg7gP
uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT Qb6x5A53OhsQAGT6azS9bdBM2RFbqBkeZkXA
6IAiGfqY/zYFXWSIsmJr0875PQ0= ) 8mJ/QOldXdH5iPpmZb2Pn47x7V4= )
3600 AAAA 2001:db8::f00:baa9 3600 AAAA 2001:db8::f00:baa9
3600 RRSIG AAAA 1 2 3600 20031029215736 ( 3600 RRSIG AAAA 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4 uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
KI0DhRWJC/iKs6J963WLNdPnwKk= ) 8gB4wQFPYoozOQYTprwGtIHR2k8= )
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM W3fFJqdRtmpz9QikpK+v5rL+Y5iNpx5H7X7c
J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ 1yPMlcaS0nhowHGjCPnNbCP28Ktv9I5eqhO1
U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji N/A75FLTOe9L5Qzetb/C3/ME8D46apKLBEv5
qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL 0GWsJqTsijj4dAjup60yeLPXTWxIdO6RNdfe
SpV8hBOC+EAcLjnuAi5DJJlONmc= ) Qd56t0fY79/kd25RzRCFGs2qHXs= )
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 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
u2x/e3zoBQdHAId3LCOO9jYDzCc= ) BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
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 20031029215736 ( 3600 RRSIG A 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
fdZ587NLR1Ns2GraGTztUDMSK/A= ) Oett68JnQVQq2l/DhWsJSjuIFBQ= )
3600 NSEC ns2.example. A RRSIG NSEC 3600 NSEC ns2.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
I2mIq/WvuXTr2XKcJDbxYIdSyss= ) o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )
ns2.example. 3600 IN A 192.0.2.2 ns2.example. 3600 IN A 192.0.2.2
3600 RRSIG A 1 2 3600 20031029215736 ( 3600 RRSIG A 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
IGUMRh8nFi+wnG09+OH46IlkB9s= ) 8Ic8f9zHwZmCUc0wnxX6x+422PM= )
3600 NSEC *.w.example. A RRSIG NSEC 3600 NSEC *.w.example. A RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3 kkYPMaBn4zJM/iQAOO9i81X57MMCQnzk+pch
pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ 6tWUFF/D1ZFZf8QY2MzwDA5Bv/1DluWVbo3x
64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs WjzyUV7fn77k9QKLQseUSXGnpyL2HR1hGfBV
n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/ 6ZHAqJc99t5+5vjyiflLtOpA0+Ri46SlQGZf
2aw1RkmYb4LbuhP0uwN/lZqQVik= ) IZ4X2Ksgn+hpIu77NRQMdmh59M8= )
*.w.example. 3600 IN MX 1 ai.example. *.w.example. 3600 IN MX 1 ai.example.
3600 RRSIG MX 1 2 3600 20031029215736 ( 3600 RRSIG MX 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+ b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
G7zd/X4PmuWIIYG+5IAzmtB2UJs= ) FxfIqrcIL24dO4Ytdz2ifqvJmuM= )
3600 NSEC x.w.example. MX RRSIG NSEC 3600 NSEC x.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
tXBqjlbdFl70S+dzovir86EQBHavroozeo4f fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog 7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y 4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
w1LXOATBvP/kCRgmq4KdFNwTiBc= ) vOHmndDhRTDwVCg179qlrEIsOgE= )
x.w.example. 3600 IN MX 1 xx.example. x.w.example. 3600 IN MX 1 xx.example.
3600 RRSIG MX 1 3 3600 20031029215736 ( 3600 RRSIG MX 1 3 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
+tqUhrmtTxtItfpV/8Q7i6+B2bY= ) IKZXg2219TD4UqJuRATLhxZj2fU= )
3600 NSEC x.y.w.example. MX RRSIG NSEC 3600 NSEC x.y.w.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 3 3600 20031029215736 ( 3600 RRSIG NSEC 1 3 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4 VTRE+Bu91QK7dBiMshr04tE/I5HCvSrjqDv+
EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP b4tlUqUqkv4MoxfoceUwavMkdLm9Pi/aYUrS
M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi m6XVGBDAjpDmjivlMKNkME8c0f7oQ3E1CtHS
lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29 pPLjTcB9WfxEOzjJJGK5BDDT6A56P4eibLiw
IgHVoBYahu8hE0DycgzLredhC5A= ) +bNx4OGknGvVqhg9pu5qEWi814s= )
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 20031029215736 ( 3600 RRSIG MX 1 4 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg yDPXa5Osa4r1AF0AjKWOo87kGNDlnVPmCbIi
Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk MPvBpzJ91d5TFtEZWYJpYv+eGWZCJhK7SsnL
h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7 Zbbjthkn7YmX1tReDQhn8aCQ6DyrIU6wZpj5
CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD ywBx0z3HGcqoYmv+AiFtcYVPxG0elsrakIwG
JYEmK1UOpYTDRx+lKLRI5tLzKmc= ) /e+CPi2yE2c9M+NnwMxhpEFVGRs= )
3600 NSEC xx.example. MX RRSIG NSEC 3600 NSEC xx.example. MX RRSIG NSEC
3600 RRSIG NSEC 1 4 3600 20031029215736 ( 3600 RRSIG NSEC 1 4 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27 sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
rKbS4qvhL+dfOnPBPNI099W7EAw= ) 66FPTb3/hhrHYkMneBO2Yvfvpj8= )
xx.example. 3600 IN A 192.0.2.10 xx.example. 3600 IN A 192.0.2.10
3600 RRSIG A 1 2 3600 20031029215736 ( 3600 RRSIG A 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
zJKlxAUeVRQ2ufYCoSY7wa6cIV4= ) aI16ggg9/UEWRbvn+7tp2UfMYSw= )
3600 HINFO "KLH-10" "TOPS-20" 3600 HINFO "KLH-10" "TOPS-20"
3600 RRSIG HINFO 1 2 3600 20031029215736 ( 3600 RRSIG HINFO 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61 vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku
DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9 6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj
5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM
opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB
hjNlRggyhvEmSNw4kvl5w99jqKg= ) AAwDzum3fUKzVM274T9O8ggeXgE= )
3600 AAAA 2001:db8::f00:baaa 3600 AAAA 2001:db8::f00:baaa
3600 RRSIG AAAA 1 2 3600 20031029215736 ( 3600 RRSIG AAAA 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
ndtF5V/pM6xI0tiE51KudVttsJI= ) GxlD/3EneV4+IIIv0hekxzpR8Qs= )
3600 NSEC example. A HINFO AAAA RRSIG NSEC 3600 NSEC example. A HINFO AAAA RRSIG NSEC
3600 RRSIG NSEC 1 2 3600 20031029215736 ( 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20030929215736 4638 example. 20031009232541 5742 example.
fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34 cKkFJS6Em56M0XCjMma4zFzy5ylHh2ma62oe
k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI yHrqkMYS+QVUuJ8yfAoXoFbok/kDLN3rsCKK
AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu ICJl1dFA3fvJnMejg0JVabQHShO2W1LmWegr
YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0 dh251WZQVtJHDRY8/ltYB+GHUuFpZ1CF4m+c
fQ5nfoBQ++eHo+IEohbqrwnE60E= ) 6EPqS1uLrFpRg3k4BV5y6146nZ8= )
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
Flags indicate that each of these DNSKEY RRs is a zone key. One of Flags indicate that each of these DNSKEY RRs is a zone key. One of
these DNSKEY RRs also has the SEP flag set and has been used to sign these DNSKEY RRs also has the SEP flag set and has been used to sign
the apex DNSKEY RRset; this is the key which should be hashed to the apex DNSKEY RRset; this is the key which should be hashed to
generate a DS record to be inserted into the parent zone. The other generate a DS record to be inserted into the parent zone. The other
DNSKEY is used to sign all the other RRsets in the zone. DNSKEY is used to sign all the other RRsets in the zone.
The zone includes a wildcard entry "*.w.example". Note that the name The zone includes a wildcard entry "*.w.example". Note that the name
"*.w.example" is used in constructing NSEC chains, and that the RRSIG "*.w.example" is used in constructing NSEC chains, and that the RRSIG
covering the "*.w.example" MX RRset has a label count of 2. covering the "*.w.example" MX RRset has a label count of 2.
The zone also includes two delegations. The delegation to The zone also includes two delegations. The delegation to
"b.example" includes an NS RRset, glue address records, and an NSEC "b.example" includes an NS RRset, glue address records, and an NSEC
RR; note that only the NSEC RRset is signed. The delegation to RR; note that only the NSEC RRset is signed. The delegation to
"a.example" provides a DS RR; note that only the NSEC and DS RRsets "a.example" provides a DS RR; note that only the NSEC and DS RRsets
are signed. are signed.
Appendix B. Example Responses
The examples in this section show response messages using the signed
zone example in Appendix A.
B.1 Answer
A successful query to an authoritative server.
;; Header: QR AA DO RCODE=0
;;
;; Question
x.w.example. IN MX
;; Answer
x.w.example. 3600 IN MX 1 xx.example.
x.w.example. 3600 RRSIG MX 1 3 3600 20031108232541 (
20031009232541 5742 example.
i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d
NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5
UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r
uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp
IKZXg2219TD4UqJuRATLhxZj2fU= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
example. 3600 RRSIG NS 1 1 3600 20031108232541 (
20031009232541 5742 example.
KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
;; Additional
xx.example. 3600 IN A 192.0.2.10
xx.example. 3600 RRSIG A 1 2 3600 20031108232541 (
20031009232541 5742 example.
ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp
Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v
ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd
+N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4
aI16ggg9/UEWRbvn+7tp2UfMYSw= )
xx.example. 3600 AAAA 2001:db8::f00:baaa
xx.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 (
20031009232541 5742 example.
LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43
YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27
ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+
AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0
GxlD/3EneV4+IIIv0hekxzpR8Qs= )
ns1.example. 3600 IN A 192.0.2.1
ns1.example. 3600 RRSIG A 1 2 3600 20031108232541 (
20031009232541 5742 example.
dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58
+ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF
cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE
HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s
Oett68JnQVQq2l/DhWsJSjuIFBQ= )
ns2.example. 3600 IN A 192.0.2.2
ns2.example. 3600 RRSIG A 1 2 3600 20031108232541 (
20031009232541 5742 example.
VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ
tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4
mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9
+huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas
8Ic8f9zHwZmCUc0wnxX6x+422PM= )
B.2 Name Error
An authoritative name error. The NSEC RRs prove that the name does
not exist and that no covering wildcard exists.
;; Header: QR AA DO RCODE=3
;;
;; Question
ml.example. IN A
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.ns1.example. (
1065745538
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
20031009232541 5742 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20031009232541 5742 example.
csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 1 1 3600 20031108232541 (
20031009232541 5742 example.
10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
;; Additional
;; (empty)
B.3 No Data Error
A "NODATA" response. The NSEC RR proves that the name exists and
that the requested RR type does not.
;; Header: QR AA DO RCODE=0
;;
;; Question
ns1.example. IN MX
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.ns1.example. (
1065745538
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
20031009232541 5742 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
ns1.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20031009232541 5742 example.
M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO
KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L
zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a
ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk
o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= )
;; Additional
;; (empty)
B.4 Referral to Signed Zone
Referral to a signed zone. The DS RR contains the data which the
resolver will need to validate the corresponding DNSKEY RR in the
child zone's apex.
;; Header: QR DO RCODE=0
;;
;; Question
mc.a.example. IN MX
;; Answer
;; (empty)
;; Authority
a.example. 3600 IN NS ns1.a.example.
a.example. 3600 IN NS ns2.a.example.
a.example. 3600 DS 42939 1 1 (
4BA08982E5739A60E02B69409B0927F9524E
3494 )
a.example. 3600 RRSIG DS 1 2 3600 20031108232541 (
20031009232541 5742 example.
Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/
gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp
zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H
YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c
iHQEOrm7yXIHwnrre1iuzMZn1jY= )
;; Additional
ns1.a.example. 3600 IN A 192.0.2.5
ns2.a.example. 3600 IN A 192.0.2.6
B.5 Referral to Unsigned Zone
Referral to an unsigned zone. The NSEC RR proves that no DS RR for
this delegation exists in the parent zone.
;; Header: QR DO RCODE=0
;;
;; Question
mc.b.example. IN MX
;; Answer
;; (empty)
;; Authority
b.example. 3600 IN NS ns1.b.example.
b.example. 3600 IN NS ns2.b.example.
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20031009232541 5742 example.
csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th
0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM
RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps
TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f
BFydo6dXwQ4WK8OUC6sMCM+OHEg= )
;; Additional
ns1.b.example. 3600 IN A 192.0.2.7
ns2.b.example. 3600 IN A 192.0.2.8
B.6 Wildcard Expansion
A successful query which was answered via wildcard expansion. The
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
closer match exists in the zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN MX
;; Answer
a.z.w.example. 3600 IN MX 1 ai.example.
a.z.w.example. 3600 RRSIG MX 1 2 3600 20031108232541 (
20031009232541 5742 example.
Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD
b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd
agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/
+T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20
FxfIqrcIL24dO4Ytdz2ifqvJmuM= )
;; Authority
example. 3600 NS ns1.example.
example. 3600 NS ns2.example.
example. 3600 RRSIG NS 1 1 3600 20031108232541 (
20031009232541 5742 example.
KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw
ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ
exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ
dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF
BYpCn/jKFJ7lYnYYGLAUofh/+mo= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 (
20031009232541 5742 example.
cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
66FPTb3/hhrHYkMneBO2Yvfvpj8= )
;; Additional
ai.example. 3600 IN A 192.0.2.9
ai.example. 3600 RRSIG A 1 2 3600 20031108232541 (
20031009232541 5742 example.
MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a
0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn
KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n
3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F
UU/kYIPkm9qpSE3wtELJEq2cNsU= )
ai.example. 3600 AAAA 2001:db8::f00:baa9
ai.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 (
20031009232541 5742 example.
LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1
ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC
uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG
qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv
8gB4wQFPYoozOQYTprwGtIHR2k8= )
B.7 Wildcard No Data Error
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
requested type and that no closer match exists in the zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
a.z.w.example. IN AAAA
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.ns1.example. (
1065745538
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
20031009232541 5742 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 (
20031009232541 5742 example.
cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj
R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb
w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P
sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa
66FPTb3/hhrHYkMneBO2Yvfvpj8= )
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
*.w.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 (
20031009232541 5742 example.
fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9
7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL
4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH
yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx
vOHmndDhRTDwVCg179qlrEIsOgE= )
;; Additional
;; (empty)
B.8 DS Child Zone No Data Error
A "NODATA" response for a QTYPE=DS query which was mistakenly sent to
a name server for the child zone.
;; Header: QR AA DO RCODE=0
;;
;; Question
example. IN DS
;; Answer
;; (empty)
;; Authority
example. 3600 IN SOA ns1.example. bugs.ns1.example. (
1065745538
3600
300
3600000
3600
)
example. 3600 RRSIG SOA 1 1 3600 20031108232541 (
20031009232541 5742 example.
0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb
8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v
BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff
pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX
LQTbyhlNTWdVYxPLo2T2dNP8a+0= )
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
example. 3600 RRSIG NSEC 1 1 3600 20031108232541 (
20031009232541 5742 example.
10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG
krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1
IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By
yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2
2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= )
;; Additional
;; (empty)
Appendix C. Authentication Examples
The examples in this section show how the response messages in
Appendix B are authenticated.
C.1 Authenticating An Answer
The query in section Appendix B.1 returned an MX RRset for
"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
resolver needs the corresponding DNSKEY RR in order to authenticate
this answer. The discussion below describes how a resolver might
obtain this DNSKEY RR.
The RRSIG indicates the original TTL of the MX RRset was 3600 and,
for the purpose of authentication, the current TTL is replaced by
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
is placed in canonical form and, assuming the current time falls
between the signature inception and expiration dates, the signature
is authenticated.
C.1.1 Authenticating the example DNSKEY RR
This example shows the logical authentication process that starts
from the a preconfigured root DNSKEY (or DS RR) and moves down the
tree to authenticate the desired "example" DNSKEY RR. Note the
logical order is presented for clarity and an implementation may
choose to construct the authentication as referrals are received or
may choose to construct the authentication chain only after all
RRsets have been obtained, or in any other combination it sees fit.
The example here demonstrates only the logical process and does not
dictate any implementation rules.
We assume the resolver starts with an preconfigured DNSKEY RR for the
root zone (or a preconfigured DS RR for the root zone). The resolver
checks this preconfigured DNSKEY RR is present in the root DNSKEY
RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset),
this DNSKEY RR has signed the root DNSKEY RRset and the signature
lifetime is valid. If all these conditions are met, all keys in the
DNSKEY RRset are considered authenticated. The resolver then uses
one (or more) of the root DNSKEY RRs to authenticate the "example" DS
RRset. Note the resolver may need to query the root zone to obtain
the root DNSKEY RRset and/or "example" DS RRset.
Once the DS RRset has been authenticated using the root DNSKEY, the
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
RR that matches one of the authenticated "example" DS RRs. If such a
matching "example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the "example"
DNSKEY RRset are considered authenticated.
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
is used to authenticated the RRSIG included in the response. If
multiple "example" DNSKEY RRs have algorithm 1 and key tag of 5742,
then each DNSKEY RR is tried and the answer is authenticated if
either DNSKEY RR validates the signature as described above.
C.2 Name Error
The query in section Appendix B.2 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
authenticated in a manner identical to that of the MX RRset discussed
above.
C.3 No Data Error
The query in section Appendix B.3 returned an NSEC RR that proves the
requested name exists, but the requested RR type does not exist. The
negative reply is authenticated by verifying the NSEC RR. The NSEC
RR is authenticated in a manner identical to that of the MX RRset
discussed above.
C.4 Referral to Signed Zone
The query in section Appendix B.4 returned a referral to the signed
"a.example." zone. The DS RR is authenticated in a manner identical
to that of the MX RRset discussed above. This DS RR is used to
authenticate the "a.example" DNSKEY RRset.
Once the "a.example" DS RRset has been authenticated using the
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
for some "a.example" DNSKEY RR that matches the DS RR. If such a
matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
RR has signed the "a.example" DNSKEY RRset and the signature lifetime
is valid. If all these conditions are met, all keys in the
"a.example" DNSKEY RRset are considered authenticated.
C.5 Referral to Unsigned Zone
The query in section Appendix B.5 returned a referral to an unsigned
"b.example." zone. The NSEC proves that no authentication leads from
"example" to "b.example" and the NSEC RR is authenticated in a manner
identical to that of the MX RRset discussed above.
C.6 Wildcard Expansion
The query in section Appendix B.6 returned an answer that was
produced as a result of wildcard expansion. The RRset expanded as
the similar to The corresponding RRSIG indicates the MX RRset was
signed by an "example" DNSKEY with algorithm 1 and key tag 5742. The
RRSIG indicates the original TTL of the MX RRset was 3600 and, for
the purpose of authentication, the current TTL is replaced by 3600.
The RRSIG labels field value of 2 indicates the answer the result of
wildcard expansion since the "a.z.w.example" name contains 4 labels.
The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset
is placed in canonical form and, assuming the current time falls
between the signature inception and expiration dates, the signature
is authenticated.
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
authenticated before the answer is considered valid.
C.7 Wildcard No Data Error
The query in section Appendix B.7 returned NSEC RRs that prove the
requested data does not exist and no wildcard applies. The negative
reply is authenticated by verifying both NSEC RRs.
C.8 DS Child Zone No Data Error
The query in section Appendix B.8 returned NSEC RRs that shows the
requested was answered by a child server ("example" server). The
NSEC RR indicates the presence of an SOA RR, showing the answer is
from the child . Queries for the "example" DS RRset should be sent
to the parent servers ("root" servers).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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