DNS解析故障排查，TTL和权威服务器哪个先看

实际排障时，很多人一上来就盯TTL：是不是缓存没过期？是不是刚改记录还没生效？这个方向没错，但不一定是最省时间的方向。DNS问题看起来像“解析没更新”，背后可能是权威服务器没给对、递归DNS缓存没刷新、NS委派异常、CNAME链路断了，或者某个运营商递归DNS拿到的是旧答案。

现场处理时，判断顺序通常不是固定背口诀，而是看现象。如果是“刚改完A记录，部分地区还解析到老IP”，先看TTL很正常；如果是“全网都解析不到”“dig直接SERVFAIL”“只有某些NS返回不同结果”，TTL往往不是入口，应该先看权威服务器。

先把问题分成两类：答案旧，还是答案错

DNS故障排查最怕混在一起看。TTL解决的是缓存时间问题，权威服务器解决的是源头答案问题。源头都错了，TTL再短也只是更快地传播错误；源头是对的，TTL很长，用户看到旧结果才有解释空间。

举个常见场景：域名www.example.com原来解析到1.1.1.1，刚切到2.2.2.2。用户反馈有的地方访问新站，有的地方还访问旧站。这个时候要问的不是“TTL设置多少合适”，而是先确认权威服务器现在到底返回什么。

直接查权威：

dig NS example.com

dig @ns1.example-dns.com www.example.com A +norecurse

dig @ns2.example-dns.com www.example.com A +norecurse

如果所有权威NS都稳定返回2.2.2.2，再看递归DNS缓存和TTL。如果ns1返回2.2.2.2，ns2还返回1.1.1.1，问题就不在TTL，而在权威数据同步、DNS托管平台发布状态、隐藏主从同步，或者某台权威节点没更新。

TTL适合解释“为什么还有旧答案”

TTL是缓存保鲜期。递归DNS拿到记录后，会按TTL缓存一段时间。在TTL没归零之前，它可以不再去权威服务器问。用户用的本地运营商DNS、公共DNS、企业内网DNS，都会有自己的缓存行为。

例如A记录原TTL是3600秒，10:00把IP从1.1.1.1改成2.2.2.2。某个递归DNS在09:59刚问过权威服务器，它最多可能缓存旧记录到10:59。10:20用户通过这个递归DNS访问，拿到旧IP，这不算DNS异常，属于TTL预期内。

实际使用中发现，TTL还会遇到两个不太好看的情况。一个是部分递归DNS不完全尊重超短TTL，比如设置30秒，但实际缓存到几分钟。另一个是某些客户端、浏览器、JVM、移动端SDK也有自己的DNS缓存，排查时只看公共DNS不一定能解释用户端现象。

所以TTL更适合回答这类问题：

记录已经在权威服务器上改对了，为什么用户还没全部看到？

为什么8.8.8.8已经是新IP，114.114.114.114还是旧IP？

为什么业务切换后，某些地区过了20分钟才恢复？

权威服务器适合判断“源头有没有问题”

权威服务器是DNS答案的源头。排障时只要怀疑“源头答案可能不一致”，就不要先纠结TTL。特别是以下现象，建议直接查权威。

多个NS返回结果不一致

这个问题在线上不少见。DNS平台有多个权威节点，配置发布后有的节点成功，有的节点失败；或者主从DNS同步延迟，serial没更新；也可能是域名注册商处NS没改干净，老NS还在被递归DNS访问。

表现通常是：同一域名，同一记录类型，多查几次结果不同。有时用户反馈“刷新几次访问到不同服务器”，很多人会以为是负载均衡，结果一查发现是权威NS答案不一致。

排查命令可以这样跑：

dig NS example.com +short

dig @ns1.xxx.com www.example.com A +norecurse

dig @ns2.xxx.com www.example.com A +norecurse

dig @ns3.xxx.com www.example.com A +norecurse

如果三个权威返回的A记录分别是2.2.2.2、2.2.2.2、1.1.1.1，这就不是TTL问题。递归DNS问到哪个权威，就可能缓存哪个答案。用户看到随机结果，本质是源头不一致被递归DNS放大了。

递归DNS返回SERVFAIL

SERVFAIL不要急着说“缓存没更新”。SERVFAIL更多时候和DNSSEC、权威不可达、NS委派异常、CNAME链路异常有关。尤其是DNSSEC配置过的域名，DS记录、DNSKEY、RRSIG有问题时，支持校验的递归DNS会直接失败。

这时可以查：

dig www.example.com A

dig +trace www.example.com A

dig @权威NS www.example.com A +dnssec +norecurse

如果+trace在某一级断掉，或者根、TLD返回的NS指向已经废弃的DNS服务商，TTL不是重点。要先把委派链路修好。

NXDOMAIN和NOERROR空答案要分清

NXDOMAIN表示名字不存在，NOERROR空答案表示名字存在但没有这个类型的记录。比如查A记录没有，但可能只有AAAA记录；查根域A没有，但存在MX或TXT。

这里补充一点，CNAME也容易制造误判。www.example.com CNAME到cdn.example.net，如果cdn.example.net不存在或者权威异常，用户看到的是www解析失败，但真正出问题的可能在CNAME目标域名。

遇到CNAME链路，建议逐级查：

dig www.example.com CNAME

dig cdn.example.net A

dig +trace cdn.example.net A

不要只盯入口域名TTL。

一线排障更常用的判断节奏

线上接到DNS告警或用户反馈时，比较快的处理方式是先拿到“用户实际使用的递归DNS结果”和“权威服务器结果”。这两个结果一对比，方向基本就出来了。

权威是新IP，递归是旧IP

这是典型TTL缓存场景。比如权威返回2.2.2.2，用户本地DNS返回1.1.1.1。继续看旧记录TTL原来是多少、修改时间是什么、递归DNS剩余TTL是多少。

可以用：

dig @223.5.5.5 www.example.com A

dig @114.114.114.114 www.example.com A

dig @8.8.8.8 www.example.com A

dig @1.1.1.1 www.example.com A

如果返回旧IP，同时TTL还剩1800秒，那就等缓存过期，或者在业务侧做兼容。比如老IP继续保留一段时间，Nginx同时接新老来源，应用层不要在DNS切换瞬间把老节点下掉。

权威就是旧IP

这时别再等TTL。权威还没更新，递归DNS当然可能继续拿旧答案。要查DNS控制台发布是否成功、记录是否改错线路、是否有分线路解析、是否存在@和www混淆、是否改了测试域名没改正式域名。

实际使用中发现，分线路解析是重灾区。控制台默认视图已经改成新IP，但电信线路、联通线路、海外线路还挂着旧IP。查询时如果只用一个公共DNS，很容易误判为“部分地区缓存”。

这种情况可以指定不同递归DNS和不同地区探测点看结果，也可以直接在DNS平台检查每条线路视图。

权威NS之间不一致

这种现象比TTL更危险，因为它会不断制造新的缓存差异。一个递归DNS问到了旧NS，就缓存旧答案；另一个递归DNS问到新NS，就缓存新答案。用户侧看起来像随机故障。

处理方向是让所有权威NS答案一致，必要时临时降低业务风险：老IP保留服务，新IP也接流量，避免用户被解析到不可用节点。

TTL不是越低越好，切换前后要分阶段看

很多业务喜欢把TTL长期设置成60秒，觉得这样切换快。这个做法在部分场景可用，但不是没有成本。TTL低会增加权威DNS请求量，递归DNS更频繁回源，DNS托管质量差时反而容易暴露抖动。对高并发业务，DNS解析稳定性也要算进可用性里。

常见做法是：平时TTL设300秒或600秒，重大切换前提前把TTL调低，比如从3600秒调到300秒，等待至少一个旧TTL周期后再切IP。比如原TTL是3600秒，计划20:00切换，那最好在19:00以前把TTL降到300秒。否则20:00切换时，很多递归DNS手里仍然有一小时旧缓存。

如果是强依赖DNS切流的业务，比如游戏登录入口、API网关、下载站、海外业务回源，TTL策略要和服务器承载能力一起看。切到新IP后，新节点要扛得住突增流量，老节点也要继续保留一段时间。

在购买云服务器或规划切换方案时，线路和防护能力也会影响DNS切换效果。比如游戏服、下载分发、海外访问加速，需要较大带宽和稳定三网线路，可以看看129云的美国精品大宽带-D型，8C、16G DDR4 ECC、160G SSD、1Gbps峰值带宽、3TB流量，适合做海外入口或备用切换节点。遇到被打流量的场景，美国高防-A型带300G防御，更适合放在DNS切换的高防入口前面。需要国内西北电信单线业务，西安电信-B型带50Gbps单机防御，适合企业站、接口服务、区域业务入口。需要确认线路和业务匹配，可以直接问客服热线400-9177118。

权威查询和递归查询不要混着看

很多排障记录里会看到这样的描述：“我dig了一下，解析还是旧的。”但没说是查的哪个DNS。这个信息不够。查本机默认DNS、查公共DNS、查权威NS，结论完全不同。

本机默认查询：

dig www.example.com A

这看到的是当前机器配置的递归DNS结果，可能是公司内网DNS，也可能是云厂商VPC DNS。

指定公共递归DNS：

dig @8.8.8.8 www.example.com A

dig @223.5.5.5 www.example.com A

这看到的是公共递归DNS缓存和解析结果。

指定权威NS：

dig @ns1.example-dns.com www.example.com A +norecurse

这才是源头答案。+norecurse的意义是不要让对方帮你递归查询，只看它作为权威是否能回答。

多说一句，dig输出里的TTL也要看清。查递归DNS时看到的TTL通常是剩余缓存时间，不是权威记录配置的原始TTL。比如记录原TTL是600秒，递归DNS已经缓存了400秒，再查可能只看到200秒。不要拿这个数反推控制台配置一定是200。

有些故障看起来是TTL，其实是线路解析

分线路解析在国内业务里很常见，比如电信用户返回电信IP，联通用户返回联通IP，海外用户返回海外IP。问题也容易藏在这里。

比如控制台里默认线路A记录已经改成新IP，但电信线路没有改。用海外VPS查是新IP，用北京电信用户查还是旧IP。这个现象很像TTL缓存，但如果电信权威视图本身还返回旧IP，就不是等缓存能解决的。

排查这类问题，需要结合DNS服务商的线路视图、不同运营商探测点、公共DNS结果一起看。只用8.8.8.8查国内分线路域名，很多时候不够准确，因为它不一定代表国内用户真实解析路径。

改DNS服务器本身时，TTL更容易被误解

修改A记录和修改NS记录不是一回事。A记录的TTL在权威区里控制，NS委派还涉及注册商、TLD、父区缓存。很多人迁移DNS服务商时，以为在新平台配好记录就生效了，结果父区还委派到老NS，递归DNS继续去老服务商拿答案。

迁移DNS服务商时，要同时检查：

注册商处NS是否已经改成新DNS服务商。

TLD返回的NS是否已经更新。

老DNS服务商上是否还保留同样记录，避免过渡期被解析到空或旧IP。

新DNS服务商所有权威NS是否都能返回正确记录。

这个阶段用dig +trace很有用：

dig +trace www.example.com A

它能看到从根到TLD再到权威NS的链路。哪一级还指向旧NS，一眼就能定位。

DDoS切换场景里，不要只依赖短TTL

DDoS场景经常会用DNS把业务从普通节点切到高防节点。这里有个常见误区：把TTL设成60秒，就以为一分钟内全网都会切到高防。实际不会这么理想。

攻击开始后，部分递归DNS可能仍然缓存普通节点IP，客户端也可能持有连接，攻击流量还会继续打老IP。正确处理通常是老IP侧做黑洞、ACL、源站保护，高防IP侧接入业务，同时保证DNS权威答案稳定返回高防入口。

如果业务经常面临DDoS，不建议等被打时再临时改DNS。可以提前把业务架构做成高防入口常态化，或者至少保留可快速切换的高防记录。像129云美国高防-A型提供300G防御，适合海外业务、高风险站点、游戏入口做抗攻击接入；国内区域业务也可以结合西安电信-B型这种带50Gbps单机防御的节点做分区承载。

现场判断时的优先级更像这样

如果用户反馈“解析不到”，先查权威链路。因为NXDOMAIN、SERVFAIL、委派错误、DNSSEC错误，都不是TTL能解释的。

如果用户反馈“解析到旧IP”，先查权威是否已经是新IP。权威没更新，处理发布；权威已更新，再看TTL和递归缓存。

如果用户反馈“不同地区结果不同”，不要马上认定是缓存。先确认是否有分线路解析，再逐个权威NS查答案一致性。

如果用户反馈“偶发解析到不同IP”，重点查权威NS一致性、CNAME链路、DNS负载均衡策略。TTL只能解释旧答案保留多久，解释不了源头随机返回异常答案。

如果刚迁移DNS服务商，优先看NS委派和+trace结果。新平台控制台里配置正确，不代表全网已经去新权威服务器查询。

记录一次典型排查过程

业务把api.example.com从旧服务器10.0.0.1切到新服务器10.0.0.2，TTL原来是3600秒，切换前半小时才改成300秒。切完后，上海用户正常，北京电信用户异常，海外用户正常。

先查权威NS：

dig NS example.com +short

dig @ns1.dns-provider.com api.example.com A +norecurse

dig @ns2.dns-provider.com api.example.com A +norecurse

两个权威都返回10.0.0.2，看起来源头没问题。

再查公共递归DNS：

dig @223.5.5.5 api.example.com A

dig @114.114.114.114 api.example.com A

dig @8.8.8.8 api.example.com A

223.5.5.5和8.8.8.8返回10.0.0.2，114.114.114.114返回10.0.0.1，TTL还剩2400秒。这个结果说明它在降TTL之前缓存过旧记录，仍在旧TTL周期内。

但北京电信用户异常不能只看114。继续查DNS平台线路视图，发现电信线路单独配置了一条A记录，仍然是10.0.0.1，TTL 600秒。也就是说这里同时有两个问题：一部分是旧TTL缓存，一部分是电信线路配置漏改。

处理方式不是等。先把电信线路改到10.0.0.2，确认所有权威NS返回一致；旧服务器10.0.0.1继续保留服务至少一个小时，避免还拿着旧缓存的用户访问失败；应用层把新老节点都接入同一后端状态，等递归缓存自然过期后再下线旧节点。

TTL和权威服务器的关系要放在同一张排障图里看

TTL不是排障入口，也不是排障结论。它更像解释缓存传播时间的证据。权威服务器也不是每次都必须查到很深，但只要现象涉及“结果不一致”“解析失败”“改完不生效”，查权威能快速把问题切开。

比较稳的习惯是：每次DNS变更前记录旧值、旧TTL、变更时间、涉及线路；变更后查所有权威NS；再查几个主要递归DNS；业务侧保留老入口一段时间。这样遇到投诉时，不会只剩一句“可能是DNS缓存”。

如果只能在TTL和权威服务器之间选一个先看，解析失败、SERVFAIL、NXDOMAIN、NS迁移、权威不一致，先看权威服务器；刚改记录后还有旧IP，先确认权威已正确，再看TTL剩余时间和递归缓存。