The infrastructure you depend on but don't own

The infrastructure you depend on but don't own
Photo of Kaveh Azarhoosh

Kaveh Azarhoosh

Community & Research Lead

SharePostLinkedInEmail

Graph figures verified against WhisperGraph on 13 August 2026; the incident timeline is verified against Cloudflare's published post-mortem. Every hostname cited below is a live query result, re-runnable in a single query.

The infrastructure you depend on but don't own

On the night of 5 May 2026, every .de lookup through a validating resolver started returning SERVFAIL at once. Deutsche Bahn, Spiegel, and the inbound mail of DENIC, the registry that runs Germany's .de top-level domain, were unreachable for roughly three hours. The cause was small and ordinary: a scheduled DNSSEC key rollover at DENIC began producing DNS responses with non-validatable signatures at around 19:30 UTC. Cloudflare's 1.1.1.1 resolver saw the SERVFAIL spike from that moment, and it climbed over the next three hours as cached records expired. By 22:17 UTC Cloudflare had treated .de as insecure for 1.1.1.1, applying the Negative Trust Anchor approach defined in RFC 7646, and leaned on serve-stale (RFC 8767) to cushion users. DENIC distributed a corrected zone and fully restored normal operation by about 23:15 UTC.

One key rollover at one TLD made millions of German domains unreachable, for every user behind a validating resolver, for three hours.

The dependency you didn't negotiate

The internet feels like a set of contracts you signed: this hosting provider, that registrar, this CDN, that certificate authority. Underneath those contracts sits a chain of trust that runs through other people's keys, schedules, and maintenance windows. The DENIC failure sat at the TLD signing layer, which means every name whose resolution passes through .de inherited it instantly, regardless of registrar, hosting choice, or whether the domain itself was DNSSEC-signed. A company can run a perfect internal security programme, with hardware keys, signed zones, and redundant resolvers, and still be unreachable for three hours because someone else's scheduled maintenance broke a layer above it.

This generalises beyond DENIC. Every operator on the public internet sits inside a dependency graph they did not design, made up of TLD operators, root key signers, resolver populations, CDN edges, certificate authorities, transit providers, and BGP upstreams. Most of these dependencies are invisible until they fail, and a handful of them, the ones near the top of the tree, fail in ways that take everything underneath with them. Vendor questionnaires do not see this layer, contracts do not bind it, and procurement diligence does not surface it.

Visibility is the only operational response

If you cannot harden DENIC, you can at least know what breaks when DENIC has a bad night. That means knowing, before the next incident, which of your inbound mail flows route through .de MX records and will quietly queue against bounces while the zone is broken, and, less obviously, which of the domains you depend on aren't .de names at all but still resolve through .de. The same question applies to every other TLD, certificate authority, and anycast provider you implicitly depend on.

This is unglamorous work, but it is the only work that turns an outage on someone else's infrastructure into a known, scoped, communicable risk on yours. The DENIC incident lasted three hours, and most operators spent those three hours guessing.

Mapping what's actually there

Whisper holds the public internet as a 46-billion-point graph covering DNS, BGP, WHOIS, GeoIP, hosting relationships, certificate transparency, and threat-intel provenance, all queryable in a single query. The DENIC incident is exactly the kind of question the graph was built for, not "which .de domains broke," because that set is obvious from the name, but "which domains that aren't .de inherited the failure anyway." That second question is the one no questionnaire answers, and it is a single query here.

It returns names you would not guess. Whisper holds over 13.6 million .de domains, but the more revealing figure is one layer across. Of the forty companies in the DAX, Germany's blue-chip index, thirty-seven use a primary corporate domain that is not a .de name. Twelve of those thirty-seven delegate their DNS, wholly or partly, to nameservers that live under .de, among them Volkswagen, SAP, Deutsche Bank, Mercedes-Benz, Allianz, Deutsche Börse, BMW, RWE, Rheinmetall, and Deutsche Telekom. Two of them depend on .de completely: every authoritative nameserver for volkswagen-group.com sits under volkswagen.de, and every one for rheinmetall.com sits under xc-ns.de. During the DENIC window, a user behind a validating resolver could not reach either global .com, for the same three hours, without a single .de name ever appearing in the address they typed. Porsche's holding company, porsche-se.com, routes all of its inbound mail through porsche.de, so its mail queued against the same failure. None of these dependencies is visible from the company's name; all of them are one query away in DNS records that have been public all along.

That is the shape of the blast radius: not just the .de zone, but everything delegated into it. The dependencies are not hidden by anyone, they are published in DNS delegation, MX records, BGP tables, and certificate logs. The problem was never access; it was assembly, holding all of it as one graph so that "what else fails when .de fails" is a query and not a research project. Whisper gives you that graph directly from your own tools, whether that is your SIEM, your scripts, or your AI agents. There is a free API key if you want to try it.

SharePostLinkedInEmail

Gain the Whisper Advantage Today

Empower your security team with the infrastructure context they need to investigate threats faster.