A ccTLD Hijack Turns Authoritative DNS Into Certificate Evidence

A ccTLD hijack changes what a certificate authority sees when it asks who controls a domain. Google’s October 6 post describes domain hijacks in the .gh, .sl and .as namespaces in which attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations. Google says its own systems were not compromised, and that it has no reason to believe the certificate authorities that issued the certificates did anything wrong.

That last statement is the architectural problem. If the CAs followed their applicable procedures, the incident illustrates a different problem: domain-control validation can return an acceptable result even when the underlying namespace has been compromised. This note covers that mechanism, and the recovery step that is easy to skip once DNS is back.

What Google’s Post States, and What It Does Not

Everything incident-specific in this note is Google’s account of the ccTLD hijack. The post is short, and it leaves most of the usual questions open. Reading it precisely matters more than reading it quickly.

Stated by Google	Not established by Google’s post
The affected namespaces were .gh, .sl and .as	Hijack dates and duration
Attackers modified authoritative DNS records	The domain-validation method behind any certificate
Unauthorized certificates covered several Google domains and domains of other organizations	Issuing CAs and the number of certificates
Certificate Transparency data revealed additional organizations believed affected, and Chrome blocked those certificates	Which organizations were affected
Chrome blocked the certificates through CRLSets and Google worked with the CAs on revocation	Whether any certificate was used against users
Google has no reason to believe the issuing CAs did anything wrong	Whether DNSSEC or registry lock was enabled, absent or defeated

Google also says it cannot guarantee that its analysis identified every affected domain. That limit matters for the monitoring question below.

Certificate Transparency is the detection layer in Google’s account: it is where the additional affected organizations surfaced. By construction it reports issuance after the fact, which is why the second and third checks below exist.

Why a ccTLD Hijack Becomes Certificate Evidence

Three layers are involved, and they fail differently.

The compromised layer is the namespace: authoritative DNS under a country-code TLD. The trust decision is the CA’s domain-control validation, the check that a requester controls the domain it is asking a certificate for. The consequence is a certificate that is technically valid and wrong about who owns the name.

Validation methods differ in what they query, and Google’s post does not say which method applied to any certificate. This note does not assume one. The post does establish the outcome, and Google’s statement about the CAs is what makes the outcome instructive. A CA can run its validation as designed and still reach the wrong answer about ownership when the namespace it validates against is under attacker control. That reading is analysis built on Google’s statement, not a reconstruction of any specific issuance.

DNSSEC is a relevant control at this layer. The Baseline Requirements require CAs to perform DNSSEC validation on the DNS queries used for domain-control validation and on CAA lookups, and RFC 8657 describes the protection as applying to DNSSEC-signed domains. Whether any of that applied to a certificate in the ccTLD hijack is not something Google’s post addresses, and this note does not speculate.

The trust-anchor rollover post is the useful contrast. A trust anchor decides what a validating resolver believes about the DNS tree. Domain-control validation decides what a CA believes about a requester. They have different consumers and different repair paths, and verifying a resolver’s trust anchor does nothing about a certificate that has already been issued.

Restoring DNS Is Not Restoring Issuance Control

Google states that CAA cannot prevent certificate issuance during an active DNS hijack. My reading of why: a CAA policy is a DNS record, and during the hijack the records a CA reads are served by whoever controls the zone. Google’s post states the limitation, not that reason.

For the period after a ccTLD hijack ends and DNS control is restored, Google’s guidance is specific. CAs may cache and reuse completed domain control validation checks for later issuance. Restoring a restrictive CAA policy, especially one that limits issuance to specific authorized accounts and validation methods, is meant to stop an attacker from using cached validation state to mint new certificates once the hijack ends.

That is a defensive rationale. Google’s post documents no case of a CA issuing from cached validation after restoration, and this note does not claim one occurred. It describes the condition the policy is meant to close.

The control also has a precondition. RFC 8657 states that the account and validation-method parameters rely on the CA recognizing them, and are not an effective means of control over issuance unless the CA’s support is established beforehand; a domain must not assume the restrictions are effective without explicit indication from the CA. The current Baseline Requirements (version 2.3.1) do not yet make that processing universal: they require CAs to process both parameters from 2027-03-15. A restored policy that names restrictions an authorized CA does not process is a record, not a gate.

The operational consequence is an invariant: DNS restoration is not certificate-issuance recovery. The sequence below is my recommendation, not a procedure Google documents. Restore authoritative control. Publish the restrictive CAA policy. Confirm from outside your own network that the restored authoritative servers return it. Confirm, from each authorized CA’s own documentation, that it recognizes and processes the account and validation-method restrictions you rely on. Only then close the incident for issuance. Closing at step one leaves the single control Google names for the post-hijack window unestablished.

The ccTLD Hijack Check

Three checks answer it, and each has to produce evidence, not a policy statement.

Check	Evidence that answers it
Can we detect unauthorized issuance across the whole portfolio?	Certificate Transparency monitoring covers every domain you hold, including parked domains and regional ccTLDs, and alerts reach a named owner.
Is issuance constrained before an incident?	A published CAA policy names the authorized CAs, with ACME account and validation-method restrictions only where each authorized CA documents that it recognizes and processes them.
Can we restore DNS without leaving issuance exposed?	A written recovery procedure verifies authoritative control, the effective CAA policy and each authorized CA’s support for the restrictions relied on before the incident is closed.

The inventory behind the first check has to come from registrations, not from the domains people remember. Google’s guidance names parked and regional ccTLD properties explicitly, and an inventory built from memory will miss them.

If you hold a domain in .gh, .sl or .as, Google’s guidance is to review recent Certificate Transparency entries for unexpected issuance. Google is also explicit that Chrome’s blocking is not a substitute for any of the three: it does not reliably protect users of other clients, and Google cannot promise it found every affected domain.

What This Does Not Argue

This note does not claim an attack method for the ccTLD hijack, because Google’s post does not give one. It does not claim the CAs erred, because Google says it has no reason to believe they did. It does not claim that any CA issued from cached validation after DNS was restored, because no such case is documented. It makes no claim about whether DNSSEC or registry lock was enabled, absent or defeated in this incident, because the post does not discuss either. And it is not a tutorial on Certificate Transparency or CAA.

The claim is narrower. Control of authoritative DNS can undermine the evidence used to issue a trusted certificate, and restoring DNS does not by itself show that issuance has been closed to everyone else.

Additional Resources