SC-085: Require Validation of DNSSEC (when present) for CAA and DCV Lookups #579
Conversation
Catchup to main
|
Please don't forget to add the referenced RFCs in section 1.6.3. |
Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com>
|
My recent commits added a reference to the appropriate RFCs in Sec 1.6.3 I also did a full review of RFC 6840. Several Forum members advised either moving the RFC 6840 reference to a SHOULD or bringing in specific sections. Upon reviewing the RFC I feel the only sections that need to be referenced in the Baseline Requirements are Sections 2 and Sections 4 and it would be best to keep them as a MUST statement. Section 2 defines the critical additional algorithms NSEC3 and SHA-2. To quote RFC 6840: Validators that do not support I personally feel SHA-2 is in a similar boat given it has become a very popular digest algorithm and not supporting it significantly hampers the effectiveness of DNSSEC validation. RFC 6840 Section 4 describes several security concerns. Some of these are merely clarifications of previous RFC text. As RFC 6840 states: This section provides clarifications that, if overlooked, could lead I similarly think these are important to include as a MUST statement. The other text in the RFC discusses other concerns like interoperability and are not critical to the secure operations of DNSSEC. If someone is aware of a modern DNS resolver that does not comply with sections 2 and 4 of RFC6840 please let me know. This RFC is now 12 years old and largely presents clarifications on the proper way to operate DNSSEC. I has been included in every RFC compliance list I have found. |
docs/BR.md
Outdated
| * MUST support NSEC3 and SHA-2 as defined in [RFC 6840 Section 2](https://datatracker.ietf.org/doc/html/rfc6840#section-2); and | ||
| * MUST properly handle the security concerns enumerated in [RFC 6840 Section 4](https://datatracker.ietf.org/doc/html/rfc6840#section-4) | ||
|
|
||
| DNSSEC validation back to the ICANN DNSSEC root trust anchor MAY be performed on all DNS queries associated with the validation of domain authorization or control by Remote Network Perspectives used for Multi-Perspective Issuance Corroboration. |
There was a problem hiding this comment.
I received a comment that IANA maintains the DNSSEC root trust anchor, not ICANN.
There was a problem hiding this comment.
IANA is more appropriate here. I will update this. The old text in the BRs referencing the DNSSEC root trust anchor said ICANN, but IANA is actually tasked with managing it.
| * the failure is outside the CA's infrastructure; and | ||
| * the lookup has been retried at least once; and | ||
| * the domain's zone does not have a DNSSEC validation chain to the ICANN root. | ||
| * the CA has confirmed that the domain is "Insecure" as defined in [RFC 4035 Section 4.3](https://datatracker.ietf.org/doc/html/rfc4035#section-4.3). |
There was a problem hiding this comment.
There were discussions back in 2017 about fidelity of popular DNSSEC implementations against the RFC definitions of "insecure" and "bogus": https://groups.google.com/g/mozilla.dev.security.policy/c/2WxCMEYEbrE/m/nlRjRfiTAQAJ.
I haven't had the cycles to investigate yet whether the situation has changed, but this is an area where historically there was deviation between the RFC definition and popular implementations.
There was a problem hiding this comment.
Thanks for bringing this up. I did review the thread and I think the main issue was unbound-host marking several domains as "insecure" where in fact it had lookup errors so the insecure status of the domain could not be determined.
It appears this issue has been fixed an updated version of unbound-host. Rerunning the queries in question I now get a status of "2(SERVFAIL). (error)" which no longer states the domain is insecure, thus complying with the RFC. This ballot language also has an explicit reference to the "SERVFAIL" error (see line 1132 of the new changes) as not being permission to issue which I think is helpful.
Even in light of this, I still think the use of RFC language is superior to prior language in the BRs.
- The RFC 4035 definition of "Insecure" properly defines the state of a domain which is appropriate for this CAA check failure language. Given there is an existing and appropriate definition in a well established DNSSEC standard doc, I think the correct thing is to use it.
- I think these problems and bugs discussed exist whether the old or new language is employed. The linked MDSP thread is in fact debating the applicability of signing certificates in these states under the old baseline requirement language (which is in my opinion a less accurate and more ambiguous description of the RFC 4035 insecure state). The root of the problem is that if a DNS resolver encounters certain types of lookup errors, it can be very difficult to determine the DNSSEC state of a domain. I think this challenge is helped by specifically tying the requirement to the RFC 4035 insecure state which is understood by DNS software. Without this I personally don't see a straightforward way for a CA to deduce the presence of absence of a DNSSEC chain given the CA's DNS resolver is throwing an error on the domain in question.
- As I stated previously, the mentioned bug has since been fixed.
A longer-term initiative along this front could be to conduct a survey of CAs and find out how many still issue on CAA lookup failures. The cleanest approach down the road would probably be to remove this language (i.e., require all CAA lookups to be successful) because this clause requires DNS resolvers that return errors to additionally indicate if the domain in question was DNSSEC signed or not. If the DNS resolver had an error, then something went wrong, and it is likely the DNS resolver will not be able to make an accurate attestation of the domain's DNSSEC status.
In the interest of minimal changes in each ballot, I felt proposing removal of this language would simply complicate things and is not fully related to DNSSEC. However, given that we now have an RFC 4035 reference, I feel using it here is appropriate and offers more clarity.
Below are the outputs of my unbound-host runs using the same flags as the original MDSP post:
henry@MacBook-Pro-259 sbin % ./unbound-host -v -t CAA -D -f /usr/local/etc/unbound/root.key blackhole.caatestsuite-dnssec.com.
Host blackhole.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (error)
henry@MacBook-Pro-259 sbin % ./unbound-host -v -t CAA -D -f /usr/local/etc/unbound/root.key servfail.caatestsuite-dnssec.com.
Host servfail.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (error)
henry@MacBook-Pro-259 sbin % ./unbound-host -v -t CAA -D -f /usr/local/etc/unbound/root.key refused.caatestsuite-dnssec.com.
Host refused.caatestsuite-dnssec.com. not found: 2(SERVFAIL). (error)
henry@MacBook-Pro-259 sbin % ./unbound-host -v -t CAA -D -f /usr/local/etc/unbound/root.key expired.caatestsuite-dnssec.com.
expired.caatestsuite-dnssec.com. has no CAA record (BOGUS (security failure))
validation failure <expired.caatestsuite-dnssec.com. CAA IN>: signature expired from 45.79.179.40 and 45.79.179.40 for key expired.caatestsuite-dnssec.com. while building chain of trust
henry@MacBook-Pro-259 sbin % ./unbound-host -v -t CAA -D -f /usr/local/etc/unbound/root.key missing.caatestsuite-dnssec.com.
missing.caatestsuite-dnssec.com. has no CAA record (BOGUS (security failure))
validation failure <missing.caatestsuite-dnssec.com. CAA IN>: no signatures from 45.79.179.40 for key missing.caatestsuite-dnssec.com. while building chain of trust
There was a problem hiding this comment.
Thanks for checking this. What version of unbound-host are you using?
There was a problem hiding this comment.
Unbound and unbound-host are Version 1.22.0
docs/BR.md
Outdated
| Effective November 15th, 2025: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective: | ||
|
|
||
| * MUST be a "security-aware resolver" as defined in [RFC 4035 Section 4](https://datatracker.ietf.org/doc/html/rfc4035#section-4); and | ||
| * MUST support NSEC3 and SHA-2 as defined in [RFC 6840 Section 2](https://datatracker.ietf.org/doc/html/rfc6840#section-2); and |
There was a problem hiding this comment.
I don't see any MUST-level requirements in https://datatracker.ietf.org/doc/html/rfc6840#section-2.1 (NSEC3) or https://datatracker.ietf.org/doc/html/rfc6840#section-2.2 (SHA-2) for validators to implement these two features. They are "strongly encouraged", which I interpret to be a "SHOULD" as opposed to being mandatory.
There was a problem hiding this comment.
In this situation, I think it is important to consider context. Particularly 1) RFC 6840 is now 13 years old and 2) the RFC is titled "Clarifications and Implementation Notes for DNS Security (DNSSEC)." Given this RFC is intended to be clarification and security notes, I suspect the IETF would have deemed it inappropriate to use MUST to dictate the use of new algorithms. Furthermore, this type of language would also instantaneously made any existing DNSSEC implementation that had not yet implemented those algorithms non-compliant which I do not think was the goal of this RFC. In today's DNSSEC ecosystem I feel a MUST is appropriate for both of these. I will address the case for SHA-2 and NSEC3 separately.
SHA-2: IANA lists the SHA-2 algorithm as mandatory ( https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml ). I feel SHA-2 being mandatory is particularly critical as the behavior of a DNSSEC-validating resolver when it encounters an unknown digest algorithm is to continue processing the lookup without performing validation. The delegations to .com, .net and .org all use the SHA-2 digest so any domain under these TLDs cannot be validated if a resolver does not support the SHA-2 digest. Measuring the top DNSSEC domains on the Tranco list ( https://tranco-list.eu ) shows 960 out of the 1058 DS records found use the SHA-2 algorithm ( https://github.com/birgelee/dnssec-measurements ). Furthermore, there exist no viable alternatives to the SHA-2 digest. The SHA-1 digest originally introduced in the first DNSSEC documents is now broken and all other digests are optional with limited support. Thus, if SHA-2 is not supported there is no option for a secure digest algorithm. Given that unknown digest algorithms cause a fail-open behavior, not supporting SHA-2 is similar to not validating at all. I personally cannot see mandating DNSSEC without requiring support of the SHA-2 digest.
NSEC3: Unlike SHA-2 support, resolvers lacking NSEC3 support will fail closed in the presence of NSEC3 records. If a recursive resolver queries a record that does not exist and cannot understand an NSEC3 record, it will be unable to validate the proof of nonexistence and return an error code for the query. Technically this is an availability not a security concern. However, NSEC3 is quite prominent with 296 / 707 top domains using it ( https://github.com/birgelee/dnssec-measurements ). A CA not supporting NSEC3 will likely encounter significant errors particularly since CAA record behavior treats the absence of the record as permission to issue. This could harm DNSSEC deployment as many properly configured domains will encounter DNSSEC errors which are not the domain's fault but due to the CA's use of an outdated DNSSEC validator.
It is important to remember that RFC 6840 is 13 years old. 13 years ago, it may not have seemed fitting to strictly mandate the use of these new algorithms and it reasonable that the algorithms be recommended for a significant period of time before being mandated. RFC 6840 does still contain strong language as it "define[s] NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification." (RFC 6840). Given that 1) NSEC3 and SHA-2 are core parts of the DNSSEC specification and 2) these algorithms have been deployed significantly leading to high prevalence and even dominance (in the case of SHA-2) in the DNSSEC ecosystem, I think mandating their support is called for. Additionally, I would ask the question of what operational advantage is obtained by listing these as SHOULD? Are there any contemporary production DNS resolvers that do not support these algorithms? I would even argue there is an operational advantage to having these as a MUST given a resolver that does not support these methods is likely to be 13+ years out of date and subject to ample other security vulnerabilities.
There was a problem hiding this comment.
I was reviewing RFCs and I came across RFC 4034 Appendix A which reads:
A DNSSEC aware resolver or name server MUST implement all MANDATORY
algorithms.
RFC 4034 is referenced by RFC 4035 as being the authoritative reference for all DNSSEC resource records. Given that the current IANA registry lists SHA-2 as MANDATORY and 4034 requires support for all MANDATORY algorithms, I feel not supporting SHA-2 would be an RFC violation.
There was a problem hiding this comment.
To be clear, I don't have any objection to requiring NSEC3 or SHA-2 algorithm support for the reasons you noted. My point is that the current draft language does not establish any MUST-level requirements, because the referenced sections in RFC 6840 all contain SHOULD-level language. SHOULD-level "strong encouragements" do not become MUST-level requirements solely due to the passage of time. In a similar vein, updates to IANA registries (or any other RFC publication action) do not translate to BR normative changes absent BR language to require adherence to the MTI elements in the registry.
Instead, I think this ballot should instead directly reference the appropriate section(s) of the appropriate RFCs that define NSEC3 and the use of SHA-2. This will make the requirement much easier to understand.
There was a problem hiding this comment.
@CBonnell that makes sense. Thanks for clarifying. I will push a change to have the language directly reference the SHA-2 and NSEC3 RFCs.
docs/BR.md
Outdated
|
|
||
| Effective November 15th, 2025: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective: | ||
|
|
||
| * MUST be a "security-aware resolver" as defined in [RFC 4035 Section 4](https://datatracker.ietf.org/doc/html/rfc4035#section-4); and |
There was a problem hiding this comment.
A few thoughts:
- This ballot should explicitly disallow CAs from using the "get out of jail free card" where DNSSEC validation is disabled if defined by local policy (RFC 4035, section 4.2)
- I think the fragmentation guidance in section 4.1 regarding proper handling of fragmentation is outdated. See https://www.dnsflagday.net/2020/. Specifically, the SHOULD in that section is outdated.
- The requirement to discern the four different states is not strictly required. Specifically, there is no need to distinguish between Bogus and Indeterminate for the purposes of domain validation.
- Add a reference to RFC 8198, section 7? https://www.rfc-editor.org/rfc/rfc8198.html#section-7
There was a problem hiding this comment.
regarding local policy
I agree. Possibly language like the following could be added:
CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control.
with a corresponding line in the CAA section.
regarding fragmentation guidance
That is correct. The SHOULD in that section is outdated and the DNS Flag Day recommendation is the current best practice (e.g., https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html ). Perhaps just adding a clarifying SHOULD in the bullet list
- SHOULD have the Extension Mechanisms for DNS (EDNS) buffer size set to 1232 bytes.
regarding distinguishing between Bogus and Indeterminate
I agree that distinguishing between Bogus and Indeterminate is not required. I feel both should be treated as a lookup failure that does not give permission to issue. Maybe the first bullet could be changed to:
- MUST be a "security-aware resolver" as defined in RFC 4035 Section 4 with the exception that the resolver does not need to distinguish between the Bogus and Indeterminate sates; and
RFC 8198, section 7
Sure. Potentially in the DNS resolver bullet list stating the properties, a property could be added stating:
- SHOULD follow the guidance in RFC 8198 Section 7.
I will note that I don't think this update is strictly needed from a security or compliance standpoint.
|
Hi all, I had gotten feedback from @CBonnell that RFC 4035 Section 4 contained several out of date SHOULD statements and required "security-aware" DNS resolvers to do more than what was strictly needed for DNSSEC validation at CAs. @dzacharo also noted that putting in additional SHOULD statements to update those requirements meant specifying several operational angles of DNS that could be left out of this ballot. To remedy this situation, in the 4/17/2025 validation subcommittee teleconference @CBonnell proposed looking for a more narrow definition to pull in that would only mandate DNSSEC without any of the operational considerations. Along these lines, I noticed that the "security-aware" DNS resolver definition in RFC 4035 Section 4 made many statements about the operational behavior of a security-aware DNS resolver (e.g., what types of caches it should maintain, how it should handle the DO and AD bits, etc.) which are not strictly relevant from the perspective a BR change mandating DNSSEC validation. However, Section 5 of RFC 4035 specifically describes the DNSSEC validation algorithm without specifying any of the other properties of a security-aware DNS resolver. Furthermore, the only RFC that updates RFC 4035 Section 5 is RFC 6840 Section 4, which is already being referenced in this ballot. There are 4 other RFCs that update statements made in Section 4 of RFC 4035 (including RFC 8198 section 7 brought up by @CBonnell) which would arguably each need an additional statement in the ballot text to address the ways in which RFC 4035 Section 4 text was inaccurate or out of date. To this end, I changed the text to simply require implementation of the algorithm in RFC 4035 Section 5. This removed the need for the statement about validating the different security states and removed the SHOULD statement about the EDNS buffer size. Both of these statements were related to text in RFC 4035 Section 4. I like that this is a more minimal specification and produces fewer lines of text. @CBonnell and @dzacharo, please let me know your thoughts on this change. |
|
Hi all, I wonder what this ballot is supposed to require CAs to do in the following situations:
|
|
First and foremost I want to clarify that from the purposes of this ballot (and I would argue for DNSSEC in general), ".cn" is not misconfigured. The notices presented by dnsviz.net on this TLD are intended for DNS zone operators to improve their DNSSEC configuration. ".cn" does not lead to a lookup error on any DNSSEC validating resolver. In fact, the inclusion of RFC5155 in this ballot text ensures that CAs will resolve this zone correctly with a NOERROR response code. The proper configuration of .cn can be confirmed with the following command: Notice the unbound host tool properly accepted the non-existence proof showing the domain has no IPv4 A address and marked the domain as “secure” (i.e., having a valid DNSSEC signature chain). DNSSEC and non-DNSSEC domains under “.cn” also show NOERROR response codes and valid signatures. For example: sjtu.edu.cn is DNSSEC signed under .cn and resolves fine. At the end of this response, I have a more detailed discussion of the DNSSEC configuration on .cn, but it will not cause a lookup error on proper resolver implementations. Regarding these specific points:
Regarding the .cn DNSSEC configuration: As I stated above, this DNSSEC configuration is perfectly valid. DNSVis’s complaint with the domain (seen when the non-existence setting is turned on) is that it does not follow RFC 9276 which is Best Current Practice 236 (BCP 236). Specifically, .cn uses the hash-iterations field of its NSEC3 record (which is well defined and standardized in RFC 5155 and would be supported by this ballot). BCP 236 states that domains MUST use an iteration count of 0 (i.e., not using hash iterations). .cn uses an iteration count of 10, but this is actually pretty standard and I have even seen 10 recommended elsewhere. Ironically, increasing the hash iteration count actually provides additional security against zone enumeration attacks for the .cn zone although presents a slightly higher load to DNSSEC-validating resolvers which is why it was set to zero in BCP 236. Importantly:
Below is a full DNSSEC-enabled query for .cn and a DNSSEC-signed domain under .cn. Both return NOERROR codes and would not cause a validation problem by CAs. |
|
Henry, thank you for putting together this proposal. GTS fully supports requiring DNSSEC validation for the additional security properties it provides. It has been mentioned that using an open source resolver should allow CAs to meet the requirements of this proposal. Coincidentally, GTS went through this exercise several months ago when we started the process of moving to a new DNS resolution solution using an open source resolver. GTS has performed DNSSEC validation for several years now, so DNSSEC support was an important consideration when evaluating the available resolvers. I will share our analysis below to highlight some implementation considerations that may come up. After eliminating resolvers which were not options for us due to license restrictions (this includes PowerDNS which uses the GNU GPLv2 license), we evaluated the following list: Bind We found Bind and Unbound to be the only feasible choices. Unbound has some level of security audit: https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results/ and Bind has extra functionality which we didn’t need and we didn’t want the additional attack surface. So we chose Unbound. One consideration to be aware of with this, is if a lot of CAs land on the same open source resolver, then a vulnerability or a bug in that resolver would render all of those CAs unable to operate, and possibly require mass revocations. |
|
Hickory-DNS still carries the warning that it is not production ready: https://github.com/hickory-dns/hickory-dns/blob/main/bin/README.md?plain=1#L48 |
|
@geegeea DNSSEC Validation TestingA purpose of this ballot is to implement DNSSEC in a way that is easy to verify and test. There are several services for testing the DNSSEC validation behavior of a resolver. One such service is Check My DNS by DNS OARC which can be run in a browser and does check for DNSSEC support (as well as other good security features of DNS resolvers). Below I list several commands to test for specific DNSSEC features. In the below commands, replace
To make the above-mentioned testing process automated, you can see the script at https://github.com/birgelee/dnssec-validator-test for an example. To be clear, the best way to verify the required DNSSEC support is by documentation and confirmation with the project maintainers. These tests are not exhaustive. Impact of the DNSSEC requirement on the available options of DNS softwareRegarding the analysis presented by @geegeea , I want to mention that I do not think Knot Resolver should be excluded based on the now patched DNSSEC bug @geegeea mentioned. Knot resolver powered CloudFlare's 1.1.1.1 for a long time (https://blog.cloudflare.com/big-pineapple-intro/), is deployed by many large organizations, and offers an SLA for enterprises (https://www.knot-resolver.cz/support/pro/). Additionally, the maintainers of Knot Resolver (CZ.NIC) also provide one of the most widely used linux software routers (Bird) and have a fairly good reputation. Even reputable projects occasionally see bugs. Unbound and Bind, mentioned by @geegeea are also good alternatives. The Open MPIC project maintains an Unbound container (https://github.com/open-mpic/open-mpic-containers/tree/main/unbound), and Bind is probably the oldest and most established DNS resolver option. As @geegeea mentioned, people sometimes prefer lighter-weight resolvers like Unbound or Knot due to bloat concerns with Bind which 1) packages its recursive resolver with its authoritative DNS implementation and 2) has an extensive feature set which may not be needed in all cases. Hickory DNS is not production ready but will likely be the chosen option by Let's Encrypt once its development is complete (it is funded by the same parent organization ISRG). One advantage of Hickory DNS is that it is written in Rust, a memory safe language, whereas many of the other options are C or C++ codebases (primarily for efficiency). At a higher level, I think the most relevant consideration for this ballot is: to what extent does the DNSSEC requirement limit the number of DNS resolvers available to CAs? I would personally argue that requiring DNSSEC in fact assists with good DNS resolver choice and DNS resolvers that have not implemented DNSSEC are likely poorly maintained or not intended for enterprise use. E.g., DJBDNS does not natively support DNSSEC and the project is often considered no longer maintained (although many patches exist). While not an authoritative source, Wikipedia provides a very rough overview and lists 14 options for recursive DNS resolvers (13 if you count dbndns and djbdns as the same). Of these 13 options, only 4 lack DNSSEC support including options like djbdns (discussed earlier), Posadis (which has not had a new release since 2013) and Mara DNS (which seems to have one maintainer). Obviously, choice of DNS resolver is dependent on the needs of a CA, but I do think there are several options for DNS resolvers that support DNSSEC, and I feel DNSSEC support does not significantly limit DNS resolver options. Furthermore, many DNS resolvers specifically list RFCs they comply with ([Hickory] [Bind] [Unbound] [Power DNS], [Knot]) or make explicit statements about their support for DNSSEC (e.g., [Technitium], [MS DNS], [Secure64 Cache])). DNS resolver project maintainers can verify the required feature set for a CA. To clarify, the features mentioned in this ballot are quite standard on modern DNS resolvers. While I do agree that there is some centralization in the DNS ecosystem particularly when constraints like licensing terms are imposed, I do not feel the DNSSEC requirement significantly reduces the available options of DNS resolvers and I think DNSSEC support is a good litmus test for whether a DNS resolver is well maintained and suitable for enterprise use. |
|
Henry, thank you for the commentary. Is it correct to summarize from the comment that resolvers like Unbound, Bind, and Knot are all good candidates for meeting the requirements of this ballot, but to definitively say so we would need to refer to documentation or confirm with maintainers? Regarding resolver choice, we agree with the assessment that: There is an assumption in the commentary that CAs all use third party resolvers (third party meaning a resolver which is developed outside of the CA’s org, not the BR term “delegated third party”). This may not be true, some CAs could have in-house developed resolvers, and depending on the enforcement timeline, this ballot could push most CAs to use third party resolvers. This may not be a significant risk for this ballot, but I want to point it out so the choice is intentional. |
docs/BR.md
Outdated
|
|
||
| Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. | ||
|
|
||
| Effective November 15th, 2025: DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective MUST: |
There was a problem hiding this comment.
Section 8.7 of the BRs requires the CA to monitor adherence to these requirements by performing self-audits on 3% of certificate issuances. Under the current ballot text, will a CA be required to also verify DNSSEC verification as part of these self-audits? Doing so will likely require saving all DNSSEC lookup records, and re-validating them during the self-audit. Can it be made explicit in the ballot text whether this will be expected or not?
There was a problem hiding this comment.
Hi @geegeea
Thanks for following up. To briefly clarify the comment I made about checking with documentation or maintainers. In the case of [Hickory] [Bind] [Unbound] [Power DNS], [Knot], all the RFCs listed in this ballot appear on their compliance lists and I feel this is sufficient to show these choices achieve compliance. Many other DNS resolvers state DNSSEC support but don't provide the same level of detail regarding their compliance. This is where I would recommend contact with maintainers. The RFCs required by this ballot are quite standard and I think it is unlikely a well maintained DNS resolver with DNSSEC support would have issue with them.
Regarding first-party-maintained resolvers: I encourage any CA in such a situation to speak up. I will say I think in-house developed resolvers do expose a CA to some risk of misissuance given the frequency of vulnerabilities and Best Current Practice updates regarding the DNS protocol. Some practices that were once commonplace for DNS resolvers are now serious security vulnerabilities (e.g., fixed source ports). If this ballot does encourage a push to externally-maintained DNS resolvers, that may even be beneficial to the ecosystem. Also, to clarify, no text in this ballot precludes the use of an in-house DNS resolver, but I do understand that CAs in this position may need longer to invest the required engineering resources.
I do not think DNS records should be saved for the purpose of the self audit. Many DNS resolvers do not produce a validation attestation and the volume of saving all DNS records is extremely high. In DNSSEC, my understanding is that DNS resolvers have the right to cache DNSSEC signed results without storing the underlying signatures used to validate those results (presuming the signatures verified correctly). Thus in many implementations it is non-trivial to simply ask the resolver to produce an entire validation chain particularly if intermediate results were not stored at the time the lookups were performed.
…eegeea's proposal Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com>
Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com>
* SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods (#553) * Introduce Schedule of Reducing Validity and Data Reuse Periods * Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days * Update Table Row header Fix copy/pasted table row header * Update SC-081 * Shift dates to March * Align on 3 dates for changes to take effect (2026, 2027, 2028) * Address various comments with corrections to wording * Update table formatting (to hopefully produce better-looking headings in the PDF output) * Update Tables * Update Table headings in 4.2.1 * Add "days" to tables for clarity * Remove 1 September 2020 date to align with table * Fix capitalization Remove erroneous capitalization of "Validation Data Reuse Periods" * Increase SII reuse period * Update table in Section 3.2.1 for "Subject Identity Information validation data reuse periods" to increase the Maximum data reuse period after March 15, 2026 from 366 days to 398 days. * Shift timeline of Validity Period * Move the reduction from 100 days maximum Validity Period to 47 days maximum Validity Period back by 1 year (from March 15, 2028 to March 15, 2029) * This change is based on discussion in the Servercert-wg call on Feb 13, 2025 and on-list for ballot SC-081. * Fix other 47-day timeline dates * Delay 10 day DCV reuse date Based on discussion in the Feb 27, 2025 SCWG meeting, this commit pushes the enforcement date for reducing the maximum reuse period of domain validation to 10 days from March 15, 2028 to March 15, 2029 -- aligning with the date for reducing the maximum validity period of certificates to 47 days. * Fixing workflow file Updating build-draft-docs.yml to match main * Introduce Schedule of Reducing Validity and Data Reuse Periods * Expand Section 4.2.1 to detail allowed data reuse periods for validation data (both for domains/IPs and for everything else in 3.2) * Overall reduction of non-SAN validation reuse from 825 to 366 days * Overall reduction of SAN validation reuse from 398 days to 10 days * Expand section 6.3.2 to detail schedule of reducing maximum validity periods in coming years * Overall reduction of maximum valdiity period from 398 days to 45 days * Update Table Row header Fix copy/pasted table row header * Update SC-081 * Shift dates to March * Align on 3 dates for changes to take effect (2026, 2027, 2028) * Address various comments with corrections to wording * Update table formatting (to hopefully produce better-looking headings in the PDF output) * Update Tables * Update Table headings in 4.2.1 * Add "days" to tables for clarity * Remove 1 September 2020 date to align with table * Fix capitalization Remove erroneous capitalization of "Validation Data Reuse Periods" * Increase SII reuse period * Update table in Section 3.2.1 for "Subject Identity Information validation data reuse periods" to increase the Maximum data reuse period after March 15, 2026 from 366 days to 398 days. * Shift timeline of Validity Period * Move the reduction from 100 days maximum Validity Period to 47 days maximum Validity Period back by 1 year (from March 15, 2028 to March 15, 2029) * This change is based on discussion in the Servercert-wg call on Feb 13, 2025 and on-list for ballot SC-081. * Fix other 47-day timeline dates * Delay 10 day DCV reuse date Based on discussion in the Feb 27, 2025 SCWG meeting, this commit pushes the enforcement date for reducing the maximum reuse period of domain validation to 10 days from March 15, 2028 to March 15, 2029 -- aligning with the date for reducing the maximum validity period of certificates to 47 days. * Fixing workflow file Updating build-draft-docs.yml to match main * Update version number and recent changes. --------- Co-authored-by: dzacharo <dzacharo@yahoo.com> * Bump workflow versions (#581) * Bump workflow versions * Set fetch-depth for changelog * Bump action workflow version * SC-081: Introduce Schedule of Reducing Validity and Data Reuse Periods Fixed table format * Fix formatting and effective date in section 1.2.2 (#595) * Fix formatting in 3.2.2.9 * Fix numbering in 5.4.1 * Fix effective date in 1.2.2 * SC-085: Require Validation of DNSSEC (when present) for CAA and DCV Lookups (#579) * require DNSSEC * SHOULD to MAY Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> * RFCs in sec 1.6.3. * Improved RFC 6840 reference * added effective dates and changed other should to may. * change ICANN DNSSEC root to IANA DNSSEC root * Added updates in response to CBonnell suggestions. * states typo fix * Using dzacharo 's proposed wording for SHOULD EDNS buffer size. * changed RFC 4035 reference to Section 5. * wording change * Updated effective date to March 15th, 2026 * explicitly omit DNSSEC validation from Section 8.7 self audits per @geegeea's proposal Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> * add exclusion to self audit for DCV DNSSEC checks Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> --------- Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> * SC085: Require Validation of DNSSEC (when present) for CAA and DCV Lookups (#606) * Update version number, recent changes and relevant dates * fix version * SC-089: Mass Revocation Planning (#611) * SC-089: Mass Revocation Planning (#610) * Initial draft of 5.7.1.2 Here is an initial draft of a proposal to add section 5.7.1.2 to the TLS Baseline Requirements. See Issue #602 * Added CPS Compliance Date Added a CPS compliance date of Dec. 1, 2025 --------- Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com> * Updated version number and relevant dates. * Fix formatting --------- Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com> * Fix formatting in table 1.2.1 (#613) --------- Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Henry Birge-Lee <henrybirgelee@gmail.com> Co-authored-by: Gurleen Grewal <gurleen.grewal@gmail.com> Co-authored-by: Ben Wilson <63610154+BenWilson-Mozilla@users.noreply.github.com>
(updating PR #571 ) Require DNSSEC for CAA and DCV lookups using an RFC reference. Obsoletes PR #571 and branches off of the latest commits on main instead of Clint's branch since Clint's branch (as Clint's old DNSSEC branch is now several commits behind).
Identical text as PR #571 except i.e., statement was removed per discussion to avoid confusion.