企业官网建设流程全解析

开局先聊一个特别常见的场景：电脑突然打不开网页了，你顺手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\hosts，Linux在 /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地址。ARP（Address 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应答是单播的。但也有一种特殊情况叫免费ARP（Gratuitous ARP），主机开机或IP地址变更时主动广播自己的IP和MAC映射，目的是告诉别人“我来了，如果有冲突赶紧告诉我”，同时让交换机更新自己的MAC地址表。

第二，ARP表是有老化时间的。Windows系统默认的ARP缓存超时时间在2到10分钟之间，动态条目超过这个时间没被使用就会被删除，下次通信需要重新解析。这就解释了为什么你ping同网段的一台机器，第一次ping会慢一下（因为要先走ARP解析），后面就快了（缓存命中了）。

第三，ARP只工作在同一个网段内。跨网段通信时，你请求的是网关的MAC地址，而不是目标主机的MAC地址。数据帧先发给网关，由网关负责转发到目标网段。这是一个很多新手容易混淆的点。

2.3 DNS和ARP在数据链路中的衔接关系

把两个协议串起来看。你访问www.example.com，DNS解析出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。你手动在文件里改了nameserver，NetworkManager一刷新，又会把DHCP下发的DNS配置写回去。

正确的改法取决于你的系统版本和网络管理方式。CentOS 7及以前的版本，修改 /etc/sysconfig/network-scripts/ifcfg-eth0（具体文件名看你网卡名），在里面加一行 DNS1=114.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记录）。右键区域，选择“新建主机”，名称填主机名（比如www），IP地址填对应的内网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接主机A（192.168.1.1/24），R1的e0/1接R2的e0/0（两个接口都是10.0.0.0/24网段），R2的e0/1接主机B（192.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.2（R2）。此时R1查看自己的ARP缓存，如果没有R2的10.0.0.2的MAC映射，就再发一个ARP广播——这次是发在R1和R2之间的网段上。

第四组，R2回应ARP，R1重新封装数据帧，目的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和Let's Encrypt验证报错

“ce: -90100 cloudcom dns error 1006”这类报错通常出现在使用华为云CloudDNS时API调用返回异常，1006一般是权限校验失败或区域参数不匹配。排查思路是：先确认API凭证有没有过期，再看调用的区域（Region）跟域名所在的区域是否一致，最后看域名是不是在托管区里存在。

“during secondary validation: dns problem: networking error looking up a for”这个报错来自Let's Encrypt证书申请过程。申请证书验证域名所有权时，Let's Encrypt的服务器反向查询你的域名A记录，发现查到了多个IP或者查询超时。

处理方式通常是：确认域名的A记录配置正确且是公网可达的IP，确认TTL不要设太短（至少300秒以上），确认没有配置多条有冲突的A记录。还需要检查防火墙是否限制了外部对DNS查询的访问，有些云安全组默认只放行了TCP/UDP 53的入方向流量，但Let's 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检测（DAI，Dynamic 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方面，防劫持的思路是端到端加密。现在主流浏览器和系统已经在推DoH（DNS over HTTPS）、DoT（DNS 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、模拟器都是免费的工具，随便搭个实验环境就能验证我上面说的所有内容。多动手折腾几次，比看十篇文章都管用。