Ubuntu DNS 解析失败：systemd-resolved 分层排查
本文适用于 Ubuntu 24.04 中由 systemd-resolved 提供解析服务的服务器。镜像可能采用其他管理方式，因此先确认服务状态，不能根据发行版名称直接假定配置结构。一次域名查询失败，既可能是本机设置，也可能是上游服务器或域名记录的问题。
先确定失败发生在哪一层
保存失败域名、查询时间、应用报错和预期结果。测试时使用业务域名，并另外选一个已知正常的域名进行对照。单个域名失败与所有域名都失败，对排查方向的意义不同。
# 服务器：把 example.com 替换为实际需要测试的域名
getent ahosts example.com
resolvectl query example.com
systemctl status systemd-resolved
getent 通过系统名称服务接口查询，可能受到 /etc/hosts 和名称服务配置影响；resolvectl 查询 systemd-resolved。两者结果不同，值得检查应用使用的解析路径。浏览器、容器或特定程序还可能自带缓存或独立解析配置，宿主机成功并不能直接证明它们正常。
不要仅凭 ping 没有回应判定 DNS 失败。先看域名是否得到地址，再分别处理网络连通、服务监听和访问策略。查询功能说明见 resolvectl 手册。
看清本机存根与实际上游
# 服务器：只读查看 DNS 来源与配置文件指向
resolvectl status
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
/etc/resolv.conf 中出现 127.0.0.53，通常表示应用向本机解析存根发送请求，这个地址不是外部 DNS 服务器。实际使用的上游及其关联网络接口，应结合 resolvectl status 查看。
systemd-resolved 支持多种 resolv.conf 接入方式。不要看到回环地址就把文件改成公共 DNS，也不要直接覆盖一个由系统管理的符号链接。相关模式在 systemd-resolved 官方手册中有说明。修改前先记录链接目标、网络管理工具和配置来源，才能知道修复应该落在哪一层。
多网卡和 VPN 要检查域名路由
服务器同时连接公网、内网或 VPN 时，不同域名可能应由不同接口的 DNS 解析。内网数据库名称交给公网解析器，可能得到不存在或错误地址；将所有查询强行送入一个公共解析器，也可能破坏正常的分流配置。
查看每个接口的 DNS Servers、DNS Domain 和 DefaultRoute 等信息，结合业务网络设计判断查询应走哪条路径。路由域、搜索域和默认 DNS 路由会影响选择，不能仅按配置列表的先后顺序推断。需要短期对某个接口排查时，可按文档使用 resolvectl dns 等命令，但它们属于运行时变更，应事先保存状态，明确恢复方法。
长期设置应回到真正管理接口的 Netplan、NetworkManager 或 systemd-networkd 配置，且要遵循该镜像的网络管理方式。远程修改网络前保持现有会话，并准备可用的控制台入口；不要在故障诊断中同时替换整套网络配置。
区分缓存结果和权威记录
刚修改域名解析后，本机、上游和应用可能仍保存缓存。sudo resolvectl flush-caches 只清理本机 systemd-resolved 缓存，不会清空递归解析器或应用的缓存，也不会修改域名权威记录。使用后应重新查询并记录结果，不能把短暂恢复视为根因已解决。
若不同网络得到不同地址，进一步核对权威记录、TTL、是否存在多个 A 或 AAAA 记录，以及 IPv6 地址是否实际可达。解析器返回地址但网站连接失败，往往需要继续验证该地址的服务和网络路径。域名侧的基础检查可参阅域名解析设置教程。
修复必须经过应用侧验证
确定问题后只修改对应层：错误的持久 DNS 配置、过期的内网解析地址、异常的 VPN 分流，或域名本身的记录。不要为了绕过短期故障长期写死业务 IP 到 /etc/hosts，尤其是地址会变化的服务。
修复后分别验证系统查询、实际业务程序和依赖该域名的后台任务，再观察下一次网络重连或配置重新应用后是否仍然有效。如果采用了临时接口覆盖，应按已记录状态恢复，确认持久配置能够独立工作。需要分享故障信息时，删除内部域名、私网结构和认证信息，仅保留足够的查询时间及结果证据。