< draft-ietf-dnsext-dnssec-bis-updates-16.txt   draft-ietf-dnsext-dnssec-bis-updates-17.txt >
Network Working Group S. Weiler Network Working Group S. Weiler
Internet-Draft SPARTA, Inc. Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) VeriSign, Inc. (if approved) Verisign, Inc.
Intended status: Standards Track January 14, 2012 Intended status: Standards Track March 12, 2012
Expires: July 17, 2012 Expires: September 13, 2012
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-16 draft-ietf-dnsext-dnssec-bis-updates-17
Abstract Abstract
This document is a collection of technical clarifications to the This document is a collection of technical clarifications to the
DNSSECbis document set. It is meant to serve as a resource to DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata. implementors as well as a repository of DNSSECbis errata.
This document updates the core DNSSECbis documents (RFC4033, RFC4034, This document updates the core DNSSECbis documents (RFC4033, RFC4034,
and RFC4035) as well as the NSEC3 specification (RFC5155). It also and RFC4035) as well as the NSEC3 specification (RFC5155). It also
defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 17, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 4 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 4
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5
3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5
4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5
4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6
4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6
4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 6 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 6
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 7
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8
5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9
5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9
5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 9 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 10
5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10
5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 10 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11
5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 11 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 11
5.10.3. Preference Based on Source . . . . . . . . . . . . . 11 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12
5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 12 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12
5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 12 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 13 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 12
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 13 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 13
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix C. Discussion of Trust Anchor Preference Options . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 17 C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 19
C.3. Preference Based on Source . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Terminology 1. Introduction and Terminology
This document lists some additions, clarifications and corrections to This document lists some additions, clarifications and corrections to
the core DNSSECbis specification, as originally described in the core DNSSECbis specification, as originally described in
[RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
(See section Section 2 for more recent additions to that core (See section Section 2 for more recent additions to that core
document set.) document set.)
It is intended to serve as a resource for implementors and as a It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the repository of items that need to be addressed when advancing the
DNSSECbis documents from Proposed Standard to Draft Standard. DNSSECbis documents from Proposed Standard to Draft Standard.
1.1. Structure of this Document 1.1. Structure of this Document
The clarifications to DNSSECbis are sorted according to their The clarifications and changes to DNSSECbis are sorted according to
importance, starting with ones which could, if ignored, lead to their importance, starting with ones which could, if ignored, lead to
security problems and progressing down to clarifications that are security problems and progressing down to clarifications that are
expected to have little operational impact. expected to have little operational impact.
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
skipping to change at page 4, line 42 skipping to change at page 4, line 42
This section lists some documents that should be considered core This section lists some documents that should be considered core
DNSSEC protocol documents in addition to those originally specified DNSSEC protocol documents in addition to those originally specified
in Section 10 of [RFC4033]. in Section 10 of [RFC4033].
2.1. NSEC3 Support 2.1. NSEC3 Support
[RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
records for hashed denial of existence. Validator implementations records for hashed denial of existence. Validator implementations
are strongly encouraged to include support for NSEC3 because a number are strongly encouraged to include support for NSEC3 because a number
of highly visible zones are expected to use it. Validators that do of highly visible zones use it. Validators that do not support
not support validation of responses using NSEC3 will likely be validation of responses using NSEC3 will be hampered in validating
hampered in validating large portions of the DNS space. large portions of the DNS space.
[RFC5155] should be considered part of the DNS Security Document [RFC5155] should be considered part of the DNS Security Document
Family as described by [RFC4033], Section 10. Family as described by [RFC4033], Section 10.
Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
signal that a zone MAY be using NSEC3, rather than NSEC. The zone signal that a zone MAY be using NSEC3, rather than NSEC. The zone
MAY indeed be using either and validators supporting these algorithms MAY be using either and validators supporting these algorithms MUST
MUST support both NSEC3 and NSEC responses. support both NSEC3 and NSEC responses.
2.2. SHA-2 Support 2.2. SHA-2 Support
[RFC4509] describes the use of SHA-256 as a digest algorithm in [RFC4509] describes the use of SHA-256 as a digest algorithm in
Delegation Signer (DS) RRs. [RFC5702] describes the use of the Delegation Signer (DS) RRs. [RFC5702] describes the use of the
RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
Validator implementations are strongly encouraged to include support Validator implementations are strongly encouraged to include support
for these algorithms for DS, DNSKEY, and RRSIG records. for these algorithms for DS, DNSKEY, and RRSIG records.
Both [RFC4509] and [RFC5702] should also be considered part of the Both [RFC4509] and [RFC5702] should also be considered part of the
DNS Security Document Family as described by [RFC4033], Section 10. DNS Security Document Family as described by [RFC4033], Section 10.
3. Scaling Concerns 3. Scaling Concerns
3.1. Implement a BAD cache 3.1. Implement a BAD cache
Section 4.7 of RFC4035 permits security-aware resolvers to implement Section 4.7 of RFC4035 permits security-aware resolvers to implement
a BAD cache. Because of scaling concerns not discussed in this a BAD cache. Because of scaling concerns not discussed in this
document, that guidance has changed: security-aware resolvers SHOULD document, that guidance has changed: security-aware resolvers SHOULD
implement a BAD cache, as described in RFC4035. implement a BAD cache as described in RFC4035.
4. Security Concerns 4. Security Concerns
This section provides clarifications that, if overlooked, could lead This section provides clarifications that, if overlooked, could lead
to security issues. to security issues.
4.1. Clarifications on Non-Existence Proofs 4.1. Clarifications on Non-Existence Proofs
[RFC4035] Section 5.4 under-specifies the algorithm for checking non- [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
existence proofs. In particular, the algorithm as presented would existence proofs. In particular, the algorithm as presented would
skipping to change at page 6, line 34 skipping to change at page 6, line 34
the rules in [RFC4035] Section 5.4 (as clarified in this document). the rules in [RFC4035] Section 5.4 (as clarified in this document).
To be clear, a validator must not expect to receive all records at To be clear, a validator must not expect to receive all records at
the QNAME in response to QTYPE=*. the QNAME in response to QTYPE=*.
4.3. Check for CNAME 4.3. Check for CNAME
Section 5 of [RFC4035] says little about validating responses based Section 5 of [RFC4035] says little about validating responses based
on (or that should be based on) CNAMEs. When validating a NOERROR/ on (or that should be based on) CNAMEs. When validating a NOERROR/
NODATA response, validators MUST check the CNAME bit in the matching NODATA response, validators MUST check the CNAME bit in the matching
NSEC or NSEC3 RR's type bitmap in addition to the bit for the query NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
type. Without this check, an attacker could successfully transform a type.
positive CNAME response into a NOERROR/NODATA response.
Without this check, an attacker could successfully transform a
positive CNAME response into a NOERROR/NODATA response by (e.g.)
simply stripping the CNAME RRset from the response. A naive
validator would then note that the QTYPE was not present in the
matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
set, and thus the response should have been a positive CNAME
response.
4.4. Insecure Delegation Proofs 4.4. Insecure Delegation Proofs
[RFC4035] Section 5.2 specifies that a validator, when proving a [RFC4035] Section 5.2 specifies that a validator, when proving a
delegation is not secure, needs to check for the absence of the DS delegation is not secure, needs to check for the absence of the DS
and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also
needs to check for the presence of the NS bit in the matching NSEC MUST check for the presence of the NS bit in the matching NSEC (or
(or NSEC3) RR (proving that there is, indeed, a delegation), or NSEC3) RR (proving that there is, indeed, a delegation), or
alternately make sure that the delegation is covered by an NSEC3 RR alternately make sure that the delegation is covered by an NSEC3 RR
with the Opt-Out flag set. If this is not checked, spoofed unsigned with the Opt-Out flag set.
delegations might be used to claim that an existing signed record is
not signed. Without this check, an attacker could reuse an NSEC or NSEC3 RR
matching a non-delegation name to spoof an unsigned delegation at
that name. This would claim that an existing signed RRset (or set of
signed RRsets) is below an unsigned delegation, thus not signed and
vulnerable to further attack.
5. Interoperability Concerns 5. Interoperability Concerns
5.1. Errors in Canonical Form Type Code List 5.1. Errors in Canonical Form Type Code List
When canonicalizing DNS names (for both ordering and signing), DNS When canonicalizing DNS names (for both ordering and signing), DNS
names in the RDATA section of NSEC resource records are not names in the RDATA section of NSEC resource records are not
downcased. DNS names in the RDATA section of RRSIG resource records downcased. DNS names in the RDATA section of RRSIG resource records
are downcased. are downcased.
The guidance in the above paragraph differs from what has been The guidance in the above paragraph differs from what has been
published before but is consistent with current common practice. published before but is consistent with current common practice.
[RFC4034] Section 6.2 item 3 says that names in both of these RR [RFC4034] Section 6.2 item 3 says that names in both of these RR
skipping to change at page 7, line 41 skipping to change at page 7, line 50
The existing text says: The existing text says:
If the validator does not support any of the algorithms listed in If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as authenticated NSEC RRset proving that no DS RRset exists, as
described above. described above.
To paraphrase the above, when determining the security status of a In other words, when determining the security status of a zone, a
zone, a validator disregards any DS records listing unknown or validator disregards any authenticated DS records that specify
unsupported algorithms. If none are left, the zone is treated as if unknown or unsupported DNSKEY algorithms. If none are left, the zone
it were unsigned. is treated as if it were unsigned.
Modified to consider DS message digest algorithms, a validator also This document modifies the above text to additionally disregard
disregards any DS records using unknown or unsupported message digest authenticated DS records using unknown or unsupported message digest
algorithms. algorithms.
5.3. Private Algorithms 5.3. Private Algorithms
As discussed above, section 5.2 of [RFC4035] requires that validators As discussed above, Section 5.2 of [RFC4035] requires that validators
make decisions about the security status of zones based on the public make decisions about the security status of zones based on the public
key algorithms shown in the DS records for those zones. In the case key algorithms shown in the DS records for those zones. In the case
of private algorithms, as described in [RFC4034] Appendix A.1.1, the of private algorithms, as described in [RFC4034] Appendix A.1.1, the
eight-bit algorithm field in the DS RR is not conclusive about what eight-bit algorithm field in the DS RR is not conclusive about what
algorithm(s) is actually in use. algorithm(s) is actually in use.
If no private algorithms appear in the DS set or if any supported If no private algorithms appear in the DS RRset, or if any supported
algorithm appears in the DS set, no special processing will be algorithm appears in the DS RRset, no special processing is needed.
needed. In the remaining cases, the security status of the zone Furthermore, if the validator implementation does not support any
depends on whether or not the resolver supports any of the private private algorithms, or only supports private algorithms using an
algorithms in use (provided that these DS records use supported hash algorithm number not present in the DS RRset, no special processing
functions, as discussed in Section 5.2). In these cases, the is needed.
resolver MUST retrieve the corresponding DNSKEY for each private
algorithm DS record and examine the public key field to determine the In the remaining cases, the security status of the zone depends on
algorithm in use. The security-aware resolver MUST ensure that the whether or not the resolver supports any of the private algorithms in
hash of the DNSKEY RR's owner name and RDATA matches the digest in use (provided that these DS records use supported hash functions, as
the DS RR. If they do not match, and no other DS establishes that discussed in Section 5.2). In these cases, the resolver MUST
the zone is secure, the referral should be considered Bogus data, as retrieve the corresponding DNSKEY for each private algorithm DS
discussed in [RFC4035]. record and examine the public key field to determine the algorithm in
use. The security-aware resolver MUST ensure that the hash of the
DNSKEY RR's owner name and RDATA matches the digest in the DS RR as
described in Section 5.2 of [RFC4035], authenticating the DNSKEY. If
all of the retrieved and authenticated DNSKEY RRs use unknown or
unsupported private algorithms, then the zone is treated as if it
were unsigned.
Note that if none of the private algorithm DS RRs can be securely
matched to DNSKEY RRs and no other DS establishes that the zone is
secure, the referral should be considered Bogus data as discussed in
[RFC4035].
This clarification facilitates the broader use of private algorithms, This clarification facilitates the broader use of private algorithms,
as suggested by [RFC4955]. as suggested by [RFC4955].
5.4. Caution About Local Policy and Multiple RRSIGs 5.4. Caution About Local Policy and Multiple RRSIGs
When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
suggests that "the local resolver security policy determines whether suggests that "the local resolver security policy determines whether
the resolver also has to test these RRSIG RRs and how to resolve the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results." In most conflicts if these RRSIG RRs lead to differing results."
cases, a resolver would be well advised to accept any valid RRSIG as
sufficient. If the first RRSIG tested fails validation, a resolver This document specifies that a resolver SHOULD accept any valid RRSIG
would be well advised to try others, giving a successful validation as sufficient, and only determine that an RRset is Bogus if all
result if any can be validated and giving a failure only if all
RRSIGs fail validation. RRSIGs fail validation.
If a resolver adopts a more restrictive policy, there's a danger that If a resolver adopts a more restrictive policy, there's a danger that
properly-signed data might unnecessarily fail validation, perhaps properly-signed data might unnecessarily fail validation due to cache
because of cache timing issues. Furthermore, certain zone management timing issues. Furthermore, certain zone management techniques, like
techniques, like the Double Signature Zone-signing Key Rollover the Double Signature Zone-signing Key Rollover method described in
method described in section 4.2.1.2 of [RFC4641] might not work section 4.2.1.2 of [RFC4641], will not work reliably. Such a
reliably. resolver is also vulnerable to malicious insertion of gibberish
signatures.
5.5. Key Tag Calculation 5.5. Key Tag Calculation
[RFC4034] Appendix B.1 incorrectly defines the Key Tag field [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
calculation for algorithm 1. It correctly says that the Key Tag is calculation for algorithm 1. It correctly says that the Key Tag is
the most significant 16 of the least significant 24 bits of the the most significant 16 of the least significant 24 bits of the
public key modulus. However, [RFC4034] then goes on to incorrectly public key modulus. However, [RFC4034] then goes on to incorrectly
say that this is 4th to last and 3rd to last octets of the public key say that this is 4th to last and 3rd to last octets of the public key
modulus. It is, in fact, the 3rd to last and 2nd to last octets. modulus. It is, in fact, the 3rd to last and 2nd to last octets.
5.6. Setting the DO Bit on Replies 5.6. Setting the DO Bit on Replies
As stated in [RFC3225], the DO bit of the query MUST be copied in the As stated in [RFC3225], the DO bit of the query MUST be copied in the
response. At least one implementation has done something different, response. However, in order to interoperate with implementations
so it may be wise for resolvers to be liberal in what they accept. that ignore this rule on sending, resolvers MUST ignore the DO bit in
responses.
5.7. Setting the AD Bit on Queries 5.7. Setting the AD Bit on Queries
The use of the AD bit in the query was previously undefined. This The use of the AD bit in the query was previously undefined. This
document defines it as a signal indicating that the requester document defines it as a signal indicating that the requester
understands and is interested in the value of the AD bit in the understands and is interested in the value of the AD bit in the
response. This allows a requestor to indicate that it understands response. This allows a requestor to indicate that it understands
the AD bit without also requesting DNSSEC data via the DO bit. the AD bit without also requesting DNSSEC data via the DO bit.
5.8. Setting the AD Bit on Replies 5.8. Setting the AD Bit on Replies
Section 3.2.3 of [RFC4035] describes under which conditions a Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response. In validating resolver should set or clear the AD bit in a response. In
order to protect legacy stub resolvers and middleboxes, validating order to interoperate with legacy stub resolvers and middleboxes that
resolvers SHOULD only set the AD bit when a response both meets the neither understand nor ignore the AD bit, validating resolvers SHOULD
conditions listed in RFC 4035, section 3.2.3, and the request only set the AD bit when a response both meets the conditions listed
contained either a set DO bit or a set AD bit. in RFC 4035, section 3.2.3, and the request contained either a set DO
bit or a set AD bit.
5.9. Always set the CD bit on Queries 5.9. Always set the CD bit on Queries
This section does not apply to stub resolvers.
When processing a request with the CD bit set, a resolver SHOULD When processing a request with the CD bit set, a resolver SHOULD
attempt to return all responsive data, even data that has failed attempt to return all response data, even data that has failed DNSSEC
DNSSEC validation. RFC4035 section 3.2.2 requires a resolver validation. RFC4035 section 3.2.2 requires a resolver processing a
processing a request with the CD bit set to set the CD bit on its request with the CD bit set to set the CD bit on its upstream
upstream queries. queries.
Prevailing wisdom suggests that a validating resolver SHOULD set the This document further specifies that validating resolvers SHOULD set
CD bit on every upstream query regardless of whether the CD bit was the CD bit on every upstream query. This is regardless of whether
set on the incoming query or whether it has a trust anchor at or the CD bit was set on the incoming query or whether it has a trust
above the QNAME. In other words, a validating resolver should anchor at or above the QNAME.
attempt to retrieve all possible data -- even that which it can not
validate itself -- on the grounds that a later query might come with
the CD bit set.
RFC4035 is ambiguous about what to do when a cached response was [RFC4035] is ambiguous about what to do when a cached response was
obtained with the CD bit not set, a case that only arises when the obtained with the CD bit unset, a case that only arises when the
resolver chooses not to set the CD bit on all upstream queries, as resolver chooses not to set the CD bit on all upstream queries, as
suggested above. In the typical case, no new query is required, nor specified above. In the typical case, no new query is required, nor
does the cache need to track the state of the CD bit used to make a does the cache need to track the state of the CD bit used to make a
given query. The problem arises when the cached response is a server given query. The problem arises when the cached response is a server
failure (RCODE 2), which may indicate that the requested data failed failure (RCODE 2), which may indicate that the requested data failed
DNSSEC validation at an upstream validating resolver. (RFC2308 DNSSEC validation at an upstream validating resolver. (RFC2308
permits caching of server failures for up to five minutes.) In these permits caching of server failures for up to five minutes.) In these
cases, a new query with the CD bit set is required. cases, a new query with the CD bit set is required.
Appendix B discusses more of the logic behind the recommendation Appendix B discusses more of the logic behind the recommendation
presented in this section. presented in this section.
skipping to change at page 10, line 30 skipping to change at page 10, line 45
A DNSSEC validator may be configured such that, for a given response, A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of more than one trust anchor could be used to validate the chain of
trust to the response zone. For example, imagine a validator trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example." configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply. "www.sub.zone.example.", either trust anchor could apply.
When presented with this situation, DNSSEC validators have a choice When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of of which trust anchor(s) to use. Which to use is a matter of
implementation choice. It is possible and perhaps advisable to implementation choice. Appendix C discusses several possible
expose the choice of policy as a configuration option. The rest of algorithms.
this section discusses some possible policies. As a default, we
suggest that validators implement the "Accept Any Success" policy
described below in Section 5.10.2 while exposing other policies as
configuration options.
5.10.1. Closest Encloser
One policy is to choose the trust anchor closest to the QNAME of the
response. In our example, that would be the "zone.example." trust
anchor.
This policy has the advantage of allowing the operator to trivially
override a parent zone's trust anchor with one that the operator can
validate in a stronger way, perhaps because the resolver operator is
affiliated with the zone in question. This policy also minimizes the
number of public key operations needed, which may be of benefit in
resource-constrained environments.
This policy has the disadvantage of possibly giving the user some
unexpected and unnecessary validation failures when sub-zone trust
anchors are neglected. As a concrete example, consider a validator
that configured a trust anchor for "zone.example." in 2009 and one
for "example." in 2011. In 2012, "zone.example." rolls its KSK and
updates its DS records, but the validator operator doesn't update its
trust anchor. With the "closest encloser" policy, the validator gets
validation failures.
5.10.2. Accept Any Success
Another policy is to try all applicable trust anchors until one gives
a validation result of Secure, in which case the final validation
result is Secure. If and only if all applicable trust anchors give a
result of Insecure, the final validation result is Insecure. If one
or more trust anchors lead to a Bogus result and there is no Secure
result, then the final validation result is Bogus.
This has the advantage of causing the fewer validation failures,
which may deliver a better user experience. If one trust anchor is
out of date (as in our above example), the user may still be able to
get a Secure validation result (and see DNS responses).
This policy has the disadvantage of making the validator subject to
compromise of the weakest of these trust anchors while making its
relatively painless to keep old trust anchors configured in
perpetuity.
5.10.3. Preference Based on Source
When the trust anchors have come from different sources (e.g.
automated updates ([RFC5011]), one or more DLV registries
([RFC5074]), and manually configured), a validator may wish to choose
between them based on the perceived reliability of those sources.
The order of precedence might be exposed as a configuration option.
For example, a validator might choose to prefer trust anchors found
in a DLV registry over those manually configured on the theory that
the manually configured ones will not be as aggressively maintained.
Conversely, a validator might choose to prefer manually configured It is possible and advisable to expose the choice of policy as a
trust anchors over those obtained from a DLV registry on the theory configuration option. As a default, it is suggested that validators
that the manually configured ones have been more carefully implement the "Accept Any Success" policy described in Appendix C.2
authenticated. while exposing other policies as configuration options.
Or the validator might do something more complicated: prefer a sub- The "Accept Any Success" policy is to try all applicable trust
set of manually configured trust anchors (based on a configuration anchors until one gives a validation result of Secure, in which case
option), then trust anchors that have been updated using the RFC5011 the final validation result is Secure. If and only if all applicable
mechanism, then trust anchors from one DLV registry, then trust trust anchors give a result of Insecure, the final validation result
anchors from a different DLV registry, then the rest of the manually is Insecure. If one or more trust anchors lead to a Bogus result and
configured trust anchors. there is no Secure result, then the final validation result is Bogus.
5.11. Mandatory Algorithm Rules 5.11. Mandatory Algorithm Rules
The last paragraph of RFC4035 Section 2.2 includes rules for which The last paragraph of RFC4035 Section 2.2 includes rules describing
algorithms must be used to sign a zone. Since these rules have been which algorithms must be used to sign a zone. Since these rules have
confusing, we restate them in different language here: been confusing, they are restated using different language here:
The DS RRset and DNSKEY RRset are used to signal which algorithms The DS RRset and DNSKEY RRset are used to signal which algorithms
are used to sign a zone. The pressence of an algorithm in a are used to sign a zone. The presence of an algorithm in either a
zone's DS or DNSKEY RRset set signals that that algorithm is used zone's DS or DNSKEY RRset signals that that algorithm is used to
to sign the entire zone. sign the entire zone.
A signed zone MUST include a DNSKEY for each algorithm present in A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key) zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset. It is possible to add algorithms at present in the DNSKEY RRset. It is possible to add algorithms at
the DNSKEY that aren't in the DS record, but not vice-versa. If the DNSKEY that aren't in the DS record, but not vice-versa. If
more than one key of the same algorithm is in the DNSKEY RRset, it more than one key of the same algorithm is in the DNSKEY RRset, it
is sufficient to sign each RRset with any subset of these DNSKEYs. is sufficient to sign each RRset with any subset of these DNSKEYs.
It is acceptable to sign some RRsets with one subset of keys (or It is acceptable to sign some RRsets with one subset of keys (or
key) and other RRsets with a different subset, so long as at least key) and other RRsets with a different subset, so long as at least
one DNSKEY of each algorithm is used to sign each RRset. one DNSKEY of each algorithm is used to sign each RRset.
Likewise, if there are DS records for multiple keys of the same Likewise, if there are DS records for multiple keys of the same
algorithm, any subset of those may appear in the DNSKEY RRset. algorithm, any subset of those may appear in the DNSKEY RRset.
Lastly, note that this a requirement at the server side, not the Lastly, note that this a requirement at the server side, not the
client side. Validators SHOULD accept any single valid path. They client side. Validators SHOULD accept any single valid path. They
SHOULD NOT insist that all algorithms signalled in the DS RRset work, SHOULD NOT insist that all algorithms signaled in the DS RRset work,
and they MUST NOT insist that all algorithms signalled in the DNSKEY and they MUST NOT insist that all algorithms signaled in the DNSKEY
RRset work. A validator MAY have a configuration option to perform a RRset work. A validator MAY have a configuration option to perform a
signature completeness test to support troubleshooting. signature completeness test to support troubleshooting.
5.12. Expect Extra Signatures From Strange Keys 5.12. Ignore Extra Signatures From Unknown Keys
Validating resolvers should not be surprised to find RRSIGs in a zone Validating resolvers MUST disregard RRSIGs in a zone that do not
that do not (currently) have a corresponding DNSKEY in the zone. (currently) have a corresponding DNSKEY in the zone. Similarly, a
Likewise, a validating resolver should not be surprised to find validating resolver MUST disregard RRSIGs with algorithm types that
RRSIGs with algorithm types that don't exist in the DNSKEY RRset or don't exist in the DNSKEY RRset.
DNSKEYs with algorithm types that don't appear in the zone's DS
RRset.
Good key rollover and algorithm rollover practices, as discussed in Good key rollover and algorithm rollover practices, as discussed in
RFC4641 and its successor documents and as suggested by the rules in RFC4641 and its successor documents and as suggested by the rules in
the previous section, may require that such RRSIGs be present in a the previous section, may require that such RRSIGs be present in a
zone. zone.
6. Minor Corrections and Clarifications 6. Minor Corrections and Clarifications
6.1. Finding Zone Cuts 6.1. Finding Zone Cuts
skipping to change at page 13, line 22 skipping to change at page 12, line 23
As explained in Section 3.1.4.1 of [RFC4035], security-aware name As explained in Section 3.1.4.1 of [RFC4035], security-aware name
servers need to apply special processing rules to handle the DS RR, servers need to apply special processing rules to handle the DS RR,
and in some situations the resolver may also need to apply special 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 rules to locate the name servers for the parent zone if the resolver
does not already have the parent's NS RRset. Section 4.2 of does not already have the parent's NS RRset. Section 4.2 of
[RFC4035] specifies a mechanism for doing that. [RFC4035] specifies a mechanism for doing that.
6.2. Clarifications on DNSKEY Usage 6.2. Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing this It is possible to use different DNSKEYs to sign different subsets of
RRset" have occasionally arisen. a zone, constrained only by the rules in Section 5.11. It is even
possible to use a different DNSKEY for each RRset in a zone, subject
The short answer is "yes, absolutely". You can even use a different only to practical limits on the size of the DNSKEY RRset and the
DNSKEY for each RRset in a zone, subject only to practical limits on above rules. However, be aware that there is no way to tell
the size of the DNSKEY RRset. However, be aware that there is no way resolvers what a particular DNSKEY is supposed to be used for -- any
to tell resolvers what a particularly DNSKEY is supposed to be used DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to any RRset in the zone. For example, if a weaker or less trusted
authenticate any RRset in the zone. For example, if a weaker or less DNSKEY is being used to authenticate NSEC RRsets or all dynamically
trusted DNSKEY is being used to authenticate NSEC RRsets or all updated records, that same DNSKEY can also be used to sign any other
dynamically updated records, that same DNSKEY can also be used to RRsets from the zone.
sign any other RRsets from the zone.
Furthermore, note that the SEP bit setting has no effect on how a Furthermore, note that the SEP bit setting has no effect on how a
DNSKEY may be used -- the validation process is specifically DNSKEY may be used -- the validation process is specifically
prohibited from using that bit by [RFC4034] section 2.1.2. It is prohibited from using that bit by [RFC4034] section 2.1.2. It is
possible to use a DNSKEY without the SEP bit set as the sole secure possible to use a DNSKEY without the SEP bit set as the sole secure
entry point to the zone, yet use a DNSKEY with the SEP bit set to entry point to the zone, yet use a DNSKEY with the SEP bit set to
sign all RRsets in the zone (other than the DNSKEY RRset). It is sign all RRsets in the zone (other than the DNSKEY RRset). It is
also possible to use a single DNSKEY, with or without the SEP bit also possible to use a single DNSKEY, with or without the SEP bit
set, to sign the entire zone, including the DNSKEY RRset itself. set, to sign the entire zone, including the DNSKEY RRset itself.
skipping to change at page 14, line 36 skipping to change at page 13, line 38
RFC 5155 3.2.1 should be: RFC 5155 3.2.1 should be:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
7. IANA Considerations 7. IANA Considerations
This document specifies no IANA Actions. This document specifies no IANA Actions.
8. Security Considerations 8. Security Considerations
This document adds two cryptographic features to the core DNSSEC This document adds SHA-2 and NSEC3 support to the core DNSSEC
protocol. Security considerations for those features are discussed protocol. Security considerations for those features are discussed
in the documents defining them. Additionally, this document in the documents defining them. Additionally, this document
addresses some ambiguities and omissions in the core DNSSEC documents addresses some ambiguities and omissions in the core DNSSEC documents
that, if not recognized and addressed in implementations, could lead that, if not recognized and addressed in implementations, could lead
to security failures. In particular, the validation algorithm to security failures. In particular, the validation algorithm
clarifications in Section 4 are critical for preserving the security clarifications in Section 4 are critical for preserving the security
properties DNSSEC offers. Furthermore, failure to address some of properties DNSSEC offers. Furthermore, failure to address some of
the interoperability concerns in Section 5 could limit the ability to the interoperability concerns in Section 5 could limit the ability to
later change or expand DNSSEC, including adding new algorithms. later change or expand DNSSEC, including adding new algorithms.
skipping to change at page 17, line 8 skipping to change at page 16, line 8
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
and Scott Rose for their substantive comments on the text of this and Scott Rose for their substantive comments on the text of this
document. document.
Appendix B. Discussion of Setting the CD Bit Appendix B. Discussion of Setting the CD Bit
RFC 4035 may be read as relying on the implicit assumption that there RFC 4035 may be read as relying on the implicit assumption that there
is (at least usually) at most one validating system between the stub is at most one validating system between the stub resolver and the
resolver and the authoritative server for a given zone. It is authoritative server for a given zone. It is entirely possible,
entirely possible, however, for more than one validator to stand however, for more than one validator to exist between a stub resolver
between a stub resolver and an authoritative server. If these and an authoritative server. If these different validators have
different validators have disjoint trust anchors configured, then it disjoint trust anchors configured, then it is possible that each
will be possible that each would be able to validate some portion of would be able to validate some portion of the DNS tree but neither is
the DNS tree but neither will be able to validate all of it. able to validate all of it. Accordingly, it might be argued that it
Accordingly, it might be argued that it is desirable not to set the is desirable not to set the CD bit on upstream queries, because that
CD bit on upstream queries, because that will allow for maximal allows for maximal validation.
validation.
In Section 5.9 of the present memo, it is recommended to set the CD In section Section 5.9 of this document, it is recommended to set the
bit on an upstream query even when the incoming query arrives with CD bit on an upstream query even when the incoming query arrives with
CD=0. This is for two reasons: it encourages a more predictable CD=0. This is for two reasons: it encourages a more predictable
validation experience (because it means that one validator is always validation experience as only one validator is always doing the
doing the validation), and it ensures that all DNSSEC data that validation, and it ensures that all DNSSEC data that exists may be
exists may be available from the local cache should a query with CD=1 available from the local cache should a query with CD=1 arrive.
arrive.
As a matter of policy, it is possible to set the CD bit differently As a matter of policy, it is possible to set the CD bit differently
than suggested in Section 5.9. A different choice will, of course, than suggested in Section 5.9. A different choice will, of course,
not always yield the benefits listed above. It is beyond the scope not always yield the benefits listed above. It is beyond the scope
of this memo to outline all of the considerations and counter of this document to outline all of the considerations and counter
considerations for all possible policies. Nevertheless, it is considerations for all possible policies. Nevertheless, it is
possible to describe three approaches and their underlying philosophy possible to describe three approaches and their underlying philosophy
of operation. These are laid out in the tables below. of operation. These are laid out in the tables below.
The table that describes each model has five columns. The first The table that describes each model has five columns. The first
column indicates the value of the CD bit that the resolver receives column indicates the value of the CD bit that the resolver receives
(for instance, on the name server side in an iterative resolver, or (for instance, on the name server side in an iterative resolver, or
as local policy or from the API in the case of a stub). The next as local policy or from the API in the case of a stub). The second
column indicates whether the query needs to be forwarded for column indicates whether the query needs to be forwarded for
resolution (F) or can be satisfied from a local cache (C). The next resolution (F) or can be satisfied from a local cache (C). The third
column is a line number, so that it can be referred to later in the column is a line number, so that it can be referred to later in the
table. The next column indicates any relevant conditions at the table. The fourth column indicates any relevant conditions at the
resolver: whether the resolver has a covering trust anchor and so on resolver: whether the resolver has a covering trust anchor and so on.
(if there are no parameters here, the column is empty). The final If there are no parameters here, the column is empty. The fifth and
column indicates what the resolver does. final column indicates what action the resolver takes.
The tables differentiate between "cached data" and "cached RCODE=2". The tables differentiate between "cached data" and "cached RCODE=2".
This is a shorthand; the point is that one has to treat RCODE=2 as This is a shorthand; the point is that one has to treat RCODE=2 as
special, because it might indicate a validation failure somewhere special, because it might indicate a validation failure somewhere
upstream. The distinction is really between "cached RCODE=2" and upstream. The distinction is really between "cached RCODE=2" and
"cached everything else". "cached everything else".
The tables are probably easiest to think of in terms of describing The tables are probably easiest to think of in terms of describing
what happens when a stub resolver sends a query to an intermediate what happens when a stub resolver sends a query to an intermediate
resolver, but they are perfectly general and can be applied to any resolver, but they are perfectly general and can be applied to any
validating resolver. validating resolver.
Model 1: "always set" Model 1: "always set"
This model is so named because the validating resolver sets the CD This model is so named because the validating resolver sets the CD
bit on queries it makes reegardless of whether it has a covering bit on queries it makes regardless of whether it has a covering trust
trust anchor for the query. It is the model recommended in anchor for the query. The general philosophy represented by this
Section 5.9 of this memo. The general philosophy represented by this
table is that only one resolver should be responsible for validation table is that only one resolver should be responsible for validation
irrespective of the possibility that an upstream resolver may be irrespective of the possibility that an upstream resolver may be
present and with TAs that cover different or additional QNAMEs. present with trust anchors that cover different or additional QNAMEs.
It is the model recommended in Section 5.9 of this document.
CD F/C line conditions action CD F/C line conditions action
==================================================================== ====================================================================
1 F A1 Set CD=1 on upstream query 1 F A1 Set CD=1 on upstream query
0 F A2 Set CD=1 on upstream query 0 F A2 Set CD=1 on upstream query
1 C A3 Return the cache contents 1 C A3 Return the cache contents
(data or RCODE=2) (data or RCODE=2)
0 C A4 no covering TA Return cache contents 0 C A4 no covering TA Return cache contents
(data or RCODE=2) (data or RCODE=2)
0 C A5 covering TA Validate cached result and 0 C A5 covering TA Validate cached result and
return it. return it.
Model 2: "never set when receiving CD=0" Model 2: "never set when receiving CD=0"
This model is so named because it sets CD=0 on upstream queries for This model is so named because it sets CD=0 on upstream queries for
all received CD=0 queries even if it has a covering trust anchor. all received CD=0 queries even if it has a covering trust anchor.
The general philosophy represented by this table is that more than The general philosophy represented by this table is that more than
one resolver may take responsibility for validating a QNAME and that one resolver may take responsibility for validating a QNAME and that
a validation failure for a QNAME by any resolver in the chain is a a validation failure for a QNAME by any resolver in the chain is a
validation failure for the query. Using this model instead of model validation failure for the query. Using this model is NOT
1 is NOT RECOMMENDED. RECOMMENDED.
CD F/C line conditions action CD F/C line conditions action
==================================================================== ====================================================================
1 F N1 Set CD=1 on upstream query 1 F N1 Set CD=1 on upstream query
0 F N2 Set CD=0 on upstream query 0 F N2 Set CD=0 on upstream query
1 C N3 cached data Return cached data 1 C N3 cached data Return cached data
1 C N4 cached RCODE=2 Treat as line N1 1 C N4 cached RCODE=2 Treat as line N1
0 C N5 no covering TA Return cache contents 0 C N5 no covering TA Return cache contents
(data or RCODE=2) (data or RCODE=2)
0 C N6 covering TA & Treat as line N2 0 C N6 covering TA & Treat as line N2
cached data was cached data was
generated with CD=1 generated with CD=1
0 C N7 covering TA & Validate and return 0 C N7 covering TA & Validate and return
cached data was cached data was
generated with CD=0 generated with CD=0
Model 3: "sometimes set" Model 3: "sometimes set"
This model is so named because it sets the CD bit on upstream queries This model is so named because it sets the CD bit on upstream queries
triggered by received CD=0 queries based on whether the validator has triggered by received CD=0 queries based on whether the validator has
a TA configured that covers the query. If there is no covering TA, a trust anchor configured that covers the query. If there is no
the resolver clears the CD bit in the upstream query. If there is a covering trust anchor, the resolver clears the CD bit in the upstream
covering TA, it sets CD=1 and performs validation itself. The query. If there is a covering trust anchor, the resolver sets CD=1
general philosophy represented by this table is that a resolver and performs validation itself. The general philosophy represented
should try and validate QNAMEs for which is has trust anchors and by this table is that a resolver should try and validate QNAMEs for
should not preclude validation by other resolvers for QNAMEs for which is has trust anchors and should not preclude validation by
which it does not have covering trust anchors. Using this model other resolvers for QNAMEs for which it does not have covering trust
instead of model 1 is NOT RECOMMENDED. anchors. Using this model is NOT RECOMMENDED.
CD F/C line conditions action CD F/C line conditions action
==================================================================== ====================================================================
1 F S1 Set CD=1 on upstream query 1 F S1 Set CD=1 on upstream query
0 F S2 covering TA Set CD=1 on upstream query 0 F S2 covering TA Set CD=1 on upstream query
0 F S3 no covering TA Set CD=0 on upstream query 0 F S3 no covering TA Set CD=0 on upstream query
1 C S4 cached data Return cached data 1 C S4 cached data Return cached data
1 C S5 cached RCODE=2 Treat as line S1 1 C S5 cached RCODE=2 Treat as line S1
0 C S6 cached data was Return cache contents 0 C S6 cached data was Return cache contents
generated with generated with
CD=0 CD=0
0 C S7 cached data was Validate & return cache 0 C S7 cached data was Validate & return cache
generated with contents generated with contents
CD=1 & CD=1 &
covering TA covering TA
0 C S8 cached RCODE=2 Return cache contents 0 C S8 cached RCODE=2 Return cache contents
0 C S9 cached data Treat as line S3 0 C S9 cached data Treat as line S3
was generated was generated
with CD=1 & with CD=1 &
no covering no covering
TA TA
Appendix C. Discussion of Trust Anchor Preference Options
This section presents several different policies for validating
resolvers to use when they have a choice of trust anchors available
for validating a given answer.
C.1. Closest Encloser
One policy is to choose the trust anchor closest to the QNAME of the
response. For example, consider a validator configured with trust
anchors for "example." and "zone.example." When asked to validate a
response for "www.sub.zone.example.", a validator using the "Closest
Encloser" policy would choose the "zone.example." trust anchor.
This policy has the advantage of allowing the operator to trivially
override a parent zone's trust anchor with one that the operator can
validate in a stronger way, perhaps because the resolver operator is
affiliated with the zone in question. This policy also minimizes the
number of public key operations needed, which is of benefit in
resource-constrained environments.
This policy has the disadvantage of giving the user some unexpected
and unnecessary validation failures when sub-zone trust anchors are
neglected. As a concrete example, consider a validator that
configured a trust anchor for "zone.example." in 2009 and one for
"example." in 2011. In 2012, "zone.example." rolls its KSK and
updates its DS records, but the validator operator doesn't update its
trust anchor. With the "closest encloser" policy, the validator gets
validation failures.
C.2. Accept Any Success
Another policy is to try all applicable trust anchors until one gives
a validation result of Secure, in which case the final validation
result is Secure. If and only if all applicable trust anchors give a
result of Insecure, the final validation result is Insecure. If one
or more trust anchors lead to a Bogus result and there is no Secure
result, then the final validation result is Bogus.
This has the advantage of causing the fewest validation failures,
which may deliver a better user experience. If one trust anchor is
out of date (as in our above example), the user may still be able to
get a Secure validation result (and see DNS responses).
This policy has the disadvantage of making the validator subject to
the compromise of the weakest of these trust anchors while making it
relatively painless to keep old trust anchors configured in
perpetuity.
C.3. Preference Based on Source
When the trust anchors have come from different sources (e.g.
automated updates ([RFC5011]), one or more DLV registries
([RFC5074]), and manually configured), a validator may wish to choose
between them based on the perceived reliability of those sources.
The order of precedence might be exposed as a configuration option.
For example, a validator might choose to prefer trust anchors found
in a DLV registry over those manually configured on the theory that
the manually configured ones will not be as aggressively maintained.
Conversely, a validator might choose to prefer manually configured
trust anchors over those obtained from a DLV registry on the theory
that the manually configured ones have been more carefully
authenticated.
Or the validator might do something more complex: prefer a sub-set of
manually configured trust anchors (based on a configuration option),
then trust anchors that have been updated using the RFC5011
mechanism, then trust anchors from one DLV registry, then trust
anchors from a different DLV registry, then the rest of the manually
configured trust anchors.
Authors' Addresses Authors' Addresses
Samuel Weiler Samuel Weiler
SPARTA, Inc. SPARTA, Inc.
7110 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, Maryland 21046 Columbia, Maryland 21046
US US
Email: weiler@tislabs.com Email: weiler@tislabs.com
David Blacka David Blacka
VeriSign, Inc. Verisign, Inc.
21345 Ridgetop Circle 12061 Bluemont Way
Dulles, VA 20166 Reston, VA 20190
US US
Email: davidb@verisign.com Email: davidb@verisign.com
 End of changes. 53 change blocks. 
229 lines changed or deleted 265 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/