日本服务器 DNS 解析失败怎么办？6 步排查与修复方案

问题一：域名完全无法解析

• 表现：nslookup example.com 提示 SERVFAIL 或 connection timed out; no servers could be reached，所有依赖域名的服务都挂了。
• 可能原因：① /etc/resolv.conf 配置错误；② 本地 DNS 服务器（如 systemd-resolved）崩溃；③ 防火墙拦截 53 端口出方向；④ 域名注册商的 NS 记录被篡改。
• 排查步骤：
  1. cat /etc/resolv.conf 确认 nameserver 是否正确；
  2. nslookup example.com 8.8.8.8 直接指定公共 DNS 测试；
  3. 若公共 DNS 能解析 → 本地 resolver 问题；若也不行 → 域名或网络问题。
• 快速修复：
  1. 临时把 nameserver 8.8.8.8 和 nameserver 1.1.1.1 写入 /etc/resolv.conf；
  2. 重启 resolver：systemctl restart systemd-resolved；
  3. 检查 iptables -L OUTPUT | grep 53 是否拦截了 DNS 出方向。

问题二：解析时好时坏（间歇性失败）

• 表现：大部分请求正常，偶发 Could not resolve host，应用日志大量 DNS 超时。
• 可能原因：① 本地 DNS 服务器性能不足（并发太高）；② DNS 缓存配置不合理（TTL 太短或缓存失效）；③ 网络抖动导致 53 端口丢包。
• 排查步骤：
  1. dig @8.8.8.8 example.com +stats 看查询耗时；
  2. systemd-resolve --statistics 看本地 DNS 缓存命中率与超时数；
  3. mtr -u -P 53 8.8.8.8 看 DNS 路径是否丢包。
• 快速修复：
  1. 配置本地 DNS 缓存（dnsmasq/unbound），TTL 设为 300s 以上；
  2. 多 DNS 服务器轮询：nameserver 8.8.8.8 + nameserver 1.1.1.1；
  3. 应用层加重试与超时控制（如 Node.js 的 dns.setDefaultResultOrder）。

问题三：解析到错误的 IP（劫持/污染）

• 表现：同一域名在日本服务器解析出的 IP 与本地不同，或解析到未知 IP，网站显示异常内容。
• 可能原因：① ISP 级 DNS 劫持；② 国内 GFW DNS 污染（日本访问国内域名时）；③ /etc/hosts 被篡改；④ 恶意软件修改 DNS。
• 排查步骤：
  1. cat /etc/hosts 检查是否有异常条目；
  2. dig @8.8.8.8 example.com vs dig @1.1.1.1 example.com 对比结果；
  3. nslookup example.com 208.67.222.222（OpenDNS）看第三地结果。
• 快速修复：
  1. 强制使用可信 DNS（8.8.8.8 / 1.1.1.1 / Cloudflare 1.0.0.1）；
  2. 关键域名走 DNS over HTTPS (DoH) 或 DNS over TLS (DoT)，避免劫持；
  3. 检查 ls -la /etc/hosts 与可疑进程，必要时重装系统。

问题四：内网域名解析失败

• 表现：nslookup db.internal 失败，但公网域名正常，应用无法连接数据库/缓存。
• 可能原因：① VPC 内网 DNS 未启用；② 安全组没放行 53 端口到内网 DNS；③ 容器（Docker）网络 DNS 配置错误。
• 排查步骤：
  1. cat /etc/resolv.conf 看是否有内网 DNS（如 10.x.x.x）；
  2. nslookup db.internal <内网DNS IP> 直接测试；
  3. Docker 环境：docker exec cat /etc/resolv.conf。
• 快速修复：
  1. 在 /etc/resolv.conf 加入内网 DNS；
  2. Docker 容器用 --dns 指定或配置 /etc/docker/daemon.json；
  3. 安全组放行内网 DNS 的 53 端口（UDP/TCP）。

问题五：DNS 缓存导致旧 IP 生效慢

• 表现：域名已切到新 IP，但日本服务器还解析到旧 IP，持续几小时到几天。
• 可能原因：① 本地 DNS 缓存未过期（TTL 太长）；② 应用层有 DNS 缓存（如 Java JVM、Nginx resolver）；③ 操作系统 nscd/systemd-resolved 缓存。
• 排查步骤：
  1. dig example.com 看当前解析结果与剩余 TTL；
  2. systemd-resolve --flush-caches 或 nscd -i hosts 清缓存；
  3. 应用层检查是否有独立 DNS 缓存。
• 快速修复：
  1. 切换 IP 前先把 TTL 降到 60s，稳定后再调高；
  2. 清本地缓存：systemd-resolve --flush-caches；
  3. Java 应用加 -Dnetworkaddress.cache.ttl=60；Nginx 配置 resolver valid=60s。

问题六：如何预防 DNS 故障？

• 多 DNS 提供商：配置 8.8.8.8 + 1.1.1.1 + 日本 NTT DNS 至少 3 个，避免单点。
• 本地缓存：部署 dnsmasq/unbound 做本地缓存，减少对公网 DNS 的依赖。
• DoH/DoT：关键服务用 DNS over HTTPS，防止劫持与污染。
• 监控：每 30s 探测关键域名解析，配置告警；TTL 变更前通知运维。