上周处理了一个挺典型的报障财务部所有同事反映网页打不开但是OA系统、微信收发都正常。我的第一反应是DNS又出问题了登录核心交换机看了一眼结果发现网关的MAC地址表一片混乱好几台终端的ARP缓存里网关MAC指向了一个不存在的地址。这不是DNS的锅是有人在局域网里发起了ARP欺骗。这种把DNS和ARP混在一起排查的故障干网络的老手应该都遇到过——一个管“域名解析”一个管“局域网寻址”但出问题时的症状几乎一模一样都是“能上聊天下不了网页”或者“网时通时不通”。这篇文章我把DNS和ARP这两个协议放在一起拆开讲。先搞懂它们各自的工作原理再讲清楚它们结合之后会衍生出哪些安全风险最后给出可以直接落地的防护方案和排查思路。内容包括完整的域名解析流程、ARP请求应答细节、GNS3抓包实验参考、ARP欺骗和DNS劫持的攻击链分析以及从设备防护到终端加固的一整套实操。适合刚入门网络的新人也适合需要系统性梳理协议的运维和网安同事。1. 为什么DNS和ARP经常被放在同一次排查里1.1 一次真实故障网页打不开问题却出在ARP先说开头那个案例的结局。我登进核心交换机发现网关VLAN的MAC地址表项里有大量不正常的动态条目用arp -a在几台电脑上一看网关192.168.10.1对应的MAC居然有三种不同的地址。正常的应该是核心交换机的物理MAC如果出现了别的那就是有人伪造了网关的MAC把内网终端的流量都引到了一个错误的目标上。流量发过去之后没人转发自然打不开网页。但QQ、微信这类应用走的是长连接很多已经建立的会话还能继续维持所以看起来没完全断网。这个案例本身不复杂但它很好地说明了一个问题在局域网里很多表面上的“DNS故障”并真的是DNS服务器出了故障。凡是涉及“访问不通”“解析慢”“时通时不通”的问题排查路径上一定绕不开这两个协议。所以理解它们严格的职责边界比背一堆报文格式更重要。1.2 DNS做翻译ARP做找门牌一次访问背后的数据链路我用一个生活化的类比来说清两者的分工。你通过手机通讯录里存的“王大厨”这个名字拨通了一家餐厅的电话这个“名字到号码”的转换过程就是DNS做的事。当你知道了电话号码还得知道餐厅的实体地址和具体门牌号才能把外卖送到这个“地址到具体门牌坐标”的匹配过程就是ARP做的事。放到真实的网络通信里用户在浏览器输入www.example.com操作系统拿到的是一个域名需要先通过DNS解析出对应的IP地址。拿到IP之后数据包才能开始在网络中传输。但在以太网这种局域网环境里设备之间通信不能直接靠IP找到对方必须知道对方的MAC地址。这时就需要通过ARP将IP地址解析成MAC地址。如果目标是同一个网段的设备ARP解析的是目标主机的MAC如果目标是外网地址ARP解析的是网关的MAC然后把数据包交给网关转发。从端到端来看IP地址负责“从哪来到哪去”MAC地址负责“每一跳具体交给谁”。DNS负责在通信开始前把域名翻译成IPARP负责在每一段局域网里找到真正的物理目标。两件事看起来不在一个层面但在网络不通的实际表现上却互相影响所以排查时经常被放在一起。1.3 两者出故障时症状高度相似先分清楚再动手我总结了一下这两个协议出问题时最常见的三类症状几乎是重叠的完全打不开网页、部分网页能开部分不能开、网络延迟忽高忽低。区别在于症状特征更可能是DNS问题更可能是ARP问题完全打不开任何网页有可能DNS服务器挂掉有可能网关被欺骗所有外网流量中断部分网页能开部分不能开更常见域名解析失败但IP直连正常较少见除非攻击者选择性丢弃某些流量局域网内互相访问不通无关内网一般不用域名更常见ARP缓存错误导致二层通信失败网络延迟忽高忽低较少见更常见中间人截获流量再转发增加时延ping域名失败ping IP成功基本可以确定是DNS基本排除拿到报障先别急着改DNS按这个表先判断一下是“解析不到”还是“二层找不到路”能省下很多时间。2. DNS域名解析全流程与常见配置翻车点2.1 从输入域名到拿到IP中间发生了什么很多人对DNS的理解停留在“把域名翻译成IP”这一句话上但实际解析过程比这句话复杂得多。以www.example.com为例完整的解析路径是这样的浏览器输入域名后先查浏览器自身的DNS缓存。Chrome这类浏览器内部有单独的DNS缓存所以服务器改了解析记录之后浏览器没有立刻生效的情况很常见。浏览器没命中就查操作系统级缓存。Windows下是DNS Client服务在管用ipconfig /displaydns可以查看Linux下取决于用的是systemd-resolved还是别的缓存服务。操作系统的缓存也没有就查hosts文件。Windows在C:\Windows\System32\drivers\etc\hostsLinux在/etc/hosts。这一步很多人会忽略但排查问题时往往一查一个准。本地也没有记录就把请求发给网络配置里指定的DNS服务器这通常是你路由器下发的运营商DNS也可能是手动配置的公共DNS。收到请求的DNS服务器先查自己的缓存。有就直接返回没有就要代替客户端向上层发起查询。到了第5步之后才是真正展示DNS系统层级的关键部分。我下一小节单独说。2.2 递归查询和迭代查询DNS服务器的“跑腿”方式先明确两个概念。你电脑作为客户端向本地DNS服务器发起的是递归查询——意思是“你帮我查到这个域名的IP查不到你也别让我再去问别人了你负责到底”。而本地DNS服务器去问根DNS、顶级域DNS、权威DNS时走的是迭代查询——意思是“我有没有缓存没有的话我告诉你下一步该问谁你自己去问”。以www.example.com为例本地DNS服务器的处理流程请求根DNS服务器。根服务器说我不管具体域名但.com顶级域的服务器地址我给你。请求.com顶级域服务器。它说example.com的权威DNS服务器是ns.example.comIP是给到你。请求ns.example.com。权威服务器返回www.example.com的A记录IPv4或AAAA记录IPv6。本地DNS服务器把结果缓存起来再返回给你的电脑。整个过程里你的电脑只问了一次剩下的跑腿全由本地DNS服务器完成。这也解释了为什么本地DNS服务器性能不好或者出口网络差时即使你自己的宽带是千兆打开网页还是会觉得很慢——你只是在最后环节等它的结果而已。2.3 TTL与缓存为什么改了DNS解析记录还要等半天DNS记录里有个核心参数叫TTLTime To Live单位是秒表示这条记录能在缓存里存活多久。比如TTL是600那本地DNS服务器和各个层级的路由器、系统缓存会把这个结果保留10分钟。TTL设为3600缓存就保留1小时。实际工作中经常遇到这个场景网站换了服务器IP管理员把解析记录改了但是等了半小时用户还在访问旧IP。问题一般出在两处你改解析之前旧记录的TTL已经很长比如86400一天那么整个互联网上所有曾经查过这条记录的缓存服务器最长要一天之后才舍得丢弃旧值。用户本机的浏览器和系统缓存也没清掉。所以规范的做法是计划要做DNS解析变更时提前一天把TTL调小比如调到60或300让全球缓存快速过期等变更生效几天后再把TTL调回一个比较大的值。这不属于DNS和ARP协议原理的范畴但它是最影响实际体验的“原理外知识”。2.4 Linux和路由器上DNS配置的几个真实翻车点先看Linux。很多新手在/etc/resolv.conf里改了DNS重启网络之后发现被还原了。原因基本是现在的发行版几乎都在用systemd-resolved或NetworkManager接管DNS配置直接改/etc/resolv.conf会被系统服务启动时覆盖。正确做法要看发行版Ubuntu/Debian在/etc/systemd/resolved.conf里配DNS字段或者用nmcli改连接配置nmcli con mod Wired ipv4.dns 223.5.5.5 119.29.29.29 nmcli con up Wired如果你确实是想临时指定DNS做测试可以直接nslookup www.example.com 223.5.5.5把DNS服务器作为命令参数传进去绕过系统配置省心又干净。再看路由器。热搜里有一条“锐捷3063路由器DNS自动获取”这说的是路由器的WAN口DNS是自动从运营商获取的。一般建议如果路由器只是普通家庭或者小办公场景自动获取问题不大但如果内网有自建DNS服务或者你想统一管控内网的域名解析就要手动指定上游DNS甚至在内网专门架一台DNS转发服务器。还需要注意很多路由器默认开启了“DNS代理DNS Proxy”功能会把内网客户端的DNS请求接管由路由器本身代替向上游DNS发起查询。这个功能出问题时症状就是“内网的DNS服务器明明改了客户端却永远拿到的是代理服务器提供的解析结果”。华三防火墙的DNS代理同理。有次用户那边内网突然大面积解析失败排查下来发现是防火墙DNS代理的上游DNS配置成了已经停用的内网地址所有经由防火墙上网的客户端的DNS请求都被转发到了错误目标。当时在防火墙上关闭了DNS代理让客户端直接使用公共DNS问题立刻消失。2.5 公共DNS怎么选114、4.2.2.1、8.8.8.8的取舍学网络的人一定见过这几个地址114.114.114.114、4.2.2.1、8.8.8.8。它们确实都是公共DNS选择时关键看场景DNS归属特点适合场景114.114.114.114国内服务商国内访问快解析准确有防钓鱼功能国内办公、家庭首选223.5.5.5 / 119.29.29.29阿里 / 腾讯国内节点多解析稳定支持DoH/DoT国内备用配合主DNS使用4.2.2.1海外运营商Leonet海外访问优秀但国内使用延迟高海外服务器、跨境办公8.8.8.8Google海外解析能力强国内多数地区不稳定海外场景我个人的建议是国内环境主用223.5.5.5备选114.114.114.114两个都配上海外业务再考虑海外DNS。不要盲目跟风8.8.8.8你在国内用8.8.8.8每次域名解析都会先绕到海外去自然觉得网页加载变卡。2.6 判断DNS故障的实用命令不是只有ping很多人判断DNS故障只知道ping一下域名不通就说是DNS。这个习惯要改一下。更准确的步骤是# 1. 先确认域名能不能解析出IP nslookup www.example.com # 2. 指定一个公认可用的DNS来解析判断是否是本机配置的DNS有问题 nslookup www.example.com 223.5.5.5 # 3. 查看详细解析过程Windows用nslookupLinux可以用dig dig www.example.com trace # 4. 直接pingIP如果IP通但域名不通那就锁定是DNS问题 ping 93.184.215.14Windows系统上如果没有dig用nslookup和Resolve-DnsNamePowerShell就够了。Resolve-DnsName www.example.com -Server 223.5.5.5可以指定服务器查询排查时很好用。3. ARP协议原理局域网通信的真正“快递员”3.1 为什么需要ARPIP是逻辑定位MAC是物理门牌ARP全称Address Resolution Protocol地址解析协议它的作用是在以太网环境中通过已知的IP地址获取目标设备的MAC地址。为什么不能直接用IP通信因为二层交换机转发数据帧时根本不看IP头只看目的MAC地址。以太网帧头部没有IP字段它只有源MAC、目的MAC和类型字段。IP地址是逻辑概念MAC地址才是物理网卡上烧录的身份标识。你可以把IP理解成一个人的外号MAC理解成身份证号。你叫人外号可以但快递员要送到门口必须核对身份证号。所以每一台要接入以太网通信的设备都必须维护一张IP到MAC的映射表。这张表就叫ARP缓存表。3.2 请求与应答一次ARP解析的完整细节我们模拟一个场景主机A192.168.1.10要访问主机B192.168.1.20两台机器在同一网段。A的ARP缓存里没有B的记录于是A在局域网内广播一个ARP请求帧。源IP是192.168.1.10源MAC是A的MAC目的IP是192.168.1.20目的MAC是FF:FF:FF:FF:FF:FF广播地址。请求内容翻译过来就是“谁是192.168.1.20请告诉192.168.1.10我的MAC是xx:xx:xx:xx:xx:xx。”交换机这个广播帧转发给VLAN里的所有设备。所有设备收到后拆开看只有IP是192.168.1.20的主机B会认为这是找自己的其他设备直接丢弃。主机B收到请求后先把A的IP和MAC映射记入自己的ARP缓存表然后向A发送一个单播ARP应答帧。应答内容翻译过来就是“我是192.168.1.20我的MAC是yy:yy:yy:yy:yy:yy。”主机A收到应答后将B的IP和MAC映射写入自己的ARP缓存表然后开始正常发送数据帧。这里有三个细节值得记住ARP请求是广播ARP应答是单播。目标主机收到请求后会先把请求方的映射存入缓存。这就是所谓的“ARP免费学习”也是后面ARP欺骗能得手的关键。ARP报文直接封装在以太网帧里不经过IP层。抓包时看到ARP包是没有IP头部的。如果A要访问的是不同网段的地址比如公网IP那么它不会去ARP请求目标IP而是ARP请求网关IP对应的MAC。数据帧的目的MAC是网关的MAC网关收到后再做下一步转发。这个“逐跳解析”的特点在跨路由实验里最能体现。3.3 免费ARP既是自愈机制也是攻击武器免费ARPGratuitous ARP是指主机主动发送一个ARP请求请求的内容是自己的IP地址。比如设备拿到IP地址后会发一个广播“我是192.168.1.10我的MAC是xx:xx:xx:xx:xx:xx谁有冲突”这个广播有两个实际作用检测IP地址冲突。如果局域网里已经有别的设备用了这个IP那台设备会回复一个ARP应答启动网卡时会提示IP冲突。让局域网内所有设备刷新ARP缓存。收到这个广播的设备不管自己是不是请求目标都会把发送方IP和MAC的映射更新到缓存里。这意味着任何人只需伪造一个免费ARP包就能让全网设备的ARP缓存迅速更新——这就是ARP欺骗最基础的实现方式。3.4 ARP缓存与老化为什么配置没变网络却突然不通每台设备里的ARP缓存表并不是永久生效的它有一个老化时间。Windows默认一般是20到45秒Linux默认约60秒Cisco交换机默认约300秒。表项到期后会被删除下一次通信时需要重新发起ARP请求。这个机制本身能保证网络变化后设备及时更新记录但也带来了一个体验问题如果局域网里的网关做了主备切换可能短时间内有设备还是拿着旧的网关MAC去发包导致业务闪断。解决办法是主备切换后在核心设备上发一个免费ARP全网刷新缓存。很多高可用方案VRRP之类会在状态切换后主动发送免费ARP就是这个原因。还有一个小技巧排查内网问题时Windows下先ping一下目标IP再用arp -a查看缓存就能确认通信是否真的转发到了目标设备。如果想把重置的缓存重新清理用arp -d # Windows删除全部ARP表项Linux下是ip neigh flush all。3.5 用GNS3复现跨路由通信中的数据帧变化GNS3是验证网络协议行为的好工具我拿它搭过一组拓扑两台路由器R1、R2直连R1的G0/0接PC1192.168.1.10/24R2的G0/0接PC2192.168.2.10/24两台路由器之间用G0/1互联地址分别192.168.12.1和192.168.12.2。PC1 ping PC2同时在PC1的接入链路和R1-R2链路两端抓包可以清楚地看到ARP的逐跳解析。PC1发出第一个包之前它会先检查目标192.168.2.10是否和自己同网段发现不是于是需要找到网关192.168.1.1的MAC。抓包序列第一条一定是ARP广播请求“谁是192.168.1.1”R1的G0/0接口应答PC1拿到了网关的MAC才发出ICMP请求包。这个ICMP包的目的MAC是网关的MAC源IP和目的IP分别是PC1和PC2IP头全局不变。R1收到这个帧拆开后发现目的IP是192.168.2.10查路由表匹配到出接口G0/1下一跳是192.168.12.2。此时R1会先查看自己的ARP缓存是否有192.168.12.2对应的MAC如果没有就再发一个ARP请求拿到的MAC作为出接口数据帧的目的MAC。所以同一个ICMP请求在PC1到R1这一段和R1到R2这一段帧头里的源MAC、目的MAC是完全不同的源IP和目的IP则始终一致。这个细节搞懂了就理解了为什么说“ARP是局部的IP是端到端的”。4. 局域网流量安全ARP欺骗与DNS劫持的真实攻击链4.1 ARP欺骗为什么能得手ARP协议从设计之初就没有考虑过身份认证攻击者可以随意构造ARP报文把自己的MAC地址映射到别人的IP地址上然后广播出去。局域网里所有收到这个报文的设备都会信以为真更新自己的ARP缓存。最常见的两种欺骗场景欺骗网关。攻击者伪造一个“网关IP对应攻击者MAC”的免费ARP包内网所有终端的ARP缓存里网关IP的MAC全部变成攻击者的MAC。终端发往外网的流量全部先到达攻击者机器攻击者再决定是丢弃还是转发。丢弃就是全网断网转发就是标准的中间人窃听。欺骗目标主机。攻击者伪造“目标主机IP对应攻击者MAC”的ARP应答发给受害者。受害者想访问目标主机时实际把帧发给了攻击者。在Wireshark里如果看到短时间内出现大量源IP地址不同但SRC MAC不变的ARP应答包基本就是攻击流量的特征。防御上最直观的办法是静态ARP绑定但真正根治要靠交换机的DAI机制后面第5小节详细说。4.2 DNS劫持的常见入口配置篡改、透明代理、公共WiFiDNS劫持和ARP欺骗经常被组合使用。单独看DNS劫持常见入口有四个DHCP下发的DNS被篡改。攻击者架设一个伪造的DHCP服务器抢先给终端分配IP和网关DNS地址被指到一个攻击者控制的服务器上。终端不查上层DNS时所有的域名解析结果都在攻击者手里。路由器DNS被篡改。家用或者小办公室路由器密码弱被攻击者登进去之后把DNS改成恶意服务器。这种情况在公共WiFi和酒店网络里不少见。热搜里“打开网页找不到DNS地址”“电脑DNS服务器无法访问”很多时候就是路由器层面的配置被改了。防火墙/路由器的DNS透明代理逻辑。前面提到的华三防火墙DNS代理就是一个典型——管理员本来想集中管理DNS请求但如果代理逻辑不符合预期反而会让客户端得不到正确解析结果。系统本机hosts或DNS被改。某些软件安装时会顺手改掉系统DNS或hosts文件排查时先查这两处最稳妥。DNS被劫持之后的危害不仅是打不开网页。攻击者可以把银行的域名解析到钓鱼服务器IP用户在浏览器里看到的是熟悉的域名实际访问的却是一个伪造的服务器。这也是为什么我一直强调光靠URL没锁没杆子安全还得靠HTTPS。4.3 SSL/TLS只能兜底CVE-2016-2183这类扫描结果说明了什么热搜里有一条“ssl/tls协议信息泄露漏洞(cve-2016-2183)【原理扫描】”这其实是一个针对SSL/TLS协议中使用3DES算法时产生的一个漏洞被大量安全扫描器扫出来。它的意义在于即使你把DNS和ARP防御做得滴水不漏通信链路上如果使用了脆弱的加密算法窃听者还是可能解密你的流量。CVE-2016-2183本质上是生日攻击在3DES上的体现3DES的密钥有效强度实际只有约112位当加密数据量足够大时破解难度会大幅降低。实际扫描中看到“原理扫描”四个字意味着扫描器只是检测到服务端支持了易受影响的3DES密码套件不必然代表已经被攻击利用但它是一个明确的整改提示在SSL/TLS服务端配置里禁用弱密码套件。具体到Nginx服务器可以在配置里限制ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on;禁用TLSv1.0/1.1禁用3DES、RC4、CBC类弱套件。DNS保证你访问的是正确的服务器ARP保证流量不被引到错误设备TLS/SSL保证即使流量被截获也难以解密。三者缺一不可。4.4 攻击者如何把ARP和DNS串成一条链最高段位的局域网攻击是先把ARP欺骗做成中间人再在中间人的链路上做DNS劫持。攻击者先用伪造的ARP广播让自己成为受害者访问外网的“合法网关”。受害者的所有流量都先经过攻击者的机器。此时攻击者在自己的机器上架一个假DNS服务对所有DNS请求返回一个伪造的IP——比如把受害者的网上银行域名解析到一个钓鱼网站的IP。受害人完全无感知因为他在浏览器里输入的还是正确的域名浏览器的地址栏显示的也是对的网址只是背后的链路已经被完全掌控了。这就是为什么只做静态ARP绑定、不做DNS验证依然不够。防这类组合攻击的思路必须是“链路层传输层”双管齐下链路层用DAI防止ARP欺骗传输层用加密DNS和HTTPS保证即使被截获也无法篡改内容。5. 防护与排查实战让DNS和ARP问题一眼现形5.1 接入层必做DHCP Snooping与DAI如果你的环境里交换机支持DHCP Snooping和DAIDynamic ARP Inspection优先部署这两个它们是防ARP欺骗最有效的手段。DHCP Snooping的作用是监听DHCP交互过程建立一个“IP-MAC-端口-VLAN”的合法绑定表。它有一个信任端口概念面向DHCP服务器的端口设为信任端口面向终端的端口设为非信任端口。只有信任端口才能收到DHCP服务器分配地址的应答从非信任端口收到的DHCP服务器报文一律丢弃从源头上杜绝了伪造的DHCP服务器。DAI基于DHCP Snooping表来校验ARP报文。交换机收到ARP报文时会检查报文中“源IP-源MAC-端口-VLAN”的组合是否合法。不匹配的直接丢弃同时可以通过日志记录攻击来源。核心配置片段ip dhcp snooping vlan 10 ip dhcp snooping interface GigabitEthernet1/0/1 ip dhcp snooping trust interface GigabitEthernet1/0/2 ip dhcp snooping limit rate 10 ip arp inspection trust interface GigabitEthernet1/0/3 ip arp inspection trust注意DAI开启后如果某个端口没有对应的DHCP Snooping绑定信息ARP报文会被直接丢弃可能导致合法的静态IP设备无法通信。所以网络中如果有手工配置静态IP的打印机、服务器需要提前手工添加对应的绑定ip dhcp snooping binding 52:54:00:12:35:02 vlan 10 192.168.10.50 interface GigabitEthernet1/0/35.2 终端与网关的静态绑定没有DAI的环境退而求其次做静态ARP绑定。最稳妥的方式是在终端上绑定网关的MAC# Windows管理员命令行 netsh interface ipv4 show interfaces # 先查到网卡的 Interface Index netsh interface ipv4 add neighbors 12 192.168.1.1 aa-bb-cc-dd-ee-ffLinux下ip neigh add 192.168.1.1 lladdr aa:bb:cc:dd:ee:ff nud permanent dev eth0注意静态绑定在数量较多的网络里维护成本很高而且换网关时所有终端的绑定都要跟着改所以这只适合终端数量少或对安全要求极高的场景。更靠谱的方案还是靠交换机侧防护。如果使用的是华三防火墙这类设备在配置界面找到DNS代理选项并将其关闭同时确认内网终端的DNS指向正确。这个操作在排查“内网客户端DNS解析被统一改写”的场景下很有效。5.3 加固DNS从本地配置到加密DNSDNS本身是明文协议默认情况下查询路径里的任何环节都可以被监听和篡改。现在比较成熟的加固方向是加密DNSDNS over HTTPSDoH将DNS查询包装进HTTPS请求里走443端口攻击者看不出你在解析哪个域名也无法篡改解析结果。DNS over TLSDoT专用853端口用TLS加密DNS报文配置更轻量。DNSSEC对DNS记录做数字签名客户端可以验证记录合法性防止中间人伪造解析结果。国内公共DNS基本都支持DoH和DoT阿里的DoH地址是https://dns.alidns.com/dns-query腾讯的DoH地址是https://doh.pub/dns-query。浏览器层面Chrome/Firefox都可以直接配置安全DNS。Windows 11系统设置里也有“加密DNS”的开关打开后指定DoH即可。在服务器场景可以在本地部署dnsmasq或unbound作为转发器再向上游走DoT/DoHserver: do-not-query-localhost: no forward-zone: name: . forward-ssl-upstream: yes forward-addr: 223.5.5.5853 forward-addr: 119.29.29.29853这样的配置下本机所有DNS查询都通过TLS加密发送给上游即使所在网络部署了DNS劫持也没法轻易篡改解析结果。不过在配置过程中要注意unbound和系统解析器的兼容性在/etc/resolv.conf中指定nameserver 127.0.0.1时要确认系统的缓存服务不会和unbound冲突否则可能出现DNS查询偶尔超时的情况。5.4 从“打不开网页”到定位问题完整排查链路我在多次故障处理中总结了一套比较高效的排查顺序分享出来先确认是单点问题还是全网问题。找两三台不同位置的终端试一下如果都故障继续如果只有一台先查那台的配置。用IP直连测试。比如ping 223.5.5.5如果通了说明二层到出口链路基本正常重点转向DNS。用nslookup www.example.com检查域名解析。如果解析失败再用nslookup www.example.com 223.5.5.5指定公共DNS重试。指定公共DNS正常、默认DNS失败说明问题在DNS配置上两个都失败怀疑出口或者DNS服务器本身。查看本机ARP缓存。arp -a看网关IP的MAC是否正常如果和上一次记录不一样立刻到交换机上查对应IPP端口下的真实MAC确认是否有伪造。在网关/防火墙上检查DNS请求日志看是否有异常的大量DNS查询判断是否中了劫持后门在频繁和外联服务器通信。如果以上都查完没问题最后怀疑ARP欺骗。到交换机上看端口流量统计和DAI日志这是最直接的证据来源。5.5 日常巡检与我的几个小习惯说几个我自己的习惯不一定适合所有场景但确实帮我省了不少事每个季度在核心交换机上执行一次display arp | include Internet之类的命令核对网关、服务器等重要IP的MAC是否稳定。华三和华为设备都有类似命令巡检时顺便把日志导出来保存。给监控系统加上DNS解析延迟的检测项不只是ping通不通还要看域名解析耗时。解析耗时曲线突然拉升往往意味着链路被插入了额外转发环节。对DHCP地址池做每日巡检发现每天同一台终端频繁重传DHCP请求可以考虑是否有人在设备上做ARP欺骗导致网络中断。不要轻易在局域网里部署过多的“上网行为管理”设备很多行为管理器本身就是基于中间人方式工作容易和ARP或者DNS透明代理机制冲突造成各种疑难杂症。根据我自己处理过的这类问题很多“DNS上不了网”故障最后查下来是ARP层面或者上游DNS代理的问题所以在日常运维中把这两个协议放在一起巡检、一起定位比抓着一个疯狂换DNS地址要高效得多。遇到这类问题先把排查链路按我上面写的方式走一遍往往十分钟内就能出结果。