凌晨2点，监控发现 shop.example.com 在华东访问超时，部分用户却被导向203.0.113.18，源站实际为203.0.113.9。直接扩容、切流量或重启应用，都可能掩盖问题：故障也许在DNS链路，而非源站。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：digvps（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
DNS污染、递归缓存偏差、权威NS错误和源站故障，外表都可能表现为“打不开”。只有对齐每一跳的应答与时间点，才能找到错误地址的来源。
递归解析链路通常从客户端存根解析器进入递归服务器，再询问根、TLD和权威服务器。任一层都可能返回旧记录、被劫持记录，或因转发路径不同产生差异。排查要固定域名、记录类型和查询时刻，记录响应码、TTL、CNAME链、最终地址及authority段，不能只抄浏览器显示的IP。
再从不同运营商、不同递归节点重复查询。若多数节点稳定返回203.0.113.9，异常节点却轮换出无关地址，应优先怀疑污染或递归链路差异；若所有节点返回同一地址，再测试端口、TLS证书和回源路径。NXDOMAIN、SERVFAIL与正常空应答也必须分开判断。
递归结果只是线索，权威应答比对应直接询问权威服务器，并用dig跟踪查询还原委派过程，再核对AA标志、TTL、SOA serial和各RRset。重点核对NS记录一致性，检查父区与子区NS、glue及lame delegation；CNAME目标及其A、AAAA分别核验，避免把目标域错误算到主域。
若已启用，DNSSEC验证要沿DS、DNSKEY、RRSIG核对信任链并查看校验状态。验证失败引发的SERVFAIL属于签名或信任链问题，不应等同于污染，更不能为恢复访问而关闭校验。
缓存状态核验须先保留现场：比对递归结果与权威实时结果，用未缓存的新名称测试转发路径，再回到原名称观察TTL。权威正确而递归错误，重点查污染、陈旧和负缓存；权威不一致，则修正NS委派与SOA。借助ServLlama汇总多地递归节点的响应码、TTL与地址差异，但结论仍需权威查询交叉确认。清理缓存应放在取证之后，否则会抹掉证据。
递归解析并非一次查询：客户端先请求递归器，再按根、TLD、权威逐级定位，命中缓存便返回。“本机失败、异地正常”常因链路节点不同。排查须固定递归解析链路的 qname、qtype 与 ECS，避免分流参数造成假差异。
同一问题应向本地/公共递归器及每个权威节点查询，做权威应答比对。权威侧记录 AA、rcode、ANSWER/AUTHORITY、TTL；递归侧查看 Age、缓存标志、截断回退。CNAME、referral、否定缓存不可混作最终地址。若权威给新值而递归仍给旧值，优先怀疑缓存或中间链路。
检查NS记录一致性，要查询父区与子区 apex 的 NS，确认 glue 可解析、各权威返回相同 SOA serial。字符串相同只是第一步；切流期新旧 NS 并存常见，须结合 serial、变更时间和日志判断。
缓存状态核验应交叉比较递归器、权威及不同出口的 TTL、Age、rcode。随机标签可绕开正向缓存，却不能排除否定缓存；serve-stale、隐藏 Age 或递归器改写也会造成错觉。换递归器可访问，不等于旧缓存已清除。
DNSSEC验证须沿父区 DS、子区 DNSKEY 到 RRSIG 逐级检查，用 delv 或 dig +dnssec 复现并记录错误。失败可能源于时钟偏差、签名过期、DS 委派过期或算法配置；关闭校验后可用，不能证明链路健康。
可执行检查清单：① dig +trace example.com 查委派；② dig @192.0.2.53 example.com A +norecurse 采集权威应答；③核对各权威的 SOA serial、NS、glue；④在故障网络、公共递归器、权威侧比对 TTL、rcode；⑤检查 UDP/53、TCP/53、截断回退及任播出口；⑥ delv example.com 核验签名链。
结论要落到“哪个节点、哪类对象、何时失效”：换递归器只证明路径有差异，不能替代对权威数据、委派和缓存的确认。保存原始响应后再变更，避免把临时缓存或切流窗口误判为根因。
