Tuesday, October 13, 2026
What is DNS? That's right, it's a database. You can disagree with me but you would be wrong. What can you put in a database? Strings, ints (and you learn the difference right quick if your AWS account ID has a leading zero!), JSON objects, coordinates; some of the databases out there have some pretty esoteric types. PostgreSQL supports circle, a polygon, a macaddr8, and a tsquery. Oracle will store a ROWID and your dignity. In a word, databases store data. Can you put answers in a database? Well sure; you could record that "3 + 2 is equal to 5" and store that answer. You can do the same with comparison operators; "3 is larger than 2" and so on. Take it a step further and you've built something with your database: a remarkably inconvenient calculator. So now we've established that you can store arithmetic and decisions in a database. And what can we do with those things? That's right, we can follow instructions! Good job! And what does following instructions require? Generally, memory; a place to store your numbers, your instructions, and which instruction comes next. If only we had a place to store those things. Oh right, we do; we have a database! Now connect those lookups together. Read an instruction, look up an answer, save the result, repeat as needed. So what have we built? That's right: a computer! And what can a computer run? Programs! My, you're quite good at this. And now, gentle reader: what program do we apparently have a moral obligation to run on every computer? Oh yes, though many of you are going to sit back and instead say "oh no" as the horror courses through you. I am talking about Doom. This very publication agrees with me! What have I done? That's right; I have compiled Doom for a 32-bit machine whose arithmetic and memory live in DNS. A small program supplies the wiring and the clock, neither of which the architects of DNS saw fit to include. But DNS does supply the answers. So, can we play Doom? Only if it's turn-based. It won't render on human timescales anyway. In my first attempt, I pressed Right, and then waited for 577 seconds to find out what happened. By using native transport, pipelining, packing registers densely, and optimizing instruction blocks, I was able to drop that to 146 seconds, before I hit a wall. BIND answers in about 7 µs per query over TCP and 4 µs over UDP, which is fast. The problem is that a 32-bit add is four DNS lookups, a branch is five, and a frame needs 6.6 million of them, so don't use a server that charges per request. And what do we do when BIND isn't performing the way we want it to? I don't know what you do, but I publish my code, then reach out to Paul Vixie, DNS pioneer and architect of BIND 8 to unjustifiably complain. Paul then apparently congratulates me on "the best use of RFC 2136 DNS UPDATE" that he'd ever seen. Given that he's a co-author of that RFC, I suspect he's seen a lot! Which was gratifying, but unhelpful. So let's take another crack at it. What if I do lookaheads? Good thought, bad outcome, because BIND is bound by message count, not chain depth. Well okay, I have some more tricks in my Big Bag of Stupid Ideas. So I went a bit further and via committing registers to DNS less often, moving lookups to UDP, telling BIND to stop padding answers with authority records, and requiring fewer lookups per instruction, I was ultimately able to get that press-right time down from 577 seconds to 146.3 seconds to 54.4 seconds, for a 10.6x improvement. And now I think I have hit a wall. Even at one DNS exchange per instruction (which is far better than anything realistically achievable), 1.4 million instructions at roughly 10 µs each is 14 seconds per tick. Doom says its tic rate is 35 per second, so "playable" is a tic every 28.6 ms. I remain at 54,000 ms, which is three orders of magnitude away from victory. Okay seriously, WHAT? This legitimately works. Every commit is an RFC 2136 UPDATE with a hard requirement: it fails unless the previous state is still exactly what was last written. Apparently "real" database people call that optimistic concurrency, or compare-and-swap. Joke's on you, friends; DNS has shipped with that since 1997; has your inferior database? The database itself is 6.4 million rows of truth tables. ff.01.0.add holds "001": 255 plus 1 is 00 carry 1. DNS is just acting as a librarian here, fetching memorized answers to any arithmetic question in-scope and returning the answer upon request. It's also verifiable! The frame that's spat out is checked on every pixel against an independent emulator. If one record is corrupted in the AND table, the answer changes, which proves there's no local fallback doing arithmetic for us. I've included tooling so that reviewers can run two commands against that repo and verify correctness. I also confess I cheated slightly here; the run I'm pulling these numbers from started from a checkpoint prepared by a normal emulator. It turns out that for SOME UNKNOWN REASON getting a cold boot through Doom's startup screens via DNS would take hours. Also, before the timer starts, DNS has to load those 6.4 million records, so it's a computer that takes roughly a minute to boot before it can even start. We can't cheat This runs atop nothing special: Debian's stock BIND 9.20, configured through named.conf. It lives in a container with networking disabled. I want to be very clear here: this isn't DNS pretending to be a CPU. The instruction decoding is done ahead of time by a compiler; BIND never executes an instruction itself. All that it sees is a key-value read, a conditional write, and 6.4 million rows of precomputed answers. So instead, think of this monstrosity as a database with a key-value read, a conditional write, and 6.4 million rows of precomputed answers. It's not really a computer; it's simply a very good database. And that turns out to be enough. ®
source https://www.theregister.com/columnists/2026/10/12/no-shame-in-the-domain-name-game-dns-is-doomed-literally/5302670
source https://www.theregister.com/columnists/2026/10/12/no-shame-in-the-domain-name-game-dns-is-doomed-literally/5302670
