CentOS 7 DNS配置后无法解析域名？

Question

在CentOS 7系统中，配置完`/etc/resolv.conf`添加DNS服务器后仍无法解析域名，常见原因是网络管理服务（NetworkManager）动态覆盖了该文件。即使手动设置nameserver，重启网络或系统后DNS配置可能被重置为默认值，导致域名解析失败。此外，`systemd-resolved`与传统DNS配置冲突、防火墙阻止UDP 53端口、或DNS服务器本身不可达也会引发此问题。需检查`NetworkManager`的DNS管理策略，确保配置持久化，并验证网络连通性与DNS服务可达性。

Answer 1

CentOS 7 中 /etc/resolv.conf 配置 DNS 失效的深度解析与解决方案

1. 问题现象描述与初步排查路径

在 CentOS 7 系统中，用户常通过编辑 /etc/resolv.conf 文件添加自定义 DNS 服务器（如 nameserver 8.8.8.8），但重启网络服务或系统后发现配置被重置。典型表现为：

• ping google.com 提示“Name or service not known”
• nslookup baidu.com 返回超时或无法解析
• 手动修改 /etc/resolv.conf 后立即生效，但不久即恢复为原始内容

这表明配置未持久化，根源通常在于系统级网络管理机制对文件的动态覆盖行为。

2. 核心原因分析：NetworkManager 的 DNS 管理策略

CentOS 7 默认启用 NetworkManager 作为主要网络管理工具，其会根据连接配置自动写入 /etc/resolv.conf。以下是关键影响点：

配置项	默认值	说明
dns=	default	由 DHCP 获取 DNS 并写入 resolv.conf
ignore-auto-dns=true	false	是否忽略 DHCP 分配的 DNS
managed=true	true	NetworkManager 是否管理该连接

若未显式设置 DNS 策略，NetworkManager 将在每次网络启动时覆盖 /etc/resolv.conf，导致手动配置丢失。

3. 深层机制探究：systemd-resolved 与传统 DNS 冲突

尽管 CentOS 7 不默认启用 systemd-resolved，但在某些更新版本或最小化安装后启用 systemd-networkd 时可能引入冲突：

$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled)
   Active: inactive (dead)

若此服务处于运行状态，则它会监听 127.0.0.53:53，并将 /etc/resolv.conf 软链接至 /run/systemd/resolve/stub-resolv.conf，造成用户修改无效。可通过以下命令检查软链：

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr  5 10:20 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

4. 解决方案一：禁用 NetworkManager 对 DNS 的自动管理

确保 NetworkManager 不覆盖 DNS 配置，需修改其主配置文件：

1. 编辑 /etc/NetworkManager/NetworkManager.conf
2. 在 [main] 段落下添加：dns=none
3. 保存并重启服务：systemctl restart NetworkManager

此时 NetworkManager 将不再生成 /etc/resolv.conf，允许用户完全控制该文件。

5. 解决方案二：使用 nmcli 设置静态 DNS（推荐生产环境）

更符合 CentOS 7 设计理念的方式是通过 nmcli 命令配置 DNS，使变更被 NetworkManager 正确识别并持久化：

# 查看当前连接名称
nmcli connection show

# 为指定连接设置静态 DNS
nmcli con mod "System eth0" ipv4.dns "8.8.8.8 1.1.1.1"

# 可选：设置 DNS 搜索域
nmcli con mod "System eth0" ipv4.dns-search "example.com"

# 生效配置
nmcli con down "System eth0" && nmcli con up "System eth0"

该方法确保 DNS 配置随连接持久保存，且不受重启影响。

6. 验证 DNS 可达性与防火墙策略

即使配置正确，外部因素仍可能导致解析失败。需验证如下：

# 测试 DNS 服务器连通性（UDP 53）
dig @8.8.8.8 google.com +short

# 使用 tcpdump 抓包确认请求发出
tcpdump -i eth0 port 53 -n -c 5

# 检查防火墙是否放行 DNS
firewall-cmd --list-all | grep 53/udp

若无响应，可能是主机或上游防火墙阻止了 UDP 53 端口通信。

7. 进阶诊断流程图（Mermaid 格式）

graph TD
    A[域名解析失败] --> B{/etc/resolv.conf 是否被修改?}
    B -- 是 --> C[检查是否为软链接]
    C -- 是 --> D[停用 systemd-resolved 或重新链接]
    C -- 否 --> E[检查 NetworkManager dns 策略]
    E --> F[dns=none?]
    F -- 否 --> G[设置 dns=none 或使用 nmcli 配置]
    F -- 是 --> H[测试 dig/nslookup]
    H --> I{有响应?}
    I -- 否 --> J[检查防火墙 & 路由可达性]
    I -- 是 --> K[应用正常]
    J --> L[开放 UDP 53 或更换 DNS]

8. 持久化建议与最佳实践

为避免未来配置漂移，建议遵循以下运维规范：

• 统一使用 nmcli 管理网络配置，而非直接编辑文件
• 对关键服务器禁用 NetworkManager，改用传统 network.service
• 定期审计 /etc/resolv.conf 的 inode 与权限（chmod 644）
• 部署监控脚本检测 DNS 解析健康状态
• 在云环境中注意元数据服务（如 AWS EC2）注入 DNS 的行为

通过标准化流程可显著降低因 DNS 配置异常引发的服务中断风险。