DNS解析被污染，先别急着甩锅运营商 DNS解析异常现场里，最容易吵起来的就是这句话：到底是运营商污染，还是域名服务商、云厂商、权威DNS出了问题？实际处理时不能靠感觉，尤其是业务已经受影响的时候，谁的问题要用证据说话。 DNS污染这个词在现场经常被混着用。严格一点看，它可能是本地递归DNS返回了错误结果，也可能是中间链路注入了伪造DNS响应，也可能是权威DNS配置本来就错了，还可能是域名服务商做

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

DNS解析太慢会影响网站速度吗 会影响，但影响的方式要看场景。DNS解析不是网页加载里耗时最大的环节，可一旦它慢，用户的第一下访问会非常明显地卡住。因为浏览器在拿不到 IP 之前，后面的 TCP 连接、TLS 握手、HTTP 请求都没法开始。 实际使用中发现，很多人排查网站慢，会先看服务器 CPU、带宽、数据库、CDN命中率，但忽略了 DNS Lookup 这一段。尤其是海外业务、跨境访问、CNA

DNS解析做故障转移，健康检查探针频率别拍脑袋设 DNS解析故障转移看起来很简单：A记录指向主站，健康检查发现主站挂了，就把解析切到备用站。实际用起来会发现，真正影响切换体验的，不只是探针频率，还有TTL、递归DNS缓存、客户端缓存、探针判定策略、故障类型。 探针频率设太低，故障发现慢；设太高，误判概率上升，还会给业务入口制造额外压力。尤其是跨境业务、游戏登录服、支付回调、API网关这类场景，探针

DNS解析TTL设太低和设太高分别会踩什么坑 TTL这个参数平时看着不起眼，真出故障时会非常明显。它决定DNS记录在递归DNS、Local DNS、部分客户端缓存里能存多久。TTL设成300秒，理论上就是5分钟后缓存过期，再去权威DNS查一次；设成3600秒，理论上就是1小时。 实际使用中发现，TTL不是越低越灵活，也不是越高越稳定。它更像一个“缓存保质期”。保质期太短，查询压力和抖动会变多；保质

DNS解析TTL值设太低和设太高各自会踩什么坑 DNS TTL看起来只是一个数字，很多人改解析时顺手填个60、300、600、3600，甚至直接用DNS服务商默认值。实际线上跑一段时间就会发现，TTL不是越低越灵活，也不是越高越稳定。它影响的是递归DNS缓存多久，也就是用户、运营商Local DNS、公共DNS在多长时间内继续相信旧记录。 这里先把概念放准：TTL是权威DNS返回给递归DNS的缓存

DNS解析里CNAME和A记录混用，会不会让CDN回源路径绕弯 这个问题实际排查中经常遇到，尤其是站点接了CDN以后，DNS控制台里还能看到一堆A记录、CNAME记录、备用线路记录，访问慢了就开始怀疑：是不是DNS解析写乱了，导致CDN回源跑远了。 先把结论放在前面：普通访问链路里，用户侧DNS解析主要决定“用户访问哪个CDN节点”，不直接决定“CDN节点怎么回源”。CDN回源路径通常由CDN平台

DNS被污染了，别急着改解析，先把链路拆开看 DNS问题最麻烦的地方在于，表面现象都很像：域名打不开、解析到奇怪IP、部分地区访问正常、部分地区访问异常、换个DNS又好了。实际排查时不能只盯着控制台里的解析记录，因为用户拿到的结果不一定来自权威DNS，中间可能经过了本机缓存、运营商Local DNS、公共递归DNS、EDNS Client Subnet、DNS劫持设备，甚至还有应用自己的DNS缓存

DNS被污染之后，最快恢复业务的动作不是改解析 业务因为DNS污染中断时，很多人第一反应是去DNS控制台改A记录、改CNAME、切DNS服务商。这个动作不一定错，但它通常不是最快的。 原因很简单：DNS污染的麻烦点不在权威DNS有没有返回正确结果，而在用户侧递归DNS、运营商链路、Local DNS缓存、甚至中间路径已经把错误结果塞给用户了。你在权威DNS上改得再快，用户那边仍然可能拿到脏结果。

DNS anycast 和 unicast 在解析速度上的差异实测 DNS 解析速度这个问题，平时看起来很小，真到业务抖动、跨境访问、移动网络异常的时候，它会变得很明显。尤其是同一个域名，在不同地区、不同运营商下，使用 anycast DNS 和 unicast DNS，解析耗时可能差几十毫秒，也可能差到上百毫秒。 实际使用中发现，很多人判断 DNS 快不快，只看某一次 dig 的 Query t