简介《Wireshark数据包分析实战第3版》第10.5.2节“分析”内容被单独整理为PDF资源面向网络工程师、运维人员及Wireshark学习者演示一次典型的DNS解析故障排查全过程。案例从工作站172.16.16.101访问总部应用服务器172.16.16.200失败切入先后捕获DNS A记录查询、服务器故障响应、使用TCP 53端口连接中心DNS服务器的SYN数据包逐步剔除应用层与传输层疑点将问题锁定在分公司与总部DNS服务器的区域传送异常上最终发现中心办公室路由器仅放行UDP 53、阻断TCP 53的配置错误。读者可跟随完整的抓包、过滤与分层排查流程理解A记录查询机制、DNS区域传送原理、UDP与TCP协议切换条件、端口过滤对服务的影响并学会从异常数据包反推网络故障根源。资源为单个PDF文档压缩包仅644KB文件总数1份轻量便于快速查阅。目前已有327人学习。1. 一次DNS服务器故障排查从分类响应到ACL配置错误做网络排障的人都知道最怕的不是抓不到包而是抓了一堆包却看不懂它想说什么。这次要拆解的是一份来自《Wireshark数据包分析实战第3版》的经典案例分析——一个分支办公室的客户端无法访问总部应用服务器抓包结果显示第一个数据包就是DNS查询响应却返回了服务器故障Server Failure而最终定位到的根因竟是路由器上一条针对TCP 53端口的ACL配置失误。整个排查过程只用了三个捕获文件链路却从客户端一路延伸到了DNS服务器的区域传送。这套方案适合正在做网络协议分析课设、数据包分析实验、或者需要在答辩中展示“完整排障链路”的同学参考拿到的不仅是一个案例更是一条可复用的“从现象到根因”的分析方法论。2. 排障抓包方案设计链路接入点、镜像配置与最小化捕获策略在展开具体的包分析之前先把抓包方案的架构理清楚。这个案子里最值得学习的一点是抓包不是一次抓完而是分了三个阶段先在客户端侧捕获第一手通信再在分公司DNS服务器侧做端口镜像捕获最后判断核心问题是否出在总部DNS服务器这一端。每一阶段都有明确的“判断目标”这就是排障型抓包和普通抓包的本质区别。2.1 链路接入点选定镜像端口与串联TAP接入点的选择决定了你能否看到关键包。最常见的方式有两种一种是在交换机上配置端口镜像SPAN把目标端口的流量复制到分析端口另一种是用网络TAP设备物理串联在链路上进行分光。这两种方式各有利弊端口镜像不用中断业务但镜像端口本身的带宽和缓冲可能丢包TAP能保证完整复制但需要物理接入可能影响链路可用性。在这个案例中最初的捕获是在工作站172.16.16.101侧完成的捕获文件里只有两个数据包。从图10-30的描述来看这个捕获能完整看到工作站发出的DNS查询和收到的错误响应。要做到这一步通常的做法是把嗅探器接在分支办公室的接入交换机上并配置端口镜像指向工作站所在的接入端口镜像方向选both这样上下行流量都能看到。# 交换机上配置SPAN的参考命令以常见交换机命令风格为例 configure terminal monitor session 1 source interface GigabitEthernet0/1 both monitor session 1 destination interface GigabitEthernet0/10 end这里有几个设计要点需要说明。首先是镜像方向必须使用both而不是rx或tx因为我们既需要看到客户端发出的DNS查询也需要看到DNS服务器返回的响应只镜像一个方向就可能漏掉关键证据。其次是目的端口的选择不要使用一个正在承载业务的端口作为镜像目的地否则流量拥塞时可能丢包这在后续分析中会直接造成误判。最后是镜像会话的编号一个交换机上通常可以配置多个SPAN会话建议给每个排障任务分配独立的会话编号方便后期清理。2.2 捕获过滤器设计按会话范围收窄流量很多人在抓包的时候习惯“全部抓下来再说”这样做通常会在分析阶段被海量无关流量淹没。正确做法是先想清楚“我要证明什么问题”再设计捕获过滤器。在这个案例中第一阶段关心的是工作站到DNS服务器的通信所以过滤器应该围绕这两个IP展开。# tcpdump常用写法限定源和目标IP并过滤DNS端口 tcpdump -i eth0 -nn -s 0 host 172.16.16.101 and host 172.16.16.251 -w phase1_client.pcap # 第二阶段在分公司DNS服务器侧抓它与总部DNS服务器的通信 tcpdump -i eth0 -nn -s 0 host 172.16.16.251 and host 172.16.16.250 -w phase2_branchdns.pcap捕获过滤器的作用是在内核层面提前丢弃无关流量减少抓包文件体积和处理压力。与显示过滤器不同捕获过滤器无法用表达式组合复杂的协议条件但胜在效率高。这里的-s 0表示抓取完整包长度不做截断——分析DNS负载时如果只抓了包头而丢了DNS payload会直接导致你看不到查询的域名和响应码。关于端口过滤还有一个细节容易被忽略DNS查询正常情况下使用UDP 53但区域传送和TCP回退场景使用TCP 53。如果一开始就把过滤器写成port 53那么TCP和UDP都会被纳入能够覆盖大多数场景如果只写udp port 53那么案例中那个关键SYN数据包就会被漏掉后续排查就会走弯路。2.3 文件保存与轮转策略不要抓到手忙脚乱排障场景中抓包时长往往是未知的——你不知道问题什么时候复现也不知道需要对比多少轮流量。如果手动控制抓包启停很容易在问题还没发生时就结束了或者磁盘空间耗尽后导致后期数据缺失。这个案例虽然没有给出具体的抓包时长但从分析过程来看三个阶段各有一个pcap文件说明作者一开始就有意识地把不同阶段的捕获分开保存。# 按文件大小自动轮转保留最近5个文件 tcpdump -i eth0 -nn -s 0 -w phase_%Y%m%d_%H%M.pcap -C 50 -W 5 -Z root这里解释一下几个参数的含义。-C 50表示每个文件写到50MB时自动切换新文件-W 5表示最多保留5个文件超过后自动覆盖最早的文件防止磁盘写满-Z root表示抓包进程以root权限运行tcpdump丢弃权限后可能无法访问raw socket。这种轮转策略非常适合长时间无人值守的场景问题复现后直接取最后一个文件分析即可。配合-G 3600按小时轮转还能自动把文件名带上时间戳后期归档时就能清楚知道每个文件对应哪个时段。3. 基于Wireshark的DNS链路梳理从客户端查询到服务器故障响应现在进入实际的数据包分析环节。Wireshark的界面操作虽然直观但要真正利用它完成排障需要对显示过滤器、协议分层和响应码有深入理解。这一节会逐个拆解捕获文件中的关键包说明每个字段如何指向下一阶段的方向。3.1 客户端侧抓包分析先证明“是不是DNS的问题”整个案例的起点是客户端访问总部应用服务器失败但通信故障未必是DNS引起的——可能是网络不通、路由不可达、服务器本身宕机甚至可能是防火墙拦截。在客户端侧的第一个抓包文件里第一个数据包已经给出了答案工作站172.16.16.101发送了一个DNS查询请求解析应用服务器的A记录。# Wireshark显示过滤器定位DNS查询和响应 dns.flags.opcode 0 dns.qry.name contains appserver # 展开DNS协议层的关键字段判断 # - dns.flags.response 0 表示查询包 # - dns.qry.type 1 表示A记录查询分析这个包时需要注意几个要素。查询域名、查询类型A记录、目的地址172.16.16.251分公司本地DNS服务器、源端口通常是随机高端口构成了完整的请求上下文。客户端没有直接向公共DNS发起查询而是先经过分公司的DNS服务器这符合企业网络的正常解析路径。但紧接着的响应包就暴露了问题DNS服务器返回了“服务器故障”错误这是一个响应码为SERVFAIL值对应十进制2的响应包。3.2 解析SERVFAIL响应码错误的定位方向SERVFAIL是DNS协议中最值得玩味的响应码之一——它不像NXDOMAIN表示域名不存在那样明确而是泛指服务器在处理查询时遇到了内部错误或无法从上游获取答案。这个响应码的微妙之处在于它既可能是递归服务器自身故障也可能是上游权威服务器故障还可能是区域数据加载失败。在这个案例中返回服务器故障的是一个错误响应并且响应包中没有携带查询结果。这里需要补充一个辨析点正常的DNS响应即使返回NXDOMAIN也会在Answer区段之外保留Question区段并且可能有SOA记录在Authority区段而SERVFAIL通常只包含Question区段没有Answer记录。Wireshark中可以直接看到响应包每个区段的记录数如果Answer区段是0同时响应码是2那么基本可以认定查询在到达权威解析环节前就被中断了。# Wireshark中查看DNS响应的快捷方式 # 1. 点击响应包展开DNS协议层 # 2. 查看Flags字段中Response code: Server Failure (2) # 3. 查看Answers字段计数0表示无任何解析结果返回 # 4. 对比Question字段确认查询域名未被改写这个阶段的结论是客户端发起了DNS查询但分公司DNS服务器没有成功完成解析因此通信故障与DNS有关。判断的依据不是凭感觉而是响应码和Answer区段的组合证据。3.3 响应链路分析谁是递归服务器、谁是权威服务器确定通信故障与DNS有关之后下一个需要澄清的问题是“是谁的DNS解析失败”。案例中的分公司DNS服务器172.16.16.251在解析总部的应用服务器域名时返回了SERVFAIL那么这台服务器是如何获取总部域名解析结果的在递归解析模式下它可能向根服务器发起迭代查询如果它被配置为总部的从属DNS服务器Secondary DNS那么它依赖从总部主DNS服务器进行区域传送从本地zone文件中加载数据。这两种模式下的故障排查路径完全不同。递归模式的故障点通常在缓存、上游转发配置或根服务器可达性而从属模式的故障点则在于区域传送是否成功。案例中的提示给出了一个重要线索——分公司DNS服务器是总部DNS服务器的从属服务器这也解释了后续出现TCP SYN数据包的背景。Wireshark分析到这里排查方向已经从“DNS查询链路”转换到了“DNS服务器之间的数据同步链路”下一步需要调整抓包位置来验证。4. 定位主干链路故障SYN数据包与TCP 53端口的区域传送分析根据第一阶段的判断问题出在分公司DNS服务器上游。此时把嗅探器留在原地只改变端口镜像设置让分公司DNS服务器与外部通信的流量也被镜像到分析端口。新的捕获文件stranded_branchdns.pcap中除了之前看到的查询和响应外还多了一个额外的数据包——目标地址172.16.16.250目标端口53但协议是TCP。4.1 区分DNS的UDP与TCP场景超过512字节还是区域传送为什么DNS查询通常用UDP而这个包却是TCPWireshark分析中要避免一个常见的误区——看到TCP端口53就认为“DNS用了TCP”。在DNS的RFC规范中TCP确实作为UDP的补充存在但是分两种不同场景一种是响应超过512字节现代EDNS0环境下是1232字节时的回退机制另一种是区域传送时主从服务器之间的数据传输。# 在Wireshark中快速识别TCP上的DNS # 1. 显示过滤器输入tcp.port 53 # 2. 查看协议列标记为DNS的TCP包 # 3. 展开TCP载荷DNS层会以tcp.len 0形式出现 # 4. 查看包方向从分支DNS服务器(172.16.16.251)到总部(172.16.16.250)区分这两种场景的关键在于数据包内容。如果是响应过大回退通常会先出现UDP查询、UDP响应截断标志TC1、然后客户端发起TCP查询如果是区域传送第一个TCP包通常是SYN握手包且没有前置的UDP交互。案例中数据包是一个SYN目的端口53没有前置UDP过程——这基本可以排除响应过大的回退机制指向区域传送。区域传送的过程在协议层面对TCP端口的依赖很强主DNS服务器通过TCP连接将整个zone文件传送给从服务器。对于分公司的DNS服务器来说如果无法从总部服务器同步区域数据那么它永远不会知道总部应用服务器的IP地址也就无法回复任何客户端查询。4.2 SYN无响应意味着什么定位到包是否到达对端捕获文件中的SYN数据包没有得到响应。SYN包作为TCP三次握手的第一个包如果对端在线且服务正常会回复SYN-ACK如果没有响应可能的原因包括对端主机不可达、对端防火墙丢弃、对端服务未监听、或者中间路由器阻断。为了进一步区分需要判断SYN包是否到达了总部DNS服务器——如果能抓到总部DNS服务器的网卡流量那么到达与否一目了然。这个案子里有一个干脆的结论没有给出总部DNS服务器的流量捕获文件因为根本没有——SYN包从来没有到达服务器。这句话值得展开理解一下。如果我们的探针部署在总部DNS服务器的镜像口而该端口上没有出现任何来自172.16.16.251的SYN包那就说明问题不在DNS服务器本身而在两台服务器之间的网络路径上。结合分支机构到总部的链路结构最可疑的路由器就是承担两站点路由转发的中间设备。# 检查路由器ACL是否放行了TCP和UDP 53端口常见路由器配置风格 show access-lists # 期望输出示例关键行 # permit udp any any eq domain # 如果缺少以下这一行TCP区域传送必然失败 # permit tcp any any eq domain这里的配置检查逻辑是ACL中放行了UDP 53保证客户端DNS查询正常但没有放行TCP 53阻止了服务器之间的区域传送。最终原因正是中心办公室的路由器被配置成只允许53端口的UDP流量进入而TCP 53流量被阻止。这就是整个故障的根因。4.3 区域传送失败的连锁反应从根因到客户端故障的完整链路现在把整个故障链串起来看工作站访问应用服务器时提交DNS查询到172.16.16.251分公司DNS服务器是一个从属DNS服务器需要从总部主DNS服务器172.16.16.250同步区域数据由于路由器阻断TCP 53区域传送无法建立分公司DNS服务器的zone文件里没有总部应用服务器的记录它对客户端返回服务器故障。这是一条清晰且完整的功能链路每一步都有对应的数据包证据支撑。修改路由器配置后区域传送需要手动触发或等待刷新周期。从属DNS服务器通常会有刷新时间、重试时间和过期时间三个参数决定它何时重新尝试连接主服务器。修复ACL后通常可以主动在从属服务器上触发一次区域传送而不必等待自动刷新。# 在分公司DNS服务器上手动触发区域传送以常见DNS软件为例bind rndc retransfer appserver.example.com # 执行后查看日志是否显示转移成功 tail -f /var/log/messages | grep zone appserver参数说明retransfer命令的作用是强制从主服务器重新传送指定区域适合在修复网络问题后立即验证如果不手动触发可能需要等待zone的refresh周期通常在几小时到一天之间。区域传送成功后从属DNS服务器会持有总部的A记录客户端的解析请求随之恢复正常。这条链路最后的验证指标就是来自172.16.16.101的DNS查询能够收到一个包含A记录的响应包而不是服务器故障。5. DNS与抓包排查的典型误区现象对照、成因分析与操作修正抓包排障的过程中翻车很常见而且每次翻车之后回头去看总会发现是某些基础环节没做到位。这里整理了三个在这类DNS故障排查中最容易踩的坑每条都按现象、原因、解决来写可以直接对照排查。5.1 只关注UDP 53导致关键SYN包在手边被忽略现象客户端DNS查询失败抓包只看到UDP查询和SERVFAIL响应TCP包完全没出现在视野里。原因是很多人在Wireshark中下意识使用udp.port 53过滤器把TCP流量排除在外。解决方法是改用port 53同时保留UDP和TCP在查看数据包列表时兼顾TCP协议层的流量。DNS排障的正确姿势是两个传输层协议都要看服务器之间的区域传送和响应超时回退都发生在TCP层。5.2 SERVFAIL被误读为DNS服务器故障现象看到SERVFAIL响应就认为是DNS服务器宕机或服务异常直接重启DNS服务问题依旧。原因是SERVFAIL的含义是“服务器暂时无法提供答案”它可能是本机问题也可能是上游问题甚至可能是区域数据没有加载。解决方法是在Wireshark里对比多次查询的响应时间、响应码和Answer区段记录数再结合DNS服务器的日志确认是否为区域数据缺失。如果服务器本身有日志直接查看zone加载记录是最快的判断方式。5.3 SYN包没有响应时先检查服务器而不是检查路径现象分析到SYN无响应第一反应去总部DNS服务器上查看服务状态和端口监听但服务是正常的。原因是SYN包如果没有到达对端服务器一切正常毫无意义——链路路径上的任何一个ACL都可能把它丢弃。解决方法是先确认SYN包是否出现在对端网卡的抓包结果中如果没有顺藤摸瓜检查路径上的路由器ACL配置。这类问题中“服务器没有收到包”比“服务器出了问题”更常见因为ACL配置只放行UDP 53的情况屡见不鲜。6. 方案验收与答辩准备对照pcap文件证明区域传送恢复拿到一份完整的排障方案后如何向导师或评审证明“这个方案确实解决了问题”是关键的一步。尤其是在答辩场景中不能只说“改好了”最好用数据包级别的证据链条来展现分析过程。6.1 验收指标从SERVFAIL到A记录的完整回归验收的最终标准是客户端再次发起DNS查询后能够从172.16.16.251得到携带A记录的响应并且应用访问恢复正常。建议用以下几项指标作为验收依据第一在分公司DNS服务器重新抓包确认TCP 53的SYN包能够得到SYN-ACK响应证明区域传送路径已通第二在客户端侧重新发起DNS查询看到响应码从SERVFAIL变为NOERRORAnswer区段计数为1第三确认A记录的IP地址与总部应用服务器实际地址一致。# 客户端验证DNS解析是否正常的命令 nslookup appserver.example.com 172.16.16.251 # 预期结果示例 # Server: 172.16.16.251 # Address: 172.16.16.251#53 # Name: appserver.example.com # Address: 172.16.16.200配合Wireshark抓包用显示过滤器dns.flags.response 1 dns.qry.name appserver.example.com筛选出最终响应结果截图作为交付物附在方案后面。如果无法获得真实环境复现也可以用模拟项目的方式在实验环境里按照“客户端—分支DNS—路由ACL—总部DNS”的拓扑复现一遍重点演示故障从出现到修复的完整过程。6.2 答辩思路把“问题判断链路”讲透比堆技术细节更重要答辩时最容易出彩的地方其实是你的分析链路是否完整。在开场陈述阶段建议按“客户端故障现象 → DNS查询失败 → 服务器故障响应 → 定位到上游 → 发现SYN无响应 → 检查ACL → 修复验证”这个顺序展开每一步都给出对应的数据包截图或抓包字段。这能直观证明你在排障过程中有清晰的逻辑边界而不是无头苍蝇式地乱试。答辩中常被问到的一个问题是“为什么你会想到去看区域传送而不是直接检查服务器配置”。可以这样回答因为在分公司DNS服务器的抓包中看到SYN数据包且此前从未出现过UDP截断响应这排除了响应过大的回退场景区域传送是TCP 53流量的下一顺位解释。同时结合从属DNS服务器的角色判断区域数据同步一旦失败返回SERVFAIL是完全吻合的现象。6.3 复盘与沉淀用一次完整的抓包事故终结一个排查盲区在那次排障之后我养成了一个习惯遇到DNS相关故障会同时打开UDP 53和TCP 53的过滤器把服务器之间的区域传送作为默认怀疑项之一。这个方法的性价比极高因为TCP 53流量在普通的DNS监控中几乎不可见而它一旦受阻影响面是整个区域的解析能力。希望帮到你——下次遇到DNS解析异常时记得看看有没有一个被忽略的SYN包正在等你发现。本文还有配套的精品资源点击获取