服务已经恢复,为什么客户端还在报“域名不存在”?

举报
霍格沃兹测试学社 发表于 2026/09/14 16:05:15 2026/09/14
【摘要】 新服务上线时DNS记录延迟创建,导致客户端缓存“域名不存在”(NXDOMAIN)负响应。即使权威DNS已更新,多层缓存仍会延续故障数分钟。本文详解负缓存机制、真实恢复延迟及可控发布与验证方法。

新服务上线时,DNS记录晚了45秒创建。运维补齐记录后,浏览器很快能打开;一批后台客户端却继续报“域名不存在”,直到几分钟后才自行恢复。

服务端已经健康,权威DNS也已经返回正确地址。客户端仍失败,是因为此前查询到的“不存在”也可能被缓存。这个结果叫负响应;它有自己的缓存生命周期,不会因为服务刚恢复就自动收到通知。

本文使用教学内部服务。约束是:上线过程允许记录短暂缺失;客户端经过本机、容器、节点与递归解析器多层缓存;关键调用恢复目标为2分钟;不能靠无限重试放大DNS流量;故障切换要区分“域名不存在”和“暂时解析失败”。

“刷新网页好了”不能证明所有客户端都好了

浏览器、操作系统、语言运行时、连接池和企业递归解析器可能各有缓存。某个浏览器重新解析成功,只说明它走到的缓存路径已经更新。

长连接客户端甚至不再解析域名;另一些客户端每次请求都询问本地缓存。于是同一个时间点,部分实例正常、部分实例继续失败,并不矛盾。

01.png

负缓存为什么会延长故障

在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后永久缓存,除非产品明确接受直到重启都不恢复。

02.png

故障演练怎样做才真实

先在隔离域名制造短暂不存在,再补齐记录。分别从新启动进程、持续运行进程、不同节点和不同递归解析器查询,记录首次失败、权威恢复和各客户端首次成功的时间。

至少断言:

  • 权威侧恢复不等于全链路恢复;
  • 负缓存到期后能重新查询,而非永久失败;
  • NXDOMAIN与超时、SERVFAIL等错误被分别观测;
  • 重试有上限和抖动;
  • 发布流程在切流前验证名称存在;
  • 恢复时间满足业务目标,否则需要调整发布顺序或缓存策略。

监控不要只看服务健康探针。增加解析失败按错误码、客户端版本、节点和递归解析器分组的指标,才能看见“只有某一批实例没恢复”。

服务恢复是权威侧事实,用户恢复是整条解析链事实。DNS故障测试必须把负缓存的生命周期算进恢复时间。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。