idnits 2.17.00 (12 Aug 2021) /tmp/idnits1744/draft-ietf-dnsext-dnssec-bis-updates-16.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 (January 14, 2012) is 3779 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 January 14, 2012 7 Expires: July 17, 2012 9 Clarifications and Implementation Notes for DNSSECbis 10 draft-ietf-dnsext-dnssec-bis-updates-16 12 Abstract 14 This document is a collection of technical clarifications to the 15 DNSSECbis document set. It is meant to serve as a resource to 16 implementors as well as a repository of DNSSECbis errata. 18 This document updates the core DNSSECbis 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 DNSSECbis 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 July 17, 2012. 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 DNSSSECbis . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 6 81 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 6 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 . . . . . . 8 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 . . . . . . . . . . . . . . 9 90 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 9 91 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10 92 5.10.1. Closest Encloser . . . . . . . . . . . . . . . . . . 10 93 5.10.2. Accept Any Success . . . . . . . . . . . . . . . . . 11 94 5.10.3. Preference Based on Source . . . . . . . . . . . . . 11 95 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 12 96 5.12. Expect Extra Signatures From Strange Keys . . . . . . . . 12 97 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 13 98 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 13 99 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 13 100 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13 101 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 14 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 108 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 17 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 111 1. Introduction and Terminology 113 This document lists some additions, clarifications and corrections to 114 the core DNSSECbis specification, as originally described in 115 [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. 116 (See section Section 2 for more recent additions to that core 117 document set.) 119 It is intended to serve as a resource for implementors and as a 120 repository of items that need to be addressed when advancing the 121 DNSSECbis documents from Proposed Standard to Draft Standard. 123 1.1. Structure of this Document 125 The clarifications to DNSSECbis are sorted according to their 126 importance, starting with ones which could, if ignored, lead to 127 security problems and progressing down to clarifications that are 128 expected to have little operational impact. 130 1.2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119]. 137 2. Important Additions to DNSSSECbis 139 This section lists some documents that should be considered core 140 DNSSEC protocol documents in addition to those originally specified 141 in Section 10 of [RFC4033]. 143 2.1. NSEC3 Support 145 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM 146 records for hashed denial of existence. Validator implementations 147 are strongly encouraged to include support for NSEC3 because a number 148 of highly visible zones are expected to use it. Validators that do 149 not support validation of responses using NSEC3 will likely be 150 hampered in validating large portions of the DNS space. 152 [RFC5155] should be considered part of the DNS Security Document 153 Family as described by [RFC4033], Section 10. 155 Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- 156 SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) 157 signal that a zone MAY be using NSEC3, rather than NSEC. The zone 158 MAY indeed be using either and validators supporting these algorithms 159 MUST support both NSEC3 and NSEC responses. 161 2.2. SHA-2 Support 163 [RFC4509] describes the use of SHA-256 as a digest algorithm in 164 Delegation Signer (DS) RRs. [RFC5702] describes the use of the 165 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. 166 Validator implementations are strongly encouraged to include support 167 for these algorithms for DS, DNSKEY, and RRSIG records. 169 Both [RFC4509] and [RFC5702] should also be considered part of the 170 DNS Security Document Family as described by [RFC4033], Section 10. 172 3. Scaling Concerns 174 3.1. Implement a BAD cache 176 Section 4.7 of RFC4035 permits security-aware resolvers to implement 177 a BAD cache. Because of scaling concerns not discussed in this 178 document, that guidance has changed: security-aware resolvers SHOULD 179 implement a BAD cache, as described in RFC4035. 181 4. Security Concerns 183 This section provides clarifications that, if overlooked, could lead 184 to security issues. 186 4.1. Clarifications on Non-Existence Proofs 188 [RFC4035] Section 5.4 under-specifies the algorithm for checking non- 189 existence proofs. In particular, the algorithm as presented would 190 incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove 191 the non-existence of RRs in the child zone. 193 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: 195 o the NS bit set, 196 o the SOA bit clear, and 197 o a signer field that is shorter than the owner name of the NSEC RR, 198 or the original owner name for the NSEC3 RR. 200 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- 201 existence of any RRs below that zone cut, which include all RRs at 202 that (original) owner name other than DS RRs, and all RRs below that 203 owner name regardless of type. 205 Similarly, the algorithm would also allow an NSEC RR at the same 206 owner name as a DNAME RR, or an NSEC3 RR at the same original owner 207 name as a DNAME, to prove the non-existence of names beneath that 208 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used 209 to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's 210 (original) owner name. 212 4.2. Validating Responses to an ANY Query 214 [RFC4035] does not address how to validate responses when QTYPE=*. 215 As described in Section 6.2.2 of [RFC1034], a proper response to 216 QTYPE=* may include a subset of the RRsets at a given name. That is, 217 it is not necessary to include all RRsets at the QNAME in the 218 response. 220 When validating a response to QTYPE=*, all received RRsets that match 221 QNAME and QCLASS MUST be validated. If any of those RRsets fail 222 validation, the answer is considered Bogus. If there are no RRsets 223 matching QNAME and QCLASS, that fact MUST be validated according to 224 the rules in [RFC4035] Section 5.4 (as clarified in this document). 225 To be clear, a validator must not expect to receive all records at 226 the QNAME in response to QTYPE=*. 228 4.3. Check for CNAME 230 Section 5 of [RFC4035] says little about validating responses based 231 on (or that should be based on) CNAMEs. When validating a NOERROR/ 232 NODATA response, validators MUST check the CNAME bit in the matching 233 NSEC or NSEC3 RR's type bitmap in addition to the bit for the query 234 type. Without this check, an attacker could successfully transform a 235 positive CNAME response into a NOERROR/NODATA response. 237 4.4. Insecure Delegation Proofs 239 [RFC4035] Section 5.2 specifies that a validator, when proving a 240 delegation is not secure, needs to check for the absence of the DS 241 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also 242 needs to check for the presence of the NS bit in the matching NSEC 243 (or NSEC3) RR (proving that there is, indeed, a delegation), or 244 alternately make sure that the delegation is covered by an NSEC3 RR 245 with the Opt-Out flag set. If this is not checked, spoofed unsigned 246 delegations might be used to claim that an existing signed record is 247 not signed. 249 5. Interoperability Concerns 250 5.1. Errors in Canonical Form Type Code List 252 When canonicalizing DNS names (for both ordering and signing), DNS 253 names in the RDATA section of NSEC resource records are not 254 downcased. DNS names in the RDATA section of RRSIG resource records 255 are downcased. 257 The guidance in the above paragraph differs from what has been 258 published before but is consistent with current common practice. 259 [RFC4034] Section 6.2 item 3 says that names in both of these RR 260 types should be downcased. The earlier [RFC3755] says that they 261 should not. Current practice follows neither document fully. 263 Section 6.2 of RFC4034 also erroneously lists HINFO as a record that 264 needs downcasing, and twice at that. Since HINFO records contain no 265 domain names, they are not subject to downcasing. 267 5.2. Unknown DS Message Digest Algorithms 269 Section 5.2 of [RFC4035] includes rules for how to handle delegations 270 to zones that are signed with entirely unsupported public key 271 algorithms, as indicated by the key algorithms shown in those zone's 272 DS RRsets. It does not explicitly address how to handle DS records 273 that use unsupported message digest algorithms. In brief, DS records 274 using unknown or unsupported message digest algorithms MUST be 275 treated the same way as DS records referring to DNSKEY RRs of unknown 276 or unsupported public key algorithms. 278 The existing text says: 280 If the validator does not support any of the algorithms listed in 281 an authenticated DS RRset, then the resolver has no supported 282 authentication path leading from the parent to the child. The 283 resolver should treat this case as it would the case of an 284 authenticated NSEC RRset proving that no DS RRset exists, as 285 described above. 287 To paraphrase the above, when determining the security status of a 288 zone, a validator disregards any DS records listing unknown or 289 unsupported algorithms. If none are left, the zone is treated as if 290 it were unsigned. 292 Modified to consider DS message digest algorithms, a validator also 293 disregards any DS records using unknown or unsupported message digest 294 algorithms. 296 5.3. Private Algorithms 298 As discussed above, section 5.2 of [RFC4035] requires that validators 299 make decisions about the security status of zones based on the public 300 key algorithms shown in the DS records for those zones. In the case 301 of private algorithms, as described in [RFC4034] Appendix A.1.1, the 302 eight-bit algorithm field in the DS RR is not conclusive about what 303 algorithm(s) is actually in use. 305 If no private algorithms appear in the DS set or if any supported 306 algorithm appears in the DS set, no special processing will be 307 needed. In the remaining cases, the security status of the zone 308 depends on whether or not the resolver supports any of the private 309 algorithms in use (provided that these DS records use supported hash 310 functions, as discussed in Section 5.2). In these cases, the 311 resolver MUST retrieve the corresponding DNSKEY for each private 312 algorithm DS record and examine the public key field to determine the 313 algorithm in use. The security-aware resolver MUST ensure that the 314 hash of the DNSKEY RR's owner name and RDATA matches the digest in 315 the DS RR. If they do not match, and no other DS establishes that 316 the zone is secure, the referral should be considered Bogus data, as 317 discussed in [RFC4035]. 319 This clarification facilitates the broader use of private algorithms, 320 as suggested by [RFC4955]. 322 5.4. Caution About Local Policy and Multiple RRSIGs 324 When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 325 suggests that "the local resolver security policy determines whether 326 the resolver also has to test these RRSIG RRs and how to resolve 327 conflicts if these RRSIG RRs lead to differing results." In most 328 cases, a resolver would be well advised to accept any valid RRSIG as 329 sufficient. If the first RRSIG tested fails validation, a resolver 330 would be well advised to try others, giving a successful validation 331 result if any can be validated and giving a failure only if all 332 RRSIGs fail validation. 334 If a resolver adopts a more restrictive policy, there's a danger that 335 properly-signed data might unnecessarily fail validation, perhaps 336 because of cache timing issues. Furthermore, certain zone management 337 techniques, like the Double Signature Zone-signing Key Rollover 338 method described in section 4.2.1.2 of [RFC4641] might not work 339 reliably. 341 5.5. Key Tag Calculation 343 [RFC4034] Appendix B.1 incorrectly defines the Key Tag field 344 calculation for algorithm 1. It correctly says that the Key Tag is 345 the most significant 16 of the least significant 24 bits of the 346 public key modulus. However, [RFC4034] then goes on to incorrectly 347 say that this is 4th to last and 3rd to last octets of the public key 348 modulus. It is, in fact, the 3rd to last and 2nd to last octets. 350 5.6. Setting the DO Bit on Replies 352 As stated in [RFC3225], the DO bit of the query MUST be copied in the 353 response. At least one implementation has done something different, 354 so it may be wise for resolvers to be liberal in what they accept. 356 5.7. Setting the AD Bit on Queries 358 The use of the AD bit in the query was previously undefined. This 359 document defines it as a signal indicating that the requester 360 understands and is interested in the value of the AD bit in the 361 response. This allows a requestor to indicate that it understands 362 the AD bit without also requesting DNSSEC data via the DO bit. 364 5.8. Setting the AD Bit on Replies 366 Section 3.2.3 of [RFC4035] describes under which conditions a 367 validating resolver should set or clear the AD bit in a response. In 368 order to protect legacy stub resolvers and middleboxes, validating 369 resolvers SHOULD only set the AD bit when a response both meets the 370 conditions listed in RFC 4035, section 3.2.3, and the request 371 contained either a set DO bit or a set AD bit. 373 5.9. Always set the CD bit on Queries 375 When processing a request with the CD bit set, a resolver SHOULD 376 attempt to return all responsive data, even data that has failed 377 DNSSEC validation. RFC4035 section 3.2.2 requires a resolver 378 processing a request with the CD bit set to set the CD bit on its 379 upstream queries. 381 Prevailing wisdom suggests that a validating resolver SHOULD set the 382 CD bit on every upstream query regardless of whether the CD bit was 383 set on the incoming query or whether it has a trust anchor at or 384 above the QNAME. In other words, a validating resolver should 385 attempt to retrieve all possible data -- even that which it can not 386 validate itself -- on the grounds that a later query might come with 387 the CD bit set. 389 RFC4035 is ambiguous about what to do when a cached response was 390 obtained with the CD bit not set, a case that only arises when the 391 resolver chooses not to set the CD bit on all upstream queries, as 392 suggested above. In the typical case, no new query is required, nor 393 does the cache need to track the state of the CD bit used to make a 394 given query. The problem arises when the cached response is a server 395 failure (RCODE 2), which may indicate that the requested data failed 396 DNSSEC validation at an upstream validating resolver. (RFC2308 397 permits caching of server failures for up to five minutes.) In these 398 cases, a new query with the CD bit set is required. 400 Appendix B discusses more of the logic behind the recommendation 401 presented in this section. 403 5.10. Nested Trust Anchors 405 A DNSSEC validator may be configured such that, for a given response, 406 more than one trust anchor could be used to validate the chain of 407 trust to the response zone. For example, imagine a validator 408 configured with trust anchors for "example." and "zone.example." 409 When the validator is asked to validate a response to 410 "www.sub.zone.example.", either trust anchor could apply. 412 When presented with this situation, DNSSEC validators have a choice 413 of which trust anchor(s) to use. Which to use is a matter of 414 implementation choice. It is possible and perhaps advisable to 415 expose the choice of policy as a configuration option. The rest of 416 this section discusses some possible policies. As a default, we 417 suggest that validators implement the "Accept Any Success" policy 418 described below in Section 5.10.2 while exposing other policies as 419 configuration options. 421 5.10.1. Closest Encloser 423 One policy is to choose the trust anchor closest to the QNAME of the 424 response. In our example, that would be the "zone.example." trust 425 anchor. 427 This policy has the advantage of allowing the operator to trivially 428 override a parent zone's trust anchor with one that the operator can 429 validate in a stronger way, perhaps because the resolver operator is 430 affiliated with the zone in question. This policy also minimizes the 431 number of public key operations needed, which may be of benefit in 432 resource-constrained environments. 434 This policy has the disadvantage of possibly giving the user some 435 unexpected and unnecessary validation failures when sub-zone trust 436 anchors are neglected. As a concrete example, consider a validator 437 that configured a trust anchor for "zone.example." in 2009 and one 438 for "example." in 2011. In 2012, "zone.example." rolls its KSK and 439 updates its DS records, but the validator operator doesn't update its 440 trust anchor. With the "closest encloser" policy, the validator gets 441 validation failures. 443 5.10.2. Accept Any Success 445 Another policy is to try all applicable trust anchors until one gives 446 a validation result of Secure, in which case the final validation 447 result is Secure. If and only if all applicable trust anchors give a 448 result of Insecure, the final validation result is Insecure. If one 449 or more trust anchors lead to a Bogus result and there is no Secure 450 result, then the final validation result is Bogus. 452 This has the advantage of causing the fewer validation failures, 453 which may deliver a better user experience. If one trust anchor is 454 out of date (as in our above example), the user may still be able to 455 get a Secure validation result (and see DNS responses). 457 This policy has the disadvantage of making the validator subject to 458 compromise of the weakest of these trust anchors while making its 459 relatively painless to keep old trust anchors configured in 460 perpetuity. 462 5.10.3. Preference Based on Source 464 When the trust anchors have come from different sources (e.g. 465 automated updates ([RFC5011]), one or more DLV registries 466 ([RFC5074]), and manually configured), a validator may wish to choose 467 between them based on the perceived reliability of those sources. 468 The order of precedence might be exposed as a configuration option. 470 For example, a validator might choose to prefer trust anchors found 471 in a DLV registry over those manually configured on the theory that 472 the manually configured ones will not be as aggressively maintained. 474 Conversely, a validator might choose to prefer manually configured 475 trust anchors over those obtained from a DLV registry on the theory 476 that the manually configured ones have been more carefully 477 authenticated. 479 Or the validator might do something more complicated: prefer a sub- 480 set of manually configured trust anchors (based on a configuration 481 option), then trust anchors that have been updated using the RFC5011 482 mechanism, then trust anchors from one DLV registry, then trust 483 anchors from a different DLV registry, then the rest of the manually 484 configured trust anchors. 486 5.11. Mandatory Algorithm Rules 488 The last paragraph of RFC4035 Section 2.2 includes rules for which 489 algorithms must be used to sign a zone. Since these rules have been 490 confusing, we restate them in different language here: 492 The DS RRset and DNSKEY RRset are used to signal which algorithms 493 are used to sign a zone. The pressence of an algorithm in a 494 zone's DS or DNSKEY RRset set signals that that algorithm is used 495 to sign the entire zone. 497 A signed zone MUST include a DNSKEY for each algorithm present in 498 the zone's DS RRset and expected trust anchors for the zone. The 499 zone MUST also be signed with each algorithm (though not each key) 500 present in the DNSKEY RRset. It is possible to add algorithms at 501 the DNSKEY that aren't in the DS record, but not vice-versa. If 502 more than one key of the same algorithm is in the DNSKEY RRset, it 503 is sufficient to sign each RRset with any subset of these DNSKEYs. 504 It is acceptable to sign some RRsets with one subset of keys (or 505 key) and other RRsets with a different subset, so long as at least 506 one DNSKEY of each algorithm is used to sign each RRset. 507 Likewise, if there are DS records for multiple keys of the same 508 algorithm, any subset of those may appear in the DNSKEY RRset. 510 Lastly, note that this a requirement at the server side, not the 511 client side. Validators SHOULD accept any single valid path. They 512 SHOULD NOT insist that all algorithms signalled in the DS RRset work, 513 and they MUST NOT insist that all algorithms signalled in the DNSKEY 514 RRset work. A validator MAY have a configuration option to perform a 515 signature completeness test to support troubleshooting. 517 5.12. Expect Extra Signatures From Strange Keys 519 Validating resolvers should not be surprised to find RRSIGs in a zone 520 that do not (currently) have a corresponding DNSKEY in the zone. 521 Likewise, a validating resolver should not be surprised to find 522 RRSIGs with algorithm types that don't exist in the DNSKEY RRset or 523 DNSKEYs with algorithm types that don't appear in the zone's DS 524 RRset. 526 Good key rollover and algorithm rollover practices, as discussed in 527 RFC4641 and its successor documents and as suggested by the rules in 528 the previous section, may require that such RRSIGs be present in a 529 zone. 531 6. Minor Corrections and Clarifications 533 6.1. Finding Zone Cuts 535 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 536 for a parent zone. To do that, a resolver may first need to apply 537 special rules to discover what those servers are. 539 As explained in Section 3.1.4.1 of [RFC4035], security-aware name 540 servers need to apply special processing rules to handle the DS RR, 541 and in some situations the resolver may also need to apply special 542 rules to locate the name servers for the parent zone if the resolver 543 does not already have the parent's NS RRset. Section 4.2 of 544 [RFC4035] specifies a mechanism for doing that. 546 6.2. Clarifications on DNSKEY Usage 548 Questions of the form "can I use a different DNSKEY for signing this 549 RRset" have occasionally arisen. 551 The short answer is "yes, absolutely". You can even use a different 552 DNSKEY for each RRset in a zone, subject only to practical limits on 553 the size of the DNSKEY RRset. However, be aware that there is no way 554 to tell resolvers what a particularly DNSKEY is supposed to be used 555 for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to 556 authenticate any RRset in the zone. For example, if a weaker or less 557 trusted DNSKEY is being used to authenticate NSEC RRsets or all 558 dynamically updated records, that same DNSKEY can also be used to 559 sign any other RRsets from the zone. 561 Furthermore, note that the SEP bit setting has no effect on how a 562 DNSKEY may be used -- the validation process is specifically 563 prohibited from using that bit by [RFC4034] section 2.1.2. It is 564 possible to use a DNSKEY without the SEP bit set as the sole secure 565 entry point to the zone, yet use a DNSKEY with the SEP bit set to 566 sign all RRsets in the zone (other than the DNSKEY RRset). It is 567 also possible to use a single DNSKEY, with or without the SEP bit 568 set, to sign the entire zone, including the DNSKEY RRset itself. 570 6.3. Errors in Examples 572 The text in [RFC4035] Section C.1 refers to the examples in B.1 as 573 "x.w.example.com" while B.1 uses "x.w.example". This is painfully 574 obvious in the second paragraph where it states that the RRSIG labels 575 field value of 3 indicates that the answer was not the result of 576 wildcard expansion. This is true for "x.w.example" but not for 577 "x.w.example.com", which of course has a label count of 4 578 (antithetically, a label count of 3 would imply the answer was the 579 result of a wildcard expansion). 581 The first paragraph of [RFC4035] Section C.6 also has a minor error: 582 the reference to "a.z.w.w.example" should instead be "a.z.w.example", 583 as in the previous line. 585 6.4. Errors in RFC 5155 587 A NSEC3 record that matches an Empty Non-Terminal effectively has no 588 type associated with it. This NSEC3 record has an empty type bit 589 map. Section 3.2.1 of [RFC5155] contains the statement: 591 Blocks with no types present MUST NOT be included. 593 However, the same section contains a regular expression: 595 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 597 The plus sign in the regular expression indicates that there is one 598 or more of the preceding element. This means that there must be at 599 least one window block. If this window block has no types, it 600 contradicts with the first statement. Therefore, the correct text in 601 RFC 5155 3.2.1 should be: 603 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 605 7. IANA Considerations 607 This document specifies no IANA Actions. 609 8. Security Considerations 611 This document adds two cryptographic features to the core DNSSEC 612 protocol. Security considerations for those features are discussed 613 in the documents defining them. Additionally, this document 614 addresses some ambiguities and omissions in the core DNSSEC documents 615 that, if not recognized and addressed in implementations, could lead 616 to security failures. In particular, the validation algorithm 617 clarifications in Section 4 are critical for preserving the security 618 properties DNSSEC offers. Furthermore, failure to address some of 619 the interoperability concerns in Section 5 could limit the ability to 620 later change or expand DNSSEC, including adding new algorithms. 622 The recommendation in Section 5.9 to always set the CD bit has 623 security implications. By setting the CD bit, a resolver will not 624 benefit from more stringent validation rules or a more complete set 625 of trust anchors at an upstream validator. 627 9. References 629 9.1. Normative References 631 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 632 STD 13, RFC 1034, November 1987. 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, March 1997. 637 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 638 RFC 3225, December 2001. 640 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 641 Rose, "DNS Security Introduction and Requirements", 642 RFC 4033, March 2005. 644 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 645 Rose, "Resource Records for the DNS Security Extensions", 646 RFC 4034, March 2005. 648 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 649 Rose, "Protocol Modifications for the DNS Security 650 Extensions", RFC 4035, March 2005. 652 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 653 (DS) Resource Records (RRs)", RFC 4509, May 2006. 655 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 656 Security (DNSSEC) Hashed Authenticated Denial of 657 Existence", RFC 5155, March 2008. 659 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 660 and RRSIG Resource Records for DNSSEC", RFC 5702, 661 October 2009. 663 9.2. Informative References 665 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 666 Signer (DS)", RFC 3755, May 2004. 668 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 669 RFC 4641, September 2006. 671 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 672 July 2007. 674 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 675 Trust Anchors", RFC 5011, September 2007. 677 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 678 November 2007. 680 Appendix A. Acknowledgments 682 The editors would like the thank Rob Austein for his previous work as 683 an editor of this document. 685 The editors are extremely grateful to those who, in addition to 686 finding errors and omissions in the DNSSECbis document set, have 687 provided text suitable for inclusion in this document. 689 The lack of specificity about handling private algorithms, as 690 described in Section 5.3, and the lack of specificity in handling ANY 691 queries, as described in Section 4.2, were discovered by David 692 Blacka. 694 The error in algorithm 1 key tag calculation, as described in 695 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 696 contributed text for Section 5.5. 698 The bug relating to delegation NSEC RR's in Section 4.1 was found by 699 Roy Badami. Roy Arends found the related problem with DNAME. 701 The errors in the [RFC4035] examples were found by Roy Arends, who 702 also contributed text for Section 6.3 of this document. 704 Text on the mandatory algorithm rules was derived from suggestions by 705 Matthijs Mekking and Ed Lewis. 707 The CD bit logic was analyzed in depth by David Blacka, Olafur 708 Gudmundsson, Mike St. Johns, and Andrew Sullivan. 710 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 711 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 712 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, 713 and Scott Rose for their substantive comments on the text of this 714 document. 716 Appendix B. Discussion of Setting the CD Bit 718 RFC 4035 may be read as relying on the implicit assumption that there 719 is (at least usually) at most one validating system between the stub 720 resolver and the authoritative server for a given zone. It is 721 entirely possible, however, for more than one validator to stand 722 between a stub resolver and an authoritative server. If these 723 different validators have disjoint trust anchors configured, then it 724 will be possible that each would be able to validate some portion of 725 the DNS tree but neither will be able to validate all of it. 726 Accordingly, it might be argued that it is desirable not to set the 727 CD bit on upstream queries, because that will allow for maximal 728 validation. 730 In Section 5.9 of the present memo, it is recommended to set the CD 731 bit on an upstream query even when the incoming query arrives with 732 CD=0. This is for two reasons: it encourages a more predictable 733 validation experience (because it means that one validator is always 734 doing the validation), and it ensures that all DNSSEC data that 735 exists may be available from the local cache should a query with CD=1 736 arrive. 738 As a matter of policy, it is possible to set the CD bit differently 739 than suggested in Section 5.9. A different choice will, of course, 740 not always yield the benefits listed above. It is beyond the scope 741 of this memo to outline all of the considerations and counter 742 considerations for all possible policies. Nevertheless, it is 743 possible to describe three approaches and their underlying philosophy 744 of operation. These are laid out in the tables below. 746 The table that describes each model has five columns. The first 747 column indicates the value of the CD bit that the resolver receives 748 (for instance, on the name server side in an iterative resolver, or 749 as local policy or from the API in the case of a stub). The next 750 column indicates whether the query needs to be forwarded for 751 resolution (F) or can be satisfied from a local cache (C). The next 752 column is a line number, so that it can be referred to later in the 753 table. The next column indicates any relevant conditions at the 754 resolver: whether the resolver has a covering trust anchor and so on 755 (if there are no parameters here, the column is empty). The final 756 column indicates what the resolver does. 758 The tables differentiate between "cached data" and "cached RCODE=2". 759 This is a shorthand; the point is that one has to treat RCODE=2 as 760 special, because it might indicate a validation failure somewhere 761 upstream. The distinction is really between "cached RCODE=2" and 762 "cached everything else". 764 The tables are probably easiest to think of in terms of describing 765 what happens when a stub resolver sends a query to an intermediate 766 resolver, but they are perfectly general and can be applied to any 767 validating resolver. 769 Model 1: "always set" 771 This model is so named because the validating resolver sets the CD 772 bit on queries it makes reegardless of whether it has a covering 773 trust anchor for the query. It is the model recommended in 774 Section 5.9 of this memo. The general philosophy represented by this 775 table is that only one resolver should be responsible for validation 776 irrespective of the possibility that an upstream resolver may be 777 present and with TAs that cover different or additional QNAMEs. 779 CD F/C line conditions action 780 ==================================================================== 781 1 F A1 Set CD=1 on upstream query 782 0 F A2 Set CD=1 on upstream query 783 1 C A3 Return the cache contents 784 (data or RCODE=2) 785 0 C A4 no covering TA Return cache contents 786 (data or RCODE=2) 787 0 C A5 covering TA Validate cached result and 788 return it. 790 Model 2: "never set when receiving CD=0" 792 This model is so named because it sets CD=0 on upstream queries for 793 all received CD=0 queries even if it has a covering trust anchor. 794 The general philosophy represented by this table is that more than 795 one resolver may take responsibility for validating a QNAME and that 796 a validation failure for a QNAME by any resolver in the chain is a 797 validation failure for the query. Using this model instead of model 798 1 is NOT RECOMMENDED. 800 CD F/C line conditions action 801 ==================================================================== 802 1 F N1 Set CD=1 on upstream query 803 0 F N2 Set CD=0 on upstream query 804 1 C N3 cached data Return cached data 805 1 C N4 cached RCODE=2 Treat as line N1 806 0 C N5 no covering TA Return cache contents 807 (data or RCODE=2) 808 0 C N6 covering TA & Treat as line N2 809 cached data was 810 generated with CD=1 811 0 C N7 covering TA & Validate and return 812 cached data was 813 generated with CD=0 815 Model 3: "sometimes set" 817 This model is so named because it sets the CD bit on upstream queries 818 triggered by received CD=0 queries based on whether the validator has 819 a TA configured that covers the query. If there is no covering TA, 820 the resolver clears the CD bit in the upstream query. If there is a 821 covering TA, it sets CD=1 and performs validation itself. The 822 general philosophy represented by this table is that a resolver 823 should try and validate QNAMEs for which is has trust anchors and 824 should not preclude validation by other resolvers for QNAMEs for 825 which it does not have covering trust anchors. Using this model 826 instead of model 1 is NOT RECOMMENDED. 828 CD F/C line conditions action 829 ==================================================================== 830 1 F S1 Set CD=1 on upstream query 831 0 F S2 covering TA Set CD=1 on upstream query 832 0 F S3 no covering TA Set CD=0 on upstream query 833 1 C S4 cached data Return cached data 834 1 C S5 cached RCODE=2 Treat as line S1 835 0 C S6 cached data was Return cache contents 836 generated with 837 CD=0 838 0 C S7 cached data was Validate & return cache 839 generated with contents 840 CD=1 & 841 covering TA 842 0 C S8 cached RCODE=2 Return cache contents 843 0 C S9 cached data Treat as line S3 844 was generated 845 with CD=1 & 846 no covering 847 TA 849 Authors' Addresses 851 Samuel Weiler 852 SPARTA, Inc. 853 7110 Samuel Morse Drive 854 Columbia, Maryland 21046 855 US 857 Email: weiler@tislabs.com 859 David Blacka 860 VeriSign, Inc. 861 21345 Ridgetop Circle 862 Dulles, VA 20166 863 US 865 Email: davidb@verisign.com