The rule changed on March 15, 2026
Your certificate renewal picked up a new dependency this spring, and it is one most teams never counted as being anywhere near the critical path. The DNSSEC signatures on your zone. As of March 15, 2026, every publicly trusted CA has to validate DNSSEC when it is present on your domain. That means both when it reads your CAA records and when it does the DNS lookups for domain control validation. The rule comes from CA/Browser Forum ballot SC-085v2, which passed in June 2025 and landed in the Baseline Requirements this March.
Here is what that buys you when it goes wrong. If DNSSEC is enabled and your signatures are broken, the CA's resolver gets a SERVFAIL. A CA that gets SERVFAIL on your CAA lookup does not issue. It cannot. The rule tells it to treat that as a failure, not as a "probably fine, carry on."
For years this only bit Let's Encrypt users. Let's Encrypt ran a validating resolver and would hand you a DNS problem: SERVFAIL looking up CAA error while some commercial CA down the road issued the same cert without blinking. That gap is closed now. Same rule, every CA.
What "validate DNSSEC when present" actually means
Two words carry the whole thing: when present. Never signed your zone? None of this touches you. There is no DS record in your parent zone, validators treat you as unsigned, and your CAA and DCV lookups work exactly like they did last year. You can stop reading.
Publish a DS record at your registrar, though, and you have opted in. From that moment every resolver that validates, and the CA's does, expects a clean chain from the root down to your records. An expired signature. A DNSKEY that no longer matches the DS. A ZSK rollover you fumbled. Any one of those flips your zone from "insecure" to "bogus," and bogus means SERVFAIL.
And here is the part people miss. This is not a DNS-01 problem. CAA gets checked on every single issuance, whatever challenge type you run. So a broken DNSSEC chain takes down HTTP-01 and TLS-ALPN-01 right along with it, even though neither of those goes near a TXT record. The CA reads your CAA before it signs anything at all, and if that read fails validation, you walk away with nothing. If you have never thought hard about which method you use, the split between DNS-01 and HTTP-01 matters less here than you would hope, because this rule sits upstream of all of them.
The failure mode nobody planned for: your signatures expire
This is the part that makes it genuinely dangerous and not merely annoying. DNSSEC signatures expire on a clock of their own, and that clock has nothing to do with your certificate.
Every RRSIG record carries an inception time and an expiration time. Your signer re-signs the zone on a cycle. A lot of setups use a signature validity of a couple of weeks and re-sign daily. While the signer runs, you never think about it. But let the signing pipeline stop and the trouble stays quiet at first. The HSM goes unreachable. A hidden primary falls over. Someone disables the cron that does the re-signing. Whatever the cause, the existing signatures keep validating right up to their expiration timestamp, and then they go bogus everywhere at once, for every validating resolver on the planet.
Now put the renewal cadence on top of that. Certificates are heading toward 47-day lifetimes, and Let's Encrypt already hands out six-day certs. Your ACME client is renewing more or less constantly. A DNSSEC outage that used to be a quiet 48-hour blip nobody caught now lands on top of a renewal window nearly every time it happens. The renewal fails. The old certificate keeps counting down. And if no one is watching both clocks, you find out the hard way, on the day the certificate actually expires.
How to tell if this affects you
Start with one question. Is your zone signed at all? Check the parent for a DS record:
dig DS example.com +short
Nothing comes back? You are unsigned and none of this is your problem. Get one or more DS records, and you are signed, so keep going.
Now confirm the chain actually validates right now, not in theory. delv is the tool. It does full validation the way a real resolver does, not the surface-level answer dig gives you:
delv @1.1.1.1 example.com CAA
A healthy zone prints ; fully validated next to the answer. See ; resolution failed: SERVFAIL or a complaint about a missing RRSIG, and your chain is broken this very second. Every CA trying to issue for you is hitting the same wall.
Debugging a DNSSEC-induced issuance failure
Issuance failed, and the error says SERVFAIL on a CAA or DNS lookup. Do not start with your ACME client. It is the messenger, not the problem. Go look at the signatures.
Pull the RRSIG on your CAA or SOA record and read the expiration field:
dig +dnssec example.com SOA
Each RRSIG line ends with two timestamps in YYYYMMDDHHMMSS form, an inception and an expiration. Expiration in the past, or close to it? Your signer stopped, and that is the whole story. Re-sign the zone, push it out, and issuance comes back as the fixed records propagate.
Timestamps look fine? Then the break is structural, and the usual culprit is a key rollover where the DS in the parent no longer matches any DNSKEY in your zone. Line them up:
dig DNSKEY example.com +short
dig DS example.com +short
The DS is a hash of a DNSKEY. If none of your current DNSKEYs hashes to the published DS, validators throw out the entire zone. Fix it by updating the DS at your registrar or republishing the key it expects. For anything you cannot read by eye, feed the zone to DNSViz or Verisign's DNSSEC debugger. Both draw the whole chain and point at the exact link that snapped.
SC100 tightened the language in August
The rule got a second pass this summer. On August 6, 2026, the Server Certificate Working Group reported the vote on ballot SC100, "DNSSEC Clarification and Consolidation," put forward by DigiCert and endorsed by Amazon and eMudhra. It passed, 22 members in favor, and sits in its IPR review period as of this writing.
SC100 does not move the goalposts, and nobody wanted it to. It tidies up the DNSSEC wording scattered across the Baseline Requirements and pins down one thing that had been murky. DNSSEC validation is required only on the Primary Network Perspective, and a CA may run it on the remote perspectives it uses for multi-perspective corroboration. That is the right call. Demanding a strict validation result from a dozen network vantage points would turn every transient resolver hiccup into a dead issuance. Your job does not change either way. The zone has to validate cleanly from the CA's main resolver, every single time it asks.
Shorter lifetimes make this a standing risk
It is tempting to file DNSSEC under set-it-and-forget-it. That held up when a certificate lasted a year and a DNSSEC wobble had four seasons to sort itself out before renewal came around. It does not hold up now. When lifetimes shrink, the window where a signing failure overlaps a renewal stops being a rare coincidence. It becomes the default, and it gets wider every time the industry knocks another chunk off the maximum.
DNSSEC signing health is certificate health now. If you sign your zones, the RRSIG expiration belongs on the same board as your certificate expiration, because either one can now take the other down. Watch only the certificate and you are blind to the thing that will stop you from renewing it. It is the same trap as every other certificate monitoring blind spot. The metric you are not graphing is the one that pages you at 3 AM.
What to actually do about it
Run DNSSEC? Then monitor signature expiration directly. Alert on the RRSIG expiration of your apex and your _acme-challenge records, not just on whether the zone resolves, because a zone resolves perfectly fine right up to the minute its signatures lapse. Give yourself days of headroom, not hours.
Treat a key rollover as a change that can break issuance, and stage it like you would any other change on the renewal path. Test it with delv from outside your own network before you call it done. And if a given zone has no real operational reason to run DNSSEC, be honest about whether it is worth the risk it adds to your certificate pipeline. An unsigned zone can never hand a CA a SERVFAIL.
For the zones where DNSSEC earns its keep, the answer is not to be scared of it. The answer is to watch it, because as of this March it sits squarely on the path to a working certificate.
Frequently asked questions
Does this apply to Let's Encrypt or to commercial CAs? Both. Let's Encrypt has validated DNSSEC and returned SERVFAIL on broken chains for years, so its users may not notice a thing. What changed on March 15, 2026 is that SC-085v2 makes this a Baseline Requirement for every publicly trusted CA, so a commercial CA that used to issue despite a broken chain is no longer allowed to look the other way.
I do not use DNS-01 validation. Am I still affected? Yes, if your zone is signed. CAA records get checked on every issuance no matter which challenge type you use, and that check now has to pass DNSSEC validation. A broken chain blocks HTTP-01 and TLS-ALPN-01 issuance just as hard as DNS-01, because the CA still reads your CAA before it signs.
How would a DNSSEC problem reach my certificates if the zone looks fine? DNSSEC signatures carry their own expiration, separate from the certificate. If your signer stops re-signing, the existing signatures keep validating until their expiration timestamp and then go bogus everywhere at once. The zone looked healthy right up to that moment, which is exactly why this one catches teams out.
What is the single most useful command to check my chain?
Run delv @1.1.1.1 example.com CAA. It performs full validation the way a CA's resolver does and prints fully validated on a healthy zone or a SERVFAIL on a broken one, which is the exact check a CA runs before it issues.
Does SC100 change anything I have to do? No. SC100 only clarifies and consolidates the existing DNSSEC language and confirms that strict validation is required on the Primary Network Perspective rather than on every remote one. The operational requirement, which is to keep your zone validating cleanly, has not moved.
