DNS记录已经补上，为什么部分网络仍显示域名不存在：NXDOMAIN、负缓存与SOA时间怎么分

域名原本没有 api.example，维护者在控制台补上A记录。办公室网络几分钟后已经能解析，手机热点却仍显示域名不存在。两边看到的结果可以同时成立：权威服务器保存的是当前区数据，用户通常询问的递归解析器还可能保存稍早取得的否定答案。新增记录只改变权威区当前状态，旧递归解析器要等负TTL结束后才会重新取得新答案。

先确认记录真的进入所有权威服务器

等待缓存之前，先直接查询域名登记的每一台权威服务器。查询必须固定完整名称、记录类型和类别，并保存响应码、AA标志、答案、SOA序列与查询时间。若三台权威服务器中两台返回新地址、一台仍返回NXDOMAIN，问题不是公共递归缓存尚未更新，而是区发布、区传送或权威节点加载不一致。

控制台显示“已保存”也不足以证明公开权威链路已经提供记录。管理平台可能先写入数据库，再异步发布到权威节点；名称服务器委派也可能仍指向另一组服务器。应从父区取得实际NS，再逐台询问，不凭控制台列出的目标推断网络已经使用它。

SOA序列号可以帮助观察区版本，但不能单独替代目标记录查询。不同节点序列相同而答案不同，仍说明配置或提供路径需要调查；序列不同则给出更直接的同步线索。只有所有实际权威服务器都以AA响应给出新记录，才进入负缓存时间的分析。

NXDOMAIN与NODATA不是同一种空答案

NXDOMAIN表示名称不存在，NODATA表示名称存在但没有所查记录类型。前者通常在响应码中显示Name Error；后者常见为NOERROR、答案区为空，并带有权威区的SOA信息。把两者都写成“没解析到IP”，会丢掉最重要的诊断差异。

例如 api.example 已有A记录，却没有AAAA记录。查询A得到IPv4地址，查询AAAA得到NODATA并不矛盾；名称存在，只是没有IPv6记录。若浏览器优先尝试AAAA，而手工工具只查A，维护者会误以为两次观察同属一条缓存。记录表必须同时保留QNAME与QTYPE。

RFC 2308还规定两类否定结果的缓存范围不同。NXDOMAIN按名称和类别保存，NODATA还要包含记录类型。因此，刚补A记录后，先前对AAAA的NODATA不应被当成A查询的NXDOMAIN；反过来，名称级NXDOMAIN可能影响对多个记录类型的后续查询。

CNAME会增加另一层边界。查询名称可能先得到别名，真正不存在的是链条末端。RFC 8020提醒，缓存中被否定的名称不一定等于最初QNAME。只抄浏览器输入的域名而不保存别名链，可能把目标名称的NXDOMAIN错误归给入口名称。

SOA提供负缓存的倒计时

权威服务器返回可缓存的NXDOMAIN或NODATA时，应在authority部分带上所属区的SOA记录。负缓存TTL取SOA.MINIMUM与SOA自身TTL中的较小值。这个值随缓存停留时间递减，到零后，缓存的否定答案不得继续作为同一结果使用。

假设SOA自身TTL是3600秒，MINIMUM是600秒，负答案最多按较小的600秒计算。递归器甲在10:00取得NXDOMAIN，维护者10:02补上记录，甲仍可能到10:10附近才重新询问。递归器乙直到10:04才首次查询，而权威区已经更新，它会直接得到正答案。两位用户于是从10:04起看到不同结果。

负TTL不是从维护者点击保存时开始，也不是全球统一时钟。每个递归解析器在自己取得否定答案时建立倒计时；大型服务还可能由多台缓存节点分担查询。相同公共DNS地址背后，不同地点或节点的缓存年龄可以不同。

观察递归响应中的SOA与剩余TTL，可以估计该答案是否来自缓存，但要谨慎解释。解析器可能设置负TTL上限，转发器也可能重新包装响应。看到300秒不一定等于权威SOA原值就是300；需要与直接权威查询同时保存，才能比较。

无SOA的否定答案不应被当作可长期缓存的标准证据，因为缺少使其按时失效的边界。若网络设备、过滤页面或错误转发器制造NXDOMAIN，它可能没有规范的authority信息。此时应核对响应来源、服务器地址与DNSSEC状态，不把任何带NXDOMAIN字样的画面自动当成权威结论。

NXDOMAIN Cut可能影响新建子名称

RFC 8020进一步说明，递归解析器收到某名称的NXDOMAIN后，可以把该节点及其下级名称视为不可达。若 missing.example 被权威否定，随后查询 api.missing.example。解析器可能直接依据缓存返回NXDOMAIN，而不再向权威服务器发送第二次查询。NXDOMAIN缓存可能覆盖被否定名称之下的子名称。

这会让“我只补了子域记录”出现更长的错觉。维护者新增 api.missing.example，但某解析器此前缓存的是父名称 missing.example 不存在。只看新子域自己的TTL无法解释旧结果，因为影响它的是上级节点的否定缓存。应逐级查询名称，并检查哪一个名称最先得到权威NXDOMAIN。

规范使用SHOULD而非所有场景绝对一致的MUST，解析器实现可能不同。已经缓存的下级正答案、DNSSEC验证策略、内部与公开名称混用等情况，也会改变行为。所以部分网络受NXDOMAIN Cut影响、另一部分网络没有同样表现，并不意外。

空非终端名称也是重要反例。某节点自身没有记录，但它下面有有效子名称时，该节点并非不存在，正确结果应是NODATA。权威服务器若错误返回NXDOMAIN，递归器可能据此否定整棵下级名称。遇到这种情况，等待TTL只能暂时缓解，权威响应逻辑仍需修正。

别把SERVFAIL和超时写成域名不存在

NXDOMAIN是一项关于名称存在性的否定判断；SERVFAIL、超时和无法联系服务器描述的是解析过程没有成功完成。RFC 9520要求解析器对多种失败采用受限缓存，目的在于避免持续高频重试给故障链路增加压力，但这些失败不能改写成名称不存在。

若一个网络返回NXDOMAIN，另一个返回SERVFAIL，应分别调查。前者要追踪权威否定与SOA负TTL，后者要检查委派、DNSSEC验证、权威可达性和转发链。把两者合并成“DNS还没生效”，既不能预测恢复时间，也容易掩盖配置错误。

DNSSEC验证失败尤其需要保留原始状态。签名过期、DS与DNSKEY不匹配可能让验证解析器返回SERVFAIL，而不验证的解析器仍给出地址。此时清除NXDOMAIN缓存不是解决方法；要核对验证链和区签名。

浏览器、本机与公共递归器是不同缓存层

普通应用先询问操作系统，系统可能再询问路由器、企业转发器或公共递归服务。ICANN的说明指出，递归解析器会缓存从权威服务器取得的数据，并在命中时直接回答，不必再次联系权威服务器。直接查询权威服务器是在看当前区数据，查询递归服务器还会经过已有缓存与本地策略。

关闭浏览器或清理浏览器缓存，最多影响应用层保存的状态；它不会向运营商递归解析器发送全网删除命令。重启路由器也未必改变上游递归器。只有在明确掌握组织自营解析器时，管理员才可能执行定向清除；公共服务是否提供刷新接口以及如何处理，要以运营方说明为准。

切换手机热点有诊断价值，因为它可能换用另一条递归路径，但结果只能说明两条路径当时不同。热点立即正常不能证明办公室解析器配置永久错误，办公室仍NXDOMAIN也不能证明权威记录没有发布。要把两次查询的服务器、时间、QTYPE与返回码一起记录。

浏览器还可能使用加密DNS，绕过操作系统显示的服务器。测试时应先确认实际解析路径，或使用能明确指定服务器的查询工具。否则，修改系统DNS后浏览器结果不变，可能只是浏览器仍通过自己的DoH服务查询，并非缓存拒绝更新。

用时间线判断该等待还是修配置

第一步，记录变更前是否真的出现过NXDOMAIN，以及当时的SOA负TTL。若没有变更前证据，就不能准确倒推哪台解析器从何时开始缓存。第二步，在变更后直接查询每台权威服务器；所有节点必须给出一致新答案。

第三步，选择两个独立递归解析器，在同一时间查询相同QNAME与QTYPE。保存完整输出，而不是只截图“成功”或“失败”。若返回NXDOMAIN，记录authority中的SOA与剩余TTL；隔一段时间复查，看TTL是否递减并在归零后变成正答案。

第四步，逐级检查上级名称，排除NXDOMAIN Cut。第五步，再检查本机缓存、企业转发器和浏览器加密DNS。这个顺序先固定权威事实，再观察递归缓存，最后处理终端层，使每次观察都有明确层次和上下文。

若权威答案一致、旧递归NXDOMAIN的剩余TTL稳定递减，等待通常有明确边界。若TTL归零后仍不断出现全新的高TTL NXDOMAIN，说明解析器仍从某个权威路径取得否定答案，或查询名称、记录类型。委派并非维护者以为的对象。此时继续等待没有依据，应回到权威链逐项核对。

若不同权威服务器答案不一致，不应要求用户清缓存；若权威一致但只有某个企业网络持续异常，应检查该网络的转发器、策略区与内部名称覆盖；若仅浏览器异常而指定递归查询正常，再调查浏览器DoH、连接复用和页面缓存。每一种结果都对应不同责任层。

还应保存一次对照查询，而不是只留下异常样本。对照可以选择同一区内长期存在的名称，使用相同解析器、相同记录类型和相近时间查询。如果对照名称正常而新名称仍被否定，线索集中在名称级缓存、别名链或区数据；如果两者都失败，递归服务、委派或网络路径更值得优先检查。对照不能证明原因，却能缩小受影响范围。

交接给另一位维护者时，记录里应包含原始命令输出、解析器地址、UTC与当地时间、变更单号和权威区版本。不要只贴网页截图，因为截图通常缺少响应码、authority部分和查询服务器。完整记录也能避免下一次变更重复制造先查询不存在名称、随后立刻上线的负缓存窗口。

固定名称和记录类型，记录权威与递归响应的RCODE、AA标志、SOA序列、剩余TTL、时间和网络。这样的记录既能证明新记录何时进入权威区，也能看出旧否定答案在哪一层继续存在。TTL归零允许解析器停止使用旧否定答案，却不能保证全球解析器在同一秒完成刷新。DNS的目标是让分散缓存按各自边界逐步收敛；可靠排查依靠可复查的查询时间线，而不是把所有差异都归为一句“传播还没结束”。

资料来源

• RFC Editor：《RFC 2308: Negative Caching of DNS Queries》，发布或更新于 1998-03-01
• RFC Editor：《RFC 8020: NXDOMAIN: There Really Is Nothing Underneath》，发布或更新于 2016-11-01
• RFC Editor：《RFC 9520: Negative Caching of DNS Resolution Failures》，发布或更新于 2024-02-01
• ICANN：《DNSSEC – What Is It and Why Is It Important?》，发布或更新于 2019-03-05