在域名游戏中没有什么可耻的：DNS 是注定要失败的
DNS 本质上是一个数据库。虽然这一观点可能引发争议，但事实确凿：数据库能够存储字符串、整数（例如 AWS 账户 ID 中的前导零差异）、JSON 对象、坐标，甚至包括圆形、多边形、macaddr8 和 tsquery 等复杂类型。Oracle 数据库甚至可以存储 ROWID。
既然数据库可以存储数据，那么它能否存储计算结果？答案是肯定的。无论是记录“3+2=5”这样的算术结果，还是通过比较运算符处理逻辑判断，数据库都能胜任。基于此，我们可以构建一个功能完备但操作不便的计算器系统，证明数学运算和决策逻辑均可被存储在数据库中。
进一步推演，如果我们将指令序列、内存状态以及执行指针都存入数据库，并通过循环读取指令、查找答案、保存结果的方式运行，这就构成了一台计算机的基本模型。计算机运行程序，而所有计算机都有义务运行的程序是什么？这里指的是经典游戏《毁灭战士》（Doom）。已有开发者为 32 位机器编译了该游戏的算法和内存数据，并将其存储在 DNS 中。
尽管 DNS 的设计初衷并非提供时钟信号或电线连接，但它确实能提供查询响应。因此，理论上可以通过 DNS 协议来运行《毁灭战士》。然而，受限于人类时间尺度，这种尝试效率极低。在初次测试中，一次右键点击操作需要等待 577 秒才能完成。
为了优化性能，开发者采用了本地传输、管道、密集包装寄存器以及指令块优化等技术手段。数据显示，通过 TCP 协议，BIND 服务器每次查询耗时约 7 微秒；通过 UDP 协议则降至 4 微秒。由于一个渲染帧需要处理约 660 万个查询，使用按请求收费的服务器显然不切实际。
当标准 BIND 配置无法满足需求时，开发者发布了代码并联系了 Paul Vixie。作为 RFC 2136 的共同作者，Vixie 建议使用 DNS UPDATE 机制。这一方案虽然令人满意，但在性能提升上仍显不足。
随后，开发者发现 BIND 是基于消息数量而非链深度进行处理的。通过减少注册表提交次数、将查询转移至 UDP、禁止 BIND 填充权威记录答案以及精简每条指令所需的查询数，单次右键操作的延迟从 577 秒大幅降低至 146.3 秒。
尽管如此，性能瓶颈依然存在。即便假设每个指令对应的 DNS 交换能在理想状态下于 10 微秒内完成（这比现实情况好得多），处理 140 万个指令仍需 14 秒。《毁灭战士》的标准刷新率为每秒 35 次点击，即每 28.6 毫秒需完成一次交互。目前的 54,000 毫秒延迟距离可玩性仍有三个数量级的差距。
值得注意的是，每一次状态提交都必须遵循 RFC 2136 UPDATE 协议的严格规定：除非之前的状态完全保持不变，否则无法进行更新。
