摘要

  • DNSOP 的 GREASE 草案第 03 版拟在多个 DNS 扩展点上周期性使用未分配值，防止实现与中间设备把今天见过的值固化成唯一允许清单。它仍是有效期内的工作组 Internet-Draft，不是 RFC、正式分配或部署命令。
  • 失败后的顺序重试会增加等待时间；同时发送普通查询与实验查询可保护响应速度，却会增加权威端流量。若由响应方发起 GREASE，服务器甚至未必看得见下游客户端是否失败。
  • 默认启用前，应有一份到期即失效的实验章程，记录具体字段、取值算法、样本与排除范围、时延和流量上限、遥测与指纹控制、停止条件及回滚负责人。这是 Daniel Kade 的治理建议，不是 IETF 规则。

协议真正失去扩展能力，通常没有一场醒目的事故。一个预留字段多年没有新值，实现者便在代码里写下“只能是这些”。防火墙或代理把陌生数字当成异常。现有功能仍然正常，于是错误继续扩散。等标准组织终于需要使用那块空间，登记表说它可以用，网络却已经拒绝它。

GREASE 把故障发现时间提前。它产生没有业务含义、按协议应被忽略的数值，让不容忍未知值的实现尽早暴露。RFC 8701 已把这种做法用于 TLS：稀疏保留的 GREASE 值由客户端发出，合规服务器继续协商，僵硬实现则在真实新功能依赖它之前显形。

DNSOP 的《Greasing Protocol Extension Points in the DNS》尝试把这套维护方法带入 DNS。第 03 版发布于 2026 年 7 月 6 日，将在 2027 年 1 月 7 日到期。它是工作组正在推进的草案，可以被更新或替代，并不等于最终共识。

草案本身很诚实地标出了未完工处：工作组尚未就保留取值范围达成一致；“保留码点值”一节仍是占位文字；解析器与服务器的详细行为、错误判断、回退、测试结束日期、逐项停用和遥测共享都列在待展开清单中；IANA 部分也等待范围决策。

这并不削弱 GREASE 的价值，却决定了部署纪律。技术机制可以先进入产品，治理契约不能因此被假定已经存在。

“DNS GREASE”不是一个单一动作

草案列出的候选位置包括 DNS 头部剩余标志位、Opcode、EDNS 版本、EDNS 头部标志、Class、资源记录类型与 EDNS 选项码。它们的容量从一个空余比特到近六万多个未分配值不等，而且会随 IANA 分配变化。

RCODE 与扩展 RCODE 被明确排除。它们表达响应状态；修改它们会改变查询方对答案的判断，不再是“能否无害忽略未知扩展”的测试。

因此，把 GREASE 描述成“发送畸形 DNS 包”并不准确。实验值是有效结构里没有实用语义的值。一个合规接收者应忽略它并继续工作。出错只能先证明实验流量与对照流量之间存在不兼容差异，不能自动证明是哪台中间设备、哪个厂商或哪一段网络有罪。

不同字段还要求不同实验。EDNS 选项除了代码还有数据，数据如何生成同样需要规则。测试新 RR 类型可能必须另造一条查询，而不是给原查询附加内容。适合十六位空间的保留区间，不适合只有一个余位的字段。授权对象应是“某方向、某扩展点、某算法”，不能只是一个总开关。

重试与并行，把成本记在不同账户

解析器发出带 GREASE 的查询后，如果失败，可以去掉实验扩展再试一次。用户最终可能仍得到正常答案，但要等待第一次失败结束。若常规可用性指标只记录最后结果，实验发现的问题还会被成功重试遮住。

另一种做法是并行发送：普通查询用于服务，GREASE 查询只用于遥测。这样不会让用户等待实验分支，权威服务器和沿途网络却要处理额外查询。

顺序模式消耗时延与重试预算；并行模式消耗查询量、CPU 与出口预算。两者都会增加日志、分析与故障协作成本。不能只规定“抽样比例”，却不说明实际动用了哪一种资源。

第 03 版只说高吞吐解析器用少量样本即可粗略观察，并写下“也许千分之一？”这一尚带问号的例子。它不是规范阈值，也不是任何规模部署的安全证明。对于全球公共解析服务，千分之一仍可能在短时间向某个小型权威服务集中大量额外请求。

实验章程需要比例，也需要绝对上限；既要有全局上限，也要有单一目的端上限。事故窗口、高影响服务、已知脆弱权威设施可被明确排除。扩大样本之前，必须分别证明普通服务路径稳定、实验数据可解释、单项停止按钮有效。

从响应端发起，盲区会落在用户一侧

由解析器发起时，实验者至少能看到近端结果：发了什么、是否收到响应、与去掉 GREASE 的对照有何差异。它仍然不能只凭一次超时定位故障设备，但观察链条的两端都在发起者附近。

权威服务器也可以在响应中加入未知标志、EDNS 选项或更高版本号，用于针对性测量。问题是服务器可能不知道查询方如何处理：接受了答案、改问其他服务器、静默失败，还是让下游应用中断。

所以草案明确提出，响应方发起的 GREASE 应默认关闭。这条边界不应被产品界面抹平。运营者允许递归解析器在出站查询中抽样，不等于允许权威服务在入站请求的答案里做反向实验。

响应端实验需要更窄的区域或流量清单、外部客户端观察点、更低阈值与可立即生效的关闭机制。发起者看不到最终失败时，本地没有告警不能成为自动扩大范围的理由。

保留值会被特殊对待，未分配值也会改变身份

专门保留一批 GREASE 数值，能避免它们日后承载真实功能，也便于在抓包里识别。但接收方可能只为这批已知值写例外，继续拒绝其他未知值。测试通过了，真正要维护的通用扩展能力却没有得到证明。

从当前未分配空间随机选择，较难形成固定白名单。代价是某个数值以后可能被 IANA 分配给真实扩展。旧软件曾被训练为忽略它，等它有了含义仍可能继续丢弃。

草案提出用预配置或可配置的测试结束日期降低碰撞风险。这个日期不是项目管理装饰，而是协议安全条件。到期自动停用，迫使续期人重新检查登记表，而不是让一场早已无人记得的实验永久运行。

截至本次研究，IANA DNS 参数登记表在 2026 年 8 月 28 日更新，分别管理 Class、RR 类型、Opcode、EDNS 选项、头部标志与 EDNS 版本等空间。现有表项没有替草案解决尚未形成共识的 DNS GREASE 保留范围。

章程应保存启动时的登记表快照或哈希。它证明的只是“当时所见状态”，不是对空闲编号的长期占有权。每次续期、软件大版本或登记变化都应触发重新比对；发生交叉就自动退役相关测试值。

遥测要能解释这次打扰

GREASE 的回报是诊断。如果错误频率低到淹没在日常噪声里，实验只增加了不确定性；如果发送模式过于固定，接收方又可能专门识别并绕过它。通用 GREASE 草案把这两端都列为风险。

DNS 的回退机制还会制造“服务成功、实验失败”的双重结果。最小事件记录至少要区分：扩展点、取值类别、算法版本、方向、时间、实验响应、耗时、重试或并行分支，以及最终交给客户端的普通答案。否则团队只能看到成功率，却不知道扩展点是否已经僵化。

结论也要受限。超时不能指认中间设备；FORMERR 不能证明拒绝发生在哪一跳；对照查询成功也不能证明未来真实扩展一定安全。可重复差异是调查起点，不是公开归责的终点。

指纹风险同样真实。第 03 版指出，不随机选择 GREASE 值可能暴露具体解析器实现。通用草案则提醒，任何参数变化都可能影响指纹。为了复现，团队可能愿意在一个软件版本内保持模式；为了降低识别性，又希望每次交互都变化。两者无法同时最大化。

章程应写明选择：例如在有限时期内稳定、跨时期轮换；只公布算法类别，不公开部署级秘密；查询名最小化；原始事件仅保留到定位完成；对外共享聚合结果。空泛的“匿名遥测”不能代替字段与保留期限。

回退保护服务，也会延长技术债

遇到不兼容就关闭扩展再试，是 DNS 长期使用的生存策略。它让旧系统继续工作，同时也让拒绝未知值几乎没有成本，修复动力被传回所有发送方。

草案进一步提醒：如果回退会关闭安全扩展，攻击者可能诱导系统走上这条降级路径。GREASE 的长期目标之一，就是提前暴露这种问题，最终减少未来扩展对回退的依赖。

但“发现不兼容”“控制当下影响”“取消回退”是三项不同决定。实验运营者可能没有权力更新故障设备。立即取消回退，会把维护争议直接转换成用户不可用。

章程需要分别记录三种状态及其责任人。观察证据可触发调查；缓解措施可保持服务；只有明确的兼容性政策与变更授权，才能决定何时不再迁就。仪表盘上的红点不是取消回退的授权书。

一份会自动失效的实验章程

第一部分是权力：谁批准把真实流量纳入实验，谁实现算法，谁解释证据，谁握有无需发布新版本即可停止的权限。厂商把功能随升级送达，不代表运营者已经接受全部成本。

第二部分是线上的准确对象：字段、值集合或生成算法、必要载荷、发起方向、实现版本与 IANA 快照。保留、实验用途、私用和未分配必须分别记载。

第三部分是范围与预算：纳入和排除的流量，分阶段比例，全球与目的端硬上限，顺序重试或并行对照，允许增加的时延、查询量、CPU、日志与告警。实验分支失败时，普通服务分支仍须可独立工作。

第四部分是证据与隐私：何种差异算失败，哪些情况仍未归因，原始数据保存多久，谁能查看，什么只能以聚合形式分享，以及如何检测产品指纹。

最后是时间和退出：开始日期、默认结束日期、登记表复查、显式续期、逐项关闭、自动中止阈值与回滚负责人。新增 IANA 分配撞上活跃值时，应由系统停止，而不是等用户先发现。

GREASE 的理由是让未来仍有选择。实验章程的理由，是让今天承担代价的人也保有选择。一个无法说明范围、期限和停止权的机制，还没有资格成为默认设置。

来源

  1. DNS 协议扩展点 GREASE——第 03 版
  2. DNS GREASE Datatracker 页面
  3. DNS GREASE 文档历史
  4. DNSOP 活跃文档
  5. DNSOP 工作组章程
  6. RFC 8701——TLS GREASE
  7. RFC 6891——DNS 扩展机制
  8. Maintaining Protocols Using Grease and Variability——第 06 版
  9. IANA DNS 参数登记表