systemd-resolved 实战：解决 DNS 解析疑难杂症及性能优化

内容摘要：systemd-resolved 实战：解决 DNS 解析疑难杂症及性能优化,

在使用 Linux 服务器的过程中，DNS 解析问题经常让人头疼。例如，明明配置了 DNS 服务器，但服务却无法正常解析域名，或者解析速度慢如蜗牛。systemd-resolved.service 作为 systemd 的一部分，负责系统的域名解析，它的配置不当或者理解不深入，就容易引发各种问题。本文将深入探讨 systemd-resolved.service 的原理和配置，并通过实际案例，教你如何利用它解决 DNS 解析难题。

问题场景重现：域名解析超时与失败

假设我们遇到这样一个场景：服务器部署了 Nginx 服务，Nginx 配置了反向代理，需要解析一个外部域名才能正常工作。然而，Nginx 启动后却无法正常代理，查看 Nginx 日志，发现大量的域名解析超时或失败的错误。

[error] 2345#0: *1 upstream timed out (110: Connection timed out) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: , request: "GET / HTTP/1.1", upstream: "http://your_domain.com/", host: "your_domain.com"

通常，我们会首先检查 /etc/resolv.conf 文件，确认 DNS 服务器是否正确配置。但即使配置正确，问题仍然存在，这很可能与 systemd-resolved.service 的配置有关。

底层原理深度剖析：systemd-resolved 的工作机制

systemd-resolved 是一个本地 DNS 解析器服务，它提供了本地应用程序的域名解析服务。其核心原理如下：

1. 监听端口 53：systemd-resolved 默认监听 127.0.0.53:53 端口，作为本地 DNS 服务器。
2. 管理 /etc/resolv.conf：systemd-resolved 可以通过不同的模式管理 /etc/resolv.conf 文件，例如 stub-resolver 模式会创建一个指向 127.0.0.53 的 resolv.conf 文件。
3. 支持 DNSSEC：systemd-resolved 支持 DNSSEC 验证，提高了域名解析的安全性。
4. 缓存 DNS 记录：systemd-resolved 会缓存 DNS 记录，加快解析速度。
5. 优先使用本地配置：systemd-resolved 优先使用 /etc/systemd/resolved.conf 和网络接口配置中指定的 DNS 服务器。

理解了这些原理，我们才能更好地配置和调试 systemd-resolved。

/etc/resolv.conf 的管理模式

systemd-resolved 可以通过不同的模式管理 /etc/resolv.conf 文件，常见的模式有：

• stub-resolver：这是默认模式，会创建一个指向 127.0.0.53 的 resolv.conf 文件。应用程序通过 127.0.0.53 与 systemd-resolved 通信。
• static：禁用 systemd-resolved 对 /etc/resolv.conf 的管理，用户需要手动配置 /etc/resolv.conf。
• auto：systemd-resolved 根据网络接口配置自动管理 /etc/resolv.conf。

具体的代码/配置解决方案：优化 DNS 解析

针对上述域名解析超时的问题，我们可以采取以下步骤进行排查和解决：

1. 检查 systemd-resolved 状态：

systemctl status systemd-resolved

确保 systemd-resolved 服务正在运行。

2. 查看当前 DNS 配置：

resolvectl status

这个命令会显示当前系统使用的 DNS 服务器、DNSSEC 状态等信息。确认 DNS 服务器地址是否正确。

3. 修改 DNS 服务器：

如果发现 DNS 服务器不正确，可以通过以下方式修改：

*   **修改 `/etc/systemd/resolved.conf` 文件**：

[Resolve]
DNS=8.8.8.8 114.114.114.114
#FallbackDNS=8.8.4.4
#Domains=~.

    将 `DNS` 设置为可用的公共 DNS 服务器，例如 Google DNS (8.8.8.8, 8.8.4.4) 或国内的 114 DNS (114.114.114.114)。

*   **重启 `systemd-resolved` 服务**：

systemctl restart systemd-resolved

*   **确认 DNS 配置生效**：

resolvectl status

4. 绕过 systemd-resolved (不推荐，作为应急方案)： 如果 systemd-resolved 服务本身存在问题，可以考虑直接修改 /etc/resolv.conf 文件，将其指向可用的 DNS 服务器。但是，这种方式会绕过 systemd-resolved 的管理，可能导致其他问题。 修改前备份：

cp /etc/resolv.conf /etc/resolv.conf.bak

然后编辑 /etc/resolv.conf 文件:

nameserver 8.8.8.8
nameserver 114.114.114.114

如果想让 /etc/resolv.conf 的修改永久生效，需要修改 NetworkManager 的配置。或者将 /etc/systemd/resolved.conf 中的 DNSStubListener 设置为 no，并重启服务。

5. Nginx 配置检查：

确保 Nginx 配置文件中的域名正确，并且 Nginx 用户有权限访问 /etc/resolv.conf 文件。

实战避坑经验总结：常见问题与解决方案

1. /etc/resolv.conf 被覆盖：

   systemd-resolved 可能会覆盖 /etc/resolv.conf 文件，导致手动配置的 DNS 失效。解决方法是修改 /etc/systemd/resolved.conf 文件，或者禁用 systemd-resolved 对 /etc/resolv.conf 的管理。

2. DNSSEC 验证失败：

   如果启用了 DNSSEC 验证，但 DNS 服务器不支持 DNSSEC，会导致域名解析失败。解决方法是禁用 DNSSEC 验证，或者更换支持 DNSSEC 的 DNS 服务器。

   

3. 缓存问题：

   systemd-resolved 的缓存可能导致解析结果不正确。可以使用 resolvectl flush-caches 命令刷新缓存。

4. 与 NetworkManager 冲突：

   systemd-resolved 和 NetworkManager 可能会争夺 /etc/resolv.conf 的管理权。解决方法是配置 NetworkManager，使其与 systemd-resolved 协同工作。

5. 容器环境下的 DNS 问题：

   在 Docker 等容器环境中，需要确保容器能够访问宿主机的 DNS 服务。可以通过配置 Docker 的 --dns 参数来实现。

通过上述方法，可以有效地解决 systemd-resolved.service 引起的 DNS 解析问题，提升服务器的稳定性和性能。同时，对 Nginx 的反向代理、负载均衡等功能也能起到保障作用。在高并发场景下，合理配置 DNS 解析，能够有效降低延迟，提升用户体验。