From 39158a4c93131db13c7260253c82ece87f0cf92c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 8 Mar 2010 22:17:03 +0000 Subject: [PATCH] new draft --- ...aft-ietf-dnsext-dnssec-bis-updates-10.txt} | 433 +++++++++++------- 1 file changed, 273 insertions(+), 160 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-bis-updates-09.txt => draft-ietf-dnsext-dnssec-bis-updates-10.txt} (67%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt similarity index 67% rename from doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt rename to doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt index 0953e28b47..eef3308e92 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-10.txt @@ -5,12 +5,18 @@ Network Working Group S. Weiler Internet-Draft SPARTA, Inc. Updates: 4033, 4034, 4035, 5155 D. Blacka (if approved) VeriSign, Inc. -Intended status: Standards Track September 5, 2009 -Expires: March 9, 2010 +Intended status: Standards Track March 8, 2010 +Expires: September 9, 2010 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 @@ -33,32 +39,30 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - 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 + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of -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 - implementors as well as a repository of DNSSECbis errata. + publication of this document. Please review these documents + 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 @@ -68,56 +72,54 @@ Table of Contents 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 4 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 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.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 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.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 - 4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7 - 4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 - 4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 - 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8 - 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8 - 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9 - 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9 - 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 + 4.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 + 4.9. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 + 4.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 + 4.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 + 4.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 9 + 4.10.3. Preference Based on Source . . . . . . . . . . . . . 10 + 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 + 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 10 + 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 10 + 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 + 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 - - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 2] +Weiler & Blacka Expires September 9, 2010 [Page 2] -Internet-Draft DNSSECbis Implementation Notes September 2009 +Internet-Draft DNSSECbis Implementation Notes March 2010 1. Introduction and Terminology This document lists some additions, clarifications and corrections to 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 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 - This section updates the set of core DNSSEC protocol documents - originally specified in Section 10 of [RFC4033]. + This section lists some documents that should be considered core + DNSSEC protocol documents in addition to those originally specified + in Section 10 of [RFC4033]. 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 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 - [RFC4509] describes the use of SHA-256 as a digest algorithm for use - with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256] - describes the use of the RSASHA256 algorithm for use in DNSKEY and - RRSIG RRs. Validator implementations are strongly encouraged to - include support for this algorithm for DS, DNSKEY, and RRSIG records. + [RFC4509] describes the use of SHA-256 as a digest algorithm in + Delegation Signer (DS) RRs. [RFC5702] describes the use of the + RSASHA256 algorithm in DNSKEY and RRSIG RRs. Validator + implementations are strongly encouraged to include support for this + algorithm for DS, DNSKEY, and RRSIG records. - - -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. + Both [RFC4509] and [RFC5702] should also be considered part of the + DNS Security Document Family as described by [RFC4033], Section 10. 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 (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 [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 validation, the answer is considered Bogus. If there are no RRsets 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). To be clear, a validator must not expect to receive all records at 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 which DNS names in the RDATA are downcased for purposes of DNSSEC 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 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 to zones that are signed with entirely unsupported public key 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 that use unsupported message digest algorithms. In brief, DS records 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 algorithm appears in the DS set, no special processing will be 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 algorithms in use (provided that these DS records use supported hash 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]. 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]. 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 - [RFC4035] does not provide any instructions to servers as to how to - set the DO bit. Some authoritative server implementations have - chosen to copy the DO bit settings from the incoming query to the - 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. + As stated in [RFC3225], the DO bit of the query MUST be copied in the + response. At least one implementation has done something different, + so it may be wise for resolvers to be liberal in what they accept. -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 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 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] - -Internet-Draft DNSSECbis Implementation Notes September 2009 + 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 + (and thus can reasonably expect to be able to validate the response). - - 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 +4.10. Nested Trust Anchors 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 @@ -414,13 +441,95 @@ Internet-Draft DNSSECbis Implementation Notes September 2009 When the validator is asked to validate a response to "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 - configurable overrides. + + +Weiler & Blacka Expires September 9, 2010 [Page 8] + +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 @@ -438,23 +547,20 @@ Internet-Draft DNSSECbis Implementation Notes September 2009 does not already have the parent's NS RRset. Section 4.2 of [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 Questions of the form "can I use a different DNSKEY for signing this RRset" have occasionally arisen. 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 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 @@ -498,18 +604,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009 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 )+ 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 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 RFC 5155 3.2.1 should be: @@ -538,29 +645,19 @@ Internet-Draft DNSSECbis Implementation Notes September 2009 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", - RFC 1034, STD 13, November 1987. + STD 13, RFC 1034, November 1987. [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. Rose, "DNS Security Introduction and Requirements", 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. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. @@ -569,6 +666,13 @@ Internet-Draft DNSSECbis Implementation Notes September 2009 Rose, "Protocol Modifications for the DNS Security 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 (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 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 [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, 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 @@ -607,22 +721,22 @@ Appendix A. Acknowledgments contributed text for Section 4.5. 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 March 9, 2010 [Page 11] +Weiler & Blacka Expires September 9, 2010 [Page 13] -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 also contributed text for Section 5.3 of this document. - The editors would like to thank Ed Lewis, Danny Mayer, Olafur - Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive - comments on the text of this document. + The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, + Olafur Gudmundsson, Suzanne Woolf, and Scott Rose for their + substantive comments on the text of this document. Authors' Addresses @@ -666,7 +780,6 @@ Authors' Addresses - - -Weiler & Blacka Expires March 9, 2010 [Page 12] +Weiler & Blacka Expires September 9, 2010 [Page 14] +