RFC 6840
Clarifications and Implementation Notes for DNS Security (DNSSEC)
RFC 6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) 🎀
Title block tea ☕
- Publisher: Internet Engineering Task Force (IETF) 🌸
- Authors: S. Weiler, Ed. (SPARTA, Inc.) and D. Blacka, Ed. (Verisign, Inc.) 👑
- Category: Standards Track, and the ISSN is 2070-1721 ✨
- Date: February 2013 🦋
- Updates: RFC 4033, RFC 4034, RFC 4035, and RFC 5155 🔥
- Obsoletes: the title block doesn't list any RFCs being obsoleted 🙈
Abstract 💖
Okay so this doc is basically a big bag of technical clarifications for the DNS Security (DNSSEC) document set 🧚. It's meant to help implementers, and it also gathers up the DNSSEC errata that existed when it was written 💅.
It updates the core DNSSEC docs (RFC 4033, RFC 4034, and RFC 4035) and the NSEC3 spec (RFC 5155). It also makes NSEC3 and SHA-2 (RFC 4509 and RFC 5702) core parts of DNSSEC, which is honestly iconic 👑.
Status of This Memo 📝
This is an Internet Standards Track document ✨.
It's a product of the Internet Engineering Task Force (IETF) and it represents IETF community consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 🌈.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6840 💜.
Copyright Notice ⭐
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they explain your rights and restrictions for this document 🫶. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧾.
This document might contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process 🙈. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside that process either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌸.
Table of Contents 🗂️
1. Introduction and Terminology ....................................4
1.1. Structure of This Document .................................4
1.2. Terminology ................................................4
2. Important Additions to DNSSEC ...................................4
2.1. NSEC3 Support ..............................................4
2.2. SHA-2 Support ..............................................5
3. Scaling Concerns ................................................5
3.1. Implement a BAD Cache ......................................5
4. Security Concerns ...............................................5
4.1. Clarifications on Nonexistence Proofs ......................5
4.2. Validating Responses to an ANY Query .......................6
4.3. Check for CNAME ............................................6
4.4. Insecure Delegation Proofs .................................7
5. Interoperability Concerns .......................................7
5.1. Errors in Canonical Form Type Code List ....................7
5.2. Unknown DS Message Digest Algorithms .......................7
5.3. Private Algorithms .........................................8
5.4. Caution about Local Policy and Multiple RRSIGs .............9
5.5. Key Tag Calculation ........................................9
5.6. Setting the DO Bit on Replies ..............................9
5.7. Setting the AD Bit on Queries .............................10
5.8. Setting the AD Bit on Replies .............................10
5.9. Always Set the CD Bit on Queries ..........................10
5.10. Nested Trust Anchors .....................................11
5.11. Mandatory Algorithm Rules ................................11
5.12. Ignore Extra Signatures from Unknown Keys ................12
6. Minor Corrections and Clarifications ...........................12
6.1. Finding Zone Cuts .........................................12
6.2. Clarifications on DNSKEY Usage ............................12
6.3. Errors in Examples ........................................13
6.4. Errors in RFC 5155 ........................................13
7. Security Considerations ........................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Appendix A. Acknowledgments .......................................16
Appendix B. Discussion of Setting the CD Bit ......................16
Appendix C. Discussion of Trust Anchor Preference Options .........19
C.1. Closest Encloser ..........................................19
C.2. Accept Any Success ........................................20
C.3. Preference Based on Source ................................201. Introduction and Terminology ✨
Here's the tea 🍵: this doc lists additions, clarifications, and corrections to the core DNSSEC spec. That spec was first described in [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. (For newer additions to that core set, see Section 2 👀.)
It's meant to be a resource for implementors, and a repository of stuff that existed when it was written and still needed fixing before the DNSSEC docs could move forward on the Standards Track 🦋.
1.1. Structure of This Document 🗂️
The changes and clarifications are sorted by importance 💅. We start with the ones that, if ignored, could cause security problems, and then go down to the ones that are expected to have very little operational impact 🌈.
1.2. Terminology 💬
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.
2. Important Additions to DNSSEC 🔥
This section lists some docs that are now considered core DNSSEC protocol docs, on top of the ones originally specified in Section 10 of [RFC4033] 💜.
2.1. NSEC3 Support 🧚
[RFC5155] describes how to use the NSEC3 and NSEC3PARAM records for hashed denial of existence 🙈. Validator implementations are strongly encouraged to support NSEC3, because a bunch of highly visible zones use it. Validators that can't validate responses using NSEC3 are going to struggle with large chunks of the DNS space 😭.
[RFC5155] is now considered part of the DNS Security Document Family, as described by Section 10 of [RFC4033] 👑.
Heads up 📣: the algorithm identifiers defined in [RFC5155] (DSA-NSEC3-SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512) signal that a zone might be using NSEC3 instead of NSEC. The zone could be using either one, and validators that support these algorithms MUST support both NSEC3 and NSEC responses 💅.
2.2. SHA-2 Support 🌸
[RFC4509] describes using SHA-256 as a digest algorithm in Delegation Signer (DS) RRs 🦋. [RFC5702] describes using the RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs ✨. Validator implementations are strongly encouraged to support these algorithms for DS, DNSKEY, and RRSIG records 🎀.
Both [RFC4509] and [RFC5702] are now considered part of the DNS Security Document Family, as described by Section 10 of [RFC4033] 🌈.
3. Scaling Concerns 📈
3.1. Implement a BAD Cache 🔥
Section 4.7 of [RFC4035] lets security-aware resolvers implement a BAD cache. That guidance has changed 🙃. Security-aware resolvers SHOULD implement a BAD cache, as described in [RFC4035] 💖.
Why the change? It's based on operational experience with DNSSEC administrative errors causing big spikes in DNS traffic. Those events are more likely and more damaging than people originally thought 😭. An example is documented in "Rolling Over DNSSEC Keys" [Huston] 📚.
4. Security Concerns 🔐
This section has clarifications that, if overlooked, could lead to security issues 🚨. Pay attention to this part, bestie 💀.
4.1. Clarifications on Nonexistence Proofs 🙈
Section 5.4 of [RFC4035] under-specifies the algorithm for checking nonexistence proofs 😬. As presented, the algorithm would let a validator read an NSEC or NSEC3 RR from an ancestor zone as proving that an RR doesn't exist in a child zone. Not okay 💀.
An "ancestor delegation" NSEC RR (or NSEC3 RR) is one that has:
- the NS bit set,
- the Start of Authority (SOA) bit clear, and
- a signer field that is shorter than the owner name of the NSEC RR, or the original owner name for the NSEC3 RR.
Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume nonexistence of any RRs below that zone cut. That covers every RR at that (original) owner name other than DS RRs, plus all RRs below that owner name, no matter the type 🚫.
Similarly, the algorithm would also let an NSEC RR at the same owner name as a DNAME RR, or an NSEC3 RR at the same original owner name as a DNAME, prove that names beneath that DNAME don't exist 😵. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume nonexistence of any subdomain of that NSEC/NSEC3 RR's (original) owner name 🛑.
4.2. Validating Responses to an ANY Query 🔍
[RFC4035] doesn't say how to validate responses when QTYPE=* 🤷♀️. As described in Section 6.2.2 of [RFC1034], a proper response to QTYPE=* can include a subset of the RRsets at a given name. So it's not necessary to include every RRset at the QNAME in the response 🧃.
When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus 💥. If there are no RRsets matching QNAME and QCLASS, that fact MUST be validated according to the rules in Section 5.4 of [RFC4035] (as clarified in this document) ✅. To be clear, a validator must not expect to receive all records at the QNAME in response to QTYPE=* 🫶.
Part 1 done, bestie 🌈💖
4.3. Check for CNAME ✨
Okay so, [RFC4035]'s Section 5 doesn't say anything explicit about validating responses based on CNAMEs (or what they should be based on, lol) 💅 So here's the rule, bestie: when validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap, in addition to the bit for the query type. 🫶
Why does this matter?? Without that check, an attacker could totally transform a positive CNAME response into a NOERROR/NODATA response, like by just stripping the CNAME RRset right off the response 😭 A naive validator would notice that the QTYPE isn't in the matching NSEC/NSEC3 RR, but it wouldn't catch that the CNAME bit was set. So the response should have been a positive CNAME response all along. Not on my watch 🔥
4.4. Insecure Delegation Proofs 🧚
Section 5.2 of [RFC4035] says that when a validator is proving a delegation is not secure, it needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. Then there's the bit I need you to remember: the validator also MUST check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (that proves there is, indeed, a delegation). Or, alternately, it can make sure the delegation is covered by an NSEC3 RR with the Opt-Out flag set. 🌸
Why is this so important?? Without that check, an attacker could reuse an NSEC or NSEC3 RR that matches a non-delegation name to spoof an unsigned delegation at that name. That would claim an existing signed RRset (or set of signed RRsets) is below an unsigned delegation, so it's not signed and becomes vulnerable to further attack. Literally a whole plot twist 💀
5. Interoperability Concerns 🎀
5.1. Errors in Canonical Form Type Code List 🍓
When canonicalizing DNS names (for both ordering and signing), DNS names in the RDATA section of NSEC resource records are not converted to lowercase. DNS names in the RDATA section of RRSIG resource records are converted to lowercase.
The guidance in that paragraph is different from what was published before, but it's consistent with current common practice, so it's giving realness ✨ Item 3 of Section 6.2 of [RFC4034] says names in both of these RR types should be converted to lowercase. The earlier [RFC3755] says they should not. Current practice follows neither document fully. Messy, but that's the vibe.
Also, Section 6.2 of [RFC4034] erroneously lists HINFO as a record that needs conversion to lowercase, and twice at that 🙈 Since HINFO records contain no domain names, they aren't subject to case conversion at all.
5.2. Unknown DS Message Digest Algorithms 🦋
Section 5.2 of [RFC4035] has rules for handling delegations to zones that are signed with entirely unsupported public key algorithms, as indicated by the key algorithms shown in those zones' DS RRsets. But it doesn't explicitly cover DS records that use unsupported message digest algorithms. So here's the tea: DS records using unknown or unsupported message digest algorithms MUST be treated the same way as DS records referring to DNSKEY RRs of unknown or unsupported public key algorithms. 🫶
The existing text says:
If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.
In other words, when a validator is figuring out the security status of a zone, it disregards any authenticated DS records that specify unknown or unsupported DNSKEY algorithms. If none are left, the zone is treated as if it were unsigned.
This document modifies the above text so validators also disregard authenticated DS records using unknown or unsupported message digest algorithms. Main character energy 👑
5.3. Private Algorithms 🔥
As discussed above, Section 5.2 of [RFC4035] requires that validators make decisions about the security status of zones based on the public key algorithms shown in the DS records for those zones. With private algorithms (described in Appendix A.1.1 of [RFC4034]), the eight-bit algorithm field in the DS RR isn't conclusive about what algorithm(s) is actually in use. Nobody knows for sure from that field alone, which is kind of wild 🙈
If no private algorithms appear in the DS RRset, or if any supported algorithm appears in the DS RRset, no special processing is needed. Also, if the validator implementation doesn't support any private algorithms, or only supports private algorithms using an algorithm number that isn't present in the DS RRset, no special processing is needed either.
In the remaining cases, the security status of the zone depends on whether or not the resolver supports any of the private algorithms in use (provided that these DS records use supported message digest algorithms, as discussed in Section 5.2 of this document). In these cases, the resolver MUST retrieve the corresponding DNSKEY for each private algorithm DS record and examine the public key field to determine the algorithm in use. The security-aware resolver MUST ensure that the hash of the DNSKEY RR's owner name and RDATA matches the digest in the DS RR, as described in Section 5.2 of [RFC4035], which authenticates the DNSKEY. If all of the retrieved and authenticated DNSKEY RRs use unknown or unsupported private algorithms, then the zone is treated as if it were unsigned. ✨
Note that if none of the private algorithm DS RRs can be securely matched to DNSKEY RRs, and no other DS establishes that the zone is secure, the referral should be considered Bogus data, as discussed in [RFC4035].
This clarification facilitates the broader use of private algorithms, as suggested by [RFC4955]. Growth 🌈
5.4. Caution about Local Policy and Multiple RRSIGs 💜
When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035] suggests that "the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results".
This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation. Simple, clean, no drama 💅
BUT if a resolver adopts a more restrictive policy, there's a danger that properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like the Double Signature Zone Signing Key Rollover method described in Section 4.2.1.2 of [RFC6781], won't work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures. Yikes 😭
5.5. Key Tag Calculation 🧮
Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field calculation for algorithm 1. It correctly says that the Key Tag is the most significant 16 of the least significant 24 bits of the public key modulus. However, [RFC4034] then goes on to incorrectly say that this is the fourth-to-last and third-to-last octets of the public key modulus. It's actually the third-to-last and second-to-last octets. Math is a whole mood 🙈
5.6. Setting the DO Bit on Replies 🔥
As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the query MUST be copied in the response. However, to interoperate with implementations that ignore this rule when sending, resolvers MUST ignore the DO bit in responses. Both rules are musts, so no cap, we're not negotiating this one 💅
5.7. Setting the AD Bit on Queries 🦋
The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries.
This document defines setting the AD bit in a query as a signal that the requester understands and is interested in the value of the AD bit in the response. This lets a requester show that it understands the AD bit without also requesting DNSSEC data via the DO bit. Iconic, honestly ✨
5.8. Setting the AD Bit on Replies 🌸
Section 3.2.3 of [RFC4035] describes the conditions under which a validating resolver should set or clear the AD bit in a response. To interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035] and the request contained either a set DO bit or a set AD bit. Careful, it's a lot of conditions, but it's so worth it 🫶
5.9. Always Set the CD Bit on Queries 🧚
When processing a request with the Checking Disabled (CD) bit set, a resolver SHOULD attempt to return all response data, even data that has failed DNSSEC validation. Section 3.2.2 of [RFC4035] requires a resolver processing a request with the CD bit set to set the CD bit on its upstream queries.
This document further specifies that validating resolvers SHOULD set the CD bit on every upstream query. This is regardless of whether the CD bit was set on the incoming query, or whether the resolver has a trust anchor at or above the QNAME.
[RFC4035] is ambiguous about what to do when a cached response was obtained with the CD bit unset. That case only arises when the resolver chooses not to set the CD bit on all upstream queries, as specified above. In the typical case, no new query is required, nor does the cache need to track the state of the CD bit used to make a given query. The problem shows up when the cached response is a server failure (RCODE 2), which may indicate that the requested data failed DNSSEC validation at an upstream validating resolver. ([RFC2308] permits caching of server failures for up to five minutes.) In these cases, a new query with the CD bit set is required. Plot twist, but we handled it 💖
Appendix B discusses more of the logic behind the recommendation presented in this section. Go read it, bestie 📖
5.10. Nested Trust Anchors 👑
A DNSSEC validator may be configured such that, for a given response, more than one trust anchor could be used to validate the chain of trust to the response zone. For example, imagine a validator configured with trust anchors for "example." and "zone.example." When the validator is asked to validate a response to "www.sub.zone.example.", either trust anchor could apply. Two valid options, one response, very dramatic 🎭
When presented with this situation, DNSSEC validators have a choice of which trust anchor(s) to use. Which one to use is a matter of implementation choice. Appendix C discusses several possible algorithms.
It is possible and advisable to expose the choice of policy as a configuration option. As a default, it is suggested that validators implement the "Accept Any Success" policy described in Appendix C.2, while exposing other policies as configuration options.
The "Accept Any Success" policy is to try all applicable trust anchors until one gives a validation result of Secure, in which case the final validation result is Secure. If and only if all applicable trust anchors give a result of Insecure, the final validation result is Insecure. If one or more trust anchors lead to a Bogus result and there is no Secure result, then the final validation result is Bogus. Every option gets a fair shot, and the best valid result wins 💅🦋
5.11. Mandatory Algorithm Rules 🎀
okay so the last paragraph of Section 2.2 of [RFC4035] lays out which algorithms a zone has to be signed with, and bestie, it was SO confusing 😭 so here it is again in plain words:
The DS RRset and DNSKEY RRset are how a zone says which algorithms it uses to sign itself. If an algorithm shows up in either one, that means the whole zone is signed with it 💅
A signed zone MUST include a DNSKEY for each algorithm in its DS RRset, plus the expected trust anchors for the zone. The zone MUST also be signed with each algorithm in the DNSKEY RRset. (Not each key, just each algorithm 🫶) You can add an algorithm to the DNSKEY RRset that isn't in the DS record, but you can't go the other way around. If there's more than one key with the same algorithm in the DNSKEY RRset, it's fine to sign each RRset with any subset of those keys. You can even sign some RRsets with one subset and others with a different subset, as long as at least one DNSKEY of each algorithm signs each RRset. And if there are DS records for several keys of the same algorithm, any subset of them can show up in the DNSKEY RRset. Iconic flexibility, honestly 🌈
This rule is for servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that every algorithm signaled in the DS RRset works, and they MUST NOT insist that every algorithm signaled in the DNSKEY RRset works. A validator MAY have a configuration option that runs a signature completeness test, which is a great little troubleshooting helper 🔧
5.12. Ignore Extra Signatures from Unknown Keys 🦋
Validating resolvers MUST disregard RRSIGs in a zone that don't (currently) have a matching DNSKEY in that zone. Same deal for RRSIGs whose algorithm type isn't in the DNSKEY RRset: a validating resolver MUST disregard those too 🙅♀️
Now, good key rollover and algorithm rollover practices, like the ones covered in RFC 6781 and its successor documents, and like the rules in the previous section, can mean these extra RRSIGs need to hang out in a zone for a while. So don't panic when you see them 💜
6. Minor Corrections and Clarifications ✨
6.1. Finding Zone Cuts 🗺️
Appendix C.8 of [RFC4035] talks about sending DS queries to the servers for a parent zone, but it never says how to find those servers. Good news, though: the specific instructions are in Section 4.2 of [RFC4035] 🙌
6.2. Clarifications on DNSKEY Usage 🔑
You can use different DNSKEYs to sign different subsets of a zone, as long as you follow the rules in Section 5.11. You can even use a different DNSKEY for every RRset in a zone, subject only to practical limits on the size of the DNSKEY RRset and those same rules. BUT, and this is a big but 😤, resolvers have no way of knowing what a particular DNSKEY is meant for. Any DNSKEY in the zone's signed DNSKEY RRset can be used to authenticate any RRset in the zone. So if a weaker or less trusted DNSKEY is handling NSEC RRsets or all the dynamically updated records, that same DNSKEY can also sign any other RRsets in the zone. Yikes 💀
Also, the SEP bit has zero effect on how a DNSKEY can be used. Section 2.1.2 of [RFC4034] specifically bans validation from using that bit at all 🙅♀️ So you can have a DNSKEY without the SEP bit set be the only secure entry point to the zone, while a DNSKEY with the SEP bit set signs every RRset except the DNSKEY RRset. You can also use one single DNSKEY, with or without the SEP bit, to sign the whole zone, DNSKEY RRset included 🌸
6.3. Errors in Examples 🙈
The text in Appendix C.1 of [RFC4035] calls the examples in Appendix B.1 x.w.example.com, but B.1 actually uses x.w.example. This is painfully obvious in the second paragraph, which says that an RRSIG labels field value of 3 means the answer was not the result of wildcard expansion. That's true for x.w.example, but not for x.w.example.com, which has a label count of 4 (and, antithetically, a label count of 3 would actually mean the answer was the result of a wildcard expansion) 🤓
The first paragraph of Appendix C.6 of [RFC4035] has a smaller slip too. It refers to a.z.w.w.example, but it should say a.z.w.example, like the line right before it 🧚
6.4. Errors in RFC 5155 💅
An NSEC3 record that matches an Empty Non-Terminal effectively has no type associated with it. That means this NSEC3 record has an empty type bit map. Section 3.2.1 of [RFC5155] contains this statement:
Blocks with no types present MUST NOT be included.
But the same section also has a regular expression:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+The plus sign means "one or more of the element before it." So there has to be at least one window block. If that window block has no types, it contradicts the first statement. The correct text in Section 3.2.1 of [RFC5155] should therefore be:
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*7. Security Considerations 🔐
This document adds SHA-2 and NSEC3 support to the core DNSSEC protocol. The security considerations for those features live in the documents that define them. This document also fixes some ambiguities and omissions in the core DNSSEC documents that could lead to security failures if implementations don't recognize and address them. The validation algorithm clarifications in Section 4 are critical for keeping the security properties DNSSEC offers, and no bestie, this is not a drill 😭 Plus, failing to deal with some of the interoperability concerns in Section 5 could make it harder to change or expand DNSSEC later, including adding new algorithms.
The recommendation in Section 5.9 to always set the CD bit has security implications. When a resolver sets the CD bit, it won't benefit from stricter validation rules or a more complete set of trust anchors at an upstream validator. Think carefully before you set it 🚨
8. References 📚
8.1. Normative References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
- [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
8.2. Informative References
- [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston, "Rolling Over DNSSEC Keys", Internet Protocol Journal, Vol. 13, No.1, pp. 2-16, March 2010.
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
- [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, July 2007.
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, September 2007.
- [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, November 2007.
- [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, December 2012.
Appendix A. Acknowledgments 🫶
The editors would like to thank Rob Austein for his earlier work as an editor of this document. 💖
The editors are extremely grateful to everyone who found errors and omissions in the DNSSEC document set and who also provided text for this document. You're all legends 🌟
David Blacka discovered the lack of specificity about handling private algorithms (Section 5.3) and the lack of specificity in handling ANY queries (Section 4.2).
Abhijit Hayatnagarkar found the error in the algorithm 1 key tag calculation (Section 5.5). Donald Eastlake contributed the text for Section 5.5.
Roy Badami found the bug relating to delegation NSEC RRs in Section 4.1, and Roy Arends found the related problem with DNAME.
Roy Arends found the errors in the [RFC4035] examples and also contributed text for Section 6.3 of this document.
The text on the mandatory algorithm rules was derived from suggestions by Matthijs Mekking and Ed Lewis.
David Blacka, Olafur Gudmundsson, Mike St. Johns, and Andrew Sullivan analyzed the CD bit logic in depth.
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer, Warren Kumari, and Scott Rose for their contributions to this document. ✨
Appendix B. Discussion of Setting the CD Bit ✨
okay so [RFC4035] kinda assumes there's only ONE validating system between the stub resolver and the authoritative server for a zone 🙈 but bestie, it's totally possible to have more than one validator in that chain. If those validators have totally different trust anchors configured, each one might be able to validate some part of the DNS tree, but neither one can validate all of it 😭 So someone could argue it's better NOT to set the CD bit on upstream queries, because that gives you the most validation possible 🧐
In Section 5.9 of this document, we recommend setting the CD bit on an upstream query even when the incoming query has CD=0 🫶 There are two reasons: it makes the validation experience more predictable, since only one validator is always doing the work 💅 and it makes sure all the DNSSEC data that exists can be pulled from the local cache if a query with CD=1 shows up later 🌸
As a matter of policy, you can set the CD bit differently than Section 5.9 suggests 🎀 Just know a different choice won't always give you those benefits. This doc isn't going to list every single consideration and counter-consideration for every possible policy (that would be a whole novel, lol 💀). But we can walk through three approaches and the thinking behind each one 🦋 They're in the tables below.
Each model's table has five columns 📊 Column one is the CD bit value the resolver receives (like on the name server side of an iterative resolver, or from local policy or the API if it's a stub). Column two says whether the query has to be forwarded for resolution (F) or can be answered from a local cache (C). Column three is a line number so you can refer back to it later. Column four has any relevant conditions at the resolver, like whether it has a covering trust anchor, and so on. If there aren't any conditions, that column is empty 🍓 Column five is the action the resolver takes.
The tables split things into "cached data" and "cached RCODE=2" 👑 That's a shorthand, btw. The real point is that you have to treat RCODE=2 (server failure) as special, because it might mean a validation failure happened somewhere upstream. So the real split is "cached RCODE=2" vs. "cached everything else" ✨
These tables are easiest to picture as a stub resolver sending a query to an intermediate resolver, but they're totally general and work for any validating resolver 💜
Model 1: "always set"
This model is named that because the validating resolver sets the CD bit on the queries it makes, no matter whether it has a covering trust anchor for the query 💖 The big vibe here is that only one resolver should be responsible for validation, even though an upstream resolver might exist with trust anchors covering different or extra QNAMEs. This is the model recommended in Section 5.9 of this document 🌈
CD F/C line conditions action
====================================================================
1 F A1 Set CD=1 on upstream query
0 F A2 Set CD=1 on upstream query
1 C A3 Return the cache contents
(data or RCODE=2)
0 C A4 no covering TA Return cache contents
(data or RCODE=2)
0 C A5 covering TA Validate cached result and
return itModel 2: "never set when receiving CD=0"
This model is named that because it sets CD=0 on upstream queries for every received CD=0 query, even if it has a covering trust anchor 🙅♀️ The philosophy here is that more than one resolver might take responsibility for validating a QNAME, and a validation failure for a QNAME by any resolver in the chain counts as a validation failure for the query. Using this model is NOT RECOMMENDED. 🥀
CD F/C line conditions action
====================================================================
1 F N1 Set CD=1 on upstream query
0 F N2 Set CD=0 on upstream query
1 C N3 cached data Return cached data
1 C N4 cached RCODE=2 Treat as line N1
0 C N5 no covering TA Return cache contents
(data or RCODE=2)
0 C N6 covering TA & Treat as line N2
cached data was
generated with CD=1
0 C N7 covering TA & Validate and return
cached data was
generated with CD=0Model 3: "sometimes set"
This model is named that because it sets the CD bit on upstream queries triggered by received CD=0 queries, depending on whether the validator has a trust anchor configured that covers the query 🎯 No covering trust anchor? The resolver clears the CD bit in the upstream query. Covering trust anchor? The resolver sets CD=1 and does the validation itself. The philosophy is that a resolver should try to validate QNAMEs it has trust anchors for, and it shouldn't block other resolvers from validating QNAMEs it doesn't have covering trust anchors for 🤝 Using this model is NOT RECOMMENDED. 💀
CD F/C line conditions action
====================================================================
1 F S1 Set CD=1 on upstream query
0 F S2 covering TA Set CD=1 on upstream query
0 F S3 no covering TA Set CD=0 on upstream query
1 C S4 cached data Return cached data
1 C S5 cached RCODE=2 Treat as line S1
0 C S6 cached data was Return cache contents
generated with
CD=0
0 C S7 cached data was Validate & return cache
generated with contents
CD=1 &
covering TA
0 C S8 cached RCODE=2 Return cache contents
0 C S9 cached data Treat as line S3
was generated
with CD=1 &
no covering
TAAppendix C. Discussion of Trust Anchor Preference Options 🧚
okay so this section lays out a few different policies that validating resolvers can use when they've got more than one trust anchor available for validating a given answer 💅
C.1. Closest Encloser
One policy is to pick the trust anchor closest to the QNAME of the response 📍 For example, say a validator has trust anchors for example. and zone.example.. When it's asked to validate a response for www.sub.zone.example., a validator using the "Closest Encloser" policy picks the zone.example. trust anchor 💖
This policy is great because the operator can easily override a parent zone's trust anchor with one they can validate in a stronger way, maybe because the resolver operator is affiliated with that zone 👑 It also cuts down on the number of public key operations needed, which helps a lot in resource-constrained environments 🔋
But it has a downside: it can hand the user some unexpected and unnecessary validation failures when sub-zone trust anchors get neglected 😭 Here's a concrete example. Imagine a validator that configured a trust anchor for zone.example. in 2009 and one for example. in 2011. In 2012, zone.example. rolls its Key Signing Key (KSK) and updates its DS records, but the validator operator doesn't update the trust anchor. With the "Closest Encloser" policy, the validator starts getting validation failures 🥺
C.2. Accept Any Success
Another policy is to try every applicable trust anchor until one gives a validation result of Secure, in which case the final validation result is Secure ✨ If and only if all applicable trust anchors give a result of Insecure, the final validation result is Insecure. If one or more trust anchors lead to a Bogus result and there's no Secure result, then the final validation result is Bogus 🌸
This has the big advantage of causing the fewest validation failures, which can mean a better user experience 🫶 If one trust anchor is out of date (like in our example above), the user might still get a Secure validation result and see DNS responses 🙌
The downside? This policy makes the validator subject to compromise of the weakest of these trust anchors 😬 And it makes it pretty painless to keep old trust anchors configured forever 🕰️
C.3. Preference Based on Source
When trust anchors come from different sources (for example, automated updates ([RFC5011]), one or more DNSSEC Lookaside Validation (DLV) registries ([RFC5074]), and manual configuration), a validator may want to choose between them based on how reliable it thinks those sources are 🔍 The order of precedence might be exposed as a configuration option 🎀
For example, a validator might prefer trust anchors found in a DLV registry over manually configured ones, on the theory that the manually configured ones won't be as aggressively maintained 🤔
Flip it around, and a validator might prefer manually configured trust anchors over ones from a DLV registry, on the theory that the manually configured ones have been more carefully authenticated 🔐
Or the validator might get more complex: prefer a subset of manually configured trust anchors (based on a configuration option), then trust anchors updated using the mechanism in [RFC5011], then trust anchors from one DLV registry, then trust anchors from a different DLV registry, then the rest of the manually configured trust anchors 🌈
Authors' Addresses 💌
Samuel Weiler (editor)
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
US
EMail: weiler@tislabs.com
David Blacka (editor)
Verisign, Inc.
12061 Bluemont Way
Reston, VA 20190
US
EMail: davidb@verisign.com📦 where this page comes from
- ietf: rfc6840 2013-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms