2972 lines
128 KiB
Plaintext
2972 lines
128 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group R. Arends
|
||
Request for Comments: 4035 Telematica Instituut
|
||
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
|
||
3755, 3757, 3845 ISC
|
||
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
|
||
3007, 3597, 3226 VeriSign
|
||
Category: Standards Track D. Massey
|
||
Colorado State University
|
||
S. Rose
|
||
NIST
|
||
March 2005
|
||
|
||
|
||
Protocol Modifications for the DNS Security Extensions
|
||
|
||
Status of This Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
Abstract
|
||
|
||
This document is part of a family of documents that describe the DNS
|
||
Security Extensions (DNSSEC). The DNS Security Extensions are a
|
||
collection of new resource records and protocol modifications that
|
||
add data origin authentication and data integrity to the DNS. This
|
||
document describes the DNSSEC protocol modifications. This document
|
||
defines the concept of a signed zone, along with the requirements for
|
||
serving and resolving by 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 1]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.1. Background and Related Documents . . . . . . . . . . . . 4
|
||
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
|
||
2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5
|
||
2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5
|
||
2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6
|
||
2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7
|
||
2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7
|
||
2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8
|
||
2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8
|
||
3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||
3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9
|
||
3.1.1. Including RRSIG RRs in a Response . . . . . . . 10
|
||
3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11
|
||
3.1.3. Including NSEC RRs in a Response . . . . . . . . 11
|
||
3.1.4. Including DS RRs in a Response . . . . . . . . . 14
|
||
3.1.5. Responding to Queries for Type AXFR or IXFR . . 15
|
||
3.1.6. The AD and CD Bits in an Authoritative Response. 16
|
||
3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17
|
||
3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17
|
||
3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17
|
||
3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18
|
||
3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
|
||
4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
|
||
4.2. Signature Verification Support . . . . . . . . . . . . . 19
|
||
4.3. Determining Security Status of Data . . . . . . . . . . 20
|
||
4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21
|
||
4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21
|
||
4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22
|
||
4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
|
||
4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
|
||
4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
|
||
4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24
|
||
4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24
|
||
4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24
|
||
5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
|
||
5.1. Special Considerations for Islands of Security . . . . . 26
|
||
5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26
|
||
5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28
|
||
5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28
|
||
5.3.2. Reconstructing the Signed Data . . . . . . . . . 29
|
||
5.3.3. Checking the Signature . . . . . . . . . . . . . 31
|
||
5.3.4. Authenticating a Wildcard Expanded RRset
|
||
Positive Response. . . . . . . . . . . . . . . . 32
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 2]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
5.4. Authenticated Denial of Existence . . . . . . . . . . . 32
|
||
5.5. Resolver Behavior When Signatures Do Not Validate . . . 33
|
||
5.6. Authentication Example . . . . . . . . . . . . . . . . . 33
|
||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
|
||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
|
||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
|
||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
|
||
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
|
||
9.2. Informative References . . . . . . . . . . . . . . . . . 35
|
||
A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36
|
||
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41
|
||
B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
|
||
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
|
||
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44
|
||
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44
|
||
B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45
|
||
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
|
||
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
|
||
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48
|
||
C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49
|
||
C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49
|
||
C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49
|
||
C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
|
||
C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50
|
||
C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50
|
||
C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51
|
||
C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
|
||
C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
|
||
C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
|
||
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
|
||
|
||
1. Introduction
|
||
|
||
The DNS Security Extensions (DNSSEC) are a collection of new resource
|
||
records and protocol modifications that 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 for handling signed zones. Section 4
|
||
describes the behavior of entities that include security-aware
|
||
resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
|
||
to authenticate a response.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 3]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
1.1. Background and Related Documents
|
||
|
||
This document is part of a family of documents defining DNSSEC that
|
||
should be read together as a set.
|
||
|
||
[RFC4033] contains an introduction to DNSSEC and definitions of
|
||
common terms; the reader is assumed to be familiar with this
|
||
document. [RFC4033] also contains a list of other documents updated
|
||
by and obsoleted by this document set.
|
||
|
||
[RFC4034] defines the DNSSEC resource records.
|
||
|
||
The reader is also assumed to be familiar with the basic DNS concepts
|
||
described in [RFC1034], [RFC1035], and the subsequent documents that
|
||
update them; particularly, [RFC2181] and [RFC2308].
|
||
|
||
This document defines the DNSSEC protocol operations.
|
||
|
||
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 [RFC2119].
|
||
|
||
2. Zone Signing
|
||
|
||
DNSSEC introduces the concept of signed zones. A signed zone
|
||
includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
|
||
Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
|
||
according to the rules specified in Sections 2.1, 2.2, 2.3, and 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 does a CNAME RR.
|
||
|
||
DNSSEC specifies the placement of two new RR types, NSEC and DS,
|
||
which can be placed at the parental side of a zone cut (that is, at a
|
||
delegation point). This is an exception to the general prohibition
|
||
against putting data in the parent zone at a zone cut. Section 2.6
|
||
describes this change.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 4]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 in a zone, the zone SHOULD include a zone DNSKEY RR
|
||
containing the corresponding public key. A zone key DNSKEY RR MUST
|
||
have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
|
||
of [RFC4034]). 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 administrator intends a signed zone to be usable other
|
||
than as an island of security, the zone apex MUST contain at least
|
||
one DNSKEY RR to act as a secure entry point into the zone. This
|
||
secure entry point could then be used as the target of a secure
|
||
delegation via a corresponding DS RR in the parent zone (see
|
||
[RFC4034]).
|
||
|
||
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 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
|
||
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.
|
||
|
||
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 [RFC4034]. An RRset MAY have multiple RRSIG RRs
|
||
associated with it. Note that as RRSIG RRs are closely tied to the
|
||
RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 5]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
RR types, do not form RRsets. In particular, the TTL values among
|
||
RRSIG RRs with a common owner name do not follow the RRset rules
|
||
described in [RFC2181].
|
||
|
||
An RRSIG RR itself MUST NOT be signed, as 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 zone apex DNSKEY RRset. The apex DNSKEY RRset
|
||
itself MUST be signed by each algorithm appearing in the DS RRset
|
||
located at the delegating parent (if any).
|
||
|
||
2.3. Including NSEC RRs in a Zone
|
||
|
||
Each owner name in the zone that has authoritative data or a
|
||
delegation point NS RRset MUST have an NSEC resource record. The
|
||
format of NSEC RRs and the process for constructing the NSEC RR for a
|
||
given name is described in [RFC4034].
|
||
|
||
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 name nodes that were not
|
||
the owner name of any RRset before the zone was signed. The main
|
||
reasons for this are a desire for namespace consistency between
|
||
signed and unsigned versions of the same zone and a desire to reduce
|
||
the risk of response inconsistency in security oblivious recursive
|
||
name servers.
|
||
|
||
The type bitmap of every NSEC resource record in a signed zone MUST
|
||
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
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 6]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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
|
||
visible only during the zone signing process, as NSEC RRsets are
|
||
authoritative data and are therefore signed. Thus, any owner name
|
||
that has an NSEC RRset will have RRSIG RRs as well in the signed
|
||
zone.
|
||
|
||
The bitmap for the NSEC RR at a delegation point requires special
|
||
attention. Bits corresponding to the delegation NS RRset and any
|
||
RRsets for which the parent zone has authoritative data MUST be set;
|
||
bits corresponding to any non-NS RRset for which the parent is not
|
||
authoritative MUST be clear.
|
||
|
||
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 that is present in the child's
|
||
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
|
||
by the corresponding private key. DS RRs that fail to meet these
|
||
conditions are not useful for validation, but because the DS RR and
|
||
its corresponding DNSKEY RR are in different zones, and because the
|
||
DNS is only loosely consistent, temporary mismatches can occur.
|
||
|
||
The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
|
||
(that is, 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 ([RFC3007]).
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 7]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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.
|
||
|
||
2.6. DNSSEC RR Types Appearing at Zone Cuts
|
||
|
||
DNSSEC introduced two new RR types that are unusual in that they can
|
||
appear at the parental side of a zone cut. At the parental side of a
|
||
zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
|
||
the owner name. A DS RR could also be present if the zone being
|
||
delegated is signed and seeks to have a chain of authentication to
|
||
the parent zone. This is an exception to the original DNS
|
||
specification ([RFC1034]), which states that only NS RRsets could
|
||
appear at the parental side of a zone cut.
|
||
|
||
This specification updates the original DNS specification to allow
|
||
NSEC and DS RR types at the parent side of a zone cut. These RRsets
|
||
are authoritative for the parent when they appear at the parent side
|
||
of a zone cut.
|
||
|
||
2.7. Example of a Secure Zone
|
||
|
||
Appendix A shows a complete example of a small signed zone.
|
||
|
||
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. 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.
|
||
|
||
In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
|
||
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. As IPv6
|
||
packets can only be fragmented by the source host, a security aware
|
||
name server SHOULD take steps to ensure that UDP datagrams it
|
||
transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
|
||
MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460],
|
||
and [RFC3226] for further discussion of packet size and fragmentation
|
||
issues.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 8]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 clear 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.
|
||
Because 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.
|
||
|
||
Security aware name servers that receive explicit queries for
|
||
security RR types that match the content of more than one zone that
|
||
it serves (for example, NSEC and RRSIG RRs above and below a
|
||
delegation point where the server is authoritative for both zones)
|
||
should behave self-consistently. As long as the response is always
|
||
consistent for each query to the name server, the name server MAY
|
||
return one of the following:
|
||
|
||
o The above-delegation RRsets.
|
||
o The below-delegation RRsets.
|
||
o Both above and below-delegation RRsets.
|
||
o Empty answer section (no records).
|
||
o Some other response.
|
||
o An error.
|
||
|
||
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 Sections 3.1.6,
|
||
3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
|
||
|
||
A security aware name server that synthesizes CNAME RRs from DNAME
|
||
RRs as described in [RFC2672] SHOULD NOT generate signatures for the
|
||
synthesized CNAME RRs.
|
||
|
||
3.1. Authoritative Name Servers
|
||
|
||
Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
|
||
pseudo-RR DO bit ([RFC3225]) set, 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 9]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
These rules only apply to responses where the semantics convey
|
||
information about the presence or absence of resource records. That
|
||
is, these rules are not intended to rule out responses such as RCODE
|
||
4 ("Not Implemented") or RCODE 5 ("Refused").
|
||
|
||
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, 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. A name server SHOULD make every attempt to keep the RRset
|
||
and its associated RRSIG(s) together in a response. Inclusion of
|
||
RRSIG RRs in a response is subject to the following rules:
|
||
|
||
o When placing a signed RRset in the Answer section, the name server
|
||
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 have 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 have 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 MAY retain the RRset while
|
||
dropping the RRSIG RRs. If this happens, the name server MUST NOT
|
||
set the TC bit solely because these RRSIG RRs didn't fit.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 10]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
3.1.2. Including DNSKEY RRs in a Response
|
||
|
||
When responding to a query that has the DO bit set 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 does
|
||
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).
|
||
|
||
3.1.3. Including NSEC RRs in a Response
|
||
|
||
When responding to a query that has the DO bit set, 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> and 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 in the zone.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 11]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 that 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:
|
||
|
||
o An NSEC RR proving that there is no exact match for <SNAME,
|
||
SCLASS>.
|
||
|
||
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. If
|
||
it does, 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
|
||
that is not the owner name for any RRset but that 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 that exactly match <SNAME,
|
||
SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
|
||
via wildcard name expansion, the name server MUST include the
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 12]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 although the zone
|
||
does contain RRsets that match <SNAME, SCLASS> via wildcard
|
||
expansion, none of those RRsets matches 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 that matched <SNAME, SCLASS> via wildcard
|
||
expansion.
|
||
|
||
o An NSEC RR proving that there are no RRsets in the zone that would
|
||
have been a closer match for <SNAME, SCLASS>.
|
||
|
||
In some cases, a single NSEC RR may prove both of these points. If
|
||
it does, 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 has to locate an NSEC RR
|
||
that proves that no RRsets matching a particular SNAME 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 that would have held
|
||
the non-existent RRsets matching SNAME. The algorithm below is
|
||
written for clarity, not for efficiency.
|
||
|
||
To find the NSEC that proves that no RRsets matching name N exist in
|
||
the zone Z that would have held them, construct a sequence, S,
|
||
consisting of the owner names of every RRset in Z, sorted into
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 13]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
canonical order ([RFC4034]), with no duplicate names. Find the name
|
||
M that would have immediately preceded N in S if any RRsets with
|
||
owner name N had existed. M is the owner name of the NSEC RR that
|
||
proves that no RRsets exist with owner name N.
|
||
|
||
The algorithm for finding the NSEC RR that 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 no RRsets exist with the applicable wildcard name is
|
||
precisely the same as the algorithm for finding the NSEC RR that
|
||
proves that RRsets with any other owner name do not exist. The part
|
||
that's missing is a method of determining the name of the non-
|
||
existent 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 that has the DO bit set, a security-aware
|
||
authoritative name server returning a referral includes DNSSEC data
|
||
along with the NS RRset.
|
||
|
||
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.
|
||
|
||
If no DS RRset is present at the delegation point, the name server
|
||
MUST return both the NSEC RR that 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, as 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.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 14]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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.
|
||
|
||
o The name server is authoritative for the child zone.
|
||
|
||
o The name server is not authoritative for the parent zone.
|
||
|
||
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 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.
|
||
|
||
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 to meet 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 that
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 15]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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, as the NSEC RR in the child zone's apex will always indicate
|
||
the presence of the child zone's SOA RR whereas 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 in zone transfers of
|
||
the parent zone, and the NSEC at the zone apex of the child zone 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, and the RRSIG for any RRset in the
|
||
child zone's apex will be authoritative in the child zone. Parental
|
||
and child RRSIG RRs at a zone cut will never be identical to each
|
||
other, as the Signer's Name field of an RRSIG RR in the child zone's
|
||
apex will indicate a DNSKEY RR in the child zone's apex whereas the
|
||
same field of a parental RRSIG RR at the zone cut will indicate a
|
||
DNSKEY RR in the parent zone's apex. 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 for use in communication between
|
||
security-aware resolvers and security-aware recursive name servers.
|
||
These bits are for the most part not relevant to query processing by
|
||
security-aware authoritative name servers.
|
||
|
||
A security-aware name server does not perform signature validation
|
||
for authoritative data during query processing, even when the CD bit
|
||
is clear. A security-aware name server SHOULD clear the CD bit when
|
||
composing an authoritative response.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 16]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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. However, 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 that 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 [RFC4033], a security-aware recursive name server is
|
||
an entity that 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 that implements the
|
||
security-aware name server role and the code that implements the
|
||
security-aware resolver role, respectively.
|
||
|
||
The resolver side follows the usual rules for caching and negative
|
||
caching that would apply to any security-aware resolver.
|
||
|
||
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 RR types 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 state of the CD bit to the resolver side along with the rest
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 17]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
of an initiating query, so that the resolver side will know whether
|
||
it is required to verify the response data it returns to the name
|
||
server side. If the CD bit is set, 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, 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 that matches an entry in the
|
||
resolver side's BAD cache, the name server side's response depends on
|
||
the state 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).
|
||
|
||
The intent of the above rule is to provide the raw data to clients
|
||
that are capable of performing their own signature verification
|
||
checks while protecting clients that depend on the resolver side of a
|
||
security-aware recursive name server to perform such checks. Several
|
||
of the possible reasons why signature validation might fail involve
|
||
conditions that may not apply equally to the recursive name server
|
||
and the client that invoked it. For example, the recursive name
|
||
server's clock may be set incorrectly, or the client may have
|
||
knowledge of a relevant island of security that the recursive name
|
||
server does not share. In such cases, "protecting" a client that is
|
||
capable of performing its own signature validation from ever seeing
|
||
the "bad" data does not help the client.
|
||
|
||
3.2.3. The AD Bit
|
||
|
||
The name server side of a security-aware recursive name server MUST
|
||
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. The name server side 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.
|
||
However, for backward compatibility, a recursive name server MAY set
|
||
the AD bit when a response includes unsigned CNAME RRs if those CNAME
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 18]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
RRs demonstrably could have been synthesized from an authentic DNAME
|
||
RR that is also included in the response according to the synthesis
|
||
rules described in [RFC2672].
|
||
|
||
3.3. Example DNSSEC Responses
|
||
|
||
See Appendix B for example response packets.
|
||
|
||
4. Resolving
|
||
|
||
This section describes the behavior of entities that 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 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
|
||
use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
|
||
to advertise the message size that it is willing to accept. A
|
||
security-aware resolver's IP layer MUST handle fragmented UDP packets
|
||
correctly regardless of whether any such fragmented packets were
|
||
received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and
|
||
[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 SHOULD 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 that instructed the security-aware
|
||
resolver not to perform validation for this query; or
|
||
|
||
o validation for this query has been disabled by local policy.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 19]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
A security-aware resolver's support for signature verification MUST
|
||
include support for verification of wildcard owner names.
|
||
|
||
Security-aware resolvers MAY query for missing security RRs in an
|
||
attempt to perform validation; implementations that choose to do so
|
||
must be aware that the answers received may not be sufficient to
|
||
validate the original response. For example, a zone update may have
|
||
changed (or deleted) the desired information between the original and
|
||
follow-up queries.
|
||
|
||
When attempting to retrieve missing NSEC RRs that 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 off 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.
|
||
|
||
4.3. Determining Security Status of Data
|
||
|
||
A security-aware resolver MUST be able to determine whether it should
|
||
expect a particular RRset to be signed. More precisely, a
|
||
security-aware resolver must be able to distinguish between four
|
||
cases:
|
||
|
||
Secure: An RRset for which the resolver is able to build a chain of
|
||
signed DNSKEY and DS RRs from a trusted security anchor to the
|
||
RRset. In this case, the RRset should be signed and is subject to
|
||
signature validation, as described above.
|
||
|
||
Insecure: 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
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 20]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Bogus: An RRset for which the resolver believes that it ought to be
|
||
able to establish a chain of trust but for which it is unable to
|
||
do so, either due to signatures that for some reason fail to
|
||
validate or due to missing data that the relevant DNSSEC RRs
|
||
indicate should be present. This case may indicate an attack but
|
||
may also indicate a configuration error or some form of data
|
||
corruption.
|
||
|
||
Indeterminate: An RRset for which the resolver is not able to
|
||
determine whether the RRset should be signed, as 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. Configured Trust Anchors
|
||
|
||
A security-aware resolver MUST be capable of being configured with at
|
||
least one trusted public key or DS RR and SHOULD be capable of being
|
||
configured with multiple trusted public keys or DS RRs. Since a
|
||
security-aware resolver will not be able to validate signatures
|
||
without such a configured trust anchor, the resolver SHOULD have some
|
||
reasonably robust mechanism for obtaining such keys when it boots;
|
||
examples of such a mechanism would be some form of non-volatile
|
||
storage (such as a disk drive) or some form of trusted local network
|
||
configuration mechanism.
|
||
|
||
Note that trust anchors also cover key material that is updated in a
|
||
secure manner. This secure manner could be through physical media, a
|
||
key exchange protocol, or some other out-of-band means.
|
||
|
||
4.5. Response Caching
|
||
|
||
A security-aware resolver SHOULD cache each response as a single
|
||
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>.
|
||
|
||
The reason for these recommendations is that, between the initial
|
||
query and the expiration of the data from the cache, the
|
||
authoritative data might have been changed (for example, via dynamic
|
||
update).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 21]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
There are two situations for which this is relevant:
|
||
|
||
1. By using the RRSIG record, it is possible to deduce that an
|
||
answer was synthesized from a wildcard. A security-aware
|
||
recursive name server could store this wildcard data and use it
|
||
to generate positive responses to queries other than the name for
|
||
which the original answer was first received.
|
||
|
||
2. NSEC RRs received to prove the non-existence of a name could be
|
||
reused by a security-aware resolver to prove the non-existence of
|
||
any name in the name range it spans.
|
||
|
||
In theory, a resolver could use wildcards or NSEC RRs to generate
|
||
positive and negative responses (respectively) until the TTL or
|
||
signatures on the records in question expire. However, it seems
|
||
prudent for resolvers to avoid blocking new authoritative data or
|
||
synthesizing new data on their own. Resolvers that follow this
|
||
recommendation will have a more consistent view of the namespace.
|
||
|
||
4.6. Handling of the CD and AD Bits
|
||
|
||
A security-aware resolver MAY set a query's CD bit 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 clear the AD bit when composing query
|
||
messages to protect against buggy name servers that blindly copy
|
||
header bits that they do not understand from the query message to the
|
||
response message.
|
||
|
||
A resolver MUST disregard the meaning of the CD and AD bits in a
|
||
response unless the response was obtained by using a secure channel
|
||
or the resolver was specifically configured to regard the message
|
||
header bits without using a secure channel.
|
||
|
||
4.7. Caching BAD Data
|
||
|
||
While many validation errors will be transient, some are likely to be
|
||
more persistent, such as those caused by administrative error
|
||
(failure to re-sign a zone, clock skew, and so forth). Since
|
||
requerying will not help in these cases, validating resolvers might
|
||
generate a significant amount of unnecessary DNS traffic as a result
|
||
of repeated queries for RRsets with persistent validation failures.
|
||
|
||
To prevent such unnecessary DNS traffic, security-aware resolvers MAY
|
||
cache data with invalid signatures, with some restrictions.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 22]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Conceptually, caching such data is similar to negative caching
|
||
([RFC2308]), except that instead of caching a valid negative
|
||
response, the resolver is caching the fact that a particular answer
|
||
failed to validate. This document refers to a cache of data with
|
||
invalid signatures as a "BAD cache".
|
||
|
||
Resolvers that implement a BAD cache MUST take steps to prevent the
|
||
cache from being useful as a denial-of-service attack amplifier,
|
||
particularly the following:
|
||
|
||
o Since RRsets that fail to validate do not have trustworthy TTLs,
|
||
the implementation MUST assign a TTL. This TTL SHOULD be small,
|
||
in order to mitigate the effect of caching the results of an
|
||
attack.
|
||
|
||
o In order to prevent caching of a transient validation failure
|
||
(which might be the result of an attack), resolvers SHOULD track
|
||
queries that result in validation failures and SHOULD only answer
|
||
from the BAD cache after the number of times that responses to
|
||
queries for that particular <QNAME, QTYPE, QCLASS> have failed to
|
||
validate exceeds a threshold value.
|
||
|
||
Resolvers MUST NOT return RRsets from the BAD cache unless the
|
||
resolver is not required to validate the signatures of the RRsets in
|
||
question under the rules given in Section 4.2 of this document. See
|
||
Section 3.2.2 for discussion of how the responses returned by a
|
||
security-aware recursive name server interact with a BAD cache.
|
||
|
||
4.8. Synthesized CNAMEs
|
||
|
||
A validating security-aware resolver MUST treat the signature of a
|
||
valid signed DNAME RR as also covering unsigned CNAME RRs that could
|
||
have been synthesized from the DNAME RR, as described in [RFC2672],
|
||
at least to the extent of not rejecting a response message solely
|
||
because it contains such CNAME RRs. The resolver MAY retain such
|
||
CNAME RRs in its cache or in the answers it hands back, but is not
|
||
required to do so.
|
||
|
||
4.9. 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 23]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
4.9.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 that
|
||
invoked it, but is not required to do so. A non-validating stub
|
||
resolver that seeks to do this will need to set the DO bit in order
|
||
to receive DNSSEC RRs from the recursive name server.
|
||
|
||
A validating security-aware stub resolver MUST set the DO bit,
|
||
because otherwise it will not receive the DNSSEC RRs it needs to
|
||
perform signature validation.
|
||
|
||
4.9.2. Handling of the CD Bit
|
||
|
||
A non-validating security-aware stub resolver SHOULD NOT set the CD
|
||
bit when sending queries unless it is requested by the application
|
||
layer, as 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,
|
||
because 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 that would be
|
||
acceptable to the stub resolver's local policy.
|
||
|
||
4.9.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
|
||
that 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. Therefore, there may be little
|
||
practical value in 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 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, as, by definition, the
|
||
stub resolver performs its own signature validation regardless of the
|
||
setting of the AD bit.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 24]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
5. Authenticating DNS Responses
|
||
|
||
To use DNSSEC RRs for authentication, a security-aware resolver
|
||
requires configured knowledge of at least one authenticated DNSKEY or
|
||
DS RR. The process for obtaining and authenticating this initial
|
||
trust anchor 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 to 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
|
||
trust anchors.
|
||
|
||
An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
|
||
RRset. To authenticate an apex DNSKEY RRset by using an initial key,
|
||
the resolver MUST:
|
||
|
||
1. verify that the initial DNSKEY RR appears in the apex DNSKEY
|
||
RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
|
||
bit 7) set; and
|
||
|
||
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 by using an
|
||
initial DNSKEY RR, delegations from that zone can be authenticated by
|
||
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 configured 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.
|
||
|
||
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 once the resolver has authenticated a zone's apex
|
||
DNSKEY RRset. 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
|
||
lacks the appropriate DNSSEC RRs, whether due to configuration issues
|
||
such as an upstream security-oblivious recursive name server that
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 25]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
accidentally interferes 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 [RFC4033]) 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 that the validator have some other means of obtaining an
|
||
initial authenticated zone key for the island. If a validator cannot
|
||
obtain such a key, it SHOULD switch to operating as if the zones in
|
||
the island of security are unsigned.
|
||
|
||
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 trust anchor 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. Use of a strong cryptographic digest
|
||
algorithm ensures that it is computationally infeasible for an
|
||
adversary to 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).
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 26]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
o The Algorithm and Key Tag in the DS RR match the Algorithm field
|
||
and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
|
||
RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
|
||
using the digest algorithm specified in the DS RR's Digest Type
|
||
field, the resulting digest value matches the Digest field of the
|
||
DS RR.
|
||
|
||
o The matching DNSKEY RR in the child zone has the Zone Flag bit
|
||
set, 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 validator 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 validator cannot authenticate RRsets in or below the
|
||
child zone.
|
||
|
||
If the validator does not support any of the algorithms listed in an
|
||
authenticated DS RRset, then the resolver has no supported
|
||
authentication path leading from the parent to the child. The
|
||
resolver should treat this case as it would the case of an
|
||
authenticated NSEC RRset proving that no DS RRset exists, as
|
||
described above.
|
||
|
||
Note that, for a signed delegation, there are two NSEC RRs associated
|
||
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 because 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 27]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 with an RRSIG RR
|
||
|
||
A validator can use an RRSIG RR and its corresponding DNSKEY RR to
|
||
attempt to authenticate RRsets. The validator first checks the RRSIG
|
||
RR to verify that it covers the RRset, has a valid time interval, and
|
||
identifies a valid DNSKEY RR. The validator then constructs the
|
||
canonical form of the signed data by appending the RRSIG RDATA
|
||
(excluding the Signature Field) with the canonical form of the
|
||
covered RRset. Finally, the validator uses the public key and
|
||
signature to authenticate the signed data. Sections 5.3.1, 5.3.2,
|
||
and 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 validator'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 validator'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.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 28]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
It is possible for more than one DNSKEY RR to match the conditions
|
||
above. In this case, the validator cannot predetermine which DNSKEY
|
||
RR to use to authenticate the signature, and it MUST try each
|
||
matching DNSKEY RR until either the signature is validated or the
|
||
validator has run out of matching public keys to try.
|
||
|
||
Note that this authentication process is only meaningful if the
|
||
validator 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
|
||
|
||
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 trust anchor.
|
||
|
||
5.3.2. Reconstructing the Signed Data
|
||
|
||
Once the RRSIG RR has met the validity requirements described in
|
||
Section 5.3.1, the validator has 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 validator 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 | type | class | 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
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 29]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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,
|
||
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 [RFC4034].
|
||
|
||
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
|
||
RRsets 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 as only a child NSEC RR will indicate that 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. 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 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 30]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 validator 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). [RFC4034]
|
||
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 validator can only
|
||
determine which DNSKEY RR is correct by trying each matching public
|
||
key until the validator 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 has to test these RRSIG
|
||
RRs and how to resolve conflicts if these RRSIG RRs lead to differing
|
||
results.
|
||
|
||
If the resolver accepts the RRset as authentic, the validator 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;
|
||
|
||
o the value in the RRSIG RR's Original TTL field; and
|
||
|
||
o the difference of the RRSIG RR's Signature Expiration time and the
|
||
current time.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 31]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 validator has verified the signature, as described in
|
||
Section 5.3, it 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
|
||
|
||
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.
|
||
|
||
Denial of existence is determined by the following rules:
|
||
|
||
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 [RFC4034], 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.
|
||
|
||
In addition, security-aware resolvers MUST authenticate the NSEC
|
||
RRsets that comprise the non-existence proof as described in Section
|
||
5.3.
|
||
|
||
To prove the 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
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 32]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 the 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 validated NSEC RR proves the existence of both itself and its
|
||
corresponding RRSIG RR, a validator MUST ignore the settings of the
|
||
NSEC and RRSIG bits in an NSEC RR.
|
||
|
||
5.5. Resolver Behavior When Signatures Do Not Validate
|
||
|
||
If for whatever reason none of the RRSIGs can be validated, the
|
||
response SHOULD be considered BAD. If the validation was being done
|
||
to service a recursive query, the name server MUST return RCODE 2 to
|
||
the originating client. However, it MUST return the full response if
|
||
and only if the original query had the CD bit set. Also see Section
|
||
4.7 on caching responses that do not validate.
|
||
|
||
5.6. Authentication Example
|
||
|
||
Appendix C shows an example of the authentication process.
|
||
|
||
6. IANA Considerations
|
||
|
||
[RFC4034] contains a review of the IANA considerations introduced by
|
||
DNSSEC. The following are 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.
|
||
|
||
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 [RFC4033] for terminology and general security
|
||
considerations related to DNSSEC; see [RFC4034] for considerations
|
||
specific to the DNSSEC resource record types.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 33]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 that 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 Sections 3.2.2 and 4.9 for further discussion.
|
||
|
||
The protocol described in this document attempts to extend the
|
||
benefits of DNSSEC to security-oblivious stub resolvers. However, as
|
||
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 have to pay close attention to the
|
||
behavior of the applications that use their services when choosing a
|
||
local validation policy; failure to do so could easily result in the
|
||
recursive name server accidentally denying service to the clients it
|
||
is intended to support.
|
||
|
||
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. Although explicitly listing everyone who has
|
||
contributed during the decade in which DNSSEC has been under
|
||
development would be impossible, [RFC4033] includes a list of some of
|
||
the participants who were kind enough to comment on these documents.
|
||
|
||
9. References
|
||
|
||
9.1. 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.
|
||
|
||
[RFC1122] Braden, R., "Requirements for Internet Hosts -
|
||
Communication Layers", STD 3, RFC 1122, October 1989.
|
||
|
||
[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.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 34]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
||
(IPv6) Specification", RFC 2460, December 1998.
|
||
|
||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||
2671, August 1999.
|
||
|
||
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
|
||
2672, 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.
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements", RFC
|
||
4033, March 2005.
|
||
|
||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Resource Records for DNS Security Extensions", RFC
|
||
4034, March 2005.
|
||
|
||
9.2. Informative References
|
||
|
||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
|
||
NCACHE)", RFC 2308, March 1998.
|
||
|
||
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
|
||
Extensions", RFC 2535, March 1999.
|
||
|
||
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||
Update", RFC 3007, November 2000.
|
||
|
||
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
|
||
Authenticated Data (AD) bit", RFC 3655, November 2003.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 35]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Appendix A. Signed Zone Example
|
||
|
||
The following example shows a (small) complete signed zone.
|
||
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1081539377
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
3600 RRSIG SOA 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
|
||
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
|
||
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
|
||
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
|
||
jV7j86HyQgM5e7+miRAz8V01b0I= )
|
||
3600 NS ns1.example.
|
||
3600 NS ns2.example.
|
||
3600 RRSIG NS 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
|
||
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
|
||
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
|
||
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
|
||
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
|
||
3600 MX 1 xx.example.
|
||
3600 RRSIG MX 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
|
||
2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
|
||
VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
|
||
6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
|
||
W6OISukd1EQt7a0kygkg+PEDxdI= )
|
||
3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
3600 RRSIG NSEC 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
|
||
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
|
||
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
|
||
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
|
||
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
|
||
3600 DNSKEY 256 3 5 (
|
||
AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
|
||
rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
|
||
k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
|
||
vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 36]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
|
||
)
|
||
3600 DNSKEY 257 3 5 (
|
||
AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
|
||
LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
|
||
syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
|
||
RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
|
||
Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
|
||
)
|
||
3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
|
||
20040409183619 9465 example.
|
||
ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
|
||
xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
|
||
XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
|
||
hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
|
||
NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
|
||
3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
|
||
DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
|
||
bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
|
||
eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
|
||
7z5OXogYVaFzHKillDt3HRxHIZM= )
|
||
a.example. 3600 IN NS ns1.a.example.
|
||
3600 IN NS ns2.a.example.
|
||
3600 DS 57855 5 1 (
|
||
B6DCD485719ADCA18E5F3D48A2331627FDD3
|
||
636B )
|
||
3600 RRSIG DS 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
|
||
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
|
||
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
|
||
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
|
||
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
|
||
3600 NSEC ai.example. NS DS RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
|
||
U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
|
||
039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
|
||
BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
|
||
sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
|
||
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 20040509183619 (
|
||
20040409183619 38519 example.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 37]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
|
||
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
|
||
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
|
||
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
|
||
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
|
||
3600 HINFO "KLH-10" "ITS"
|
||
3600 RRSIG HINFO 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
|
||
e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
|
||
ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
|
||
AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
|
||
FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
|
||
3600 AAAA 2001:db8::f00:baa9
|
||
3600 RRSIG AAAA 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
|
||
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
|
||
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
|
||
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
|
||
sZM6QjBBLmukH30+w1z3h8PUP2o= )
|
||
3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
|
||
CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
|
||
P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
|
||
3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
|
||
AhS+JOVfDI/79QtyTI0SaDWcg8U= )
|
||
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 20040509183619 (
|
||
20040409183619 38519 example.
|
||
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
|
||
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
|
||
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
|
||
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
|
||
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
|
||
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 20040509183619 (
|
||
20040409183619 38519 example.
|
||
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
|
||
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
|
||
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
|
||
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 38]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
v/iVXSYC0b7mPSU+EOlknFpVECs= )
|
||
3600 NSEC ns2.example. A RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
|
||
1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
|
||
jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
|
||
ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
|
||
IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
|
||
ns2.example. 3600 IN A 192.0.2.2
|
||
3600 RRSIG A 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
|
||
Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
|
||
yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
|
||
6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
|
||
rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
|
||
3600 NSEC *.w.example. A RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
|
||
VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
|
||
3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
|
||
l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
|
||
Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
|
||
*.w.example. 3600 IN MX 1 ai.example.
|
||
3600 RRSIG MX 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
|
||
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
|
||
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
|
||
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
|
||
4kX18MMR34i8lC36SR5xBni8vHI= )
|
||
3600 NSEC x.w.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
|
||
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
|
||
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
|
||
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
|
||
s1InQ2UoIv6tJEaaKkP701j8OLA= )
|
||
x.w.example. 3600 IN MX 1 xx.example.
|
||
3600 RRSIG MX 5 3 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
|
||
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
|
||
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
|
||
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 39]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
|
||
3600 NSEC x.y.w.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 3 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
|
||
vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
|
||
mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
|
||
NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
|
||
IjgiM8PXkBQtxPq37wDKALkyn7Q= )
|
||
x.y.w.example. 3600 IN MX 1 xx.example.
|
||
3600 RRSIG MX 5 4 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
|
||
t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
|
||
q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
|
||
GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
|
||
+gLcMZBnHJ326nb/TOOmrqNmQQE= )
|
||
3600 NSEC xx.example. MX RRSIG NSEC
|
||
3600 RRSIG NSEC 5 4 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
|
||
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
|
||
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
|
||
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
|
||
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
|
||
xx.example. 3600 IN A 192.0.2.10
|
||
3600 RRSIG A 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
|
||
7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
|
||
0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
|
||
VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
|
||
kbIDV6GPPSZVusnZU6OMgdgzHV4= )
|
||
3600 HINFO "KLH-10" "TOPS-20"
|
||
3600 RRSIG HINFO 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
|
||
t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
|
||
BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
|
||
3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
|
||
RgNvuwbioFSEuv2pNlkq0goYxNY= )
|
||
3600 AAAA 2001:db8::f00:baaa
|
||
3600 RRSIG AAAA 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
|
||
aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
|
||
ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
|
||
U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 40]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
xS9cL2QgW7FChw16mzlkH6/vsfs= )
|
||
3600 NSEC example. A HINFO AAAA RRSIG NSEC
|
||
3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
|
||
9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
|
||
mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
|
||
asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
|
||
GghLahumFIpg4MO3LS/prgzVVWo= )
|
||
|
||
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 that 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.
|
||
|
||
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 20040509183619 (
|
||
20040409183619 38519 example.
|
||
Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
|
||
XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
|
||
H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 41]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
|
||
jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
|
||
|
||
;; Authority
|
||
example. 3600 NS ns1.example.
|
||
example. 3600 NS ns2.example.
|
||
example. 3600 RRSIG NS 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
|
||
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
|
||
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
|
||
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
|
||
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
|
||
|
||
;; Additional
|
||
xx.example. 3600 IN A 192.0.2.10
|
||
xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
|
||
7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
|
||
0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
|
||
VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
|
||
kbIDV6GPPSZVusnZU6OMgdgzHV4= )
|
||
xx.example. 3600 AAAA 2001:db8::f00:baaa
|
||
xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
|
||
aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
|
||
ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
|
||
U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
|
||
xS9cL2QgW7FChw16mzlkH6/vsfs= )
|
||
ns1.example. 3600 IN A 192.0.2.1
|
||
ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
|
||
5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
|
||
im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
|
||
+iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
|
||
v/iVXSYC0b7mPSU+EOlknFpVECs= )
|
||
ns2.example. 3600 IN A 192.0.2.2
|
||
ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
|
||
Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
|
||
yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
|
||
6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
|
||
rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 42]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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. (
|
||
1081539377
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
|
||
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
|
||
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
|
||
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
|
||
jV7j86HyQgM5e7+miRAz8V01b0I= )
|
||
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
|
||
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
|
||
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
|
||
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
|
||
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
|
||
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
|
||
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
|
||
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
|
||
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
|
||
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
|
||
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
|
||
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 43]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
B.3. No Data Error
|
||
|
||
A "no data" 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. (
|
||
1081539377
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
|
||
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
|
||
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
|
||
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
|
||
jV7j86HyQgM5e7+miRAz8V01b0I= )
|
||
ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
|
||
ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
|
||
1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
|
||
jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
|
||
ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
|
||
IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
|
||
|
||
;; 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
|
||
;;
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 44]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
;; 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 57855 5 1 (
|
||
B6DCD485719ADCA18E5F3D48A2331627FDD3
|
||
636B )
|
||
a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
|
||
oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
|
||
kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
|
||
EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
|
||
Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
|
||
|
||
;; Additional
|
||
ns1.a.example. 3600 IN A 192.0.2.5
|
||
ns2.a.example. 3600 IN A 192.0.2.6
|
||
|
||
B.5. Referral to Unsigned Zone
|
||
|
||
Referral to an unsigned zone. The NSEC RR proves that no DS RR for
|
||
this delegation exists in the parent zone.
|
||
|
||
;; Header: QR DO RCODE=0
|
||
;;
|
||
;; Question
|
||
mc.b.example. IN MX
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
b.example. 3600 IN NS ns1.b.example.
|
||
b.example. 3600 IN NS ns2.b.example.
|
||
b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
|
||
b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
|
||
9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
|
||
xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
|
||
0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
|
||
vhRXgWT7OuFXldoCG6TfVFMs9xE= )
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 45]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
;; 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 that 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 20040509183619 (
|
||
20040409183619 38519 example.
|
||
OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
|
||
f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
|
||
tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
|
||
TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
|
||
4kX18MMR34i8lC36SR5xBni8vHI= )
|
||
|
||
;; Authority
|
||
example. 3600 NS ns1.example.
|
||
example. 3600 NS ns2.example.
|
||
example. 3600 RRSIG NS 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
|
||
EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
|
||
4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
|
||
RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
|
||
0HjMeRaZB/FRPGfJPajngcq6Kwg= )
|
||
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
|
||
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
|
||
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
|
||
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
|
||
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
|
||
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
|
||
|
||
;; Additional
|
||
ai.example. 3600 IN A 192.0.2.9
|
||
ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 46]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
20040409183619 38519 example.
|
||
pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
|
||
ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
|
||
hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
|
||
ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
|
||
6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
|
||
ai.example. 3600 AAAA 2001:db8::f00:baa9
|
||
ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
|
||
kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
|
||
1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
|
||
cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
|
||
sZM6QjBBLmukH30+w1z3h8PUP2o= )
|
||
|
||
B.7. Wildcard No Data Error
|
||
|
||
A "no data" response for a name covered by a wildcard. The NSEC RRs
|
||
prove that the matching wildcard name does not have any RRs of the
|
||
requested type and that no closer match exists in the zone.
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
a.z.w.example. IN AAAA
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1081539377
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
|
||
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
|
||
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
|
||
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
|
||
jV7j86HyQgM5e7+miRAz8V01b0I= )
|
||
x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
|
||
x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 47]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
|
||
xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
|
||
a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
|
||
QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
|
||
*.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
|
||
*.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
|
||
HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
|
||
5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
|
||
91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
|
||
s1InQ2UoIv6tJEaaKkP701j8OLA= )
|
||
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
B.8. DS Child Zone No Data Error
|
||
|
||
A "no data" response for a QTYPE=DS query that was mistakenly sent to
|
||
a name server for the child zone.
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
example. IN DS
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1081539377
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
|
||
7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
|
||
vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
|
||
DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
|
||
jV7j86HyQgM5e7+miRAz8V01b0I= )
|
||
example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
|
||
example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
|
||
20040409183619 38519 example.
|
||
O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 48]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
|
||
Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
|
||
SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
|
||
jfFJ5arXf4nPxp/kEowGgBRzY/U= )
|
||
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
Appendix C. Authentication Examples
|
||
|
||
The examples in this section show how the response messages in
|
||
Appendix B are authenticated.
|
||
|
||
C.1. Authenticating an Answer
|
||
|
||
The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
|
||
The corresponding RRSIG indicates that the MX RRset was signed by an
|
||
"example" DNSKEY with algorithm 5 and key tag 38519. 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 that 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 configured root DNSKEY (or DS RR) and moves down the tree
|
||
to authenticate the desired "example" DNSKEY RR. Note that the
|
||
logical order is presented for clarity. An implementation may choose
|
||
to construct the authentication as referrals are received or 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 a configured DNSKEY RR for the
|
||
root zone (or a configured DS RR for the root zone). The resolver
|
||
checks whether this configured DNSKEY RR is present in the root
|
||
DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
|
||
DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
|
||
RRset, and whether the signature lifetime is valid. If all these
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 49]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
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 that the
|
||
resolver may have to query the root zone to obtain the root DNSKEY
|
||
RRset or "example" DS RRset.
|
||
|
||
Once the DS RRset has been authenticated using the root DNSKEY, the
|
||
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
|
||
RR that matches one of the authenticated "example" DS RRs. If such a
|
||
matching "example" DNSKEY is found, the resolver checks whether this
|
||
DNSKEY RR has signed the "example" DNSKEY RRset and the signature
|
||
lifetime is valid. If 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 38519. This
|
||
DNSKEY is used to authenticate the RRSIG included in the response.
|
||
If multiple "example" DNSKEY RRs match this algorithm and key tag,
|
||
then each DNSKEY RR is tried, and the answer is authenticated if any
|
||
of the matching DNSKEY RRs validate the signature as described above.
|
||
|
||
C.2. Name Error
|
||
|
||
The query in Appendix B.2 returned NSEC RRs that prove that 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 Appendix B.3 returned an NSEC RR that proves that 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 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 whether
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 50]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
|
||
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 Appendix B.5 returned a referral to an unsigned
|
||
"b.example." zone. The NSEC proves that no authentication leads from
|
||
"example" to "b.example", and the NSEC RR is authenticated in a
|
||
manner identical to that of the MX RRset discussed above.
|
||
|
||
C.6. Wildcard Expansion
|
||
|
||
The query in Appendix B.6 returned an answer that was produced as a
|
||
result of wildcard expansion. The answer section contains a wildcard
|
||
RRset expanded as it would be in a traditional DNS response, and the
|
||
corresponding RRSIG indicates that the expanded wildcard MX RRset was
|
||
signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
|
||
The RRSIG indicates that 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 that the answer
|
||
is the result of wildcard expansion, as 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 that 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 Appendix B.7 returned NSEC RRs that prove that 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 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 that the answer is from
|
||
the child . Queries for the "example" DS RRset should be sent to the
|
||
parent servers ("root" servers).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 51]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Roy Arends
|
||
Telematica Instituut
|
||
Brouwerijstraat 1
|
||
7523 XC Enschede
|
||
NL
|
||
|
||
EMail: roy.arends@telin.nl
|
||
|
||
|
||
Rob Austein
|
||
Internet Systems Consortium
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
USA
|
||
|
||
EMail: sra@isc.org
|
||
|
||
|
||
Matt Larson
|
||
VeriSign, Inc.
|
||
21345 Ridgetop Circle
|
||
Dulles, VA 20166-6503
|
||
USA
|
||
|
||
EMail: mlarson@verisign.com
|
||
|
||
|
||
Dan Massey
|
||
Colorado State University
|
||
Department of Computer Science
|
||
Fort Collins, CO 80523-1873
|
||
|
||
EMail: massey@cs.colostate.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. Standards Track [Page 52]
|
||
|
||
RFC 4035 DNSSEC Protocol Modifications March 2005
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights 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; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at ietf-
|
||
ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 53]
|
||
|