Linux下dhcpd配置DNS后客户端无法解析怎么办，dhcpd域名解析失败如何解决？

dhcpd 配置了 DNS 客户端却无法解析域名，多数情况下问题不在 dhcpd 服务本身，而是客户端仍在使用旧租约中缓存的 DNS 地址，或者 resolv.conf 被 NetworkManager 覆盖重置，先排查这两处远比反复修改 dhcpd.conf 更有效率。

dhcpd 下发DNS不生效 客户端无法解析怎么排查

遇到 dhcpd 已经配置了域名解析、客户端也正常拿到了 IP，但 ping 域名报 “名称解析暂时失败”，先按下面的顺序走一遍，大多数场景能在三步内定位。

1. 检查 dhcpd 配置语法是否真实生效，在 DHCP 服务器上执行 dhcpd -t -cf /etc/dhcp/dhcpd.conf，如果提示 option domain-name-servers 相关报错，多半是 IP 地址格式写错或容器内未加载配置。
2. 查看客户端租约文件的实际内容,以 CentOS/RHEL 为例，cat /var/lib/NetworkManager/dhclient-eth0.leases，Debian/Ubuntu 则看 /var/lib/dhcp/dhclient.leases，如果里面记录的 domain-name-servers 还是修改前的旧 IP，说明服务端新配置根本没送达。
3. 对比客户端 /etc/resolv.conf，如果文件内容与租约文件不一致，说明有第三方程序在托管这个文件，后续处理思路完全不同。

行业共识认为,这类问题的核心难点不是 dhcpd 服务不会发 DNS，而是 DHCP 协议本身的续租机制让客户端“赖着旧配置不放”。

dhcpd 配置了DNS 客户端不解析 大概率是租约还在“续命”

DHCP 客户端不会每次开机都走完整的四步握手，租约时间过半时，客户端直接向服务器发送 DHCPREQUEST 要求续租，此时如果服务器端的 dhcpd.conf 没有重启，服务端仍按旧配置响应续租请求，客户端自然拿不到新的 DNS 地址。

具体场景可以还原一下：你在 /etc/dhcp/dhcpd.conf 里把 option domain-name-servers 从 114.114.114.114 改成了 223.5.5.5，保存文件后只是习惯性 systemctl restart dhcpd，但没有让客户端主动重新获取地址，服务端重启后虽然配置新了，但客户端的续租请求早于重启完成，租约到期前它不会心平气和地重新请求一次完整分配。

操作上,建议在服务端和客户端两侧各做一次强制动作。

• 服务端：重启 dhcpd 后立刻用 tail -f /var/log/messages 或 journalctl -u dhcpd -f

  

  观察有没有客户端新请求进入。

• 客户端：先释放地址再重新获取，CentOS 执行 dhclient -r eth0 && dhclient eth0，Ubuntu 执行 dhclient -r eth0 后用 nmcli device reapply eth0，或者干脆重启网络服务。
• 租约文件清理：删除客户端 dhclient.leases 文件后重启网络，可以彻底抛弃旧租约，删除前备份一个副本，如果公司对 DHCP 有审计要求，别删。

如果客户端拿到新租约后解析恢复,那这单子就结了，但还有一类情况：租约没问题，dhclient.leases 里记录的 DNS 也是新地址，客户端仍然解析失败这时候要盯住 resolv.conf 的归属权。

resolv.conf 被覆盖 即使dhcpd配置了DNS也白搭

我在帮一台 Ubuntu 22.04 工作站排查时，conf 里已经确认是 223.5.5.5，租约文件也对得上，但客户端 cat /etc/resolv.conf 显示的却是 127.0.0.53，这是 systemd-resolved 在系统里充当本地 DNS 转发的典型表现，resolv.conf 是指向 /run/systemd/resolve/stub-resolv.conf 的软链接，把本机地址作为 DNS 写入，这种架构本身没有错，但如果你期望客户端直接使用 dhcpd 下发的公网 DNS，就需要在 systemd-resolved 层面把配置打通。

还有一种更常见的覆盖场景是 NetworkManager 接管，多数桌面版 Linux 默认启用 NetworkManager，它会根据连接配置里的 ipv4.dns 设置重写 resolv.conf，即使 dhcpd 通过 DHCP 下发了 DNS，NetworkManager 的默认策略是“使用 DHCP 推送的 DNS”，但如果你在连接配置里手动指定过 DNS，或者开启了 ipv4.ignore-auto-dns，下级配置与 DHCP 上配置会产生冲突。

验证方法和修复路径比较明确：

• 用 nmcli device show eth0 查看当前连接实际生效的 DNS 值。
• 用 ls -l /etc/resolv.conf 判断它是不是软链接，指向什么。
• 若看到 ../run/systemd/resolve/stub-resolv.conf，说明走的是 systemd-resolved，执行 resolvectl status 看 Current DNS Server 是哪台。
• 想强制使用 dhcpd 下发的 DNS，在 NetworkManager 连接里执行 nmcli connection modify 加上 ipv4.dns 223.5.5.5、ipv4.ignore-auto-dns no，随后 systemctl restart NetworkManager。

处理完这台机器后,我顺手检查其余十几台客户端，发现有三台的文件头写着 “Generated by NetworkManager”，这类问题的比例在混合桌面环境中不容小觑，近年来的排障经验表明，resolv.conf 被覆盖占了 DHCP 解析问题的一半以上。

从抓包确认dhcpd分配DNS是否真实到达客户端

如果上述两步都排查干净了,客户端依然无法解析，那就用抓包把 DNS 选项从 DHCP 报文里捞出来看，不需要用什么重型工具，tcpdump 就够。

先在客户端执行释放租约的操作,同时在 DHCP 服务器上抓包：

tcpdump -i eth0 port 67 or port 68 -nn

然后回到客户端重新获取地址,重点关注服务器返回的 DHCPACK 报文，展开报文末尾的 Domain Name Server Option，如果这个选项里是空值或缺失，说明 dhcpd 确实没有把 DNS 打包进分配响应，问题在服务器配置侧。

此时回头检查 dhcpd.conf 文件，常见原因有两个。

option domain-name-servers 写在了 subnet 声明块之外，配置层级大意不得，subnet 块的选项定义优先级高于全局，但如果写在全局位置而 subnet 内定义了空数组，等于没写。

配置文件里写的是 option domain-name-servers 223.5.5.5, 114.114.114.114; 但少了末尾分号，或者两个地址之间用了空格而非逗号，DHCP 服务端对这类语法非常敏感，dhcpd -t 检语法时通常能报错，有些版本只警告但不会拒绝启动，报文里这个选项就被丢弃了。

抓包看到 ACK 里已包含 DNS 但仍解析失败，接下来就该检查该网段的网关是否屏蔽了对外发往 UDP/53 端口的流量，有一种隐蔽情况是运维人员在核心交换机上做了基于 DHCP 网段的 ACL，只放行特定 DNS 服务器 IP，而 dhcpd 下发的 DNS 并不在其中，此时客户端 IP 和 DNS 都正常，但查询请求被网关截断，这种问题在跨网段环境中比较突出，单纯的 dhcpd 服务器抓包看不出端倪，需要拉通网络设备日志辅助定位。

dhcpd 监听网卡选错会导致配置下发无效

多网卡服务器上部署 dhcpd 时，容易忽略 /etc/default/dhcpd 或 /etc/sysconfig/dhcpd 文件里的 INTERFACESv4 参数，如果默认的 INTERFACESv4 没有显式指定实际承载客户端的网卡，dhcpd 可能只监听 eth0，而客户端业务跑在 eth1 上，这个时候客户端获取 IP 的方式如果走 IP Helper 或 DHCP 中继，链路大概率是通的，但 DNS 选项会从错误的网卡配置中读取，结果就是拿到一个不在期望网段范围内的 DNS。

检查方法简单：先看 /etc/dhcp/dhcpd.conf 里共享网络的配置，然后确认默认配置文件里监听的网卡名称，再对比 ip addr 里实际地址，三者必须对齐，我遇到过一次 eth0 和 eth1 都配置了 DHCP 服务的情况，eth0 的配置里漏写了 DNS 选项，而中继把请求转发到了 eth0，客户端自然拿到空的 DNS。

这里也可以顺手核对 dhcpd 服务是否启动了多个实例，端口冲突时新配置无法生效，执行 ss -ulpn | grep :67 检查端口占用，如果有其他 DHCP 进程，优先停掉旧实例。

dhcpd 与客户端域名解析 相关疑问解答

dhcpd 配置了DNS 客户端为什么还用旧地址？
最直接的原因是客户端租约尚未到期，DHCPREQUEST 续租在租约过半时触发，服务器未重启导致响应仍按照旧配置打包，解决方法是服务端重启 dhcpd，随后客户端释放并重新获取租约，建议清理 dhclient.leases 文件排除缓存干扰。

dhcpd 服务器本机能解析，客户端不行，问题在哪？
服务器本机解析依赖 /etc/resolv.conf 或系统解析配置，与 DHCP 报文下发的 DNS 没有关系，如果客户端确实收到了 DHCPACK 且报文含 DNS 选项，则问题要么在系统层面的解析服务（NetworkManager 覆盖、systemd-resolved 接管）覆盖了租约配置，要么在客户端所在网段的网络设备对 DNS 协议做了策略管控。

dhcpd 更换了DNS 地址后需要重启服务吗？
需要重启，但重启只影响后续新分配的租约或客户端续租行为，已持有旧租约的客户端在租约到期前不会主动请求新配置，只能靠客户端释放重新获取或等待租约自然过期，两者取时间上更早发生的那一个为实际生效点。

如果把 dhcpd 比作快递员，它要派送的包裹就是客户端的网络参数，DNS 地址只是其中一个选项，包裹丢没丢、收件人是否签收，取决于链路各环节的配合，先从租约和 resolv.conf 入手排查这几条主线问题，多数情况下都能快速定位，不需要动配置文件的大手术。