Can It Resolve Doom? Game Engine in 2k DNS Records

A developer has successfully stored and executed the DOOM game engine entirely within DNS TXT records, demonstrating how the aging protocol can be repurposed as a serverless file system.
If you’ve ever poked at one of my CTF challenges, you’ve probably noticed a pattern - I love hiding payloads in TXT DNS records. I stash the malicious code in a TXT record, have the implant query for it at runtime, and now suddenly the payload is being delivered by the same infrastructure that resolves grandmas-cookie-recipes.com. It’s trivially easy to set up and surprisingly annoying to catch forensically, because who’s flagging the historic contents of TXT records?
I’ve always suspected the technique could go further than staging shellcode. TXT records are just arbitrary text fields with no validation. If you can store a payload, you can store a file. If you can store a file, you can store a program. And if you can store a program… well, it can probably run DOOM.
WTF is DNS
For the blissfully uninitiated, DNS is the system that turns domain names into IP addresses. You type google.com and DNS tells your browser where to go. It’s one of the oldest protocols on the internet and it is deeply, profoundly boring.
But DNS also supports TXT records, these little text fields originally intended for things like email authentication. The key word there is “intended.” Nobody actually validates what you put in them. You can write whatever you want - a love letter, a recipe, or in this case base64-encoded binary data.
Each TXT record can hold about 2,000 characters of text. A single DNS zone can support thousands of records. Public DNS is also globally distributed, cached at edge nodes all over the world, and publicly queryable by anyone with an internet connection. It is (if you squint hard enough) a free, worldwide, serverless key-value store.
Naturally, I wanted to store my movie collection in it.
Duck.jpg
The proof of concept was shockingly easy. Take a file, Base64-encode it, split it into chunks, and upload each chunk as a TXT record. Add a metadata record so the reassembly script knows how to put it back together, and that’s it.
I tested it with a picture of a duck and it worked perfectly. The duck went up, the duck came back down with identical hashes. DNS is now a file server.
But a JPEG of a duck is boring, and a 1GB MP4 would need roughly 670,000 TXT records spread across hundreds of domains. This was not going to scale to my aspirations of Shrek. I needed something smaller, something compressed, and something that would actually demonstrate how absurd this is.
Can It Run DOOM?
The universal benchmark for “can this thing do something it was never designed to do?” is, always has been, and always will be DOOM. Thermostats run DOOM, pregnancy tests run DOOM, and I want DNS to run DOOM.
The idea is to fetch the entire game engine and its assets from DNS TXT records, load everything into memory, and run it. No downloads, no installers, and no files written to disk. My goal is to load the game into memory entirely through public DNS queries.
While researching this, I knew I needed to use a DOOM port written in a language that could be reflected into memory in Windows. I knew C# is used frequently by threat actors for this, but I don’t know C# and wasn’t about to rewrite the DOOM source myself, so that’s where I started looking. I found managed-doom, a pure C# port of the original DOOM engine. Managed .NET assemblies can be loaded from raw bytes in memory, so no files need to exist on the filesystem.
Implementation Details
managed-doom needed some patching before it could run from memory. It expected to read game data from disk using file paths, so that had to be changed to accept a memory stream instead. Its windowing library was also a native DLL, which must exist as a file on disk for Windows to load it, so that had to be ripped out entirely and replaced with direct Win32 API calls.
I worked on a majority of this piece with Claude. The result is a set of pure managed .NET assemblies that can run DOOM from a MemoryStream with zero native dependencies. I also decided to completely cut the audio to save on the amount of DNS records needed.
Creating the Records
With compression, DOOM fits comfortably in a single CloudFlare Pro DNS zone. The WAD file drops from 4MB to 1.7MB, the DLL bundle goes from 4.4MB to 1.2MB. In total, it required about 1,966 TXT records on a single DNS zone. The upload took about 15 minutes using the CloudFlare API.
The player script is about 250 lines of standalone PowerShell. It resolves all ~2,000 DNS queries in 10 to 20 seconds, reassembles everything in memory, loads the assemblies via reflection, and launches the game with nothing written to disk.
DOOM Over DNS
And it works. DOOM is stored, launched, and running from DNS records. No files are written disk as part of the player script, nothing is installed, and no additional dependencies are required. All it took was about 2,000 TXT records and a 250-line PowerShell script that knows how to put them back together with Resolve-DNSName and some vibes.
DNS is almost 45 years old and it was designed to map hostnames to IP addresses. It is not a file storage system. Yet here we are. The most boring protocol on the internet is also, quietly, one of the most abusable.
Source: Hacker News














