新服务上线时，DNS记录晚了45秒创建。运维补齐记录后，浏览器很快能打开；一批后台客户端却继续报“域名不存在”，直到几分钟后才自行恢复。
服务端已经健康，权威DNS也已经返回正确地址。客户端仍失败，是因为此前查询到的“不存在”也可能被缓存。这个结果叫负响应；它有自己的缓存生命周期，不会因为服务刚恢复就自动收到通知。
本文使用教学内部服务。约束是：上线过程允许记录短暂缺失；客户端经过本机、容器、节点与递归解析器多层缓存；关键调用恢复目标为2分钟；不能靠无限重试放大DNS流量；故障切换要区分“域名不存在”和“暂时解析失败”。
“刷新网页好了”不能证明所有客户端都好了
浏览器、操作系统、语言运行时、连接池和企业递归解析器可能各有缓存。某个浏览器重新解析成功，只说明它走到的缓存路径已经更新。
长连接客户端甚至不再解析域名；另一些客户端每次请求都询问本地缓存。于是同一个时间点，部分实例正常、部分实例继续失败，并不矛盾。
负缓存为什么会延长故障
在0秒时，解析器得到“名称不存在”并缓存；45秒时，权威侧已经有记录；但只要负缓存仍有效，解析器就可能直接返回旧的不存在结果，不再向权威侧查询。到缓存到期后，下一次查询才看到新记录。
具体缓存时长与DNS响应、权威区配置、递归解析器和客户端实现有关。测试不能假设所有负响应都固定缓存同一个秒数，也不能把所有解析错误都当成NXDOMAIN。
下面用可控时钟模拟最核心的行为：
class ResolverCache:
def __init__(self):
self.entries = {
}
def remember_negative(self, name, now, ttl):
self.entries[name] = (None, now + ttl)
def lookup(self, name, now, authoritative):
cached = self.entries.get(name)
if cached and now < cached[1]:
return cached[0], "NEGATIVE_CACHE"
value = authoritative(name, now)
if value is not None:
self.entries[name] = (value, now + 30)
return value, "AUTHORITATIVE_QUERY"
def authority(_name, now):
return None if now < 45 else "10.0.0.8"
cache = ResolverCache()
cache.remember_negative("new.service", now=0, ttl=120)
assert cache.lookup("new.service", 46, authority) == (None, "NEGATIVE_CACHE")
assert cache.lookup("new.service", 121, authority) == ("10.0.0.8", "AUTHORITATIVE_QUERY")
这不是DNS协议栈实现，只是把“权威侧已恢复”和“缓存侧仍持有旧结论”分开。生产验证应使用真实解析链、抓包或查询日志确认每一层事实。
修复先从发布顺序开始
最便宜的防线，是先创建并验证名称，再启动依赖它的客户端或切流。删除旧记录也要考虑已有连接与缓存，不要把DNS当成瞬时配置总线。
客户端遇到名称不存在时，应遵守有限重试、抖动和总截止时间；但重试如果始终命中同一有效负缓存，只会增加本地调用次数。更不能收到NXDOMAIN后永久缓存，除非产品明确接受直到重启都不恢复。
故障演练怎样做才真实
先在隔离域名制造短暂不存在，再补齐记录。分别从新启动进程、持续运行进程、不同节点和不同递归解析器查询，记录首次失败、权威恢复和各客户端首次成功的时间。
至少断言：
- 权威侧恢复不等于全链路恢复；
- 负缓存到期后能重新查询，而非永久失败；
- NXDOMAIN与超时、SERVFAIL等错误被分别观测；
- 重试有上限和抖动；
- 发布流程在切流前验证名称存在；
- 恢复时间满足业务目标，否则需要调整发布顺序或缓存策略。
监控不要只看服务健康探针。增加解析失败按错误码、客户端版本、节点和递归解析器分组的指标，才能看见“只有某一批实例没恢复”。
服务恢复是权威侧事实，用户恢复是整条解析链事实。DNS故障测试必须把负缓存的生命周期算进恢复时间。
