二级域名查询？先分清这3种记录

查一个二级域名，返回的结果跟预期对不上，十有八九不是查询工具坏了，而是想查的东西压根不是同一种记录。二级域名查询这个动作看着简单，输入框敲一下回车就行，可 A 记录、CNAME、TXT 这几行返回的内容，回答的是完全不同的三个问题。分不清就急着怀疑 DNS 被人动了手脚、怀疑服务商在后台搞事，折腾半天，最后发现是自己把记录类型看错了。这篇就把这三种记录掰开说说，顺便聊聊查的时候几个容易踩的坑。

二级域名查询之前，先分清这3种记录

三种记录各管一摊。A 记录回答的是“这个名字现在对应哪个 IP”，最直白；CNAME 回答的是“这个名字是另一个名字的别名”，它自己不带 IP；TXT 回答的是“这个域名对外声明了什么”，各类验证字符串、反垃圾邮件声明都塞在这里面。另外 MX 单独管邮件往哪投，跟上面三个不算一类，但查询的时候经常一起冒出来。所以动手之前先问自己一句：我要的是 IP，还是要确认它指向谁，还是想验证某条声明在不在。想清楚这一步，后面返回的结果才好解读。

A记录查出来的IP，未必是你那台机器

很多人查二级域名，目的就一个——确认它是不是指向自己那台服务器。ping 一下出来个 IP，去查归属地，发现不是自己买的机房，立马紧张。前面挂了 CDN、挂了高防、挂了负载均衡的，A 记录指的一定是加速节点，不是源站，这属于正常现象。想确认回源对不对，得去 CDN 控制台看源站配置，或者拿源站自己的域名去查，别指望从一个加速域名上把源站 IP 看出来。

还有个细节，同一个名字的 A 记录可以配好几条，解析的时候轮询返回，ping 只看到其中一条太正常了。有人两次结果不一样就以为出故障，人家本来就是那么配的。要一次看全，用 dig 指定类型，别用 ping 那种只看一眼的工具。

CNAME链太长，问题往往在最后一跳

www 这种前缀十有八九是 CNAME，指向服务商给的一长串域名。有人查的时候只看到第一跳，就下结论说“没指对”，链其实还在后面。工具里指定 CNAME 类型，或者顺着链一路查下去，才能看到最后落到哪台机器上。

几个常见坑：根域按规范是不建议设 CNAME 的，虽然有厂商做了展平处理，但老工具查出来会很怪；CNAME 和 MX 挂在同一个名字上会打架，邮件就收不到了；CNAME 的目标如果绕一圈指回自己，解析直接成环挂掉。这几种情况拿查询工具都能看出来，看的时候别只盯第一行。

TXT和MX，查询结果里最容易被跳过的两行

TXT 现在用得特别多。搜索引擎站长平台的验证、SSL 证书的 DNS 验证、SPF 那条反垃圾邮件声明，全往里塞。查不到 TXT，很多时候是记录值被拆成好几段，或者引号加得不对，工具只显示前一段，看着像缺了一半。

MX 决定邮件往哪个服务器投。二级域名一般不做 MX，但 mail. 这种子域做企业邮箱的时候会配上。查的时候工具默认只给 A 记录，得手动把类型切过去，不切你就会以为“什么都没有”。

同一个名字两个工具查出两样，先怀疑缓存

本地系统有缓存，运营商的递归 DNS 也有缓存，记录上还有个 TTL 管着缓存多久。改完记录马上查，看到旧值是再正常不过的事，别急着提工单骂人。

想快点确认，Windows 上敲 ipconfig /flushdns，macOS 上 sudo dscacheutil -flushcache，Linux 看 systemd-resolved 那套。再拿 dig @8.8.8.8 名字 类型 直接去问公共 DNS，跟自己本地的结果对一下。两边一致说明是真生效了，不一致多半还卡在某一层缓存里。TTL 设得长的，等的时间就长，那是当初自己设的，怪不到别人头上。

泛解析这个隐形坑

一条 * 记录开下去，随便敲个不存在的子域都能查到 IP，看着“全都有”，实际上没有一个单独配过。判断办法很简单：随手敲一串乱码子域去查，如果也返回同一个 IP，那就是泛解析在兜底。这时候“能查到”不等于“配好了”，别拿查询结果当配置清单用，更别照着查出来的东西去改别处的设置。

查不到记录，先确认这三件事

一是 NS 指向。域名在 A 家注册，解析却托管在 B 家，改记录改错地方是常有的事，先看 NS 到底指向谁。二是记录有没有保存生效，注意 TTL，别刚点完保存就去查。三是名字有没有敲错，带 www 和不带 www 是两个完全不同的名字，看着差不多，结果差得远。

顺序不复杂：先确定自己要查哪种记录，再用 dig 把类型指定死，直接问公共 DNS，绕开本地缓存；碰上有 CDN 的域名，先把节点 IP 和源站 IP 分清；查不到就先看 NS 和拼写。按这个顺序走一遍，大部分“二级域名查不到”“查出来对不上”的问题，自己就能定位到是哪一环出的岔子，省得一出事就往被黑、被劫持上想。