开发者常用 DNS 记录说明
理解 A、AAAA、CNAME、MX、TXT、NS 记录，覆盖 TTL、传播和根域 CNAME 陷阱，并在上线前验证解析结果。
为什么上线前要做 DNS 检查
多数被归咎于"DNS"的故障，其实不是 DNS 慢或不稳定，而是记录写错了、只改了一半、或还没传播到位。把客户切到新域名之前花 30 秒 `dig` 一下，能拦住绝大部分。
下面这几类记录是开发者实际会动到的。知道每种记录是干什么的、怎么读、怎么从外部验证，基本就够用了。
A 与 AAAA：地址记录
A 记录把主机名映射到一个或多个 IPv4 地址，AAAA 对应 IPv6。同一名称配多条 A 记录就是 round-robin DNS，客户端每次查询挑一个。
服务支持双栈时，A 和 AAAA 一起上线。AAAA 先上而服务器还没准备好 IPv6，偏好 IPv6 的客户端（大多数现代系统）会直接连不上。
dig A example.com +short
dig AAAA example.com +short
# 指定公共解析器，绕过本地缓存：
dig @1.1.1.1 A example.com
dig @8.8.8.8 AAAA example.comCNAME 与根域陷阱
CNAME 把一个主机名别名到另一个，常见于 CDN（`www.example.com → d12345.cloudfront.net`）、SaaS 接入、证书验证子域。
关键规则：根域（如 `example.com`）按 RFC 不能有 CNAME，因为根上必须存在 SOA 和 NS 记录，CNAME 会和它们冲突。服务商用非标准的 "ALIAS"、"ANAME"、"CNAME flattening" 来解决——表面像 CNAME，查询时返回 A/AAAA。DNS 服务商不支持这些就只能在根域用 A 记录。
dig CNAME www.example.com
# 一般无 CNAME，只有 A/AAAA：
dig CNAME example.comMX 与邮件路由
MX 记录指明谁收这个域的邮件。每条 MX 有一个优先级，数字越小优先级越高。客户端先试最小的，失败才退到大的。
邮件迁移时要注意优先级。旧 MX 留在 10、新 MX 加在 20，意味着只有旧服务器挂了才会走新服务器——这通常不是迁移想要的效果。
dig MX example.com +short
# 返回类似：
# 10 mail1.example.com.
# 20 mail2.example.com.TXT 记录：SPF / DKIM / DMARC 与服务验证
TXT 记录可以放任意字符串。实际用途主要是：SPF（哪些服务器可以以你的域发邮件）、DKIM（邮件签名的公钥）、DMARC（接收方对失败邮件的处理方式），以及 Google Workspace、GitHub Pages、AWS ACM 等服务的短验证 token。
一个域可以有很多条 TXT 记录，互不排斥。值太长在传输层会被切成多段引号包裹，但逻辑上仍是同一条。大部分工具会自动拼起来。
dig TXT example.com +short
# 过滤单一机制：
dig TXT example.com +short | grep "v=spf1"
dig TXT _dmarc.example.com +shortNS 记录与委派
NS 记录指明一个区域的权威名字服务器。注册商在父级（TLD）写一份 NS，子区域本身也应发布对应的 NS——两者必须一致。
把子域委派给其他服务商（如 `apps.example.com` 交给另一个云）就要在父区域设这个子域的 NS。父子 NS 不一致是"部分用户能访问、部分访问不到"这种典型故障的来源。
dig NS example.com +short
# 看 TLD 实际是怎么委派的（类似 whois）：
dig NS example.com @a.iana-servers.netTTL、传播与验证
每条记录都有 TTL，决定解析器允许缓存多久。计划变更前一天先降低 TTL（如设到 300 秒），切换才能快速生效；变更稳定后再恢复正常 TTL。
"DNS 传播"实质是"缓存过期"。变更在权威服务器上是立即可见的，全球可见要等各处缓存到期。验证时务必从多个公共解析器看，不要只看自己的机器。
# 从多个解析器查：
for R in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
echo -n "$R: "
dig @$R A example.com +short
done
# 查看当前 TTL 值：
dig A example.com