5154

在Arch Linux这类高度可定制的发行版中，域名系统（DNS）的配置既强大又时而令人困惑，DNS作为互联网的“电话簿”，负责将我们易于记忆的域名（如www.archlinux.org）解析为机器可读的IP地址，当DNS出现故障时，我们将无法访问大多数网站和服务，本文旨在提供一个结构化的指南，帮助用户诊断并修复在Arch Linux上遇到的各类DNS问题。

理解核心问题：诊断DNS故障

在着手修复之前,准确的诊断是关键，盲目修改配置文件往往会使问题复杂化，以下是一些基础的诊断步骤和工具。

检查核心的DNS配置文件 /etc/resolv.conf，这个文件包含了系统用于查询DNS的域名服务器地址，一个典型的文件内容如下：

# /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com

这里,nameserver 指定了DNS服务器的IP地址，系统会按顺序尝试查询。search 则允许在不完整的主机名后自动附加域名。

使用命令行工具进行测试。ping 是最基本的连通性测试工具，尝试 ping 一个公网IP地址，如 ping 8.8.8.8，如果成功，说明你的网络连接是正常的，尝试 ping 一个域名，如 ping archlinux.org，如果后者失败而前者成功，问题几乎可以肯定出在DNS上。

为了获取更详细的DNS查询信息,nslookup 和 dig 是更专业的工具。nslookup 交互式且简单，而 dig 功能强大，输出信息极为详尽。

# 使用 dig 查询 archlinux.org 的 A 记录
dig archlinux.org

dig 的输出会告诉你查询的DNS服务器、响应时间、查询结果以及TTL（生存时间）等关键信息，如果这里查询超时或返回错误，就意味着DNS解析路径上存在障碍。

常见原因与修复策略

在Arch Linux中，DNS问题通常源于服务冲突或配置不当，以下是几种最常见的情况及其解决方案。

处理 /etc/resolv.conf 的“自动重置”

许多新手用户会发现,手动编辑 /etc/resolv.conf 后，更改在重启或网络重连后会丢失，这是因为该文件通常由其他服务动态管理，主要的管理者包括 systemd-resolved、NetworkManager 和 dhcpcd。

解决方案： 你需要确定由哪个服务来管理DNS，并使其配置持久化。

• 方案A：交由 systemd-resolved 管理 systemd-resolved 是一个系统服务，它提供了一个本地DNS存根，要使用它，首先确保服务已启用：

  sudo systemctl enable --now systemd-resolved

  将 /etc/resolv.conf 替换为一个指向 systemd-resolved 存根文件的符号链接：

  sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

  此后,/etc/resolv.conf 的内容将由 systemd-resolved 自动维护，你应通过编辑 /etc/systemd/resolved.conf 来配置上游DNS服务器。

• 方案B：交由 NetworkManager 管理 如果你使用图形化桌面环境，NetworkManager 很可能是网络的管理者，你可以通过其图形界面或 nmcli 命令行为特定连接设置DNS。

  # 为 'wlan0' 连接设置固定的DNS服务器
  nmcli connection modify 'wlan0' ipv4.dns "8.8.8.8 1.1.1.1"
  nmcli connection up 'wlan0'

  确保在 /etc/NetworkManager/NetworkManager.conf 中 [main] 部分没有 dns=none 这一行，否则它将不会管理 /etc/resolv.conf。

systemd-resolved 与其他服务的冲突

有时,systemd-resolved 和 NetworkManager（或 dhcpcd）会同时尝试管理 /etc/resolv.conf，导致冲突和混乱。

解决方案： 选择一个服务作为唯一的DNS管理者，禁用或配置另一个服务放弃管理权。

• 禁用 systemd-resolved：如果你更倾向于让 NetworkManager 或 dhcpcd 全权处理，可以完全禁用 systemd-resolved。

  sudo systemctl disable --now systemd-resolved
  sudo rm /etc/resolv.conf  # 删除可能存在的符号链接
  # NetworkManager 或 dhcpcd 会在下次网络连接时重新生成一个标准的 /etc/resolv.conf

下表小编总结了主要网络服务与DNS管理的关系：

防火墙干扰

虽然不常见,但配置不当的防火墙（如 ufw 或 iptables）可能会阻止DNS查询所使用的端口（UDP 53，有时也包括TCP 53）。

解决方案： 为了快速验证，可以临时禁用防火墙并测试DNS是否恢复正常。

# 以 ufw 为例
sudo systemctl stop ufw
dig archlinux.org
# 如果恢复正常，说明是防火墙规则问题
sudo systemctl start ufw

确认后,你需要添加规则以允许DNS流量，对于 ufw，通常是：

sudo ufw allow out 53

高级方案与最佳实践

对于追求更高性能和隐私性的用户,可以考虑使用加密DNS工具，如 dnscrypt-proxy 或 stubby，这些工具作为本地服务运行，将你的DNS查询通过加密协议（如DoH或DoT）发送给上游服务器，防止被窃听或篡改，配置这些工具通常涉及安装软件包、编辑其配置文件，然后将 /etc/resolv.conf 指向其本地监听地址（如 0.0.1）。

相关问答FAQs

问题1：为什么我每次手动修改 /etc/resolv.conf 后，重启网络或系统后文件就恢复了原样？ 解答： 这是因为你的系统中有网络管理服务（如 systemd-resolved, NetworkManager, dhcpcd）在运行，它们的职责之一就是根据网络状态自动生成和维护 /etc/resolv.conf 文件，你直接修改的文件会被这些服务在下次网络事件（如重启、重新连接）时覆盖，正确的做法不是直接编辑该文件，而是去配置管理它的那个服务，若由 systemd-resolved 管理，应编辑 /etc/systemd/resolved.conf 并确保 /etc/resolv.conf 是指向其存根文件的符号链接；若由 NetworkManager 管理，则应使用 nmcli 或图形界面来设置DNS。

问题2：我可以 ping 8.8.8.8，但无法 ping google.com，这究竟意味着什么？ 解答： 这是一个非常典型的DNS故障症状，能够 ping 8.8.8.8（一个公共IP地址）证明你的计算机到互联网的物理链路是通畅的，你的网卡、路由器、ISP连接都没有问题，无法 ping google.com（一个域名）则意味着你的计算机无法将 google.com 这个域名翻译成对应的IP地址，这直接指向了DNS解析环节的故障，问题可能出在 /etc/resolv.conf 配置错误、指定的DNS服务器无响应或被防火墙阻止，或者负责DNS解析的系统服务（如 systemd-resolved）运行不正常，你的排查重点应完全集中在DNS配置和服务上。