Security

DNS Security Alert: Hijacked ccTLDs Minted Google Certs

Published October 8, 2026 · DNS Benchmark Pro Editorial · Reading time: 7 minutes

The most consequential DNS security incident of the week did not involve a software bug, a patch or a CVE. It involved three small registry operators, a handful of changed DNS records, and the uncomfortable fact that the entire public web certificate system takes DNS at its word. Google’s Chrome Secure Web and Networking Team published its account on Tuesday 6 October, after learning of the hijacks the previous week. The attackers are unnamed, the method of compromise undisclosed, and Google has not said whether the certificates were used to intercept live traffic.

What happened inside .gh, .sl and .as

Three ccTLD registries were taken over at the operator level. With control of the zone, the attackers pointed the relevant names wherever they wanted and then requested certificates from automated CAs. Domain-validated issuance works by asking the applicant to prove control of the name — typically by publishing a specific DNS record or serving a specific file at a hostname that DNS resolves. An attacker holding the authoritative zone satisfies that test honestly, from the CA’s point of view. Nothing was forged and no validation rule was broken.

Certificate Transparency logs give the timeline. The first unauthorized certificates for .gh names appeared on 22 September, .sl names on 25 September and .as names on 27 September. Three were revoked on 26 September and the remaining nine on 1 October. Records going back to at least 10 September show every other certificate for these names was issued by Google Trust Services, which is exactly the kind of anomaly CT exists to surface.

Why a registry compromise beats every control below it

The usual advice does not apply cleanly here.

DNSSEC does not help. A validating resolver proves that an answer came from the zone’s legitimate signing authority. When the registry operator itself is the compromised party, the attacker inherits that authority. The signatures validate; they simply attest to records the attacker chose. DNSSEC defends the path between resolver and zone, not the zone’s own integrity.

CAA does not help during the hijack. A Certification Authority Authorization record restricts which CAs may issue for a name — but CAA is itself a DNS record, read from the same zone the attacker now controls. Google is explicit that CAA cannot stop issuance while a hijack is live. What it does do is matter enormously afterwards, which is the point most write-ups miss.

Registrar-level locks do not help either, because the compromise was above the registrar. Registry lock protects a delegation from unauthorised change requests; it does not protect a zone whose operator has been taken over.

The DNS security lesson: trust flows downward from the registry

Everything a modern organisation treats as an identity control — the padlock, SSO redirects, API client pinning, email authentication — resolves, eventually, to a DNS lookup. The web public key infrastructure is, functionally, a DNS application with a revocation layer bolted on. That is tolerable when the zone operators are large, well-resourced and audited. It is less comfortable when a browser-trusted certificate for a global brand can be produced by compromising a registry serving a few hundred thousand names.

The practical exposure is wider than the seven domains listed. Google said CT data revealed other affected organisations, including well-known global brands and widely used online services, which it blocked in Chrome and contacted where it could. It also warned that its analysis may not have found every affected domain, and that Chrome-side blocking does not protect users of other browsers. Browser blocklists are a backstop, not a boundary.

The validation-reuse clock is the real fix

The structural remedy already in motion is shorter memory. CAs are permitted to reuse a completed domain check for subsequent certificates; under the CA/Browser Forum Baseline Requirements that reuse window is currently up to 200 days. A schedule approved in April 2025 cuts it to 100 days in March 2027 and 10 days in March 2029. Let’s Encrypt currently reuses validations for 30 days and has said it intends to reach seven hours by 2028.

That matters because a transient hijack has a long tail. An attacker who holds a zone for 48 hours can bank a validation that remains spendable for months after control returns to the rightful owner. Shrinking the reuse window converts a persistent capability into a brief one. Google frames this alongside shorter certificate lifetimes and its Chrome Root Program work as the long-term answer to transient routing and DNS compromises — which is the correct diagnosis: you cannot make every registry on earth unbreachable, so you shorten how long a breach pays.

What domain owners should do this week

1. Monitor Certificate Transparency across the whole portfolio. Not just the primary domain — the parked defensive registrations and regional ccTLD variants too. Those are precisely the names nobody watches, and in this incident they were the names that were abused.
2. Audit recent CT entries for any .gh, .sl or .as name you own. If issuance appeared from a CA you do not use, treat it as confirmed and file a Certificate Problem Report; under the Baseline Requirements the CA must report initial findings within 24 hours.
3. Publish strict CAA records with ACME account binding. Naming your permitted CAs is the baseline; binding issuance to a specific ACME account and validation method (RFC 8657) is what actually blocks an attacker from spending a cached validation after the hijack ends. As of 7 October all seven affected names carried a CAA record naming only Google Trust Services.
4. Check what your zones currently say. Most organisations have never looked at their own CAA, DS or NS records in production. Our DNS lookup tool queries CAA, DNSSEC and delegation records directly — a five-minute way to confirm your policy exists outside a ticket.
5. Treat registry concentration as a risk register item. Know which names sit in namespaces run by small or outsourced operators, and decide deliberately whether a brand-critical service belongs there.

There is also a measurement angle. Hijacks of this kind change which answers resolvers hand back, and the first symptom is often inconsistency rather than failure — one resolver returns something different from another, or a record changes shape without a corresponding change on your side. Running our free DNS benchmark and network diagnostic tool gives you a per-resolver view instead of a single vantage point. If you are weighing encrypted transport for your clients, our guide to DNS over HTTPS and DNS over TLS explains what those protocols protect — the query path — and, just as importantly, what they do not: the integrity of the zone data itself.

Industry impact: the quiet parts of the namespace

Set this beside the kind of story that usually fills this column — an edge appliance with a zero-day vulnerability, a cloud tenant boundary that leaked, a DDoS attack that knocked a provider offline. Those are failures of server infrastructure you own and can patch. This one is different in kind. Nothing Google ran was vulnerable. Nothing Let’s Encrypt did was wrong. The failure was in a part of the namespace that almost nobody in a corporate security programme has ever thought about, and it produced browser-trusted certificates for one of the most heavily defended brands on the internet.

That asymmetry is the lesson worth carrying into next quarter’s planning. Cloud security reviews enumerate accounts, regions and identity providers. Very few enumerate registries. Yet the registry is the root of every name-based control beneath it, and a meaningful share of the world’s ccTLDs are run by small technical teams, universities or outsourced operators with budgets that bear no relationship to the value of the brands registered in them.

Chrome users, for their part, are covered: Google states plainly that “Chrome users do not need to take any action to be protected”. Everyone operating a domain portfolio has rather more to do. Turn on CT monitoring, publish CAA with account binding, and write down which registries you depend on. Good DNS security is not only about which resolver you point at — it is about knowing who can rewrite your zone, and who would tell you if they did.

Sources

• Google — Chrome’s response to recent ccTLD registry hijacks
• The Hacker News — Attackers hijack .gh, .sl and .as registries to obtain certificates for Google domains
• Help Net Security — Hackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains
• Cyber Security News — Hackers hijack .gh, .sl and .as registry to obtain unauthorized HTTPS certificates

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Google campus photograph is by Austin McKinley, via Wikimedia Commons, licensed CC BY 3.0; the Google logo is a public-domain reproduction of an official corporate mark, via Wikimedia Commons; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated. DNS Benchmark Pro is not affiliated with Google LLC, Let’s Encrypt or ZeroSSL.