Your CAA Record Did Nothing During the Hijack. Here's When It Starts Working
Domain validation worked exactly as designed, so the fix is to control what happens after you recover the zone and to catch the next hijack faster.
Why the usual defense failed, and why it still matters
The registry operator serves the whole zone, CAA records included. During a live hijack the attacker publishes whatever CAA they want. CAA only starts to matter after the zone comes back. CAs re-check CAA at every issuance, even when reusing an earlier domain validation. Those validations stay reusable for months. The validation the attacker banked during the hijack is the residual risk.
One detail in the CT count changes the advice. Almost every rogue certificate came from Let's Encrypt, the CA many victims already use. A plain issue "letsencrypt.org" record would have blocked nothing. Only RFC 8657 parameters stop a banked validation. accounturi pins issuance to one specific ACME account. validationmethods limits which challenge types are allowed.
| Control | During the hijack | After you recover the zone | Gotcha |
|---|---|---|---|
| CAA, issuer only | No effect | No effect; the attacker used the same CA | False comfort in this incident |
| CAA + accounturi + validationmethods | No effect | Blocks reuse of the attacker's validation | Any issuer you forgot to list starts failing renewals |
| DNSSEC / registry lock | No effect against a compromised registry | Limited | Stops registrar-level hijacks, not registry-level ones |
| CT monitoring | Detects rogue certs | Catches late issuance | Worthless unless the alert pages someone |
Revocation protected Chrome, not your services
Google says Chrome users need do nothing. That is accurate for Chrome and only Chrome. CRLSets are a Chrome mechanism. Go's crypto/tls does not check revocation. Java ships with revocation checking off. OpenSSL-based stacks, curl, Python, Ruby and Node among them, skip the check unless someone configures it. Those clients accept a revoked but unexpired certificate until its notAfter date.
The remaining exposure is narrow but real. After DNS is restored, using a rogue certificate requires a separate network position. The dangerous window is during the hijack, when attacker-controlled DNS and a valid certificate line up. In that window, webhook targets, OAuth and SAML endpoints, and service calls without mTLS can all be impersonated. The only control that works in that window is how fast you detect it.
Where the reporting agrees and where it adds detail
Both analyses call CAA defense in depth, not a fix. Both rank CT alerting first. SANS's Johannes Ullrich adds that ccTLD hijacks happen more often than gTLD hijacks, and that ccTLDs 'do not always obey modern rules.' The two analyses warn about opposite self-inflicted outages. Matt Johansen recommends binding a second CA account in CAA, so one lost ACME key does not halt all issuance. SANS warns that accounturi is unforgiving. Skip the inventory of every issuer, including CDN-managed certs, cloud load balancers and cert-manager in every cluster, and an auto-renewal fails weeks later. Our inference: .io, .ai, .co, .me, .sh and .gg are all ccTLDs, each run under its own operator arrangement.
The move
Inventory every issuer first. Then publish account-bound CAA. The order matters, and the SANS warning is the reason. Monitor what the parent zone serves for the domain, meaning the NS and DS records, from several vantage points, and page on any change. Over time, move hostnames that carry authentication to a gTLD with mature registry operations. Keep the ccTLD as a vanity domain that redirects.
What to do
Inventory every certificate issuer across CDNs, load balancers and cert-manager clusters, then publish RFC 8657 CAA records (accounturi plus validationmethods, with a second CA account bound as a fallback) on every production apex this sprint
Route Certificate Transparency alerts for your names to on-call, and stand up a multi-vantage NS/DS drift monitor on the parent zone this week
Plan the migration of login, OAuth callback and API hostnames off ccTLDs onto a gTLD this quarter