某头部社交平台那次全球范围的服务中断，哪怕已经过去了很久，在很多团队的复盘文档里依然是必讲案例。服务中断的整整几个小时里，旗下的即时通讯、社交主页、账号体系几乎全部不可用，用户端报错五花八门。有人猜测是服务器整体宕机，有人猜测是遭遇了恶意攻击，事后技术复盘把矛头指向了两个平时容易被忽略的基础设施组件：网络出口的路由协议BGP，以及内部域名解析DNS。作为一个常年跟基础设施打交道的工程师，我想借这个话题，把“如何及时发现DNS问题”这件事彻底讲清楚。即使你所在的公司没有那家平台的体量，DNS监控的思路、脚本和教训也完全适用。这篇文章不会复述那场事故的每一个细节，重点放在DNS故障为什么难发现、该用什么思路去监控、有哪些可以直接抄走的脚本和避坑经验。适合运维工程师、SRE、后端开发，以及所有需要对服务可用性负责的同学参考。1. 事件复盘：一次全球性宕机，为什么问题会卡在DNS上1.1 从“通而不通”的表象看故障链条那次事件最令人印象深刻的，是它的“大”和“怪”。说它大，是因为旗下多款应用在全球范围同时失效，这不是某机房、某区域的局部事故；说它怪，是因为很多内部监控指标看起来都还正常，服务器进程没有全挂，网络没有完全断开。可用户就是访问不了任何域名下的资源，要么一直转圈，要么直接报错。要理解为什么会出现这种“通而不通”的状态，得先把访问一个网站的链路拆开。用户在浏览器里输入域名，第一件事不是建立连接，而是做域名解析，把类似 example.com 这种名字翻译成对应的IP地址。解析过程中，用户的设备会把查询请求交给配置好的递归解析器。递归解析器如果不知道答案，会按照层级关系一路查下去：先找根服务器，再找顶级域服务器，最终找到这个域名的权威服务器。拿到IP之后，用户的设备才会真正去连接那台服务器、传输数据。与此同时，互联网网络上还有一个角色叫边界网关协议，也就是BGP。它负责在网络运营商之间交换“这些IP空间归谁管、通往哪里”的路由信息。如果把网络比作现实交通，BGP就是路口的大指示牌，告诉数据包该往哪个方向走。一旦某块IP空间的BGP公告出错，其他网络根本不知道这些IP的归属位置，数据包自然就送不进来。复盘下来，那场事故的触发点是一连串复杂的网络协议连锁反应：路由层先出现问题，随后内部DNS解析链路也受到拖累。外部用户到不了权威服务器，或者递归节点缓存了错误的路由信息，导致解析请求无法完成。于是用户看到的只是“页面打不开”，实际故障链路却从路由层一直延伸到应用入口。1.2 这类故障暴露出的监控盲区复盘之后，我印象最深的有三点。第一，监控必须站在用户视角。很多团队对服务器层面的监控已经做得非常细致：进程、端口、CPU、内存、磁盘，全都有，但这一堆指标回答不了一个关键问题——“在用户所在网络环境下，这个域名到底能不能解析成功？”只有从用户的网络视角发出真实解析请求，才能拿到真实可用的结论。内部再健康，只要用户进不来，一切都是零。第二，DNS故障具有低基数、高爆发的特点。DNS平时太稳定了，成功率和响应时间长期处在漂亮的状态，这恰恰是陷阱。因为它太稳，很多人不会为它设计复杂的监控。一旦出问题，就是全局性的、秒级的崩溃，而传统阈值告警在“成功率从99.99%掉到90%”的时候可能根本不会触发，等触发时，用户报障早就铺天盖地。第三，变更管理比监控本身更重要。几乎所有大规模基础设施故障都与一次看似不起眼的变更有关：一段路由公告、一条域名记录的TTL调整、一台递归服务器的转发策略。任何一个环节在灰度不充分的情况下推了全局，都可能造成跨区域雪崩。事后我去检查自己负责的系统，发现凡是我当时能快速定位的问题，基本都有清晰的变更记录可查；凡是排查了几个小时的问题，基本都是变更没有被记录下来。2. DNS故障到底为什么这么难及时发现2.1 解析路径里的缓存和层级，决定了观测的复杂度很多人觉得DNS不就是“把域名翻译成IP”吗？要是真这么简单，监控也就不难做了。实际上，DNS是一个分层的分布式系统，这直接决定了故障观测的复杂度。正常一次解析过程，至少要经过这些环节：用户设备先检查浏览器和操作系统的本地缓存。这里命中后，解析过程根本不产生网络请求。缓存未命中，查询请求才会发给本地配置的递归解析器。这个递归解析器可能来自运营商，也可能是企业级自建DNS。递归解析器收到请求后，如果缓存里有记录，就直接返回；没有，它会从根服务器开始逐级查询，先问根服务器“com域归谁管”，再到顶级域服务器问“example.com的权威服务器是谁”，最后向权威服务器要具体的A记录或AAAA记录。权威服务器返回结果后，递归解析器会按照TTL（存活时间）在本地缓存一段时间，并把结果原样返回给用户。这里面的任何一层出现问题，用户看到的结果都高度相似：解析超时、解析失败、返回空结果。但故障根因可能藏在客户端配置、本地网络、递归服务器故障、根或顶级域通信异常、权威服务器配置错误等许多位置。这就是为什么光靠“能不能通”这种二值判断根本没法定位问题。用一个生活化类比：你想找一家餐厅的电话，先查自己手机通讯录。没存号码，于是打给查号台。查号台自己也不知道号码，需要转总机、再让分机接线员查询。这串环节里只要有一个人不接电话、查错了号，你最后都会觉得“连个号码都查不到”。DNS故障也同理，用户只会觉得“网站打不开”，并不知道断在哪一层。2.2 四类常见故障类型，每一类都容易伪装故障类型典型表现监控难点解析失败递归服务器返回SERVFAIL、NXDOMAIN等错误码需要解析RCODE，不能只看通不通解析超时查询发出后长时间无响应，最终超时需要区分网络丢包和服务无响应解析结果错误返回了IP，但不是预期目标地址需要维护预期IP集合做比对缓存不一致不同地区、不同递归节点解析结果不同需要多地点、多视角交叉验证第一类，解析失败。这种情况下递归服务器通常会明确返回错误码。SERVFAIL意味着服务器内部异常或无法完成递归查询；NXDOMAIN则表示域名或记录真的不存在。但需要警惕的是，权威侧配置错误也可能导致NXDOMAIN误报。监控不能只判断“有没有返回”，必须看返回的是什么。第二类，解析超时。查询发出去后石沉大海，直到超过timeout才报错。超时可能是因为网络丢包、防火墙丢弃UDP 53流量、递归服务器负载过高。这类问题和普通的网络抖动长得一模一样，是最容易误判的一类。第三类，解析结果错误。DNS明明返回了IP，但返回的不是预期目标。原因可能是权威记录配置错误、递归缓存被污染，或者路由层面的错误劫持。这类最危险，因为TCP连接能建立、80或443端口能连通，表面看起来完全正常，用户却被带到了错误地址而不自知。第四类，缓存不一致。同一个域名，在不同地区、不同递归节点拿到完全不同的结果。这可能源于TTL设置不合理、权威记录更新后旧缓存未过期，或者出现了某种配置漂移。即使权威服务器本身正常，用户在前端递归节点上也可能长期拿到旧地址。2.3 为什么传统监控体系在这里基本失灵我见过不少团队用“ping加端口探测”来作为基础设施可用性的底线。在DNS场景下，这套方法几乎全部失效。ping能通，只能证明主机和网络路径是活的，证明不了DNS服务能正确回答问题；端口能连，只能说明53端口有进程在监听，但监听端口和应用层逻辑是两回事。更麻烦的是，监控端如果配置了本机缓存，在非强制刷新模式下，查询过程根本不走网络，它拿到的永远是Local Cache里的“正常结果”，而真实用户可能已经因为递归节点故障打不开页面了。再加上偶发的小问题容易被告警阈值和平滑算法过滤，直到量变引发质变，才以用户报障的形式爆发出来。所以结论很直接：要可靠地发现DNS问题，必须主动发起真实的、模拟用户路径的解析查询，并对查询结果做多维度校验，而不能依赖被动式的端口监控或系统内置的存活探测。3. 设计一套能“及时发现问题”的DNS监控方案3.1 先想清楚监控目标，再谈工具监控不是越复杂越好，而是先回答“你到底要保护什么”。围绕DNS，我把核心目标拆成三件事：可用性：这个域名还能不能被正常解析。这是底线。正确性：解析出来的IP是不是我预期的IP。这是防止“解析到了错误地方”事故的关键。性能：解析响应快不快。这直接影响到每一个用户的页面首屏速度和接口调用成功率。这三个目标的优先级是有讲究的，可用性解决“通不通”，正确性解决“对不对”，性能解决“快不快”。通不通是底线，不对会让用户访问到错误目标，不快会让体验直线下降。建议团队在搭建监控时，先照着这三个目标把监控项列出来，再去看需要什么工具。这样既能减少监控盲区，也能避免为凑指标而监控一堆没用的东西。3.2 核心指标与阈值设计，别拍脑袋定围绕三个目标，我建议重点看这几个指标：解析成功率：成功解析次数除以总查询次数，衡量可用性。平均响应时间：从发出查询到拿到最终响应的时间，衡量性能。慢查询比例：超过设定阈值（比如1秒）的查询在总查询中的占比，比平均值更能反映尾部体验。结果匹配率：解析出的IP集合与预期IP集合的匹配情况，衡量正确性。阈值方面，我的经验是先采集一周历史数据，把基线跑出来。比如某个域名平时平均响应时间30毫秒，P95是80毫秒，P99是150毫秒。正常情况下几乎不出现失败。那就可以设定：连续3次解析失败触发告警；平均响应时间超过250至300毫秒持续5分钟触发告警；解析结果不在预期IP集合内，直接告警。这里有个关键点：不要对单次失败立即告警。一次超时可能只是网络抖动，连续失败才说明有持续性问题。但也不要让阈值过宽，否则故障已经发生很久告警才出现。建议频率：基础巡检1分钟一次，多地域交叉验证5分钟一次。太频繁会给DNS服务器带来额外压力，反而把自己变成告警源。3.3 方案一：定时脚本巡检，最轻量也能解决问题最简单也最实用的入门方案，是用系统自带的计划任务跑一个脚本，定时对关键域名发起真实的DNS查询，把异常状态记录下来并触发告警。整套方案不需要引入额外平台，只要服务器上装了dig命令就行。下面是一个用bash写的巡检脚本骨架，可以直接复制改成自己的域名和IP集合。#!/bin/bash # DNS健康巡检脚本 DOMAINS=(example.com api.example.com) EXPECTED_IPS=("1.2.3.4,5.6.7.8" "2.3.4.5,6.7.8.9") LOG_FILE="/var/log/dns_check.log" ALERT_HOOK="/usr/local/bin/send_alert.sh" for i in "${!DOMAINS[@]}"; do domain="${DOMAINS[$i]}" # 使用系统默认递归解析器做一次真实解析 result=$(dig +short +time=3 +tries=2 "$domain" A 2>/dev/null) exit_code=$? if [ $exit_code -ne 0 ] || [ -z "$result" ]; then echo "$(date +'%F %T') [ERROR] $domain 解析失败" >> "$LOG_FILE" "$ALERT_HOOK" "$domain 解析失败" continue fi # 校验解析结果是否在预期IP集合内 expected="${EXPECTED_IPS[$i]}" match=0 for ip in $result; do if [[ ",$expected," == *",$ip,"* ]]; then match=1 fi done if [ $match -eq 0 ]; then echo "$(date +'%F %T') [ERROR] $domain 解析结果异常，结果=$result" >> "$LOG_FILE" "$ALERT_HOOK" "$domain 解析结果不在预期集合内: $result" else echo "$(date +'%F %T') [OK] $domain 解析正常" >> "$LOG_FILE" fi done这里最关键的两个细节一个是+time=3 +tries=2，限制单次查询的超时秒数和重试次数，避免整个计划任务被一台无响应的DNS服务器拖死；另一个是预期IP集合比对，因为很多DNS问题根本不是不解析，而是解析到了错误的结果。脚本里的告警hook可以是一个发站内信、短信、电话的脚本，也可以直接调用运维平台的webhook，按你现有环境来。3.4 方案二：多地域与递归交叉验证，捕获更隐蔽的故障单机脚本只能证明本机自己的网络视角。当问题只出现在某个地区、某个运营商，或者只出现在某些递归节点时，单点脚本可能依然是绿的。真正要覆盖这种场景，必须引入多地点交叉验证。常规做法是布置几个分布在异地、不同运营商网络中的探针。可以是一台小云主机，也可以是已有的多地服务器。每个探针对同一批域名发起解析查询，但使用不同的递归解析器：例如一个使用某运营商默认递归服务，一个使用公共递归服务。所有探针把结果汇总到一个中心节点的页面或数据库里，做统一比对。这里特别强调公共递归视角：公共递归服务器通常代表了大多数真实用户的解析路径，用它探测出来的结果，最接近用户真实体验。如果自建DNS正常、公共递归异常，问题大概率出在自建环境和外部递归节点的连通性上；如果多个公共递归节点同时失败，就很有可能是权威服务器或域名配置本身出问题。这种“内外对照”的视角，能显著压缩故障定位时间。另外还可以加一层更复杂的验证：对核心域名定期执行一次完整链路追踪，确认从根服务器到顶级域再到权威服务器的每一跳返回都正常。这层检查不需要频繁跑，5到10分钟一次就够了，能把那些“解析有结果但链路里某一跳响应异常”的隐患也照顾到。4. 实操过程：从零到一实现DNS健康巡检4.1 开始前的准备清单动手之前先列一份清单，能省掉很多返工麻烦。确定要监控的域名清单：从核心业务域名开始，比如官网入口、API域名、登录认证域名。不要一上来就监控几百个域名，告警噪音会迅速冲淡你的判断力。确认每个域名的预期IP集合：提前把当前解析结果拉出来存一份作为基准，后续任何配置变更走流程后同步更新这个基准。挑选探测节点：至少两个，最好跨地域、跨运营商。决定执行方式：可以用系统计划任务，也可以用专门的调度平台。对大多数团队来说，服务器自带的计划任务已经够用。确定单次查询超时时间：建议3秒，这个值能平衡“网络慢”和“故障丢弃”两种误报。4.2 用Python写一个结构更清晰、更完整的巡检器如果不想依赖外部命令，或者希望结果结构化、方便后续接入运维平台，我更推荐用Python的dnspython库来写巡检器。代码更直观，同时也更容易扩展成一套长期跑的服务。import dns.resolver import datetime import json import time import requests # 配置区域 CHECKS = [ { "domain": "example.com", "record": "A", "expected_ips": {"1.2.3.4", "5.6.7.8"}, "timeout": 3, }, { "domain": "api.example.com", "record": "A", "expected_ips": {"2.3.4.5"}, "timeout": 3, }, ] ALERT_URL = "http://alert.example.local/api/v1/alert" # 统一使用某个公共递归服务器作为参照视角 PUBLIC_RESOLVER = "<你的公共递归IP>" def check(domain, record, expected_ips, timeout): resolver = dns.resolver.Resolver() resolver.nameservers = [PUBLIC_RESOLVER] resolver.timeout = timeout resolver.lifetime = timeout start = time.time() try: answers = resolver.resolve(domain, record) result_ips = {str(rdata) for rdata in answers} elapsed = (time.time() - start) * 1000 ok = result_ips == expected_ips return { "ok": ok, "ips": list(result_ips), "response_time_ms": round(elapsed, 2), "error": None, } except Exception as e: return { "ok": False, "ips": [], "response_time_ms": None, "error": str(e), } def send_alert(message): try: requests.post(ALERT_URL, json={"text": message}, timeout=5) except Exception: pass def main(): for item in CHECKS: result = check( item["domain"], item["record"], item["expected_ips"], item["timeout"] ) status = "OK" if result["ok"] else "ERROR" log_line = { "time": datetime.datetime.now().isoformat(), "domain": item["domain"], "status": status, "detail": result, } print(json.dumps(log_line, ensure_ascii=False)) if not result["ok"]: send_alert( f"{item['domain']} 检查异常, 详情: " f"{json.dumps(result, ensure_ascii=False)}" ) if __name__ == "__main__": main()这个版本有几个很实用的点：把预期IP做严格匹配，一旦解析出陌生IP马上能发现；记录响应时间字段，为后续性能趋势分析留数据；异常时直接调用统一告警接口，可以和现有监控体系快速打通。初次运行前记得先安装依赖，然后用一条计划任务定时执行，并把标准输出重定向到日志文件。4.3 告警策略设计：三层漏斗，别让告警把人淹没告警规则设计得不好，运维团队很快会对告警声音脱敏，后面再响也没人当回事。我的经验是三层漏斗式策略。第一层，单次失败先记录不告警，继续观察。第二层，连续3次失败，或者1分钟内失败率超过50%，触发普通告警。第三层，多个探测点同时失败，或核心域名解析结果大面积异常，直接升级为紧急告警。这套策略既能过滤掉网络抖动引起的单点误报，又能保证全局性问题在几分钟内浮出水面。再补充一个关键点：告警消息里一定带上上下文。光说“example.com解析失败”价值不大，最好把当时的预期IP、实际返回IP、响应时间、使用的递归服务器都带上。值班人员看到消息基本就能判断是哪一类问题，而不是先登录机器查半天。4.4 实测效果：模拟故障后的真实表现我在一个测试环境里做过演练：把权威服务器上某条A记录临时改成错误IP，设定巡检脚本每60秒执行一次，走公共递归路径。下一轮执行就报了异常，告警内容显示“解析结果不在预期集合内”。这个过程只花了不足一分钟。同样的故障，如果只依赖端口监控，很可能要等几个小时后用户投诉才能暴露。还有一次演练，直接断掉某台递归服务器的出方向网络，让递归器暂时无法访问权威服务器。此时脚本表现为连续解析超时，成功触发普通告警；但在同一时间段，服务器本身能ping通，端口也正常。这个对比能很直观地说明问题：监控要模拟用户链路，而不是检查服务器是否“活着”。5. 常见问题与排查技巧实录5.1 我在DNS监控上踩过的坑第一个坑是缓存骗人。某次一个域名已经切换到了新IP，脚本却一直解析到旧地址，看起来一切正常。最后发现是脚本所在机器和本机递归解析器都保留了旧缓存，TTL还没过期。解决方法是探测时显式指定与线上用户一致或相近的递归解析器，同时定期清理监控端的缓存，必要时用随机化域名片段绕过缓存。第二个坑是只测A记录。很多服务的登录、图片、接口分别依赖MX、CNAME、AAAA等不同记录类型。真正出事时，A记录可能完全正常，但CNAME链路断掉了。建议把核心服务的各类记录都列进巡检范围，而不是只盯着A记录。第三个坑是忽略TCP 53。DNS默认走UDP，但遇到响应体较大、需要从权威侧回退到TCP时，一旦网络层对TCP的53有限制策略，就会造成部分用户解析异常。而纯UDP脚本完全测不出来，因为所有UDP查询都是正常的。我的做法是定期用TCP模式补测一轮，作为对照。第四个坑是监控机和用户的网络视角不一致。比如监控脚本配置了企业自建DNS，而真实用户走的是运营商DNS，两边解析结果会因为缓存和地域节点不同而产生差异。解决思路是在关键业务上增加至少一个与用户路径一致的公共递归视角，避免用内部视角替代全局视角。5.2 故障排查时最实用的一组工具命令真到故障发生时，手边最快的几个命令：dig <域名> A @<指定递归服务器>：快速验证从某个递归节点拿到的解析结果。dig <域名> +trace：完整走一遍从根到权威的解析路径，直接看问题卡在第几跳。nslookup -type=a <域名>：顺手做一次对照验证。tcpdump -i eth0 port 53 -n：抓53端口流量，确认请求是否发出、响应是否回来。权威侧解析日志：确认权威服务器收到的查询量是否异常，流量骤降或骤升都值得警惕。排查顺序我建议按这个走：先用自己的机器解析一次，确认本机能不能拿到结果；再换一个公共递归解析器查一遍，排除本地缓存因素；然后用完整链路追踪看断点；最后到权威服务器侧看日志和负载。通常十分钟内能定位到问题到底出在客户端配置、递归路径、中间网络还是权威侧。注意：不要一上来就怀疑权威服务器配置。大量问题其实出在递归路径、客户端配置或中间网络，逐层排除才是效率最高的方式。去权威侧之前，一定要用完整链路追踪确认断点位置。5.3 几条日常维护建议，提前消灭隐患第一，DNS配置变更要留痕。每一次修改解析记录、调整TTL、转发规则，都要记录变更时间、操作人和影响范围，出现问题后可以快速回看比对。第二，定期做解析结果对比。把权威结果和主要公共递归节点的结果放在一起比对，能提前发现配置漂移或缓存不一致的风险。第三，周期性演练不能省。模拟一次域名解析不可用，跑一遍告警、定位、恢复的完整流程，比写一堆永远不用的监控规则有用得多。第四，把DNS相关的告警输出接入统一日志中心，用趋势分析看是否存在渐进式恶化，避免只靠实时告警被动响应。要说这套监控方案有什么缺点，那就是需要有人持续维护预期IP集合，以及定期校准递归视角。它毕竟不是一套买来装上就完事的商业产品。但从投入产出比看，它能在几分钟内发现影响全局的解析问题，已经比“等用户报障再排查”强太多了。我个人在运维里最深的感受是，DNS监控的难点从来不在工具，而在视角。每一次故障结束后，我都会问自己一个问题：如果下一次同样规模的事故发生，我用什么方法能提前5分钟发现它？只要这个问题的答案不是空白的，这套监控方案就还有继续迭代的价值。
某头部社交平台那次全球范围的服务中断，哪怕已经过去了很久，在很多团队的复盘文档里依然是必讲案例。服务中断的整整几个小时里，旗下的即时通讯、社交主页、账号体系几乎全部不可用，用户端报错五花八门。有人猜测是服务器整体宕机，有人猜测是遭遇了恶意攻击，事后技术复盘把矛头指向了两个平时容易被忽略的基础设施组件：网络出口的路由协议BGP，以及内部域名解析DNS。作为一个常年跟基础设施打交道的工程师，我想借这个话题，把“如何及时发现DNS问题”这件事彻底讲清楚。即使你所在的公司没有那家平台的体量，DNS监控的思路、脚本和教训也完全适用。这篇文章不会复述那场事故的每一个细节，重点放在DNS故障为什么难发现、该用什么思路去监控、有哪些可以直接抄走的脚本和避坑经验。适合运维工程师、SRE、后端开发，以及所有需要对服务可用性负责的同学参考。1. 事件复盘：一次全球性宕机，为什么问题会卡在DNS上1.1 从“通而不通”的表象看故障链条那次事件最令人印象深刻的，是它的“大”和“怪”。说它大，是因为旗下多款应用在全球范围同时失效，这不是某机房、某区域的局部事故；说它怪，是因为很多内部监控指标看起来都还正常，服务器进程没有全挂，网络没有完全断开。可用户就是访问不了任何域名下的资源，要么一直转圈，要么直接报错。要理解为什么会出现这种“通而不通”的状态，得先把访问一个网站的链路拆开。用户在浏览器里输入域名，第一件事不是建立连接，而是做域名解析，把类似 example.com 这种名字翻译成对应的IP地址。解析过程中，用户的设备会把查询请求交给配置好的递归解析器。递归解析器如果不知道答案，会按照层级关系一路查下去：先找根服务器，再找顶级域服务器，最终找到这个域名的权威服务器。拿到IP之后，用户的设备才会真正去连接那台服务器、传输数据。与此同时，互联网网络上还有一个角色叫边界网关协议，也就是BGP。它负责在网络运营商之间交换“这些IP空间归谁管、通往哪里”的路由信息。如果把网络比作现实交通，BGP就是路口的大指示牌，告诉数据包该往哪个方向走。一旦某块IP空间的BGP公告出错，其他网络根本不知道这些IP的归属位置，数据包自然就送不进来。复盘下来，那场事故的触发点是一连串复杂的网络协议连锁反应：路由层先出现问题，随后内部DNS解析链路也受到拖累。外部用户到不了权威服务器，或者递归节点缓存了错误的路由信息，导致解析请求无法完成。于是用户看到的只是“页面打不开”，实际故障链路却从路由层一直延伸到应用入口。1.2 这类故障暴露出的监控盲区复盘之后，我印象最深的有三点。第一，监控必须站在用户视角。很多团队对服务器层面的监控已经做得非常细致：进程、端口、CPU、内存、磁盘，全都有，但这一堆指标回答不了一个关键问题——“在用户所在网络环境下，这个域名到底能不能解析成功？”只有从用户的网络视角发出真实解析请求，才能拿到真实可用的结论。内部再健康，只要用户进不来，一切都是零。第二，DNS故障具有低基数、高爆发的特点。DNS平时太稳定了，成功率和响应时间长期处在漂亮的状态，这恰恰是陷阱。因为它太稳，很多人不会为它设计复杂的监控。一旦出问题，就是全局性的、秒级的崩溃，而传统阈值告警在“成功率从99.99%掉到90%”的时候可能根本不会触发，等触发时，用户报障早就铺天盖地。第三，变更管理比监控本身更重要。几乎所有大规模基础设施故障都与一次看似不起眼的变更有关：一段路由公告、一条域名记录的TTL调整、一台递归服务器的转发策略。任何一个环节在灰度不充分的情况下推了全局，都可能造成跨区域雪崩。事后我去检查自己负责的系统，发现凡是我当时能快速定位的问题，基本都有清晰的变更记录可查；凡是排查了几个小时的问题，基本都是变更没有被记录下来。2. DNS故障到底为什么这么难及时发现2.1 解析路径里的缓存和层级，决定了观测的复杂度很多人觉得DNS不就是“把域名翻译成IP”吗？要是真这么简单，监控也就不难做了。实际上，DNS是一个分层的分布式系统，这直接决定了故障观测的复杂度。正常一次解析过程，至少要经过这些环节：用户设备先检查浏览器和操作系统的本地缓存。这里命中后，解析过程根本不产生网络请求。缓存未命中，查询请求才会发给本地配置的递归解析器。这个递归解析器可能来自运营商，也可能是企业级自建DNS。递归解析器收到请求后，如果缓存里有记录，就直接返回；没有，它会从根服务器开始逐级查询，先问根服务器“com域归谁管”，再到顶级域服务器问“example.com的权威服务器是谁”，最后向权威服务器要具体的A记录或AAAA记录。权威服务器返回结果后，递归解析器会按照TTL（存活时间）在本地缓存一段时间，并把结果原样返回给用户。这里面的任何一层出现问题，用户看到的结果都高度相似：解析超时、解析失败、返回空结果。但故障根因可能藏在客户端配置、本地网络、递归服务器故障、根或顶级域通信异常、权威服务器配置错误等许多位置。这就是为什么光靠“能不能通”这种二值判断根本没法定位问题。用一个生活化类比：你想找一家餐厅的电话，先查自己手机通讯录。没存号码，于是打给查号台。查号台自己也不知道号码，需要转总机、再让分机接线员查询。这串环节里只要有一个人不接电话、查错了号，你最后都会觉得“连个号码都查不到”。DNS故障也同理，用户只会觉得“网站打不开”，并不知道断在哪一层。2.2 四类常见故障类型，每一类都容易伪装故障类型典型表现监控难点解析失败递归服务器返回SERVFAIL、NXDOMAIN等错误码需要解析RCODE，不能只看通不通解析超时查询发出后长时间无响应，最终超时需要区分网络丢包和服务无响应解析结果错误返回了IP，但不是预期目标地址需要维护预期IP集合做比对缓存不一致不同地区、不同递归节点解析结果不同需要多地点、多视角交叉验证第一类，解析失败。这种情况下递归服务器通常会明确返回错误码。SERVFAIL意味着服务器内部异常或无法完成递归查询；NXDOMAIN则表示域名或记录真的不存在。但需要警惕的是，权威侧配置错误也可能导致NXDOMAIN误报。监控不能只判断“有没有返回”，必须看返回的是什么。第二类，解析超时。查询发出去后石沉大海，直到超过timeout才报错。超时可能是因为网络丢包、防火墙丢弃UDP 53流量、递归服务器负载过高。这类问题和普通的网络抖动长得一模一样，是最容易误判的一类。第三类，解析结果错误。DNS明明返回了IP，但返回的不是预期目标。原因可能是权威记录配置错误、递归缓存被污染，或者路由层面的错误劫持。这类最危险，因为TCP连接能建立、80或443端口能连通，表面看起来完全正常，用户却被带到了错误地址而不自知。第四类，缓存不一致。同一个域名，在不同地区、不同递归节点拿到完全不同的结果。这可能源于TTL设置不合理、权威记录更新后旧缓存未过期，或者出现了某种配置漂移。即使权威服务器本身正常，用户在前端递归节点上也可能长期拿到旧地址。2.3 为什么传统监控体系在这里基本失灵我见过不少团队用“ping加端口探测”来作为基础设施可用性的底线。在DNS场景下，这套方法几乎全部失效。ping能通，只能证明主机和网络路径是活的，证明不了DNS服务能正确回答问题；端口能连，只能说明53端口有进程在监听，但监听端口和应用层逻辑是两回事。更麻烦的是，监控端如果配置了本机缓存，在非强制刷新模式下，查询过程根本不走网络，它拿到的永远是Local Cache里的“正常结果”，而真实用户可能已经因为递归节点故障打不开页面了。再加上偶发的小问题容易被告警阈值和平滑算法过滤，直到量变引发质变，才以用户报障的形式爆发出来。所以结论很直接：要可靠地发现DNS问题，必须主动发起真实的、模拟用户路径的解析查询，并对查询结果做多维度校验，而不能依赖被动式的端口监控或系统内置的存活探测。3. 设计一套能“及时发现问题”的DNS监控方案3.1 先想清楚监控目标，再谈工具监控不是越复杂越好，而是先回答“你到底要保护什么”。围绕DNS，我把核心目标拆成三件事：可用性：这个域名还能不能被正常解析。这是底线。正确性：解析出来的IP是不是我预期的IP。这是防止“解析到了错误地方”事故的关键。性能：解析响应快不快。这直接影响到每一个用户的页面首屏速度和接口调用成功率。这三个目标的优先级是有讲究的，可用性解决“通不通”，正确性解决“对不对”，性能解决“快不快”。通不通是底线，不对会让用户访问到错误目标，不快会让体验直线下降。建议团队在搭建监控时，先照着这三个目标把监控项列出来，再去看需要什么工具。这样既能减少监控盲区，也能避免为凑指标而监控一堆没用的东西。3.2 核心指标与阈值设计，别拍脑袋定围绕三个目标，我建议重点看这几个指标：解析成功率：成功解析次数除以总查询次数，衡量可用性。平均响应时间：从发出查询到拿到最终响应的时间，衡量性能。慢查询比例：超过设定阈值（比如1秒）的查询在总查询中的占比，比平均值更能反映尾部体验。结果匹配率：解析出的IP集合与预期IP集合的匹配情况，衡量正确性。阈值方面，我的经验是先采集一周历史数据，把基线跑出来。比如某个域名平时平均响应时间30毫秒，P95是80毫秒，P99是150毫秒。正常情况下几乎不出现失败。那就可以设定：连续3次解析失败触发告警；平均响应时间超过250至300毫秒持续5分钟触发告警；解析结果不在预期IP集合内，直接告警。这里有个关键点：不要对单次失败立即告警。一次超时可能只是网络抖动，连续失败才说明有持续性问题。但也不要让阈值过宽，否则故障已经发生很久告警才出现。建议频率：基础巡检1分钟一次，多地域交叉验证5分钟一次。太频繁会给DNS服务器带来额外压力，反而把自己变成告警源。3.3 方案一：定时脚本巡检，最轻量也能解决问题最简单也最实用的入门方案，是用系统自带的计划任务跑一个脚本，定时对关键域名发起真实的DNS查询，把异常状态记录下来并触发告警。整套方案不需要引入额外平台，只要服务器上装了dig命令就行。下面是一个用bash写的巡检脚本骨架，可以直接复制改成自己的域名和IP集合。#!/bin/bash # DNS健康巡检脚本 DOMAINS=(example.com api.example.com) EXPECTED_IPS=("1.2.3.4,5.6.7.8" "2.3.4.5,6.7.8.9") LOG_FILE="/var/log/dns_check.log" ALERT_HOOK="/usr/local/bin/send_alert.sh" for i in "${!DOMAINS[@]}"; do domain="${DOMAINS[$i]}" # 使用系统默认递归解析器做一次真实解析 result=$(dig +short +time=3 +tries=2 "$domain" A 2>/dev/null) exit_code=$? if [ $exit_code -ne 0 ] || [ -z "$result" ]; then echo "$(date +'%F %T') [ERROR] $domain 解析失败" >> "$LOG_FILE" "$ALERT_HOOK" "$domain 解析失败" continue fi # 校验解析结果是否在预期IP集合内 expected="${EXPECTED_IPS[$i]}" match=0 for ip in $result; do if [[ ",$expected," == *",$ip,"* ]]; then match=1 fi done if [ $match -eq 0 ]; then echo "$(date +'%F %T') [ERROR] $domain 解析结果异常，结果=$result" >> "$LOG_FILE" "$ALERT_HOOK" "$domain 解析结果不在预期集合内: $result" else echo "$(date +'%F %T') [OK] $domain 解析正常" >> "$LOG_FILE" fi done这里最关键的两个细节一个是+time=3 +tries=2，限制单次查询的超时秒数和重试次数，避免整个计划任务被一台无响应的DNS服务器拖死；另一个是预期IP集合比对，因为很多DNS问题根本不是不解析，而是解析到了错误的结果。脚本里的告警hook可以是一个发站内信、短信、电话的脚本，也可以直接调用运维平台的webhook，按你现有环境来。3.4 方案二：多地域与递归交叉验证，捕获更隐蔽的故障单机脚本只能证明本机自己的网络视角。当问题只出现在某个地区、某个运营商，或者只出现在某些递归节点时，单点脚本可能依然是绿的。真正要覆盖这种场景，必须引入多地点交叉验证。常规做法是布置几个分布在异地、不同运营商网络中的探针。可以是一台小云主机，也可以是已有的多地服务器。每个探针对同一批域名发起解析查询，但使用不同的递归解析器：例如一个使用某运营商默认递归服务，一个使用公共递归服务。所有探针把结果汇总到一个中心节点的页面或数据库里，做统一比对。这里特别强调公共递归视角：公共递归服务器通常代表了大多数真实用户的解析路径，用它探测出来的结果，最接近用户真实体验。如果自建DNS正常、公共递归异常，问题大概率出在自建环境和外部递归节点的连通性上；如果多个公共递归节点同时失败，就很有可能是权威服务器或域名配置本身出问题。这种“内外对照”的视角，能显著压缩故障定位时间。另外还可以加一层更复杂的验证：对核心域名定期执行一次完整链路追踪，确认从根服务器到顶级域再到权威服务器的每一跳返回都正常。这层检查不需要频繁跑，5到10分钟一次就够了，能把那些“解析有结果但链路里某一跳响应异常”的隐患也照顾到。4. 实操过程：从零到一实现DNS健康巡检4.1 开始前的准备清单动手之前先列一份清单，能省掉很多返工麻烦。确定要监控的域名清单：从核心业务域名开始，比如官网入口、API域名、登录认证域名。不要一上来就监控几百个域名，告警噪音会迅速冲淡你的判断力。确认每个域名的预期IP集合：提前把当前解析结果拉出来存一份作为基准，后续任何配置变更走流程后同步更新这个基准。挑选探测节点：至少两个，最好跨地域、跨运营商。决定执行方式：可以用系统计划任务，也可以用专门的调度平台。对大多数团队来说，服务器自带的计划任务已经够用。确定单次查询超时时间：建议3秒，这个值能平衡“网络慢”和“故障丢弃”两种误报。4.2 用Python写一个结构更清晰、更完整的巡检器如果不想依赖外部命令，或者希望结果结构化、方便后续接入运维平台，我更推荐用Python的dnspython库来写巡检器。代码更直观，同时也更容易扩展成一套长期跑的服务。import dns.resolver import datetime import json import time import requests # 配置区域 CHECKS = [ { "domain": "example.com", "record": "A", "expected_ips": {"1.2.3.4", "5.6.7.8"}, "timeout": 3, }, { "domain": "api.example.com", "record": "A", "expected_ips": {"2.3.4.5"}, "timeout": 3, }, ] ALERT_URL = "http://alert.example.local/api/v1/alert" # 统一使用某个公共递归服务器作为参照视角 PUBLIC_RESOLVER = "<你的公共递归IP>" def check(domain, record, expected_ips, timeout): resolver = dns.resolver.Resolver() resolver.nameservers = [PUBLIC_RESOLVER] resolver.timeout = timeout resolver.lifetime = timeout start = time.time() try: answers = resolver.resolve(domain, record) result_ips = {str(rdata) for rdata in answers} elapsed = (time.time() - start) * 1000 ok = result_ips == expected_ips return { "ok": ok, "ips": list(result_ips), "response_time_ms": round(elapsed, 2), "error": None, } except Exception as e: return { "ok": False, "ips": [], "response_time_ms": None, "error": str(e), } def send_alert(message): try: requests.post(ALERT_URL, json={"text": message}, timeout=5) except Exception: pass def main(): for item in CHECKS: result = check( item["domain"], item["record"], item["expected_ips"], item["timeout"] ) status = "OK" if result["ok"] else "ERROR" log_line = { "time": datetime.datetime.now().isoformat(), "domain": item["domain"], "status": status, "detail": result, } print(json.dumps(log_line, ensure_ascii=False)) if not result["ok"]: send_alert( f"{item['domain']} 检查异常, 详情: " f"{json.dumps(result, ensure_ascii=False)}" ) if __name__ == "__main__": main()这个版本有几个很实用的点：把预期IP做严格匹配，一旦解析出陌生IP马上能发现；记录响应时间字段，为后续性能趋势分析留数据；异常时直接调用统一告警接口，可以和现有监控体系快速打通。初次运行前记得先安装依赖，然后用一条计划任务定时执行，并把标准输出重定向到日志文件。4.3 告警策略设计：三层漏斗，别让告警把人淹没告警规则设计得不好，运维团队很快会对告警声音脱敏，后面再响也没人当回事。我的经验是三层漏斗式策略。第一层，单次失败先记录不告警，继续观察。第二层，连续3次失败，或者1分钟内失败率超过50%，触发普通告警。第三层，多个探测点同时失败，或核心域名解析结果大面积异常，直接升级为紧急告警。这套策略既能过滤掉网络抖动引起的单点误报，又能保证全局性问题在几分钟内浮出水面。再补充一个关键点：告警消息里一定带上上下文。光说“example.com解析失败”价值不大，最好把当时的预期IP、实际返回IP、响应时间、使用的递归服务器都带上。值班人员看到消息基本就能判断是哪一类问题，而不是先登录机器查半天。4.4 实测效果：模拟故障后的真实表现我在一个测试环境里做过演练：把权威服务器上某条A记录临时改成错误IP，设定巡检脚本每60秒执行一次，走公共递归路径。下一轮执行就报了异常，告警内容显示“解析结果不在预期集合内”。这个过程只花了不足一分钟。同样的故障，如果只依赖端口监控，很可能要等几个小时后用户投诉才能暴露。还有一次演练，直接断掉某台递归服务器的出方向网络，让递归器暂时无法访问权威服务器。此时脚本表现为连续解析超时，成功触发普通告警；但在同一时间段，服务器本身能ping通，端口也正常。这个对比能很直观地说明问题：监控要模拟用户链路，而不是检查服务器是否“活着”。5. 常见问题与排查技巧实录5.1 我在DNS监控上踩过的坑第一个坑是缓存骗人。某次一个域名已经切换到了新IP，脚本却一直解析到旧地址，看起来一切正常。最后发现是脚本所在机器和本机递归解析器都保留了旧缓存，TTL还没过期。解决方法是探测时显式指定与线上用户一致或相近的递归解析器，同时定期清理监控端的缓存，必要时用随机化域名片段绕过缓存。第二个坑是只测A记录。很多服务的登录、图片、接口分别依赖MX、CNAME、AAAA等不同记录类型。真正出事时，A记录可能完全正常，但CNAME链路断掉了。建议把核心服务的各类记录都列进巡检范围，而不是只盯着A记录。第三个坑是忽略TCP 53。DNS默认走UDP，但遇到响应体较大、需要从权威侧回退到TCP时，一旦网络层对TCP的53有限制策略，就会造成部分用户解析异常。而纯UDP脚本完全测不出来，因为所有UDP查询都是正常的。我的做法是定期用TCP模式补测一轮，作为对照。第四个坑是监控机和用户的网络视角不一致。比如监控脚本配置了企业自建DNS，而真实用户走的是运营商DNS，两边解析结果会因为缓存和地域节点不同而产生差异。解决思路是在关键业务上增加至少一个与用户路径一致的公共递归视角，避免用内部视角替代全局视角。5.2 故障排查时最实用的一组工具命令真到故障发生时，手边最快的几个命令：dig <域名> A @<指定递归服务器>：快速验证从某个递归节点拿到的解析结果。dig <域名> +trace：完整走一遍从根到权威的解析路径，直接看问题卡在第几跳。nslookup -type=a <域名>：顺手做一次对照验证。tcpdump -i eth0 port 53 -n：抓53端口流量，确认请求是否发出、响应是否回来。权威侧解析日志：确认权威服务器收到的查询量是否异常，流量骤降或骤升都值得警惕。排查顺序我建议按这个走：先用自己的机器解析一次，确认本机能不能拿到结果；再换一个公共递归解析器查一遍，排除本地缓存因素；然后用完整链路追踪看断点；最后到权威服务器侧看日志和负载。通常十分钟内能定位到问题到底出在客户端配置、递归路径、中间网络还是权威侧。注意：不要一上来就怀疑权威服务器配置。大量问题其实出在递归路径、客户端配置或中间网络，逐层排除才是效率最高的方式。去权威侧之前，一定要用完整链路追踪确认断点位置。5.3 几条日常维护建议，提前消灭隐患第一，DNS配置变更要留痕。每一次修改解析记录、调整TTL、转发规则，都要记录变更时间、操作人和影响范围，出现问题后可以快速回看比对。第二，定期做解析结果对比。把权威结果和主要公共递归节点的结果放在一起比对，能提前发现配置漂移或缓存不一致的风险。第三，周期性演练不能省。模拟一次域名解析不可用，跑一遍告警、定位、恢复的完整流程，比写一堆永远不用的监控规则有用得多。第四，把DNS相关的告警输出接入统一日志中心，用趋势分析看是否存在渐进式恶化，避免只靠实时告警被动响应。要说这套监控方案有什么缺点，那就是需要有人持续维护预期IP集合，以及定期校准递归视角。它毕竟不是一套买来装上就完事的商业产品。但从投入产出比看，它能在几分钟内发现影响全局的解析问题，已经比“等用户报障再排查”强太多了。我个人在运维里最深的感受是，DNS监控的难点从来不在工具，而在视角。每一次故障结束后，我都会问自己一个问题：如果下一次同样规模的事故发生，我用什么方法能提前5分钟发现它？只要这个问题的答案不是空白的，这套监控方案就还有继续迭代的价值。