简介《Wireshark 数据包分析实战第3版》10.5.2节案例分析文档围绕分支机构工作站访问总部应用服务器时产生的DNS解析故障展开。文档以抓包数据为线索逐步分析DNS A记录查询、服务器故障响应、TCP SYN无回应等异常现象并涉及工作站、分公司DNS服务器、总部应用服务器及中心办公室首选DNS等多个节点最终定位到中心办公室路由器仅放行UDP 53端口、阻止TCP 53端口导致DNS区域传送失败这一配置错误。该案例完整呈现了从异常抓包到根因确认的排查过程帮助网络运维、安全分析及协议学习者理解DNS、TCP/UDP的工作原理掌握依据数据包特征反向定位故障的实操思路同时厘清DNS常规使用UDP、区域传送等场景切换到TCP的协议细节。资源为1个PDF文件大小644KB内容精炼便于碎片化查阅。目前已有327人学习下载适合需要快速建立Wireshark实战分析能力的读者。1. 引论一次DNS大面积解析失败暴露的不只是网络问题分公司一个普通工作日早上工位上的用户突然打不开总部应用系统。应用服务器IP拼得通吗拼不通。服务器宕机了吗没宕机是你根本没能把它的域名解析成IP。真正让人头疼的是这种故障的排查路径先在客户端抓包看到第一个数据包是DNS请求查的是应用服务器的A记录响应却直接扔回来一个「服务器故障SERVFAIL」连解析结果都没有——这行字几乎把所有初学者的排查方向都带偏了。这套方案要解决的就是这类「看着像服务器挂了、实际死在DNS链路」的隐蔽故障。以《Wireshark 数据包分析实战第 3 版》中的一个真实场景为例完整走一遍客户端 172.16.16.101 访问总部应用服务器 172.16.16.200中间隔着分公司DNS 172.16.16.251 与总部DNS 172.16.16.250抓包定位出区域传送被路由器ACL拦截最终恢复服务。适合正在做网络协议分析课程设计的人也适合被DNS故障折腾过的运维按这套方法可以直接照搬排查流程。2. 抓包前期设计镜像端口、过滤规则与pcap文件组织2.1 先把嗅探器放对位置再谈分析很多人抓包翻车不是不会用Wireshark而是流量根本没走到抓包网卡上。这个案例里有一个关键动作为了从分公司DNS服务器捕获合适流量把嗅探器留在原地只改变端口镜像设置让DNS服务器的流量被镜像到嗅探器。这一步说明抓包位置决定了你能不能在故障发生时拿到有效数据而不是事后补抓。通常的做法是我会先在交换机的上行口配置SPAN端口镜像把目标端口流量复制一份到接嗅探器的监听口。这里有个血泪经验镜像口不要接成普通接入端口否则会参与业务转发抓包数据量一大交换机CPU和镜像链路都容易被打满。正确姿势是配置一个专门的监听VLAN只做流量收包不转发业务报文。配置层面提供两个思路一是直接在交换机上做SPAN二是用TAP分光器物理分流项目里要求不高的话用SPAN就够了。# 交换机SPAN配置示意不同厂商命令有差异思路一致 Switch(config)# monitor session 1 source interface gi1/0/1 both Switch(config)# monitor session 1 destination interface gi1/0/24关键参数说明source interface指定被镜像的端口这里接分公司DNS服务器both表示进出双向都复制destination interface是嗅探器接入端口。配置完成后用Wireshark在监听口上随便抓几秒流量确认能看到DNS服务器的ARP和查询报文再放长线抓故障流量。如果看不到不是镜像方向配反了就是源端口选择有误这是抓包前必须验证的一步别等故障复现了才发现数据没进来。2.2 抓包与显示过滤器别把所有流量都收进来案例中提到捕获文件里「开头是我们之前看到的查询和响应但还有一个额外的数据包」说明这个场景下流量很干净但这不代表抓包时不用做过滤。我还是建议在任何抓包之前把捕获过滤器设置好减少无关注入降低文件体积和后期分析负担。这个项目里最合适的捕获过滤器是这样# 只抓与DNS服务器交互相关的流量 host 172.16.16.101 or host 172.16.16.251 or host 172.16.16.250 or host 172.16.16.200 # 也可以再加端口限定比如 host 172.16.16.250 and (port 53 or port 80)这个过滤器背后的逻辑是我们的目标是判断「工作站 → 分公司DNS → 总部DNS → 应用服务器」这条链路上哪个环节断了所以只要关注这四个IP之间的交互即可。捕获过滤器是BPF语法在Wireshark的Capture Options里设置它的好处是数据包在进入软件之前就被丢弃适合高流量环境缺点是过滤条件太长容易误伤实际项目里我一般用一条host限定就够更细的过滤交给显示过滤器做。显示过滤器则是事后分析神器。比如案例中判断DNS响应是否异常用dns.flags.rcode 1可以直接标出所有SERVFAIL的响应包判断TCP连接是否建立用tcp.flags.syn 1 tcp.flags.ack 0找出所有SYN包。我在判读数据包时通常先按IP分组再按协议分类最后用时间戳把两个文件客户端侧和DNS服务器侧对齐这样谁先谁后、谁没回复一眼就能看出来。2.3 pcap文件的组织与命名让复盘和交接不吵架案例中两次捕获文件分别命名为默认文件第一次和stranded_branchdns.pcap第二次这个命名习惯值得学。第一次是工作站侧抓包说明故障发生在「工作站与分公司DNS之间」或「分公司DNS再往上」第二次抓包前只改了端口镜像抓到的是分公司DNS的收发流量文件命名直接点出「分支DNS」这个位置。我一般做这种多段排查时文件命名会带上三要素位置、时间、方向。比如branchdns_client_query_1016.pcap、hqdns_server_syn_1016.pcap。这样一旦连续抓了七八个文件整理报告时不至于对着文件名发愣。另外抓包时提前在Wireshark里设置好环形缓冲每个文件50MB共10个文件防止流量一大把磁盘写满这个故障场景虽然只产生几个包但生产环境上一旦涉及TCP重传数据量会迅速膨胀后悔药得提前备好。3. 故障判读全流程从DNS失败响应到SYN疑点3.1 第1个包A记录查询与「服务器故障」响应打开第一次捕获文件第一个数据包是工作站 172.16.16.101 发给 172.16.16.251 的DNS查询查询类型是A记录查询名称是应用服务器 172.16.16.200 对应的域名。这个包的特征很标准客户端向本地DNS服务器发起递归查询期望拿到目标域名对应的IPv4地址。到这里为止一切正常。问题出在响应包上。响应里没有返回A记录而是直接标记为服务器故障SERVFAIL响应码1。在DNS协议中SERVFAIL通常表示服务器在递归查询过程中遇到上游故障或自身处理异常属于临时性错误和NXDOMAIN域名不存在完全是两回事。注意案例里强调「这个数据包只是一个错误并没有响应查询结果」——这说明分公司DNS替客户端去上级查询时失败了它自己也不知道这个域名该指向哪里。用tshark可以直接把这个响应码打出来# 把DNS响应里rcode字段拿出来看 tshark -r branch_client_first.pcap -Y dns.flags.response 1 \ -T fields -e frame.number -e ip.src -e ip.dst -e dns.flags.rcode输出里第1个响应包如果rcode为1就说明是SERVFAIL。这个字段在Wireshark的DNS协议树里显示为Response code: Server failure (1)。看到这个结果基本上可以把排查范围从「应用服务器是否宕机」收窄到「DNS解析链路是否中断」。这也解释了用户为什么访问不了工作站连域名都解析不出来自然无法发起HTTP请求。3.2 启动二段抓包分公司DNS侧那一串奇怪的SYN包为了确认分公司DNS到底出了什么问题把嗅探器留在原地只改端口镜像设置让分公司DNS服务器的流量镜像过来得到stranded_branchdns.pcap。打开后能看到开头依然是之前那对查询/响应但多了第三个包分公司DNS服务器172.16.16.251主动向总部首选DNS服务器172.16.16.250的53端口发出一个SYN包协议是TCP而不是常规的UDP。很多人看到TCP 53会觉得奇怪——DNS不是用UDP吗为什么会出现TCP连接这里要回到DNS协议的机制UDP是主用传输协议适合单个小查询但当响应数据超过512字节扩展机制下可到4096或者进行区域传送zone transfer时必须改用TCP保证数据完整性和顺序性。区域传送就是把整个DNS区域文件从主服务器同步到从服务器资源记录数量多、数据量大只能用TCP。这个SYN包就是区域传送请求的连接建立包分公司DNS作为从属服务器定期向总部主服务器请求同步区域数据。案例里明确指出分公司DNS是总部DNS的从属服务器而应用服务器的权威记录在总部DNS上所以分公司必须从总部把资源记录同步过来才能真正解析这个域名。SYN包发出后无人应答说明TCP握手都建立不起来区域传送彻底失败。3.3 链路推演从客户端到总部DNS的四段判定把抓包数据按通信链路排一遍这套故障的逻辑会非常清晰。客户端到分公司DNS这一段是通的因为查询请求和SERVFAIL响应都回来了说明客户端能到达本地DNS服务器本地DNS也正常回了包。分公司DNS到总部DNS这一段是断的TCP SYN发出去没人理说明分公司试图向总部同步区域资源的路径已经阻塞。链路推演到这里有两个可能断点中间的路由器规则拦截或总部DNS根本没有收到报文。案例里特别提了一句「我没有给出总部DNS服务器的流量捕获文件因为根本就没有」并指出SYN包从来没有到达服务器。这句话说明排查人员实际上嗅探了总部DNS流量确认请求根本没进来于是断点锁定在路由器。最后技术人员检查路由器配置发现ACL只放行了端口53的UDP流量而阻止了TCP流量这就是区域传送失败的直接原因也是最容易让人忽略的地方。用Wireshark做链路定位时我一般会在显示过滤器里这样逐步筛选# 只看客户端发往分公司DNS的查询 ip.src 172.16.16.101 ip.dst 172.16.16.251 dns # 只看分公司DNS发往总部DNS的TCP同步包 ip.src 172.16.16.251 ip.dst 172.16.16.250 tcp.flags.syn 1 # 对比两段看请求是否被中途丢弃 dns.qry.name contains 你的应用域名每次过滤出来的包都要记录时间和seq号这些是答辩验收时证明「我确实分析了数据包」的实锤证据。注意TCP的SYN重传次数和时间间隔也值得看比如第一次SYN发出后1秒、3秒、7秒的重传能进一步确认是丢包而不是对端处理慢。4. 排查陷阱与避坑DNS区域传送故障最常见的翻车点4.1 陷阱一把DNS解析失败直接归因为应用服务器宕机现象用户在客户端ping应用服务器域名失败于是结论写成「应用服务器不可用」开始检查服务器进程和端口监听折腾一两个小时一无所获。原因混淆了「域名解析失败」和「IP不通」两个概念根本没有看第一步DNS查询的结果。解决任何应用访问故障的第一张抓包先从DNS报文看起响应码是SERVFAIL还是无响应、有没有返回A记录这两个细节直接决定了排查方向也是案例分析里第一个强调的判断点。4.2 陷阱二只过滤UDP 53流量把TCP 53的SYN全滤掉了现象抓到了分公司DNS和总部DNS之间的流量用udp.port 53过滤后只看到常规查询找不到任何异常结论写成「网络正常」。原因默认印象里DNS只用UDP忽略了区域传送这种要跑TCP的场景。解决过滤条件改成port 53而不加协议限定把所有53端口的TCP和UDP包都拉出来看。这个案例里最关键的第三个包就是TCP SYN单看UDP的话它就是隐形故障。血泪经验是凡是涉及DNS的排查都要同时看TCP 53主从DNS结构尤其如此。4.3 陷阱三不区分递归DNS与权威DNS的职责边界现象分公司DNS报SERVFAIL技术人员把矛头指向总部DNS「服务未启动」反复重启服务问题依旧。原因没搞清楚递归查询和权威查询的分工。总部DNS是应用服务器域名的权威服务器分公司DNS是从服务器它必须主动向总部拉取区域数据才能应答本地客户端的查询。把从服务器和主服务器的依赖关系忽略掉就会错误地在错误的位置找根因。解决画一张拓扑图标清楚谁是谁的上游谁依赖谁同步数据再决定每个节点的抓包位置。4.4 陷阱四只在客户端抓包却试图判断服务器端行为现象在客户端抓了长时间流量看到SYN重传但不知道服务器收没收到只能猜是服务器忙。原因单个位置的抓包只能证明「本机发出了什么、收到了什么」无法覆盖网络上其他节点的行为。解决遵循案例里「逐级镜像」的思路先抓客户端侧再抓DNS服务器侧必要时在路由器两侧同时抓。确认SYN到底有没有越过路由器的ACL这个断点判断必须在边界两侧各放一个嗅探点否则你永远在猜黑匣子里发生了什么。4.5 陷阱五修改ACL后不做区域传送回归验证现象把路由器配置改成允许TCP 53后客户端能解析域名了故障宣告解决但一个小时后区域数据同步失败告警再次出现。原因只验证了客户端解析结果没验证服务器间的区域传送是否成功。解决修复后不只是ping通域名还要在分公司DNS服务器上主动触发一次区域传送或等一个更新周期后查看serial number是否和主服务器一致。验证命令也很简单手动执行一次区域传送请求看TCP 53流量是否正常交互、SOA记录的序列号是否递增这步看起来多余实际能挡掉一大半配置残留问题。5. 验收与答辩怎么证明你真正解决了故障5.1 验收标准的设定这套方案是否真正闭环不要凭「用户说能打开网页了」来判断要有明确的四层验收步骤。第一层是客户端验证在工作站上用nslookup或dig查询应用服务器域名必须返回172.16.16.200响应码为NOERROR。第二层是链路验证在分公司DNS服务器上发起到总部DNS的TCP 53连接确认三次握手完成。第三层是区域传送验证对比主从DNS服务器的SOA序列号必须一致也就是数据完成了同步。第四层是回归抓包走一遍当时的抓包流程确认原来的TCP SYN包能收到SYN-ACK响应响应码从SERVFAIL变成正常解析结果这一步在答辩时最有说服力。# 手动触发一次区域传送并观察结果 dig 172.16.16.250 你的应用域名 axfr # 或者用nslookup验证客户端解析 nslookup 你的应用域名 172.16.16.2515.2 答辩演示清单如果这是一份课程设计答辩或项目汇报建议按时间线准备三张材料。第一张是抓包文件列表标清楚每个文件抓自哪个位置、覆盖了哪段时间与原始文件一一对应。第二张是故障分析链路图从客户端DNS查询到SERVFAIL响应再到分公司DNS的TCP SYN每一步都配上包序号和过滤时的显示过滤器表达式说明你是如何排除干扰项、逐步逼近路由器ACL这一根因的。第三张是修复前后对比表修前看到SERVFAIL与SYN超时修后看到NOERROR与TCP握手完成。这三张材料拿出来答辩老师或主管就基本不会再追问「你参与了多少」这类问题因为每一步都有数据支撑。5.3 一个答辩技巧汇报时不要把结论前置而是顺着排查顺序讲先讲发现SERVFAIL再讲排除应用服务器故障然后讲看到TCP 53 SYN的疑惑接着讲区域传送机制最后讲路由器配置确认。这个「还原现场」的过程本身就是技术含量所在比直接给结论更能体现你掌握了DNS协议和抓包分析能力。从那以后我每次做协议类故障排查都强制自己把每一个决策点对应到具体的包、时间戳和过滤器养成这个习惯之后写报告和答辩都轻松很多希望帮到你。本文还有配套的精品资源点击获取