“域名打不开”不是一个足够具体的故障结论。DNS 查询可能收到权威服务器明确返回的 NXDOMAIN，也可能因为解析器、网络路径或防火墙没有返回任何响应而超时。两者在终端里都可能表现为应用无法连接，但修复对象完全不同：前者应检查名称和记录集，后者应检查解析器可达性与 DNS 服务链路。
适用范围与核心结论
本文适用于 Linux 主机、容器或集群内的 A/AAAA 查询失败。验证环境使用 Docker 24.0.7、CoreDNS 1.14.6、Alpine Linux 3.20 与 Nginx 1.28.3。
NXDOMAIN 是 DNS 响应码，表示查询名称不存在；它是服务器给出的负面答案，不等于“DNS 服务器不可达”。超时则意味着在客户端等待窗口内没有收到可解析的响应，常见原因包括解析器地址错误、UDP/TCP 53 被阻断、解析器过载或网络路径故障。不要看到两者都“解析失败”就统一清缓存或改成公共 DNS。
第一步：记录应用实际使用的名称和解析器
先从报错应用所在的同一网络命名空间取证。宿主机查询成功不能证明容器、Pod 或沙箱使用的解析器也正常。
cat /etc/resolv.conf
getent ahosts api.example.com
nslookup api.example.com
# systemd-resolved 环境
resolvectl status
resolvectl query api.example.com
记录完整名称、查询类型、解析器地址、搜索域和发生时间。短名称可能被 search 与 ndots 改写成另一个查询，因此排障时应同时测试应用使用的原始名称与末尾带点的绝对域名。
第二步：对同一解析器做有边界的查询
使用明确的超时和重试次数，避免命令长时间挂起。若安装了 dig，建议保存响应头中的 status、SERVER、Query time 和 Authority 区段：
dig @10.0.0.53 api.example.com A +time=2 +tries=1
dig @10.0.0.53 api.example.com AAAA +time=2 +tries=1
收到 status: NXDOMAIN 说明解析器已经响应。继续确认拼写、环境后缀、权威区是否存在该名称、CNAME 最终目标是否存在，并查看 SOA 中用于负缓存的 TTL。RFC 2308 定义了不存在名称或记录集的负缓存；即使刚补上记录，递归解析器也可能在负 TTL 内继续返回旧的负面答案。
如果查询到期仍没有响应，应先测试解析器而不是修改业务记录：
ping -c 2 10.0.0.53 # 仅作辅助，ICMP 可能被禁用
nc -vz -w 2 10.0.0.53 53 # 检查 TCP 53
dig +tcp @10.0.0.53 api.example.com A +time=2 +tries=1
UDP 查询超时但 TCP 查询成功，可能涉及 UDP 53、分片或中间设备；两者都失败时再检查路由、安全组、NetworkPolicy、解析器进程和监听地址。
第三步：把 DNS 与服务健康分开证明
DNS 失败不能直接证明后端服务宕机。已知正确地址时，可以固定连接地址但保留 Host、SNI 和主机名校验：
curl -sv --connect-timeout 3 \
--resolve api.example.com:443:203.0.113.20 \
https://api.example.com/health
如果固定地址的请求成功，而正常域名查询返回 NXDOMAIN，故障证据指向 DNS 记录链。如果固定地址也失败，才继续检查服务监听、TLS、代理和应用健康。不要在生产机器长期写入 /etc/hosts 作为修复；它会绕过 TTL、故障切换和后续 DNS 变更。
最小修复与复核
NXDOMAIN 场景应在权威 DNS 中补齐或修正具体记录集，修改前导出旧记录和值、TTL 与序列号。解析器超时场景应恢复正确的解析器地址、路由或 DNS 服务容量。只有确认企业解析链故障且变更流程允许时，才临时切换备用解析器。
修复后从原应用网络命名空间重复查询，确认响应码为 NOERROR、答案地址正确，并执行原业务健康请求。还应从另一个递归解析器复核，避免只命中本机缓存。
风险与回滚
DNS 记录修改会影响全部新查询，应使用小 TTL 的计划窗口，并准备恢复原记录集。清空共享解析器缓存可能扩大影响，不能作为默认动作。解析器地址变更要保留原 resolv.conf、NetworkManager、systemd-resolved 或集群 DNS 配置，以便按原路径回滚。
V2CE 复现实验记录
隔离实验启动两个 CoreDNS 权威实例。第一个区文件没有 api.test.local，客户端收到两次明确的 NXDOMAIN；查询未使用的解析器地址 10.250.241.99，四秒内无响应并由边界超时结束；第二个区文件加入 A 记录后，同一名称返回 10.250.241.20。同时直接访问该地址的 Nginx 页面一直成功。
这组证据证明名称不存在、解析器无响应和服务健康是三个可以独立验证的状态。原始查询、CoreDNS 日志与 Compose 状态保存在 labs/dns-nxdomain-timeout/evidence。