Lets Encrypt and DNSSEC verification

Hello everyone,

I read in RFC 8555 that using DNSSEC as CA is only recommended, but not mandatory. I also checked the CA/Browser Forum baseline requirements, which do not require CAs to use DNSSEC for lookups (if DNSSEC it is available). Checking this forum shows several posts, which show that DNSSEC seems to be checked by Let's Encrypt, but is there any official statement on DNSSEC? Does Let's Encrypt verify DNSSEC, when certificates are issued for a hostname?

Yes [before each (re)issuance].

2 Likes

Anyone who cares at all about security checks DNSSEC, and Let's Encrypt is no exception. While it does appear that DNSSEC isn't required for many of a CA's checks (though I don't understand why not), my understanding there are some restrictions on the checking of CAA specifically where DNSSEC needs to be used, or at least that there are some CAA errors can't be ignored if the domain is DNSSEC-signed.

In terms of "official statement", I'm not sure what there is, though there's a mention of it in the CAA documentation. But really at this point I'd call any DNS resolver system that doesn't check DNSSEC buggy.

2 Likes

Yes, but the absence of DNSSEC is not a reason for failure. However, if you do have DNSSEC enabled and for some reason it fails, then that is a reason for failure of the authorization.

Thus: DNSSEC isn't mandatory, but if it's in use, it needs to be valid.

That said, I agree with @petercooperjr. There's no good reason not to use DNSSEC IMO.

4 Likes

Let’s Encrypt always verifies DNSSEC. There are some cases CAs are permitted to not, but it is simpler for us and everyone to just always validate. We do not require domains to be DNSSEC signed.

6 Likes

I'm sure there are some DNS server implementations that still don't support signing zones with DNSSEC at all. Of the ones that do, some don't actually support it when using "advanced" features like CNAME flattening/ALIAS records which have become way more common in recent years with everything pointing to cloud-managed FQDNs rather than static IPs. And they'll continue to be common until SVCB/HTTPS records are better supported.

From a DNSSEC validation perspective, there are a ton of businesses out there that don't validate DNSSEC responses. I'd guess in a lot of cases, it's only off because that's the default and people are lazy. But I know some organizations explicitly choose to leave it disabled so they're less affected by outages caused by other orgs misconfigurations. I was surprised to learn how many large DNSSEC outages there have been over the years. Entire TLDs have been broken, like lots of them.

I'd be curious if there's a similar list of successful attacks that were possible because DNSSEC wasn't being validated.

3 Likes

Thank you very much for your answers!

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.