Why the Web's Certificate Revocation System Is Broken and What DNS Can Do Instead

The web's secure connections rely on X.509 certificates, digital documents that bind a website's public encryption key to its identity. When a certificate is stolen or misused, the issuing Certificate Authority (CA) can revoke it. But as Geoff Huston explains in a discussion on the APNIC blog, the X.509 model treats certificates as valid right up to their NotAfter expiry date. The only check on this relatively unconstrained use is that the relying party, the browser or app connecting to a site, should regularly check the CA's current revocation list, and the standard never clearly defines what 'regularly' means. The DNS takes a different view: local copies of authoritative DNS information may be used only for a specified Time to Live (TTL), after which a fresh copy must be fetched from an authoritative server. DNS does not revoke information; it replaces it, and expects clients to refresh within that TTL.

Two mechanisms exist for checking revocation. A Certificate Revocation List (CRL) is a bulky file containing serial numbers of all revoked certificates. The Online Certificate Status Protocol (OCSP) lets a client ask a CA in real time whether a specific certificate is still valid. Let's Encrypt, one of the largest CAs, has decided to step back from OCSP, in part because the associated query load reached about 140,000 queries per second, a forbidding problem. Notably, the Chrome and Android ecosystems did not perform OCSP checking at all. Only Apple and Firefox platforms did. Huston observes that if Chrome and Android had checked, given their far larger size relative to Apple and Firefox, this decision might have been reached years earlier.

Commenter Morgan Collett recalls that WTLS (Wireless Transport Layer Security) certificates in the late 1990s were intended to have very short validities because CRLs were infeasible on feature phones. VeriSign reportedly used 48-hour validities, renewed on a 24-hour basis. Huston then unpacks an unfortunate ambiguity in the X.509 NotAfter time. One interpretation refers to the subject of the certificate: the CA is unwilling to attest to the validity of the subject's public key after a certain time, signalling the subject to generate a new key pair and request a new certificate before then. Another interpretation refers to the relying party: the copy of the certificate being used should not be used after that date, and the certificate should be retrieved once more from the CA's publication point. To avoid CRLs, it would make sense to limit the lifetime of a copy of the certificate, forcing relying parties to re-check with the CA regularly without requiring the subject to go through a new Certificate Signing Request (CSR). But the industry ended up with the first interpretation, forcing subjects to get new CSRs simply because relying parties needed to check in more often.

New measurements add depth. Commenter tijay says that an OCSP-via-DNS design space was revisited in a SIGCOMM 2025 paper. Earlier proposals ODIN and DCSP stumbled by putting a separate DNS record per certificate. The new angle is to publish only revoked serials as DNSSEC-signed TXT records and use NSEC records plus aggressive negative caching for everything else. In that model, resolvers answer approximately 99.8 percent of checks from cache without contacting the CA, and Let's Encrypt's 612 million active certificates fit in a roughly 345 megabyte signed zone. Tijay calls this the same DANE and DNSSEC instinct, scoped specifically to revocation. The other surprising measurement is that a small handful of content delivery networks (CDNs) now serve the majority of OCSP traffic. About 70 percent of certificates have their revocation data fronted by just five providers. So even before Let's Encrypt's announcement, OCSP had quietly been re-centralized into a few CDN edges. Tijay argues that saying 'OCSP is broken' obscures the fact that what is actually broken is the decentralized version of OCSP.

Geoff Huston agrees that the centralisation of both CAs and CDN providers was evident, and the OCSP query load cited by Let's Encrypt is a forbidding problem. Commenter Named Bird suggests that DNSSEC combined with DANE is the way forward. In that future, CAs would no longer be part of the critical domain name authenticity chain and might play a different role. However, Named Bird also warns that DNS itself is strained. Where users once requested a single A record (an IPv4 address), they now request A, AAAA, and HTTPS records, records for underscore subdomains, and TXT records used for many technologies, possibly tens or hundreds of records, each carrying its own RRSIG signature and other DNSSEC records. The running joke that 'it's always DNS' highlights a problem that is slowly getting worse, and Named Bird wonders whether DNS needs an update or full redesign for current and future use cases.

For everyday users and website owners, these discussions matter because revocation is a safety net that often fails silently. Short-lived certificates reduce the window of harm, and DNSSEC-signed revocation data could one day make checking both faster and more private. Using a privacy-first encrypted DNS resolver that validates DNSSEC, such as AEU DNS (https://aeu-dns.com), helps ensure the DNS answers you receive are authentic and have not been tampered with, which is a necessary foundation if these DNSSEC-backed certificate ideas take hold.