1. 域名怎么变成IP又怎么被送进局域网做网络排查这些年我见过太多人把DNS和ARP混在一谈或者在抓包时看到ARP报文一头雾水。实际上这两个协议解决的是不同层的“找到目标”问题DNS负责把人类易记的域名解析成IP地址解决的是“你要访问谁”ARP负责在同一个局域网内把IP地址解析成MAC地址解决的是“数据帧到底要交给哪块网卡”。这两层映射一旦断裂就会出现“DNS能解析但就是ping不通”“同一交换机下机器互相访问偶尔失败”之类的诡异问题。先说一个完整的访问过程。你在浏览器输入www.example.com系统首先要向DNS服务器发起解析请求拿到93.184.216.34这样的IP。随后应用程序通过Socket发起连接操作系统查看路由表发现目标IP不在本地网段于是把包交给网关但如果目标IP就在本网段操作系统就需要知道目标主机的MAC地址这时ARP协议登场。对于跨网段访问数据链路层要封装的是下一跳网关的MAC地址而不是最终服务器的MAC地址。这两个步骤是串联的缺少任何一个业务都跑不通。从我个人的维护经验看大多数网络故障的根因往往不在链路本身而在这些映射关系上。比如DNS缓存里存了一条过期记录或者ARP缓存里对应了错误的MAC地址。理解这两个协议的细节不是为了应付考试而是为了在出问题时能快速定位到层级。这篇文章我会把两个协议的原理、报文结构、常见坑和排障工具串起来讲尤其会结合我在Linux服务器、Windows Server以及国产操作系统上配置DNS时踩过的坑和局域网内ARP攻击的实测经验。2. DNS解析链路拆解递归、缓存和报文2.1 递归查询与迭代查询的关系DNS解析的过程说白了就是一部“逐级问路”的字典查询系统。当客户端配置的DNS服务器收到一个解析请求如果它本地没有缓存就会帮客户端去根服务器开始一层层问。根服务器不会直接告诉你某域名的IP它只告诉你“com”这个顶级域的服务器在哪然后你的DNS服务器再去问“com”域的服务器对方又告诉你“example.com”这个域的权威服务器在哪最后你的DNS服务器去问ns1.example.com这台权威服务器才得到真正的A记录。这条链路里客户端到配置的DNS服务器之间是“递归查询”因为这台DNS服务器要负责把所有后续查询做完最终返回结果。而DNS服务器与根、顶级域、权威服务器之间是“迭代查询”每次只问下一步该找谁。理解这个流程对排障非常关键。你在本机nslookup一个域名如果迟迟没有响应有可能是本机到运维配的那台DNS服务器网络不通也可能是上游递归服务器与根或权威服务器之间的链路出了问题。区分这两类问题最简单的办法是换一台DNS服务器再试。比如我在排查时经常用dig 223.5.5.5 www.example.com如果换了服务器立刻返回结果说明问题大概率出在原DNS服务器到外部链路的解析上而不是客户端的内网配置。2.2 TTL和缓存对解析速度和排障的影响DNS查询返回的报文里有个TTLTime to Live字段单位是秒。它告诉客户端和各级DNS缓存服务器这条记录可以缓存多久。比如TTL是300秒那意味着解析结果在5分钟内可能不会重新向权威服务器确认。这个字段直接决定了你修改DNS记录后的生效速度也决定了大量请求是否会压到权威服务器上。我经常遇到这样的工单运维同学改了公司官网的IP然后反馈“怎么过了半小时还是不生效”。一查原先的A记录TTL是86400秒一天而DNS缓存服务器遵循的就是这个TTL在24小时之内它都会继续给客户端返回旧IP不会去权威服务器问一次。所以规范的服务器运维在做记录变更之前应该先把TTL调低比如调到60秒等一天让旧缓存自然过期再改IP改完之后观察稳定了再恢复原来的TTL。这是很多文档里不会写但实战中极其重要的经验。2.3 常见DNS记录类型A、AAAA、CNAME、MX、NS排障时至少要能区分几种最常用的记录类型否则你可能拿着一个CNAME记录当成A记录检查半天。记录类型作用典型场景A域名指向IPv4地址www.example.com. IN A 93.184.216.34AAAA域名指向IPv6地址www.example.com. IN AAAA 2400:cb00:2048:1::c629:d7a2CNAME别名指向另一个域名blog.example.com. IN CNAME example.github.ioMX邮件路由指定邮件服务器example.com. IN MX 10 mail.example.comNS指定该域名的权威服务器example.com. IN NS ns1.example.com很多新手会忽略CNAME和A记录同时存在时的行为。规范情况下CNAME记录不能与其他记录共存于同一个名字上。我曾经维护的一套系统里有人给www.xxx既配置了A记录指向老IP又配置了CNAME指向CDN结果有的地区解析到老IP有的地区解析到CDN最终导致部分用户访问异常。这类问题通过dig查看多地区的解析结果就能迅速定位同时也会提醒你管理DNS记录前先搞清楚现有记录的类型。3. 那些年踩过的DNS配置坑3.1 Linux下配置DNS后重启失效Linux下配置DNS最直观的方式是修改/etc/resolv.conf写上nameserver 223.5.5.5。但很多人会发现重启网络服务或者重启机器后这个文件又变回了原来的样子。这种情况在现代Linux发行版里太常见了原因是/etc/resolv.conf可能被NetworkManager、systemd-resolved或者DHCP客户端接管你手改的内容只是临时的。我在CentOS和老版本Ubuntu上的做法是如果确定要使用静态DNS就直接关闭DHCP对DNS的覆盖。以当前主流的nmcli为例先查看连接名nmcli connection show然后针对活动的连接设置DNSnmcli con mod eth0 ipv4.dns 223.5.5.5 1.1.1.1 nmcli con mod eth0 ipv4.ignore-auto-dns yes nmcli con up eth0对于使用systemd-resolved的系统如较新的Ubuntu、欧拉部分版本/etc/resolv.conf通常是一个符号链接指向systemd-resolved生成的动态文件。此时直接修改这个链接指向的文件是没有意义的。正确做法是修改/etc/systemd/resolved.conf设置DNS字段然后重启systemd-resolved服务或者用resolvectl dns命令动态设置。我在欧拉系统上多次遇到这种问题最后统一改用NetworkManager管理才避免了“改了没生效”的乌龙。类似的坑在银河麒麟系列上也有因为它们多半继承了Debian或CentOS的网络管理习惯关键点就是先确认谁在“管理”resolv.conf再对症下药。3.2 公共DNS与内网DNS的选型逻辑很多人喜欢把DNS改成8.8.8.8觉得“大厂DNS一定稳”。但在国内网络环境下8.8.8.8并不一定是最优选原因不止是延迟。公共DNS服务器通常部署在境外或特定节点很多本地化服务比如视频网站、CDN节点调度会根据DNS请求的出口IP来返回离你最近的节点IP。当你使用公共DNS时它返回的IP很可能是一个对公共DNS出口最优、但对你当前网络并不最优的节点结果就是“能解析但访问很慢”。与之相对的114.114.114.114国内、223.5.5.5阿里DNS、119.29.29.29腾讯DNS在国内多数网络下表现都不错而且有利于CDN调度。但一概而论也不对。我建议的做法是在多个DNS之间对比解析速度和连接测速用dig加上统计信息看解析耗时dig 223.5.5.5 www.baidu.com同时测量关键业务的TCP连接耗时选择响应稳定且连接快的DNS。对于企业内网我更倾向于自建内网DNS把内网域名如gitlab.corp解析到内网IP同时配好上游转发策略。注意内网DNS的上游设置不能简单写死一个公共DNS最好配置多个上游并根据优先级和失败重试做冗余避免内网DNS本身成为单点故障。3.3 Windows Server与国产系统上的DNS配置差异Windows Server 2016/2022上配置DNS服务本身并不复杂装好DNS角色在DNS管理器中创建正向查找区域添加主机记录即可。但容易踩的坑是在配置DNS服务器静默安装时忘记同时指定本机DNS指向自身导致客户端查询正常但服务器自身解析外部域名失败。正确做法是在安装DNS服务后立刻在“服务器管理器-本地服务器”里把DNS服务器指向127.0.0.1并把备用DNS指向一个外部公共DNS。这个操作不复杂但漏掉的人真不少。银河麒麟这类国产系统配置DNS时兼容CentOS的很多习惯但图形化网络工具使用的人少反而常常直接改配置文件。需要注意的是麒麟系统许多版本使用了NetworkManager或systemd-networkd如果两者同时管理同一网卡可能出现overlapping问题。我在银河麒麟V10上遇到过修改网卡配置文件后systemctl restart network成功但网络依然用旧配置的情况最后发现是NetworkManager的配置优先级更高需要通过nmcli或者修改连接配置文件来解决。核心原则先确认网络管理栈再谈配置方式。4. ARP协议原理局域网内的最终寻址机制4.1 为什么有了IP还要MAC在同一个局域网里IP地址是逻辑地址但随着主机位置变化比如从交换机A口换到B口IP可以保持不变而MAC地址才是网卡烧录的物理标识。数据链路层的以太网帧头部里的目标地址必须是目的网卡的MAC地址交换机也是通过MAC地址表来决定把帧从哪个端口转发出去。所以即使你知道对方的IP也要先在局域网内找到对应IP的MAC地址才能成功封装出以太网帧。这也是ARP存在的根本意义把IP和MAC做一次动态映射。4.2 ARP请求/应答与缓存老化当主机A想访问同网段主机B时它先查询自己的ARP缓存表Linux下用arp -a或ip neigh show查看如果缓存中有B的IP和MAC映射就直接封装帧。如果没有A会发送一个广播帧也就是ARP请求内容是“谁是192.168.1.10请告诉192.168.1.1我的IP”。这个广播会泛洪到整个二层网络所有收到的主机都会检查自己的IP是否匹配只有B会回复一个单播的ARP应答内容大意是“我就是192.168.1.10我的MAC是00:1A:2B:3C:4D:5E”。A收到应答后把映射写入ARP缓存然后进行正常通信。ARP缓存不是永久有效的每条记录都有老化时间Linux默认多条记录的老化时间在几十秒到几分钟不等。这个机制是好事因为IP和MAC的映射关系可能变化比如网卡更换、虚拟机漂移。但坏处就是老化期给攻击者留下了篡改缓存的机会也给频繁变更IP的场景带来了短暂的解析延迟。我曾在维护虚拟化集群时遇到新虚拟机刚从模板克隆出来蹭蹭地扫描一遍网段后才恢复通信就是因为ARP老化加上交换机MAC表未刷新。4.3 免费ARP与冲突检测除了请求和应答ARP还有一种特例免费ARPGratuitous ARP。主机在配置IP地址后会主动发送一条ARP广播内容是“192.168.1.10这个IP是谁的如果没人回应我就用这个IP了”。这样做有两个作用一是探测IP是否有冲突二是通知局域网内其他主机自己的IP和MAC映射已经更新让它们更新ARP缓存。很多网络设备在VRRP、VRF或者虚拟IP地址切换时也会主动发送免费ARP让交换机和对端设备及时更新MAC表从而加速主备切换。这个机制对排障很重要。如果某些设备对免费ARP响应不合理或者攻击者伪造免费ARP就能让局域网内的主机把流量导向错误的MAC地址这也就是后面要讲的ARP欺骗的基础。4.4 用Wireshark抓一次ARP包理论看十遍不如抓包看一遍。在Wireshark中抓取一个局域网接口的流量然后清空本机ARP缓存再去ping一个局域网内其他IP。Wireshark的过滤栏输入arp你就能看到完整的请求和应答过程。请求帧的目标MAC是ff:ff:ff:ff:ff:ff代表广播发送方MAC是源主机的MAC发送方IP是源IP目标MAC为全0目标IP是目标主机的IP。应答帧的目标MAC变成了源主机的MAC而不是广播方向反过来。看包的时候注意一个细节ARP报文没有经过IP层它直接承载在以太网帧之上只有ARP头。以太网帧头部的“类型”字段是0x0806表示上层是ARPIP包的类型字段是0x0800。如果搞清楚了这两者的区别你在看抓包工具时就不会再被“为什么只看到IP看不到ARP”之类的问题弄晕。实际上只有当主机缓存中没有映射时才会出现ARP报文缓存里有映射时你看到的就只剩IP数据包了。5. 局域网流量安全的命门ARP欺骗与防护5.1 ARP欺骗的攻击原理前面提到ARP协议有一个致命弱点它不校验报文来源的真实性。任何主机都可以发送一个ARP应答帧声称“192.168.1.1的MAC是xx:xx:xx:xx:xx:xx”而收到这个应答的主机通常会无条件更新自己的ARP缓存Linux系统在某些情况下会接受更新。攻击者利用这一点在网络里伪装成网关或者某台服务器就能截获流量这就是ARP欺骗也就是常说的ARP攻击。最常见的攻击形式是冒充网关。假设网段是192.168.1.0/24网关是192.168.1.1攻击者发送大量ARP应答告诉受害主机“网关192.168.1.1的MAC是攻击者的MAC”受害主机就会把发给网关的流量全部发到攻击者的网卡上。攻击者可以用iptables开启IP转发把流量再转发给真正的网关这样就形成了一条从受害者到网关之间的“桥”而受害者完全无感知。此时攻击者可以监视、抓取甚至篡改流量。这在公司内网里是非常严重的风险。5.2 一次中间人攻击的完整演示模拟为了理解防护手段我曾在实验室里完整模拟过一次ARP中间人攻击。环境是三个虚拟机受害者AIP 192.168.1.10、攻击者BIP 192.168.1.20、网关CIP 192.168.1.1。在B上启用IP转发echo 1 /proc/sys/net/ipv4/ip_forward然后用arpspoof工具向A发送伪造的ARP应答让A认为网关的MAC是B的MAC同时向网关发送伪造的ARP应答让网关认为A的MAC也是B的MAC。这样一来A到网关的所有双向流量都会经过B。在B上运行Wireshark或tcpdump抓取接口流量我看到A访问外网的HTTP请求明文出现在抓包里甚至能直接看到请求的URL和Cookie。这个实验还只是最基础的真正高明的攻击会利用SSL Strip或域名替换进一步控制会话。但关键在于ARP欺骗之所以能成功前提就是二层网络里的主机对ARP无脑信任。如果你想在公司局域网里做一次安全演习建议先和网络负责人沟通在隔离环境中操作避免影响生产。5.3 防护手段静态ARP、端口安全、DAI、DHCP Snooping对付ARP欺骗最基本也最笨的办法是配置静态ARP条目。在Windows下通过arp -s 192.168.1.1 00-11-22-33-44-55添加静态映射在Linux下通过ip neigh add 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0 nud permanent。这种方式适合小型网络但维护成本高一旦网关或服务器换了网卡你必须同步更新所有主机的静态表否则会彻底断网。在企业交换机上更推荐组合使用DHCP Snooping和动态ARP检测DAI。DHCP Snooping会把交换机的端口分成信任端口和非信任端口只信任连接合法DHCP服务器和上行设备的端口其他端口不允许私自发送DHCP响应从而防止伪造DHCP地址分配。在此基础上DAI技术利用DHCP Snooping建立起来的IP-MAC绑定表校验非信任端口上收到的ARP报文是否合法如果ARP报文中声称的IP和MAC不匹配绑定表交换机会直接丢弃。这套组合拳是目前抑制ARP欺骗最有效的手段前提是全网交换机支持并正确配置。另一个重要防护是交换机端口安全Port Security它限制每个端口允许学习的MAC地址数量并且可以设置“违规”处理动作。如果攻击者试图在接入端口上发送大量伪造源MAC的ARP报文端口会被shutdown或丢弃报文从而阻断攻击。不过要注意这类配置如果策略过严也会误伤通过该端口接入的多设备场景比如一个端口下接了一个小交换机需要在部署前做好规划。5.4 日常巡检与自查命令网络维护不能等出了问题再排查日常巡检时可以主动观察ARP缓存是否异常。Linux下查看ARP表ip neigh show如果某个IP的MAC在短时间内不断变化或者同一个MAC对应了多个IP就很可疑。Windows下用arp -a同样可以查看。我有个习惯每次ping外网不通先ping一下网关如果网关能通但外网不通就会查一下“网关IP对应的MAC是否和我预期一致”。很多中间人攻击的初期症状就是网关MAC变了但你却不知道。交换机上也可以通过查看MAC地址表来发现异常思科、华为、华三的命令大同小异比如华为的display mac-address。如果发现一个MAC地址频繁在多个端口上跳变或者同一个IP对应的MAC在短时间内变了多次就要警惕是否有ARP攻击。更彻底的防御是在核心交换机上开启DHCP Snooping与DAI同时关闭不必要的二层协议扩展缩小攻击面。6. 从DNS到ARP一次完整访问的排障思考6.1 排障顺序先应用层还是先链路层当用户反馈“网站打不开”时大多数人会先ping一下域名如果ping不通就认为DNS解析有问题。但实际上ping域名不通可能是DNS查不到IP也可能是IP通但ICMP被防火墙拦截。正确的排障思维是分层递进先确认DNS解析是否正常再看IP层是否可达最后看链路层是否正常。具体操作上我会先执行nslookup www.example.com确认返回的IP是否符合预期。如果符合再ping IP注意这里不要ping域名因为ping域名又会触发一次DNS查询会混淆问题边界。如果ping IP能通但ping域名不通那问题几乎一定在DNS。如果ping IP也不通则可能是路由、防火墙或ARP的问题此时再去检查网关和ARP缓存。6.2 一个混合故障案例有一次办公网突然大面积反馈“访问公司官网很慢且经常超时”。我检查DNS解析一切正常返回的也是内网CDN的IP。然后ping这个IP发现丢包率很高。接下来登到核心交换机去看设备表发现该IP对应的MAC地址在多个端口之间反复横跳。再一看某个端口下新接入了一台测试用的无线路由器它把LAN口接到了办公网同时自己又开了一个DHCP服务等于在办公网里插了一个“野”DHCP服务器和二层环路。很多终端拿到错误网关和DNS内网流量被导来导去形成了广播风暴。最终处理很简单把该测试路由器从办公网断开同时在该接口上配置了端口安全和DHCP Snooping禁止私接路由器的未知DHCP报文。处理完后网络恢复。这个案例很有代表性表面上是“DNS解析慢”实际根因在链路层是二层网络中有非法设备破坏了DNS和ARP的正常工作。查网络问题一定不要死盯某一个协议要有链路思维。6.3 给运维新手的自查清单基于这些经验我整理了一份日常自查清单每次处理网络问题或做设备变更时都会过一遍。先确认客户端到DNS服务器的连通性ping DNS_IP不通则检查网络基础链路。用nslookup或者dig查询目标域名看返回IP和解析耗时是否正常。用ping IP绕过DNS判断是否为解析问题还是路由问题。查看ARP缓存确认网关IP对应MAC是否一致如果有历史记录做对比。检查交换机与路由器上的接口状态和MAC表看是否有异常飘移。如果怀疑存在ARP欺骗抓包看局域网上是否有大量ARP应答报文尤其是非广播的ARP应答。对于长期运行的服务器整理一份IP-MAC-交换机端口的绑定清单定期比对。这些步骤看起来基础但大部分耗时上小时的故障最后都能落实到清单里的某一项。大家可以在自己的环境里测试一遍遇到问题不要慌把层次拆开一步一步缩小范围。我个人在维护网络时的最大体会是DNS和ARP都是“映射管理”的协议它们最怕的是“假”。DNS会返回假IPARP会被迫接受假MAC网络里所有的不稳定十有八九都出在这些“假”上。理解了这一点你就抓住了这两个协议在流量安全中的核心位置。你不需要一次看完所有细节但可以先把今天的自查清单存下来下次遇到“能上QQ但打不开网页”之类的问题翻出来对照排查基本不会空手而归。