当一款诞生于 1993 年的经典游戏能够通过 DNS 协议完整传输并运行，这一技术壮举的背后是對 DNS 协议报文编码约束的精确把握。doom-over-dns 项目将整个 Doom 引擎与 WAD 文件拆解为约 1964 个 DNS TXT 记录，在不触碰磁盘的前提下直接加载到内存中运行，这一过程涉及对 DNS 协议底层限制的深度理解和系统化的分片策略设计。
512 字节限制的协议根源
DNS 协议自 RFC 1035 定义以来，其核心传输层约束一直影响着数据承载的上限。在传统的 UDP 传输模式下，DNS 响应报文被限制在 512 字节以内，这一限制并非刻意设定，而是源于当时网络环境的实际考量 —— 较小 UDP 报文能够降低分片丢失的风险，提高整体传输可靠性。虽然 EDNS (0) 扩展机制允许客户端声明更大的接收能力，且 TCP 传输可以携带任意大小的响应，但在实际部署中，许多中间网络设备、防火墙和递归解析器仍偏好处理小于 512 字节的响应，这一历史惯性使得 512 字节成为设计分片策略时的基准参考。
理解这一限制的关键在于区分两个不同层面的概念：DNS 消息总体的 512 字节上限与 TXT 记录内部字符串的 255 字节上限。前者约束整个响应包的大小，后者则规定单个 TXT 字符串的最大长度。这意味着在设计数据传输方案时，需要同时考虑两个维度的约束条件，任何一个突破都可能导致解析失败或数据截断。
TXT 记录的多层编码结构
TXT 记录的数据结构采用独特的嵌套长度前缀模式。每个 TXT 记录由一个或多个字符串组成，每个字符串以单个字节声明其后续数据的长度，随后跟随对应数量的文本数据。这种设计允许 TXT 记录携带任意二进制内容，因为长度字节的值域覆盖了 0 至 255 的完整范围。然而，当需要传输超过 255 字节的数据时，必须将数据拆分为多个独立的字符串，每个字符串独立携带自己的长度前缀。
这种编码方式的工程意义在于，分片策略需要精确计算每个字符串的实际承载量。以 doom-over-dns 为例，项目采用了精简的编码方案来最大化有效载荷利用率。在实际实现中，每个分片不仅包含游戏数据，还需嵌入必要的元信息用于重组和校验，这些额外开销进一步压缩了纯数据的可用空间。设计者必须仔细权衡数据块大小与元信息开销的比例，在传输效率与可靠性之间找到最优平衡点。
当数据通过 DNS 解析器返回时，客户端接收到的实际上是所有字符串的拼接结果。这意味着发送端可以自由地将长数据分散在多个字符串中，而接收端则获得连续的数据流。这种透明的拼接机制为上层应用提供了简单的数据访问接口，但同时也要求应用层自行处理数据分块和重组的逻辑。
分片策略的核心参数设计
doom-over-dns 的分片实现建立在对多个参数的精细控制之上。系统将 WAD 文件与.NET 引擎 DLL 分别存储为独立的数据条带，每个条带内部再细分为固定大小的数据块。每个数据块对应一个独立的 TXT 记录，通过可预测的命名规则进行组织。这种设计使得客户端可以根据已知的命名模式按需查询特定编号的数据块，而无需维护复杂的元数据索引。
在单条记录层面，分片大小需要考虑 DNS 协议开销、TXT 字符串长度限制以及数据重组的颗粒度。根据项目文档，每个 TXT 字符串的实际可用空间远小于 255 字节的理论上限，因为需要为编号、校验和等元数据预留位置。通过合理的编码方案，系统能够在每个记录中携带约 200 至 220 字节的有效游戏数据，这一数值是经过多次实验验证的工程最优解。
分片数量的计算遵循一个简洁的公式：总数据大小除以单个分片的有效载荷，再向上取整得到所需的记录总数。以 Doom1.WAD 文件为例，该文件约 2.5MB 的有效数据需要超过 1000 个独立的 TXT 记录来承载，再加上引擎 DLL 所需的数百个记录，整体分片数量接近 2000 这一量级。这种大规模分片对解析性能和网络延迟提出了严峻挑战，也是项目选择 Cloudflare 作为 DNS 提供商的重要原因 —— 其全球分布的边缘节点能够提供稳定低延迟的查询响应。
多 zone 架构下的分片调度
Cloudflare 的免费套餐对单个 zone 的 TXT 记录数量设置了 185 个的上限，而付费套餐则将这一限制提升至 3400 个。这一差异直接影响了分片策略的选择：对于免费用户而言，单个域名无法承载完整的游戏数据，必须引入多域名分担机制。doom-over-dns 通过支持多 zone 参数来实现这一点，系统会自动计算每个域名应该承担的记录数量，并将分片均匀分布到所有指定的 zone 中。
多 zone 调度的实现涉及对记录编号的全局管理。系统在上传阶段维护一个记录编号分配器，当第一个 zone 的配额用尽时，自动切换到下一个 zone 继续分配。这种自动化的调度机制对上层应用透明，用户只需在启动时提供一组可用的域名列表即可。值得注意的是，不同 zone 可能指向不同的权威 Nameserver，但在客户端看来，这些分散的记录共同构成了统一的数据存储池。
对于拥有付费账户的用户，单个 Pro 级别以上的 zone 即可容纳全部约 1964 个分片，简化了部署复杂度。这一差异也揭示了云 DNS 服务在企业级应用中的实际价值 —— 不仅是简单的域名解析能力，更是大规模数据分发的可靠基础设施。在选择 DNS 提供商时，除了解析速度和服务可用性，其对 TXT 记录数量和响应大小的政策同样是重要的考量因素。
断线续传与数据完整性保障
大规模分片传输面临的另一核心挑战是可靠性。当传输过程因网络波动或服务端超时而中断时，如何高效地定位断点并恢复传输，而非从头开始，是决定系统实用性的关键。doom-over-dns 实现了基于哈希校验的断线续传机制，这一机制的核心在于为每个数据块计算并存储其内容哈希值。
当上传过程被中断后，系统可以扫描已存在的记录，提取每个块的哈希并与本地数据进行比对。比对成功的记录被认为是已正确上传的，而第一个哈希不匹配的记录则标记为上传失败点。恢复传输时，系统从该失败点继续剩余的数据上传，避免了重复传输已成功存储的内容。
这种设计依赖于 DNS 记录的幂等性特性 —— 相同的记录内容可以反复上传而不会产生副作用。同时，哈希校验确保了即使在网络异常导致部分写入失败的情况下，也能精确识别数据完整性状态。对于大规模数据传输场景，这种增量式的传输策略能够显著降低失败重试的成本，提升整体系统的鲁棒性。
工程落地的关键参数清单
将类似方案应用于实际项目时，以下参数需要重点关注和调优。单条 TXT 记录的有效载荷目标值建议设置在 200 至 220 字节之间，这是综合考虑协议开销和元数据需求后的经验值。记录命名模式应包含足够的信息用于客户端自描述，包括数据类型标识、序号和校验信息，命名格式如doom-wad-001-a3f7能够在不额外查询元数据的情况下传递基本信息。
对于分片调度的并发控制，强烈建议将并发查询数限制在 10 至 20 以内，过高的并发可能导致部分 DNS 解析器触发速率限制反而降低整体吞吐。超时配置方面，单次查询的超时阈值建议设置为 2000 至 3000 毫秒，考虑到 DNS 查询的往返延迟，这是保证成功率与响应速度的平衡点。
在存储侧，如果计划存储超过 1.5MB 的数据，应提前评估 DNS 服务商的记录数量限制和计费策略。doom-over-dns 项目的实践表明，约 2MB 的游戏数据需要近 2000 条 TXT 记录，这一规模已经触及免费套餐的边界，选择合适的 DNS 服务商直接影响项目的可行性。
DNS 协议的 512 字节限制和 TXT 记录的 255 字节字符串约束，源于上世纪八十年代的设计考量，却在当代被创造性地用于构建一种全新的数据传输范式。doom-over-dns 项目展示的不仅是技术上的可能性，更是对协议约束深入理解后进行系统工程设计的方法论。从编码结构到分片策略，从多 zone 调度到断线续传，每一个工程决策都建立在对协议特性的精确把握之上，这正是系统编程之美在网络协议层的具体体现。
资料来源：doom-over-dns 项目 GitHub 仓库（https://github.com/resumex/doom-over-dns）