idnits 2.17.1 draft-ietf-dnsext-dnssec-bis-updates-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5155, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4033, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4033, updated by this document, for RFC5378 checks: 2001-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2010) is 5144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft SPARTA, Inc. 4 Updates: 4033, 4034, 4035, 5155 D. Blacka 5 (if approved) VeriSign, Inc. 6 Intended status: Standards Track March 27, 2010 7 Expires: September 28, 2010 9 Clarifications and Implementation Notes for DNSSECbis 10 draft-ietf-dnsext-dnssec-bis-updates-11 12 Abstract 14 This document is a collection of technical clarifications to the 15 DNSSECbis document set. It is meant to serve as a resource to 16 implementors as well as a repository of DNSSECbis errata. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 28, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 59 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 60 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 62 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 4 66 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 68 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 5 69 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 70 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 71 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6 72 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 6 73 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 6 74 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 7 75 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 76 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 8 77 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 8 78 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 8 79 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 8 80 5.9. Handling Queries With the CD Bit Set . . . . . . . . . . . 8 81 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 9 82 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 9 83 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 10 84 5.10.3. Preference Based on Source . . . . . . . . . . . . . 10 85 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 10 86 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 11 87 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 11 88 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 11 89 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 12 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 98 1. Introduction and Terminology 100 This document lists some additions, clarifications and corrections to 101 the core DNSSECbis specification, as originally described in 102 [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. 103 (See section Section 2 for more recent additions to that core 104 document set.) 106 It is intended to serve as a resource for implementors and as a 107 repository of items that need to be addressed when advancing the 108 DNSSECbis documents from Proposed Standard to Draft Standard. 110 1.1. Structure of this Document 112 The clarifications to DNSSECbis are sorted according to their 113 importance, starting with ones which could, if ignored, lead to 114 security problems and progressing down to clarifications that are 115 expected to have little operational impact. 117 1.2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Important Additions to DNSSSECbis 125 This section lists some documents that should be considered core 126 DNSSEC protocol documents in addition to those originally specified 127 in Section 10 of [RFC4033]. 129 2.1. NSEC3 Support 131 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM 132 records for hashed denial of existence. Validator implementations 133 are strongly encouraged to include support for NSEC3 because a number 134 of highly visible zones are expected to use it. Validators that do 135 not support validation of responses using NSEC3 will likely be 136 hampered in validating large portions of the DNS space. 138 [RFC5155] should be considered part of the DNS Security Document 139 Family as described by [RFC4033], Section 10. 141 Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- 142 SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) 143 signal that a zone MAY be using NSEC3, rather than NSEC. The zone 144 MAY indeed be using either and validators supporting these algorithms 145 MUST support both NSEC3 and NSEC responses. 147 2.2. SHA-2 Support 149 [RFC4509] describes the use of SHA-256 as a digest algorithm in 150 Delegation Signer (DS) RRs. [RFC5702] describes the use of the 151 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. 152 Validator implementations are strongly encouraged to include support 153 for these algorithms for DS, DNSKEY, and RRSIG records. 155 Both [RFC4509] and [RFC5702] should also be considered part of the 156 DNS Security Document Family as described by [RFC4033], Section 10. 158 3. Scaling Concerns 160 This is a placeholder section. New text is forthcoming with general 161 themes of "please play well with others", "don't flood authoritative 162 servers with queries" and "don't try TOO hard to recover from 163 validation failures". 165 3.1. Implement a BAD cache 167 Section 4.7 of RFC4035 permits security-aware resolvers to implement 168 a BAD cache. Because of the concerns outlined above, that guidance 169 has changed: security-aware resolvers SHOULD implement a BAD cache, 170 as described in RFC4035. 172 4. Security Concerns 174 This section provides clarifications that, if overlooked, could lead 175 to security issues. 177 4.1. Clarifications on Non-Existence Proofs 179 [RFC4035] Section 5.4 under-specifies the algorithm for checking non- 180 existence proofs. In particular, the algorithm as presented would 181 incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove 182 the non-existence of RRs in the child zone. 184 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: 186 o the NS bit set, 187 o the SOA bit clear, and 188 o a signer field that is shorter than the owner name of the NSEC RR, 189 or the original owner name for the NSEC3 RR. 191 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- 192 existence of any RRs below that zone cut, which include all RRs at 193 that (original) owner name other than DS RRs, and all RRs below that 194 owner name regardless of type. 196 Similarly, the algorithm would also allow an NSEC RR at the same 197 owner name as a DNAME RR, or an NSEC3 RR at the same original owner 198 name as a DNAME, to prove the non-existence of names beneath that 199 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used 200 to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's 201 (original) owner name. 203 4.2. Validating Responses to an ANY Query 205 [RFC4035] does not address how to validate responses when QTYPE=*. 206 As described in Section 6.2.2 of [RFC1034], a proper response to 207 QTYPE=* may include a subset of the RRsets at a given name. That is, 208 it is not necessary to include all RRsets at the QNAME in the 209 response. 211 When validating a response to QTYPE=*, all received RRsets that match 212 QNAME and QCLASS MUST be validated. If any of those RRsets fail 213 validation, the answer is considered Bogus. If there are no RRsets 214 matching QNAME and QCLASS, that fact MUST be validated according to 215 the rules in [RFC4035] Section 5.4 (as clarified in this document). 216 To be clear, a validator must not expect to receive all records at 217 the QNAME in response to QTYPE=*. 219 4.3. Check for CNAME 221 Section 5 of [RFC4035] says little about validating responses based 222 on (or that should be based on) CNAMEs. When validating a NOERROR/ 223 NODATA response, validators MUST check the CNAME bit in the matching 224 NSEC or NSEC3 RR's type bitmap in addition to the bit for the query 225 type. Without this check, an attacker could successfully transform a 226 positive CNAME response into a NOERROR/NODATA response. 228 4.4. Insecure Delegation Proofs 230 [RFC4035] Section 5.2 specifies that a validator, when proving a 231 delegation is not secure, needs to check for the absence of the DS 232 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also 233 needs to check for the presence of the NS bit in the matching NSEC 234 (or NSEC3) RR (proving that there is, indeed, a delegation), or 235 alternately make sure that the delegation is covered by an NSEC3 RR 236 with the Opt-Out flag set. If this is not checked, spoofed unsigned 237 delegations might be used to claim that an existing signed record is 238 not signed. 240 5. Interoperability Concerns 242 5.1. Errors in Canonical Form Type Code List 244 When canonicalizing DNS names, DNS names in the RDATA section of NSEC 245 and RRSIG resource records are not downcased. 247 [RFC4034] Section 6.2 item 3 has a list of resource record types for 248 which DNS names in the RDATA are downcased for purposes of DNSSEC 249 canonical form (for both ordering and signing). That list 250 erroneously contains NSEC and RRSIG. According to [RFC3755], DNS 251 names in the RDATA of NSEC and RRSIG should not be downcased. 253 The same section also erroneously lists HINFO, and twice at that. 254 Since HINFO records contain no domain names, they are not subject to 255 downcasing. 257 5.2. Unknown DS Message Digest Algorithms 259 Section 5.2 of [RFC4035] includes rules for how to handle delegations 260 to zones that are signed with entirely unsupported public key 261 algorithms, as indicated by the key algorithms shown in those zone's 262 DS RRsets. It does not explicitly address how to handle DS records 263 that use unsupported message digest algorithms. In brief, DS records 264 using unknown or unsupported message digest algorithms MUST be 265 treated the same way as DS records referring to DNSKEY RRs of unknown 266 or unsupported public key algorithms. 268 The existing text says: 270 If the validator does not support any of the algorithms listed in 271 an authenticated DS RRset, then the resolver has no supported 272 authentication path leading from the parent to the child. The 273 resolver should treat this case as it would the case of an 274 authenticated NSEC RRset proving that no DS RRset exists, as 275 described above. 277 To paraphrase the above, when determining the security status of a 278 zone, a validator disregards any DS records listing unknown or 279 unsupported algorithms. If none are left, the zone is treated as if 280 it were unsigned. 282 Modified to consider DS message digest algorithms, a validator also 283 disregards any DS records using unknown or unsupported message digest 284 algorithms. 286 5.3. Private Algorithms 288 As discussed above, section 5.2 of [RFC4035] requires that validators 289 make decisions about the security status of zones based on the public 290 key algorithms shown in the DS records for those zones. In the case 291 of private algorithms, as described in [RFC4034] Appendix A.1.1, the 292 eight-bit algorithm field in the DS RR is not conclusive about what 293 algorithm(s) is actually in use. 295 If no private algorithms appear in the DS set or if any supported 296 algorithm appears in the DS set, no special processing will be 297 needed. In the remaining cases, the security status of the zone 298 depends on whether or not the resolver supports any of the private 299 algorithms in use (provided that these DS records use supported hash 300 functions, as discussed in Section 5.2). In these cases, the 301 resolver MUST retrieve the corresponding DNSKEY for each private 302 algorithm DS record and examine the public key field to determine the 303 algorithm in use. The security-aware resolver MUST ensure that the 304 hash of the DNSKEY RR's owner name and RDATA matches the digest in 305 the DS RR. If they do not match, and no other DS establishes that 306 the zone is secure, the referral should be considered Bogus data, as 307 discussed in [RFC4035]. 309 This clarification facilitates the broader use of private algorithms, 310 as suggested by [RFC4955]. 312 5.4. Caution About Local Policy and Multiple RRSIGs 314 When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 315 suggests that "the local resolver security policy determines whether 316 the resolver also has to test these RRSIG RRs and how to resolve 317 conflicts if these RRSIG RRs lead to differing results." In most 318 cases, a resolver would be well advised to accept any valid RRSIG as 319 sufficient. If the first RRSIG tested fails validation, a resolver 320 would be well advised to try others, giving a successful validation 321 result if any can be validated and giving a failure only if all 322 RRSIGs fail validation. 324 If a resolver adopts a more restrictive policy, there's a danger that 325 properly-signed data might unnecessarily fail validation, perhaps 326 because of cache timing issues. Furthermore, certain zone management 327 techniques, like the Double Signature Zone-signing Key Rollover 328 method described in section 4.2.1.2 of [RFC4641] might not work 329 reliably. 331 5.5. Key Tag Calculation 333 [RFC4034] Appendix B.1 incorrectly defines the Key Tag field 334 calculation for algorithm 1. It correctly says that the Key Tag is 335 the most significant 16 of the least significant 24 bits of the 336 public key modulus. However, [RFC4034] then goes on to incorrectly 337 say that this is 4th to last and 3rd to last octets of the public key 338 modulus. It is, in fact, the 3rd to last and 2nd to last octets. 340 5.6. Setting the DO Bit on Replies 342 As stated in [RFC3225], the DO bit of the query MUST be copied in the 343 response. At least one implementation has done something different, 344 so it may be wise for resolvers to be liberal in what they accept. 346 5.7. Setting the AD Bit on Queries 348 The use of the AD bit in the query was previously undefined. This 349 document defines it as a signal indicating that the requester 350 understands and is interested in the value of the AD bit in the 351 response. This allows a requestor to indicate that it understands 352 the AD bit without also requesting DNSSEC data via the DO bit. 354 5.8. Setting the AD Bit on Replies 356 Section 3.2.3 of [RFC4035] describes under which conditions a 357 validating resolver should set or clear the AD bit in a response. In 358 order to protect legacy stub resolvers and middleboxes, validating 359 resolvers SHOULD only set the AD bit when a response both meets the 360 conditions listed in RFC 4035, section 3.2.3, and the request 361 contained either a set DO bit or a set AD bit. 363 5.9. Handling Queries With the CD Bit Set 365 When processing a request with the CD bit set, a resolver SHOULD 366 attempt to return all responsive data, even data that has failed 367 DNSSEC validation. RFC4035 section 3.2.2 requires a resolver 368 processing a request with the CD bit set to set the CD bit on its 369 upstream queries. 371 The guidance in RFC4035 is ambiguous about what to do when a cached 372 response was obtained with the CD bit not set. In the typical case, 373 no new query is required, nor does the cache need to track the state 374 of the CD bit used to make a given query. The problem arises when 375 the cached response is a server failure (RCODE 2), which may indicate 376 that the requested data failed DNSSEC validation at an upstream 377 validating resolver. (RFC2308 permits caching of server failures for 378 up to five minutes.) In these cases, a new query with the CD bit set 379 is required. 381 For efficiency, a validator may wish to set the CD bit on all 382 upstream queries when it has a trust anchor at or above the QNAME 383 (and thus can reasonably expect to be able to validate the response). 385 5.10. Nested Trust Anchors 387 A DNSSEC validator may be configured such that, for a given response, 388 more than one trust anchor could be used to validate the chain of 389 trust to the response zone. For example, imagine a validator 390 configured with trust anchors for "example." and "zone.example." 391 When the validator is asked to validate a response to 392 "www.sub.zone.example.", either trust anchor could apply. 394 When presented with this situation, DNSSEC validators have a choice 395 of which trust anchor(s) to use. Which to use is a matter of 396 implementation choice. It is possible and perhaps advisable to 397 expose the choice of policy as a configuration option. The rest of 398 this section discusses some possible policies. As a default, we 399 suggest that validators implement the "Accept Any Success" policy 400 described below in Section 5.10.2 while exposing other policies as 401 configuration options. 403 5.10.1. Closest Encloser 405 One policy is to choose the trust anchor closest to the QNAME of the 406 response. In our example, that would be the "zone.example." trust 407 anchor. 409 This policy has the advantage of allowing the operator to trivially 410 override a parent zone's trust anchor with one that the operator can 411 validate in a stronger way, perhaps because the resolver operator is 412 affiliated with the zone in question. This policy also minimizes the 413 number of public key operations needed, which may be of benefit in 414 resource-constrained environments. 416 This policy has the disadvantage of possibly giving the user some 417 unexpected and unnecessary validation failures when sub-zone trust 418 anchors are neglected. As a concrete example, consider a validator 419 that configured a trust anchor for "zone.example." in 2009 and one 420 for "example." in 2011. In 2012, "zone.example." rolls its KSK and 421 updates its DS records, but the validator operator doesn't update its 422 trust anchor. With the "closest encloser" policy, the validator gets 423 validation failures. 425 5.10.2. Accept Any Success 427 Another policy is to try all applicable trust anchors until one gives 428 a validation result of Secure, in which case the final validation 429 result is Secure. If and only if all applicable trust anchors give a 430 result of Insecure, the final validation result is Insecure. If one 431 or more trust anchors lead to a Bogus result and there is no Secure 432 result, then the final validation result is Bogus. 434 This has the advantage of causing the fewer validation failures, 435 which may deliver a better user experience. If one trust anchor is 436 out of date (as in our above example), the user may still be able to 437 get a Secure validation result (and see DNS responses). 439 This policy has the disadvantage of making the validator subject to 440 compromise of the weakest of these trust anchors while making its 441 relatively painless to keep old trust anchors configured in 442 perpetuity. 444 5.10.3. Preference Based on Source 446 When the trust anchors have come from different sources (e.g. 447 automated updates ([RFC5011]), one or more DLV registries 448 ([RFC5074]), and manually configured), a validator may wish to choose 449 between them based on the perceived reliability of those sources. 450 The order of precedence might be exposed as a configuration option. 452 For example, a validator might choose to prefer trust anchors found 453 in a DLV registry over those manually configured on the theory that 454 the manually configured ones will not be as aggressively maintained. 456 Conversely, a validator might choose to prefer manually configured 457 trust anchors over those obtained from a DLV registry on the theory 458 that the manually configured ones have been more carefully 459 authenticated. 461 Or the validator might do something more complicated: prefer a sub- 462 set of manually configured trust anchors (based on a configuration 463 option), then trust anchors that have been updated using the RFC5011 464 mechanism, then trust anchors from one DLV registry, then trust 465 anchors from a different DLV registry, then the rest of the manually 466 configured trust anchors. 468 6. Minor Corrections and Clarifications 469 6.1. Finding Zone Cuts 471 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 472 for a parent zone. To do that, a resolver may first need to apply 473 special rules to discover what those servers are. 475 As explained in Section 3.1.4.1 of [RFC4035], security-aware name 476 servers need to apply special processing rules to handle the DS RR, 477 and in some situations the resolver may also need to apply special 478 rules to locate the name servers for the parent zone if the resolver 479 does not already have the parent's NS RRset. Section 4.2 of 480 [RFC4035] specifies a mechanism for doing that. 482 6.2. Clarifications on DNSKEY Usage 484 Questions of the form "can I use a different DNSKEY for signing this 485 RRset" have occasionally arisen. 487 The short answer is "yes, absolutely". You can even use a different 488 DNSKEY for each RRset in a zone, subject only to practical limits on 489 the size of the DNSKEY RRset. However, be aware that there is no way 490 to tell resolvers what a particularly DNSKEY is supposed to be used 491 for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to 492 authenticate any RRset in the zone. For example, if a weaker or less 493 trusted DNSKEY is being used to authenticate NSEC RRsets or all 494 dynamically updated records, that same DNSKEY can also be used to 495 sign any other RRsets from the zone. 497 Furthermore, note that the SEP bit setting has no effect on how a 498 DNSKEY may be used -- the validation process is specifically 499 prohibited from using that bit by [RFC4034] section 2.1.2. It is 500 possible to use a DNSKEY without the SEP bit set as the sole secure 501 entry point to the zone, yet use a DNSKEY with the SEP bit set to 502 sign all RRsets in the zone (other than the DNSKEY RRset). It's also 503 possible to use a single DNSKEY, with or without the SEP bit set, to 504 sign the entire zone, including the DNSKEY RRset itself. 506 6.3. Errors in Examples 508 The text in [RFC4035] Section C.1 refers to the examples in B.1 as 509 "x.w.example.com" while B.1 uses "x.w.example". This is painfully 510 obvious in the second paragraph where it states that the RRSIG labels 511 field value of 3 indicates that the answer was not the result of 512 wildcard expansion. This is true for "x.w.example" but not for 513 "x.w.example.com", which of course has a label count of 4 514 (antithetically, a label count of 3 would imply the answer was the 515 result of a wildcard expansion). 517 The first paragraph of [RFC4035] Section C.6 also has a minor error: 518 the reference to "a.z.w.w.example" should instead be "a.z.w.example", 519 as in the previous line. 521 6.4. Errors in RFC 5155 523 A NSEC3 record that matches an Empty Non-Terminal effectively has no 524 type associated with it. This NSEC3 record has an empty type bit 525 map. Section 3.2.1 of [RFC5155] contains the statement: 527 Blocks with no types present MUST NOT be included. 529 However, the same section contains a regular expression: 531 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 533 The plus sign in the regular expression indicates that there is one 534 or more of the preceding element. This means that there must be at 535 least one window block. If this window block has no types, it 536 contradicts with the first statement. Therefore, the correct text in 537 RFC 5155 3.2.1 should be: 539 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 541 7. IANA Considerations 543 This document specifies no IANA Actions. 545 8. Security Considerations 547 This document adds two cryptographic features to the core DNSSEC 548 protocol. Additionally, it addresses some ambiguities and omissions 549 in the core DNSSEC documents that, if not recognized and addressed in 550 implementations, could lead to security failures. In particular, the 551 validation algorithm clarifications in Section 4 are critical for 552 preserving the security properties DNSSEC offers. Furthermore, 553 failure to address some of the interoperability concerns in Section 5 554 could limit the ability to later change or expand DNSSEC, including 555 adding new algorithms. 557 9. References 558 9.1. Normative References 560 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 561 STD 13, RFC 1034, November 1987. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 567 RFC 3225, December 2001. 569 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 570 Rose, "DNS Security Introduction and Requirements", 571 RFC 4033, March 2005. 573 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 574 Rose, "Resource Records for the DNS Security Extensions", 575 RFC 4034, March 2005. 577 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 578 Rose, "Protocol Modifications for the DNS Security 579 Extensions", RFC 4035, March 2005. 581 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 582 (DS) Resource Records (RRs)", RFC 4509, May 2006. 584 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 585 Security (DNSSEC) Hashed Authenticated Denial of 586 Existence", RFC 5155, March 2008. 588 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 589 and RRSIG Resource Records for DNSSEC", RFC 5702, 590 October 2009. 592 9.2. Informative References 594 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 595 Signer (DS)", RFC 3755, May 2004. 597 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 598 RFC 4641, September 2006. 600 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 601 July 2007. 603 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 604 Trust Anchors", RFC 5011, September 2007. 606 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 607 November 2007. 609 Appendix A. Acknowledgments 611 The editors would like the thank Rob Austein for his previous work as 612 an editor of this document. 614 The editors are extremely grateful to those who, in addition to 615 finding errors and omissions in the DNSSECbis document set, have 616 provided text suitable for inclusion in this document. 618 The lack of specificity about handling private algorithms, as 619 described in Section 5.3, and the lack of specificity in handling ANY 620 queries, as described in Section 4.2, were discovered by David 621 Blacka. 623 The error in algorithm 1 key tag calculation, as described in 624 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 625 contributed text for Section 5.5. 627 The bug relating to delegation NSEC RR's in Section 4.1 was found by 628 Roy Badami. Roy Arends found the related problem with DNAME. 630 The errors in the [RFC4035] examples were found by Roy Arends, who 631 also contributed text for Section 6.3 of this document. 633 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 634 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 635 and Scott Rose for their substantive comments on the text of this 636 document. 638 Authors' Addresses 640 Samuel Weiler 641 SPARTA, Inc. 642 7110 Samuel Morse Drive 643 Columbia, Maryland 21046 644 US 646 Email: weiler@tislabs.com 647 David Blacka 648 VeriSign, Inc. 649 21345 Ridgetop Circle 650 Dulles, VA 20166 651 US 653 Email: davidb@verisign.com