域名解析故障应先用dig和nslookup精准定位环节：dig+trace追踪完整链路，查ttl、权威响应及rcodes；nslookup对比本地resolver行为，交叉验证排除缓存或配置干扰。
域名解析出问题，第一反应不是换DNS服务器，而是用 dig 和 nslookup 精准定位故障环节——它们能分别查清“到底哪一级没响应”“缓存有没有捣鬼”“返回结果是否合规”。关键不是命令怎么输，而是知道每一步在验证什么。
用 dig 看完整解析链路，重点盯 TTL 和权威响应
dig 默认只查本地配置的 DNS 服务器，但加参数就能模拟真实递归过程。先执行：
dig example.com +trace它会从根服务器（.）开始，逐级向下查：根 → 顶级域（.com）→ 权威服务器（example.com 的 NS），最后拿到 A 记录。如果卡在某一级（比如停在 .com 的 NS 列表就不动了），说明上一级没返回正确 NS 地址，或是网络策略拦截了 UDP 53 端口。
日常排查更常用的是直查目标域名并观察细节：
dig example.com @8.8.8.8重点关注三块：
- HEADER 段的 rcodes：NOERROR 表示成功；NXDOMAIN 是域名不存在；SERVFAIL 是上游服务器出错（不一定是你的问题）
- ANSWER SECTION 是否为空：空但 AUTHORITY SECTION 有 NS 记录，说明权威服务器没配该域名的记录
- TTL 值是否异常小或为 0：TTL=0 往往是刚改记录还没生效，或权威服务器配置了禁止缓存
用 nslookup 测本地 resolver 行为，区分缓存与转发问题
nslookup 更贴近系统实际调用方式，尤其适合验证 /etc/resolv.conf 配置是否生效、以及 glibc 的 DNS 缓存（nscd 或 systemd-resolved）是否干扰判断。
分两步对比：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
nslookup example.com 127.0.0.53
前者走系统默认 resolver（可能经过 systemd-resolved 代理）；后者直连本地 stub resolver。如果结果不同，说明本地服务做了缓存或重写（比如把内网域名强制解析到私有 IP）。
再试绕过所有中间层：
nslookup example.com 8.8.8.8若这步通，但前两步失败，问题一定出在本地 DNS 配置、防火墙拦截或本地 resolver 服务异常。
交叉验证避免误判：别信单一工具的“成功”
同一个域名，dig 返回 A 记录，nslookup 却报 NXDOMAIN？大概率是二者查询路径不同：
- dig 默认用 UDP，nslookup 在某些系统下会 fallback 到 TCP（尤其响应超长时）
- dig @ip 默认跳过 /etc/resolv.conf；nslookup 不带 @ 则严格按它走
- systemd-resolved 可能对 .local 域名启用 mDNS，而 dig 完全不走这套逻辑
所以关键操作是统一基准：
dig example.com @127.0.0.53 +shortnslookup example.com 127.0.0.53 | grep "Address:"
两个命令都指向同一 resolver，结果还不同，就该检查该 resolver 的日志（如 journalctl -u systemd-resolved）了。
快速定位常见陷阱：超时、截断、权限限制
遇到 “connection timed out” 或 “server can't find” 不能只怪网络。先确认基础项：
- 防火墙是否放行 UDP 53 出向？sudo ss -tuln | grep :53 看本地有没有监听，tcpdump -i any port 53 抓包看请求发没发出
- 返回结果里有 truncated 字样？说明响应超 512 字节且 EDNS0 被禁用，尝试加 +edns=0 或换 TCP：dig +tcp example.com
- 查内网域名（如 host.internal）失败？确认 /etc/nsswitch.conf 中 dns 行是否在 hosts 行之后，避免被 /etc/hosts 里的旧条目覆盖
