DNS 记录类型完全指南：从 A 记录到排障实战

改 DNS 是运维里”改动最小、影响最大”的操作之一：只是编辑几行文本，却能让全站宕机、邮件全丢，而且出了问题往往要等几小时才能确认。大多数人平时只会接触 A 记录和 CNAME，真遇到 MX 配置错误或者 CAA 证书签发失败时才发现自己对 DNS 的理解停留在表面。这篇文章把常见记录类型、TTL 缓存机制和一套实用的排障流程讲清楚。

DNS 解析：从域名到 IP 发生了什么

DNS（域名系统）本质上是一个分布式的键值数据库：键是域名，值是各种类型的记录。当你在浏览器输入 example.com，解析过程大致是这样的：

浏览器和操作系统先查本地缓存，命中就直接返回。
没命中就问递归解析器（通常是运营商或公司内网提供的，也可以是 8.8.8.8、1.1.1.1 这类公共 DNS）。
递归解析器从根服务器开始，依次问 .com 的顶级域服务器、example.com 的权威服务器，拿到答案后缓存并返回给你。

关键的一点是：普通用户的电脑几乎从不直接和权威服务器对话，中间隔着层层缓存。这解释了 DNS 的两个经典现象——改动不会立刻全球生效（缓存还没过期），以及不同地区看到的结果可能不一样（各地缓存状态不同）。理解这条链路，后面讲 TTL 和排障时就顺理成章了。

A 记录：IPv4 地址

A 记录（Address）是最基础的记录类型，把域名映射到一个 IPv4 地址：

example.com.    300    IN    A    93.184.216.34

同一个名字可以配多条 A 记录，解析器会返回全部地址，客户端通常轮询使用——这是最原始的负载均衡方式。需要留意的是，DNS 轮询没有健康检查，其中一台机器挂了，仍有一部分用户会拿到死地址，所以生产环境的负载均衡一般交给专业的 LB 或 CDN，而不是堆 A 记录。

AAAA 记录：IPv6 地址

AAAA 记录和 A 记录结构完全一样，只是指向 IPv6 地址。因为 IPv6 地址长度是 IPv4 的四倍（128 位对 32 位），所以叫”四个 A”：

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

常见做法是 A 和 AAAA 同时配置，支持 IPv6 的客户端优先走 AAAA，不支持的回落到 A。如果你只配了 A 记录，纯 IPv6 网络的用户就可能访问不到你的站点。

CNAME 记录：别名

CNAME（Canonical Name）表示”这个名字是另一个名字的别名”，解析时会顺着别名继续查下去：

www.example.com.    300    IN    CNAME    example.com.

查 www.example.com 的 A 记录时，解析器发现它是 CNAME，就转去查 example.com 的 A 记录，把整条链的结果一起返回。CNAME 最常见的用途是把子域名指向第三方服务，比如 CDN 或对象存储给的域名。

MX 记录：邮件交给谁收

MX（Mail Exchange）记录告诉全世界：发往这个域名的邮件应该投递到哪台服务器。它比普通记录多一个优先级字段，数字越小优先级越高：

example.com.    300    IN    MX    10 mail.example.com.
example.com.    300    IN    MX    20 backup-mx.example.com.

发件方先尝试优先级 10 的服务器，失败了再试 20。注意 MX 的值必须是主机名（再由这个主机名的 A/AAAA 记录解析出 IP），不能直接写 IP 地址，也不应该指向一个 CNAME——这两点后面讲配置错误时还会展开。

TXT 记录：验证与策略文本

TXT 记录允许在域名下放任意文本，如今它最主要的用途是域名所有权验证和邮件防伪策略：

example.com.    300    IN    TXT    "v=spf1 include:_spf.example.net ~all"
example.com.    300    IN    TXT    "google-site-verification=abc123..."
_dmarc.example.com. 300 IN  TXT    "v=DMARC1; p=quarantine"

SPF（声明哪些服务器有权代你发邮件）、DKIM 公钥、DMARC 策略、各大平台的所有权验证，全都靠 TXT 记录实现。一个域名可以有多条 TXT 记录，互不影响。

NS 与 SOA：授权与区管理

NS（Name Server）记录声明这个域由哪些权威服务器负责：

example.com.    172800    IN    NS    ns1.dns-provider.com.

当你在域名注册商处”修改 DNS 服务器”，改的就是上级域里为你登记的 NS 记录。换 DNS 服务商时的”全球生效要等一两天”，等的就是 NS 记录的长 TTL 缓存过期。

SOA（Start of Authority）是每个 DNS 区（zone）必须有且只有一条的记录，包含区的管理信息：主服务器、管理员邮箱、序列号（从服务器据此判断区数据是否更新）、以及刷新、重试、过期时间和否定缓存时长。普通用户很少手动改 SOA，但 dig 排查时经常会在应答里看到它。

CAA 与 SRV：小众但有用

CAA（Certification Authority Authorization）记录声明哪些证书机构有权为你的域名签发证书：

example.com.    300    IN    CAA    0 issue "letsencrypt.org"

配了 CAA 之后，不在名单里的 CA 签发请求会被拒绝——这是防止误签发的一道防线。实际中常见的坑是：主域配了 CAA 只允许某家 CA，后来给子域申请别家的证书时签发失败，查半天才发现是 CAA 拦的。

SRV（Service）记录用来描述”某项服务在哪台主机的哪个端口上”，格式里带优先级、权重和端口：

_sip._tcp.example.com.    300    IN    SRV    10 60 5060 sipserver.example.com.

它主要出现在 SIP、XMPP、Minecraft 服务器等场景，普通网站基本用不到，但看到 _服务._协议.域名 这种下划线开头的名字时要知道它是什么。

想快速查看某个域名当前配置了哪些记录，直接用 DNS 查询输入域名就能看到各类记录的解析结果，不用开终端。

为什么 CNAME 不能和其他记录共存

这是 DNS 规则里最容易踩的一条：一个名字一旦是 CNAME，它下面就不能再有任何其他类型的记录（DNSSEC 相关的除外）。逻辑上很好理解——CNAME 的意思是”这个名字的一切都以另一个名字为准”，如果它同时又有自己的 A 记录，到底听谁的？

由此引出一个经典问题：根域名（apex domain，如 example.com）不能是 CNAME。因为根域名上必须存在 SOA 和 NS 记录，而 CNAME 不能和它们共存，所以 example.com CNAME cdn.example.net 是非法配置。这就是为什么很多 CDN 教程让你把 www 指向它们，而裸域需要另想办法。

解决办法有几种：用 A/AAAA 记录直接指向服务的 IP（缺点是 IP 变了要手动更新）；或者使用部分 DNS 服务商提供的 CNAME Flattening / ALIAS / ANAME 这类扩展——它们在权威服务器层面动态把 CNAME 的目标解析成 A 记录返回，效果上等同于”根域名的 CNAME”。要注意这些是各厂商的私有扩展，不是 DNS 标准，行为和名称因服务商而异，换服务商时配置不一定能照搬。

TTL 与缓存行为

每条记录都带一个 TTL（Time To Live），单位是秒，表示”这个结果可以被缓存多久”。前面例子里的 300 就是缓存 5 分钟。递归解析器拿到答案后，在 TTL 到期前都会直接返回缓存，不再去问权威服务器。

TTL 是个权衡：

TTL 长（如 86400 秒 = 一天）：权威服务器压力小、解析快，但改记录后生效慢。
TTL 短（如 60–300 秒）：改动生效快，适合需要频繁切换的场景，代价是查询量大、解析延迟略高。

最重要的实战经验：计划迁移服务器前，提前至少一个旧 TTL 周期把 TTL 调低。比如当前 TTL 是 86400，就至少提前一天把它改成 300，等全世界缓存里的都是短 TTL 版本之后再切 IP，切换就能在几分钟内生效。迁移完成、确认稳定后再把 TTL 调回去。如果你改了记录之后”有人能访问有人不能”，多半就是旧 TTL 的缓存还没过期。

常见配置错误

实际工作中高频出现的 DNS 错误基本就这几类：

根域名配 CNAME：非法配置，多数 DNS 服务商直接拒绝保存，但有些界面允许保存后造成解析异常、邮件失效。根域名请用 A/AAAA 或服务商的 ALIAS 类功能。
MX 指向 CNAME：RFC 明确禁止 MX 的目标是一个别名。正确做法是让 MX 指向一个有 A/AAAA 记录的主机名，比如 mail.example.com，再给它配地址记录。
迁移前没调低 TTL：改完 IP 才发现旧记录要缓存一天，只能干等。参见上一节的正确姿势。
CNAME 和其他记录混搭：比如给 blog.example.com 同时配了 CNAME 和 TXT，违反共存规则，行为不可预期。
改 NS 之后旧服务商的记录没同步：切换 DNS 服务商时，新旧两边的权威服务器要在过渡期内保持记录一致，否则部分用户会解析到旧数据。
CAA 过于严格：只放行了一家 CA，换证书提供商或申请新证书时签发失败。

排查流程：dig、nslookup 与传播检查

DNS 问题排查的核心思路是：分清是权威数据错了，还是缓存还没更新。推荐的工作流：

直接问权威服务器，绕过所有缓存，看”真实”的配置：

dig @ns1.dns-provider.com example.com A +short

如果权威应答就是错的，去 DNS 服务商控制台改配置。

问公共递归解析器，看缓存里的结果：

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com MX

对比第 1 步和第 2 步的结果：权威对、递归旧，就是缓存未过期，等 TTL 或继续下一步；两边一致但不符合预期，说明配置本身就没改对。

看完整应答和 TTL 倒计时：不加 +short 的 dig example.com A 会显示剩余 TTL（每次查询都在减少）和应答来自哪台服务器。dig +trace example.com 还能完整走一遍从根到权威的委托链，定位是哪一级出了问题。没有 dig 的环境（比如 Windows 默认）用 nslookup example.com 和 nslookup -type=MX example.com 也能完成大部分检查。
检查全球传播情况：不同地区的递归服务器缓存状态不同。不想开终端的话，用 DNS 查询快速确认记录当前值，再配合权威/递归对比的思路判断是不是传播延迟。
邮件问题先查 MX 链：MX 指向的主机名是否真的有 A 记录？拿到的 IP 是不是你预期的邮件服务器？可以用 IP 归属查询确认那个 IP 属于哪家服务商，避免邮件被投到早已下线的旧服务器上。

另外一个容易被忽视的前提：DNS 记录里写的都是域名，如果你手头的线索是一个 URL，先用 URL 解析把主机名拆出来再查，别带着路径和参数去 dig。

DNS 的规则不多，但每条都踩过坑的人才会真正记住：A 管 IPv4、AAAA 管 IPv6、CNAME 是独占式别名、MX 要带优先级且目标不能是别名、TTL 以秒计且迁移前要先调低。掌握这些，再加上”权威对比递归”的排查思路，绝大多数 DNS 问题都能在十分钟内定位。