摘要

  • 10 月 30 日的个人 Internet-Draft 建议：不自行验证 DNSSEC 的递归解析器收到未设置 DO 位的请求时，上游查询也清除 DO 位。
  • 如果后来的客户要验证证明，解析器必须识别先前缓存没有证明，再向权威服务器查询一次。

第一位客户只要答案，缓存于是存了一份轻巧的答案。第二位客户要加密证明，缓存却拿不出来。解析器得跑回权威服务器。这就是 Warren Kumari、Geoff Huston 和 Peter Thomassen 在 《Clearing the DO bit for DNSSEC》 中提出的交换条件。它是供讨论的个人草案，尚无 IETF 标准地位。

DO 位表示请求 DNSSEC 记录。RFC 3225 和 RFC 4035 当前要求懂 DNSSEC 的递归解析器向上游发请求时设置 DO 位，即使原客户没有设置。解析器可以向该客户隐去证明，同时自己留着。现行做法让权威侧多传数据，换取后续可用的证明材料。

草案建议调整一个特定情形：递归解析器本身不验证，进来的请求也没有 DO 位，那么向上游发出的请求也不设 DO 位。权威服务器便不自动附上签名等证明。作者担忧后量子签名变大，会增加响应尺寸、截断和转用 TCP 的次数。草案没有给出节省的字节数、失败率或部署测量。

代价写在缓存规则里。解析器必须标记哪些条目取得时没有 DNSSEC 记录；后来收到带 DO 位的同名请求，就必须重新向权威服务器索取证明。把“缓存命中”直接当成“验证材料齐全”，会让需要验签的客户拿不到材料。IETF DNSOP 的讨论还提出另一条路线：更多使用能容纳大响应的流式传输，而非继续压小 UDP 响应。谁承担容量成本，取决于实际流量。能改变判断的证据，是同时测试两种到达顺序、后续验证结果与权威侧总负载的实现数据。

原始草案 · RFC 3225 · RFC 4035