1 Internet Engineering Task Force (IETF) S. Weiler, Ed. 2 Request for Comments: 6840 SPARTA, Inc. 3 Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed. 4 Category: Standards Track Verisign, Inc. 5 ISSN: 2070-1721 February 2013 6 7 8 Clarifications and Implementation Notes for DNS Security (DNSSEC) 9 10 Abstract 11 12 This document is a collection of technical clarifications to the DNS 13 Security (DNSSEC) document set. It is meant to serve as a resource 14 to implementors as well as a collection of DNSSEC errata that existed 15 at the time of writing. 16 17 This document updates the core DNSSEC documents (RFC 4033, RFC 4034, 18 and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also 19 defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the 20 DNSSEC specification. 21 22 Status of This Memo 23 24 This is an Internet Standards Track document. 25 26 This document is a product of the Internet Engineering Task Force 27 (IETF). It represents the consensus of the IETF community. It has 28 received public review and has been approved for publication by the 29 Internet Engineering Steering Group (IESG). Further information on 30 Internet Standards is available in Section 2 of RFC 5741. 31 32 Information about the current status of this document, any errata, 33 and how to provide feedback on it may be obtained at 34 http://www.rfc-editor.org/info/rfc6840. 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 Weiler & Blacka Standards Track [Page 1] 53 RFC 6840 DNSSEC Implementation Notes February 2013 54 55 56 Copyright Notice 57 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 60 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 70 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 Weiler & Blacka Standards Track [Page 2] 108 RFC 6840 DNSSEC Implementation Notes February 2013 109 110 111 Table of Contents 112 113 1. Introduction and Terminology ....................................4 114 1.1. Structure of This Document .................................4 115 1.2. Terminology ................................................4 116 2. Important Additions to DNSSEC ...................................4 117 2.1. NSEC3 Support ..............................................4 118 2.2. SHA-2 Support ..............................................5 119 3. Scaling Concerns ................................................5 120 3.1. Implement a BAD Cache ......................................5 121 4. Security Concerns ...............................................5 122 4.1. Clarifications on Nonexistence Proofs ......................5 123 4.2. Validating Responses to an ANY Query .......................6 124 4.3. Check for CNAME ............................................6 125 4.4. Insecure Delegation Proofs .................................7 126 5. Interoperability Concerns .......................................7 127 5.1. Errors in Canonical Form Type Code List ....................7 128 5.2. Unknown DS Message Digest Algorithms .......................7 129 5.3. Private Algorithms .........................................8 130 5.4. Caution about Local Policy and Multiple RRSIGs .............9 131 5.5. Key Tag Calculation ........................................9 132 5.6. Setting the DO Bit on Replies ..............................9 133 5.7. Setting the AD Bit on Queries .............................10 134 5.8. Setting the AD Bit on Replies .............................10 135 5.9. Always Set the CD Bit on Queries ..........................10 136 5.10. Nested Trust Anchors .....................................11 137 5.11. Mandatory Algorithm Rules ................................11 138 5.12. Ignore Extra Signatures from Unknown Keys ................12 139 6. Minor Corrections and Clarifications ...........................12 140 6.1. Finding Zone Cuts .........................................12 141 6.2. Clarifications on DNSKEY Usage ............................12 142 6.3. Errors in Examples ........................................13 143 6.4. Errors in RFC 5155 ........................................13 144 7. Security Considerations ........................................13 145 8. References .....................................................14 146 8.1. Normative References ......................................14 147 8.2. Informative References ....................................15 148 Appendix A. Acknowledgments .......................................16 149 Appendix B. Discussion of Setting the CD Bit ......................16 150 Appendix C. Discussion of Trust Anchor Preference Options .........19 151 C.1. Closest Encloser ..........................................19 152 C.2. Accept Any Success ........................................20 153 C.3. Preference Based on Source ................................20 154 155 156 157 158 159 160 161 162 Weiler & Blacka Standards Track [Page 3] 163 RFC 6840 DNSSEC Implementation Notes February 2013 164 165 166 1. Introduction and Terminology 167 168 This document lists some additions, clarifications, and corrections 169 to the core DNSSEC specification, as originally described in 170 [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. 171 (See Section 2 for more recent additions to that core document set.) 172 173 It is intended to serve as a resource for implementors and as a 174 repository of items existing at the time of writing that need to be 175 addressed when advancing the DNSSEC documents along the Standards 176 Track. 177 178 1.1. Structure of This Document 179 180 The clarifications and changes to DNSSEC are sorted according to 181 their importance, starting with ones which could, if ignored, lead to 182 security problems and progressing down to clarifications that are 183 expected to have little operational impact. 184 185 1.2. Terminology 186 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in 190 [RFC2119]. 191 192 2. Important Additions to DNSSEC 193 194 This section lists some documents that are now considered core DNSSEC 195 protocol documents in addition to those originally specified in 196 Section 10 of [RFC4033]. 197 198 2.1. NSEC3 Support 199 200 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM 201 records for hashed denial of existence. Validator implementations 202 are strongly encouraged to include support for NSEC3 because a number 203 of highly visible zones use it. Validators that do not support 204 validation of responses using NSEC3 will be hampered in validating 205 large portions of the DNS space. 206 207 [RFC5155] is now considered part of the DNS Security Document Family 208 as described by Section 10 of [RFC4033]. 209 210 211 212 213 214 215 216 217 Weiler & Blacka Standards Track [Page 4] 218 RFC 6840 DNSSEC Implementation Notes February 2013 219 220 221 Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3- 222 SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512) 223 signal that a zone might be using NSEC3, rather than NSEC. The zone 224 may be using either, and validators supporting these algorithms MUST 225 support both NSEC3 and NSEC responses. 226 227 2.2. SHA-2 Support 228 229 [RFC4509] describes the use of SHA-256 as a digest algorithm in 230 Delegation Signer (DS) RRs. [RFC5702] describes the use of the 231 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. 232 Validator implementations are strongly encouraged to include support 233 for these algorithms for DS, DNSKEY, and RRSIG records. 234 235 Both [RFC4509] and [RFC5702] are now considered part of the DNS 236 Security Document Family as described by Section 10 of [RFC4033]. 237 238 3. Scaling Concerns 239 240 3.1. Implement a BAD Cache 241 242 Section 4.7 of [RFC4035] permits security-aware resolvers to 243 implement a BAD cache. That guidance has changed: security-aware 244 resolvers SHOULD implement a BAD cache as described in [RFC4035]. 245 246 This change in guidance is based on operational experience with 247 DNSSEC administrative errors leading to significant increases in DNS 248 traffic, with an accompanying realization that such events are more 249 likely and more damaging than originally supposed. An example of one 250 such event is documented in "Rolling Over DNSSEC Keys" [Huston]. 251 252 4. Security Concerns 253 254 This section provides clarifications that, if overlooked, could lead 255 to security issues. 256 257 4.1. Clarifications on Nonexistence Proofs 258 259 Section 5.4 of [RFC4035] under-specifies the algorithm for checking 260 nonexistence proofs. In particular, the algorithm as presented would 261 allow a validator to interpret an NSEC or NSEC3 RR from an ancestor 262 zone as proving the nonexistence of an RR in a child zone. 263 264 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: 265 266 o the NS bit set, 267 268 o the Start of Authority (SOA) bit clear, and 269 270 271 272 Weiler & Blacka Standards Track [Page 5] 273 RFC 6840 DNSSEC Implementation Notes February 2013 274 275 276 o a signer field that is shorter than the owner name of the NSEC RR, 277 or the original owner name for the NSEC3 RR. 278 279 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume 280 nonexistence of any RRs below that zone cut, which include all RRs at 281 that (original) owner name other than DS RRs, and all RRs below that 282 owner name regardless of type. 283 284 Similarly, the algorithm would also allow an NSEC RR at the same 285 owner name as a DNAME RR, or an NSEC3 RR at the same original owner 286 name as a DNAME, to prove the nonexistence of names beneath that 287 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used 288 to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's 289 (original) owner name. 290 291 4.2. Validating Responses to an ANY Query 292 293 [RFC4035] does not address how to validate responses when QTYPE=*. 294 As described in Section 6.2.2 of [RFC1034], a proper response to 295 QTYPE=* may include a subset of the RRsets at a given name. That is, 296 it is not necessary to include all RRsets at the QNAME in the 297 response. 298 299 When validating a response to QTYPE=*, all received RRsets that match 300 QNAME and QCLASS MUST be validated. If any of those RRsets fail 301 validation, the answer is considered Bogus. If there are no RRsets 302 matching QNAME and QCLASS, that fact MUST be validated according to 303 the rules in Section 5.4 of [RFC4035] (as clarified in this 304 document). To be clear, a validator must not expect to receive all 305 records at the QNAME in response to QTYPE=*. 306 307 4.3. Check for CNAME 308 309 Section 5 of [RFC4035] says nothing explicit about validating 310 responses based on (or that should be based on) CNAMEs. When 311 validating a NOERROR/NODATA response, validators MUST check the CNAME 312 bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the 313 bit for the query type. 314 315 Without this check, an attacker could successfully transform a 316 positive CNAME response into a NOERROR/NODATA response by (for 317 example) simply stripping the CNAME RRset from the response. A naive 318 validator would then note that the QTYPE was not present in the 319 matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was 320 set; thus, the response should have been a positive CNAME response. 321 322 323 324 325 326 327 Weiler & Blacka Standards Track [Page 6] 328 RFC 6840 DNSSEC Implementation Notes February 2013 329 330 331 4.4. Insecure Delegation Proofs 332 333 Section 5.2 of [RFC4035] specifies that a validator, when proving a 334 delegation is not secure, needs to check for the absence of the DS 335 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also 336 MUST check for the presence of the NS bit in the matching NSEC (or 337 NSEC3) RR (proving that there is, indeed, a delegation), or 338 alternately make sure that the delegation is covered by an NSEC3 RR 339 with the Opt-Out flag set. 340 341 Without this check, an attacker could reuse an NSEC or NSEC3 RR 342 matching a non-delegation name to spoof an unsigned delegation at 343 that name. This would claim that an existing signed RRset (or set of 344 signed RRsets) is below an unsigned delegation, thus not signed and 345 vulnerable to further attack. 346 347 5. Interoperability Concerns 348 349 5.1. Errors in Canonical Form Type Code List 350 351 When canonicalizing DNS names (for both ordering and signing), DNS 352 names in the RDATA section of NSEC resource records are not converted 353 to lowercase. DNS names in the RDATA section of RRSIG resource 354 records are converted to lowercase. 355 356 The guidance in the above paragraph differs from what has been 357 published before but is consistent with current common practice. 358 Item 3 of Section 6.2 of [RFC4034] says that names in both of these 359 RR types should be converted to lowercase. The earlier [RFC3755] 360 says that they should not. Current practice follows neither document 361 fully. 362 363 Section 6.2 of [RFC4034] also erroneously lists HINFO as a record 364 that needs conversion to lowercase, and twice at that. Since HINFO 365 records contain no domain names, they are not subject to case 366 conversion. 367 368 5.2. Unknown DS Message Digest Algorithms 369 370 Section 5.2 of [RFC4035] includes rules for how to handle delegations 371 to zones that are signed with entirely unsupported public key 372 algorithms, as indicated by the key algorithms shown in those zones' 373 DS RRsets. It does not explicitly address how to handle DS records 374 that use unsupported message digest algorithms. In brief, DS records 375 using unknown or unsupported message digest algorithms MUST be 376 treated the same way as DS records referring to DNSKEY RRs of unknown 377 or unsupported public key algorithms. 378 379 380 381 382 Weiler & Blacka Standards Track [Page 7] 383 RFC 6840 DNSSEC Implementation Notes February 2013 384 385 386 The existing text says: 387 388 If the validator does not support any of the algorithms listed in 389 an authenticated DS RRset, then the resolver has no supported 390 authentication path leading from the parent to the child. The 391 resolver should treat this case as it would the case of an 392 authenticated NSEC RRset proving that no DS RRset exists, as 393 described above. 394 395 In other words, when determining the security status of a zone, a 396 validator disregards any authenticated DS records that specify 397 unknown or unsupported DNSKEY algorithms. If none are left, the zone 398 is treated as if it were unsigned. 399 400 This document modifies the above text to additionally disregard 401 authenticated DS records using unknown or unsupported message digest 402 algorithms. 403 404 5.3. Private Algorithms 405 406 As discussed above, Section 5.2 of [RFC4035] requires that validators 407 make decisions about the security status of zones based on the public 408 key algorithms shown in the DS records for those zones. In the case 409 of private algorithms, as described in Appendix A.1.1 of [RFC4034], 410 the eight-bit algorithm field in the DS RR is not conclusive about 411 what algorithm(s) is actually in use. 412 413 If no private algorithms appear in the DS RRset, or if any supported 414 algorithm appears in the DS RRset, no special processing is needed. 415 Furthermore, if the validator implementation does not support any 416 private algorithms, or only supports private algorithms using an 417 algorithm number not present in the DS RRset, no special processing 418 is needed. 419 420 In the remaining cases, the security status of the zone depends on 421 whether or not the resolver supports any of the private algorithms in 422 use (provided that these DS records use supported message digest 423 algorithms, as discussed in Section 5.2 of this document). In these 424 cases, the resolver MUST retrieve the corresponding DNSKEY for each 425 private algorithm DS record and examine the public key field to 426 determine the algorithm in use. The security-aware resolver MUST 427 ensure that the hash of the DNSKEY RR's owner name and RDATA matches 428 the digest in the DS RR as described in Section 5.2 of [RFC4035], 429 authenticating the DNSKEY. If all of the retrieved and authenticated 430 DNSKEY RRs use unknown or unsupported private algorithms, then the 431 zone is treated as if it were unsigned. 432 433 434 435 436 437 Weiler & Blacka Standards Track [Page 8] 438 RFC 6840 DNSSEC Implementation Notes February 2013 439 440 441 Note that if none of the private algorithm DS RRs can be securely 442 matched to DNSKEY RRs and no other DS establishes that the zone is 443 secure, the referral should be considered Bogus data as discussed in 444 [RFC4035]. 445 446 This clarification facilitates the broader use of private algorithms, 447 as suggested by [RFC4955]. 448 449 5.4. Caution about Local Policy and Multiple RRSIGs 450 451 When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] 452 suggests that "the local resolver security policy determines whether 453 the resolver also has to test these RRSIG RRs and how to resolve 454 conflicts if these RRSIG RRs lead to differing results". 455 456 This document specifies that a resolver SHOULD accept any valid RRSIG 457 as sufficient, and only determine that an RRset is Bogus if all 458 RRSIGs fail validation. 459 460 If a resolver adopts a more restrictive policy, there's a danger that 461 properly signed data might unnecessarily fail validation due to cache 462 timing issues. Furthermore, certain zone management techniques, like 463 the Double Signature Zone Signing Key Rollover method described in 464 Section 22.214.171.124 of [RFC6781], will not work reliably. Such a 465 resolver is also vulnerable to malicious insertion of gibberish 466 signatures. 467 468 5.5. Key Tag Calculation 469 470 Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field 471 calculation for algorithm 1. It correctly says that the Key Tag is 472 the most significant 16 of the least significant 24 bits of the 473 public key modulus. However, [RFC4034] then goes on to incorrectly 474 say that this is fourth-to-last and third-to-last octets of the 475 public key modulus. It is, in fact, the third-to-last and second-to- 476 last octets. 477 478 5.6. Setting the DO Bit on Replies 479 480 As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the 481 query MUST be copied in the response. However, in order to 482 interoperate with implementations that ignore this rule on sending, 483 resolvers MUST ignore the DO bit in responses. 484 485 486 487 488 489 490 491 492 Weiler & Blacka Standards Track [Page 9] 493 RFC 6840 DNSSEC Implementation Notes February 2013 494 495 496 5.7. Setting the AD Bit on Queries 497 498 The semantics of the Authentic Data (AD) bit in the query were 499 previously undefined. Section 4.6 of [RFC4035] instructed resolvers 500 to always clear the AD bit when composing queries. 501 502 This document defines setting the AD bit in a query as a signal 503 indicating that the requester understands and is interested in the 504 value of the AD bit in the response. This allows a requester to 505 indicate that it understands the AD bit without also requesting 506 DNSSEC data via the DO bit. 507 508 5.8. Setting the AD Bit on Replies 509 510 Section 3.2.3 of [RFC4035] describes under which conditions a 511 validating resolver should set or clear the AD bit in a response. In 512 order to interoperate with legacy stub resolvers and middleboxes that 513 neither understand nor ignore the AD bit, validating resolvers SHOULD 514 only set the AD bit when a response both meets the conditions listed 515 in Section 3.2.3 of [RFC4035], and the request contained either a set 516 DO bit or a set AD bit. 517
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
(This document specifies no IANA Actions.)
(Add following text:)
(This document specifies no IANA Actions.)
(Add following text:)
This document specifies no IANA Actions.
518 5.9. Always Set the CD Bit on Queries 519 520 When processing a request with the Checking Disabled (CD) bit set, a 521 resolver SHOULD attempt to return all response data, even data that 522 has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a 523 resolver processing a request with the CD bit set to set the CD bit 524 on its upstream queries. 525 526 This document further specifies that validating resolvers SHOULD set 527 the CD bit on every upstream query. This is regardless of whether 528 the CD bit was set on the incoming query or whether it has a trust 529 anchor at or above the QNAME. 530 531 [RFC4035] is ambiguous about what to do when a cached response was 532 obtained with the CD bit unset, a case that only arises when the 533 resolver chooses not to set the CD bit on all upstream queries, as 534 specified above. In the typical case, no new query is required, nor 535 does the cache need to track the state of the CD bit used to make a 536 given query. The problem arises when the cached response is a server 537 failure (RCODE 2), which may indicate that the requested data failed 538 DNSSEC validation at an upstream validating resolver. ([RFC2308] 539 permits caching of server failures for up to five minutes.) In these 540 cases, a new query with the CD bit set is required. 541 542 Appendix B discusses more of the logic behind the recommendation 543 presented in this section. 544 545 546 547 Weiler & Blacka Standards Track [Page 10] 548 RFC 6840 DNSSEC Implementation Notes February 2013 549 550 551 5.10. Nested Trust Anchors 552 553 A DNSSEC validator may be configured such that, for a given response, 554 more than one trust anchor could be used to validate the chain of 555 trust to the response zone. For example, imagine a validator 556 configured with trust anchors for "example." and "zone.example." 557 When the validator is asked to validate a response to 558 "www.sub.zone.example.", either trust anchor could apply. 559 560 When presented with this situation, DNSSEC validators have a choice 561 of which trust anchor(s) to use. Which to use is a matter of 562 implementation choice. Appendix C discusses several possible 563 algorithms. 564 565 It is possible and advisable to expose the choice of policy as a 566 configuration option. As a default, it is suggested that validators 567 implement the "Accept Any Success" policy described in Appendix C.2 568 while exposing other policies as configuration options. 569 570 The "Accept Any Success" policy is to try all applicable trust 571 anchors until one gives a validation result of Secure, in which case 572 the final validation result is Secure. If and only if all applicable 573 trust anchors give a result of Insecure, the final validation result 574 is Insecure. If one or more trust anchors lead to a Bogus result and 575 there is no Secure result, then the final validation result is Bogus. 576
<p>Section 5.9 - Always set CD=1 on queries. This is not done, as it prevents DNSSEC from working correctly through another recursive server. When talking to a recursive server, the best algorithm is to send CD=0 and then send CD=1 iff SERVFAIL is returned, in case the recursive server has a bad clock and/or bad trust anchor. Alternatively, one can send CD=1 then CD=0 on validation failure, in case the recursive server is under attack or there is stale/bogus authoritative data.</p>
577 5.11. Mandatory Algorithm Rules 578 579 The last paragraph of Section 2.2 of [RFC4035] includes rules 580 describing which algorithms must be used to sign a zone. Since these 581 rules have been confusing, they are restated using different language 582 here: 583 584 The DS RRset and DNSKEY RRset are used to signal which algorithms 585 are used to sign a zone. The presence of an algorithm in either a 586 zone's DS or DNSKEY RRset signals that that algorithm is used to 587 sign the entire zone. 588 589 A signed zone MUST include a DNSKEY for each algorithm present in 590 the zone's DS RRset and expected trust anchors for the zone. The 591 zone MUST also be signed with each algorithm (though not each key) 592 present in the DNSKEY RRset. It is possible to add algorithms at 593 the DNSKEY that aren't in the DS record, but not vice versa. If 594 more than one key of the same algorithm is in the DNSKEY RRset, it 595 is sufficient to sign each RRset with any subset of these DNSKEYs. 596 It is acceptable to sign some RRsets with one subset of keys (or 597 key) and other RRsets with a different subset, so long as at least 598 599 600 601 602 Weiler & Blacka Standards Track [Page 11] 603 RFC 6840 DNSSEC Implementation Notes February 2013 604 605 606 one DNSKEY of each algorithm is used to sign each RRset. 607 Likewise, if there are DS records for multiple keys of the same 608 algorithm, any subset of those may appear in the DNSKEY RRset. 609 610 This requirement applies to servers, not validators. Validators 611 SHOULD accept any single valid path. They SHOULD NOT insist that all 612 algorithms signaled in the DS RRset work, and they MUST NOT insist 613 that all algorithms signaled in the DNSKEY RRset work. A validator 614 MAY have a configuration option to perform a signature completeness 615 test to support troubleshooting. 616 617 5.12. Ignore Extra Signatures from Unknown Keys 618 619 Validating resolvers MUST disregard RRSIGs in a zone that do not 620 (currently) have a corresponding DNSKEY in the zone. Similarly, a 621 validating resolver MUST disregard RRSIGs with algorithm types that 622 don't exist in the DNSKEY RRset. 623 624 Good key rollover and algorithm rollover practices, as discussed in 625 RFC 6781 and its successor documents and as suggested by the rules in 626 the previous section, may require that such RRSIGs be present in a 627 zone. 628 629 6. Minor Corrections and Clarifications 630 631 6.1. Finding Zone Cuts 632 633 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 634 for a parent zone but does not state how to find those servers. 635 Specific instructions can be found in Section 4.2 of [RFC4035]. 636 637 6.2. Clarifications on DNSKEY Usage 638 639 It is possible to use different DNSKEYs to sign different subsets of 640 a zone, constrained only by the rules in Section 5.11. It is even 641 possible to use a different DNSKEY for each RRset in a zone, subject 642 only to practical limits on the size of the DNSKEY RRset and the 643 above rules. However, be aware that there is no way to tell 644 resolvers what a particular DNSKEY is supposed to be used for -- any 645 DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate 646 any RRset in the zone. For example, if a weaker or less trusted 647 DNSKEY is being used to authenticate NSEC RRsets or all dynamically 648 updated records, that same DNSKEY can also be used to sign any other 649 RRsets from the zone. 650 651 Furthermore, note that the SEP bit setting has no effect on how a 652 DNSKEY may be used -- the validation process is specifically 653 prohibited from using that bit by Section 2.1.2 of [RFC4034]. It is 654 655 656 657 Weiler & Blacka Standards Track [Page 12] 658 RFC 6840 DNSSEC Implementation Notes February 2013 659 660 661 possible to use a DNSKEY without the SEP bit set as the sole secure 662 entry point to the zone, yet use a DNSKEY with the SEP bit set to 663 sign all RRsets in the zone (other than the DNSKEY RRset). It is 664 also possible to use a single DNSKEY, with or without the SEP bit 665 set, to sign the entire zone, including the DNSKEY RRset itself. 666 667 6.3. Errors in Examples 668 669 The text in Appendix C.1 of [RFC4035] refers to the examples in 670 Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This 671 is painfully obvious in the second paragraph where it states that the 672 RRSIG labels field value of 3 indicates that the answer was not the 673 result of wildcard expansion. This is true for "x.w.example" but not 674 for "x.w.example.com", which of course has a label count of 4 675 (antithetically, a label count of 3 would imply the answer was the 676 result of a wildcard expansion). 677 678 The first paragraph of Appendix C.6 of [RFC4035] also has a minor 679 error: the reference to "a.z.w.w.example" should instead be 680 "a.z.w.example", as in the previous line. 681 682 6.4. Errors in RFC 5155 683 684 An NSEC3 record that matches an Empty Non-Terminal effectively has no 685 type associated with it. This NSEC3 record has an empty type bit 686 map. Section 3.2.1 of [RFC5155] contains the statement: 687 688 Blocks with no types present MUST NOT be included. 689 690 However, the same section contains a regular expression: 691 692 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 693 694 The plus sign in the regular expression indicates that there is one 695 or more of the preceding element. This means that there must be at 696 least one window block. If this window block has no types, it 697 contradicts with the first statement. Therefore, the correct text in 698 Section 3.2.1 of [RFC5155] should be: 699 700 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 701 702 7. Security Considerations 703 704 This document adds SHA-2 and NSEC3 support to the core DNSSEC 705 protocol. Security considerations for those features are discussed 706 in the documents defining them. Additionally, this document 707 addresses some ambiguities and omissions in the core DNSSEC documents 708 that, if not recognized and addressed in implementations, could lead 709 710 711 712 Weiler & Blacka Standards Track [Page 13] 713 RFC 6840 DNSSEC Implementation Notes February 2013 714 715 716 to security failures. In particular, the validation algorithm 717 clarifications in Section 4 are critical for preserving the security 718 properties DNSSEC offers. Furthermore, failure to address some of 719 the interoperability concerns in Section 5 could limit the ability to 720 later change or expand DNSSEC, including adding new algorithms. 721 722 The recommendation in Section 5.9 to always set the CD bit has 723 security implications. By setting the CD bit, a resolver will not 724 benefit from more stringent validation rules or a more complete set 725 of trust anchors at an upstream validator. 726 727 8. References 728 729 8.1. Normative References 730 731 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 732 STD 13, RFC 1034, November 1987. 733 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 737 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 738 RFC 3225, December 2001. 739 740 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 741 Rose, "DNS Security Introduction and Requirements", 742 RFC 4033, March 2005. 743 744 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 745 Rose, "Resource Records for the DNS Security Extensions", 746 RFC 4034, March 2005. 747 748 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 749 Rose, "Protocol Modifications for the DNS Security 750 Extensions", RFC 4035, March 2005. 751 752 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 753 (DS) Resource Records (RRs)", RFC 4509, May 2006. 754 755 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 756 Security (DNSSEC) Hashed Authenticated Denial of 757 Existence", RFC 5155, March 2008. 758 759 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 760 and RRSIG Resource Records for DNSSEC", RFC 5702, 761 October 2009. 762 763 764 765 766 767 Weiler & Blacka Standards Track [Page 14] 768 RFC 6840 DNSSEC Implementation Notes February 2013 769 770 771 8.2. Informative References 772 773 [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, 774 "Rolling Over DNSSEC Keys", Internet Protocol 775 Journal, Vol. 13, No.1, pp. 2-16, March 2010. 776 777 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 778 NCACHE)", RFC 2308, March 1998. 779 780 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 781 Signer (DS)", RFC 3755, May 2004. 782 783 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 784 July 2007. 785 786 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 787 Trust Anchors", STD 74, RFC 5011, September 2007. 788 789 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 790 November 2007. 791 792 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 793 Operational Practices, Version 2", RFC 6781, 794 December 2012. 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 Weiler & Blacka Standards Track [Page 15] 823 RFC 6840 DNSSEC Implementation Notes February 2013 824 825 826 Appendix A. Acknowledgments 827 828 The editors would like the thank Rob Austein for his previous work as 829 an editor of this document. 830 831 The editors are extremely grateful to those who, in addition to 832 finding errors and omissions in the DNSSEC document set, have 833 provided text suitable for inclusion in this document. 834 835 The lack of specificity about handling private algorithms, as 836 described in Section 5.3, and the lack of specificity in handling ANY 837 queries, as described in Section 4.2, were discovered by David 838 Blacka. 839 840 The error in algorithm 1 key tag calculation, as described in 841 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 842 contributed text for Section 5.5. 843 844 The bug relating to delegation NSEC RR's in Section 4.1 was found by 845 Roy Badami. Roy Arends found the related problem with DNAME. 846 847 The errors in the [RFC4035] examples were found by Roy Arends, who 848 also contributed text for Section 6.3 of this document. 849 850 Text on the mandatory algorithm rules was derived from suggestions by 851 Matthijs Mekking and Ed Lewis. 852 853 The CD bit logic was analyzed in depth by David Blacka, Olafur 854 Gudmundsson, Mike St. Johns, and Andrew Sullivan. 855 856 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 857 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 858 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, 859 Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer, 860 Warren Kumari and Scott Rose for their contributions to this 861 document. 862 863 Appendix B. Discussion of Setting the CD Bit 864 865 [RFC4035] may be read as relying on the implicit assumption that 866 there is at most one validating system between the stub resolver and 867 the authoritative server for a given zone. It is entirely possible, 868 however, for more than one validator to exist between a stub resolver 869 and an authoritative server. If these different validators have 870 disjoint trust anchors configured, then it is possible that each 871 would be able to validate some portion of the DNS tree, but neither 872 873 874 875 876 877 Weiler & Blacka Standards Track [Page 16] 878 RFC 6840 DNSSEC Implementation Notes February 2013 879 880 881 is able to validate all of it. Accordingly, it might be argued that 882 it is desirable not to set the CD bit on upstream queries, because 883 that allows for maximal validation. 884 885 In Section 5.9 of this document, it is recommended to set the CD bit 886 on an upstream query even when the incoming query arrives with CD=0. 887 This is for two reasons: it encourages a more predictable validation 888 experience as only one validator is always doing the validation, and 889 it ensures that all DNSSEC data that exists may be available from the 890 local cache should a query with CD=1 arrive. 891 892 As a matter of policy, it is possible to set the CD bit differently 893 than suggested in Section 5.9. A different choice will, of course, 894 not always yield the benefits listed above. It is beyond the scope 895 of this document to outline all of the considerations and counter 896 considerations for all possible policies. Nevertheless, it is 897 possible to describe three approaches and their underlying philosophy 898 of operation. These are laid out in the tables below. 899 900 The table that describes each model has five columns. The first 901 column indicates the value of the CD bit that the resolver receives 902 (for instance, on the name server side in an iterative resolver, or 903 as local policy or from the API in the case of a stub). The second 904 column indicates whether the query needs to be forwarded for 905 resolution (F) or can be satisfied from a local cache (C). The third 906 column is a line number, so that it can be referred to later in the 907 table. The fourth column indicates any relevant conditions at the 908 resolver, for example, whether the resolver has a covering trust 909 anchor, and so on. If there are no parameters here, the column is 910 empty. The fifth and final column indicates what action the resolver 911 takes. 912 913 The tables differentiate between "cached data" and "cached RCODE=2". 914 This is a shorthand; the point is that one has to treat RCODE=2 915 (server failure) as special, because it might indicate a validation 916 failure somewhere upstream. The distinction is really between 917 "cached RCODE=2" and "cached everything else". 918 919 The tables are probably easiest to think of in terms of describing 920 what happens when a stub resolver sends a query to an intermediate 921 resolver, but they are perfectly general and can be applied to any 922 validating resolver. 923 924 Model 1: "always set" 925 926 This model is so named because the validating resolver sets the CD 927 bit on queries it makes regardless of whether it has a covering trust 928 anchor for the query. The general philosophy represented by this 929 930 931 932 Weiler & Blacka Standards Track [Page 17] 933 RFC 6840 DNSSEC Implementation Notes February 2013 934 935 936 table is that only one resolver should be responsible for validation 937 irrespective of the possibility that an upstream resolver may be 938 present with trust anchors that cover different or additional QNAMEs. 939 It is the model recommended in Section 5.9 of this document. 940 941 CD F/C line conditions action 942 ==================================================================== 943 1 F A1 Set CD=1 on upstream query 944 0 F A2 Set CD=1 on upstream query 945 1 C A3 Return the cache contents 946 (data or RCODE=2) 947 0 C A4 no covering TA Return cache contents 948 (data or RCODE=2) 949 0 C A5 covering TA Validate cached result and 950 return it 951 952 Model 2: "never set when receiving CD=0" 953 954 This model is so named because it sets CD=0 on upstream queries for 955 all received CD=0 queries, even if it has a covering trust anchor. 956 The general philosophy represented by this table is that more than 957 one resolver may take responsibility for validating a QNAME and that 958 a validation failure for a QNAME by any resolver in the chain is a 959 validation failure for the query. Using this model is NOT 960 RECOMMENDED. 961 962 CD F/C line conditions action 963 ==================================================================== 964 1 F N1 Set CD=1 on upstream query 965 0 F N2 Set CD=0 on upstream query 966 1 C N3 cached data Return cached data 967 1 C N4 cached RCODE=2 Treat as line N1 968 0 C N5 no covering TA Return cache contents 969 (data or RCODE=2) 970 0 C N6 covering TA & Treat as line N2 971 cached data was 972 generated with CD=1 973 0 C N7 covering TA & Validate and return 974 cached data was 975 generated with CD=0 976 977 978 Model 3: "sometimes set" 979 980 This model is so named because it sets the CD bit on upstream queries 981 triggered by received CD=0 queries, based on whether the validator 982 has a trust anchor configured that covers the query. If there is no 983 covering trust anchor, the resolver clears the CD bit in the upstream 984 985 986 987 Weiler & Blacka Standards Track [Page 18] 988 RFC 6840 DNSSEC Implementation Notes February 2013 989 990 991 query. If there is a covering trust anchor, the resolver sets CD=1 992 and performs validation itself. The general philosophy represented 993 by this table is that a resolver should try and validate QNAMEs for 994 which it has trust anchors and should not preclude validation by 995 other resolvers for QNAMEs for which it does not have covering trust 996 anchors. Using this model is NOT RECOMMENDED. 997 998 CD F/C line conditions action 999 ==================================================================== 1000 1 F S1 Set CD=1 on upstream query 1001 0 F S2 covering TA Set CD=1 on upstream query 1002 0 F S3 no covering TA Set CD=0 on upstream query 1003 1 C S4 cached data Return cached data 1004 1 C S5 cached RCODE=2 Treat as line S1 1005 0 C S6 cached data was Return cache contents 1006 generated with 1007 CD=0 1008 0 C S7 cached data was Validate & return cache 1009 generated with contents 1010 CD=1 & 1011 covering TA 1012 0 C S8 cached RCODE=2 Return cache contents 1013 0 C S9 cached data Treat as line S3 1014 was generated 1015 with CD=1 & 1016 no covering 1017 TA 1018 1019 1020 Appendix C. Discussion of Trust Anchor Preference Options 1021 1022 This section presents several different policies for validating 1023 resolvers to use when they have a choice of trust anchors available 1024 for validating a given answer. 1025 1026 C.1. Closest Encloser 1027 1028 One policy is to choose the trust anchor closest to the QNAME of the 1029 response. For example, consider a validator configured with trust 1030 anchors for "example." and "zone.example." When asked to validate a 1031 response for "www.sub.zone.example.", a validator using the "Closest 1032 Encloser" policy would choose the "zone.example." trust anchor. 1033 1034 This policy has the advantage of allowing the operator to trivially 1035 override a parent zone's trust anchor with one that the operator can 1036 validate in a stronger way, perhaps because the resolver operator is 1037 1038 1039 1040 1041 1042 Weiler & Blacka Standards Track [Page 19] 1043 RFC 6840 DNSSEC Implementation Notes February 2013 1044 1045 1046 affiliated with the zone in question. This policy also minimizes the 1047 number of public key operations needed, which is of benefit in 1048 resource-constrained environments. 1049 1050 This policy has the disadvantage of giving the user some unexpected 1051 and unnecessary validation failures when sub-zone trust anchors are 1052 neglected. As a concrete example, consider a validator that 1053 configured a trust anchor for "zone.example." in 2009 and one for 1054 "example." in 2011. In 2012, "zone.example." rolls its Key Signing 1055 Key (KSK) and updates its DS records, but the validator operator 1056 doesn't update its trust anchor. With the "Closest Encloser" policy, 1057 the validator gets validation failures. 1058 1059 C.2. Accept Any Success 1060 1061 Another policy is to try all applicable trust anchors until one gives 1062 a validation result of Secure, in which case the final validation 1063 result is Secure. If and only if all applicable trust anchors give a 1064 result of Insecure, the final validation result is Insecure. If one 1065 or more trust anchors lead to a Bogus result and there is no Secure 1066 result, then the final validation result is Bogus. 1067 1068 This has the advantage of causing the fewest validation failures, 1069 which may deliver a better user experience. If one trust anchor is 1070 out of date (as in our above example), the user may still be able to 1071 get a Secure validation result (and see DNS responses). 1072 1073 This policy has the disadvantage of making the validator subject to 1074 the compromise of the weakest of these trust anchors, while making it 1075 relatively painless to keep old trust anchors configured in 1076 perpetuity. 1077
... A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset.
A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. Each authoritative RRset in the zone MUST be signed with each algorithm (though not each key) present in the DNSKEY RRset.
Zones aren't signed (per se), the data sets within them are. But not cut point (NS) and glue. --VERIFIER NOTES-- This erratum is being rejected as the nomenclature being updated is understood within the community and is used in other DNSSEC specifications.
1078 C.3. Preference Based on Source 1079 1080 When the trust anchors have come from different sources (e.g., 1081 automated updates ([RFC5011]), one or more DNSSEC Lookaside 1082 Validation (DLV) registries ([RFC5074]), and manual configuration), a 1083 validator may wish to choose between them based on the perceived 1084 reliability of those sources. The order of precedence might be 1085 exposed as a configuration option. 1086 1087 For example, a validator might choose to prefer trust anchors found 1088 in a DLV registry over those manually configured on the theory that 1089 the manually configured ones will not be as aggressively maintained. 1090 1091 1092 1093 1094 1095 1096 1097 Weiler & Blacka Standards Track [Page 20] 1098 RFC 6840 DNSSEC Implementation Notes February 2013 1099 1100 1101 Conversely, a validator might choose to prefer manually configured 1102 trust anchors over those obtained from a DLV registry on the theory 1103 that the manually configured ones have been more carefully 1104 authenticated. 1105 1106 Or the validator might do something more complex: prefer a sub-set of 1107 manually configured trust anchors (based on a configuration option), 1108 then trust anchors that have been updated using the mechanism in 1109 [RFC5011], then trust anchors from one DLV registry, then trust 1110 anchors from a different DLV registry, then the rest of the manually 1111 configured trust anchors. 1112 1113 Authors' Addresses 1114 1115 Samuel Weiler (editor) 1116 SPARTA, Inc. 1117 7110 Samuel Morse Drive 1118 Columbia, MD 21046 1119 US 1120 1121 EMail: email@example.com 1122 1123 1124 David Blacka (editor) 1125 Verisign, Inc. 1126 12061 Bluemont Way 1127 Reston, VA 20190 1128 US 1129 1130 EMail: firstname.lastname@example.org 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 Weiler & Blacka Standards Track [Page 21] 1153
The abstrct of RFC8749 says:
"Furthermore, this document ... updates RFC 6840 by excluding the DLV registries from the trust anchor selection."
Section 126.96.36.199 of RFC8749 says:
RFC 6840 ("Clarifications and Implementation Notes for DNS Security (DNSSEC)") [RFC6840] states that when trust anchors come from different sources, a validator may choose between them based on the perceived reliability of those sources. But in reality, this does not happen in validators (both BIND 9 and Unbound have an option for a DLV trust anchor that can be used solely as a fallback). This document updates RFC 6840 [RFC6840] to exclude the DLV registries from the trust anchor selection.