3250 lines
124 KiB
Plaintext
3250 lines
124 KiB
Plaintext
|
||
|
||
DNS Extensions R. Arends
|
||
Internet-Draft Telematica Instituut
|
||
Expires: August 16, 2004 M. Larson
|
||
VeriSign
|
||
R. Austein
|
||
ISC
|
||
D. Massey
|
||
USC/ISI
|
||
S. Rose
|
||
NIST
|
||
February 16, 2004
|
||
|
||
|
||
Protocol Modifications for the DNS Security Extensions
|
||
draft-ietf-dnsext-dnssec-protocol-05
|
||
|
||
Status of this Memo
|
||
|
||
This document is an Internet-Draft and is in full conformance with
|
||
all provisions of Section 10 of RFC2026.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that other
|
||
groups may also distribute working documents as Internet-Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at http://
|
||
www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This Internet-Draft will expire on August 16, 2004.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document is part of a family of documents which describe the DNS
|
||
Security Extensions (DNSSEC). The DNS Security Extensions are a
|
||
collection of new resource records and protocol modifications which
|
||
add data origin authentication and data integrity to the DNS. This
|
||
document describes the DNSSEC protocol modifications. This document
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 1]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
defines the concept of a signed zone, along with the requirements for
|
||
serving and resolving using DNSSEC. These techniques allow a
|
||
security-aware resolver to authenticate both DNS resource records and
|
||
authoritative DNS error indications.
|
||
|
||
This document obsoletes RFC 2535 and incorporates changes from all
|
||
updates to RFC 2535.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.1 Background and Related Documents . . . . . . . . . . . . . . 4
|
||
1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
|
||
1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
|
||
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
|
||
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6
|
||
2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6
|
||
2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7
|
||
2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
|
||
2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
|
||
2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9
|
||
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||
3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10
|
||
3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11
|
||
3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11
|
||
3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12
|
||
3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14
|
||
3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16
|
||
3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17
|
||
3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17
|
||
3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
|
||
3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
|
||
3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18
|
||
3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19
|
||
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
4.2 Signature Verification Support . . . . . . . . . . . . . . . 20
|
||
4.3 Determining Security Status of Data . . . . . . . . . . . . 21
|
||
4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22
|
||
4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22
|
||
4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22
|
||
4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23
|
||
4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
|
||
4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24
|
||
4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 2]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24
|
||
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26
|
||
5.1 Special Considerations for Islands of Security . . . . . . . 27
|
||
5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27
|
||
5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28
|
||
5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29
|
||
5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30
|
||
5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31
|
||
5.3.4 Authenticating A Wildcard Expanded RRset Positive
|
||
Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32
|
||
5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32
|
||
5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33
|
||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
|
||
7. Security Considerations . . . . . . . . . . . . . . . . . . 35
|
||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
|
||
Normative References . . . . . . . . . . . . . . . . . . . . 37
|
||
Informative References . . . . . . . . . . . . . . . . . . . 38
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
|
||
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40
|
||
B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46
|
||
B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
|
||
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47
|
||
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48
|
||
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49
|
||
B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50
|
||
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50
|
||
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51
|
||
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52
|
||
C. Authentication Examples . . . . . . . . . . . . . . . . . . 54
|
||
C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54
|
||
C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54
|
||
C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55
|
||
C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55
|
||
C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55
|
||
C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55
|
||
C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56
|
||
C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56
|
||
C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56
|
||
Intellectual Property and Copyright Statements . . . . . . . 57
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 3]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
1. Introduction
|
||
|
||
The DNS Security Extensions (DNSSEC) are a collection of new resource
|
||
records and protocol modifications which add data origin
|
||
authentication and data integrity to the DNS. 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
|
||
signing. Section 3 describes the modifications to authoritative name
|
||
server behavior necessary to handle signed zones. Section 4 describes
|
||
the behavior of entities which include security-aware resolver
|
||
functions. Finally, Section 5 defines how to use DNSSEC RRs to
|
||
authenticate a response.
|
||
|
||
1.1 Background and Related Documents
|
||
|
||
The reader is assumed to be familiar with the basic DNS concepts
|
||
described in RFC1034 [RFC1034] and RFC1035 [RFC1035].
|
||
|
||
This document is part of a family of documents which define DNSSEC.
|
||
An introduction to DNSSEC and definition of common terms can be found
|
||
in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC
|
||
resource records can be found in [I-D.ietf-dnsext-dnssec-records].
|
||
|
||
1.2 Reserved Words
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119. [RFC2119].
|
||
|
||
1.3 Editors' Notes
|
||
|
||
1.3.1 Open Technical Issues
|
||
|
||
1.3.2 Technical Changes or Corrections
|
||
|
||
Please report technical corrections to dnssec-editors@east.isi.edu.
|
||
To assist the editors, please indicate the text in error and point
|
||
out the RFC that defines the correct behavior. For a technical
|
||
change where no RFC that defines the correct behavior, or if there's
|
||
more than one applicable RFC and the definitions conflict, please
|
||
post the issue to namedroppers.
|
||
|
||
An example correction to dnssec-editors might be: Page X says
|
||
"DNSSEC RRs SHOULD be automatically returned in responses." This was
|
||
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
|
||
DNSSEC RR types MUST NOT be included in responses unless the resolver
|
||
indicated support for DNSSEC.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 4]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
1.3.3 Typos and Minor Corrections
|
||
|
||
Please report any typos corrections to dnssec-editors@east.isi.edu.
|
||
To assist the editors, please provide enough context for us to find
|
||
the incorrect text quickly.
|
||
|
||
An example message to dnssec-editors might be: page X says "the
|
||
DNSSEC standard has been in development for over 1 years". It
|
||
should read "over 10 years".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 5]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
2. Zone Signing
|
||
|
||
DNSSEC introduces the concept of signed zones. A signed zone
|
||
includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
|
||
the rules specified in Section 2.1, Section 2.2, Section 2.3 and
|
||
Section 2.4, respectively. A zone that does not include these
|
||
records according to the rules in this section is an unsigned zone.
|
||
|
||
DNSSEC requires a change to the definition of the CNAME resource
|
||
record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
|
||
and NSEC RRs to appear at the same owner name as a CNAME RR.
|
||
|
||
2.1 Including DNSKEY RRs in a Zone
|
||
|
||
To sign a zone, the zone's administrator generates one or more
|
||
public/private key pairs and uses the private key(s) to sign
|
||
authoritative RRsets in the zone. For each private key used to
|
||
create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with
|
||
the public component stored in the zone. A zone key DNSKEY RR MUST
|
||
have the Zone Key bit of the flags RDATA field set to one -- see
|
||
Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys
|
||
associated with other DNS operations MAY be stored in DNSKEY RRs that
|
||
are not marked as zone keys but MUST NOT be used to verify RRSIGs.
|
||
|
||
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
|
||
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
|
||
[I-D.ietf-dnsext-dnssec-records]).
|
||
|
||
DNSKEY RRs MUST NOT appear at delegation points.
|
||
|
||
2.2 Including RRSIG RRs in a Zone
|
||
|
||
For each authoritative RRset in a signed zone, there MUST be at least
|
||
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 class is equal to the RRset class;
|
||
|
||
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 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
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 6]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
RRset owner name, not counting the null root label and not
|
||
counting the leftmost label if it is a wildcard;
|
||
|
||
o The RRSIG Signer's Name field is equal to the name of the zone
|
||
containing the RRset; and
|
||
|
||
o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
|
||
zone key DNSKEY record at the zone apex.
|
||
|
||
The process for constructing the RRSIG RR for a given RRset is
|
||
described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
|
||
multiple RRSIG RRs associated with it.
|
||
|
||
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
|
||
process.
|
||
|
||
The NS RRset that appears at the zone apex name MUST be signed, but
|
||
the NS RRsets that appear at delegation points (that is, the NS
|
||
RRsets in the parent zone that delegate the name to the child zone's
|
||
name servers) MUST NOT be signed. Glue address RRsets associated with
|
||
delegations MUST NOT be signed.
|
||
|
||
There MUST be an RRSIG for each RRset using at least one DNSKEY of
|
||
each algorithm in the parent zone's DS RRset and each additional
|
||
algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset
|
||
itself MUST be signed by each algorithm appearing in the DS RRset.
|
||
|
||
2.3 Including NSEC RRs in a Zone
|
||
|
||
Each owner name in the zone which has authoritative data or a
|
||
delegation point NS RRset MUST have an NSEC resource record. The
|
||
process for constructing the NSEC RR for a given name is described in
|
||
[I-D.ietf-dnsext-dnssec-records].
|
||
|
||
The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
|
||
value field in the zone SOA RR.
|
||
|
||
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
|
||
RRset at any particular owner name. That is, the signing process
|
||
MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
|
||
not the owner name of any RRset before the zone was signed.
|
||
|
||
The type bitmap of every NSEC resource record in a signed zone MUST
|
||
indicate the presence of both the NSEC record itself and its
|
||
corresponding RRSIG record.
|
||
|
||
The difference between the set of owner names that require RRSIG
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 7]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
records and the set of owner names that require NSEC records is
|
||
subtle and worth highlighting. RRSIG records are present at the
|
||
owner names of all authoritative RRsets. NSEC records are present at
|
||
the owner names of all names for which the signed zone is
|
||
authoritative and also at the owner names of delegations from the
|
||
signed zone to its children. Neither NSEC nor RRSIG records are
|
||
present (in the parent zone) at the owner names of glue address
|
||
RRsets. Note, however, that this distinction is for the most part is
|
||
only visible during the zone signing process, because NSEC RRsets are
|
||
authoritative data, and are therefore signed, thus any owner name
|
||
which has an NSEC RRset will have RRSIG RRs as well in the signed
|
||
zone.
|
||
|
||
2.4 Including DS RRs in a Zone
|
||
|
||
The DS resource record establishes authentication chains between DNS
|
||
zones. A DS RRset SHOULD be present at a delegation point when the
|
||
child zone is signed. The DS RRset MAY contain multiple records,
|
||
each referencing a public key in the child zone used to verify the
|
||
RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
|
||
RRsets MUST NOT appear at a zone's apex.
|
||
|
||
A DS RR SHOULD point to a DNSKEY RR which is present in the child's
|
||
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
|
||
by the corresponding private key.
|
||
|
||
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
|
||
(i.e., the NS RRset from the same zone containing the DS RRset).
|
||
|
||
Construction of a DS RR requires knowledge of the corresponding
|
||
DNSKEY RR in the child zone, which implies communication between the
|
||
child and parent zones. This communication is an operational matter
|
||
not covered by this document.
|
||
|
||
2.5 Changes to the CNAME Resource Record.
|
||
|
||
If a CNAME RRset is present at a name in a signed zone, appropriate
|
||
RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
|
||
name for secure dynamic update purposes is also allowed. Other types
|
||
MUST NOT be present at that name.
|
||
|
||
This is a modification to the original CNAME definition given in
|
||
[RFC1034]. The original definition of the CNAME RR did not allow any
|
||
other types to coexist with a CNAME record, but a signed zone
|
||
requires NSEC and RRSIG RRs for every authoritative name. To resolve
|
||
this conflict, this specification modifies the definition of the
|
||
CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 8]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
2.6 Example of a Secure Zone
|
||
|
||
Appendix A shows a complete example of a small signed zone.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 9]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
3. Serving
|
||
|
||
This section describes the behavior of entities that include
|
||
security-aware name server functions. In many cases such functions
|
||
will be part of a security-aware recursive name server, but a
|
||
security-aware authoritative name server has some of the same
|
||
requirements as a security-aware recursive name server does.
|
||
Functions specific to security-aware recursive name servers are
|
||
described in Section 3.2; functions specific to authoritative servers
|
||
are described in Section 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 that receives a DNS query that does not
|
||
include the EDNS OPT pseudo-RR or that has the DO bit set to zero
|
||
MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other
|
||
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.8 for details
|
||
on the behavior of these bits.
|
||
|
||
3.1 Authoritative Name Servers
|
||
|
||
Upon receiving a relevant query that has the EDNS [RFC2671] OPT
|
||
pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative
|
||
name server for a signed zone MUST include additional RRSIG, NSEC,
|
||
and DS RRs according to the following rules:
|
||
|
||
o RRSIG RRs that can be used to authenticate a response MUST be
|
||
included in the response according to the rules in Section 3.1.1;
|
||
|
||
o NSEC RRs that can be used to provide authenticated denial of
|
||
existence MUST be included in the response automatically according
|
||
to the rules in Section 3.1.3;
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 10]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
|
||
be included in referrals automatically according to the rules in
|
||
Section 3.1.4.
|
||
|
||
DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
|
||
discusses zone transfer requirements.
|
||
|
||
3.1.1 Including RRSIG RRs in a Response
|
||
|
||
When responding to a query that has the DO bit set to one, a
|
||
security-aware authoritative name server SHOULD attempt to send RRSIG
|
||
RRs that a security-aware resolver can use to authenticate the RRsets
|
||
in the response. Inclusion of RRSIG RRs in a response is subject to
|
||
the following rules:
|
||
|
||
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
|
||
RRs have a higher priority for inclusion than any other 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.
|
||
|
||
o When placing a signed RRset in the Authority section, the name
|
||
server MUST also place its RRSIG RRs in the Authority section.
|
||
The RRSIG RRs have a higher priority for inclusion than any other
|
||
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.
|
||
|
||
o When placing a signed RRset in the Additional section, the name
|
||
server MUST also place its RRSIG RRs in the Additional section.
|
||
If space does not permit inclusion of both the RRset and its
|
||
associated RRSIG RRs, the name server MUST NOT set the TC bit
|
||
solely because these RRSIG RRs didn't fit.
|
||
|
||
|
||
3.1.2 Including DNSKEY RRs In a Response
|
||
|
||
When responding to a query that has the DO bit set to one and that
|
||
requests the SOA or NS RRs at the apex of a signed zone, a
|
||
security-aware authoritative name server for that zone MAY return the
|
||
zone apex DNSKEY RRset in the Additional section. In this situation,
|
||
the DNSKEY RRset and associated RRSIG RRs have lower priority than
|
||
any other information that would be placed in the additional section.
|
||
The name server SHOULD NOT include the DNSKEY RRset unless there is
|
||
enough space in the response message for both the DNSKEY RRset and
|
||
its associated RRSIG RR(s). If there is not enough space to include
|
||
these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
|
||
NOT set the TC bit solely because these RRs didn't fit (see Section
|
||
3.1.1).
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 11]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
3.1.3 Including NSEC RRs In a Response
|
||
|
||
When responding to a query that has the DO bit set to one, a
|
||
security-aware authoritative name server for a signed zone MUST
|
||
include NSEC RRs in each of the following cases:
|
||
|
||
No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
|
||
but does not contain any RRsets that exactly match <SNAME, SCLASS,
|
||
STYPE>.
|
||
|
||
Name Error: The zone does not contain any RRsets that match <SNAME,
|
||
SCLASS> either exactly or via wildcard name expansion.
|
||
|
||
Wildcard Answer: The zone does not contain any RRsets that exactly
|
||
match <SNAME, SCLASS> but does contain an RRset that matches
|
||
<SNAME, SCLASS, STYPE> via wildcard name expansion.
|
||
|
||
Wildcard No Data: The zone does not contain any RRsets that exactly
|
||
match <SNAME, SCLASS>, does contain one or more RRsets that match
|
||
<SNAME, SCLASS> via wildcard name expansion, but does not contain
|
||
any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
|
||
expansion.
|
||
|
||
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 that the name server is
|
||
returning is correct given the data that are in the zone.
|
||
|
||
3.1.3.1 Including NSEC RRs: No Data Response
|
||
|
||
If the zone contains RRsets matching <SNAME, SCLASS> but contains no
|
||
RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
|
||
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).
|
||
|
||
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.
|
||
|
||
3.1.3.2 Including NSEC RRs: Name Error Response
|
||
|
||
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:
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 12]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
o An NSEC RR proving that there is no exact match for <SNAME,
|
||
SCLASS>; and
|
||
|
||
o An NSEC RR proving that the zone contains no RRsets that would
|
||
match <SNAME, SCLASS> via wildcard name expansion.
|
||
|
||
In some cases a single NSEC RR may prove both of these points, in
|
||
that case the name server SHOULD only include the NSEC RR and its
|
||
RRSIG RR(s) once in the Authority section.
|
||
|
||
If space does not permit inclusion of these NSEC and RRSIG RRs, the
|
||
name server MUST set the TC bit (see Section 3.1.1).
|
||
|
||
The owner names of these NSEC and RRSIG RRs are not subject to
|
||
wildcard name expansion when these RRs are included in the Authority
|
||
section of the response.
|
||
|
||
Note that this form of response includes cases in which SNAME
|
||
corresponds to an empty non-terminal name within the zone (a name
|
||
which is not the owner name for any RRset but which is the parent
|
||
name of one or more RRsets).
|
||
|
||
3.1.3.3 Including NSEC RRs: Wildcard Answer Response
|
||
|
||
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 the answer, NSEC and RRSIG RRs, the name
|
||
server MUST set the TC bit (see Section 3.1.1).
|
||
|
||
3.1.3.4 Including NSEC RRs: Wildcard No Data Response
|
||
|
||
This case is a combination of the previous cases. The zone does not
|
||
contain an exact match for <SNAME, SCLASS>, and while the zone does
|
||
contain RRsets which match <SNAME, SCLASS> via wildcard 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 proving that there are no RRsets matching STYPE at the
|
||
wildcard owner name which matched <SNAME, SCLASS> via wildcard
|
||
expansion; and
|
||
|
||
o An NSEC RR proving that there are no RRsets in the zone which
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 13]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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.
|
||
|
||
The owner names of these NSEC and RRSIG RRs are not subject to
|
||
wildcard name expansion when these RRs are included in the Authority
|
||
section of the response.
|
||
|
||
If space does not permit inclusion of these NSEC and RRSIG RRs, the
|
||
name server MUST set the TC bit (see Section 3.1.1).
|
||
|
||
3.1.3.5 Finding The Right NSEC RRs
|
||
|
||
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.
|
||
|
||
To find the NSEC which proves that name N does not exist in the zone
|
||
Z which would have held it, construct sequence S consisting of every
|
||
name in Z, sorted into canonical order
|
||
[I-D.ietf-dnsext-dnssec-records]. Find the name M which would have
|
||
immediately preceded N in S if N had existed. M is the owner name of
|
||
the NSEC RR which proves that N does not exist.
|
||
|
||
The algorithm for finding the NSEC RR which proves that a given name
|
||
is not covered by any applicable wildcard is similar, but requires an
|
||
extra step. More precisely, the algorithm for finding the NSEC
|
||
proving that the applicable wildcard name does not exist is precisely
|
||
the same as the algorithm for finding the NSEC RR which proves that
|
||
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].
|
||
|
||
3.1.4 Including DS RRs In a Response
|
||
|
||
When responding to a query which has the DO bit set to one, a
|
||
security-aware authoritative name server returning a referral
|
||
includes DNSSEC data along with the NS RRset.
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 14]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
If a DS RRset is present at the delegation point, the name server
|
||
MUST return both the DS RRset and its associated RRSIG RR(s) in the
|
||
Authority section along with the NS RRset. The name server MUST
|
||
place the NS RRset before the DS RRset and its associated RRSIG
|
||
RR(s).
|
||
|
||
If no DS RRset is present at the delegation point, the name server
|
||
MUST return both the NSEC RR which proves that the DS RRset is not
|
||
present and the NSEC RR's associated RRSIG RR(s) along with the NS
|
||
RRset. The name server MUST place the NS RRset before the NSEC RRset
|
||
and its associated RRSIG RR(s).
|
||
|
||
Including these DS, NSEC, and RRSIG RRs increases the size of
|
||
referral messages, and may cause some or all glue RRs to be omitted.
|
||
If space does not permit inclusion of the DS or NSEC RRset and
|
||
associated RRSIG RRs, the name server MUST set the TC bit (see
|
||
Section 3.1.1).
|
||
|
||
3.1.4.1 Responding to Queries for DS RRs
|
||
|
||
The DS resource record type is unusual in that it appears only on the
|
||
parent zone's side of a zone cut. For example, the DS RRset for the
|
||
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.
|
||
|
||
A security-aware resolver sends queries to the parent zone when
|
||
looking for a needed DS RR at a delegation point (see Section 4.2).
|
||
However, special rules are necessary to avoid confusing
|
||
security-oblivious resolvers which might become involved in
|
||
processing such a query (for example, in a network configuration that
|
||
forces a security-aware resolver to channel its queries through a
|
||
security-oblivious recursive name server). The rest of this section
|
||
describes how a security-aware name server processes DS queries in
|
||
order to avoid this problem.
|
||
|
||
The need for special processing by a security-aware name server only
|
||
arises when all the following conditions are met:
|
||
|
||
o the name server has received a query for the DS RRset at a zone
|
||
cut; and
|
||
|
||
o the name server is authoritative for the child zone; and
|
||
|
||
o the name server is not authoritative for the parent zone; and
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 15]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
o the name server does not offer recursion.
|
||
|
||
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
|
||
will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
|
||
records have no special meaning with respect to a zone transfer
|
||
operation, and these RRs are treated as any other resource record
|
||
type.
|
||
|
||
An authoritative name server is not required to verify that a zone is
|
||
properly signed before sending or accepting a zone transfer.
|
||
However, an authoritative name server MAY choose to reject the entire
|
||
zone transfer if the zone fails meets any of the signing requirements
|
||
described in Section 2. The primary objective of a zone transfer is
|
||
to ensure that all authoritative name servers have identical copies
|
||
of the zone. An authoritative name server which chooses to perform
|
||
its own zone validation MUST NOT selectively reject some RRs and
|
||
accept others.
|
||
|
||
DS RRsets appear only on the parental side of a zone cut and are
|
||
authoritative data in the parent zone. As with any other
|
||
authoritative RRset, the DS RRset MUST be included in zone transfers
|
||
of the zone in which the RRset is authoritative data: in the case of
|
||
the DS RRset, this is the parent zone.
|
||
|
||
NSEC RRs appear in both the parent and child zones at a zone cut, and
|
||
are authoritative data in both the parent and child zones. The
|
||
parental and child NSEC RRs at a zone cut are never identical to each
|
||
other, since the NSEC RR in the child zone's apex will always
|
||
indicate the presence of the child zone's SOA RR while the parental
|
||
NSEC RR at the zone cut will never indicate the presence of an SOA
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 16]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
MUST be included in zone transfers of the child zone.
|
||
|
||
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.
|
||
|
||
3.1.6 The AD and CD Bits in an Authoritative Response
|
||
|
||
The CD and AD bits are designed to be used in communication between
|
||
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.
|
||
|
||
Since a security-aware name server does not perform signature
|
||
validation for authoritative data during query processing even when
|
||
the CD bit is set to zero, a security-aware name server SHOULD ignore
|
||
the setting of the CD bit when composing an authoritative response.
|
||
|
||
A security-aware name server MUST NOT set the AD bit in a response
|
||
unless the name server considers all RRsets in the Answer and
|
||
Authority sections of the response to be authentic. A security-aware
|
||
name server's local policy MAY consider data from an authoritative
|
||
zone to be authentic without further validation, but the name server
|
||
MUST NOT do so unless the name server 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.
|
||
|
||
A security-aware name server which supports recursion MUST follow the
|
||
rules for the CD and AD bits given in Section 3.2 when generating a
|
||
response that involves data obtained via recursion.
|
||
|
||
3.2 Recursive Name Servers
|
||
|
||
As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
|
||
recursive name server is an entity which acts in both the
|
||
security-aware name server and security-aware resolver roles. This
|
||
section uses the terms "name server side" and "resolver side" to
|
||
refer to the code within a security-aware recursive name server which
|
||
implements the security-aware name server role and the code which
|
||
implements the security-aware resolver role, respectively.
|
||
|
||
The resolver side follows the usual rules for caching and negative
|
||
caching which would apply to any security-aware resolver.
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 17]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
3.2.1 The DO bit
|
||
|
||
The resolver side of a security-aware recursive name server MUST set
|
||
the DO bit when sending requests, regardless of the state of the DO
|
||
bit in the initiating request received by the name server side. If
|
||
the DO bit in an initiating query is not set, the name server side
|
||
MUST strip any authenticating DNSSEC RRs from the response, but MUST
|
||
NOT strip any DNSSEC RRs that the initiating query explicitly
|
||
requested.
|
||
|
||
3.2.2 The CD bit
|
||
|
||
The CD bit exists in order to allow a security-aware resolver to
|
||
disable signature validation in a security-aware name server's
|
||
processing of a particular query.
|
||
|
||
The name server side MUST copy the setting of the CD bit from a query
|
||
to the corresponding response.
|
||
|
||
The name server side of a security-aware recursive name server MUST
|
||
pass the sense of the CD bit to the resolver side along with the rest
|
||
of an initiating query, so that the resolver side will know whether
|
||
or not it is required to verify the response data it returns to the
|
||
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.
|
||
|
||
If the resolver side implements a BAD cache (see Section 4.7) and the
|
||
name server side receives a query which matches an entry in the
|
||
resolver side's BAD cache, the name server side's response depends on
|
||
the sense of the CD bit in the original query. If the CD bit is set,
|
||
the name server side SHOULD return the data from the BAD cache; if
|
||
the CD bit is not set, the name server side MUST return RCODE 2
|
||
(server failure).
|
||
|
||
3.2.3 The AD bit
|
||
|
||
The name server side of a security-aware recursive name server MUST
|
||
NOT set the AD bit in a response unless the name server considers all
|
||
RRsets in the Answer and Authority sections of the response to be
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 18]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
authentic, and SHOULD set the AD bit if and only if the resolver side
|
||
considers all RRsets in the Answer section and any relevant negative
|
||
response RRs in the Authority section to be authentic. The resolver
|
||
side MUST follow the procedure described in Section 5 to determine
|
||
whether the RRs in question are authentic.
|
||
|
||
3.3 Example DNSSEC Responses
|
||
|
||
See Appendix B for example response packets.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 19]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
4. Resolving
|
||
|
||
This section describes the behavior of entities which include
|
||
security-aware resolver functions. In many cases such functions will
|
||
be part of a security-aware recursive name server, but a stand-alone
|
||
security-aware resolver has many of the same requirements. Functions
|
||
specific to security-aware recursive name servers are described in
|
||
Section 3.2.
|
||
|
||
4.1 EDNS Support
|
||
|
||
A security-aware resolver MUST include an EDNS [RFC2671] OPT
|
||
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
|
||
1220 octets, SHOULD support a message size of 4000 octets, and MUST
|
||
advertise the supported message size using the "sender's UDP payload
|
||
size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST
|
||
handle fragmented UDP packets correctly regardless of whether any
|
||
such fragmented packets were received via IPv4 or IPv6. Please see
|
||
[RFC3226] for discussion of these requirements.
|
||
|
||
4.2 Signature Verification Support
|
||
|
||
A security-aware resolver MUST support the signature verification
|
||
mechanisms described in Section 5, and MUST apply them to every
|
||
received response except when:
|
||
|
||
o The security-aware resolver is part of a security-aware recursive
|
||
name server, and the response is the result of recursion on behalf
|
||
of a query received with the CD bit set;
|
||
|
||
o The response is the result of a query generated directly via some
|
||
form of application interface which instructed the security-aware
|
||
resolver not to perform validation for this query; or
|
||
|
||
o Validation for this query has been disabled by local policy.
|
||
|
||
A security-aware resolver's support for signature verification MUST
|
||
include support for verification of wildcard owner names.
|
||
|
||
Editors' note: The rest of this section is expected to change once
|
||
the WG reaches closure on Q-23.
|
||
|
||
A security-aware resolver MUST attempt to retrieve missing DS,
|
||
DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these
|
||
RRs in order to perform signature verification.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 20]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
A security-aware resolver MUST attempt to retrieve a missing NSEC RR
|
||
which the resolver needs to authenticate a NODATA response. In
|
||
general it is not possible for a resolver to retrieve missing NSEC
|
||
RRs, since the resolver will have no way of knowing the owner name of
|
||
the missing NSEC RR, but in the specific case of a NODATA response,
|
||
the resolver may know the name of the missing NSEC RR, and in such
|
||
cases must therefore attempt to retrieve it.
|
||
|
||
When attempting to retrieve missing NSEC RRs which reside on the
|
||
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.
|
||
|
||
When attempting to retrieve a missing DS, a security-aware
|
||
iterative-mode resolver MUST query the name servers for the parent
|
||
zone, not the child zone. As explained in Section 3.1.4.1,
|
||
security-aware name servers need to apply special processing rules to
|
||
handle the DS RR, and in some situations the resolver may also need
|
||
to apply special rules to locate the name servers for the parent zone
|
||
if the resolver does not already have the parent's NS RRset. To
|
||
locate the parent NS RRset, the resolver can start with the
|
||
delegation name, strip off the leftmost label, and query for an NS
|
||
RRset by that name; if no NS RRset is present at that name, the
|
||
resolver then strips of the leftmost remaining label and retries the
|
||
query for that name, repeating this process of walking up the tree
|
||
until it either finds the NS RRset or runs out of labels.
|
||
|
||
Editors' note: This algorithm could easily be read as an
|
||
invitation to careless implementors to hammer the root zone
|
||
servers. Better wording would be welcome.
|
||
|
||
|
||
4.3 Determining Security Status of Data
|
||
|
||
Editors' note: This section is waiting for resolution of Q-28.
|
||
|
||
A security-aware resolver MUST be able to determine whether or not it
|
||
should expect a particular RRset to be signed. More precisely, a
|
||
security-aware resolver must be able to distinguish between three
|
||
cases:
|
||
|
||
1. An RRset for which the resolver is able to build a chain of
|
||
signed DNSKEY and DS RRs from a trusted security anchor to the
|
||
RRset. In this case, the RRset should be signed, and is subject
|
||
to signature validation as described above.
|
||
|
||
2. An RRset for which the resolver knows that it has no chain of
|
||
signed DNSKEY and DS RRs from any trusted starting point to the
|
||
RRset. This can occur when the target RRset lies in an unsigned
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 21]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
zone or in a descendent of an unsigned zone. In this case, the
|
||
RRset may or may not be signed, but the resolver will not be able
|
||
to verify the signature.
|
||
|
||
3. An RRset for which the resolver is not able to determine whether
|
||
or not the RRset should be signed, because the resolver is not
|
||
able to obtain the necessary DNSSEC RRs. This can occur when the
|
||
security-aware resolver is not able to contact security-aware
|
||
name servers for the relevant zones.
|
||
|
||
|
||
4.4 Preconfigured Public Keys
|
||
|
||
A security-aware resolver MUST be capable of being preconfigured with
|
||
at least one trusted public key or DS RR, and SHOULD be capable of
|
||
being preconfigured with multiple trusted public keys or DS RRs.
|
||
Since a security-aware resolver will not be able to validate
|
||
signatures without such a preconfigured trusted key, the resolver
|
||
SHOULD have some reasonably robust mechanism for obtaining such keys
|
||
when it boots; examples of such a mechanism would be some form of
|
||
non-volatile storage (such as a disk drive) or some form of trusted
|
||
local network configuration mechanism.
|
||
|
||
4.5 Response Caching
|
||
|
||
Editors' note: RIPE "last call" workshop felt that the WG needs to
|
||
reexamine and discuss this section.
|
||
|
||
A security-aware resolver SHOULD cache each response as a single
|
||
atomic entry containing the entire answer, including the named RRset
|
||
and any associated DNSSEC RRs. The resolver SHOULD discard the
|
||
entire atomic entry when any of the RRs contained in it expire. In
|
||
most cases the appropriate cache index for the atomic entry will be
|
||
the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
|
||
form described in Section 3.1.3.2 the appropriate cache index will be
|
||
the double <QNAME,QCLASS>.
|
||
|
||
4.6 Handling of the CD and AD bits
|
||
|
||
A security-aware resolver MAY set the CD bit in a query to one in
|
||
order to indicate that the resolver takes responsibility for
|
||
performing whatever authentication its local policy requires on the
|
||
RRsets in the response. See Section 3.2 for the effect this bit has
|
||
on the behavior of security-aware recursive name servers.
|
||
|
||
A security-aware resolver MUST zero the AD bit when composing query
|
||
messages to protect against buggy name servers which blindly copy
|
||
header bits which they do not understand from the query message to
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 22]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
the response message.
|
||
|
||
A resolver MUST disregard the meaning of the CD and AD bits in a
|
||
response unless the response was obtained using a secure channel or
|
||
the resolver was specifically configured to regard the message header
|
||
bits without using a secure channel.
|
||
|
||
4.7 Rate Limiting
|
||
|
||
A security-aware resolver SHOULD NOT cache data with invalid
|
||
signatures under normal circumstances. However, a security-aware
|
||
resolver SHOULD take steps to rate limit the number of identical
|
||
queries that it generates if signature validation of the responses
|
||
fails repeatedly.
|
||
|
||
Conceptually, this is similar in some respects to negative caching
|
||
[RFC2308], but since the resolver has no way of obtaining an
|
||
appropriate caching TTL from received data in this case, the TTL will
|
||
have to be set by the implementation. This document refers to the
|
||
data retained as part of such a rate limiting mechanism as the "BAD
|
||
cache".
|
||
|
||
A security-aware resolver MAY chose to retain RRsets for which
|
||
signature validation has failed in its BAD cache, but MUST NOT return
|
||
such RRsets from its BAD cache unless both of the following
|
||
conditions are met:
|
||
|
||
o The resolver has recently generated enough queries identical to
|
||
this one that the resolver is suppressing queries for this <QNAME,
|
||
QTYPE, QCLASS>; and
|
||
|
||
o The resolver is not required to validate the signatures of the
|
||
RRsets in question under the rules given in Section 4 of this
|
||
document.
|
||
|
||
The intent of the above rule is to provide the raw data to clients
|
||
which are capable of performing their own signature verification
|
||
checks while protecting clients which depend on this resolver to
|
||
perform such checks. Several of the possible reasons why signature
|
||
validation might fail involve conditions which may not apply equally
|
||
to this resolver and the client which invoked it: for example, this
|
||
resolver's clock may be set incorrectly, or the client may have
|
||
knowledge of a relevant island of security which this resolver does
|
||
not share. In such cases, "protecting" a client which is capable of
|
||
performing its own signature validation from ever seeing the "bad"
|
||
data does not help the client.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 23]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
4.8 Stub resolvers
|
||
|
||
A security-aware stub resolver MUST support the DNSSEC RR types, at
|
||
least to the extent of not mishandling responses just because they
|
||
contain DNSSEC RRs.
|
||
|
||
4.8.1 Handling of the DO Bit
|
||
|
||
A non-validating security-aware stub resolver MAY include the DNSSEC
|
||
RRs returned by a security-aware recursive name server as part of the
|
||
data that the stub resolver hands back to the application which
|
||
invoked it but is not required to do so. A non-validating stub
|
||
resolver that wishes to do this will need to set the DO bit in
|
||
receive DNSSEC RRs from the recursive name server.
|
||
|
||
A validating security-aware stub resolver MUST set the DO bit, since
|
||
otherwise it will not receive the DNSSEC RRs it needs to perform
|
||
signature validation.
|
||
|
||
4.8.2 Handling of the CD Bit
|
||
|
||
A non-validating security-aware stub resolver SHOULD NOT set the CD
|
||
bit when sending queries unless requested by the application layer,
|
||
since by definition, a non-validating stub resolver depends on the
|
||
security-aware recursive name server to perform validation on its
|
||
behalf.
|
||
|
||
A validating security-aware stub resolver SHOULD set the CD bit,
|
||
since otherwise the security-aware recursive name server will answer
|
||
the query using the name server's local policy, which may prevent the
|
||
stub resolver from receiving data which would be acceptable to the
|
||
stub resolver's local policy.
|
||
|
||
4.8.3 Handling of the AD Bit
|
||
|
||
A non-validating security-aware stub resolver MAY chose to examine
|
||
the setting of the AD bit in response messages that it receives in
|
||
order to determine whether the security-aware recursive name server
|
||
which sent the response claims to have cryptographically verified the
|
||
data in the Answer and Authority sections of the response message.
|
||
Note, however, that the responses received by a security-aware stub
|
||
resolver are heavily dependent on the local policy of the
|
||
security-aware recursive name server, so as a practical matter there
|
||
may be little practical value to checking the status of the AD bit
|
||
except perhaps as a debugging aid. In any case, a security-aware
|
||
stub resolver MUST NOT place any reliance on signature validation
|
||
allegedly performed on its behalf except when the security-aware stub
|
||
resolver obtained the data in question from a trusted security-aware
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 24]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
recursive name server via a secure channel.
|
||
|
||
A validating security-aware stub resolver SHOULD NOT examine the
|
||
setting of the AD bit in response messages, since, by definition, the
|
||
stub resolver performs its own signature validation regardless of the
|
||
setting of the AD bit.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 25]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
5. Authenticating DNS Responses
|
||
|
||
In order to use DNSSEC RRs for authentication, a security-aware
|
||
resolver requires preconfigured knowledge of at least one
|
||
authenticated DNSKEY or DS RR. The process for obtaining and
|
||
authenticating this initial DNSKEY or DS RR is achieved via some
|
||
external mechanism. For example, a resolver could use some off-line
|
||
authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR
|
||
that identifies and authenticates a zone's DNSKEY RR. The remainder
|
||
of this section assumes that the resolver has somehow obtained an
|
||
initial set of authenticated DNSKEY RRs.
|
||
|
||
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
|
||
RRset. To authenticate an apex DNSKEY RRset using an initial key,
|
||
the resolver MUST:
|
||
|
||
1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
|
||
RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
|
||
(DNSKEY RDATA bit 7) set to one.
|
||
|
||
2. Verify that there is some RRSIG RR that covers the apex DNSKEY
|
||
RRset, and that the combination of the RRSIG RR and the initial
|
||
DNSKEY RR authenticates the DNSKEY RRset. The process for using
|
||
an RRSIG RR to authenticate an RRset is described in Section 5.3.
|
||
|
||
Once the resolver has authenticated the apex DNSKEY RRset using an
|
||
initial DNSKEY RR, delegations from that zone can be authenticated
|
||
using DS RRs. This allows a resolver to start from an initial key,
|
||
and use DS RRsets to proceed recursively down the DNS tree obtaining
|
||
other apex DNSKEY RRsets. If the resolver were preconfigured with a
|
||
root DNSKEY RR, and if every delegation had a DS RR associated with
|
||
it, then the resolver could obtain and validate any apex DNSKEY
|
||
RRset. The process of using DS RRs to authenticate referrals is
|
||
described in Section 5.2.
|
||
|
||
Once the resolver has authenticated a zone's apex DNSKEY RRset,
|
||
Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
|
||
DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
|
||
RRsets in the zone. Section 5.4 shows how the resolver can use
|
||
authenticated NSEC RRsets from the zone to prove that an RRset is not
|
||
present in the zone.
|
||
|
||
When a resolver indicates support for DNSSEC (by setting the DO bit),
|
||
a security-aware name server should attempt to provide the necessary
|
||
DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
|
||
However, a security-aware resolver may still receive a response that
|
||
that lacks the appropriate DNSSEC RRs, whether due to configuration
|
||
issues such as a security-oblivious recursive name server that
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 26]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
accidentally interfere with DNSSEC RRs or due to a deliberate attack
|
||
in which an adversary forges a response, strips DNSSEC RRs from a
|
||
response, or modifies a query so that DNSSEC RRs appear not to be
|
||
requested. The absence of DNSSEC data in a response MUST NOT by
|
||
itself be taken as an indication that no authentication information
|
||
exists.
|
||
|
||
A resolver SHOULD expect authentication information from signed
|
||
zones. A resolver SHOULD believe that a zone is signed if 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
|
||
parent contains a DS RRset.
|
||
|
||
5.1 Special Considerations for Islands of Security
|
||
|
||
Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
|
||
zones for which it is not possible to construct an authentication
|
||
chain to the zone from its parent. Validating signatures within an
|
||
island of security requires the validator to have some other means of
|
||
obtaining an initial authenticated zone key for the island. If a
|
||
validator cannot obtain such a key, it will have to choose whether to
|
||
accept the unvalidated responses or not based on local policy.
|
||
|
||
All the normal processes for validating responses apply to islands of
|
||
security. The only difference between normal validation and
|
||
validation within an island of security is in how the validator
|
||
obtains a starting point for the authentication chain.
|
||
|
||
5.2 Authenticating Referrals
|
||
|
||
Once the apex DNSKEY RRset for a signed parent zone has been
|
||
authenticated, DS RRsets can be used to authenticate the delegation
|
||
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
|
||
child zone's DNSKEY RR. A strong cryptographic digest algorithm
|
||
ensures that an adversary can not easily generate a DNSKEY RR that
|
||
matches the digest. Thus, authenticating the digest allows a
|
||
resolver to authenticate the matching DNSKEY RR. The resolver can
|
||
then use this child DNSKEY RR to authenticate the entire child apex
|
||
DNSKEY RRset.
|
||
|
||
Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
|
||
can be authenticated if all of the following hold:
|
||
|
||
o The DS RR has been authenticated using some DNSKEY RR in the
|
||
parent's apex DNSKEY RRset (see Section 5.3);
|
||
|
||
o The Algorithm and Key Tag in the DS RR match the Algorithm field
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 27]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
|
||
RRset that, when hashed using the digest algorithm specified in
|
||
the DS RR's Digest Type field, results in a digest value that
|
||
matches the Digest field of the DS RR; and
|
||
|
||
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
|
||
apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
|
||
child zone's apex DNSKEY RRset.
|
||
|
||
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
|
||
RRset exists for the delegated name (see Section 3.1.4). A
|
||
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
|
||
a NSEC RRset proving that the DS RRset does not exist (see Section
|
||
4).
|
||
|
||
If the resolver authenticates an NSEC RRset that proves that no DS
|
||
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
|
||
DNSKEY or DS RR that belongs to the child zone or to any delegation
|
||
below the child zone, this initial DNSKEY or DS RR MAY be used to
|
||
re-establish an authentication path. If no such initial DNSKEY or DS
|
||
RR exists, the resolver can not authenticate RRsets in or below the
|
||
child zone.
|
||
|
||
Note that, for a signed delegation, there are two NSEC RRs associated
|
||
with the delegated name. One NSEC RR resides in the parent zone, and
|
||
can be used to prove whether a DS RRset exists for the delegated
|
||
name. The second NSEC RR resides in the child zone, and identifies
|
||
which RRsets are present at the apex of the child zone. The parent
|
||
NSEC RR and child NSEC RR can always be distinguished, since the SOA
|
||
bit will be set in the child NSEC RR and clear in the parent NSEC RR.
|
||
A security-aware resolver MUST use the parent NSEC RR when attempting
|
||
to prove that a DS RRset does not exist.
|
||
|
||
If the resolver does not support any of the algorithms listed in an
|
||
authenticated DS RRset, then the resolver will not be able to verify
|
||
the authentication path to the child zone. In this case, the
|
||
resolver SHOULD treat the child zone as if it were unsigned.
|
||
|
||
5.3 Authenticating an RRset Using an RRSIG RR
|
||
|
||
A resolver can use an RRSIG RR and its corresponding DNSKEY RR to
|
||
attempt to authenticate RRsets. The resolver first checks the RRSIG
|
||
RR to verify that it covers the RRset, has a valid time interval, and
|
||
identifies a valid DNSKEY RR. The resolver then constructs the
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 28]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
canonical form of the signed data by appending the RRSIG RDATA
|
||
(excluding the Signature Field) with the canonical form of the
|
||
covered RRset. Finally, resolver uses the public key and signature
|
||
to authenticate the signed data. Section 5.3.1, Section 5.3.2, and
|
||
Section 5.3.3 describe each step in detail.
|
||
|
||
5.3.1 Checking the RRSIG RR Validity
|
||
|
||
A security-aware resolver can use an RRSIG RR to authenticate an
|
||
RRset if all of the following conditions hold:
|
||
|
||
o The RRSIG RR and the RRset MUST have the same owner name and the
|
||
same class;
|
||
|
||
o The RRSIG RR's Signer's Name field MUST be the name of the zone
|
||
that contains the RRset;
|
||
|
||
o The RRSIG RR's Type Covered field MUST equal the RRset's type;
|
||
|
||
o The number of labels in the RRset owner name MUST be greater than
|
||
or equal to the value in the RRSIG RR's Labels field;
|
||
|
||
o The resolver's notion of the current time MUST be less than or
|
||
equal to the time listed in the RRSIG RR's Expiration field;
|
||
|
||
o The resolver's notion of the current time MUST be greater than or
|
||
equal to the time listed in the RRSIG RR's Inception field;
|
||
|
||
o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
|
||
match the owner name, algorithm, and key tag for some DNSKEY RR in
|
||
the zone's apex DNSKEY RRset;
|
||
|
||
o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
|
||
RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
|
||
set to one.
|
||
|
||
It is possible for more than one DNSKEY RR to match the conditions
|
||
above. In this case, the resolver can not predetermine which DNSKEY
|
||
RR to use to authenticate the signature, MUST try each matching
|
||
DNSKEY RR until the resolver has either validated the signature or
|
||
has run out of matching public keys to try.
|
||
|
||
Note that this authentication process is only meaningful if the
|
||
resolver authenticates the DNSKEY RR before using it to validate
|
||
signatures. The matching DNSKEY RR is considered to be authentic if:
|
||
|
||
o The apex DNSKEY RRset containing the DNSKEY RR is considered
|
||
authentic; or
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 29]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
|
||
and the DNSKEY RR either matches an authenticated DS RR from the
|
||
parent zone or matches a DS RR or DNSKEY RR that the resolver has
|
||
been preconfigured to believe to be authentic.
|
||
|
||
|
||
5.3.2 Reconstructing the Signed Data
|
||
|
||
Once the RRSIG RR has met the validity requirements described in
|
||
Section 5.3.1, the resolver needs to reconstruct the original signed
|
||
data. The original signed data includes RRSIG RDATA (excluding the
|
||
Signature field) and the canonical form of the RRset. Aside from
|
||
being ordered, the canonical form of the RRset might also differ from
|
||
the received RRset due to DNS name compression, decremented TTLs, or
|
||
wildcard expansion. The resolver should use the following to
|
||
reconstruct the original signed data:
|
||
|
||
signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
|
||
|
||
"|" denotes concatenation
|
||
|
||
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
|
||
with the Signature field excluded and the Signer's Name
|
||
in canonical form.
|
||
|
||
RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
|
||
|
||
name is calculated according to the function below
|
||
|
||
class is the RRset's class
|
||
|
||
type is the RRset type and all RRs in the class
|
||
|
||
OrigTTL is the value from the RRSIG Original TTL field
|
||
|
||
All names in the RDATA field are in canonical form
|
||
|
||
The set of all RR(i) is sorted into canonical order.
|
||
|
||
To calculate the name:
|
||
let rrsig_labels = the value of the RRSIG Labels field
|
||
|
||
let fqdn = RRset's fully qualified domain name in
|
||
canonical form
|
||
|
||
let fqdn_labels = Label count of the fqdn above.
|
||
|
||
if rrsig_labels = fqdn_labels,
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 30]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
name = fqdn
|
||
|
||
if rrsig_labels < fqdn_labels,
|
||
name = "*." | the rightmost rrsig_label labels of the
|
||
fqdn
|
||
|
||
if rrsig_labels > fqdn_labels
|
||
the RRSIG RR did not pass the necessary validation
|
||
checks and MUST NOT be used to authenticate this
|
||
RRset.
|
||
|
||
The canonical forms for names and RRsets are defined in
|
||
[I-D.ietf-dnsext-dnssec-records].
|
||
|
||
NSEC RRsets at a delegation boundary require special processing.
|
||
There are two distinct NSEC RRsets associated with a signed delegated
|
||
name. One NSEC RRset resides in the parent zone, and specifies which
|
||
RRset are present at the parent zone. The second NSEC RRset resides
|
||
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
|
||
can always be distinguished since only the child NSEC RRs will
|
||
specify an SOA RRset exists at the name. When reconstructing the
|
||
original NSEC RRset for the delegation from the parent zone, the NSEC
|
||
RRs MUST NOT be combined with NSEC RRs from the child zone, and when
|
||
reconstructing the original NSEC RRset for the apex of the child
|
||
zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
|
||
zone.
|
||
|
||
Note also that each of the two NSEC RRsets at a delegation point has
|
||
a corresponding RRSIG RR with an owner name matching the delegated
|
||
name, and each of these RRSIG RRs is authoritative data associated
|
||
with the same zone that contains the corresponding NSEC RRset. If
|
||
necessary, a resolver can tell these RRSIG RRs apart by checking the
|
||
Signer's Name field.
|
||
|
||
5.3.3 Checking the Signature
|
||
|
||
Once the resolver has validated the RRSIG RR as described in Section
|
||
5.3.1 and reconstructed the original signed data as described in
|
||
Section 5.3.2, the resolver can attempt to use the cryptographic
|
||
signature to authenticate the signed data, and thus (finally!)
|
||
authenticate the RRset.
|
||
|
||
The Algorithm field in the RRSIG RR identifies the cryptographic
|
||
algorithm used to generate the signature. The signature itself is
|
||
contained in the Signature field of the RRSIG RDATA, and the public
|
||
key used to verify the signature is contained in the Public Key field
|
||
of the matching DNSKEY RR(s) (found in Section 5.3.1).
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 31]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
[I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types,
|
||
and provides pointers to the documents that define each algorithm's
|
||
use.
|
||
|
||
Note that it is possible for more than one DNSKEY RR to match the
|
||
conditions in Section 5.3.1. In this case, the resolver can only
|
||
determine which DNSKEY RR by trying each matching public key until
|
||
the resolver either succeeds in validating the signature or runs out
|
||
of keys to try.
|
||
|
||
If the Labels field of the RRSIG RR is not equal to the number of
|
||
labels in the RRset's fully qualified owner name, then the RRset is
|
||
either invalid or the result of wildcard expansion. The resolver
|
||
MUST verify that wildcard expansion was applied properly before
|
||
considering the RRset to be authentic. Section 5.3.4 describes how
|
||
to determine whether a wildcard was applied properly.
|
||
|
||
If other RRSIG RRs also cover this RRset, the local resolver security
|
||
policy determines whether the resolver also needs to test these RRSIG
|
||
RRs, and determines how to resolve conflicts if these RRSIG RRs lead
|
||
to differing results.
|
||
|
||
If the resolver accepts the RRset as authentic, the resolver MUST set
|
||
the TTL of the RRSIG RR and each RR in the authenticated RRset to a
|
||
value no greater than the minimum of:
|
||
|
||
o The RRset's TTL as received in the response;
|
||
|
||
o The RRSIG RR's TTL as received in the response; and
|
||
|
||
o The value in the RRSIG RR's Original TTL field.
|
||
|
||
|
||
5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
|
||
|
||
If the number of labels in an RRset's owner name is greater than the
|
||
Labels field of the covering RRSIG RR, then the RRset and its
|
||
covering RRSIG RR were created as a result of wildcard expansion.
|
||
Once the resolver has verified the signature as described 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
|
||
query. Section 5.4 discusses these steps.
|
||
|
||
Note that the response received by the resolver should include all
|
||
NSEC RRs needed to authenticate the response (see Section 3.1.3).
|
||
|
||
5.4 Authenticated Denial of Existence
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 32]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
A resolver can use authenticated NSEC RRs to prove that an RRset is
|
||
not present in a signed zone. Security-aware name servers should
|
||
automatically include any necessary NSEC RRs for signed zones in
|
||
their responses to security-aware resolvers.
|
||
|
||
Security-aware resolvers MUST first authenticate NSEC RRsets
|
||
according to the standard RRset authentication rules described in
|
||
Section 5.3, then apply the NSEC RRsets as follows:
|
||
|
||
o If the requested RR name matches the owner name of an
|
||
authenticated NSEC RR, then the NSEC RR's type bit map field lists
|
||
all RR types present at that owner name, and a resolver can prove
|
||
that the requested RR type does not exist by checking for the RR
|
||
type in the bit map. If the number of labels in an authenticated
|
||
NSEC RR's owner name equals the Labels field of the covering RRSIG
|
||
RR, then the existence of the NSEC RR proves that wildcard
|
||
expansion could not have been used to match the request.
|
||
|
||
o If the requested RR name would appear after an authenticated NSEC
|
||
RR's owner name and before the name listed in that NSEC RR's Next
|
||
Domain Name field according to the canonical DNS name order
|
||
defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
|
||
the requested name exist in the zone. However, it is possible
|
||
that a wildcard could be used to match the requested RR owner name
|
||
and type, so proving that the requested RRset does not exist also
|
||
requires proving that no possible wildcard RRset exists that could
|
||
have been used to generate a positive response.
|
||
|
||
To prove non-existence of an RRset, the resolver must be able to
|
||
verify both that the queried RRset does not exist and that no
|
||
relevant wildcard RRset exists. Proving this may require more than
|
||
one NSEC RRset from the zone. If the complete set of necessary NSEC
|
||
RRsets is not present in a response (perhaps due to message
|
||
truncation), then a security-aware resolver MUST resend the query in
|
||
order to attempt to obtain the full collection of NSEC RRs necessary
|
||
to verify non-existence of the requested RRset. As with all DNS
|
||
operations, however, the resolver MUST bound the work it puts into
|
||
answering any particular query.
|
||
|
||
Since a verified NSEC RR proves the existence of both itself and its
|
||
corresponding RRSIG RR, a verifier MUST ignore the settings of the
|
||
NSEC and RRSIG bits in an NSEC RR.
|
||
|
||
5.5 Authentication Example
|
||
|
||
Appendix C shows an example the authentication process.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 33]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
6. IANA Considerations
|
||
|
||
[I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
|
||
considerations introduced by DNSSEC. The additional IANA
|
||
considerations discussed in this document:
|
||
|
||
[RFC2535] reserved the CD and AD bits in the message header. The
|
||
meaning of the AD bit was redefined in [RFC3655] and the meaning of
|
||
both the CD and AD bit are restated in this document. No new bits in
|
||
the DNS message header are defined in this document.
|
||
|
||
[RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
|
||
and defined its use. The use is restated but not altered in this
|
||
document.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 34]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
7. Security Considerations
|
||
|
||
This document describes how the DNS security extensions use public
|
||
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; see
|
||
[I-D.ietf-dnsext-dnssec-intro] for considerations specific to the
|
||
DNSSEC resource record types.
|
||
|
||
An active attacker who can set the CD bit in a DNS query message or
|
||
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.8 for further discussion.
|
||
|
||
The protocol described in this document attempts to extend the
|
||
benefits of DNSSEC to security-oblivious stub resolvers. However,
|
||
since recovery from validation failures is likely to be specific to
|
||
particular applications, the facilities that DNSSEC provides for stub
|
||
resolvers may prove inadequate. Operators of security-aware
|
||
recursive name servers will need to pay close attention to the
|
||
behavior of the applications which use their services when choosing a
|
||
local validation policy; failure to do so could easily result in the
|
||
recursive name server accidently denying service to the clients it is
|
||
intended to support.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 35]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
8. Acknowledgements
|
||
|
||
This document was created from the input and ideas of the members of
|
||
the DNS Extensions Working Group and working group mailing list. The
|
||
editors would like to express their thanks for the comments and
|
||
suggestions received during the revision of these security extension
|
||
specifications. While explicitly listing everyone who has
|
||
contributed during the decade during which DNSSEC has been under
|
||
development would be an impossible task,
|
||
[I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
|
||
participants who were kind enough to comment on these documents.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 36]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Normative References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
|
||
August 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||
2671, August 1999.
|
||
|
||
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
|
||
3225, December 2001.
|
||
|
||
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
|
||
message size requirements", RFC 3226, December 2001.
|
||
|
||
[I-D.ietf-dnsext-dnssec-intro]
|
||
Arends, R., Austein, R., Larson, M., Massey, D. and S.
|
||
Rose, "DNS Security Introduction and Requirements",
|
||
draft-ietf-dnsext-dnssec-intro-09 (work in progress),
|
||
February 2004.
|
||
|
||
[I-D.ietf-dnsext-dnssec-records]
|
||
Arends, R., Austein, R., Larson, M., Massey, D. and S.
|
||
Rose, "Resource Records for DNS Security Extensions",
|
||
draft-ietf-dnsext-dnssec-records-07 (work in progress),
|
||
February 2004.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 37]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Informative References
|
||
|
||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
|
||
NCACHE)", RFC 2308, March 1998.
|
||
|
||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
|
||
RFC 2535, March 1999.
|
||
|
||
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
|
||
RR)", RFC 2930, September 2000.
|
||
|
||
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
|
||
SIG(0)s)", RFC 2931, September 2000.
|
||
|
||
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
|
||
Authenticated Data (AD) bit", RFC 3655, November 2003.
|
||
|
||
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
|
||
(RR)", RFC 3658, December 2003.
|
||
|
||
[I-D.ietf-dnsext-wcard-clarify]
|
||
Halley, B. and E. Lewis, "Clarifying the Role of Wild Card
|
||
Domains in the Domain Name System",
|
||
draft-ietf-dnsext-wcard-clarify-02 (work in progress),
|
||
September 2003.
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Roy Arends
|
||
Telematica Instituut
|
||
Drienerlolaan 5
|
||
7522 NB Enschede
|
||
NL
|
||
|
||
EMail: roy.arends@telin.nl
|
||
|
||
|
||
Matt Larson
|
||
VeriSign, Inc.
|
||
21345 Ridgetop Circle
|
||
Dulles, VA 20166-6503
|
||
USA
|
||
|
||
EMail: mlarson@verisign.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 38]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Rob Austein
|
||
Internet Systems Consortium
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
USA
|
||
|
||
EMail: sra@isc.org
|
||
|
||
|
||
Dan Massey
|
||
USC Information Sciences Institute
|
||
3811 N. Fairfax Drive
|
||
Arlington, VA 22203
|
||
USA
|
||
|
||
EMail: masseyd@isi.edu
|
||
|
||
|
||
Scott Rose
|
||
National Institute for Standards and Technology
|
||
100 Bureau Drive
|
||
Gaithersburg, MD 20899-8920
|
||
USA
|
||
|
||
EMail: scott.rose@nist.gov
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 39]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Appendix A. Signed Zone Example
|
||
|
||
The following example shows a (small) complete signed zone.
|
||
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1071609350
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
3600 RRSIG SOA 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
|
||
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
|
||
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
|
||
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
|
||
owLe/OV+Qqqic7ShV/S9l2YJF9I= )
|
||
3600 NS ns1.example.
|
||
3600 NS ns2.example.
|
||
3600 RRSIG NS 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
|
||
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
|
||
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
|
||
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
|
||
FTVyQbVkcaxQ6U2FbZtMbfo//go= )
|
||
3600 MX 1 xx.example.
|
||
3600 RRSIG MX 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18
|
||
7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe
|
||
IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+
|
||
M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q
|
||
7wxkDWyzgasGiMNIKgYrm9vXz04= )
|
||
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
3600 RRSIG NSEC 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
|
||
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
|
||
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
|
||
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
|
||
7T/nOEOVZujD8IN/Utv+KUg+P6U= )
|
||
3600 DNSKEY 256 3 5 (
|
||
AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH
|
||
UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV
|
||
fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv
|
||
BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 40]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q==
|
||
)
|
||
3600 DNSKEY 257 3 5 (
|
||
AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U
|
||
Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv
|
||
klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE
|
||
2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT
|
||
nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ==
|
||
)
|
||
3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU
|
||
pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5
|
||
YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc
|
||
tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG
|
||
PjJstq6fvRq8kX7TPJcljUmDFKM= )
|
||
3600 RRSIG DNSKEY 5 1 3600 20040115201552 (
|
||
20031216201552 60717 example.
|
||
EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/
|
||
C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK
|
||
L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY
|
||
J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34
|
||
Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= )
|
||
a.example. 3600 IN NS ns1.a.example.
|
||
3600 IN NS ns2.a.example.
|
||
3600 DS 48327 5 1 (
|
||
DFEB5E00E71A4DED5CABBBD7F15F24871983
|
||
CAB7 )
|
||
3600 RRSIG DS 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
|
||
hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
|
||
rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
|
||
ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
|
||
0yfe2uolEkeegjesDZuF+fC61Eg= )
|
||
3600 NSEC ai.example. NS DS RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb
|
||
RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1
|
||
3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O
|
||
ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf
|
||
YgfAHJEJJj7K88QbKEK4/Je1hyk= )
|
||
ns1.a.example. 3600 IN A 192.0.2.5
|
||
ns2.a.example. 3600 IN A 192.0.2.6
|
||
ai.example. 3600 IN A 192.0.2.9
|
||
3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 41]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
|
||
jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
|
||
Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
|
||
OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
|
||
sWifTxvcG5hv+A6TOd0O2xJYRik= )
|
||
3600 HINFO "KLH-10" "ITS"
|
||
3600 RRSIG HINFO 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C
|
||
hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2
|
||
KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2
|
||
Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92
|
||
xo9NLoltg0GuwggZM240pRoTwO8= )
|
||
3600 AAAA 2001:db8::f00:baa9
|
||
3600 RRSIG AAAA 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
|
||
9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
|
||
G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
|
||
A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
|
||
zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
|
||
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE
|
||
ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y
|
||
ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU
|
||
4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR
|
||
ovChG5Ih3TOa8Qnch4IJQVfSFNU= )
|
||
b.example. 3600 IN NS ns1.b.example.
|
||
3600 IN NS ns2.b.example.
|
||
3600 NSEC ns1.example. NS RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
|
||
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
|
||
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
|
||
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
|
||
GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
|
||
ns1.b.example. 3600 IN A 192.0.2.7
|
||
ns2.b.example. 3600 IN A 192.0.2.8
|
||
ns1.example. 3600 IN A 192.0.2.1
|
||
3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
|
||
CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
|
||
RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
|
||
+ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 42]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
|
||
3600 NSEC ns2.example. A RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
|
||
sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
|
||
eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
|
||
s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
|
||
I2A5W86mMEbSgEF/pZHX/wi5FJI= )
|
||
ns2.example. 3600 IN A 192.0.2.2
|
||
3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
|
||
xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
|
||
HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
|
||
sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
|
||
wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
|
||
3600 NSEC *.w.example. A RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb
|
||
IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b
|
||
f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J
|
||
aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl
|
||
yCup5bk/Dr47eU2/6+lqrBTOV8Q= )
|
||
*.w.example. 3600 IN MX 1 ai.example.
|
||
3600 RRSIG MX 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
|
||
OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
|
||
Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
|
||
n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
|
||
91Ena87PA2MvoOE+A3ZpEk8MjEE= )
|
||
3600 NSEC x.w.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
|
||
f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
|
||
9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
|
||
/RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
|
||
ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
|
||
x.w.example. 3600 IN MX 1 xx.example.
|
||
3600 RRSIG MX 5 3 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
|
||
ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
|
||
8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
|
||
MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 43]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
btznHMFDIbtuw/tAX7xXH2pDDHY= )
|
||
3600 NSEC x.y.w.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 3 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia
|
||
CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA
|
||
EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA
|
||
aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT
|
||
3lMXiX4KNWUhB87q/pT/5z+xrqY= )
|
||
x.y.w.example. 3600 IN MX 1 xx.example.
|
||
3600 RRSIG MX 5 4 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD
|
||
v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE
|
||
unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK
|
||
Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk
|
||
Iykd5UmaTO5j4LlRnAvF8Z1m9/k= )
|
||
3600 NSEC xx.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 4 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
|
||
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
|
||
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
|
||
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
|
||
viOQHZ6I4xoZQP5G7r98/PhlrLM= )
|
||
xx.example. 3600 IN A 192.0.2.10
|
||
3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
|
||
tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
|
||
iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
|
||
KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
|
||
0ToQVY81bPc3WXKZjRxQl3jiKtU= )
|
||
3600 HINFO "KLH-10" "TOPS-20"
|
||
3600 RRSIG HINFO 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw
|
||
p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA
|
||
gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/
|
||
pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp
|
||
EDXT07qFXtGntvBSpF9uQbEub6Y= )
|
||
3600 AAAA 2001:db8::f00:baaa
|
||
3600 RRSIG AAAA 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
|
||
dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
|
||
mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
|
||
CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 44]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
D4ZubIon0XGe9fIjLnmb3pX/FUk= )
|
||
3600 NSEC example. A HINFO AAAA RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn
|
||
uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE
|
||
NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a
|
||
1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187
|
||
sSNF3PAC0HPadh7SdHmXlFQtQ44= )
|
||
|
||
The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
|
||
Flags indicate that each of these DNSKEY RRs is a zone key. One of
|
||
these DNSKEY RRs also has the SEP flag set and has been used to sign
|
||
the apex DNSKEY RRset; this is the key which should be hashed to
|
||
generate a DS record to be inserted into the parent zone. The other
|
||
DNSKEY is used to sign all the other RRsets in the zone.
|
||
|
||
The zone includes a wildcard entry "*.w.example". Note that the name
|
||
"*.w.example" is used in constructing NSEC chains, and that the RRSIG
|
||
covering the "*.w.example" MX RRset has a label count of 2.
|
||
|
||
The zone also includes two delegations. The delegation to
|
||
"b.example" includes an NS RRset, glue address records, and an NSEC
|
||
RR; note that only the NSEC RRset is signed. The delegation to
|
||
"a.example" provides a DS RR; note that only the NSEC and DS RRsets
|
||
are signed.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 45]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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 5 3 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW
|
||
ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m
|
||
8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY
|
||
MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv
|
||
btznHMFDIbtuw/tAX7xXH2pDDHY= )
|
||
|
||
;; Authority
|
||
example. 3600 NS ns1.example.
|
||
example. 3600 NS ns2.example.
|
||
example. 3600 RRSIG NS 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
|
||
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
|
||
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
|
||
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
|
||
FTVyQbVkcaxQ6U2FbZtMbfo//go= )
|
||
|
||
;; Additional
|
||
xx.example. 3600 IN A 192.0.2.10
|
||
xx.example. 3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap
|
||
tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq
|
||
iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS
|
||
KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G
|
||
0ToQVY81bPc3WXKZjRxQl3jiKtU= )
|
||
xx.example. 3600 AAAA 2001:db8::f00:baaa
|
||
xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 46]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD
|
||
mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg
|
||
CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z
|
||
D4ZubIon0XGe9fIjLnmb3pX/FUk= )
|
||
ns1.example. 3600 IN A 192.0.2.1
|
||
ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7
|
||
CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs
|
||
RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf
|
||
+ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa
|
||
WNJ/ulvIFa20d0xtlB7jazNCZ3Y= )
|
||
ns2.example. 3600 IN A 192.0.2.2
|
||
ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL
|
||
xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK
|
||
HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht
|
||
sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG
|
||
wCbeY0Rl8MIRcAaiIkFos/8hd1g= )
|
||
|
||
|
||
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.x.w.example. (
|
||
1071609350
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
|
||
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
|
||
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 47]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
|
||
owLe/OV+Qqqic7ShV/S9l2YJF9I= )
|
||
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
|
||
b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
|
||
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
|
||
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
|
||
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
|
||
GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
|
||
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
|
||
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
|
||
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
|
||
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
|
||
7T/nOEOVZujD8IN/Utv+KUg+P6U= )
|
||
|
||
;; 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.x.w.example. (
|
||
1071609350
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
|
||
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 48]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
|
||
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
|
||
owLe/OV+Qqqic7ShV/S9l2YJF9I= )
|
||
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
|
||
ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ
|
||
sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0
|
||
eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA
|
||
s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj
|
||
I2A5W86mMEbSgEF/pZHX/wi5FJI= )
|
||
|
||
;; 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 48327 5 1 (
|
||
DFEB5E00E71A4DED5CABBBD7F15F24871983
|
||
CAB7 )
|
||
a.example. 3600 RRSIG DS 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/
|
||
hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb
|
||
rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c
|
||
ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC
|
||
0yfe2uolEkeegjesDZuF+fC61Eg= )
|
||
|
||
;; Additional
|
||
ns1.a.example. 3600 IN A 192.0.2.5
|
||
ns2.a.example. 3600 IN A 192.0.2.6
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 49]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs
|
||
VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW
|
||
VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN
|
||
k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX
|
||
GRIZP9W1bgeDHZRcCNz2hQ67SgY= )
|
||
|
||
;; 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 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg
|
||
OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 50]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA
|
||
n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK
|
||
91Ena87PA2MvoOE+A3ZpEk8MjEE= )
|
||
|
||
;; Authority
|
||
example. 3600 NS ns1.example.
|
||
example. 3600 NS ns2.example.
|
||
example. 3600 RRSIG NS 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz
|
||
+bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj
|
||
s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY
|
||
eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH
|
||
FTVyQbVkcaxQ6U2FbZtMbfo//go= )
|
||
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
|
||
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
|
||
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
|
||
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
|
||
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
|
||
viOQHZ6I4xoZQP5G7r98/PhlrLM= )
|
||
|
||
;; Additional
|
||
ai.example. 3600 IN A 192.0.2.9
|
||
ai.example. 3600 RRSIG A 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8
|
||
jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c
|
||
Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk
|
||
OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A
|
||
sWifTxvcG5hv+A6TOd0O2xJYRik= )
|
||
ai.example. 3600 AAAA 2001:db8::f00:baa9
|
||
ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5
|
||
9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ
|
||
G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI
|
||
A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI
|
||
zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= )
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 51]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
a.z.w.example. IN AAAA
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1071609350
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
|
||
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
|
||
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
|
||
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
|
||
owLe/OV+Qqqic7ShV/S9l2YJF9I= )
|
||
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
|
||
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8
|
||
VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj
|
||
Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq
|
||
AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J
|
||
viOQHZ6I4xoZQP5G7r98/PhlrLM= )
|
||
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
|
||
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr
|
||
f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45
|
||
9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK
|
||
/RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW
|
||
ANi1i3zhPOd3+Vjt4IQzaJXqVZE= )
|
||
|
||
;; 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.
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 52]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
example. IN DS
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1071609350
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA
|
||
hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0
|
||
VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj
|
||
CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM
|
||
owLe/OV+Qqqic7ShV/S9l2YJF9I= )
|
||
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
example. 3600 RRSIG NSEC 5 1 3600 20040115201552 (
|
||
20031216201552 41681 example.
|
||
kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT
|
||
vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX
|
||
TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g
|
||
Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4
|
||
7T/nOEOVZujD8IN/Utv+KUg+P6U= )
|
||
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 53]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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 5 and key tag 41681.
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 54]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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 5 and has a key tag of 41681. This
|
||
DNSKEY is used to authenticated the RRSIG included in the response.
|
||
If multiple "example" DNSKEY RRs have algorithm 5 and key tag of
|
||
41681, 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
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 55]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
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 5 and key tag 41681.
|
||
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).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 56]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
Intellectual Property Statement
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
intellectual property or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; neither does it represent that it
|
||
has made any effort to identify any such rights. Information on the
|
||
IETF's procedures with respect to rights in standards-track and
|
||
standards-related documentation can be found in BCP-11. Copies of
|
||
claims of rights made available for publication and any assurances of
|
||
licenses to be made available, or the result of an attempt made to
|
||
obtain a general license or permission for the use of such
|
||
proprietary rights by implementors or users of this specification can
|
||
be obtained from the IETF Secretariat.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights which may cover technology that may be required to practice
|
||
this standard. Please address the information to the IETF Executive
|
||
Director.
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assignees.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 57]
|
||
|
||
Internet-Draft DNSSEC Protocol Modifications February 2004
|
||
|
||
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Expires August 16, 2004 [Page 58]
|
||
|
||
|