DNS Recovery Isn’t Enough
Google’s 6 October 2026 notice described hijacks of third-party .gh, .sl and .as registries that enabled unauthorised certificates. Its systems were unaffected.
Chrome blocked identified certificates without user action; certificate authorities pursued revocation. Certificate Transparency (CT) revealed further affected organisations. Analysis could be incomplete and non-Chrome protection unreliable.
Two recovery decisions, two evidence trails
Certificate Transparency logs record certificates and precertificates publicly. Monitor the whole domain portfolio, then compare unfamiliar issuance with the authorised inventory.
CAA names permitted issuers; accounturi and validationmethods can narrow accounts and validation routes where a CA explicitly supports them. These controls concern issuance, not revocation, and cannot protect a policy during an active DNS hijack.
Timing matters when evaluating a mismatch. RFC 8659 explains that a certificate can have complied with an earlier policy even if it conflicts with today’s records. Preserve the policy history before describing an unfamiliar certificate as unauthorised.
For the recovery record, give each unresolved entry a named owner, an evidence reference and a decision deadline. Separate a confirmed finding from a hypothesis and from an action someone merely requested. This is a proposed record-keeping method, not a claim that any particular organisation has completed its response.
Close the loop, not just the ticket
For example, suppose a team believes it has completed a recovery task, but its case file contains only the instruction to do it. Ask for the dated confirmation and retain any exception. The next reviewer should be able to follow the decision without relying on the previous operator’s memory.
For unexpected certificates, seek revocation from the issuer and preserve the DNS and CT evidence. Rotate keys or deployment credentials if they were exposed, rather than assuming every suspicious issuance proves key theft. Keep the outstanding response separate from a successful DNS restoration.
Before tightening automated issuance, confirm the provider’s documented support and arrange a controlled renewal check. RFC 8657 warns that misconfigured restrictions can reject legitimate requests. A written policy is not a useful recovery outcome if the authorised service can no longer renew.
Google did not identify an actor, complete domain count or exact attack interval beyond previous-week awareness.
Sources: Google’s 6 October notice; Chromium’s emergency certificate-blocking documentation; Certificate Transparency’s explanation above; and the linked CAA standards, RFC 8659 and RFC 8657.
Updated 15 October 2026: expanded recovery acceptance guidance and clarified policy-history and renewal limits.
