The Seventh Unprecedented DNS Thing Before Breakfast
Preface
At DomainTools we pride ourselves on the strength of our data, but we’ve also sought to move beyond being just a data provider. And almost two years in, our threat intelligence team, DomainTools Investigations, continues to push through the noise to provide timely, relevant, and actionable intel to practitioners.
But at the end of the day, defense itself comes back to visibility. What can we see, and what can it inform? We stay rooted in technical observables and common practitioner lexicons because no matter how many observations we intake, no matter how many new feeds we add or attacks we see, it always comes back to one thing: a practitioner at their desk seeing something in their area of operation and trying to make sense of it.
So what happens when words fail us? What happens when we see something so unique that we’re momentarily out of our comfort zone — as well as so deep in analysis we’re also out of coffee?
At the end of February 2026, our team encountered one of those moments, and we’d like to share what we can now.
It all starts with DNS. That’s even one of our marketing phrases, right? But there’s a universal internet truth behind it. DNS is a systemic vulnerability for attackers - if their attack involves the internet, it must touch DNS in some way. Our passive DNS sensor network has spent more than a decade observing and recording what we’re able to see, located above recursive servers specifically to avoid collecting any user data. Quite a few of us are privacy advocates ourselves. What we want are the DNS records, what's published and actively used in the DNS, because that’s what tells us about the health and safety of the internet at large.
Due to our visibility on the global internet, DomainTools regularly discovers events and signals better served by quiet distribution than publishing widely. This post covers one such event, something we’ve been quietly and responsibly disclosing since March. Recent discussions with disclosure partners resulted in everyone agreeing that talking about this event more widely is now viable. We thank both those disclosure partners and our colleagues in the information security community that assisted with validating these observations from other vantage points. Cooperation in the public interest continues to be a deeply-held belief at DomainTools as well as a founding principle of DomainTools Investigations, as it’s one of the most impactful ways to fight badness and increase safety.
DNS Tunneling
DNS TXT records can carry arbitrary text strings. Normal use cases involve associating that arbitrary data directly with a domain, such as proving domain ownership to a third-party service, providing email authentication to battle spam, and more.
That ability to store arbitrary text also opens TXT records up to abuse of various kinds, and the ubiquity of DNS in networked environments makes it a popular choice for moving data in and out of target environments an attacker does not fully control. Early malicious use involved plaintext Linux or Windows Powershell terminal commands stored in TXT and retrieved into environments for further exploitation. This evolved into encoding of those in base64, hexadecimal, or other schemes. You can even store entire malware binaries in TXT for smuggling onto a system, and then programmatically rebuild the executable and run it.
The pipes run both ways, of course: you can also send data out of the environment using DNS. While the record byte limit makes it an inefficient means, exfiltration by this method continues to be popular for threat actors due to enterprises failing to secure or properly monitor their DNS versus their perimeter firewall. Since both directions are viable, utilizing DNS as a C2 or Command & Control mechanism becomes another favored option, as seen with actors like OilRig or malware like TrickBot.
Smuggling commands and a little data back and forth, such as beaconing activity, is one thing. But now that we know bidirectionality is possible, can someone operate an entire Virtual Private Network (VPN) over DNS?
The answer is a resounding yes.
In fact, utilizing DNS query and response to create a VPN tunnel for back-and-forth work is so viable that multiple VPN providers offer VPN-over-DNS solutions due to its utility in otherwise difficult scenarios. Many open-source and off-the-shelf software packages allow users to set up their own VPN this way as well.
With that background in mind, we progress to our mystery event.
The Flood
The DomainTools passive DNS network processes, deduplicates, and validates roughly one million observations per second. It’s a deeply fun and complex problem to have on a scale few are familiar with. We are used to a certain amount of variability there depending on multiple factors, such as legitimate real-world events causing traffic spikes, DNS-related DDoS attacks, massive beaconing from global malware events such as SUNBURST/SolarWinds, and more.
On March 1, 2026, DomainTools engineering personnel were alerted to congestion in our intake servers and responded quickly to assess the problem. The distinguished engineer involved in the response quickly diagnosed the problem: a flood of newly observed DNS records creating a massive backlog in processing. Looking closer, the engineer noted the flood originated with a single domain, and that one domain now accounted for up to 500,000 observations per second on our network.
At the end of 2025, DNIB estimated around 400 million actively-registered domain names. So this engineer was staring down a single domain that now increased our per-second observations by about half.
This domain was supaghost[.]cc.
Analysis quickly centered around DNS TXT records for supaghost, as they comprised most of the flood. The structure of the payload immediately suggested VPN-over-DNS activity. That type of activity often utilizes either TXT records or algorithmically-generated subdomain records (or both) in order to transport data across boundaries that may seek to block or inspect it otherwise.
One example can be seen here:
RDATA: "\000\024\173\138\148)R\000@\000\003M\000\000\018\001\000\000\019\001\000\000\000\000\000\000\000\026\173\138\148)Q\000@\000\135n\254\001u\000\000\000\019\001\000\000\002\000\000\000\000>\000V\173\138\148)Q\000@\000\135n\254\001v\000\000\000\019\001\000\000>\000\000\000\013\019\229\023W\226\132\220\1435\014\010z\017\197\024\000E\185\211\178\016@X\026\169\219\254\210\007\133T\199\174\188\232\"p#\177i\000|0,\222w\145\247\025\\k\229\208\167\250dEc\200a\""
RRNAME: 55xozch7rxqvhy3pk2lgzlmksquvcacaaabu2aaacmaqaadqaaaaaaqaaaaaaif.nrkkcsuiaiaaagtiaaakacaaaoaaaaabaaaaabndknz2ztkq7cqvm6wzurbvykt.4sacz364e7b5baleppzuha7sptvwfjikkrabaaaa2naaabkaiaabyaaaaaaiaaa.aaala.slsa1.supaghost[.]cc
Observed: 2026-03-01 13:17:59 UTC
What we see in the RDATA - the payload actually stored in the TXT record - is likely multiple packets encoded in binary and multiplexed into the TXT record for efficiency. They are then delivered to the specific resolver(s) being used for VPN-over-DNS, decoded, and pushed out through an exit node to their destination.
At this point I want to stress that we did not attempt to decode the data in any way, and you’ll see why down below.
DNS is a query/response or “question & answer” protocol. In the case of obfuscated VPN-over-DNS traffic, connecting the query and response in certain ways can suggest system mechanics. Observed in supaghost[.]cc records specifically was a pattern indicative of bidirectional traffic whereby traffic got partitioned by a third label and delegated to a nameserver host under the apex domain, which often resolved to a separate (cheap) Virtual Private Server protected by Cloudflare. See the relationship between RRNAME and RDATA:
{"count":326234,"time_first":"2025-11-16 04:49:15","time_last":"2026-03-03 09:28:34","rrname":"slsa1.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa1.supaghost.cc."]}
{"count":387277,"time_first":"2025-11-15 16:59:24","time_last":"2026-03-02 22:36:57","rrname":"slsa2.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa2.supaghost.cc."]}
{"count":357039,"time_first":"2025-11-17 10:40:43","time_last":"2026-03-02 22:34:06","rrname":"slsa3.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa3.supaghost.cc."]}
{"count":386855,"time_first":"2025-11-16 16:35:55","time_last":"2026-03-02 22:36:57","rrname":"slsa4.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa4.supaghost.cc."]}
{"count":420002,"time_first":"2025-11-17 16:57:37","time_last":"2026-03-02 22:34:36","rrname":"slsa5.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa5.supaghost.cc."]}
{"count":359352,"time_first":"2025-11-18 04:44:06","time_last":"2026-03-02 22:36:48","rrname":"slsa6.supaghost.cc.","rrtype":"NS","bailiwick":"supaghost.cc.","rdata":["sa6.supaghost.cc."]}
The flood originated around roughly 0700 UTC 2026-03-01 and had wildly escalated by 1200 UTC. Within a few days, supaghost[.]cc had racked up 40 billion observations before we began filtering it.
Our engineer looked at the volume, looked at the details, looked at the newspaper, and immediately reached out to me in Investigations.
Why?
The Background
Like everything else in the human experience, technology development and use never occurs in a vacuum.
Bits, binary, firmware, and hardware are all developed in a living context where multiple systems come together to create something. Some of those systems are purely technical, but many exert influence outside that; the geopolitical, the cultural, even just human perception. These all contribute to technology in different ways. Just as something like cyberpunk fiction reflects the time it was written in more than it is predictive or prescient, software and hardware can mirror the same.
Almost exactly twenty four hours prior to the DNS record flood escalation, the US and Israel initiated a bombing campaign targeting the Iranian regime. That bombing intensified rather than slowing like previous campaigns. This information did not provide any kind of evidentiary support in itself, but suggested a possible theory that could be explored. To our surprise, multiple indicators (mostly external to us) strongly suggested that the traffic involved had originated near or from Iran.
The supaghost behavior quickly took a surprising turn: it spread. What began with one domain soon spread to more than one hundred, with the Iranian .ir top-level domain grossly over-represented in the cluster. None of the second-phase domains reached 500,000 observations per second on their own, but several got close. Pattern-matching confirmed that most of the domains exhibited similar DNS query trends isolated to these few days, dormant since their registration between September and November 2025.
Activity also diversified further. Several high-throughput transport domains were not part of the base cluster, but were already-operating DNS tunneling services located in either Eurasia or South Asia.
Theories and Unanswered Questions
Despite our visibility, questions remain. Some of them we’ve purposely left unanswered.
My pre-security background is in IT support, and so that colors the lenses through which I interpret events. The clarity of coordination here and the planning months ahead, spinning up nearly technically identical off-the-shelf VPN technology, then scrambling to increase throughput and resiliency made sense to me in a “chaos engineering” kind of way. While the campaign began with a single voluminous pipe, it quickly spread to dozens as the kinetic pressure increased within Iran due to intensified bombing. Activity also intensified on several already-established DNS tunneling services located in different, but close, countries.
For a moment, let’s humor some very thin speculation: To me, this largely looked like a very voluminous emergency offsite backup. And given the volume, it did not look like opposition or civilian activity. The technical indicators pointed circumstantially to Iranian regime activity. Due to the complexity of simulations, nuclear program data in particular can be highly, highly storage-intense. So we made a strategic decision to attempt no decryption, because Iranian nuclear program data is the last thing I want in my possession, even sandboxed. But to reiterate, this is and must remain speculation.
As conclusions go, and as much as I support following hunches, we cannot rely on them or pretend confidence in them. We must stick to the technical indicators instead.
As a crew with dozens of years of expertise in DNS and domains, we observed a DNS flood beginning in March that our most distinguished DNS engineer described as “unprecedented, even in our ‘six unprecedented things before breakfast’ world.” The volume from a single domain accounted for a 50% increase in our intake, and then distributed and diversified. DNS record data appeared very consistent with VPN-over-DNS activity, and some technical indicators directly supported an origin in Iran and regional data transit to an ally.
We’re publishing now in the hopes that others with eyes on the same or similar activity will also speak up and share. No one team, company, or organization can see everything, and in the threat environment we face now, it’s more important than ever to talk and share more with each other.
.png)
