A new attack technique called Underminr was disclosed this week. It slips past protective DNS by abusing shared CDN edge IPs. The DNS query looks clean. The connection lands on malware.
This post walks through what Underminr is, why protective DNS misses it, what actually stops it, and the OTHER DNS layer most teams forget to watch.
What just happened
Researchers at ADAMnetworks disclosed a technique they call Underminr. It targets a weak spot in protective DNS, also called PDNS.
Here is the trick. An attacker hosts a malicious site on a major CDN. The CDN serves thousands of legitimate sites from the same set of edge IP addresses. The attacker tells a victim's machine to look up a trusted domain, like whatismyipaddress.com. The lookup returns a real, clean IP that PDNS has no reason to block. Then the encrypted connection to that IP requests a different host header on the same edge. The CDN routes the traffic to the attacker's payload.
The DNS log shows the trusted domain. The packet goes somewhere else.
The researchers documented four modes.
Simple mode does the swap inside a normal HTTPS request. Split mode breaks the malicious traffic across more than one trusted-looking lookup. ECH mode uses Encrypted Client Hello to hide the real SNI from any inspection in the path. Direct-to-IP mode skips DNS at the moment of attack and just hits the CDN edge by raw address.
All four end the same way. The defender sees a benign-looking DNS query. The endpoint reaches malicious content. PDNS, which is doing exactly what it is supposed to do, has no signal to block.
This is not a flaw in any single PDNS vendor. It is a property of how filters at the resolver layer work, combined with how shared CDNs route traffic.
Why protective DNS missed it
Protective DNS works at the resolver level.
When a user's machine asks "what is the IP for this hostname," PDNS sees the name being requested. It compares that name against a list of known bad domains and a set of reputation rules. If the name is bad, the lookup is blocked. If the name is fine, the lookup returns an IP and the connection proceeds.
That model assumes the hostname tells you where the traffic is going. For most of the web, it does. For shared CDN infrastructure, it does not.
A single CDN edge IP can serve thousands of unrelated domains. The CDN decides which site to return based on the host header inside the encrypted connection, not the DNS query. So an attacker who can put a malicious payload on a shared edge gets a free pass at the resolver layer. The lookup is for a clean domain. The traffic goes to the attacker's payload. PDNS has no visibility into the host header inside TLS.
ECH makes this worse. With Encrypted Client Hello turned on, even the SNI is hidden from anything in the network path. There is no plaintext signal anywhere. The DNS query is the only thing PDNS sees, and it points at a clean name.
This does not mean PDNS is broken. PDNS still blocks the long tail of cheap, lazy, domain-based threats every day. But Underminr proves that the resolver layer, on its own, cannot see every kind of attack.
What actually stops Underminr
Honest answer first. There is no single product that closes Underminr cleanly.
What works is layered, and every layer has tradeoffs.
TLS inspection, also called SSL decryption, is the most direct fix. If your egress proxy decrypts traffic and inspects the host header, you can see when a connection to a CDN edge is asking for a different site than the DNS query suggested. The catch is that TLS inspection is hard to deploy. You have to manage trusted certificates on every endpoint, you break apps that pin certificates, and you take on real privacy and compliance load. ECH defeats TLS inspection in any place the client can talk directly to a public DNS resolver, because the SNI is no longer in the clear.
Endpoint detection and response, or EDR, helps when the malicious payload actually runs. A strong EDR with behavioral analysis can flag the process that opened the connection, the files it dropped, the network calls it made after landing. EDR does not stop the initial fetch. It catches what the payload tries to do next. That is still useful, but it means the attack already reached the endpoint.
Application-aware proxies and secure web gateways with full content inspection can catch some Underminr variants by looking at host headers and request patterns. These are usually deployed alongside TLS inspection, so they share the same deployment burden.
Network segmentation reduces blast radius. If a workstation that hits Underminr cannot reach internal systems, the attack stops at that workstation. Segmentation does not stop the initial compromise. It contains it.
Even with all of these layered together, ECH and Direct-to-IP modes can still get through in narrow conditions. There is no silver bullet. The honest takeaway is that Underminr is the kind of attack that requires defense in depth, with PDNS as one layer of many, and a real plan for what each layer can and cannot see.
The OTHER DNS blind spot most teams don't watch
Now the pivot.
PDNS sits at the resolver and watches outbound DNS queries from your users. That is one DNS layer.
There is a second DNS layer. The records you publish to the world. The A, AAAA, CNAME, MX, TXT, NS, and SOA records that tell every other system on the internet where to reach your services. Almost no team watches that layer with the same care.
This is where attackers do quiet, expensive damage.
Dangling CNAMEs are the classic case. A team spins up a marketing site on a cloud provider. They add a CNAME from a subdomain to the cloud host. Two years later, the cloud account is closed. The CNAME still points at the now-free hostname. An attacker registers that hostname and serves whatever they want from your subdomain. This is called subdomain takeover. It happens to large companies several times a year.
NS record hijacking is rarer but worse. If an attacker compromises a registrar account or a DNS provider, they can change the name servers for your domain and become the authoritative source for everything. Email, web, API. All of it.
Quiet MX record changes are a favorite for business email compromise. An attacker who gets even brief access to your DNS console can swap the MX, intercept inbound mail for a few hours, harvest a password reset, and put the original MX back. The change shows up in your DNS history. If nobody is watching the history, nobody sees it.
SPF, DKIM, and DMARC are TXT records. They tell other mail servers which senders are allowed to send mail for your domain. When those records drift, when a vendor is removed and the SPF includes are not cleaned up, when a DKIM key rotates and the old one is left in place, your domain becomes easier to spoof. The drift is silent. The phishing that follows is not.
DNSSEC adds cryptographic signatures to your records. When DNSSEC is misconfigured, resolvers that validate signatures will refuse to return your records. Your site goes dark for a slice of the internet. This often happens when a key rotation is missed or a registrar update is dropped.
A-record drift after migrations is the most common quiet failure. A team moves a service to a new host. They forget to update one of the related records. The old A record points at an IP that has been recycled. Months later, that IP belongs to someone else. Your subdomain now leaks traffic to a server you do not control.
None of this shows up in a PDNS log. PDNS is on the user side of DNS. These are problems on the publisher side.
Where DNS Spy fits
DNS Spy watches the DNS records you own.
Think of it this way. PDNS watches outbound DNS queries at the resolver level. DNS Spy watches inbound DNS records at the zone level. They are the two halves of a real DNS posture. You need both.
DNS Spy does not stop Underminr. Nothing about Underminr touches the records you publish, so this is not a layer where DNS Spy plays. The point of this post is that Underminr is a reminder. If your PDNS can have a blind spot, your record monitoring almost certainly does too. Most teams have nothing watching their zone at all.
Here is what DNS Spy actually catches.
Record changes across every type. A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA. If anything in your zone moves, you get alerted with the before and after value, the timestamp, and the source.
DNSSEC validation. DNS Spy checks that your DNSSEC chain is intact and signed correctly. When a key rotation goes wrong, you find out before your users do.
Dangling CNAMEs. DNS Spy follows your CNAMEs and flags any that point at unclaimed or expired hosts. This is the single highest-value subdomain takeover signal you can monitor.
Propagation issues. DNS Spy queries multiple resolvers around the world and tells you when your records do not match. Misaligned records mean some users see one answer and others see another. That is almost always a misconfiguration.
Missing or weak SPF, DKIM, and DMARC. DNS Spy parses your email auth records and tells you what is missing, what is too permissive, and what is silently failing.
Set up takes a few minutes. You point DNS Spy at your domain, it pulls every record, and the monitor runs from there.
The defense-in-depth takeaway
Underminr is the latest reminder that a single layer of DNS defense is never enough.
Protective DNS is doing its job. It blocks the long tail of cheap, domain-based threats, and it is the right tool to deploy against the noisy attacks that hit every business every day. Underminr is a sharper, narrower threat that requires sharper, narrower controls. TLS inspection, EDR, application-aware proxies, network segmentation. Every one of those has a deployment cost and a real limit. There is no single product that closes Underminr cleanly.
The other half of the picture is the records you publish. Your zone is part of your attack surface. When a record changes without your team knowing, that is either a bug, a mistake, or an attack. You will not catch any of those if nothing is watching.
PDNS plus zone monitoring is not the full story of network security. It is the DNS portion of it. Get both layers covered and you have closed the most common DNS gaps that attackers actually use.
Two simple next steps.
Try DNS Spy free. Add your domain, see what is in your zone, see what is drifting.
See how DNS Spy monitors your records. Walk through every alert type and what it catches.
Underminr will not be the last DNS story that hits the news this year. Make sure both DNS layers are covered before the next one lands.
