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.
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
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.
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.
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
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
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
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.
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