DOOM Over DNS: The DNS Covert File System Threat Explained

DOOM Over DNS: Why Your Network's Most Trusted Protocol Is Now a Covert File System

Everyone's seen the headlines and the memes: "You can play DOOM over DNS!" It's a classic internet flex, a testament to technical ingenuity, and frankly, it's a great way to get people talking about an old protocol. But if you're a network defender, the real story behind DOOM Over DNS isn't about playing a game. It's about how a fundamental network service, designed for simple name resolution, can be repurposed into a globally distributed, memory-only DNS covert file system for payload delivery. And that should worry you.

The mainstream narrative focuses on the sheer novelty of storing and executing a game like DOOM using DNS infrastructure. It's true, the project by resumex and blog.rice.is shows exactly how to encode game binaries into thousands of DNS TXT records and then load them into memory via a PowerShell script, all without writing a single file to disk. But the technical community, especially on platforms like Hacker News, has been quick to clarify: DNS isn't running DOOM. It's acting as a highly effective, covert storage and delivery mechanism. That distinction is critical for understanding the actual security implications of a DNS covert file system.

The Incident: Abusing DNS as a Global Key-Value Store

The "incident" here isn't a breach, but a proof-of-concept (PoC) that demonstrates a significant attack vector. In late 2025, the project "DOOM Over DNS" by resumex (documented on GitHub and blog.rice.is) showed how to host the entire DOOM game engine and its assets within DNS TXT records. The goal was clear: fetch everything from DNS, load it into memory, and execute it without touching the disk or installing anything.

This wasn't about a vulnerability in DNS itself. It was about creatively abusing its design. DNS TXT records, originally for email authentication, are just arbitrary text fields. They're globally distributed, cached at edge nodes, and publicly queryable. Essentially, they're a free, worldwide, serverless key-value store. The project simply took advantage of that, effectively creating a DNS covert file system.

How DNS Becomes a **DNS Covert File System**

Here's the chain of events that makes this work, and why it's so effective for covert operations:

1. Data Preparation: The DOOM shareware WAD file (around 4MB) and the necessary .NET game engine DLLs (around 4.4MB) are compressed. This shrinks them down to about 1.7MB and 1.2MB respectively. This initial step is crucial for optimizing the data to be stored efficiently within the constraints of a DNS covert file system.
2. Encoding and Chunking: These compressed binaries are then Base64-encoded. After that, they're split into thousands of smaller chunks, each fitting within the approximately 2,000-character limit of a DNS TXT record. The entire DOOM project needs about 1,966 TXT records.
3. DNS Hosting: These TXT records are uploaded to a Cloudflare DNS zone. Cloudflare's global network means these records are distributed and cached at edge nodes, making them highly available and resilient. This global distribution is what makes DNS such an attractive platform for a DNS covert file system, offering resilience and reach. The upload process itself takes about 15 minutes via the Cloudflare API.
4. The Loader: A PowerShell script, Start-DoomOverDNS.ps1, is the client-side magic. This script, around 250 lines long, does the heavy lifting:
   • It initiates thousands of Resolve-DNSName queries to fetch all the TXT records.
   • As the responses come back, it reassembles the Base64-encoded chunks in memory.
   • It then decodes the Base64 data back into the original compressed binaries. The loader script effectively reconstructs the entire payload from the DNS covert file system directly into memory.
   • Finally, it loads the .NET assemblies directly into memory using reflection and launches the game.

The critical part here is that the WAD file and the DLLs are never written to disk. The entire operation happens in memory. This is the fundamental design choice that makes this technique so potent for attackers, turning DNS into a powerful DNS covert file system.

The Real Impact: Malware Staging and Forensic Evasion

The practical impact of DOOM Over DNS has nothing to do with gaming. It's about a highly effective method for:

• Covert Payload Delivery: An attacker can use this exact mechanism to deliver malware, ransomware, or other malicious executables. Instead of a WAD file, it's a malicious binary. The target system simply queries DNS, reassembles the payload in memory, and executes it. This bypasses traditional file-based detection on disk, leveraging the DNS covert file system.
• Command and Control (C2) Infrastructure: While the volume of data for DOOM is large, the same principle could be adapted for smaller C2 communications. Exfiltrating small chunks of data or receiving commands via DNS TXT records is a known technique, but this PoC shows the scale at which a DNS covert file system can operate.
• Forensic Evasion: The "no files written to disk" aspect is a nightmare for incident responders. If a system is compromised this way, traditional forensic analysis looking for malicious files on the filesystem will come up empty. You're left hunting for transient memory artifacts and network traffic, a direct consequence of the DNS covert file system approach.
• Bypassing Network Controls: Many firewalls and intrusion prevention systems are configured to allow DNS traffic (port 53) with minimal inspection, assuming it's just for name resolution. They might not be looking for thousands of large TXT records being queried by a single host, or for the specific content within those records.

Who's affected? Any organization with internet-facing DNS resolvers and endpoints capable of executing PowerShell (which is most Windows environments). The technique is platform-agnostic in terms of the DNS hosting, but the loader script would need to be adapted for different operating systems.

What We Need to Change: Deep DNS Inspection and Behavioral Analytics

This isn't a theoretical threat; it's a demonstrated capability. So, what do we do?

1. Deep Packet Inspection for DNS: Your firewalls and IDS/IPS need to go beyond simply allowing port 53. They need to inspect DNS query types, response sizes, and the volume of queries, specifically looking for patterns indicative of a DNS covert file system. Look for:
   • Unusual TXT record sizes (especially large ones).
   • Anomalous query volumes from single hosts to specific domains.
   • Queries for non-existent or newly registered domains that suddenly host thousands of records.
   • Repeated queries for the same domain or subdomains in rapid succession.
   • DNS tunneling detection capabilities.
2. Enhanced Endpoint Detection and Response (EDR): EDR solutions are essential here. They need to monitor PowerShell execution for:
   • Scripts that make an unusually high number of Resolve-DNSName calls.
   • PowerShell processes that load .NET assemblies via reflection, especially from memory streams.
   • Unusual parent-child process relationships (e.g., a browser spawning PowerShell that then loads code).
   • Memory forensics capabilities to detect and dump suspicious in-memory artifacts.
3. DNS Sinkholing and Threat Intelligence: Integrate threat intelligence feeds into your DNS resolvers and security tools. If a domain is identified as hosting malicious payloads via DNS, it should be sinkholed or blocked immediately.
4. Behavioral Analytics: Baseline normal DNS traffic patterns in your environment. Any significant deviation – a sudden spike in TXT record queries, a host querying thousands of unique subdomains – should trigger an alert. This is where the "trade-off" comes in: you gain security by inspecting more, but you trade off some network simplicity and potentially add latency. For critical assets, that's a non-negotiable trade when dealing with a potential DNS covert file system.
5. Network Segmentation and Egress Filtering: Limit which internal hosts can make external DNS queries, and to which DNS servers. While this won't stop a determined attacker, it can contain the blast radius and make detection easier.

The DOOM Over DNS project is a brilliant piece of engineering, but it's also a stark reminder that attackers will always find new ways to abuse existing infrastructure. Your DNS isn't just for resolving google.com; it's a potential delivery mechanism for the next generation of fileless malware via a DNS covert file system. It's time to treat it that way.