按用途退役 DNS ANY

摘要

2026 年 8 月的一份个人 Internet-Draft 建议 DNS 服务器通常以 NOTIMP 拒绝 QTYPE ANY，只有存在具体本地理由时才保留旧解释或最小应答。它尚不是 RFC，也不是 IETF 已形成共识的政策。
退役计划应逐项迁移调用目的：明确谁在查、想据此决定什么，以显式 RRtype 查询或受控本地诊断替代，并让例外到期。可选 EDE 能解释拒绝原因，却不能证明应用已经完成迁移。

很多基础设施债务不是从错误开始，而是从方便开始。一名运维人员用一次查询快速看一眼记录，把命令写进故障排查手册；后来有人把它变成脚本，脚本进入监控，监控结果又影响切换或验收。等服务器准备取消这个便利行为时，组织面对的已经不是一条命令，而是一连串无人明确签署过的决策依赖。

DNS ANY 正好具有这种条件。名字里的 ANY 容易让人联想到“全部记录”，但 QTYPE 255 并未提供一份稳定、完整、适用于任意服务器的清单。权威服务器知道自己的区域，递归解析器知道它已取得的材料，缓存只反映某个时刻的存量。在区域切割与委派边界上，哪些数据算应答对象本就不直观。调用者收到什么，既取决于名字，也取决于回答者的位置、实现和当前状态。

2026 年 8 月 6 日发布的 draft-jabley-dnsop-no-longer-support-any-00，提出进一步减少这种不确定义务。草案建议服务器通常返回 RCODE 4，即 NOTIMP；若有特定本地理由，则可以继续采用 RFC 1034、RFC 1035 的历史解释，或者 RFC 8482 允许的最小应答方式。草案还提出一种 Extended DNS Error，用来说明这台名称服务器不支持 ANY 查询。

这里必须先画清制度边界：它是仍在有效期内的个人 Internet-Draft。Datatracker 没有把它列入某条 RFC 流程，状态只是草案存在；正文页头写出的 Standards Track 意向，不等于 DNSOP 已采纳，更不等于 IETF 已批准。运营者可以现在评估其中的理由，但不能把作者希望抵达的标准状态当成已发生的集体决定。

安全理由成立，迁移责任仍然存在

ANY 的大型应答曾对反射放大攻击很有吸引力。RFC 5358 讨论了开放递归服务器怎样被滥用；RFC 8482 则解释了最小化 ANY 应答的动机与做法。服务器组装更多数据会消耗处理器和内存，传输更多字节会占用容量；消息变大还可能遇到 UDP 分片，或转向 TCP 后产生另一种资源成本。

因此，把含义不稳定、可能成本较高的公共行为改为明确拒绝，是值得认真考虑的方向。但它不是完整的 DNS 抗放大方案。其他查询同样可能得到较大的应答，递归服务暴露面、权威服务容量、限速与源地址验证等问题仍须分别处理。停止 ANY 只能被记作一个具体边界的改变，不能被写成“DNS 放大风险已消除”。

同样，安全理由不能把合法用途从迁移表中擦掉。有人用 ANY 做初步诊断，有遗留程序依赖某种应答形状，也有内部工具试图了解缓存。承认这些用途，不意味着任意公网客户端都应继续获得宽泛答复；它只意味着运营者不能把服务器侧部署成功，冒充客户端侧需求已经解决。

收到 NOTIMP 的脚本可能直接失败，也可能重试另一台服务器，或继续拿旧缓存作判断。后一种情况尤其危险：系统暂时没有报警，恰恰是因为新行为尚未触及真正的工作周期。一次委派变化、缓存过期或灾备切换，才会让隐藏的依赖醒来。眼下安静并不是完成迁移的证据。

先问用途，再选替代查询

如果工具检查邮件路由，它需要的是 MX 及其逻辑所需的后续解析，不是一次不确定的“全部”。如果检查委派，它应明确处理 NS、区域边界以及必要的地址查询。如果一个发现协议需要若干资源记录类型，应按该协议查询这些 RRtype，而不是寄希望于 ANY 恰好返回有用组合。如果要查看递归缓存，受授权的本地诊断接口才有机会说明范围和新鲜度；远程 ANY 应答从来不是可靠的缓存盘点。

由此可见，替代工作不能简单地把一条 ANY 变成十条不同类型的查询。那可能只是把服务器的模糊义务，改成客户端的无差别搜集，增加成本却没有改善判断。合理目标是：用足够而不过量的数据，恢复原本被授权的决策能力，并把这项能力的语义写清楚。

在改变默认行为前，运营团队应建立一个用途登记表。观察窗口可以有明确起止日期，并限制字段、保留时间和访问权限；不必永久记录每个查询名。接收服务、来源类别、已知内部工作负载、周期、传输方式、应答大小和归属线索，通常比无期限保存全文更接近迁移目标。数据收集的目的，是把反复出现的调用变成有限待办，不是借退役之名扩大监控。

登记表应为每一组调用回答：谁能修改它？结果被哪项决策消费？今天遇到缺项或最小应答时会怎样？是否把缓存中的可见记录误当成权威全集？多久才真正执行一次？这些问题有时会揭示，旧客户端并非失去一项可靠保证，而是终于不得不面对原本已有的脆弱假设。

不能归属的调用应明确标成“未知”。它可能来自扫描器，也可能来自未登记合作方，或者一套早被人忘记的系统。未知不自动获得永久兼容权，但也不能在报告里被悄悄当成无风险。应由有权接受残余风险的人决定如何处理，而不是由一张部署仪表盘默认替组织作出结论。

每项用途只应进入一个有终点的处置

第一种处置是替代：记录明确 RRtype 或专用接口、客户端版本、部署人群和结果测试。第二种是取消：确认没有现行决策需要这个调用，删掉它，再覆盖相关工作周期观察回归。第三种是收窄：有价值的运维诊断迁至经认证、网络范围可控的本地表面，不把局部需要推广成公网义务。

第四种是临时例外。无法修改的二进制程序，或者必须等待供应商版本的系统，可以有有限缓冲，但应写明责任人、适用来源、名字范围、补偿控制、到期日期和关停条件。如果维护已不可能，问题应进入资产替换计划；无限延长“临时兼容”，只是给永久政策换了一个不诚实的名称。

第五种是待归属风险。它应有调查动作或明确风险接受，而不是模糊地留在兼容清单里。登记表的作用，是把不确定性变成可决策的状态，并不要求运营者永远等待所有公网陌生客户端。

有了这些状态，部署就能按人群推进。已升级的受管客户端先接受新默认；小范围遗留群体保留带期限的例外；公共权威服务与内部排障工具可以采用不同策略。共享软件不意味着共享全部风险，更不意味着一个内部方便就应迫使所有公共实例继续提供旧行为。差异须有本地理由、边界和责任。

EDE 解释边界，不能替登记表盖章

RCODE 4 有一个重要优点：它把拒绝放在 DNS 应答层表达出来，而不是生成一份容易被客户端过度解读的数据集合。运营者可以计数，定位集中来源，并与改动前的观察比较。可是这个代码故意很粗；它不知道调用者的业务目的，也不知道对方是否已拥有替代办法。

递归解析器、转发器和其他实际路径组件，还会影响客户端最终看到什么。某些客户端会更换目标或传输方式，另一些只把故障转成笼统消息。拒绝率能反映服务器策略，不能独立证明应用迁移。

RFC 8914 定义 EDE 的方式，也没有改变这个边界。EDE 增补解释，不改写 RCODE 的处理规则；一次应答中可以存在多个 EDE。中间实现怎样转发或改写取决于实现，附加文本是可选的人类解释，不是机器稳定字段；消息需要缩短时，这类文本也可能被优先丢弃。

因此，新草案提出的“不支持 ANY”说明，最多能帮助排障人员更快认出一次有意政策，而非随机故障。客户端不应通过解析一段英文解释来选择新的记录类型，运营者也不应因为说明成功穿过转发链，就把迁移状态改成完成。证明应来自客户端版本、实际查询和功能结果，而非解释文本的送达。

这一区分并不贬低 EDE。可解释的拒绝有助于缩短故障定位时间，降低跨团队扯皮；只是不该把它的诊断价值抬高为业务等价性。一个信号可以把边界讲清楚，却无权替边界外的系统承担结果保证。

测完整判断，而不只是测 RCODE

发送 ANY 并观察 NOTIMP，只完成了服务器测试。迁移验收应重演被旧应答支持的决定。邮件诊断是否仍正确获取和解释 MX？委派检查是否区分权威回答与转介，并处理所需地址？发现客户端是否查询协议真正要求的全部记录类型，而非碰运气？本地缓存工具是否有经过授权的范围和明确的新鲜度？

负面与部分成功场景尤其值得测。空 RRset、截断、DNSSEC 验证失败、TCP 延迟和转发路径，都可能影响应用结论。权威服务器与递归解析器应分别观察，旧新客户端应分别统计；否则一个健康的大群体会盖住少量但重要的遗留调用。

验收还应覆盖慢周期。一个每月才执行的诊断，一个仅在故障时启动的备用系统，都不能用两天无事故证明已脱离 ANY。迁移窗口应由用途的触发条件决定。每项结果最终绑定用途、替代、责任人、部署范围与到期条件，才能让“完成”成为可核查判断，而不只是一个日期。

退役 DNS ANY 应按用途迁移，而不只是停掉查询码

为何重要

摘要

安全理由成立，迁移责任仍然存在

先问用途，再选替代查询

每项用途只应进入一个有终点的处置

EDE 解释边界，不能替登记表盖章

测完整判断，而不只是测 RCODE

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报