draft-ietf-dnsext-dnssec-bis-updates-11.txt   draft-ietf-dnsext-dnssec-bis-updates-12.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 March 27, 2010 Intended status: Standards Track November 10, 2010
Expires: September 28, 2010 Expires: May 14, 2011
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-11 draft-ietf-dnsext-dnssec-bis-updates-12
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 14, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3
1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4
3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4
4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5
4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 7 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 8 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8 5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8
5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9
5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 10 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
5.10.3. Preference Based on Source . . . . . . . . . . . . . 10 5.10.3. Preference Based on Source . . . . . . . . . . . . . 10
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 11 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11
6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 12 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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.)
skipping to change at page 5, line 19 skipping to change at page 4, line 19
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
This is a placeholder section. New text is forthcoming with general
themes of "please play well with others", "don't flood authoritative
servers with queries" and "don't try TOO hard to recover from
validation failures".
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 the concerns outlined above, that guidance a BAD cache. Because of scaling concerns not discussed in this
has changed: security-aware resolvers SHOULD implement a BAD cache, document, that guidance has changed: security-aware resolvers SHOULD
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 10, line 6 skipping to change at page 8, line 47
The guidance in RFC4035 is ambiguous about what to do when a cached The guidance in RFC4035 is ambiguous about what to do when a cached
response was obtained with the CD bit not set. In the typical case, response was obtained with the CD bit not set. In the typical case,
no new query is required, nor does the cache need to track the state no new query is required, nor does the cache need to track the state
of the CD bit used to make a given query. The problem arises when of the CD bit used to make a given query. The problem arises when
the cached response is a server failure (RCODE 2), which may indicate the cached response is a server failure (RCODE 2), which may indicate
that the requested data failed DNSSEC validation at an upstream that the requested data failed DNSSEC validation at an upstream
validating resolver. (RFC2308 permits caching of server failures for validating resolver. (RFC2308 permits caching of server failures for
up to five minutes.) In these cases, a new query with the CD bit set up to five minutes.) In these cases, a new query with the CD bit set
is required. is required.
For efficiency, a validator may wish to set the CD bit on all For efficiency, a validator SHOULD set the CD bit on upstream queries
upstream queries when it has a trust anchor at or above the QNAME when it has a trust anchor at or above the QNAME (and thus can
(and thus can reasonably expect to be able to validate the response). reasonably expect to be able to validate the response).
5.10. Nested Trust Anchors 5.10. Nested Trust Anchors
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.
 End of changes. 17 change blocks. 
35 lines changed or deleted 24 lines changed or added

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