7Internet Engineering Task Force (IETF) S. Weiler, Ed.
8Request for Comments: 6840 SPARTA, Inc.
9Updates: 4033, 4034, 4035, 5155 D. Blacka, Ed.
10Category: Standards Track Verisign, Inc.
11ISSN: 2070-1721 February 2013
14 Clarifications and Implementation Notes for DNS Security (DNSSEC)
18 This document is a collection of technical clarifications to the DNS
19 Security (DNSSEC) document set. It is meant to serve as a resource
20 to implementors as well as a collection of DNSSEC errata that existed
21 at the time of writing.
23 This document updates the core DNSSEC documents (RFC 4033, RFC 4034,
24 and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also
25 defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the
30 This is an Internet Standards Track document.
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Further information on
36 Internet Standards is available in Section 2 of RFC 5741.
38 Information about the current status of this document, any errata,
39 and how to provide feedback on it may be obtained at
40 http://www.rfc-editor.org/info/rfc6840.
58Weiler & Blacka Standards Track [Page 1]
60RFC 6840 DNSSEC Implementation Notes February 2013
65 Copyright (c) 2013 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
114Weiler & Blacka Standards Track [Page 2]
116RFC 6840 DNSSEC Implementation Notes February 2013
121 1. Introduction and Terminology ....................................4
122 1.1. Structure of This Document .................................4
123 1.2. Terminology ................................................4
124 2. Important Additions to DNSSEC ...................................4
125 2.1. NSEC3 Support ..............................................4
126 2.2. SHA-2 Support ..............................................5
127 3. Scaling Concerns ................................................5
128 3.1. Implement a BAD Cache ......................................5
129 4. Security Concerns ...............................................5
130 4.1. Clarifications on Nonexistence Proofs ......................5
131 4.2. Validating Responses to an ANY Query .......................6
132 4.3. Check for CNAME ............................................6
133 4.4. Insecure Delegation Proofs .................................7
134 5. Interoperability Concerns .......................................7
135 5.1. Errors in Canonical Form Type Code List ....................7
136 5.2. Unknown DS Message Digest Algorithms .......................7
137 5.3. Private Algorithms .........................................8
138 5.4. Caution about Local Policy and Multiple RRSIGs .............9
139 5.5. Key Tag Calculation ........................................9
140 5.6. Setting the DO Bit on Replies ..............................9
141 5.7. Setting the AD Bit on Queries .............................10
142 5.8. Setting the AD Bit on Replies .............................10
143 5.9. Always Set the CD Bit on Queries ..........................10
144 5.10. Nested Trust Anchors .....................................11
145 5.11. Mandatory Algorithm Rules ................................11
146 5.12. Ignore Extra Signatures from Unknown Keys ................12
147 6. Minor Corrections and Clarifications ...........................12
148 6.1. Finding Zone Cuts .........................................12
149 6.2. Clarifications on DNSKEY Usage ............................12
150 6.3. Errors in Examples ........................................13
151 6.4. Errors in RFC 5155 ........................................13
152 7. Security Considerations ........................................13
153 8. References .....................................................14
154 8.1. Normative References ......................................14
155 8.2. Informative References ....................................15
156 Appendix A. Acknowledgments .......................................16
157 Appendix B. Discussion of Setting the CD Bit ......................16
158 Appendix C. Discussion of Trust Anchor Preference Options .........19
159 C.1. Closest Encloser ..........................................19
160 C.2. Accept Any Success ........................................20
161 C.3. Preference Based on Source ................................20
170Weiler & Blacka Standards Track [Page 3]
172RFC 6840 DNSSEC Implementation Notes February 2013
1751. Introduction and Terminology
177 This document lists some additions, clarifications, and corrections
178 to the core DNSSEC specification, as originally described in
179 [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
180 (See Section 2 for more recent additions to that core document set.)
182 It is intended to serve as a resource for implementors and as a
183 repository of items existing at the time of writing that need to be
184 addressed when advancing the DNSSEC documents along the Standards
1871.1. Structure of This Document
189 The clarifications and changes to DNSSEC are sorted according to
190 their importance, starting with ones which could, if ignored, lead to
191 security problems and progressing down to clarifications that are
192 expected to have little operational impact.
196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
198 "OPTIONAL" in this document are to be interpreted as described in
2012. Important Additions to DNSSEC
203 This section lists some documents that are now considered core DNSSEC
204 protocol documents in addition to those originally specified in
205 Section 10 of [RFC4033].
209 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
210 records for hashed denial of existence. Validator implementations
211 are strongly encouraged to include support for NSEC3 because a number
212 of highly visible zones use it. Validators that do not support
213 validation of responses using NSEC3 will be hampered in validating
214 large portions of the DNS space.
216 [RFC5155] is now considered part of the DNS Security Document Family
217 as described by Section 10 of [RFC4033].
226Weiler & Blacka Standards Track [Page 4]
228RFC 6840 DNSSEC Implementation Notes February 2013
231 Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3-
232 SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512)
233 signal that a zone might be using NSEC3, rather than NSEC. The zone
234 may be using either, and validators supporting these algorithms MUST
235 support both NSEC3 and NSEC responses.
239 [RFC4509] describes the use of SHA-256 as a digest algorithm in
240 Delegation Signer (DS) RRs. [RFC5702] describes the use of the
241 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
242 Validator implementations are strongly encouraged to include support
243 for these algorithms for DS, DNSKEY, and RRSIG records.
245 Both [RFC4509] and [RFC5702] are now considered part of the DNS
246 Security Document Family as described by Section 10 of [RFC4033].
2503.1. Implement a BAD Cache
252 Section 4.7 of [RFC4035] permits security-aware resolvers to
253 implement a BAD cache. That guidance has changed: security-aware
254 resolvers SHOULD implement a BAD cache as described in [RFC4035].
256 This change in guidance is based on operational experience with
257 DNSSEC administrative errors leading to significant increases in DNS
258 traffic, with an accompanying realization that such events are more
259 likely and more damaging than originally supposed. An example of one
260 such event is documented in "Rolling Over DNSSEC Keys" [Huston].
264 This section provides clarifications that, if overlooked, could lead
2674.1. Clarifications on Nonexistence Proofs
269 Section 5.4 of [RFC4035] under-specifies the algorithm for checking
270 nonexistence proofs. In particular, the algorithm as presented would
271 allow a validator to interpret an NSEC or NSEC3 RR from an ancestor
272 zone as proving the nonexistence of an RR in a child zone.
274 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
278 o the Start of Authority (SOA) bit clear, and
282Weiler & Blacka Standards Track [Page 5]
284RFC 6840 DNSSEC Implementation Notes February 2013
287 o a signer field that is shorter than the owner name of the NSEC RR,
288 or the original owner name for the NSEC3 RR.
290 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume
291 nonexistence of any RRs below that zone cut, which include all RRs at
292 that (original) owner name other than DS RRs, and all RRs below that
293 owner name regardless of type.
295 Similarly, the algorithm would also allow an NSEC RR at the same
296 owner name as a DNAME RR, or an NSEC3 RR at the same original owner
297 name as a DNAME, to prove the nonexistence of names beneath that
298 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
299 to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's
300 (original) owner name.
3024.2. Validating Responses to an ANY Query
304 [RFC4035] does not address how to validate responses when QTYPE=*.
305 As described in Section 6.2.2 of [RFC1034], a proper response to
306 QTYPE=* may include a subset of the RRsets at a given name. That is,
307 it is not necessary to include all RRsets at the QNAME in the
310 When validating a response to QTYPE=*, all received RRsets that match
311 QNAME and QCLASS MUST be validated. If any of those RRsets fail
312 validation, the answer is considered Bogus. If there are no RRsets
313 matching QNAME and QCLASS, that fact MUST be validated according to
314 the rules in Section 5.4 of [RFC4035] (as clarified in this
315 document). To be clear, a validator must not expect to receive all
316 records at the QNAME in response to QTYPE=*.
320 Section 5 of [RFC4035] says nothing explicit about validating
321 responses based on (or that should be based on) CNAMEs. When
322 validating a NOERROR/NODATA response, validators MUST check the CNAME
323 bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
324 bit for the query type.
326 Without this check, an attacker could successfully transform a
327 positive CNAME response into a NOERROR/NODATA response by (for
328 example) simply stripping the CNAME RRset from the response. A naive
329 validator would then note that the QTYPE was not present in the
330 matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
331 set; thus, the response should have been a positive CNAME response.
338Weiler & Blacka Standards Track [Page 6]
340RFC 6840 DNSSEC Implementation Notes February 2013
3434.4. Insecure Delegation Proofs
345 Section 5.2 of [RFC4035] specifies that a validator, when proving a
346 delegation is not secure, needs to check for the absence of the DS
347 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also
348 MUST check for the presence of the NS bit in the matching NSEC (or
349 NSEC3) RR (proving that there is, indeed, a delegation), or
350 alternately make sure that the delegation is covered by an NSEC3 RR
351 with the Opt-Out flag set.
353 Without this check, an attacker could reuse an NSEC or NSEC3 RR
354 matching a non-delegation name to spoof an unsigned delegation at
355 that name. This would claim that an existing signed RRset (or set of
356 signed RRsets) is below an unsigned delegation, thus not signed and
357 vulnerable to further attack.
3595. Interoperability Concerns
3615.1. Errors in Canonical Form Type Code List
363 When canonicalizing DNS names (for both ordering and signing), DNS
364 names in the RDATA section of NSEC resource records are not converted
365 to lowercase. DNS names in the RDATA section of RRSIG resource
366 records are converted to lowercase.
368 The guidance in the above paragraph differs from what has been
369 published before but is consistent with current common practice.
370 Item 3 of Section 6.2 of [RFC4034] says that names in both of these
371 RR types should be converted to lowercase. The earlier [RFC3755]
372 says that they should not. Current practice follows neither document
375 Section 6.2 of [RFC4034] also erroneously lists HINFO as a record
376 that needs conversion to lowercase, and twice at that. Since HINFO
377 records contain no domain names, they are not subject to case
3805.2. Unknown DS Message Digest Algorithms
382 Section 5.2 of [RFC4035] includes rules for how to handle delegations
383 to zones that are signed with entirely unsupported public key
384 algorithms, as indicated by the key algorithms shown in those zones'
385 DS RRsets. It does not explicitly address how to handle DS records
386 that use unsupported message digest algorithms. In brief, DS records
387 using unknown or unsupported message digest algorithms MUST be
388 treated the same way as DS records referring to DNSKEY RRs of unknown
389 or unsupported public key algorithms.
394Weiler & Blacka Standards Track [Page 7]
396RFC 6840 DNSSEC Implementation Notes February 2013
399 The existing text says:
401 If the validator does not support any of the algorithms listed in
402 an authenticated DS RRset, then the resolver has no supported
403 authentication path leading from the parent to the child. The
404 resolver should treat this case as it would the case of an
405 authenticated NSEC RRset proving that no DS RRset exists, as
408 In other words, when determining the security status of a zone, a
409 validator disregards any authenticated DS records that specify
410 unknown or unsupported DNSKEY algorithms. If none are left, the zone
411 is treated as if it were unsigned.
413 This document modifies the above text to additionally disregard
414 authenticated DS records using unknown or unsupported message digest
4175.3. Private Algorithms
419 As discussed above, Section 5.2 of [RFC4035] requires that validators
420 make decisions about the security status of zones based on the public
421 key algorithms shown in the DS records for those zones. In the case
422 of private algorithms, as described in Appendix A.1.1 of [RFC4034],
423 the eight-bit algorithm field in the DS RR is not conclusive about
424 what algorithm(s) is actually in use.
426 If no private algorithms appear in the DS RRset, or if any supported
427 algorithm appears in the DS RRset, no special processing is needed.
428 Furthermore, if the validator implementation does not support any
429 private algorithms, or only supports private algorithms using an
430 algorithm number not present in the DS RRset, no special processing
433 In the remaining cases, the security status of the zone depends on
434 whether or not the resolver supports any of the private algorithms in
435 use (provided that these DS records use supported message digest
436 algorithms, as discussed in Section 5.2 of this document). In these
437 cases, the resolver MUST retrieve the corresponding DNSKEY for each
438 private algorithm DS record and examine the public key field to
439 determine the algorithm in use. The security-aware resolver MUST
440 ensure that the hash of the DNSKEY RR's owner name and RDATA matches
441 the digest in the DS RR as described in Section 5.2 of [RFC4035],
442 authenticating the DNSKEY. If all of the retrieved and authenticated
443 DNSKEY RRs use unknown or unsupported private algorithms, then the
444 zone is treated as if it were unsigned.
450Weiler & Blacka Standards Track [Page 8]
452RFC 6840 DNSSEC Implementation Notes February 2013
455 Note that if none of the private algorithm DS RRs can be securely
456 matched to DNSKEY RRs and no other DS establishes that the zone is
457 secure, the referral should be considered Bogus data as discussed in
460 This clarification facilitates the broader use of private algorithms,
461 as suggested by [RFC4955].
4635.4. Caution about Local Policy and Multiple RRSIGs
465 When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035]
466 suggests that "the local resolver security policy determines whether
467 the resolver also has to test these RRSIG RRs and how to resolve
468 conflicts if these RRSIG RRs lead to differing results".
470 This document specifies that a resolver SHOULD accept any valid RRSIG
471 as sufficient, and only determine that an RRset is Bogus if all
472 RRSIGs fail validation.
474 If a resolver adopts a more restrictive policy, there's a danger that
475 properly signed data might unnecessarily fail validation due to cache
476 timing issues. Furthermore, certain zone management techniques, like
477 the Double Signature Zone Signing Key Rollover method described in
478 Section 4.2.1.2 of [RFC6781], will not work reliably. Such a
479 resolver is also vulnerable to malicious insertion of gibberish
4825.5. Key Tag Calculation
484 Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field
485 calculation for algorithm 1. It correctly says that the Key Tag is
486 the most significant 16 of the least significant 24 bits of the
487 public key modulus. However, [RFC4034] then goes on to incorrectly
488 say that this is fourth-to-last and third-to-last octets of the
489 public key modulus. It is, in fact, the third-to-last and second-to-
4925.6. Setting the DO Bit on Replies
494 As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the
495 query MUST be copied in the response. However, in order to
496 interoperate with implementations that ignore this rule on sending,
497 resolvers MUST ignore the DO bit in responses.
506Weiler & Blacka Standards Track [Page 9]
508RFC 6840 DNSSEC Implementation Notes February 2013
5115.7. Setting the AD Bit on Queries
513 The semantics of the Authentic Data (AD) bit in the query were
514 previously undefined. Section 4.6 of [RFC4035] instructed resolvers
515 to always clear the AD bit when composing queries.
517 This document defines setting the AD bit in a query as a signal
518 indicating that the requester understands and is interested in the
519 value of the AD bit in the response. This allows a requester to
520 indicate that it understands the AD bit without also requesting
521 DNSSEC data via the DO bit.
5235.8. Setting the AD Bit on Replies
525 Section 3.2.3 of [RFC4035] describes under which conditions a
526 validating resolver should set or clear the AD bit in a response. In
527 order to interoperate with legacy stub resolvers and middleboxes that
528 neither understand nor ignore the AD bit, validating resolvers SHOULD
529 only set the AD bit when a response both meets the conditions listed
530 in Section 3.2.3 of [RFC4035], and the request contained either a set
531 DO bit or a set AD bit.
5335.9. Always Set the CD Bit on Queries
535 When processing a request with the Checking Disabled (CD) bit set, a
536 resolver SHOULD attempt to return all response data, even data that
537 has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a
538 resolver processing a request with the CD bit set to set the CD bit
539 on its upstream queries.
541 This document further specifies that validating resolvers SHOULD set
542 the CD bit on every upstream query. This is regardless of whether
543 the CD bit was set on the incoming query or whether it has a trust
544 anchor at or above the QNAME.
546 [RFC4035] is ambiguous about what to do when a cached response was
547 obtained with the CD bit unset, a case that only arises when the
548 resolver chooses not to set the CD bit on all upstream queries, as
549 specified above. In the typical case, no new query is required, nor
550 does the cache need to track the state of the CD bit used to make a
551 given query. The problem arises when the cached response is a server
552 failure (RCODE 2), which may indicate that the requested data failed
553 DNSSEC validation at an upstream validating resolver. ([RFC2308]
554 permits caching of server failures for up to five minutes.) In these
555 cases, a new query with the CD bit set is required.
557 Appendix B discusses more of the logic behind the recommendation
558 presented in this section.
562Weiler & Blacka Standards Track [Page 10]
564RFC 6840 DNSSEC Implementation Notes February 2013
5675.10. Nested Trust Anchors
569 A DNSSEC validator may be configured such that, for a given response,
570 more than one trust anchor could be used to validate the chain of
571 trust to the response zone. For example, imagine a validator
572 configured with trust anchors for "example." and "zone.example."
573 When the validator is asked to validate a response to
574 "www.sub.zone.example.", either trust anchor could apply.
576 When presented with this situation, DNSSEC validators have a choice
577 of which trust anchor(s) to use. Which to use is a matter of
578 implementation choice. Appendix C discusses several possible
581 It is possible and advisable to expose the choice of policy as a
582 configuration option. As a default, it is suggested that validators
583 implement the "Accept Any Success" policy described in Appendix C.2
584 while exposing other policies as configuration options.
586 The "Accept Any Success" policy is to try all applicable trust
587 anchors until one gives a validation result of Secure, in which case
588 the final validation result is Secure. If and only if all applicable
589 trust anchors give a result of Insecure, the final validation result
590 is Insecure. If one or more trust anchors lead to a Bogus result and
591 there is no Secure result, then the final validation result is Bogus.
5935.11. Mandatory Algorithm Rules
595 The last paragraph of Section 2.2 of [RFC4035] includes rules
596 describing which algorithms must be used to sign a zone. Since these
597 rules have been confusing, they are restated using different language
600 The DS RRset and DNSKEY RRset are used to signal which algorithms
601 are used to sign a zone. The presence of an algorithm in either a
602 zone's DS or DNSKEY RRset signals that that algorithm is used to
603 sign the entire zone.
605 A signed zone MUST include a DNSKEY for each algorithm present in
606 the zone's DS RRset and expected trust anchors for the zone. The
607 zone MUST also be signed with each algorithm (though not each key)
608 present in the DNSKEY RRset. It is possible to add algorithms at
609 the DNSKEY that aren't in the DS record, but not vice versa. If
610 more than one key of the same algorithm is in the DNSKEY RRset, it
611 is sufficient to sign each RRset with any subset of these DNSKEYs.
612 It is acceptable to sign some RRsets with one subset of keys (or
613 key) and other RRsets with a different subset, so long as at least
618Weiler & Blacka Standards Track [Page 11]
620RFC 6840 DNSSEC Implementation Notes February 2013
623 one DNSKEY of each algorithm is used to sign each RRset.
624 Likewise, if there are DS records for multiple keys of the same
625 algorithm, any subset of those may appear in the DNSKEY RRset.
627 This requirement applies to servers, not validators. Validators
628 SHOULD accept any single valid path. They SHOULD NOT insist that all
629 algorithms signaled in the DS RRset work, and they MUST NOT insist
630 that all algorithms signaled in the DNSKEY RRset work. A validator
631 MAY have a configuration option to perform a signature completeness
632 test to support troubleshooting.
6345.12. Ignore Extra Signatures from Unknown Keys
636 Validating resolvers MUST disregard RRSIGs in a zone that do not
637 (currently) have a corresponding DNSKEY in the zone. Similarly, a
638 validating resolver MUST disregard RRSIGs with algorithm types that
639 don't exist in the DNSKEY RRset.
641 Good key rollover and algorithm rollover practices, as discussed in
642 RFC 6781 and its successor documents and as suggested by the rules in
643 the previous section, may require that such RRSIGs be present in a
6466. Minor Corrections and Clarifications
6486.1. Finding Zone Cuts
650 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
651 for a parent zone but does not state how to find those servers.
652 Specific instructions can be found in Section 4.2 of [RFC4035].
6546.2. Clarifications on DNSKEY Usage
656 It is possible to use different DNSKEYs to sign different subsets of
657 a zone, constrained only by the rules in Section 5.11. It is even
658 possible to use a different DNSKEY for each RRset in a zone, subject
659 only to practical limits on the size of the DNSKEY RRset and the
660 above rules. However, be aware that there is no way to tell
661 resolvers what a particular DNSKEY is supposed to be used for -- any
662 DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
663 any RRset in the zone. For example, if a weaker or less trusted
664 DNSKEY is being used to authenticate NSEC RRsets or all dynamically
665 updated records, that same DNSKEY can also be used to sign any other
666 RRsets from the zone.
668 Furthermore, note that the SEP bit setting has no effect on how a
669 DNSKEY may be used -- the validation process is specifically
670 prohibited from using that bit by Section 2.1.2 of [RFC4034]. It is
674Weiler & Blacka Standards Track [Page 12]
676RFC 6840 DNSSEC Implementation Notes February 2013
679 possible to use a DNSKEY without the SEP bit set as the sole secure
680 entry point to the zone, yet use a DNSKEY with the SEP bit set to
681 sign all RRsets in the zone (other than the DNSKEY RRset). It is
682 also possible to use a single DNSKEY, with or without the SEP bit
683 set, to sign the entire zone, including the DNSKEY RRset itself.
6856.3. Errors in Examples
687 The text in Appendix C.1 of [RFC4035] refers to the examples in
688 Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example". This
689 is painfully obvious in the second paragraph where it states that the
690 RRSIG labels field value of 3 indicates that the answer was not the
691 result of wildcard expansion. This is true for "x.w.example" but not
692 for "x.w.example.com", which of course has a label count of 4
693 (antithetically, a label count of 3 would imply the answer was the
694 result of a wildcard expansion).
696 The first paragraph of Appendix C.6 of [RFC4035] also has a minor
697 error: the reference to "a.z.w.w.example" should instead be
698 "a.z.w.example", as in the previous line.
7006.4. Errors in RFC 5155
702 An NSEC3 record that matches an Empty Non-Terminal effectively has no
703 type associated with it. This NSEC3 record has an empty type bit
704 map. Section 3.2.1 of [RFC5155] contains the statement:
706 Blocks with no types present MUST NOT be included.
708 However, the same section contains a regular expression:
710 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
712 The plus sign in the regular expression indicates that there is one
713 or more of the preceding element. This means that there must be at
714 least one window block. If this window block has no types, it
715 contradicts with the first statement. Therefore, the correct text in
716 Section 3.2.1 of [RFC5155] should be:
718 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
7207. Security Considerations
722 This document adds SHA-2 and NSEC3 support to the core DNSSEC
723 protocol. Security considerations for those features are discussed
724 in the documents defining them. Additionally, this document
725 addresses some ambiguities and omissions in the core DNSSEC documents
726 that, if not recognized and addressed in implementations, could lead
730Weiler & Blacka Standards Track [Page 13]
732RFC 6840 DNSSEC Implementation Notes February 2013
735 to security failures. In particular, the validation algorithm
736 clarifications in Section 4 are critical for preserving the security
737 properties DNSSEC offers. Furthermore, failure to address some of
738 the interoperability concerns in Section 5 could limit the ability to
739 later change or expand DNSSEC, including adding new algorithms.
741 The recommendation in Section 5.9 to always set the CD bit has
742 security implications. By setting the CD bit, a resolver will not
743 benefit from more stringent validation rules or a more complete set
744 of trust anchors at an upstream validator.
7488.1. Normative References
750 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
751 STD 13, RFC 1034, November 1987.
753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
754 Requirement Levels", BCP 14, RFC 2119, March 1997.
756 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
757 RFC 3225, December 2001.
759 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
760 Rose, "DNS Security Introduction and Requirements",
761 RFC 4033, March 2005.
763 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
764 Rose, "Resource Records for the DNS Security Extensions",
765 RFC 4034, March 2005.
767 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
768 Rose, "Protocol Modifications for the DNS Security
769 Extensions", RFC 4035, March 2005.
771 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
772 (DS) Resource Records (RRs)", RFC 4509, May 2006.
774 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
775 Security (DNSSEC) Hashed Authenticated Denial of
776 Existence", RFC 5155, March 2008.
778 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
779 and RRSIG Resource Records for DNSSEC", RFC 5702,
786Weiler & Blacka Standards Track [Page 14]
788RFC 6840 DNSSEC Implementation Notes February 2013
7918.2. Informative References
793 [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
794 "Rolling Over DNSSEC Keys", Internet Protocol
795 Journal, Vol. 13, No.1, pp. 2-16, March 2010.
797 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
798 NCACHE)", RFC 2308, March 1998.
800 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
801 Signer (DS)", RFC 3755, May 2004.
803 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
806 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
807 Trust Anchors", STD 74, RFC 5011, September 2007.
809 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
812 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
813 Operational Practices, Version 2", RFC 6781,
842Weiler & Blacka Standards Track [Page 15]
844RFC 6840 DNSSEC Implementation Notes February 2013
847Appendix A. Acknowledgments
849 The editors would like the thank Rob Austein for his previous work as
850 an editor of this document.
852 The editors are extremely grateful to those who, in addition to
853 finding errors and omissions in the DNSSEC document set, have
854 provided text suitable for inclusion in this document.
856 The lack of specificity about handling private algorithms, as
857 described in Section 5.3, and the lack of specificity in handling ANY
858 queries, as described in Section 4.2, were discovered by David
861 The error in algorithm 1 key tag calculation, as described in
862 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
863 contributed text for Section 5.5.
865 The bug relating to delegation NSEC RR's in Section 4.1 was found by
866 Roy Badami. Roy Arends found the related problem with DNAME.
868 The errors in the [RFC4035] examples were found by Roy Arends, who
869 also contributed text for Section 6.3 of this document.
871 Text on the mandatory algorithm rules was derived from suggestions by
872 Matthijs Mekking and Ed Lewis.
874 The CD bit logic was analyzed in depth by David Blacka, Olafur
875 Gudmundsson, Mike St. Johns, and Andrew Sullivan.
877 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
878 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
879 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
880 Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
881 Warren Kumari and Scott Rose for their contributions to this
884Appendix B. Discussion of Setting the CD Bit
886 [RFC4035] may be read as relying on the implicit assumption that
887 there is at most one validating system between the stub resolver and
888 the authoritative server for a given zone. It is entirely possible,
889 however, for more than one validator to exist between a stub resolver
890 and an authoritative server. If these different validators have
891 disjoint trust anchors configured, then it is possible that each
892 would be able to validate some portion of the DNS tree, but neither
898Weiler & Blacka Standards Track [Page 16]
900RFC 6840 DNSSEC Implementation Notes February 2013
903 is able to validate all of it. Accordingly, it might be argued that
904 it is desirable not to set the CD bit on upstream queries, because
905 that allows for maximal validation.
907 In Section 5.9 of this document, it is recommended to set the CD bit
908 on an upstream query even when the incoming query arrives with CD=0.
909 This is for two reasons: it encourages a more predictable validation
910 experience as only one validator is always doing the validation, and
911 it ensures that all DNSSEC data that exists may be available from the
912 local cache should a query with CD=1 arrive.
914 As a matter of policy, it is possible to set the CD bit differently
915 than suggested in Section 5.9. A different choice will, of course,
916 not always yield the benefits listed above. It is beyond the scope
917 of this document to outline all of the considerations and counter
918 considerations for all possible policies. Nevertheless, it is
919 possible to describe three approaches and their underlying philosophy
920 of operation. These are laid out in the tables below.
922 The table that describes each model has five columns. The first
923 column indicates the value of the CD bit that the resolver receives
924 (for instance, on the name server side in an iterative resolver, or
925 as local policy or from the API in the case of a stub). The second
926 column indicates whether the query needs to be forwarded for
927 resolution (F) or can be satisfied from a local cache (C). The third
928 column is a line number, so that it can be referred to later in the
929 table. The fourth column indicates any relevant conditions at the
930 resolver, for example, whether the resolver has a covering trust
931 anchor, and so on. If there are no parameters here, the column is
932 empty. The fifth and final column indicates what action the resolver
935 The tables differentiate between "cached data" and "cached RCODE=2".
936 This is a shorthand; the point is that one has to treat RCODE=2
937 (server failure) as special, because it might indicate a validation
938 failure somewhere upstream. The distinction is really between
939 "cached RCODE=2" and "cached everything else".
941 The tables are probably easiest to think of in terms of describing
942 what happens when a stub resolver sends a query to an intermediate
943 resolver, but they are perfectly general and can be applied to any
946 Model 1: "always set"
948 This model is so named because the validating resolver sets the CD
949 bit on queries it makes regardless of whether it has a covering trust
950 anchor for the query. The general philosophy represented by this
954Weiler & Blacka Standards Track [Page 17]
956RFC 6840 DNSSEC Implementation Notes February 2013
959 table is that only one resolver should be responsible for validation
960 irrespective of the possibility that an upstream resolver may be
961 present with trust anchors that cover different or additional QNAMEs.
962 It is the model recommended in Section 5.9 of this document.
964 CD F/C line conditions action
965 ====================================================================
966 1 F A1 Set CD=1 on upstream query
967 0 F A2 Set CD=1 on upstream query
968 1 C A3 Return the cache contents
970 0 C A4 no covering TA Return cache contents
972 0 C A5 covering TA Validate cached result and
975 Model 2: "never set when receiving CD=0"
977 This model is so named because it sets CD=0 on upstream queries for
978 all received CD=0 queries, even if it has a covering trust anchor.
979 The general philosophy represented by this table is that more than
980 one resolver may take responsibility for validating a QNAME and that
981 a validation failure for a QNAME by any resolver in the chain is a
982 validation failure for the query. Using this model is NOT
985 CD F/C line conditions action
986 ====================================================================
987 1 F N1 Set CD=1 on upstream query
988 0 F N2 Set CD=0 on upstream query
989 1 C N3 cached data Return cached data
990 1 C N4 cached RCODE=2 Treat as line N1
991 0 C N5 no covering TA Return cache contents
993 0 C N6 covering TA & Treat as line N2
996 0 C N7 covering TA & Validate and return
1001 Model 3: "sometimes set"
1003 This model is so named because it sets the CD bit on upstream queries
1004 triggered by received CD=0 queries, based on whether the validator
1005 has a trust anchor configured that covers the query. If there is no
1006 covering trust anchor, the resolver clears the CD bit in the upstream
1010Weiler & Blacka Standards Track [Page 18]
1012RFC 6840 DNSSEC Implementation Notes February 2013
1015 query. If there is a covering trust anchor, the resolver sets CD=1
1016 and performs validation itself. The general philosophy represented
1017 by this table is that a resolver should try and validate QNAMEs for
1018 which it has trust anchors and should not preclude validation by
1019 other resolvers for QNAMEs for which it does not have covering trust
1020 anchors. Using this model is NOT RECOMMENDED.
1022 CD F/C line conditions action
1023 ====================================================================
1024 1 F S1 Set CD=1 on upstream query
1025 0 F S2 covering TA Set CD=1 on upstream query
1026 0 F S3 no covering TA Set CD=0 on upstream query
1027 1 C S4 cached data Return cached data
1028 1 C S5 cached RCODE=2 Treat as line S1
1029 0 C S6 cached data was Return cache contents
1032 0 C S7 cached data was Validate & return cache
1033 generated with contents
1036 0 C S8 cached RCODE=2 Return cache contents
1037 0 C S9 cached data Treat as line S3
1044Appendix C. Discussion of Trust Anchor Preference Options
1046 This section presents several different policies for validating
1047 resolvers to use when they have a choice of trust anchors available
1048 for validating a given answer.
1050C.1. Closest Encloser
1052 One policy is to choose the trust anchor closest to the QNAME of the
1053 response. For example, consider a validator configured with trust
1054 anchors for "example." and "zone.example." When asked to validate a
1055 response for "www.sub.zone.example.", a validator using the "Closest
1056 Encloser" policy would choose the "zone.example." trust anchor.
1058 This policy has the advantage of allowing the operator to trivially
1059 override a parent zone's trust anchor with one that the operator can
1060 validate in a stronger way, perhaps because the resolver operator is
1066Weiler & Blacka Standards Track [Page 19]
1068RFC 6840 DNSSEC Implementation Notes February 2013
1071 affiliated with the zone in question. This policy also minimizes the
1072 number of public key operations needed, which is of benefit in
1073 resource-constrained environments.
1075 This policy has the disadvantage of giving the user some unexpected
1076 and unnecessary validation failures when sub-zone trust anchors are
1077 neglected. As a concrete example, consider a validator that
1078 configured a trust anchor for "zone.example." in 2009 and one for
1079 "example." in 2011. In 2012, "zone.example." rolls its Key Signing
1080 Key (KSK) and updates its DS records, but the validator operator
1081 doesn't update its trust anchor. With the "Closest Encloser" policy,
1082 the validator gets validation failures.
1084C.2. Accept Any Success
1086 Another policy is to try all applicable trust anchors until one gives
1087 a validation result of Secure, in which case the final validation
1088 result is Secure. If and only if all applicable trust anchors give a
1089 result of Insecure, the final validation result is Insecure. If one
1090 or more trust anchors lead to a Bogus result and there is no Secure
1091 result, then the final validation result is Bogus.
1093 This has the advantage of causing the fewest validation failures,
1094 which may deliver a better user experience. If one trust anchor is
1095 out of date (as in our above example), the user may still be able to
1096 get a Secure validation result (and see DNS responses).
1098 This policy has the disadvantage of making the validator subject to
1099 the compromise of the weakest of these trust anchors, while making it
1100 relatively painless to keep old trust anchors configured in
1103C.3. Preference Based on Source
1105 When the trust anchors have come from different sources (e.g.,
1106 automated updates ([RFC5011]), one or more DNSSEC Lookaside
1107 Validation (DLV) registries ([RFC5074]), and manual configuration), a
1108 validator may wish to choose between them based on the perceived
1109 reliability of those sources. The order of precedence might be
1110 exposed as a configuration option.
1112 For example, a validator might choose to prefer trust anchors found
1113 in a DLV registry over those manually configured on the theory that
1114 the manually configured ones will not be as aggressively maintained.
1122Weiler & Blacka Standards Track [Page 20]
1124RFC 6840 DNSSEC Implementation Notes February 2013
1127 Conversely, a validator might choose to prefer manually configured
1128 trust anchors over those obtained from a DLV registry on the theory
1129 that the manually configured ones have been more carefully
1132 Or the validator might do something more complex: prefer a sub-set of
1133 manually configured trust anchors (based on a configuration option),
1134 then trust anchors that have been updated using the mechanism in
1135 [RFC5011], then trust anchors from one DLV registry, then trust
1136 anchors from a different DLV registry, then the rest of the manually
1137 configured trust anchors.
1141 Samuel Weiler (editor)
1143 7110 Samuel Morse Drive
1147 EMail: weiler@tislabs.com
1150 David Blacka (editor)
1156 EMail: davidb@verisign.com
1178Weiler & Blacka Standards Track [Page 21]