dns-nameservers配置后无法解析域名？

Question

在Linux系统中，配置`dns-nameservers`后仍无法解析域名是常见问题。典型场景为：在`/etc/network/interfaces`中正确设置`dns-nameservers 8.8.8.8`，但重启网络服务后`/etc/resolv.conf`未更新或被覆盖，导致域名解析失败。此问题多因NetworkManager、systemd-resolved或dhclient等服务动态管理DNS所致。解决方法包括禁用冲突服务、使用`resolvconf`工具维护配置，或改用`netplan`（Ubuntu 18.04+）统一管理网络设置，确保DNS配置持久生效。

Answer 1

Linux系统中配置dns-nameservers后域名解析失败的深度剖析与解决方案

1. 问题现象：看似正确的DNS配置为何无效？

在Debian/Ubuntu等基于/etc/network/interfaces的传统网络配置体系中，用户常通过添加dns-nameservers 8.8.8.8来指定DNS服务器。然而，即使语法正确且服务重启，执行cat /etc/resolv.conf时却发现文件内容未更新或被重置为默认值，导致ping google.com等命令提示“Name or service not known”。

该现象的核心在于：/etc/resolv.conf并非静态文件，而是由多个动态服务协同生成的结果。

2. 根本原因分析：谁在控制/etc/resolv.conf？

现代Linux发行版普遍采用多层网络管理机制，以下服务可能介入DNS配置：

• dhclient：DHCP客户端，在获取IP时自动写入DHCP提供的DNS
• NetworkManager：桌面环境常用，优先级高，会覆盖interfaces配置
• systemd-resolved：作为DNS Stub Listener运行于127.0.0.53，代理所有DNS请求
• resolvconf：元工具，协调多个服务对resolv.conf的写入权限

服务名	默认启用场景	是否覆盖interfaces	配置文件路径
dhclient	DHCP模式接口	是	/etc/dhcp/dhclient.conf
NetworkManager	桌面版Ubuntu/CentOS	强覆盖	/etc/NetworkManager/NetworkManager.conf
systemd-resolved	systemd系统（多数现代发行版）	间接覆盖	/etc/systemd/resolved.conf
resolvconf	需手动安装启用	协调而非覆盖	/etc/resolvconf/resolv.conf.d/base

3. 排查流程图：系统化诊断DNS配置冲突

```mermaid
graph TD
    A[开始排查] --> B{是否使用/etc/network/interfaces?}
    B -- 是 --> C[检查dns-nameservers是否在iface块内]
    B -- 否 --> D[转向Netplan或NetworkManager配置]
    C --> E[重启网络: systemctl restart networking]
    E --> F[查看/etc/resolv.conf内容]
    F --> G{是否仍为旧值或空?}
    G -- 是 --> H{是否存在NetworkManager?}
    H -- 是 --> I[停止并禁用NetworkManager]
    H -- 否 --> J{是否启用systemd-resolved?}
    J -- 是 --> K[配置resolved并链接stub]
    J -- 否 --> L[启用resolvconf工具]
    G -- 否 --> M[问题解决]
    I --> N[systemctl disable NetworkManager]
    K --> O[修改resolved.conf + ln -sf]
    L --> P[echo 'nameserver 8.8.8.8' > /etc/resolvconf/resolv.conf.d/base]
    P --> Q[update-resolvconf]
    ```

4. 解决方案一：统一使用resolvconf机制（兼容性最佳）

适用于仍使用/etc/network/interfaces但受其他服务干扰的场景。步骤如下：

1. 安装resolvconf：sudo apt install resolvconf
2. 编辑基底DNS：sudo nano /etc/resolvconf/resolv.conf.d/base
3. 添加内容：
   nameserver 8.8.8.8
nameserver 1.1.1.1
4. 更新配置：sudo resolvconf -u
5. 验证：cat /etc/resolv.conf 应包含上述DNS

此方法优势在于能兼容dhclient、NetworkManager等多种来源，由resolvconf统一输出最终配置。

5. 解决方案二：迁移到Netplan（Ubuntu 18.04+推荐）

Netplan作为YAML驱动的声明式网络配置工具，已成为Ubuntu标准。示例配置（/etc/netplan/01-netcfg.yaml）：

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

应用配置：sudo netplan apply。Netplan会自动与systemd-networkd或NetworkManager集成，避免配置漂移。

6. 高级调优：systemd-resolved的正确使用方式

若系统已启用systemd-resolved，建议将其作为中心化DNS缓存服务：

• 编辑/etc/systemd/resolved.conf：

• [Resolve]
  DNS=8.8.8.8 1.1.1.1
  FallbackDNS=9.9.9.9
  # 关闭Stub Listener以直接暴露真实DNS
  # DNSStubListener=no
  

• 重启服务：systemctl restart systemd-resolved
• 建立符号链接：ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

此举可提升DNS查询性能，并集中管理所有接口的DNS策略。

7. 实战案例：混合环境中DNS配置的持久化保障

某企业服务器同时运行Docker、Kubernetes与传统应用，频繁出现容器内DNS超时。经排查发现：

• 宿主机使用DHCP获取网络
• dhclient每次更新均写入私有DNS（如10.0.0.2）
• 容器继承错误DNS导致外网解析失败

解决方案：

1. 在/etc/dhcp/dhclient.conf中注释supersede domain-name-servers
2. 启用resolvconf并固定公共DNS
3. 配置Docker daemon使用自定义dns字段

最终实现全栈DNS一致性，杜绝动态覆盖问题。