排查服务器 dns 解析故障，核心思路是分层隔离：先确认本地网络连通性，再检查 dns 客户端配置，接着验证远程 dns 服务器的响应，最后排除应用层缓存或防火墙干扰。具体做法是从 ping 和 nslookup 入手，逐步缩小问题范围。
DNS 客户端配置错误会导致解析失败吗
会。如果服务器配置的 /etc/resolv.conf 中 nameserver 指向了不可达或错误的 IP，所有基于该配置的查询都会超时或返回错误。需检查文件内容并确保 search 域符合预期。
cat /etc/resolv.conf # 示例输出： nameserver 8.8.8.8 nameserver 114.114.114.114 search local.lan
若发现 nameserver 为空或指向内网未部署的 DNS，修改为正确的公共 DNS（如 8.8.8.8）后重试 nslookup example.com，应能正常返回 A 记录。
防火墙拦截 UDP 53 端口会影响解析吗
会。DNS 默认使用 UDP 53 端口，若出站规则丢弃该流量，查询将无响应。可通过 iptables -L OUTPUT -v -n 查看是否有 DROP 规则，或使用 tcpdump udp port 53 抓包确认包是否发出及是否有回应。
# 临时放行 UDP 53 出站（以 iptables 为例） iptables -A OUTPUT -p udp --dport 53 -j ACCEPT # 测试解析 nslookup google.com
若抓包显示请求已发出但无应答，且防火墙日志有 DROP 记录，则确认为防火墙拦截。添加允许规则后，nslookup 应立即恢复成功。注意部分云服务商需在安全组层面同时放行。
系统 DNS 缓存服务导致旧记录无法更新怎么办
当使用 systemd-resolved 或 dnsmasq 等本地缓存服务时，即使上游 DNS 已更新，本地仍可能返回过期 IP。需清除对应服务的缓存并重启服务以强制刷新。
# 清理 systemd-resolved 缓存 resolvectl flush-caches # 重启 dnsmasq（若使用） systemctl restart dnsmasq # 验证新记录 nslookup example.com
执行上述命令后，再次查询目标域名，若返回的 IP 与最新记录一致，则证明是缓存污染所致。建议在生产环境调整 TTL 或定期清理缓存以避免此类问题。
