systemd-resolved DNS解析失败如何排查？

Question

当使用 systemd-resolved 服务时，常见问题之一是 DNS 解析失败，表现为域名无法解析但 IP 直连正常。典型症状包括 `ping example.com` 超时而 `ping 8.8.8.8` 成功，且 `/etc/resolv.conf` 指向 127.0.0.53。需确认 systemd-resolved 是否运行（`systemctl status systemd-resolved`），检查其配置文件 `/etc/systemd/resolved.conf` 中 DNS 服务器设置是否正确，并验证网络管理器是否与其集成。此外，缓存污染或上游 DNS 不可达也会导致解析失败，可尝试重启服务并使用 `resolvectl status` 查看链路状态与 DNS 服务器响应情况。

Answer 1

systemd-resolved DNS解析失败问题深度排查与解决方案

1. 问题现象概述

在使用 systemd-resolved 服务的 Linux 系统中，常见的网络故障表现为：域名无法解析，但 IP 地址直连正常。典型症状包括：

• ping example.com 超时或报“Name or service not known”
• ping 8.8.8.8 成功，证明网络层通畅
• /etc/resolv.conf 文件内容指向 nameserver 127.0.0.53
• 浏览器、curl、wget 等应用均无法通过域名访问资源

这表明问题出在本地 DNS 解析环节，而非底层网络连接。

2. 初步诊断流程

首先确认 systemd-resolved 服务是否处于运行状态：

systemctl status systemd-resolved

若服务未运行，常见输出为：

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Mon 2025-04-05 10:20:15 UTC; 5min ago

此时应启动服务：sudo systemctl start systemd-resolved 并设置开机自启。

3. 配置文件检查与验证

核心配置位于 /etc/systemd/resolved.conf，其关键字段如下：

配置项	说明	推荐值示例
DNS=	指定上游 DNS 服务器	8.8.8.8 1.1.1.1
FallbackDNS=	备用 DNS 服务器	9.9.9.9 208.67.222.222
Domains=	搜索域配置	~.
LLMNR=	链路本地多播名称解析	yes/no
Cache=	启用本地缓存	yes

修改后需重启服务：sudo systemctl restart systemd-resolved

4. 网络管理器集成状态分析

NetworkManager 默认会与 systemd-resolved 协同工作。可通过以下命令查看当前 DNS 来源：

nmcli dev show | grep DNS

若输出为空或仍指向旧 DNS（如 DHCP 提供），则需调整 NetworkManager 配置：

sudo nmcli con modify <connection-name> ipv4.dns-options "use-dnsmasq=no"

并设置 DNS 模式为 systemd-resolved：

sudo nmcli con modify <connection-name> ipv4.dns-priority -50

最后重新加载连接：nmcli con down <conn> && nmcli con up <conn>

5. 使用 resolvectl 进行深度诊断

resolvectl status 是诊断 systemd-resolved 的核心工具，输出包含：

• Global DNS 设置（全局 DNS 服务器）
• Link-specific DNS（各网卡独立配置）
• Current Scopes（当前活跃作用域）
• Transaction Statistics（查询成功率统计）

示例输出节选：

Link 2 (enp0s3):
      Current Scopes: DNS
      DNS Server: 8.8.8.8
      DNS Domain: ~.

若显示 “No DNS Servers configured”，说明配置未生效。

6. 缓存污染与上游可达性检测

systemd-resolved 启用缓存机制，可能因缓存污染导致错误响应。清除缓存命令：

sudo resolvectl flush-caches

同时验证上游 DNS 是否可达：

dig @8.8.8.8 google.com

或使用 tcpdump 抓包分析：

sudo tcpdump -i lo port 53

观察是否有来自 127.0.0.53 的 DNS 查询发出及响应返回。

7. 故障排查流程图（Mermaid）

graph TD
            A[域名无法解析] --> B{/etc/resolv.conf 指向 127.0.0.53?}
            B -- 是 --> C[检查 systemd-resolved 状态]
            B -- 否 --> Z[调整 symlink 指向 /run/systemd/resolve/resolv.conf]
            C --> D{服务运行中?}
            D -- 否 --> E[启动服务: systemctl start systemd-resolved]
            D -- 是 --> F[执行 resolvectl status]
            F --> G{显示有效 DNS 服务器?}
            G -- 否 --> H[检查 resolved.conf 配置]
            G -- 是 --> I[测试 dig @127.0.0.53 example.com]
            I --> J{成功?}
            J -- 否 --> K[检查防火墙/上游 DNS 可达性]
            J -- 是 --> L[应用层兼容性检查]

8. 常见陷阱与最佳实践

1. 手动修改 /etc/resolv.conf：直接编辑该文件将被覆盖，应通过配置管理工具或 systemd-networkd 控制。
2. DNS 回退策略失效：确保 FallbackDNS 设置合理，避免单点故障。
3. 容器环境冲突：Docker 默认绕过 systemd-resolved，需配置 daemon.json 使用 host 网络或自定义 DNS。
4. IPv6 优先问题：某些场景下 AAAA 查询超时拖慢整体解析，可临时禁用 IPv6 解析。
5. SELinux/AppArmor 限制：安全模块可能阻止 resolved 访问网络，需审计日志排查。
6. 多网卡场景 DNS 冲突：不同接口配置不同 DNS，可能导致路由混乱，建议统一管理。
7. 时间同步影响 TLS 域名验证：虽非直接 DNS 问题，但证书校验失败常误判为解析错误。

9. 日志分析与调试技巧

启用调试日志有助于定位深层问题：

sudo journalctl -u systemd-resolved -f

关注关键词：

• "Using DNS server XXX for interface XXX" —— DNS 分配确认
• "Message failed to match incoming query" —— DNS 协议异常
• "Lost connection to DNS server" —— 上游中断
• "Too many concurrent queries" —— 性能瓶颈

可临时增加日志级别：Environment=SYSTEMD_LOG_LEVEL=debug 在服务单元文件中。

10. 自动化健康检查脚本示例

部署定期巡检脚本，提升运维效率：

#!/bin/bash
    if ! systemctl is-active --quiet systemd-resolved; then
        echo "systemd-resolved is not running. Restarting..."
        systemctl restart systemd-resolved
    fi

    if ! resolvectl query google.com >/dev/null 2>&1; then
        echo "DNS resolution failed. Flushing cache..."
        resolvectl flush-caches
        sleep 2
        if ! resolvectl query google.com >/dev/null 2>&1; then
            echo "Still failing. Restarting service..."
            systemctl restart systemd-resolved
        fi
    fi
    

可结合 cron 每5分钟执行一次，实现主动恢复。