draft-ietf-dnsext-dnssec-bis-updates-14.txt   draft-ietf-dnsext-dnssec-bis-updates-15.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 July 26, 2011 Intended status: Standards Track January 13, 2012
Expires: January 27, 2012 Expires: July 16, 2012
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-14 draft-ietf-dnsext-dnssec-bis-updates-15
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,
and RFC4035) as well as the NSEC3 specification (RFC5155). It also
defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). 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 January 27, 2012. This Internet-Draft will expire on July 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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 Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 1.1. Structure of this Document . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 4
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5
3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5
4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5
4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6
4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6
4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 6
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 7
5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 8
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9
5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9
5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 8 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 9
5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10
5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 10
5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 11
5.10.3. Preference Based on Source . . . . . . . . . . . . . 10 5.10.3. Preference Based on Source . . . . . . . . . . . . . 11
5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 10 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11
5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 11 5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 12
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 11 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 11 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 13
6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 12 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 12 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 3, line 27 skipping to change at page 4, line 27
1.1. Structure of this Document 1.1. Structure of this Document
The clarifications to DNSSECbis are sorted according to their The clarifications to DNSSECbis are sorted according to their
importance, starting with ones which could, if ignored, lead to 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Important Additions to DNSSSECbis 2. Important Additions to DNSSSECbis
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
skipping to change at page 9, line 8 skipping to change at page 10, line 8
obtained with the CD bit not set, a case that only arises when the obtained with the CD bit not set, 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 suggested 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
presented in this section.
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.
When presented with this situation, DNSSEC validators have a choice When presented with this situation, DNSSEC validators have a choice
skipping to change at page 15, line 36 skipping to change at page 16, line 44
The CD bit logic was analyzed in depth by David Blacka, Olafur The CD bit logic was analyzed in depth by David Blacka, Olafur
Gudmundsson, Mike St. Johns, and Andrew Sullivan. Gudmundsson, Mike St. Johns, and Andrew Sullivan.
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
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
resolver and the authoritative server for a given zone. It is
entirely possible, however, for more than one validator to stand
between a stub resolver and an authoritative server. If these
different validators have disjoint trust anchors configured, then it
will be possible that each would be able to validate some portion of
the DNS tree but neither will be able to validate all of it.
Accordingly, it might be argued that it is desirable not to set the
CD bit on upstream queries, because that will allow for maximal
validation.
In Section 5.9 of the present memo, it is recommended to set the 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
validation experience (because it means that one validator is always
doing the validation), and it ensures that all DNSSEC data that
exists may be available from the local cache should a query with CD=1
arrive.
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,
not always yield the benefits listed above. It is beyond the scope
of this memo to outline all of the considerations and counter
considerations for all possible policies. Nevertheless, it is
possible to describe three approaches and their underlying philosophy
of operation. These are laid out in the tables below.
The table that describes each model has five columns. The first
column indicates the value of the CD bit that the resolver receives
(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
column indicates whether the query needs to be forwarded for
resolution (F) or can be satisfied from a local cache (C). The next
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
resolver: whether the resolver has a covering trust anchor and so on
(if there are no parameters here, the column is empty). The final
column indicates what the resolver does.
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
special, because it might indicate a validation failure somewhere
upstream. The distinction is really between "cached RCODE=2" and
"cached everything else".
The tables are probably easiest to think of in terms of describing
what happens when a stub resolver sends a query to an intermediate
resolver, but they are perfectly general and can be applied to any
validating resolver.
Model 1: "always set"
This model is so named because the validating resolver sets the CD
bit on queries it makes reegardless of whether it has a covering
trust anchor for the query. It is the model recommended in
Section 5.9 of this memo. The general philosophy represented by this
table is that only one resolver should be responsible for validation
irrespective of the possibility that an upstream resolver may be
present and with TAs that cover different or additional QNAMEs.
CD F/C line conditions action
====================================================================
1 F A1 Set CD=1 on upstream query
0 F A2 Set CD=1 on upstream query
1 C A3 Return the cache contents
(data or RCODE=2)
0 C A4 no covering TA Return cache contents
(data or RCODE=2)
0 C A5 covering TA Validate cached result and
return it.
Model 2: "never set when receiving CD=0"
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.
The general philosophy represented by this table is that more than
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
validation failure for the query. Using this model instead of model
1 is NOT RECOMMENDED.
CD F/C line conditions action
====================================================================
1 F N1 Set CD=1 on upstream query
0 F N2 Set CD=0 on upstream query
1 C N3 cached data Return cached data
1 C N4 cached RCODE=2 Treat as line N1
0 C N5 no covering TA Return cache contents
(data or RCODE=2)
0 C N6 covering TA & Treat as line N2
cached data was
generated with CD=1
0 C N7 covering TA & Validate and return
cached data was
generated with CD=0
Model 3: "sometimes set"
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
a TA configured that covers the query. If there is no covering TA,
the resolver clears the CD bit in the upstream query. If there is a
covering TA, it sets CD=1 and performs validation itself. The
general philosophy represented by this table is that a resolver
should try and validate QNAMEs for which is has trust anchors and
should not preclude validation by other resolvers for QNAMEs for
which it does not have covering trust anchors. Using this model
instead of model 1 is NOT RECOMMENDED.
CD F/C line conditions action
====================================================================
1 F S1 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
1 C S4 cached data Return cached data
1 C S5 cached RCODE=2 Treat as line S1
0 C S6 cached data was Return cache contents
generated with
CD=0
0 C S7 cached data was Validate & return cache
generated with contents
CD=1 &
covering TA
0 C S8 cached RCODE=2 Return cache contents
0 C S9 cached data Treat as line S3
was generated
with CD=1 &
no covering
TA
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
 End of changes. 10 change blocks. 
48 lines changed or deleted 202 lines changed or added

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