摘要

  • TTL 到期没有让记录自动变错，却结束了缓存的普通复用权。RFC 8767 仍要求解析器重新咨询信息源；只有权威刷新无法完成时，旧记录才进入例外分支。
  • Serve-stale 至少受四个不同时间面约束：客户端等待、解析总工作、失败后重试和最大陈旧年龄。配置里一个“开启”值无法证明实际行为。
  • 必须把旧 RRset、刷新失败、DNSSEC 签名时钟、返回给下游的短 TTL、EDE 提示、后台继续刷新和应用结果分别留证。解析器获得的是有限可用性裁量，不是替权威方宣布现状的资格。

一次切换，两个现实

设想某机构将登录服务从旧地址迁往新地址。它把 A 记录改到新平台，并计划让旧平台保留两小时。迁移后四十分钟，一家网络的递归解析器仍缓存着旧地址，但普通 TTL 已经结束；同一时刻，该解析器到所有权威节点的路径发生故障。

如果返回 SERVFAIL，整家网络的用户立刻失去登录能力。如果返回旧地址，服务也许继续，直到旧平台按计划关闭；也可能把用户送往一个已经解除控制的地址。解析器看不到迁移合同，也不知道旧端点的保留时间。它只知道：过去收到过什么、普通有效期何时结束、刷新尝试为何失败、本地规则愿意为可用性承担多大的陈旧风险。

这不是“稳定优先还是正确优先”的口号题。它是旧声明的托管问题。源头无法回答时，谁能让旧声明继续产生包级后果？答案只能是：解析器可以在明确、短暂、可撤销的边界内这么做，但不能把这个决定归到域名所有者名下。

TTL 结束的是普通授权

RFC 1035 把 TTL 描述为缓存记录后应再次咨询信息源、并在到期后丢弃的时间。RFC 2181 强调它是最长生存期。RFC 8767 更新了这套含义：记录在 TTL 内可以缓存；TTL 结束时，信息源必须再次被咨询；若权威刷新无法完成，记录才可以在规定条件下按未过期方式使用。

因此次序不可颠倒。TTL 不是建议刷新一下的装饰。它是普通缓存权的终点，也是重新求证义务的起点。Serve-stale 不是跳过求证，而是在求证没有产出可用权威答案时，选择一个已知过去，而不是一个新的失败。

TTL 为 0 的记录更清楚：它只属于正在进行的事务，不能缓存，更不能日后变成陈旧后备。原始 TTL 上限也不能与最大陈旧窗口混在一起。RFC 8767 建议把收到的 TTL 限制在约七天；另一个 maximum stale timer 才决定记录过期后还能保留多久。前者约束权威数据的普通缓存，后者记录解析器自己的例外权力。

四个计时器，不是一只钟

RFC 8767 有意给出示范方法，而非一个强制的统一算法。它列出的四个计时器分别解决不同问题。

客户端响应计时器问：正常刷新可以尝试多久，才不会错过客户端仍愿意接受答案的时刻？示范值约为 1.8 秒，略短于常见的两秒等待。设得太短，会把“权威稍慢”误判为“必须陈旧返回”；设得太长，最终送达的可能只是迟到的失败。

查询解析计时器限制整个上游求解工作，RFC 讨论的常见量级是十到三十秒。关键在于，向客户端发出陈旧答案后，上游刷新不应停止。用户的等待截止与系统的修复截止不是一件事。

失败重查计时器防止每个客户端查询都再次冲击已失效的权威节点。近期刷新已经失败时，可以在重查到期前直接使用陈旧数据。过短会在 DDoS 或故障中放大流量；过长会在权威恢复后继续隐藏恢复。RFC 的示范建议失败后不高于每三十秒重试一次，并引用五分钟上限。RFC 9520 又把解析失败缓存和退避变成更明确的要求。

最大陈旧计时器决定普通 TTL 结束后，旧对象还能在缓存里等待救急多久。示范值是一到三天。太短，长故障中没有后备；太长，会占用更多内存，也延长旧地址、旧否定或已撤销配置继续执行的窗口。

四只钟不能压扁成一个绿色状态。节点可能保留陈旧对象却从不返回，也可能先返回再刷新；可能保存一天，却把失败重查抑制五分钟；重启、缓存压力或版本升级后还可能改变行为。只有在每个时钟边界制造 canary，才能知道运行代码承诺了什么。

刷新成功必须是一个可识别事件

并非从权威地址收到任何包都足以替换旧状态。RFC 8767 规定，带 AA 位且 RCODE 为 NOERROR 或 NXDOMAIN 的权威响应必须被视为已经刷新。其他 RCODE 通常应视为刷新失败，之前状态继续保留。

这能避免瞬时 SERVFAIL 擦掉最后一个有用答案，但也划出解析器不能越过的边界。如果新鲜权威响应明确给出 NXDOMAIN，旧的正面答案就不能因为运营方“觉得删除可能是误操作”而继续统治。DNS 无法可靠区分一次合法删除和一次错误删除；serve-stale 不是对新权威否定的否决权。

REFUSED 更模糊。它可能表示明确撤下、临时 ACL 错误，或服务器已经不再负责该区。RFC 允许实现决定：当所有权威都返回 REFUSED 时，是否禁止陈旧回答。因此同一个选项名在两种实现里可能表达不同权力，需要按产品、版本和 RCODE 建语义矩阵。

RFC 9520 还要求把“解析失败”自身缓存起来，至少一秒、最多五分钟。失败缓存会阻止同一查询不断向上游发送。它不是旧 A 记录，也不是 NXDOMAIN 证据。证据账本必须同时保留两个对象：可供后备的过期答案，以及解释为何当前没有每次都刷新上游的失败状态。

返回的 30 秒不是权威方延长的寿命

递归解析器返回陈旧记录时，报文中的 TTL 必须大于 0，RFC 8767 推荐 30 秒。这个值不是旧记录重新获得的权威有效期。它只是解析器对这次陈旧投影授予下游的短缓存预算，既避开历史上 TTL 0 的兼容问题，也抑制 forwarding resolver 立即形成刷新风暴。

所以日志里只写 TTL=30 没有意义。新鲜 RRset 也可能只剩 30 秒。最小证据必须包含原始 TTL、入缓存时间、普通到期点、当前陈旧年龄、返回 TTL 与选择后备的原因。少一项，就无法判断客户端看到的是源头的新鲜状态，还是解析器对旧状态的临时延寿。

RFC 8914 用 EDE code 3 表示 Stale Answer，用 code 19 表示 Stale NXDOMAIN。它为转发链提供有价值的原因，但 EDE 不改变 RCODE 的处理，也不会强迫应用弹出警告、换解析器或拒绝结果。提示是证据，不是权限；更不能用“已经附带 EDE”代替风险控制。

旧的“不存在”可能挡住新入口

陈旧正面答案把用户带去旧目的地。陈旧 NXDOMAIN 则让一个名字继续不存在。两者的业务风险不同。

假设攻击期间，运营方临时创建新的恢复域名。某递归解析器留有该名字过去的 NXDOMAIN，刷新又失败，于是把旧的不存在继续返回。用户看到的是结构完整的否定答案，而不是明显故障。EDE 19 或许跟随报文，但多数应用不会把它展示给决策者。

DNSSEC 否定证据会放大这一问题。陈旧 NSEC 或 NSEC3 可能继续覆盖刚发布的名字、DS 或 TLSA，使一次新的委派修复、证书策略或安全升级无法被看见。此时连续性并不是保留服务，而是让昨日的缺席继续执行。

因此 eligibility 不宜只按“缓存中有对象”决定。证书签发、委派、紧急撤销、普通内容寻址，对陈旧数据的成本不同。若实现支持的范围不足以精确表达这种差异，领导层应选择更小的启用面，而不是用“关键记录会另行处理”的模糊话语掩盖事实。

DNSSEC 的时钟不会随缓存延长

存储期与密码学有效期是两件事。RFC 4035 要求 validator 的当前时间落在 RRSIG 的 inception 与 expiration 之间。把签名 RRset 留到 TTL 之后，不会移动签名到期点。RFC 8914 还专门定义 EDE code 7 表示 Signature Expired。

因此必须分别统计：陈旧但签名仍有效、陈旧且签名已到期、验证失败后返回失败，以及任何本地允许的不安全处理。maximum stale timer 也许还剩两天，RRSIG 却已经结束；同一组 bytes 从一个时刻到下一个时刻改变了可验证性质。“DNSSEC 已开启”无法表达这个边界。

攻击者还可能把权威不可达与陈旧缓存组合，用 DDoS 延长旧地址或旧否定。RFC 8767 指出，已经不再由域名所有者控制的地址可能在域名验证证书场景中继续产生风险。Serve-stale 没有创造废弃地址，但会改变旧绑定还能行动多久。

实现差异是治理材料

当前 BIND 文档把保留陈旧对象的 stale-cache-enable 与返回对象的 stale-answer-enable 分开，并暴露返回 TTL、最大陈旧年龄、刷新间隔和 rndc serve-stale 运行时控制。文档给出的陈旧响应 TTL 默认值是 30 秒，启用时最大保留默认一天。当前版本的客户端等待选项默认关闭，启用时只支持 0，这意味着立即返回；字段存在不等于实现了 RFC 示例的 1.8 秒等待。

Unbound 使用 serve-expired-* 系列，分别控制最大过期年龄、回复 TTL、回复前等待和失败后的重置。其当前文档区分立即返回与 RFC 风格的先尝试后后备。两个产品都支持这个概念，却不承诺同一条执行链。

混合解析器集群因此需要真正的包级矩阵：权威快速、缓慢、超时、SERVFAIL、REFUSED、NXDOMAIN；正面与否定对象；签名仍有效与已过期；缓存压力、重启与 runtime override。观察节点等了多久、附带什么 EDE、后台刷新是否继续、何时替换或逐出对象，以及应用最终连接到了哪里。

来源