nslookup返回NXDOMAIN但浏览器能访问，主因是其默认查A记录且受本地stub resolver、缓存或DoH影响；应改用dig、指定DNS服务器、加-debug或+trace参数排查。
nslookup 返回 NXDOMAIN 但浏览器能打开网站
这是最常见的误判场景：你用 nslookup example.com 得到 NXDOMAIN，却发现在 Chrome 里能正常访问。别急着怀疑 DNS 配置——nslookup 默认查的是 A 记录，而现代网站大量依赖 HTTPS 和 HTTP/2，浏览器可能已缓存了 IP，或走了 DoH（DNS over HTTPS）、系统级 stub resolver（如 systemd-resolved）的路径，压根没走你终端里那个 nslookup 调用的 DNS 服务器。
实操建议：
- 加
-type=AAAA或-type=HTTPS看是否支持 IPv6 或新记录类型 - 用
nslookup example.com 8.8.8.8显式指定公共 DNS，排除本地 DNS 缓存干扰 - 对比
dig example.com +short输出，dig更贴近真实解析链路，nslookup的默认行为（尤其在某些发行版上）会做额外查询合并，容易误导 - 检查
/etc/resolv.conf里是否有127.0.0.53（systemd-resolved）——这时nslookup实际发给的是本地 stub，不是上游 DNS
nslookup 查不到 CNAME 却能解析出 IP
nslookup 默认只显示最终答案（ANSWER SECTION），不展示中间跳转过程。如果域名设置了 CNAME 到另一个域名，而后者再有 A 记录，nslookup 默认只返回最终的 A 地址，CNAME 行被“折叠”了。
实操建议：
- 加
-debug参数：运行nslookup -debug example.com，能看到完整响应包，包括 AUTHORITY 和 ADDITIONAL SECTION，CNAME 就在那里 - 用
dig +trace example.com更直观，它会逐级从根服务器开始查，每一步的 CNAME 都清清楚楚 - 注意：有些 CDN 厂商（如 Cloudflare）对 CNAME 做了扁平化处理（ALIAS/ANAME 类似语义），
nslookup查不到原始 CNAME，这是有意为之，不是配置错误
nslookup 超时或卡住不动
根本原因通常是 DNS 查询路径中某一级无响应，而 nslookup 默认重试 3 次、每次等待数秒，看起来就是“卡住”。常见于本地 DNS 服务器宕机、防火墙拦截 53 端口、或递归 DNS 返回了 malformed 响应。
实操建议：
- 先用
timeout 2 nslookup example.com 8.8.8.8加超时控制，避免干等 - 换 UDP/TCP 强制协议：
nslookup -vc example.com 8.8.8.8（-vc 表示 TCP），绕过 UDP 被限或丢包问题 - 检查本地 DNS 是否真在监听：
ss -tuln | grep :53，确认systemd-resolved、dnsmasq或named没崩 - 别忽略 /etc/nsswitch.conf 里的
hosts: files dns顺序——如果files（即 /etc/hosts）里有错条目，nslookup不走，但系统其他程序会优先读它，造成现象不一致
为什么 dig 比 nslookup 更可靠
dig 是 BIND 工具集里的标准诊断工具，设计目标就是“忠实反映 DNS 协议行为”；nslookup 早期是为交互式教学设计的，后来虽不断修补，但默认行为仍带不少隐式逻辑（比如自动追查 CNAME、默认启用搜索列表、对空响应处理不一致）。
实操建议：
- 排查问题时，优先用
dig example.com @8.8.8.8 +noall +answer快速看结果，加+verbose看全包 -
nslookup的交互模式（直接敲nslookup回车）容易误操作，比如输错 server 后忘记 reset，后续查询全发错地方 - 某些嵌入式系统或最小化镜像（如 Alpine）默认不装
bind-tools，只有nslookup，这时得手动apk add bind-tools或改用getent hosts example.com作轻量替代
真正麻烦的不是命令不会用，而是你看到的“成功解析”，可能来自 /etc/hosts、nscd 缓存、glibc 的 getaddrinfo() 内部逻辑，或者容器网络里的 coredns 插件——nslookup 只管 DNS 层，它说通了，不代表你的 curl 就一定能通。
