When DNS Trust Breaks: What the Counterfeit Google Certificates Reveal

According to Google’s disclosure on October 6, 2026, attackers who had compromised three country-code TLD (ccTLD) registries obtained at least 12 publicly trusted TLS certificates for Google and YouTube domains under .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). Google did not disclose how the registries were compromised. 

The attackers modified authoritative DNS records for selected domains under the hijacked ccTLDs, which let them satisfy the domain-validation process used during the certificate issuance.

CT logs show the certificates appearing across the affected TLDs over several days: .gh on September 22, .sl on September 25, and .as on September 27. Let's Encrypt issued 11 certificates and ZeroSSL issued one. All 12 had been revoked by October 1. 

Google blocked them in Chrome using CRLSets and worked with the issuing Certification Authorities (CAs) on revocation, but other browsers and clients depend on that CA revocation to stay protected. CT logs also showed unauthorized certificates for domains belonging to other global brands and online services, and Google notified the affected organizations.

Google said its own infrastructure was not compromised, and there was no indication that the certificate authorities themselves had been breached. The attackers targeted something upstream of both: DNS. Once they controlled the authoritative DNS path for the affected domains, they could temporarily demonstrate control of those names. The certificate ecosystem then behaved largely as designed. 

Google was able to respond within days because it saw the certificates, had direct relationships with the issuing CAs, and could block them in its own browser. Most organizations have none of those advantages, so they need to watch for the signals themselves, including:

• Nameserver (NS) delegation: Any unexpected change on a domain you own, especially the high-value ones

• Authoritative DNS records: Changes you did not make, including records that could be used to pass a validation challenge

• CT logs: A new certificate for any of your domains, including parked and regional ccTLD names, from an issuer you do not normally use (In this incident, that meant Let's Encrypt and ZeroSSL certificates on domains where Google's legitimate certificates came from Google Trust Services.)

• CAA records: The policy being served right now, not the one shown in your configuration dashboard

Without watching for those signals, the first sign of a problem may be a notification from someone else, as it was for the other brands that Google contacted.

The same exposure exists wherever a domain depends on a registry you have never evaluated. Regional sites, acquired brands, campaign domains, and vanity domains often sit under dozens of registries with very different security practices. You may have excellent control over your primary .com while having almost no visibility into the infrastructure behind a country domain registered years ago.

As enterprises move toward agentic AI architectures, autonomous agents increasingly call APIs and retrieve context dynamically across distributed domains. An agent cannot intuitively detect an imposter host if the underlying DNS path and TLS certificate validate successfully. When DNS trust breaks, it doesn't just put web users at risk — it also undermines the integrity of every autonomous machine-to-machine workflow operating across your ecosystem.

Domain-validated TLS certificates rely on a fundamental assumption: An entity capable of demonstrating control over a domain is authorized to request a certificate for it.

CAs can verify that control through mechanisms such as DNS-based challenges or HTTP-based validation.

Normally, that model works well. But if an attacker gains control of the infrastructure responsible for answering those validation requests, the trust assumption can break down. For example, an attacker who can manipulate authoritative DNS may be able to satisfy a DNS-based validation challenge. Depending on the affected infrastructure and validation method, DNS manipulation can also influence where HTTP validation traffic is directed. 

Attackers don't necessarily need access to the organization's cloud environment, identity provider, web server, or certificate management platform. They need the validation system to see what they want it to see. Once a publicly trusted certificate is issued, the attackers potentially have another component necessary to impersonate legitimate services while the underlying DNS compromise remains effective.

Security teams frequently think about certificates and DNS as separate operational disciplines. From an attacker's perspective, they are one trust chain.

Most organizations invest heavily in what they directly control: 

• Cloud accounts

• Applications

• Identity systems

• Endpoints

• Certificate management systems

• Authoritative DNS configuration

But domains also depend on infrastructure outside the organization's direct control.

The chain may look something like:

Registry → Registrar → DNS provider → Authoritative DNS → Certificate validation → TLS certificate → Application

Compromise any critical point in that chain and the assumptions downstream change.

That is especially important for organizations that are operating large global domain portfolios.

This situation is made worse by the set-and-forget nature of DNS. A record is created for a launch, another during a cloud migration, a regional team registers a country domain, and an acquisition brings hundreds more. Years later, ownership has changed, applications have moved, and nobody has a complete picture. Your DNS attack surface is not just the platform you actively manage — it is the entire dependency chain around your domains.

Watch for two signals: 

1. Changes to NS delegation on high-value domains

2. Certificates from unexpected issuers

In this incident, legitimate certificates for google.com.gh, google.sl, and google.as came from Google Trust Services, while the unauthorized ones came from Let's Encrypt and ZeroSSL. Google itself recommends ongoing CT monitoring across all of an organization's domains, including parked and regional ccTLD properties. CT monitoring is most useful when events are correlated with your domain inventory and approved certificate policy, so you can quickly answer “Is this one legitimate?” 

The broader lesson is that DNS security cannot be reduced to protecting a DNS server. It depends on understanding the relationships between domains, registries, registrars, authoritative infrastructure, and certificates. 

Here’s how Akamai DNS Posture Management can help you address those five critical questions:

• Know what you own: See every domain and its DNS dependencies across providers in one inventory, including the regional and inherited domains nobody remembers registering

• Close the CAA gaps: Find missing or overly permissive CAA policies and confirm the policy being served externally matches what you intended

• Catch the changes fast: Get alerted when delegation or DNS drifts from a known-good baseline, and when a certificate appears from an issuer you have not approved, alongside rogue, misconfigured, or expired certificates.

• Recover with confidence: Identify affected domains and certificates quickly, preserve change history, and verify that DNS and certificate policy have returned to their expected state

• Reduce exposure upfront: Review DNSSEC deployment, registrar support, and registry protections, such as registry lock, and flag stale or dangling records

In this incident, an alert for google.com.gh would have flagged a certificate from a CA that the domain had never used (every earlier certificate came from Google Trust Services), along with any change to the domain's delegation or DNS records. That is the difference between hearing about it from a browser vendor and spotting it the day it happened.

This ties DNS security to a principle security teams already know: Posture is not a configuration you establish once; it is a state you continuously verify.

Organizations can secure their applications, cloud environments, identities, and certificate infrastructure and still inherit risk from upstream infrastructure.

You may not be able to prevent a national registry from being compromised. But you can understand which critical assets depend on it, restrict certificate issuance where appropriate, monitor DNS and CT for unexpected activity, and build a recovery process that looks beyond simply restoring the DNS record.

When certificate issuance depends on proving control of a domain, DNS isn't just directing traffic — DNS is part of the trust model.

Contact your Akamai representative today to schedule a demo and see how DNS Posture Management can strengthen your overall security posture.