Temporary failure in name resolution 但可 ping 127.0.0.53

Question

一台Ubuntu服务器出现“Temporary failure in name resolution”错误，无法解析域名，但能成功ping通127.0.0.53。该地址是systemd-resolved提供的本地DNS stub监听地址，表明DNS客户端配置指向了本地，但后端实际DNS服务器未正确配置或服务异常。常见原因包括：/etc/resolv.conf被错误配置或指向了无效的上游DNS，systemd-resolved服务未运行，或网络管理器覆盖了DNS设置。需检查resolved服务状态、配置文件一致性及上游DNS连通性。

Answer 1

1. 问题现象与初步诊断

当一台Ubuntu服务器出现“Temporary failure in name resolution”错误时，最常见的表现是无法通过域名访问外部服务（如curl google.com失败），但可以成功执行ping 127.0.0.53。该IP地址是systemd-resolved服务提供的本地DNS stub监听地址，说明系统的DNS客户端配置已指向本地解析器。

这种现象表明：系统尝试通过本地DNS stub resolver进行解析，但后端DNS服务未能正确响应或未启动，导致最终解析失败。

• DNS查询路径为：应用 → /etc/resolv.conf → 127.0.0.53 → systemd-resolved → 上游DNS
• 若其中任一环节中断，则会出现临时解析失败

2. 核心机制分析：systemd-resolved 工作原理

systemd-resolved是现代Ubuntu系统中默认启用的本地DNS解析守护进程。它提供了一个统一的DNS管理接口，并支持LLMNR、mDNS和DNSSEC等功能。

其核心组件包括：

组件	作用
/etc/resolv.conf	指向127.0.0.53作为nameserver
/run/systemd/resolve/stub-resolv.conf	供stub resolver使用的上游DNS配置
/run/systemd/resolve/resolv.conf	完整版resolv.conf（不含stub）
systemd-resolved.service	DNS解析主服务
NetworkManager	可能覆盖DNS设置

3. 常见故障原因分类

根据实际运维经验，导致此类问题的主要原因可归纳如下：

1. systemd-resolved服务未运行：服务崩溃或被禁用
2. /etc/resolv.conf配置异常：被手动修改或符号链接损坏
3. 上游DNS服务器不可达：网络策略限制或DNS宕机
4. NetworkManager覆盖配置：动态重写resolv.conf
5. DNS缓存污染或超时：临时性网络抖动引发连锁反应
6. 防火墙阻断UDP 53端口：影响与上游通信
7. IPv6 DNS配置错误：双栈环境下优先尝试IPv6失败
8. SELinux/AppArmor策略限制（较少见）
9. 容器环境冲突：Docker等覆盖主机DNS
10. 多网卡路由混乱：DNS请求走错出口

4. 排查流程图（Mermaid格式）

```mermaid
graph TD
    A[出现 'Temporary failure in name resolution'] --> B{能否 ping 127.0.0.53?}
    B -->|Yes| C[检查 systemd-resolved 服务状态]
    B -->|No| D[修复 /etc/resolv.conf 指向 127.0.0.53]
    C --> E{systemctl is-active systemd-resolved}
    E -->|inactive| F[启动服务: systemctl start systemd-resolved]
    E -->|active| G[查看日志: journalctl -u systemd-resolved]
    G --> H{是否有 upstream DNS timeout?}
    H -->|Yes| I[测试上游DNS连通性]
    H -->|No| J[检查 /run/systemd/resolve/stub-resolv.conf]
    I --> K[使用 dig @8.8.8.8 google.com 测试]
    J --> L[确认是否存在有效 nameserver]
```

5. 实际排查命令与输出示例

以下是一组关键诊断命令及其预期输出：

# 检查服务状态
$ systemctl is-active systemd-resolved
active

# 查看 resolv.conf 内容
$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search local.domain

# 验证 stub 配置是否包含上游DNS
$ cat /run/systemd/resolve/stub-resolv.conf
nameserver 127.0.0.53
nameserver 8.8.8.8
nameserver 1.1.1.1

# 测试直接连接上游DNS
$ dig @8.8.8.8 google.com +short
142.250.179.174

# 查看 resolved 当前状态
$ resolvectl status
Global:
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: uplink
Current Scopes: DNS
     Domain: local.domain
     Server: 8.8.8.8
             1.1.1.1

6. 解决方案集合

针对不同场景，推荐采取以下措施：

• 重启 systemd-resolved 服务：

  sudo systemctl restart systemd-resolved

• 强制重新生成 resolv.conf 符号链接：

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

• 在 NetworkManager 中固定 DNS：

  [connection]
  id=eth0
  type=ethernet
  dns=8.8.8.8;1.1.1.1;
  dns-priority=100
  

• 关闭其他DNS服务冲突（如dnsmasq）：

  sudo systemctl disable --now dnsmasq

• 添加 fallback DNS 到 resolved 配置： 编辑 /etc/systemd/resolved.conf：

  [Resolve]
  FallbackDNS=8.8.8.8 1.1.1.1 208.67.222.222
  

7. 高级调试技巧

对于复杂环境，建议结合多种工具深入分析：

• 使用tcpdump抓包观察DNS流量：

  sudo tcpdump -i any port 53 -n

• 启用systemd-resolved调试日志：

  sudo systemctl edit systemd-resolved
  # 添加：
  [Service]
  Environment=SYSTEMD_LOG_LEVEL=debug

• 验证glibc解析行为：

  getent hosts google.com

• 检查nsswitch配置：

  cat /etc/nsswitch.conf | grep hosts

  正常应为：hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname