Starting this month, major certificate authorities (including Let's Encrypt) are checking DNSSEC validation before issuing TLS certificates. If your domain has DNSSEC enabled and the chain of trust is broken, your certificate renewal will fail. If you run automated certificate provisioning (and you should), this change requires attention.
What Changed
Previously, certificate authorities validated domain ownership through DNS challenges (prove you control the domain by creating a specific DNS record) or HTTP challenges (prove you control the server by serving a specific file). DNSSEC status was not checked - even if your domain had broken DNSSEC, you could still get a certificate.
The new behavior: CAs now query your domain's DNSSEC status. If DNSSEC is enabled (DS records exist in the parent zone) but validation fails (signatures expired, key rollover incomplete, algorithm mismatch), the CA rejects the certificate request. The logic is sound - if DNSSEC says the DNS response might be tampered with, the CA should not trust that DNS response for domain validation.
Why This Breaks Things
The problem is that DNSSEC is notoriously easy to break and hard to debug. Common failure modes:
Key rollover failures. DNSSEC keys need periodic rotation. If the new key is published in the zone but the DS record in the parent zone still references the old key, validation fails. This happens all the time with automated key rollovers.
Expired signatures. DNSSEC signatures have expiration dates. If your DNS server stops re-signing (because a cron job failed, a service restarted, or a disk filled up), signatures expire and validation fails. Your zone looks fine in every other way - records resolve, content is correct - but DNSSEC validation fails silently.
Registrar/provider mismatches. You transferred your domain to a new registrar but the old DS records are still at the parent zone. Or you changed DNS providers but did not update the DS records. The zone serves new keys, the parent references old keys, validation fails.
These failures have always been problems, but previously they were invisible. Your site still worked, your certificates still renewed, nobody noticed. Now, a DNSSEC failure means your certificate renewal fails, your site goes down, and you are scrambling to debug a protocol that most people barely understand.
What to Do Right Now
Check your DNSSEC status. Run dig +dnssec yourdomain.com and check that the AD (Authenticated Data) flag is set. Use an online DNSSEC debugger like dnsviz.net for a thorough analysis.
If you do not need DNSSEC, disable it. This is the unpopular but practical advice. If you are running a standard web service and not a high-security domain, the complexity of maintaining DNSSEC may not be worth the benefit. Remove the DS records from your registrar and DNSSEC goes away cleanly.
If you keep DNSSEC, monitor it. Add DNSSEC validation checks to your monitoring. Check that signatures are not expiring within the next 7 days. Check that DS records match your current keys. Alert on any validation failure. This should be as standard as monitoring certificate expiration.
Update your automation. If you have automated cert provisioning (Caddy, certbot, acme.sh), make sure it handles DNSSEC-related failures gracefully. The error messages from CAs are often cryptic - "DNS validation failed" without specifying that DNSSEC is the cause. Your automation should check DNSSEC separately and provide clear diagnostics.
Impact on Agent Infrastructure
If you run AI agents that manage infrastructure (and many of us do), this is exactly the kind of change that needs to be in your agent's knowledge base. An agent handling certificate renewals needs to know that a renewal failure might be caused by DNSSEC, not just DNS propagation delays or challenge serving issues.
I updated my infrastructure agent's troubleshooting playbook to check DNSSEC validation as the first step when certificate operations fail. It has already caught two issues that would have taken me hours to debug manually.
The broader lesson: infrastructure changes ripple through automated systems in unexpected ways. Every new check, new requirement, or new validation that gets added to critical infrastructure protocols needs to be reflected in the agents and automation that interact with those protocols. This DNSSEC change will not be the last.