六种你会实际用到的记录
DNS 记录类型有数十种，但日常运维会碰到的大约就这六种。它们各自回答一个不同的问题：这个名称指向哪个 IP、这个名称是不是另一个名称的别名、这个域名的邮件该送去哪、以及谁有权回答这个域名的查询。
搞混类型是最常见的错误来源，而且症状往往不直观——例如把应该用 CNAME 的地方写成 A 记录，设置当下完全正常，直到对方换 IP 才突然坏掉，而那可能是几个月后的事。
| 记录类型 | 用途 | 常见错误 |
|---|---|---|
| A | 把名称指向 IPv4 地址 | 对方 IP 会变时仍写死 A 记录 |
| AAAA | 把名称指向 IPv6 地址 | 只设 A 没设 AAAA，IPv6 用户走不到 |
| CNAME | 让名称成为另一个名称的别名 | 设在根域名——协议不允许 |
| MX | 指定收信服务器与优先顺序 | 填 IP 而非主机名；优先值理解颠倒 |
| TXT | 存放验证字符串（SPF、DKIM、ACME） | 多笔 SPF 并存导致验证失败 |
| NS | 指定谁有权回答此域名的查询 | 在注册商与 DNS 商两边各改一次，互相冲突 |
下表列出六种记录与各自最常见的踩雷点。第三栏值得特别看。
为什么根域名不能用 CNAME
这是最常被卡住的限制，而且它不是配置问题，是协议规定：
- CNAME 不能与其他记录共存 DNS 规范要求：一个名称上如果有 CNAME，就不能同时有任何其他类型的记录。这个规则本身很单纯，问题出在它跟根域名的必要条件冲突。
- 根域名必然带有 SOA 与 NS 记录 每个域名的根（例如 `example.com` 本身）一定要有 SOA 与 NS 记录，这是域名能被解析的前提。既然根域名必定已有这两种记录，依前一条规则，就不可能再放 CNAME——两者无法并存。
- 所以想让根域名指向一个名称，要用替代方案 多数 DNS 服务商提供 ALIAS、ANAME 或「CNAME 平坦化」之类的功能：对外看起来是 A 记录，但服务商在背后自动解析目标名称并返回其当下的 IP。效果接近 CNAME，但符合协议。要注意这**不是标准功能**，各家名称与行为不同，换服务商时要重新确认。
TTL：要在变更之前调整
TTL（Time To Live）是你告诉全世界的解析器「这笔记录可以缓存多久」。设 3600 就是一小时，在那一小时内，已经查过的解析器不会再来问你——它会直接用缓存的旧答案。
所以当你改了记录却发现没生效，原因通常不是「传播需要时间」，而是**旧记录的 TTL 还没到期**。而关键在于：此刻调低 TTL 已经来不及了，因为解析器手上那份旧缓存，带的是它取得时的旧 TTL 值。
日常运维上，变动不频繁的记录（如 MX、NS）可以设较长的 TTL；可能需要临时切换的记录（如指向源站的 A 记录）则值得维持较短的值。这是稳定性与应变速度之间的取舍，没有单一正确答案。
TXT 记录的两个实务陷阱
TXT 是最杂的一种记录，因为它被拿来塞各种验证信息：域名所有权验证、SPF、DKIM、DMARC，以及证书自动化用的 ACME DNS-01 挑战值。内容格式各自不同，全部混在同一个名称底下。
第一个陷阱是 **SPF 只能有一笔**。如果为了新增一个发信服务而多加一笔 SPF 记录，结果不是「两笔都生效」，而是验证直接失败——正确做法是把所有来源合并进同一笔。第二个陷阱是**证书验证用的 TXT 需要频繁变动**，如果您的 DNS 服务商没有 API，就无法自动化，而在证书有效期缩短之后，这会变成每年多次的手动作业。
三个实务判断
配置前先想清楚这三件事：
一、目标的 IP 会不会变？
会变就用 CNAME 指向对方的主机名，让对方自己管理 IP；不会变才写 A 记录。指向 CDN、云负载均衡这类服务时尤其如此——它们的 IP 本来就会浮动，写死 A 记录等于埋了一颗不知何时会爆的雷。
二、这笔记录多久会动一次？
这决定 TTL。几乎不动的设长一点（3600 以上），可能需要紧急切换的设短一点（300 左右）。重点是**在你需要它短之前就先设短**，而不是出事当下才调。
三、谁是这个域名的权威？
NS 记录决定由谁回答查询。常见的混乱是：在注册商改了一次 NS，又在 DNS 服务商的界面改了一次，结果两边不一致。实际生效的是注册局那一份，也就是您在注册商设定的那一份——这一点在转移域名或更换 DNS 服务商时特别容易出错。
变更前该确认的三件事
动手改之前，这三项可以省下很多排查时间：
- 确认目前的 TTL 是多少 这决定变更后最长要等多久。如果是 86400（一天），而您没有预先调低，那就得有等一整天的心理准备——这时候反复刷新浏览器不会有帮助。
- 确认要改的是哪一层 注册商、DNS 托管商、CDN 都可能有一个「DNS 设置」的界面。先确认 NS 指向谁，那一家的设置才是生效的；在没有权威的那一边改，改再多次也不会有反应。
- 改完用权威服务器直接查证 用 `dig @权威服务器 名称 记录类型` 直接向权威服务器查询，可以跳过所有缓存，立刻确认记录本身是否正确。若权威回答是对的、其他地方还是旧的，那就纯粹是等 TTL 的问题。
小结
DNS 变更的等待时间不是玄学，是您自己设定的 TTL。理解这一点之后，迁移的正确顺序就变得清楚：**先调低 TTL，等一个旧周期，再执行变更**。事后才调 TTL 对当下这次变更没有帮助。
另一个值得记住的是根域名不能用 CNAME——这是协议层面的限制，各家提供的 ALIAS 或平坦化功能只是各自的变通做法，不是标准。选择 DNS 服务商时，这项功能以及是否提供 API（证书自动化的前提）都值得一并确认。