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 4.2.1.2 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 adds an additional reference for CD bit in the DNS Parameters - DNS Header Flags registry.
(This document specifies no IANA Actions.)
(Add following text:) This document adds an additional reference for DO bit in the DNS Parameters - DNS Header Flags registry.
This document specifies no IANA Actions.
Add this document as an additional reference for AD in the DNS Parameters - DNS Header Flags registry.
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: weiler@tislabs.com
1122
1123
1124 David Blacka (editor)
1125 Verisign, Inc.
1126 12061 Bluemont Way
1127 Reston, VA 20190
1128 US
1129
1130 EMail: davidb@verisign.com
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 4.1.2.2 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.