mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 14:35:26 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2010-03-08 22:17:03 +00:00
parent 2c244f981f
commit 39158a4c93
1 changed files with 273 additions and 160 deletions
Download Patch File Download Diff File Expand all files Collapse all files

433
doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt → doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt
View File

@@ -5,12 +5,18 @@ 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 September 5, 2009 Intended status: Standards Track March 8, 2010
Expires: March 9, 2010 Expires: September 9, 2010
Clarifications and Implementation Notes for DNSSECbis Clarifications and Implementation Notes for DNSSECbis
draft-ietf-dnsext-dnssec-bis-updates-09 draft-ietf-dnsext-dnssec-bis-updates-10
Abstract
This document is a collection of technical clarifications to the
DNSSECbis document set. It is meant to serve as a resource to
implementors as well as a repository of DNSSECbis errata.
Status of this Memo Status of this Memo
@@ -33,32 +39,30 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document is a collection of technical clarifications to the
Weiler & Blacka Expires March 9, 2010 [Page 1] Weiler & Blacka Expires September 9, 2010 [Page 1]
Internet-Draft DNSSECbis Implementation Notes September 2009 Internet-Draft DNSSECbis Implementation Notes March 2010
DNSSECbis document set. It is meant to serve as a resource to publication of this document. Please review these documents
implementors as well as a repository of DNSSECbis errata. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents Table of Contents
@@ -68,56 +72,54 @@ Table of Contents
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-256 Support . . . . . . . . . . . . . . . . . . . . . 3 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 4
3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 5
3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5
4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6
4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7 4.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8
4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 4.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8
4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 4.9. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8 4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8 4.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9
5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9 4.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9
5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9 4.10.3. Preference Based on Source . . . . . . . . . . . . . 10
5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Weiler & Blacka Expires September 9, 2010 [Page 2]
Weiler & Blacka Expires March 9, 2010 [Page 2]
Internet-Draft DNSSECbis Implementation Notes September 2009 Internet-Draft DNSSECbis Implementation Notes March 2010
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]. [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
(See section Section 2 for more recent additions to that core
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
@@ -139,8 +141,9 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
2. Important Additions to DNSSSECbis 2. Important Additions to DNSSSECbis
This section updates the set of core DNSSEC protocol documents This section lists some documents that should be considered core
originally specified in Section 10 of [RFC4033]. DNSSEC protocol documents in addition to those originally specified
in Section 10 of [RFC4033].
2.1. NSEC3 Support 2.1. NSEC3 Support
@@ -154,24 +157,30 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[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-
SHA1 and RSASHA1-NSEC3-SHA1) signal that a zone MAY be using NSEC3,
rather than NSEC. The zone MAY indeed be using either and validators
supporting these algorithms MUST support both NSEC3 and NSEC
Weiler & Blacka Expires September 9, 2010 [Page 3]
Internet-Draft DNSSECbis Implementation Notes March 2010
responses.
2.2. SHA-256 Support 2.2. SHA-256 Support
[RFC4509] describes the use of SHA-256 as a digest algorithm for use [RFC4509] describes the use of SHA-256 as a digest algorithm in
with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256] Delegation Signer (DS) RRs. [RFC5702] describes the use of the
describes the use of the RSASHA256 algorithm for use in DNSKEY and RSASHA256 algorithm in DNSKEY and RRSIG RRs. Validator
RRSIG RRs. Validator implementations are strongly encouraged to implementations are strongly encouraged to include support for this
include support for this algorithm for DS, DNSKEY, and RRSIG records. algorithm for DS, DNSKEY, and RRSIG records.
Both [RFC4509] and [RFC5702] should also be considered part of the
DNS Security Document Family as described by [RFC4033], Section 10.
Weiler & Blacka Expires March 9, 2010 [Page 3]
Internet-Draft DNSSECbis Implementation Notes September 2009
Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
considered part of the DNS Security Document Family as described by
[RFC4033], Section 10.
3. Security Concerns 3. Security Concerns
@@ -205,6 +214,17 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
(original) owner name. (original) owner name.
Weiler & Blacka Expires September 9, 2010 [Page 4]
Internet-Draft DNSSECbis Implementation Notes March 2010
3.2. Validating Responses to an ANY Query 3.2. Validating Responses to an ANY Query
[RFC4035] does not address how to validate responses when QTYPE=*. [RFC4035] does not address how to validate responses when QTYPE=*.
@@ -217,14 +237,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
QNAME and QCLASS MUST be validated. If any of those RRsets fail QNAME and QCLASS MUST be validated. If any of those RRsets fail
validation, the answer is considered Bogus. If there are no RRsets validation, the answer is considered Bogus. If there are no RRsets
matching QNAME and QCLASS, that fact MUST be validated according to matching QNAME and QCLASS, that fact MUST be validated according to
Weiler & Blacka Expires March 9, 2010 [Page 4]
Internet-Draft DNSSECbis Implementation Notes September 2009
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=*.
@@ -261,6 +273,14 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4034] Section 6.2 item 3 has a list of resource record types for [RFC4034] Section 6.2 item 3 has a list of resource record types for
which DNS names in the RDATA are downcased for purposes of DNSSEC which DNS names in the RDATA are downcased for purposes of DNSSEC
canonical form (for both ordering and signing). That list canonical form (for both ordering and signing). That list
Weiler & Blacka Expires September 9, 2010 [Page 5]
Internet-Draft DNSSECbis Implementation Notes March 2010
erroneously contains NSEC and RRSIG. According to [RFC3755], DNS erroneously contains NSEC and RRSIG. According to [RFC3755], DNS
names in the RDATA of NSEC and RRSIG should not be downcased. names in the RDATA of NSEC and RRSIG should not be downcased.
@@ -273,14 +293,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Section 5.2 of [RFC4035] includes rules for how to handle delegations Section 5.2 of [RFC4035] includes rules for how to handle delegations
to zones that are signed with entirely unsupported public key to zones that are signed with entirely unsupported public key
algorithms, as indicated by the key algorithms shown in those zone's algorithms, as indicated by the key algorithms shown in those zone's
Weiler & Blacka Expires March 9, 2010 [Page 5]
Internet-Draft DNSSECbis Implementation Notes September 2009
DS RRsets. It does not explicitly address how to handle DS records DS RRsets. It does not explicitly address how to handle DS records
that use unsupported message digest algorithms. In brief, DS records that use unsupported message digest algorithms. In brief, DS records
using unknown or unsupported message digest algorithms MUST be using unknown or unsupported message digest algorithms MUST be
@@ -317,6 +329,14 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
If no private algorithms appear in the DS set or if any supported If no private algorithms appear in the DS set or if any supported
algorithm appears in the DS set, no special processing will be algorithm appears in the DS set, no special processing will be
needed. In the remaining cases, the security status of the zone needed. In the remaining cases, the security status of the zone
Weiler & Blacka Expires September 9, 2010 [Page 6]
Internet-Draft DNSSECbis Implementation Notes March 2010
depends on whether or not the resolver supports any of the private depends on whether or not the resolver supports any of the private
algorithms in use (provided that these DS records use supported hash algorithms in use (provided that these DS records use supported hash
functions, as discussed in Section 4.2). In these cases, the functions, as discussed in Section 4.2). In these cases, the
@@ -329,14 +349,6 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
discussed in [RFC4035]. discussed in [RFC4035].
This clarification facilitates the broader use of private algorithms, This clarification facilitates the broader use of private algorithms,
Weiler & Blacka Expires March 9, 2010 [Page 6]
Internet-Draft DNSSECbis Implementation Notes September 2009
as suggested by [RFC4955]. as suggested by [RFC4955].
4.4. Caution About Local Policy and Multiple RRSIGs 4.4. Caution About Local Policy and Multiple RRSIGs
@@ -369,14 +381,27 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
4.6. Setting the DO Bit on Replies 4.6. Setting the DO Bit on Replies
[RFC4035] does not provide any instructions to servers as to how to As stated in [RFC3225], the DO bit of the query MUST be copied in the
set the DO bit. Some authoritative server implementations have response. At least one implementation has done something different,
chosen to copy the DO bit settings from the incoming query to the so it may be wise for resolvers to be liberal in what they accept.
outgoing response. Others have chosen to never set the DO bit in
responses. Either behavior is permitted. To be clear, in replies to
queries with the DO-bit set servers may or may not set the DO bit.
4.7. Setting the AD bit on Replies
Weiler & Blacka Expires September 9, 2010 [Page 7]
Internet-Draft DNSSECbis Implementation Notes March 2010
4.7. Setting the AD Bit on Queries
The use of the AD bit in the query was previously undefined. This
document defines it as a signal indicating that the requester
understands and is interested in the value of the AD bit in the
response. This allows a requestor to indicate that it understands
the AD bit without also requesting DNSSEC data via the DO bit.
4.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
@@ -385,27 +410,29 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
conditions listed in RFC 4035, section 3.2.3, and the request conditions listed in RFC 4035, section 3.2.3, and the request
contained either a set DO bit or a set AD bit. contained either a set DO bit or a set AD bit.
4.9. Setting the CD bit on Requests
When processing a request with the CD bit set, a resolver SHOULD
attempt to return all responsive data, even data that has failed
DNSSEC validation. RFC4035 section 3.2.2 requires a resolver
processing a request with the CD bit set to set the CD bit on its
upstream queries.
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,
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
the cached response is a server failure (RCODE 2), which may indicate
that the requested data failed DNSSEC validation at an upstream
validating resolver. (RFC2308 permits caching of server failures for
up to five minutes.) In these cases, a new query with the CD bit set
is required.
Weiler & Blacka Expires March 9, 2010 [Page 7] For efficiency, a validator may wish to set the CD bit on all
upstream queries when it has a trust anchor at or above the QNAME
Internet-Draft DNSSECbis Implementation Notes September 2009 (and thus can reasonably expect to be able to validate the response).
4.10. Nested Trust Anchors
Note that the use of the AD bit in the query was previously
undefined. This document defines it as a signal indicating that the
requester understands and is interested in the value of the AD bit in
the response. This allows a requestor to indicate that it
understands the AD bit without also requesting DNSSEC data via the DO
bit.
4.8. Setting the CD bit on Requests
When processing a request with the CD bit set, the resolver MUST set
the CD bit on its upstream queries.
4.9. 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
@@ -414,13 +441,95 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
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 SHOULD try all
applicable trust anchors until one succeeds.
There are some scenarios where different behaviors, such as choosing
the trust anchor closest to the QNAME of the response, may be
desired. A DNSSEC validator MAY enable such behaviors as Weiler & Blacka Expires September 9, 2010 [Page 8]
configurable overrides.
Internet-Draft DNSSECbis Implementation Notes March 2010
When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. It is possible and perhaps advisable to
expose the choice of policy as a configuration option. The rest of
this section discusses some possible policies. As a default, we
suggest that validators implement the "Accept Any Success" policy
described below in Section 4.10.2 while exposing other policies as
configuration options.
4.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.
4.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
Weiler & Blacka Expires September 9, 2010 [Page 9]
Internet-Draft DNSSECbis Implementation Notes March 2010
perpetuity.
4.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
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 complicated: 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.
5. Minor Corrections and Clarifications 5. Minor Corrections and Clarifications
@@ -438,23 +547,20 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
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.
Weiler & Blacka Expires March 9, 2010 [Page 8]
Internet-Draft DNSSECbis Implementation Notes September 2009
5.2. Clarifications on DNSKEY Usage 5.2. Clarifications on DNSKEY Usage
Questions of the form "can I use a different DNSKEY for signing this Questions of the form "can I use a different DNSKEY for signing this
RRset" have occasionally arisen. RRset" have occasionally arisen.
The short answer is "yes, absolutely". You can even use a different The short answer is "yes, absolutely". You can even use a different
Weiler & Blacka Expires September 9, 2010 [Page 10]
Internet-Draft DNSSECbis Implementation Notes March 2010
DNSKEY for each RRset in a zone, subject only to practical limits on DNSKEY for each RRset in a zone, subject only to practical limits on
the size of the DNSKEY RRset. However, be aware that there is no way the size of the DNSKEY RRset. However, be aware that there is no way
to tell resolvers what a particularly DNSKEY is supposed to be used to tell resolvers what a particularly DNSKEY is supposed to be used
@@ -498,18 +604,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
However, the same section contains a regular expression: However, the same section contains a regular expression:
Weiler & Blacka Expires March 9, 2010 [Page 9]
Internet-Draft DNSSECbis Implementation Notes September 2009
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
The plus sign in the regular expression indicates that there is one The plus sign in the regular expression indicates that there is one
or more of the preceding element. This means that there must be at or more of the preceding element. This means that there must be at
least one window block. If this window block has no types, it least one window block. If this window block has no types, it
Weiler & Blacka Expires September 9, 2010 [Page 11]
Internet-Draft DNSSECbis Implementation Notes March 2010
contradicts with the first statement. Therefore, the correct text in contradicts with the first statement. Therefore, the correct text in
RFC 5155 3.2.1 should be: RFC 5155 3.2.1 should be:
@@ -538,29 +645,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
8.1. Normative References 8.1. Normative References
[I-D.ietf-dnsext-dnssec-rsasha256]
Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC",
draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
June 2009.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, STD 13, November 1987. STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
Weiler & Blacka Expires March 9, 2010 [Page 10]
Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
@@ -569,6 +666,13 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
Weiler & Blacka Expires September 9, 2010 [Page 12]
Internet-Draft DNSSECbis Implementation Notes March 2010
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
(DS) Resource Records (RRs)", RFC 4509, May 2006. (DS) Resource Records (RRs)", RFC 4509, May 2006.
@@ -576,6 +680,10 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
8.2. Informative References 8.2. Informative References
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
@@ -587,6 +695,12 @@ Internet-Draft DNSSECbis Implementation Notes September 2009
[RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
July 2007. July 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
November 2007.
Appendix A. Acknowledgments Appendix A. Acknowledgments
@@ -607,22 +721,22 @@ Appendix A. Acknowledgments
contributed text for Section 4.5. contributed text for Section 4.5.
The bug relating to delegation NSEC RR's in Section 3.1 was found by The bug relating to delegation NSEC RR's in Section 3.1 was found by
Roy Badami. Roy Arends found the related problem with DNAME.
Weiler & Blacka Expires September 9, 2010 [Page 13]
Weiler & Blacka Expires March 9, 2010 [Page 11]
Internet-Draft DNSSECbis Implementation Notes September 2009 Internet-Draft DNSSECbis Implementation Notes March 2010
Roy Badami. Roy Arends found the related problem with DNAME.
The errors in the [RFC4035] examples were found by Roy Arends, who The errors in the [RFC4035] examples were found by Roy Arends, who
also contributed text for Section 5.3 of this document. also contributed text for Section 5.3 of this document.
The editors would like to thank Ed Lewis, Danny Mayer, Olafur The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their
comments on the text of this document. substantive comments on the text of this document.
Authors' Addresses Authors' Addresses
@@ -666,7 +780,6 @@ Authors' Addresses
Weiler & Blacka Expires September 9, 2010 [Page 14]
Weiler & Blacka Expires March 9, 2010 [Page 12]