帮助中心产品文档与操作指南

Linux服务器DNS解析失败怎么检查

发布时间：2026-10-31更新时间：2026-10-31

服务器上的apt、curl或应用提示无法解析域名时，要检查的是这台Linux系统如何查询名字，不能只看域名控制台有没有A记录。本文先做只读定位，避免把不同网络管理方式都套成“覆盖resolv.conf”。

用系统实际的名称查询入口复现

getent ahosts example.com
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

将example.com换成发生问题的真实域名，再用一个你确认存在的域名对照。getent经过系统NSS查询链，可能使用hosts等来源，并非只查DNS。查看resolv.conf时记录nameserver与search设置；若它是符号链接，应先确认文件由systemd-resolved、NetworkManager、DHCP、Netplan或其他工具管理。

使用systemd-resolved时查看每条链路

resolvectl status
resolvectl query example.com

记录对应网卡的DNS服务器、DNS域和查询返回的地址/协议。看到127.0.0.53这样的本地stub地址，不代表上游DNS服务器就在这台机器；resolvectl status能帮助确认链路配置。resolvectl不存在或服务未运行时，不为完成检查强装另一套解析服务，改按当前系统使用的工具读取状态。

直接询问当前已配置的DNS服务器

系统已有dig时，可以把下例替换成实际DNS服务器地址与域名；没有dig可按发行版安装对应DNS查询工具，不需要扫描其他网络。

dig @实际DNS服务器 example.com A +time=2 +tries=1
dig @实际DNS服务器 example.com AAAA +time=2 +tries=1
返回或现象 解释与下一步
NXDOMAIN 被问到的解析器认为名字不存在；核对域名拼写、子域、权威记录与缓存，不能当成服务器端口故障
SERVFAIL 解析器没能完成查询；核对其上游、DNSSEC与网络情况，保存完整响应
NOERROR但无目标类型答案 可能该名字没有A或AAAA记录，继续看响应与别名链；不等于所有记录不存在
查询超时 检查到该DNS的访问、现有规则与解析服务；Ping正常不能证明UDP/TCP 53正常
dig正常而getent失败 查NSS、hosts、搜索域与本地stub；两条查询路径可能不同

修复应落在配置的真正来源

如果DHCP或网络管理器生成resolv.conf，直接覆盖该文件可能在续租或重启后丢失，也可能破坏内网域名解析。先确定管理工具、网卡和业务依赖，再在其配置入口修改；保留原DNS、搜索域和恢复方式。不要为了临时联网随意换成陌生DNS，也不要通过关闭TLS证书校验掩盖域名或连接错误。

验证原来的业务

  1. 重复同一域名、同一类型查询，确认返回符合预期，并记录时间与所用解析器。
  2. 重新执行最初失败的包更新、HTTPS请求或应用操作。DNS返回地址不保证端口、TLS和应用正常。
  3. 只有个别域名失败时，分别核对它们的权威记录或内网依赖；全部域名失败再检查系统解析链路。
  4. 需要协助时提供发行版、resolv.conf真实路径、非敏感DNS配置、完整查询状态与原始错误，遮挡私人域名和令牌。