Google Search outage today: Why Germany's DNS registry was actually at fault

Google Search was not down on May 5. What actually happened was narrower and stranger: a cryptographic error at Germany's domain registry made bahn.de, spiegel.de, and dozens of other .de websites unreachable for users on Google DNS, Cloudflare, and Quad9. The fault was at DENIC, the authority that manages the .de top-level domain. Google DNS users saw a "Google Search outage" because Google DNS was the service telling their browsers the site didn't exist but Google DNS was doing exactly what it's supposed to do.

The affected sites ran without interruption throughout. The servers were up. The addresses just couldn't be verified by any resolver strict enough to check, per a post-incident analysis by Blackfort Technology.

What DENIC broke and why DNSSEC-validating resolvers refused to continue

DNS works like an address book for the internet: type a web address, your device asks a resolver to translate it into a numeric IP address, and you connect. DNSSEC adds a verification layer on top, using cryptographic signatures to confirm that an address entry is genuine and hasn't been tampered with in transit. If the signature fails, a strict resolver blocks the query rather than risk passing along a compromised result.

On May 5, DENIC published a malformed signature for a specific DNS record covering part of the .de namespace. The signature wasn't missing it was present, with an expiry window running to May 19 but it didn't pass the authenticity check. That distinction matters: there was no gap in the data. The data was wrong in a way that looked intact, Blackfort Technology reported.

The affected record was an NSEC3 entry, a specific component of the DNSSEC chain of trust. Any resolver enforcing that chain would continue blocking queries until DENIC re-signed the record correctly. Because the faulty signature's expiry window ran to May 19, it would not time out on its own. A deliberate re-signing action from DENIC was the only route to a complete fix.

Neither the operators of the affected websites nor the DNS service providers made any error, Blackfort Technology concluded. The malformed signatures came directly from DENIC's own infrastructure.

One caveat: that fault attribution, and the NSEC3 technical detail, come from a single post-incident analysis. DENIC had not published an official statement in the reporting reviewed for this article, and no independent technical corroboration was available at time of writing. The Blackfort analysis is detailed and internally coherent; it is not yet a settled account.

Who was affected and why most users saw nothing unusual

The users who hit walls were almost exclusively those running Google Public DNS, Cloudflare, or Quad9 as their resolver. That's what made this feel like a Google problem. When Google DNS is the service translating web addresses into connections, and it's returning an error, Google looks broken from where the user sits even when it's enforcing a security rule correctly.

Google DNS, Cloudflare, and Quad9 refused to return addresses for affected .de domains because the DNSSEC signature attached to those entries failed the authenticity check, Blackfort Technology reported. That's deliberate, protective behavior: the point is to prevent users from being directed to spoofed or hijacked sites. Resolvers that skip strict DNSSEC validation returned results as normal. Same broken signature, different enforcement, completely different experience.

The practical result: two people in the same building could try to reach bahn.de and get different outcomes depending entirely on which resolver their device was using, Blackfort Technology noted. The DNSSEC-validating setup returned DNS_PROBE_FINISHED_NXDOMAIN or "This site can't be reached." The ISP resolver loaded the page without issue.

Most customers of Deutsche Telekom, Vodafone, and O2 were largely unaffected because their resolvers don't enforce strict DNSSEC validation, Blackfort Technology reported. The outage was nearly invisible at population level while being genuinely baffling for those it hit.

If .de websites failed on your laptop but worked on your phone's mobile data, or loaded on one device but not another, a different DNS resolver is the most likely explanation. The distinguishing factor wasn't your connection speed or your ISP. It was whether your device happened to be pointing at a resolver that checks DNSSEC signatures.

How recovery unfolded and what "resolved" actually meant

By approximately 22:15 CEST on May 5, Google DNS, Cloudflare, and Quad9 were responding correctly to queries for affected .de addresses, Blackfort Technology reported. For most users, that's the end of the story. But access returned through two distinct paths, and they're worth separating.

The first was cache. Many resolvers had stored valid responses from before the bad signature was published, so once those cached entries were served out, users could reach affected sites again even while the malformed signature remained on DENIC's servers as of that evening, per Blackfort Technology.

The second was an actual fix. DENIC performed a targeted re-signing of the affected NSEC3 record using a new key. An earlier signing pass at 20:33 UTC had updated only some of the affected records; the later action constituted the full resolution, Blackfort Technology reported.

A user whose resolver hadn't yet refreshed its cache, and who was on a DNSSEC-validating resolver, could in principle have remained locked out until the underlying record was definitively corrected. For most, that window had closed by the time the incident was declared resolved.

What the official record still doesn't show

DENIC had not issued a public statement in the reporting reviewed for this article. Whether a formal post-incident account follows and whether it confirms, expands, or complicates the technical picture currently available will determine how completely this incident can be understood.

Until then, the Blackfort analysis is the most detailed account on record, and it supports a specific conclusion: a registry-level DNSSEC error, a selective outage among DNSSEC-validating resolvers, and a recovery that came in stages. The resolvers that blocked access did so correctly. The failure was one layer of infrastructure deeper than most users ever think about.