Check the Certificates, Not Just DNS
Audit certificates after DNS recovery.
Attackers hijacked .gh, .sl and .as third-party registry infrastructure, obtaining unauthorised certificates; Google systems were unaffected.
A registry compromise sits above an individual registrar account. Recovering DNS is essential, but certificate trust needs its own evidence.
Recover two trust planes
Chrome blocked identified certificates; CAs pursued revocation; CT found more. Those certificates need no Chrome-user action; analysis may be incomplete and non-Chrome protection unreliable.
Restore authoritative DNS, then run a separate certificate-response track:
- Reconcile issuance. Compare certificates and precertificates in CT with the approved inventory for every domain.
- Constrain future issuance. CAA lets a domain holder name the certificate authorities authorised to issue for it. CAA cannot block DNS-hijack issuance.
- Narrow automated validation. The accounturi and validationmethods parameters can restrict issuance to a recognised account and listed validation methods, but only when the named CA supports them.
- Revoke and rotate. Ask the issuing authority to revoke unexpected certificates, preserve DNS and CT evidence, and rotate exposed keys or deployment credentials.
Keep the limits explicit
Google omits actor, domain total and exact interval beyond previous-week awareness.
Do not treat browser mitigation as universal recovery. For other namespaces or clients, require the organisation’s own DNS, CT and certificate evidence.
