idnits 2.17.1 draft-ietf-dnsext-dnssec-bis-updates-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 directly say this. It does mention RFC4034 though, so this could be OK. -- The draft header indicates that this document updates RFC5155, but the abstract doesn't seem to directly say this. It does mention RFC5155 though, so this could be OK. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to directly say this. It does mention RFC4035 though, so this could be OK. -- The draft header indicates that this document updates RFC4033, but the abstract doesn't seem to directly say this. It does mention RFC4033 though, so this could be OK. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2012) is 4225 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: 0 errors (**), 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 September 28, 2012 7 Expires: April 1, 2013 9 Clarifications and Implementation Notes for DNSSEC 10 draft-ietf-dnsext-dnssec-bis-updates-20 12 Abstract 14 This document is a collection of technical clarifications to the 15 DNSSEC document set. It is meant to serve as a resource to 16 implementors as well as a repository of DNSSEC errata. 18 This document updates the core DNSSEC documents (RFC4033, RFC4034, 19 and RFC4035) as well as the NSEC3 specification (RFC5155). It also 20 defines NSEC3 and SHA-2 as core parts of the DNSSEC specification. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 1, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 69 1.1. Structure of this Document . . . . . . . . . . . . . . . . 4 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Important Additions to DNSSEC . . . . . . . . . . . . . . . . 4 72 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5 76 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5 78 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6 79 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6 80 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 7 81 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 7 82 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7 83 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7 84 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8 85 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 9 86 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9 87 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9 88 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9 89 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 10 90 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 10 91 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10 92 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11 93 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 12 94 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12 95 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12 96 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12 97 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13 98 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 13 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 103 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 104 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 105 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16 106 Appendix C. Discussion of Trust Anchor Preference Options . . . . 19 107 C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 19 108 C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 20 109 C.3. Preference Based on Source . . . . . . . . . . . . . . . . 20 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 112 1. Introduction and Terminology 114 This document lists some additions, clarifications and corrections to 115 the core DNSSEC specification, as originally described in [RFC4033], 116 [RFC4034], and [RFC4035], and later amended by [RFC5155]. (See 117 section Section 2 for more recent additions to that core document 118 set.) 120 It is intended to serve as a resource for implementors and as a 121 repository of items that need to be addressed when advancing the 122 DNSSEC documents along the Standards Track. 124 1.1. Structure of this Document 126 The clarifications and changes to DNSSEC are sorted according to 127 their importance, starting with ones which could, if ignored, lead to 128 security problems and progressing down to clarifications that are 129 expected to have little operational impact. 131 1.2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 2. Important Additions to DNSSEC 140 This section lists some documents that are now considered core DNSSEC 141 protocol documents in addition to those originally specified in 142 Section 10 of [RFC4033]. 144 2.1. NSEC3 Support 146 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM 147 records for hashed denial of existence. Validator implementations 148 are strongly encouraged to include support for NSEC3 because a number 149 of highly visible zones use it. Validators that do not support 150 validation of responses using NSEC3 will be hampered in validating 151 large portions of the DNS space. 153 [RFC5155] is now considered part of the DNS Security Document Family 154 as described by [RFC4033], Section 10. 156 Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- 157 SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) 158 signal that a zone might be using NSEC3, rather than NSEC. The zone 159 may be using either and validators supporting these algorithms MUST 160 support both NSEC3 and NSEC responses. 162 2.2. SHA-2 Support 164 [RFC4509] describes the use of SHA-256 as a digest algorithm in 165 Delegation Signer (DS) RRs. [RFC5702] describes the use of the 166 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. 167 Validator implementations are strongly encouraged to include support 168 for these algorithms for DS, DNSKEY, and RRSIG records. 170 Both [RFC4509] and [RFC5702] are now considered part of the DNS 171 Security Document Family as described by [RFC4033], Section 10. 173 3. Scaling Concerns 175 3.1. Implement a BAD cache 177 Section 4.7 of RFC4035 permits security-aware resolvers to implement 178 a BAD cache. That guidance has changed: security-aware resolvers 179 SHOULD implement a BAD cache as described in RFC4035. 181 This change in guidance is based on operational experience with 182 DNSSEC administrative errors leading to significant increases in DNS 183 traffic, with an accompanying realization that such events are more 184 likely and more damaging than originally supposed. An example of one 185 such event is documented in "Roll Over and Die" [Huston]. 187 4. Security Concerns 189 This section provides clarifications that, if overlooked, could lead 190 to security issues. 192 4.1. Clarifications on Non-Existence Proofs 194 [RFC4035] Section 5.4 under-specifies the algorithm for checking non- 195 existence proofs. In particular, the algorithm as presented would 196 allow a validator to interpret an NSEC or NSEC3 RR from an ancestor 197 zone as proving the non-existence of an RR in a child zone. 199 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: 201 o the NS bit set, 202 o the SOA bit clear, and 203 o a signer field that is shorter than the owner name of the NSEC RR, 204 or the original owner name for the NSEC3 RR. 206 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- 207 existence of any RRs below that zone cut, which include all RRs at 208 that (original) owner name other than DS RRs, and all RRs below that 209 owner name regardless of type. 211 Similarly, the algorithm would also allow an NSEC RR at the same 212 owner name as a DNAME RR, or an NSEC3 RR at the same original owner 213 name as a DNAME, to prove the non-existence of names beneath that 214 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used 215 to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's 216 (original) owner name. 218 4.2. Validating Responses to an ANY Query 220 [RFC4035] does not address how to validate responses when QTYPE=*. 221 As described in Section 6.2.2 of [RFC1034], a proper response to 222 QTYPE=* may include a subset of the RRsets at a given name. That is, 223 it is not necessary to include all RRsets at the QNAME in the 224 response. 226 When validating a response to QTYPE=*, all received RRsets that match 227 QNAME and QCLASS MUST be validated. If any of those RRsets fail 228 validation, the answer is considered Bogus. If there are no RRsets 229 matching QNAME and QCLASS, that fact MUST be validated according to 230 the rules in [RFC4035] Section 5.4 (as clarified in this document). 231 To be clear, a validator must not expect to receive all records at 232 the QNAME in response to QTYPE=*. 234 4.3. Check for CNAME 236 Section 5 of [RFC4035] says nothing explicit about validating 237 responses based on (or that should be based on) CNAMEs. When 238 validating a NOERROR/NODATA response, validators MUST check the CNAME 239 bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the 240 bit for the query type. 242 Without this check, an attacker could successfully transform a 243 positive CNAME response into a NOERROR/NODATA response by (e.g.) 244 simply stripping the CNAME RRset from the response. A naive 245 validator would then note that the QTYPE was not present in the 246 matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was 247 set, and thus the response should have been a positive CNAME 248 response. 250 4.4. Insecure Delegation Proofs 252 [RFC4035] Section 5.2 specifies that a validator, when proving a 253 delegation is not secure, needs to check for the absence of the DS 254 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also 255 MUST check for the presence of the NS bit in the matching NSEC (or 256 NSEC3) RR (proving that there is, indeed, a delegation), or 257 alternately make sure that the delegation is covered by an NSEC3 RR 258 with the Opt-Out flag set. 260 Without this check, an attacker could reuse an NSEC or NSEC3 RR 261 matching a non-delegation name to spoof an unsigned delegation at 262 that name. This would claim that an existing signed RRset (or set of 263 signed RRsets) is below an unsigned delegation, thus not signed and 264 vulnerable to further attack. 266 5. Interoperability Concerns 268 5.1. Errors in Canonical Form Type Code List 270 When canonicalizing DNS names (for both ordering and signing), DNS 271 names in the RDATA section of NSEC resource records are not 272 downcased. DNS names in the RDATA section of RRSIG resource records 273 are downcased. 275 The guidance in the above paragraph differs from what has been 276 published before but is consistent with current common practice. 277 [RFC4034] Section 6.2 item 3 says that names in both of these RR 278 types should be downcased. The earlier [RFC3755] says that they 279 should not. Current practice follows neither document fully. 281 Section 6.2 of RFC4034 also erroneously lists HINFO as a record that 282 needs downcasing, and twice at that. Since HINFO records contain no 283 domain names, they are not subject to downcasing. 285 5.2. Unknown DS Message Digest Algorithms 287 Section 5.2 of [RFC4035] includes rules for how to handle delegations 288 to zones that are signed with entirely unsupported public key 289 algorithms, as indicated by the key algorithms shown in those zone's 290 DS RRsets. It does not explicitly address how to handle DS records 291 that use unsupported message digest algorithms. In brief, DS records 292 using unknown or unsupported message digest algorithms MUST be 293 treated the same way as DS records referring to DNSKEY RRs of unknown 294 or unsupported public key algorithms. 296 The existing text says: 298 If the validator does not support any of the algorithms listed in 299 an authenticated DS RRset, then the resolver has no supported 300 authentication path leading from the parent to the child. The 301 resolver should treat this case as it would the case of an 302 authenticated NSEC RRset proving that no DS RRset exists, as 303 described above. 305 In other words, when determining the security status of a zone, a 306 validator disregards any authenticated DS records that specify 307 unknown or unsupported DNSKEY algorithms. If none are left, the zone 308 is treated as if it were unsigned. 310 This document modifies the above text to additionally disregard 311 authenticated DS records using unknown or unsupported message digest 312 algorithms. 314 5.3. Private Algorithms 316 As discussed above, Section 5.2 of [RFC4035] requires that validators 317 make decisions about the security status of zones based on the public 318 key algorithms shown in the DS records for those zones. In the case 319 of private algorithms, as described in [RFC4034] Appendix A.1.1, the 320 eight-bit algorithm field in the DS RR is not conclusive about what 321 algorithm(s) is actually in use. 323 If no private algorithms appear in the DS RRset, or if any supported 324 algorithm appears in the DS RRset, no special processing is needed. 325 Furthermore, if the validator implementation does not support any 326 private algorithms, or only supports private algorithms using an 327 algorithm number not present in the DS RRset, no special processing 328 is needed. 330 In the remaining cases, the security status of the zone depends on 331 whether or not the resolver supports any of the private algorithms in 332 use (provided that these DS records use supported message digest 333 algorithms, as discussed in Section 5.2 of this document). In these 334 cases, the resolver MUST retrieve the corresponding DNSKEY for each 335 private algorithm DS record and examine the public key field to 336 determine the algorithm in use. The security-aware resolver MUST 337 ensure that the hash of the DNSKEY RR's owner name and RDATA matches 338 the digest in the DS RR as described in Section 5.2 of [RFC4035], 339 authenticating the DNSKEY. If all of the retrieved and authenticated 340 DNSKEY RRs use unknown or unsupported private algorithms, then the 341 zone is treated as if it were unsigned. 343 Note that if none of the private algorithm DS RRs can be securely 344 matched to DNSKEY RRs and no other DS establishes that the zone is 345 secure, the referral should be considered Bogus data as discussed in 347 [RFC4035]. 349 This clarification facilitates the broader use of private algorithms, 350 as suggested by [RFC4955]. 352 5.4. Caution About Local Policy and Multiple RRSIGs 354 When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 355 suggests that "the local resolver security policy determines whether 356 the resolver also has to test these RRSIG RRs and how to resolve 357 conflicts if these RRSIG RRs lead to differing results." 359 This document specifies that a resolver SHOULD accept any valid RRSIG 360 as sufficient, and only determine that an RRset is Bogus if all 361 RRSIGs fail validation. 363 If a resolver adopts a more restrictive policy, there's a danger that 364 properly-signed data might unnecessarily fail validation due to cache 365 timing issues. Furthermore, certain zone management techniques, like 366 the Double Signature Zone-signing Key Rollover method described in 367 section 4.2.1.2 of [RFC4641], will not work reliably. Such a 368 resolver is also vulnerable to malicious insertion of gibberish 369 signatures. 371 5.5. Key Tag Calculation 373 [RFC4034] Appendix B.1 incorrectly defines the Key Tag field 374 calculation for algorithm 1. It correctly says that the Key Tag is 375 the most significant 16 of the least significant 24 bits of the 376 public key modulus. However, [RFC4034] then goes on to incorrectly 377 say that this is 4th to last and 3rd to last octets of the public key 378 modulus. It is, in fact, the 3rd to last and 2nd to last octets. 380 5.6. Setting the DO Bit on Replies 382 As stated in Section 3 of [RFC3225], the DO bit of the query MUST be 383 copied in the response. However, in order to interoperate with 384 implementations that ignore this rule on sending, resolvers MUST 385 ignore the DO bit in responses. 387 5.7. Setting the AD Bit on Queries 389 The semantics of the AD bit in the query were previously undefined. 390 Section 4.6 of [RFC4035] instructed resolvers to always clear the AD 391 bit when composing queries. 393 This document defines setting the AD bit in a query as a signal 394 indicating that the requester understands and is interested in the 395 value of the AD bit in the response. This allows a requestor to 396 indicate that it understands the AD bit without also requesting 397 DNSSEC data via the DO bit. 399 5.8. Setting the AD Bit on Replies 401 Section 3.2.3 of [RFC4035] describes under which conditions a 402 validating resolver should set or clear the AD bit in a response. In 403 order to interoperate with legacy stub resolvers and middleboxes that 404 neither understand nor ignore the AD bit, validating resolvers SHOULD 405 only set the AD bit when a response both meets the conditions listed 406 in RFC 4035, section 3.2.3, and the request contained either a set DO 407 bit or a set AD bit. 409 5.9. Always set the CD bit on Queries 411 When processing a request with the CD bit set, a resolver SHOULD 412 attempt to return all response data, even data that has failed DNSSEC 413 validation. RFC4035 section 3.2.2 requires a resolver processing a 414 request with the CD bit set to set the CD bit on its upstream 415 queries. 417 This document further specifies that validating resolvers SHOULD set 418 the CD bit on every upstream query. This is regardless of whether 419 the CD bit was set on the incoming query or whether it has a trust 420 anchor at or above the QNAME. 422 [RFC4035] is ambiguous about what to do when a cached response was 423 obtained with the CD bit unset, a case that only arises when the 424 resolver chooses not to set the CD bit on all upstream queries, as 425 specified above. In the typical case, no new query is required, nor 426 does the cache need to track the state of the CD bit used to make a 427 given query. The problem arises when the cached response is a server 428 failure (RCODE 2), which may indicate that the requested data failed 429 DNSSEC validation at an upstream validating resolver. ([RFC2308] 430 permits caching of server failures for up to five minutes.) In these 431 cases, a new query with the CD bit set is required. 433 Appendix B discusses more of the logic behind the recommendation 434 presented in this section. 436 5.10. Nested Trust Anchors 438 A DNSSEC validator may be configured such that, for a given response, 439 more than one trust anchor could be used to validate the chain of 440 trust to the response zone. For example, imagine a validator 441 configured with trust anchors for "example." and "zone.example." 442 When the validator is asked to validate a response to 443 "www.sub.zone.example.", either trust anchor could apply. 445 When presented with this situation, DNSSEC validators have a choice 446 of which trust anchor(s) to use. Which to use is a matter of 447 implementation choice. Appendix C discusses several possible 448 algorithms. 450 It is possible and advisable to expose the choice of policy as a 451 configuration option. As a default, it is suggested that validators 452 implement the "Accept Any Success" policy described in Appendix C.2 453 while exposing other policies as configuration options. 455 The "Accept Any Success" policy is to try all applicable trust 456 anchors until one gives a validation result of Secure, in which case 457 the final validation result is Secure. If and only if all applicable 458 trust anchors give a result of Insecure, the final validation result 459 is Insecure. If one or more trust anchors lead to a Bogus result and 460 there is no Secure result, then the final validation result is Bogus. 462 5.11. Mandatory Algorithm Rules 464 The last paragraph of RFC4035 Section 2.2 includes rules describing 465 which algorithms must be used to sign a zone. Since these rules have 466 been confusing, they are restated using different language here: 468 The DS RRset and DNSKEY RRset are used to signal which algorithms 469 are used to sign a zone. The presence of an algorithm in either a 470 zone's DS or DNSKEY RRset signals that that algorithm is used to 471 sign the entire zone. 473 A signed zone MUST include a DNSKEY for each algorithm present in 474 the zone's DS RRset and expected trust anchors for the zone. The 475 zone MUST also be signed with each algorithm (though not each key) 476 present in the DNSKEY RRset. It is possible to add algorithms at 477 the DNSKEY that aren't in the DS record, but not vice-versa. If 478 more than one key of the same algorithm is in the DNSKEY RRset, it 479 is sufficient to sign each RRset with any subset of these DNSKEYs. 480 It is acceptable to sign some RRsets with one subset of keys (or 481 key) and other RRsets with a different subset, so long as at least 482 one DNSKEY of each algorithm is used to sign each RRset. 483 Likewise, if there are DS records for multiple keys of the same 484 algorithm, any subset of those may appear in the DNSKEY RRset. 486 This requirement applies to servers, not validators. Validators 487 SHOULD accept any single valid path. They SHOULD NOT insist that all 488 algorithms signaled in the DS RRset work, and they MUST NOT insist 489 that all algorithms signaled in the DNSKEY RRset work. A validator 490 MAY have a configuration option to perform a signature completeness 491 test to support troubleshooting. 493 5.12. Ignore Extra Signatures From Unknown Keys 495 Validating resolvers MUST disregard RRSIGs in a zone that do not 496 (currently) have a corresponding DNSKEY in the zone. Similarly, a 497 validating resolver MUST disregard RRSIGs with algorithm types that 498 don't exist in the DNSKEY RRset. 500 Good key rollover and algorithm rollover practices, as discussed in 501 RFC4641 and its successor documents and as suggested by the rules in 502 the previous section, may require that such RRSIGs be present in a 503 zone. 505 6. Minor Corrections and Clarifications 507 6.1. Finding Zone Cuts 509 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 510 for a parent zone but does not state how to find those servers. 511 Specific instructions can be found in Section 4.2 of [RFC4035]. 513 6.2. Clarifications on DNSKEY Usage 515 It is possible to use different DNSKEYs to sign different subsets of 516 a zone, constrained only by the rules in Section 5.11. It is even 517 possible to use a different DNSKEY for each RRset in a zone, subject 518 only to practical limits on the size of the DNSKEY RRset and the 519 above rules. However, be aware that there is no way to tell 520 resolvers what a particular DNSKEY is supposed to be used for -- any 521 DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate 522 any RRset in the zone. For example, if a weaker or less trusted 523 DNSKEY is being used to authenticate NSEC RRsets or all dynamically 524 updated records, that same DNSKEY can also be used to sign any other 525 RRsets from the zone. 527 Furthermore, note that the SEP bit setting has no effect on how a 528 DNSKEY may be used -- the validation process is specifically 529 prohibited from using that bit by [RFC4034] section 2.1.2. It is 530 possible to use a DNSKEY without the SEP bit set as the sole secure 531 entry point to the zone, yet use a DNSKEY with the SEP bit set to 532 sign all RRsets in the zone (other than the DNSKEY RRset). It is 533 also possible to use a single DNSKEY, with or without the SEP bit 534 set, to sign the entire zone, including the DNSKEY RRset itself. 536 6.3. Errors in Examples 538 The text in [RFC4035] Section C.1 refers to the examples in B.1 as 539 "x.w.example.com" while B.1 uses "x.w.example". This is painfully 540 obvious in the second paragraph where it states that the RRSIG labels 541 field value of 3 indicates that the answer was not the result of 542 wildcard expansion. This is true for "x.w.example" but not for 543 "x.w.example.com", which of course has a label count of 4 544 (antithetically, a label count of 3 would imply the answer was the 545 result of a wildcard expansion). 547 The first paragraph of [RFC4035] Section C.6 also has a minor error: 548 the reference to "a.z.w.w.example" should instead be "a.z.w.example", 549 as in the previous line. 551 6.4. Errors in RFC 5155 553 A NSEC3 record that matches an Empty Non-Terminal effectively has no 554 type associated with it. This NSEC3 record has an empty type bit 555 map. Section 3.2.1 of [RFC5155] contains the statement: 557 Blocks with no types present MUST NOT be included. 559 However, the same section contains a regular expression: 561 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 563 The plus sign in the regular expression indicates that there is one 564 or more of the preceding element. This means that there must be at 565 least one window block. If this window block has no types, it 566 contradicts with the first statement. Therefore, the correct text in 567 RFC 5155 3.2.1 should be: 569 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 571 7. IANA Considerations 573 This document specifies no IANA Actions. 575 8. Security Considerations 577 This document adds SHA-2 and NSEC3 support to the core DNSSEC 578 protocol. Security considerations for those features are discussed 579 in the documents defining them. Additionally, this document 580 addresses some ambiguities and omissions in the core DNSSEC documents 581 that, if not recognized and addressed in implementations, could lead 582 to security failures. In particular, the validation algorithm 583 clarifications in Section 4 are critical for preserving the security 584 properties DNSSEC offers. Furthermore, failure to address some of 585 the interoperability concerns in Section 5 could limit the ability to 586 later change or expand DNSSEC, including adding new algorithms. 588 The recommendation in Section 5.9 to always set the CD bit has 589 security implications. By setting the CD bit, a resolver will not 590 benefit from more stringent validation rules or a more complete set 591 of trust anchors at an upstream validator. 593 9. References 595 9.1. Normative References 597 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 598 STD 13, RFC 1034, November 1987. 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 604 RFC 3225, December 2001. 606 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 607 Rose, "DNS Security Introduction and Requirements", 608 RFC 4033, March 2005. 610 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 611 Rose, "Resource Records for the DNS Security Extensions", 612 RFC 4034, March 2005. 614 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 615 Rose, "Protocol Modifications for the DNS Security 616 Extensions", RFC 4035, March 2005. 618 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 619 (DS) Resource Records (RRs)", RFC 4509, May 2006. 621 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 622 Security (DNSSEC) Hashed Authenticated Denial of 623 Existence", RFC 5155, March 2008. 625 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 626 and RRSIG Resource Records for DNSSEC", RFC 5702, 627 October 2009. 629 9.2. Informative References 631 [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, 632 "Roll Over and Die?", February 2010. 634 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 635 NCACHE)", RFC 2308, March 1998. 637 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 638 Signer (DS)", RFC 3755, May 2004. 640 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 641 RFC 4641, September 2006. 643 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 644 July 2007. 646 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 647 Trust Anchors", RFC 5011, September 2007. 649 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 650 November 2007. 652 Appendix A. Acknowledgments 654 The editors would like the thank Rob Austein for his previous work as 655 an editor of this document. 657 The editors are extremely grateful to those who, in addition to 658 finding errors and omissions in the DNSSEC document set, have 659 provided text suitable for inclusion in this document. 661 The lack of specificity about handling private algorithms, as 662 described in Section 5.3, and the lack of specificity in handling ANY 663 queries, as described in Section 4.2, were discovered by David 664 Blacka. 666 The error in algorithm 1 key tag calculation, as described in 667 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 668 contributed text for Section 5.5. 670 The bug relating to delegation NSEC RR's in Section 4.1 was found by 671 Roy Badami. Roy Arends found the related problem with DNAME. 673 The errors in the [RFC4035] examples were found by Roy Arends, who 674 also contributed text for Section 6.3 of this document. 676 Text on the mandatory algorithm rules was derived from suggestions by 677 Matthijs Mekking and Ed Lewis. 679 The CD bit logic was analyzed in depth by David Blacka, Olafur 680 Gudmundsson, Mike St. Johns, and Andrew Sullivan. 682 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 683 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 684 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, 685 Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer, 686 Warren Kumari and Scott Rose for their contributions to this 687 document. 689 Appendix B. Discussion of Setting the CD Bit 691 [RFC4035] may be read as relying on the implicit assumption that 692 there is at most one validating system between the stub resolver and 693 the authoritative server for a given zone. It is entirely possible, 694 however, for more than one validator to exist between a stub resolver 695 and an authoritative server. If these different validators have 696 disjoint trust anchors configured, then it is possible that each 697 would be able to validate some portion of the DNS tree but neither is 698 able to validate all of it. Accordingly, it might be argued that it 699 is desirable not to set the CD bit on upstream queries, because that 700 allows for maximal validation. 702 In section Section 5.9 of this document, it is recommended to set the 703 CD bit on an upstream query even when the incoming query arrives with 704 CD=0. This is for two reasons: it encourages a more predictable 705 validation experience as only one validator is always doing the 706 validation, and it ensures that all DNSSEC data that exists may be 707 available from the local cache should a query with CD=1 arrive. 709 As a matter of policy, it is possible to set the CD bit differently 710 than suggested in Section 5.9. A different choice will, of course, 711 not always yield the benefits listed above. It is beyond the scope 712 of this document to outline all of the considerations and counter 713 considerations for all possible policies. Nevertheless, it is 714 possible to describe three approaches and their underlying philosophy 715 of operation. These are laid out in the tables below. 717 The table that describes each model has five columns. The first 718 column indicates the value of the CD bit that the resolver receives 719 (for instance, on the name server side in an iterative resolver, or 720 as local policy or from the API in the case of a stub). The second 721 column indicates whether the query needs to be forwarded for 722 resolution (F) or can be satisfied from a local cache (C). The third 723 column is a line number, so that it can be referred to later in the 724 table. The fourth column indicates any relevant conditions at the 725 resolver: whether the resolver has a covering trust anchor and so on. 726 If there are no parameters here, the column is empty. The fifth and 727 final column indicates what action the resolver takes. 729 The tables differentiate between "cached data" and "cached RCODE=2". 730 This is a shorthand; the point is that one has to treat RCODE=2 731 (server failure) as special, because it might indicate a validation 732 failure somewhere upstream. The distinction is really between 733 "cached RCODE=2" and "cached everything else". 735 The tables are probably easiest to think of in terms of describing 736 what happens when a stub resolver sends a query to an intermediate 737 resolver, but they are perfectly general and can be applied to any 738 validating resolver. 740 Model 1: "always set" 742 This model is so named because the validating resolver sets the CD 743 bit on queries it makes regardless of whether it has a covering trust 744 anchor for the query. The general philosophy represented by this 745 table is that only one resolver should be responsible for validation 746 irrespective of the possibility that an upstream resolver may be 747 present with trust anchors that cover different or additional QNAMEs. 748 It is the model recommended in Section 5.9 of this document. 750 CD F/C line conditions action 751 ==================================================================== 752 1 F A1 Set CD=1 on upstream query 753 0 F A2 Set CD=1 on upstream query 754 1 C A3 Return the cache contents 755 (data or RCODE=2) 756 0 C A4 no covering TA Return cache contents 757 (data or RCODE=2) 758 0 C A5 covering TA Validate cached result and 759 return it. 761 Model 2: "never set when receiving CD=0" 763 This model is so named because it sets CD=0 on upstream queries for 764 all received CD=0 queries even if it has a covering trust anchor. 765 The general philosophy represented by this table is that more than 766 one resolver may take responsibility for validating a QNAME and that 767 a validation failure for a QNAME by any resolver in the chain is a 768 validation failure for the query. Using this model is NOT 769 RECOMMENDED. 771 CD F/C line conditions action 772 ==================================================================== 773 1 F N1 Set CD=1 on upstream query 774 0 F N2 Set CD=0 on upstream query 775 1 C N3 cached data Return cached data 776 1 C N4 cached RCODE=2 Treat as line N1 777 0 C N5 no covering TA Return cache contents 778 (data or RCODE=2) 779 0 C N6 covering TA & Treat as line N2 780 cached data was 781 generated with CD=1 782 0 C N7 covering TA & Validate and return 783 cached data was 784 generated with CD=0 786 Model 3: "sometimes set" 788 This model is so named because it sets the CD bit on upstream queries 789 triggered by received CD=0 queries based on whether the validator has 790 a trust anchor configured that covers the query. If there is no 791 covering trust anchor, the resolver clears the CD bit in the upstream 792 query. If there is a covering trust anchor, the resolver sets CD=1 793 and performs validation itself. The general philosophy represented 794 by this table is that a resolver should try and validate QNAMEs for 795 which is has trust anchors and should not preclude validation by 796 other resolvers for QNAMEs for which it does not have covering trust 797 anchors. Using this model is NOT RECOMMENDED. 799 CD F/C line conditions action 800 ==================================================================== 801 1 F S1 Set CD=1 on upstream query 802 0 F S2 covering TA Set CD=1 on upstream query 803 0 F S3 no covering TA Set CD=0 on upstream query 804 1 C S4 cached data Return cached data 805 1 C S5 cached RCODE=2 Treat as line S1 806 0 C S6 cached data was Return cache contents 807 generated with 808 CD=0 809 0 C S7 cached data was Validate & return cache 810 generated with contents 811 CD=1 & 812 covering TA 813 0 C S8 cached RCODE=2 Return cache contents 814 0 C S9 cached data Treat as line S3 815 was generated 816 with CD=1 & 817 no covering 818 TA 820 Appendix C. Discussion of Trust Anchor Preference Options 822 This section presents several different policies for validating 823 resolvers to use when they have a choice of trust anchors available 824 for validating a given answer. 826 C.1. Closest Encloser 828 One policy is to choose the trust anchor closest to the QNAME of the 829 response. For example, consider a validator configured with trust 830 anchors for "example." and "zone.example." When asked to validate a 831 response for "www.sub.zone.example.", a validator using the "Closest 832 Encloser" policy would choose the "zone.example." trust anchor. 834 This policy has the advantage of allowing the operator to trivially 835 override a parent zone's trust anchor with one that the operator can 836 validate in a stronger way, perhaps because the resolver operator is 837 affiliated with the zone in question. This policy also minimizes the 838 number of public key operations needed, which is of benefit in 839 resource-constrained environments. 841 This policy has the disadvantage of giving the user some unexpected 842 and unnecessary validation failures when sub-zone trust anchors are 843 neglected. As a concrete example, consider a validator that 844 configured a trust anchor for "zone.example." in 2009 and one for 845 "example." in 2011. In 2012, "zone.example." rolls its KSK and 846 updates its DS records, but the validator operator doesn't update its 847 trust anchor. With the "closest encloser" policy, the validator gets 848 validation failures. 850 C.2. Accept Any Success 852 Another policy is to try all applicable trust anchors until one gives 853 a validation result of Secure, in which case the final validation 854 result is Secure. If and only if all applicable trust anchors give a 855 result of Insecure, the final validation result is Insecure. If one 856 or more trust anchors lead to a Bogus result and there is no Secure 857 result, then the final validation result is Bogus. 859 This has the advantage of causing the fewest validation failures, 860 which may deliver a better user experience. If one trust anchor is 861 out of date (as in our above example), the user may still be able to 862 get a Secure validation result (and see DNS responses). 864 This policy has the disadvantage of making the validator subject to 865 the compromise of the weakest of these trust anchors while making it 866 relatively painless to keep old trust anchors configured in 867 perpetuity. 869 C.3. Preference Based on Source 871 When the trust anchors have come from different sources (e.g. 872 automated updates ([RFC5011]), one or more DLV registries 873 ([RFC5074]), and manually configured), a validator may wish to choose 874 between them based on the perceived reliability of those sources. 875 The order of precedence might be exposed as a configuration option. 877 For example, a validator might choose to prefer trust anchors found 878 in a DLV registry over those manually configured on the theory that 879 the manually configured ones will not be as aggressively maintained. 881 Conversely, a validator might choose to prefer manually configured 882 trust anchors over those obtained from a DLV registry on the theory 883 that the manually configured ones have been more carefully 884 authenticated. 886 Or the validator might do something more complex: prefer a sub-set of 887 manually configured trust anchors (based on a configuration option), 888 then trust anchors that have been updated using the RFC5011 889 mechanism, then trust anchors from one DLV registry, then trust 890 anchors from a different DLV registry, then the rest of the manually 891 configured trust anchors. 893 Authors' Addresses 895 Samuel Weiler 896 SPARTA, Inc. 897 7110 Samuel Morse Drive 898 Columbia, Maryland 21046 899 US 901 Email: weiler@tislabs.com 903 David Blacka 904 Verisign, Inc. 905 12061 Bluemont Way 906 Reston, VA 20190 907 US 909 Email: davidb@verisign.com