One of the problems with DNSSEC is that it causes the size of DNS responses to increase substantially, which becomes a DDoS vector. The response to this is nominally to use response rate limiting, but the more people who use DNSSEC the less effective that is because it means more DNS servers the attacker can use to reflect their attack through without reaching the rate limit for any one. (RRL is also not ideal because a large DNS cache can hit the rate limit by just making a large number of legitimate queries.) And the more servers that use DNSSEC the harder to block a DDoS attack because it comes from a larger number of unique addresses.

And now TXT records used for domain validation are becoming quite large as well. You add a ~hundred byte TXT record for each service you want to validate your domain against, but they all want the entry to go in the same place (at the root), so you do the DNS TXT query for the root and you get a big response. Adding DNSSEC on top of that might even blow the practical limit for UDP EDNS0 responses sometimes, never mind the DDoS potential.

There may be a solution for that one -- specify a location for each TXT record instead of everyone using the root, so Facebook uses _facebook-domain-verification.[example.com], Google uses _google-site-verification.[example.com], etc. Then you wouldn't get a dozen large TXT records in response to a single query because they're each at a different name. But that's not currently what companies are doing, and a purist wouldn't like it because in principle controlling _google-site-verification.example.com doesn't mean you control all of example.com.

For at least some of this, TCP could be a decent solution. For CAA queries, for example, no one really cares how fast the query is, so a server could plausibly refuse to answer over UDP.

That works for the thing expecting the large response, but requires an unusual custom configuration on the server (refuse UDP queries for specific record types but not others), and doesn't really help other clients that may make queries that yield large responses unexpectedly.

For example, the large TXT records can prevent mail delivery from some versions of qmail, including the one currently packaged with Debian stable, because it makes an ANY query for the domain (to avoid separate queries for MX, A and CNAME) but only supports UDP and only supports responses up to the 512 octets specified in RFC1035. Then it gets a truncated response when there are >512 octets of TXT records and considers it a name resolution failure.

Making the ANY query is an unusual quirk in qmail, but it could have just as easily been an actual TXT query looking for the SPF record etc.

Route53 was very slow to even enable CAA itself. They are not exactly at the bleeding edge of DNS features.

CA/B Baseline Requirement 3.2.2.8 says to do RFC 6844, and that CAs need to implement at least enough DNSSEC so that they can determine whether "the domain's zone does not have a DNSSEC validation chain to the ICANN root" because if there is no DNSSEC validation chain you can treat DNS failure as permission.

In practice most larger CAs just do DNSSEC entirely here, Let's Encrypt uses it everywhere. Deployability to ordinary end user clients remains poor due to middle boxes and local DNS implementations that are garbage, but if you actually control your network (as a competent CA should) then it isn't a problem.

The sort of CAs and CA-customer relationships where DNSSEC was argued to be problematic aren't going to be doing ACME CAA, or probably ACME at all.

[Edited to delete me confusing one ID for another]

I don't believe that this description of DNSSEC functionality inside CAs is accurate. Can you be specific about which CAs you believe do a good job of validating DNSSEC --- not just somehow "running" it, but making use of it operationally?

The largest CA by volume, Let's Encrypt, uses DNSSEC for all its validations, and hard fails issuance if it can't get either a DNSSEC validation or the signed denial saying this part of the hierarchy isn't signed, it has done this for years now. Works well.

Several other major CAs including DigiCert do DNSSEC validation but I haven't used them and so can't even tell you from my own experience how well they work, though it seems likely some of their other customers might have noticed on that end.

Now, are they all doing a "good job"? If you actually were paying any attention at all in this space you'd presumably have quoted my already published opinions about that. I think they should retain the DNS responses the same way they would keep the actual raw data from an HTTP validation. So third parties doing incident investigation can do an effective post mortem - I also think they use too many "short cuts" that are going to result in someone finding a nasty bug one of these days and for which there's no real evidence they're necessary.

But since it seems for you a "good job" is just using something operationally, then yeah, in that limited Thomas Ptacek sense of "good job" they're already doing a good job I guess.

Can you confirm another CA other than LetsEncrypt that will reliably deny issuance on a DNSSEC failure?

(Obviously, just to point something out for the thread that you already know, the vast, overwhelming majority of LetsEncrypt issuances are for zones without DNSSEC signatures).

Given that I already wrote that...

> I haven't used them and so can't even tell you from my own experience how well they work

... I'm not sure what my "confirmation" would tell you, beyond that I know how to read the paperwork from the CAs. But sure, both Sectigo and DigiCert say their systems should deny issuance on DNSSEC failure.

I'm asking because I want to know, not to make a point.