开局先聊一个特别常见的场景电脑突然打不开网页了你顺手ping了一下域名发现解析出来的IP压根不对或者公司局域网一到下午就卡成PPT查了半天不是带宽问题最后发现有人拿着工具在局域网里发伪造的ARP应答包。DNS和ARP一个负责把域名“翻译”成IP一个负责把IP“翻译”成MAC地址它们是网络通信里最基础也最容易被忽略的两个协议。但恰恰是这两个基础协议在真实运维中制造了大量让人头疼的问题。这篇文章想把我这些年在这两个协议上踩过的坑、做过的实验、排查过的故障梳理一遍从原理讲到配置再从配置讲到安全机制。不管是刚入行的网络小白还是被DNS劫持、ARP欺骗折磨过的一线运维应该都能从中找到点可用的东西。1. 内容整体设计与思路拆解为什么这件事值得单独拿出来写很多人觉得DNS和ARP是老掉牙的知识点教科书上翻一翻都有。但问题是教科书讲的是“标准流程”实际环境里跑的却是“变形流程”。比如DNS解析标准流程是客户端问递归服务器递归服务器问根域、顶级域、权威服务器最后返回结果。但实际环境里有DNS缓存、有DNS代理、有运营商劫持、有hosts文件干扰、有多级DNS转发任何一个环节出问题表现都是“网页打不开”但原因天差地别。ARP同理标准流程是广播请求、单播应答、缓存表维护。但真实局域网里有ARP攻击、有IP冲突、有交换机端口安全策略、有VRRP虚拟IP的ARP响应、有无线终端的快速漫游ARP更新。你手上没有一套清晰的排查思路光看现象根本无从下手。所以我写这篇文章的思路是先讲清楚两个协议的核心机制再落到具体配置和故障排查最后用安全攻防的角度把ARP欺骗和DNS劫持这两大局域网流量安全风险串起来。这样从机制到实操到安全是一条完整的认知链路。它的核心价值在于让你知道“正常时它该干什么”你才能判断“异常时它到底哪里出问题了”。另外一个必须说明的思路是DNS和ARP不是孤立的。你访问一个网站先有DNS解析得到IP然后路由决定下一跳最后在局域网里靠ARP找到目标MAC地址。表面上两个协议各管一段实际上是一条链路的前后半程。所以把它们放在一篇文章里分析不是为了凑标题而是因为排障时本来就是一条线顺下来的——用户说“网不通”你要先查DNS通不通再查ARP表对不对最后才能定位到具体环节。2. 核心细节解析与实操要点两个协议到底是怎么工作的2.1 DNS解析的完整过程从域名到IP的七步接力先看一张DNS解析的完整链条。假设你在浏览器输入 www.example.com系统是怎么知道该访问哪个IP的第一步浏览器先查本地DNS缓存。Windows下可以用 ipconfig /displaydns 查看里面存着历史上解析过的记录。缓存命中的话整个过程直接结束这是最快的路径。第二步缓存没命中系统读取 hosts 文件。Windows在 C:\Windows\System32\drivers\etc\hostsLinux在 /etc/hosts。这里要注意hosts文件的优先级高于DNS服务器配置所以很多恶意软件喜欢改hosts做域名劫持排查解析异常时第一个就要看它。第三步hosts没有才轮到系统的DNS客户端解析器把请求发给网络配置里指定的DNS服务器。这个服务器通常叫递归解析器或本地DNS服务器可能是运营商的、是114这样的公共DNS、是自己公司内网的DNS服务器。第四步递归解析器收到请求后如果它自己有缓存就直接返回没有的话它去问根域名服务器。根域名服务器不直接告诉你example.com的IP它告诉你“ .com 由这些顶级域服务器负责你去问它们”。第五步递归解析器去问.com顶级域服务器得到“example.com 的权威DNS服务器是这些”的答复。第六步递归解析器向example.com的权威DNS服务器发起查询拿到具体的A记录或AAAA记录也就是IPv4或IPv6地址。第七步递归解析器把结果缓存一段时间同时把最终IP返回给你的电脑。解析器本身也会把这个结果缓存起来下次访问就快了。这个过程中牵扯到两个概念递归查询和迭代查询。你向本地DNS服务器发起的查询是递归查询——意思是“你必须给我一个最终答案”。本地DNS服务器向根域、顶级域、权威域的查询是迭代查询——意思是“我不直接给你答案但我告诉你下一步该找谁”。理解这个区别很关键因为排查DNS慢的时候你要能判断是递归环节慢还是迭代环节慢。2.2 ARP协议的工作机制IP地址到MAC地址的广播问答DNS解决了“域名对应哪个IP”的问题但真正在局域网里转发数据帧时靠的是MAC地址。ARPAddress Resolution Protocol就是干这件事的通过已知的IP地址解析出对应的MAC地址。它的工作流程特别简单。主机A要和主机B通信先查自己的ARP缓存表你们在命令行敲过的 arp -a 查的就是这张表。里面有IP地址和MAC地址的对应关系。如果表里有记录直接用没有记录主机A就向局域网里发一个广播帧谁的IP是192.168.1.100请把你的MAC地址告诉我。这个广播帧会被局域网里所有主机收到但只有IP匹配的那台主机主机B会回应一个单播帧我是192.168.1.100我的MAC地址是AA:BB:CC:DD:EE:FF。主机A收到应答后把这条记录写进ARP缓存表然后封装数据帧开始通信。注意几个细节。第一ARP请求是广播的ARP应答是单播的。但也有一种特殊情况叫免费ARPGratuitous ARP主机开机或IP地址变更时主动广播自己的IP和MAC映射目的是告诉别人“我来了如果有冲突赶紧告诉我”同时让交换机更新自己的MAC地址表。第二ARP表是有老化时间的。Windows系统默认的ARP缓存超时时间在2到10分钟之间动态条目超过这个时间没被使用就会被删除下次通信需要重新解析。这就解释了为什么你ping同网段的一台机器第一次ping会慢一下因为要先走ARP解析后面就快了缓存命中了。第三ARP只工作在同一个网段内。跨网段通信时你请求的是网关的MAC地址而不是目标主机的MAC地址。数据帧先发给网关由网关负责转发到目标网段。这是一个很多新手容易混淆的点。2.3 DNS和ARP在数据链路中的衔接关系把两个协议串起来看。你访问www.example.comDNS解析出IP 93.184.216.34。然后系统判断这个IP跟自己不在同一个网段于是把数据包交给默认网关。但要把数据包发给网关必须知道网关的MAC地址这时候ARP登场解析网关IP对应的MAC地址数据帧封装完成后从网卡发出去。所以你看DNS解析是“逻辑地址到逻辑地址”的映射ARP解析是“逻辑地址到物理地址”的映射。两者衔接的节点就是那张已经写满IP和MAC对应关系的ARP缓存表。这也是为什么排查网络不通时先ping网关再ping域名看看是ARP解析问题还是DNS解析问题——哪个环节失败了报错信息一目了然。3. 实操过程与核心环节实现从配置到抓包手把手走一遍3.1 Linux下配置DNS的完整过程与“重启还原”问题热搜词里有一个很典型的场景“linux修改dns后重启网络还原”。这说的是很多人在/etc/resolv.conf里改了DNS地址重启网络服务之后发现又被改回去了白改一场。原因在于很多Linux发行版的网络管理栈会自动覆盖resolv.conf。具体来说如果你用的是NetworkManager管理的网络它会根据DHCP获取到的DNS信息动态生成resolv.conf。你手动在文件里改了nameserverNetworkManager一刷新又会把DHCP下发的DNS配置写回去。正确的改法取决于你的系统版本和网络管理方式。CentOS 7及以前的版本修改 /etc/sysconfig/network-scripts/ifcfg-eth0具体文件名看你网卡名在里面加一行 DNS1114.114.114.114然后重启网络服务。CentOS 8、Rocky Linux、Ubuntu 18.04以上版本推荐用nmcli命令nmcli con mod 你的连接名 ipv4.dns 114.114.114.114 8.8.8.8然后 nmcli con up 你的连接名 生效。如果你只是临时测试直接修改 /etc/resolv.conf 是没问题的但重启网络或NetworkManager刷新后会被还原。所以排查“DNS配置总变”的问题第一反应是查看是不是NetworkManager在管这个接口的DNS而不是反复去改resolv.conf。再顺便说一个常见误操作很多人改完DNS后喜欢重启网卡或者重启网络服务这个动作其实没必要。用 nmcli 或 systemctl restart NetworkManager 都会导致连接重连正在跑的连接会短暂中断。如果只是改DNS可以用 nmcli con mod 配合 nmcli con up 让配置生效别动不动就重启整个网络栈。3.2 Windows Server 2016上配置DNS服务正向查找区域与转发器Windows Server 2016作为内网DNS服务器是很常见的用法。配置步骤不算复杂但有几个关键点容易出错。安装DNS服务角色后打开DNS管理器展开服务器节点找到“正向查找区域”右键新建区域。区域类型选择“主要区域”区域名称填你负责的域名比如 internal.com。之后会创建对应的区域文件。新建区域完不算完还要在区域里新建主机记录A记录。右键区域选择“新建主机”名称填主机名比如wwwIP地址填对应的内网IP勾选“创建相关的指针PTR记录”可以同时生成反向查找记录。配置完成后最关键的一步是设置转发器。内网DNS服务器一般不做根服务器迭代查询也做不了因为你没有根区的权威数据而是把外部域名的解析请求转发给上游DNS服务器。在服务器节点上右键属性找到“转发器”添加公共DNS地址比如114.114.114.114或8.8.8.8。这样内网机器把DNS指向这台Windows Server内网域名由它直接解析外部域名由它转发给公共DNS。这里有个排障经验如果你配置了DNS服务器但客户端解析不了外网域名先查两件事。第一客户端能不能ping通DNS服务器的IP第二DNS服务器的转发器配置是否正常可以在DNS服务器上直接 nslookup www.baidu.com 试试看。如果服务器自己能解析但客户端不行多半是客户端没把DNS指向服务器或者防火墙挡了UDP 53端口。3.3 华三防火墙关闭DNS代理与锐捷路由器DNS自动获取问题热搜词里提到了“华三防火墙关闭dns代理”。这个场景在企业网里很典型——防火墙开启了DNS代理功能所有客户端的DNS请求都会被防火墙拦截并代问好处是可以通过防火墙的策略控制DNS流量坏处是一旦代理功能异常全网的域名解析都会挂掉。华三防火墙关闭DNS代理的操作路径是进入系统视图执行 dns proxy enable/disable 命令。注意不同版本Comware V5/V7的命令略有差异V7版本是 dns proxy enable关闭就 no dns proxy enable或者执行 undo dns proxy。关闭之后防火墙就不再拦截DNS请求了客户端直接访问上游DNS服务器。做这个操作前先想清楚如果你关掉DNS代理那么防火墙安全策略里就需要放行UDP 53/TCP 53的流量否则客户端连外网DNS的解析请求会被防火墙拦截。很多人在防火墙上关了代理但忘了放行DNS流量结果全网解析全部失败这就是典型的“改配置时没考虑前后依赖”的坑。锐捷路由器“DNS自动获取”的问题也很常见。家用级的锐捷路由器默认开启DHCP服务给终端分配IP的同时也下发DNS地址默认选的是“自动获取上游DNS”即从运营商拨号链路里自动获取。如果你发现内网终端解析域名很慢或者解析到错误地址可以把DNS模式改成“手动指定”填写公共DNS地址。改完后别忘了重启DHCP服务或重新拨号确保客户端重新获取地址时拿到的是新DNS配置。3.4 GNS3中双路由器抓包分析ARP与IP数据转发GNS3做网络实验是特别好的学习方式。热搜词里有一个具体实验两个路由器分别连接主机分析IP数据转发报文和ARP协议过程。这个实验做通了你对ARP在跨网段通信中的角色会有非常直观的理解。实验拓扑很简单路由器R1的e0/0接主机A192.168.1.1/24R1的e0/1接R2的e0/0两个接口都是10.0.0.0/24网段R2的e0/1接主机B192.168.2.1/24。三层互联主机A要访问主机B。用Wireshark在主机A接入的交换机口上抓包在主机A上执行 ping 192.168.2.2。你会看到这样的数据流第一组主机A发ARP广播问192.168.1.1网关的MAC地址。因为192.168.2.2和A不在同一网段A知道要把数据包交给网关。第二组R1回应ARP单播告诉A自己的MAC地址。然后A把ICMP请求封装在以太网帧里目的MAC是R1的MAC目的IP是192.168.2.2。第三组R1收到数据帧拆掉以太网头看目的IP查路由表发现下一跳是10.0.0.2R2。此时R1查看自己的ARP缓存如果没有R2的10.0.0.2的MAC映射就再发一个ARP广播——这次是发在R1和R2之间的网段上。第四组R2回应ARPR1重新封装数据帧目的MAC改成R2的MAC从e0/1发出去。第五组R2收到后发现目的IP是192.168.2.2查路由表发现直连网段于是再发ARP广播询问主机B的MAC地址拿到之后封装帧发给B。这个实验抓包看下来你会深刻理解一个点数据报文每经过一个三层设备源IP和目的IP是不变的但源MAC和目的MAC一直在变。每一跳都要重新做一次ARP解析。而主机A上看到的ARP表只有网关的MAC看不到主机B的MAC——因为对于A来说B根本不在同一链路层域里。3.5 接口下ARP地址怎么查IP地址的上线和下线时间这个热搜词大概率来自网络运维场景想在交换机上查看某个IP对应的MAC多久前上线、多久前下线。不同厂商设备的命令不一样。华为交换机上先进接口视图执行 display arp interface GigabitEthernet 0/0/1可以看到该接口下的ARP表项其中Age字段就是老化计时显示这条ARP条目已经存在了多少秒。如果要看更详细的信息包括MAC地址上线时间用 display arp verbose输出的信息里有该ARP表项创建的时间。思科交换机上命令是 show ip arp带接口参数可以过滤show ip arp interface GigabitEthernet 0/1。输出里的Age字段表示这条表项的存活时间。如果看到“-”表示该条目是静态的相当于永久存在。排查IP冲突时这个字段很管用——如果发现同一个IP对应了多个MAC地址再看Age字段就能判断哪条记录是新的。华三设备上用 display arp 命令输出类似。如果要在接口下看用 display arp interface GigabitEthernet 1/0/1。另外华三支持 display arp timer 来查看ARP老化时间设置默认是20分钟。经验之谈排查ARP故障时手动清掉可疑的ARP缓存再观察比直接在表里对比更高效。华为交换机上执行 reset arp all 可以把动态ARP表项全部清除设备会重新学习。思科是 clear arp-cache。清完后再查看动态表项会重新刷新如果某个IP对应的MAC仍然不对说明攻击源还在持续发送伪造ARP包这时候就要考虑在接入交换机上做防御了。4. 常见问题与排查技巧实录DNS与ARP的疑难杂症速查4.1 电脑DNS地址变成fe80::1%11是什么情况热搜词里那个“DNS 服务器 ...... : fe80::1%11”很有代表性。fe80开头的是IPv6链路本地地址后面的%11是Windows里表示网卡编号的zone ID。出现这种情况说明你的网卡通过DHCPv6或路由器通告RA获取到了IPv6的DNS配置其中网关设备把自身的IPv6链路本地地址作为DNS服务器地址下发给了终端。这个配置本身不算错误很多家用路由器的IPv6 DNS就是通告自己的链路本地地址。真正的问题是这台设备的IPv6 DNS服务可能根本不好使或者配置了IPv6优先但IPv6链路实际不通导致解析超时。解决办法也很直接不用动IPv6直接在IPv4的DNS配置里手动指定一个可靠的DNS比如114.114.114.114或8.8.8.8。如果确实想完全禁用IPv6 DNS可以在网卡属性里把IPv6协议取消勾选不推荐全局禁用影响面太大或者在路由器上关闭IPv6 DNS通告功能。4.2 cloudcom dns error 1006和Lets Encrypt验证报错“ce: -90100 cloudcom dns error 1006”这类报错通常出现在使用华为云CloudDNS时API调用返回异常1006一般是权限校验失败或区域参数不匹配。排查思路是先确认API凭证有没有过期再看调用的区域Region跟域名所在的区域是否一致最后看域名是不是在托管区里存在。“during secondary validation: dns problem: networking error looking up a for”这个报错来自Lets Encrypt证书申请过程。申请证书验证域名所有权时Lets Encrypt的服务器反向查询你的域名A记录发现查到了多个IP或者查询超时。处理方式通常是确认域名的A记录配置正确且是公网可达的IP确认TTL不要设太短至少300秒以上确认没有配置多条有冲突的A记录。还需要检查防火墙是否限制了外部对DNS查询的访问有些云安全组默认只放行了TCP/UDP 53的入方向流量但Lets Encrypt走的是UDP 53标准查询如果被限速策略拦截就会报networking error。4.3 打开网页找不到DNS地址的通用排查步骤这个故障太常见了我总结了一套固定的排查顺序基本能解决80%的“找不到DNS地址”问题。第一先确认是不是单个网站的问题。换两个不同的网站试一下。如果所有网站都打不开那大概率是DNS配置或链路问题如果只有某个网站打不开那是这个域名解析的问题可能被污染或DNS服务器缓存异常。第二看系统解析器状态。Windows上用 ipconfig /flushdns 清空本地DNS缓存再用 ipconfig /displaydns 查看缓存加载是否正常。第三手动指定DNS。把网卡DNS改成公共DNS比如114.114.114.114或223.5.5.5阿里DNS然后 ipconfig /renew 重新获取IP。如果手动指定后能正常解析说明原来的DNS服务器不管用或者被网络环境里的设备劫持了。第四用 nslookup 验证解析链路。输入 nslookup www.baidu.com看返回的服务器地址和结果。如果返回的服务器地址不是你配置的DNS说明有中间设备路由器、运营商在拦截DNS请求。这是判断网络环境是否做了DNS劫持的最有效手段。第五查看hosts文件是否被改动。hosts文件里如果存在可疑条目直接删除再试。4.4 ARP攻击的典型表现与应急排查局域网里一旦有人跑了ARP攻击工具症状非常典型内网部分机器上网时断时续ping网关丢包严重或者网页频繁弹出奇怪的验证页面。原因是攻击者不断发送伪造的ARP应答把网关IP对应的MAC地址篡改成自己的网卡地址导致被攻击主机的流量全部被吸引到攻击者那里。应急排查第一步在受害机器上执行 arp -a查看网关IP对应的MAC地址。然后登录核心交换机或接入交换机用 display arp | include 网关IP 查看交换机上学习到的网关MAC。如果两边对不上说明ARP表已经被污染。第二步找到攻击源头。常见办法是在接入交换机上查看可疑IP对应的MAC地址再查这个MAC地址是从哪个端口学到的。华为交换机上用 display mac-address 查看MAC对应的出接口。锁定交换机端口后物理定位到终端设备。第三步临时缓解。在核心交换机上配置静态ARP条目把网关IP和网关真实MAC绑定arp static 网关IP 网关MAC。或者在被攻击主机上执行 arp -s 网关IP 网关MAC 做本地绑定Windows下需要管理员权限。这两个操作都能临时止血但重启后会失效只能作为应急手段。4.5 “ping命令ARP查询”为什么第一次总是慢半拍“ping命令ARP”这个热搜词背后的问题也很常见ping同网段的某台机器第一次总是延迟很高甚至超时第二次开始就秒回。原因不复杂第一次ping之前你的机器不知道目标主机的MAC地址需要先发ARP广播请求等目标应答。这个广播和应答通常只需要几毫秒但如果目标主机负载高、网络存在广播风暴或者交换机的STP收敛有问题这个等待时间可能被拉长到几秒。第二次ping时ARP缓存已经有了直接封装帧发送自然就快了。如果你发现每一次ping都很慢不是第一次慢那就说明ARP学习过程有问题。可能是ARP缓存表一直被刷新去 arp -a 看看是否存在大量重复条目或者局域网里有设备在频繁发送广播帧导致交换机CPU过高、ARP处理不及时。这种时候抓包分析最有效看看是不是有设备在持续发送大量广播ARP请求。4.6 手动绑定与防御机制让局域网流量安全起来应付ARP欺骗单纯靠排查和手动绑定不是长久之计。真正可靠的防御要做到端口级别的控制。企业级交换机上比较常用的防御手段是动态ARP检测DAIDynamic ARP Inspection。原理是给交换机配置DHCP Snooping交换机记录DHCP分配出去的IP和MAC对应关系然后对经过交换机的所有ARP包做检查——如果ARP报文里的IP和MAC映射关系与DHCP记录不一致直接丢弃。这样伪造的ARP应答根本到不了其他终端从根源上切断了ARP欺骗。网关设备上可以做IP-MAC绑定。华为设备在接口视图下配置 arp static 绑定或者开启IP Source Guard功能限制接口只允许特定IP来源的报文通过。家用路由器上如果支持IP与MAC绑定也应该把内网所有设备的IP-MAC绑一遍。DNS方面防劫持的思路是端到端加密。现在主流浏览器和系统已经在推DoHDNS over HTTPS、DoTDNS over TLS把DNS查询封装在加密通道里运营商和中间设备都看不到查询内容也就没法篡改。如果你特别看重DNS安全可以在路由器上配置DoH转发或者用支持DoH的公共DNS服务。另外一个容易被忽视的点是DNS和ARP的安全问题其实是联动的。攻击者用ARP欺骗截获流量之后可以把你的DNS查询重定向到恶意DNS服务器返回一个假的解析结果。所以你会发现一个ARP攻击可能导致DNS劫持的完整症状。这也是为什么我在文章开头强调这两个协议要放一起学——安全防御本来就是一整条链路的事情任何一环失守整条链路都可能被利用。写在最后这几年做了不少网络故障的善后工作我发现一个规律越是基础协议引发的问题越容易被人忽略也越可能酿成大事故。TCP握手、HTTP状态码、应用日志这些东西出了问题日志和监控能帮上忙但DNS也好、ARP也好它们的位置太底层了底层到出了问题经常被误判成“网络慢”“设备老化”“应用不稳定”。我自己处理过的最典型的案例是一家公司的财务系统每到月底就频繁断网IT部门认为是财务软件的问题厂商排查了半个月没结果。后来我过去看发现是有员工下载了某个工具软件扫描软件内置了ARP攻击模块每天固定在月初和月底启动一次把网关的ARP表一刷新财务系统整层楼的机器全部断网。最后在接入交换机上开了DAI问题当场解决再没复发过。所以我的实际体会是学DNS和ARP别只盯着原理背概念。把解析流程走一遍、抓包看一遍、攻击场景模拟一遍、防御功能配置一遍这套组合拳打下来你才算真正掌握这两个协议。网络上现在资源也丰富GNS3、Wireshark、模拟器都是免费的工具随便搭个实验环境就能验证我上面说的所有内容。多动手折腾几次比看十篇文章都管用。 DNS与ARP协议深度解析：从原理、配置到故障排查与安全防御
开局先聊一个特别常见的场景电脑突然打不开网页了你顺手ping了一下域名发现解析出来的IP压根不对或者公司局域网一到下午就卡成PPT查了半天不是带宽问题最后发现有人拿着工具在局域网里发伪造的ARP应答包。DNS和ARP一个负责把域名“翻译”成IP一个负责把IP“翻译”成MAC地址它们是网络通信里最基础也最容易被忽略的两个协议。但恰恰是这两个基础协议在真实运维中制造了大量让人头疼的问题。这篇文章想把我这些年在这两个协议上踩过的坑、做过的实验、排查过的故障梳理一遍从原理讲到配置再从配置讲到安全机制。不管是刚入行的网络小白还是被DNS劫持、ARP欺骗折磨过的一线运维应该都能从中找到点可用的东西。1. 内容整体设计与思路拆解为什么这件事值得单独拿出来写很多人觉得DNS和ARP是老掉牙的知识点教科书上翻一翻都有。但问题是教科书讲的是“标准流程”实际环境里跑的却是“变形流程”。比如DNS解析标准流程是客户端问递归服务器递归服务器问根域、顶级域、权威服务器最后返回结果。但实际环境里有DNS缓存、有DNS代理、有运营商劫持、有hosts文件干扰、有多级DNS转发任何一个环节出问题表现都是“网页打不开”但原因天差地别。ARP同理标准流程是广播请求、单播应答、缓存表维护。但真实局域网里有ARP攻击、有IP冲突、有交换机端口安全策略、有VRRP虚拟IP的ARP响应、有无线终端的快速漫游ARP更新。你手上没有一套清晰的排查思路光看现象根本无从下手。所以我写这篇文章的思路是先讲清楚两个协议的核心机制再落到具体配置和故障排查最后用安全攻防的角度把ARP欺骗和DNS劫持这两大局域网流量安全风险串起来。这样从机制到实操到安全是一条完整的认知链路。它的核心价值在于让你知道“正常时它该干什么”你才能判断“异常时它到底哪里出问题了”。另外一个必须说明的思路是DNS和ARP不是孤立的。你访问一个网站先有DNS解析得到IP然后路由决定下一跳最后在局域网里靠ARP找到目标MAC地址。表面上两个协议各管一段实际上是一条链路的前后半程。所以把它们放在一篇文章里分析不是为了凑标题而是因为排障时本来就是一条线顺下来的——用户说“网不通”你要先查DNS通不通再查ARP表对不对最后才能定位到具体环节。2. 核心细节解析与实操要点两个协议到底是怎么工作的2.1 DNS解析的完整过程从域名到IP的七步接力先看一张DNS解析的完整链条。假设你在浏览器输入 www.example.com系统是怎么知道该访问哪个IP的第一步浏览器先查本地DNS缓存。Windows下可以用 ipconfig /displaydns 查看里面存着历史上解析过的记录。缓存命中的话整个过程直接结束这是最快的路径。第二步缓存没命中系统读取 hosts 文件。Windows在 C:\Windows\System32\drivers\etc\hostsLinux在 /etc/hosts。这里要注意hosts文件的优先级高于DNS服务器配置所以很多恶意软件喜欢改hosts做域名劫持排查解析异常时第一个就要看它。第三步hosts没有才轮到系统的DNS客户端解析器把请求发给网络配置里指定的DNS服务器。这个服务器通常叫递归解析器或本地DNS服务器可能是运营商的、是114这样的公共DNS、是自己公司内网的DNS服务器。第四步递归解析器收到请求后如果它自己有缓存就直接返回没有的话它去问根域名服务器。根域名服务器不直接告诉你example.com的IP它告诉你“ .com 由这些顶级域服务器负责你去问它们”。第五步递归解析器去问.com顶级域服务器得到“example.com 的权威DNS服务器是这些”的答复。第六步递归解析器向example.com的权威DNS服务器发起查询拿到具体的A记录或AAAA记录也就是IPv4或IPv6地址。第七步递归解析器把结果缓存一段时间同时把最终IP返回给你的电脑。解析器本身也会把这个结果缓存起来下次访问就快了。这个过程中牵扯到两个概念递归查询和迭代查询。你向本地DNS服务器发起的查询是递归查询——意思是“你必须给我一个最终答案”。本地DNS服务器向根域、顶级域、权威域的查询是迭代查询——意思是“我不直接给你答案但我告诉你下一步该找谁”。理解这个区别很关键因为排查DNS慢的时候你要能判断是递归环节慢还是迭代环节慢。2.2 ARP协议的工作机制IP地址到MAC地址的广播问答DNS解决了“域名对应哪个IP”的问题但真正在局域网里转发数据帧时靠的是MAC地址。ARPAddress Resolution Protocol就是干这件事的通过已知的IP地址解析出对应的MAC地址。它的工作流程特别简单。主机A要和主机B通信先查自己的ARP缓存表你们在命令行敲过的 arp -a 查的就是这张表。里面有IP地址和MAC地址的对应关系。如果表里有记录直接用没有记录主机A就向局域网里发一个广播帧谁的IP是192.168.1.100请把你的MAC地址告诉我。这个广播帧会被局域网里所有主机收到但只有IP匹配的那台主机主机B会回应一个单播帧我是192.168.1.100我的MAC地址是AA:BB:CC:DD:EE:FF。主机A收到应答后把这条记录写进ARP缓存表然后封装数据帧开始通信。注意几个细节。第一ARP请求是广播的ARP应答是单播的。但也有一种特殊情况叫免费ARPGratuitous ARP主机开机或IP地址变更时主动广播自己的IP和MAC映射目的是告诉别人“我来了如果有冲突赶紧告诉我”同时让交换机更新自己的MAC地址表。第二ARP表是有老化时间的。Windows系统默认的ARP缓存超时时间在2到10分钟之间动态条目超过这个时间没被使用就会被删除下次通信需要重新解析。这就解释了为什么你ping同网段的一台机器第一次ping会慢一下因为要先走ARP解析后面就快了缓存命中了。第三ARP只工作在同一个网段内。跨网段通信时你请求的是网关的MAC地址而不是目标主机的MAC地址。数据帧先发给网关由网关负责转发到目标网段。这是一个很多新手容易混淆的点。2.3 DNS和ARP在数据链路中的衔接关系把两个协议串起来看。你访问www.example.comDNS解析出IP 93.184.216.34。然后系统判断这个IP跟自己不在同一个网段于是把数据包交给默认网关。但要把数据包发给网关必须知道网关的MAC地址这时候ARP登场解析网关IP对应的MAC地址数据帧封装完成后从网卡发出去。所以你看DNS解析是“逻辑地址到逻辑地址”的映射ARP解析是“逻辑地址到物理地址”的映射。两者衔接的节点就是那张已经写满IP和MAC对应关系的ARP缓存表。这也是为什么排查网络不通时先ping网关再ping域名看看是ARP解析问题还是DNS解析问题——哪个环节失败了报错信息一目了然。3. 实操过程与核心环节实现从配置到抓包手把手走一遍3.1 Linux下配置DNS的完整过程与“重启还原”问题热搜词里有一个很典型的场景“linux修改dns后重启网络还原”。这说的是很多人在/etc/resolv.conf里改了DNS地址重启网络服务之后发现又被改回去了白改一场。原因在于很多Linux发行版的网络管理栈会自动覆盖resolv.conf。具体来说如果你用的是NetworkManager管理的网络它会根据DHCP获取到的DNS信息动态生成resolv.conf。你手动在文件里改了nameserverNetworkManager一刷新又会把DHCP下发的DNS配置写回去。正确的改法取决于你的系统版本和网络管理方式。CentOS 7及以前的版本修改 /etc/sysconfig/network-scripts/ifcfg-eth0具体文件名看你网卡名在里面加一行 DNS1114.114.114.114然后重启网络服务。CentOS 8、Rocky Linux、Ubuntu 18.04以上版本推荐用nmcli命令nmcli con mod 你的连接名 ipv4.dns 114.114.114.114 8.8.8.8然后 nmcli con up 你的连接名 生效。如果你只是临时测试直接修改 /etc/resolv.conf 是没问题的但重启网络或NetworkManager刷新后会被还原。所以排查“DNS配置总变”的问题第一反应是查看是不是NetworkManager在管这个接口的DNS而不是反复去改resolv.conf。再顺便说一个常见误操作很多人改完DNS后喜欢重启网卡或者重启网络服务这个动作其实没必要。用 nmcli 或 systemctl restart NetworkManager 都会导致连接重连正在跑的连接会短暂中断。如果只是改DNS可以用 nmcli con mod 配合 nmcli con up 让配置生效别动不动就重启整个网络栈。3.2 Windows Server 2016上配置DNS服务正向查找区域与转发器Windows Server 2016作为内网DNS服务器是很常见的用法。配置步骤不算复杂但有几个关键点容易出错。安装DNS服务角色后打开DNS管理器展开服务器节点找到“正向查找区域”右键新建区域。区域类型选择“主要区域”区域名称填你负责的域名比如 internal.com。之后会创建对应的区域文件。新建区域完不算完还要在区域里新建主机记录A记录。右键区域选择“新建主机”名称填主机名比如wwwIP地址填对应的内网IP勾选“创建相关的指针PTR记录”可以同时生成反向查找记录。配置完成后最关键的一步是设置转发器。内网DNS服务器一般不做根服务器迭代查询也做不了因为你没有根区的权威数据而是把外部域名的解析请求转发给上游DNS服务器。在服务器节点上右键属性找到“转发器”添加公共DNS地址比如114.114.114.114或8.8.8.8。这样内网机器把DNS指向这台Windows Server内网域名由它直接解析外部域名由它转发给公共DNS。这里有个排障经验如果你配置了DNS服务器但客户端解析不了外网域名先查两件事。第一客户端能不能ping通DNS服务器的IP第二DNS服务器的转发器配置是否正常可以在DNS服务器上直接 nslookup www.baidu.com 试试看。如果服务器自己能解析但客户端不行多半是客户端没把DNS指向服务器或者防火墙挡了UDP 53端口。3.3 华三防火墙关闭DNS代理与锐捷路由器DNS自动获取问题热搜词里提到了“华三防火墙关闭dns代理”。这个场景在企业网里很典型——防火墙开启了DNS代理功能所有客户端的DNS请求都会被防火墙拦截并代问好处是可以通过防火墙的策略控制DNS流量坏处是一旦代理功能异常全网的域名解析都会挂掉。华三防火墙关闭DNS代理的操作路径是进入系统视图执行 dns proxy enable/disable 命令。注意不同版本Comware V5/V7的命令略有差异V7版本是 dns proxy enable关闭就 no dns proxy enable或者执行 undo dns proxy。关闭之后防火墙就不再拦截DNS请求了客户端直接访问上游DNS服务器。做这个操作前先想清楚如果你关掉DNS代理那么防火墙安全策略里就需要放行UDP 53/TCP 53的流量否则客户端连外网DNS的解析请求会被防火墙拦截。很多人在防火墙上关了代理但忘了放行DNS流量结果全网解析全部失败这就是典型的“改配置时没考虑前后依赖”的坑。锐捷路由器“DNS自动获取”的问题也很常见。家用级的锐捷路由器默认开启DHCP服务给终端分配IP的同时也下发DNS地址默认选的是“自动获取上游DNS”即从运营商拨号链路里自动获取。如果你发现内网终端解析域名很慢或者解析到错误地址可以把DNS模式改成“手动指定”填写公共DNS地址。改完后别忘了重启DHCP服务或重新拨号确保客户端重新获取地址时拿到的是新DNS配置。3.4 GNS3中双路由器抓包分析ARP与IP数据转发GNS3做网络实验是特别好的学习方式。热搜词里有一个具体实验两个路由器分别连接主机分析IP数据转发报文和ARP协议过程。这个实验做通了你对ARP在跨网段通信中的角色会有非常直观的理解。实验拓扑很简单路由器R1的e0/0接主机A192.168.1.1/24R1的e0/1接R2的e0/0两个接口都是10.0.0.0/24网段R2的e0/1接主机B192.168.2.1/24。三层互联主机A要访问主机B。用Wireshark在主机A接入的交换机口上抓包在主机A上执行 ping 192.168.2.2。你会看到这样的数据流第一组主机A发ARP广播问192.168.1.1网关的MAC地址。因为192.168.2.2和A不在同一网段A知道要把数据包交给网关。第二组R1回应ARP单播告诉A自己的MAC地址。然后A把ICMP请求封装在以太网帧里目的MAC是R1的MAC目的IP是192.168.2.2。第三组R1收到数据帧拆掉以太网头看目的IP查路由表发现下一跳是10.0.0.2R2。此时R1查看自己的ARP缓存如果没有R2的10.0.0.2的MAC映射就再发一个ARP广播——这次是发在R1和R2之间的网段上。第四组R2回应ARPR1重新封装数据帧目的MAC改成R2的MAC从e0/1发出去。第五组R2收到后发现目的IP是192.168.2.2查路由表发现直连网段于是再发ARP广播询问主机B的MAC地址拿到之后封装帧发给B。这个实验抓包看下来你会深刻理解一个点数据报文每经过一个三层设备源IP和目的IP是不变的但源MAC和目的MAC一直在变。每一跳都要重新做一次ARP解析。而主机A上看到的ARP表只有网关的MAC看不到主机B的MAC——因为对于A来说B根本不在同一链路层域里。3.5 接口下ARP地址怎么查IP地址的上线和下线时间这个热搜词大概率来自网络运维场景想在交换机上查看某个IP对应的MAC多久前上线、多久前下线。不同厂商设备的命令不一样。华为交换机上先进接口视图执行 display arp interface GigabitEthernet 0/0/1可以看到该接口下的ARP表项其中Age字段就是老化计时显示这条ARP条目已经存在了多少秒。如果要看更详细的信息包括MAC地址上线时间用 display arp verbose输出的信息里有该ARP表项创建的时间。思科交换机上命令是 show ip arp带接口参数可以过滤show ip arp interface GigabitEthernet 0/1。输出里的Age字段表示这条表项的存活时间。如果看到“-”表示该条目是静态的相当于永久存在。排查IP冲突时这个字段很管用——如果发现同一个IP对应了多个MAC地址再看Age字段就能判断哪条记录是新的。华三设备上用 display arp 命令输出类似。如果要在接口下看用 display arp interface GigabitEthernet 1/0/1。另外华三支持 display arp timer 来查看ARP老化时间设置默认是20分钟。经验之谈排查ARP故障时手动清掉可疑的ARP缓存再观察比直接在表里对比更高效。华为交换机上执行 reset arp all 可以把动态ARP表项全部清除设备会重新学习。思科是 clear arp-cache。清完后再查看动态表项会重新刷新如果某个IP对应的MAC仍然不对说明攻击源还在持续发送伪造ARP包这时候就要考虑在接入交换机上做防御了。4. 常见问题与排查技巧实录DNS与ARP的疑难杂症速查4.1 电脑DNS地址变成fe80::1%11是什么情况热搜词里那个“DNS 服务器 ...... : fe80::1%11”很有代表性。fe80开头的是IPv6链路本地地址后面的%11是Windows里表示网卡编号的zone ID。出现这种情况说明你的网卡通过DHCPv6或路由器通告RA获取到了IPv6的DNS配置其中网关设备把自身的IPv6链路本地地址作为DNS服务器地址下发给了终端。这个配置本身不算错误很多家用路由器的IPv6 DNS就是通告自己的链路本地地址。真正的问题是这台设备的IPv6 DNS服务可能根本不好使或者配置了IPv6优先但IPv6链路实际不通导致解析超时。解决办法也很直接不用动IPv6直接在IPv4的DNS配置里手动指定一个可靠的DNS比如114.114.114.114或8.8.8.8。如果确实想完全禁用IPv6 DNS可以在网卡属性里把IPv6协议取消勾选不推荐全局禁用影响面太大或者在路由器上关闭IPv6 DNS通告功能。4.2 cloudcom dns error 1006和Lets Encrypt验证报错“ce: -90100 cloudcom dns error 1006”这类报错通常出现在使用华为云CloudDNS时API调用返回异常1006一般是权限校验失败或区域参数不匹配。排查思路是先确认API凭证有没有过期再看调用的区域Region跟域名所在的区域是否一致最后看域名是不是在托管区里存在。“during secondary validation: dns problem: networking error looking up a for”这个报错来自Lets Encrypt证书申请过程。申请证书验证域名所有权时Lets Encrypt的服务器反向查询你的域名A记录发现查到了多个IP或者查询超时。处理方式通常是确认域名的A记录配置正确且是公网可达的IP确认TTL不要设太短至少300秒以上确认没有配置多条有冲突的A记录。还需要检查防火墙是否限制了外部对DNS查询的访问有些云安全组默认只放行了TCP/UDP 53的入方向流量但Lets Encrypt走的是UDP 53标准查询如果被限速策略拦截就会报networking error。4.3 打开网页找不到DNS地址的通用排查步骤这个故障太常见了我总结了一套固定的排查顺序基本能解决80%的“找不到DNS地址”问题。第一先确认是不是单个网站的问题。换两个不同的网站试一下。如果所有网站都打不开那大概率是DNS配置或链路问题如果只有某个网站打不开那是这个域名解析的问题可能被污染或DNS服务器缓存异常。第二看系统解析器状态。Windows上用 ipconfig /flushdns 清空本地DNS缓存再用 ipconfig /displaydns 查看缓存加载是否正常。第三手动指定DNS。把网卡DNS改成公共DNS比如114.114.114.114或223.5.5.5阿里DNS然后 ipconfig /renew 重新获取IP。如果手动指定后能正常解析说明原来的DNS服务器不管用或者被网络环境里的设备劫持了。第四用 nslookup 验证解析链路。输入 nslookup www.baidu.com看返回的服务器地址和结果。如果返回的服务器地址不是你配置的DNS说明有中间设备路由器、运营商在拦截DNS请求。这是判断网络环境是否做了DNS劫持的最有效手段。第五查看hosts文件是否被改动。hosts文件里如果存在可疑条目直接删除再试。4.4 ARP攻击的典型表现与应急排查局域网里一旦有人跑了ARP攻击工具症状非常典型内网部分机器上网时断时续ping网关丢包严重或者网页频繁弹出奇怪的验证页面。原因是攻击者不断发送伪造的ARP应答把网关IP对应的MAC地址篡改成自己的网卡地址导致被攻击主机的流量全部被吸引到攻击者那里。应急排查第一步在受害机器上执行 arp -a查看网关IP对应的MAC地址。然后登录核心交换机或接入交换机用 display arp | include 网关IP 查看交换机上学习到的网关MAC。如果两边对不上说明ARP表已经被污染。第二步找到攻击源头。常见办法是在接入交换机上查看可疑IP对应的MAC地址再查这个MAC地址是从哪个端口学到的。华为交换机上用 display mac-address 查看MAC对应的出接口。锁定交换机端口后物理定位到终端设备。第三步临时缓解。在核心交换机上配置静态ARP条目把网关IP和网关真实MAC绑定arp static 网关IP 网关MAC。或者在被攻击主机上执行 arp -s 网关IP 网关MAC 做本地绑定Windows下需要管理员权限。这两个操作都能临时止血但重启后会失效只能作为应急手段。4.5 “ping命令ARP查询”为什么第一次总是慢半拍“ping命令ARP”这个热搜词背后的问题也很常见ping同网段的某台机器第一次总是延迟很高甚至超时第二次开始就秒回。原因不复杂第一次ping之前你的机器不知道目标主机的MAC地址需要先发ARP广播请求等目标应答。这个广播和应答通常只需要几毫秒但如果目标主机负载高、网络存在广播风暴或者交换机的STP收敛有问题这个等待时间可能被拉长到几秒。第二次ping时ARP缓存已经有了直接封装帧发送自然就快了。如果你发现每一次ping都很慢不是第一次慢那就说明ARP学习过程有问题。可能是ARP缓存表一直被刷新去 arp -a 看看是否存在大量重复条目或者局域网里有设备在频繁发送广播帧导致交换机CPU过高、ARP处理不及时。这种时候抓包分析最有效看看是不是有设备在持续发送大量广播ARP请求。4.6 手动绑定与防御机制让局域网流量安全起来应付ARP欺骗单纯靠排查和手动绑定不是长久之计。真正可靠的防御要做到端口级别的控制。企业级交换机上比较常用的防御手段是动态ARP检测DAIDynamic ARP Inspection。原理是给交换机配置DHCP Snooping交换机记录DHCP分配出去的IP和MAC对应关系然后对经过交换机的所有ARP包做检查——如果ARP报文里的IP和MAC映射关系与DHCP记录不一致直接丢弃。这样伪造的ARP应答根本到不了其他终端从根源上切断了ARP欺骗。网关设备上可以做IP-MAC绑定。华为设备在接口视图下配置 arp static 绑定或者开启IP Source Guard功能限制接口只允许特定IP来源的报文通过。家用路由器上如果支持IP与MAC绑定也应该把内网所有设备的IP-MAC绑一遍。DNS方面防劫持的思路是端到端加密。现在主流浏览器和系统已经在推DoHDNS over HTTPS、DoTDNS over TLS把DNS查询封装在加密通道里运营商和中间设备都看不到查询内容也就没法篡改。如果你特别看重DNS安全可以在路由器上配置DoH转发或者用支持DoH的公共DNS服务。另外一个容易被忽视的点是DNS和ARP的安全问题其实是联动的。攻击者用ARP欺骗截获流量之后可以把你的DNS查询重定向到恶意DNS服务器返回一个假的解析结果。所以你会发现一个ARP攻击可能导致DNS劫持的完整症状。这也是为什么我在文章开头强调这两个协议要放一起学——安全防御本来就是一整条链路的事情任何一环失守整条链路都可能被利用。写在最后这几年做了不少网络故障的善后工作我发现一个规律越是基础协议引发的问题越容易被人忽略也越可能酿成大事故。TCP握手、HTTP状态码、应用日志这些东西出了问题日志和监控能帮上忙但DNS也好、ARP也好它们的位置太底层了底层到出了问题经常被误判成“网络慢”“设备老化”“应用不稳定”。我自己处理过的最典型的案例是一家公司的财务系统每到月底就频繁断网IT部门认为是财务软件的问题厂商排查了半个月没结果。后来我过去看发现是有员工下载了某个工具软件扫描软件内置了ARP攻击模块每天固定在月初和月底启动一次把网关的ARP表一刷新财务系统整层楼的机器全部断网。最后在接入交换机上开了DAI问题当场解决再没复发过。所以我的实际体会是学DNS和ARP别只盯着原理背概念。把解析流程走一遍、抓包看一遍、攻击场景模拟一遍、防御功能配置一遍这套组合拳打下来你才算真正掌握这两个协议。网络上现在资源也丰富GNS3、Wireshark、模拟器都是免费的工具随便搭个实验环境就能验证我上面说的所有内容。多动手折腾几次比看十篇文章都管用。