记录类型

这一课你将能做到

用 dig / nslookup 分别查出 A、AAAA、CNAME、MX、TXT、NS、SOA、PTR、SRV、CAA 十类记录，并在输出中指出 TYPE 与 ANSWER 的位置
说清楚何时用 A、何时用 CNAME，以及「同一主机名上 CNAME 与其他记录并存」为什么会踩坑
读出一条答案的 TTL，并解释改记录后短时间内为什么仍可能看到旧值

为什么要学

上线 www.coderoadmap.cn 时，DNS 面板里远不止「填一个 IP」这么简单：HTTPS 证书申请要验证 TXT，收发邮件要配 MX 和反垃圾 TXT，接入 CDN 通常要求加一条 CNAME，域本身由 NS 指明权威服务器，CAA 决定哪些 CA 能给你的域签发证书。后端或运维如果只会查 A 记录，遇到「证书续期失败」「邮件进垃圾箱」「子域指错 CDN」会完全摸不着门。

本课按 RFC 1035 的资源记录（Resource Record，RR）心智模型来讲：记录类型决定这条名字代表什么——是地址、别名、邮件交换、服务定位还是一段文本声明——而不是死背一串缩写。SOA、邮件三件套、CAA 等会在后续课程展开，本课先建立完整地图。

先建立图像

一条资源记录（RR）的通用结构：

  名字(owner)  TTL  类(CLASS)  类型(TYPE)  值(RDATA)
  ───────────  ───  ─────────  ─────────  ────────────────
  www.coderoadmap.cn.  300  IN  A      203.0.113.10
  api.coderoadmap.cn.  600  IN  CNAME  www.coderoadmap.cn.
  coderoadmap.cn.      3600 IN  MX     10 mail.coderoadmap.cn.
  coderoadmap.cn.      3600 IN  TXT    "v=spf1 -all"
  coderoadmap.cn.      3600 IN  CAA    0 issue "letsencrypt.org"

类型	人话解释	典型用途
A	名字 → IPv4 地址	指向云主机、负载均衡器
AAAA	名字 → IPv6 地址	双栈站点
CNAME	这个名字是另一个名字的别名	CDN、SaaS 托管平台入口
MX	这个域的邮件交给哪台主机收	企业邮箱、第三方邮件服务
TXT	挂一段可供查询验证的文本	SPF、ACME 域名验证、DMARC
NS	这个域的权威 DNS 是谁	委派给 Cloudflare、云厂商 DNS
SOA	区域的主控信息（序列号、管理员邮箱、计时参数）	每个区域开头必有一条
PTR	IP → 名字（反向解析）	邮件服务器信誉、日志排查
SRV	某服务在「主机+端口」哪里提供	LDAP、SIP、XMPP、服务发现
CAA	哪些证书机构允许为本域签发证书	证书安全管控

跟着做

用本机终端即可；把 coderoadmap.cn 换成你自己的域，命令形态完全相同。

步骤 1：查 A 与 AAAA，理解「空」不等于「坏」

dig www.coderoadmap.cn A +short       # IPv4
dig www.coderoadmap.cn AAAA +short    # IPv6

# Windows
nslookup -type=A www.coderoadmap.cn
nslookup -type=AAAA www.coderoadmap.cn

示例输出：

104.21.5.10
172.67.133.10

A 记录至少有一条 IPv4；AAAA 可能为空——空只表示未配置 IPv6，不代表 DNS 故障。浏览器在双栈环境下会优先尝试 AAAA（受 Happy Eyeballs 算法影响，RFC 8305）。

步骤 2：看完整报文，读懂 TTL 与各分区

dig www.coderoadmap.cn A

重点看这一行：

;; ANSWER SECTION:
www.coderoadmap.cn.  278  IN  A  203.0.113.10

名字和 IN（Internet 类）之间的数字就是 TTL（秒），在递归缓存中会倒计时。连续查两次看到 278 → 240，说明命中了递归服务器的缓存；从权威服务器查到的永远是初始值（如 300）。

步骤 3：查 NS、SOA、MX、TXT

dig coderoadmap.cn NS +short
dig coderoadmap.cn SOA +short
dig coderoadmap.cn MX +short
dig coderoadmap.cn TXT +short
dig _dmarc.coderoadmap.cn TXT +short

示例输出（经过精简）：

# NS
ns1.cloudflare.com.
ns2.cloudflare.com.

# SOA：主NS  管理员邮箱(第一个.代@)  序列号  刷新  重试  过期  否定缓存
ns1.cloudflare.com. dns.cloudflare.com. 2311000042 10000 2400 604800 3600

# MX
10 mail.coderoadmap.cn.

SOA 最后一个字段是「否定答案缓存时间」（negative TTL）：查不到的名字（NXDOMAIN）也会被缓存这么久，这是新增记录后「别人查不到」的常见原因之一。

步骤 4：查 CNAME，观察别名跳转链

dig docs.coderoadmap.cn CNAME +short
dig docs.coderoadmap.cn A +short

示例输出：

coderoadmap.github.io.          # CNAME 的目标
185.199.108.153                 # 继续解析目标拿到的最终 IP

CNAME 是「别去问我，去问另一个名字」。CDN 场景（如 cdn.coderoadmap.cn → xxx.cdnprovider.com）用得最多：对方换 IP 你完全不用管。

步骤 5：查 PTR、SRV、CAA

# PTR：反向解析，要用特殊写法 10.113.0.203.in-addr.arpa
dig -x 203.0.113.10 +short

# SRV：格式 _服务._协议.域，例如 LDAP 或 SIP
dig _sip._tcp.example.com SRV +short

# CAA：本域允许哪些 CA 签发证书
dig coderoadmap.cn CAA +short

示例输出：

# PTR
mail.coderoadmap.cn.

# SRV：优先级 权重 端口 目标
10 60 5060 sip1.example.com.

# CAA：flag 标签 值
0 issue "letsencrypt.org"
0 issuewild ";"

PTR 记录不属域管理员管，而属 IP 持有者（云厂商、运营商）在对应反向区域中配置；自建邮件服务器时通常要提工单让云厂商设置。

步骤 6：nslookup 交互模式复查（Windows 友好）

nslookup
> set type=SOA
> coderoadmap.cn
> set type=CAA
> coderoadmap.cn
> exit

把 dig 与 nslookup 的答案并排抄一行：类型必须一致，主机名/IP 应一致（TTL 显示方式允许不同）。团队里有人只用 Windows 时，runbook 要同时给两种命令。

补充一个面板心智：云厂商 DNS 面板的「主机记录」常只填 www 或 @，完整名字是拼上域名后的结果；而 dig 永远用完整域名（Fully Qualified Domain Name），不要拿面板的省略写法猜。

讲清楚要点

TYPE 决定语义：同一个名字下，A 和 MX 回答的是完全不同的问题，查错类型就会误判「没配置」。
A/AAAA 直接给地址：自建机、固定 LB IP 用 A；做双栈就在 A 之外再加 AAAA。
CNAME 表示「去问另一个名字」：适合跟随 CDN、SaaS 厂商提供的目标域名，对方 IP 变更时你一处都不用改。
CNAME 按 RFC 1034 规定不能与同名其他数据并存（有 DNSSEC 例外，RFC 4034 放宽过部分场景）：「www 既是 CNAME 又挂 MX」是典型事故源；裸域（@）因此通常不能直接设 CNAME，厂商用 ALIAS/ANAME 这类非标准记录模拟。
TTL 告诉递归器答案能记多久：改记录后，旧 TTL 窗口内仍可能返回旧值。切流量前 24～48 小时先把 TTL 降到 300～600。
TXT 是自由文本通道：SPF、DKIM、DMARC、ACME DNS-01、各类域名所有权验证都挤在这里。单条 TXT 最长 255 字符，长文本需按 RFC 4408 拆成多段字符串。
NS 指向权威：换 DNS 托管的本质是在注册商处改 NS（以及必要的胶水记录）；只在旧面板改记录而 NS 还指旧家，公网不会认。
一条名字可以有多条 A：客户端可能轮询或按地址选择（RFC 6724），但这不是负载均衡——没有健康检查，挂一台就有一部分用户失败。

你可能会懵的地方

CNAME 和 301 跳转一样吗？ 完全不同。CNAME 是 DNS 层别名，浏览器地址栏不会变；301 是 HTTP 层重定向，地址栏会变成新 URL，且由服务器在拿到请求后发出。
裸域 @ 为什么很多面板不让设 CNAME？ 根域上必须存在 SOA、NS，通常还要挂 MX，与「该名字只能有一条 CNAME」的规则冲突。Cloudflare 的 CNAME Flattening、云厂商的 ALIAS/ANAME 在解析侧自动把别名追成 A 返回，绕过了这个限制。
TTL 是权威写死的吗？为什么会变小？ 权威给出初始 TTL；你在递归器上看到的是「剩余缓存时间」，所以会倒计时归零后重新取。
MX 为什么不能直接写 IP？ 协议规定 MX 的值必须是主机名（域名）。该主机名再通过 A/AAAA 找到地址。写 IP 在很多邮件系统里会直接拒收。
CAA 查不到记录意味着什么？ 没有 CAA 表示「任何 CA 都可以签发」，这是默认行为。一旦设置了 CAA，CA 在签发前必须查询（RFC 8659/8657），不在白名单里的证书请求会被拒绝。

错法对照

错法	后果	正确做法
给已有 CNAME 的主机再加 A	解析器行为不一致，部分面板直接拒配	二选一：直接 A，或纯 CNAME
MX 值写成 IP	邮件投递失败或被拒收	MX 写主机名，再给主机配 A/AAAA
只查 A 就断言「没开邮件防护」	漏掉 TXT、_dmarc、DKIM 子域	按类型分别 dig，查全子域
TTL 长期 86400 又频繁切 IP	全球最长一天不一致	变更窗口前降到 300～600，事后恢复
TXT 记录漏写引号或拼错主机名	ACME 验证、SPF 校验失败	按面板格式写，dig 回查确认
自建邮件服务不配 PTR	对端按垃圾邮件拒收	找 IP 所属云厂商配置反向解析

卡点急救

面板提示「主机名冲突 / 记录已存在」：八成是该名字下已有 CNAME。先删除或改名，CNAME 必须独占一个 owner。
新增记录后别人查不到、你本地能查到：查 SOA 最后一列 negative TTL；如果该名字之前长期不存在，NXDOMAIN 被递归器缓存了。用 dig @8.8.8.8 名字 验证权威侧真相，等待否定缓存过期。
证书申请报 CAA 错误但你没配过 CAA：可能在父级域或 SaaS 平台侧设置了 CAA；dig 域 CAA 逐级向上查（含注册商默认策略），临时加一条 0 issue "对应CA" 即可放行。

面试常问

A 记录和 CNAME 的区别？什么场景用哪个？ A 直接把名字映射到 IPv4（AAAA 映射 IPv6）；CNAME 把名字映射到另一个名字，解析器要继续追踪。固定 IP 用 A；接入 CDN、GitHub Pages、SaaS 这类「目标 IP 由对方管理」的场景用 CNAME，省得对方换 IP 你也要跟着改。限制是 CNAME 不能与同名其他记录共存，裸域通常不能用。
一条域名配多个 A 记录能不能当负载均衡？ 能提供最粗粒度的多入口冗余：解析器返回多个 IP，客户端按 RFC 6724 排序并尝试，部分客户端会轮询。但没有健康检查、没有权重、没有会话保持，一台机器宕机仍会有约 1/N 用户拿到坏 IP 且要等连接超时才切换。生产负载均衡要用专门的 LB。
TTL 的作用是什么？调大调小各有什么影响？ TTL 告诉各级缓存这条答案可以保存多久。调大：权威压力小、解析快，但变更生效慢；调小：变更传播快，但权威查询量大、解析延迟略增。运维惯例是平时 3600～86400，计划变更前 1～2 天降到 300～600，变更后恢复。

自测三问

A、CNAME、MX、TXT、PTR、SRV 各回答什么问题？各举一个本站可能的使用场景。
为什么「www 已有 CNAME 时不宜再挂同名 A 或 MX」？
dig 两次同一条 A，TTL 从 300 变成 280，说明这条答案正存在于哪一级？从权威服务器直接查（dig @权威NS）会显示多少？

小结一句话

记录类型决定名字的含义——地址、别名、邮件、服务位置或文本声明；TTL 决定旧答案还能赖在缓存里多久。

延伸

RFC 1035：DNS 资源记录与报文
RFC 8659：DNS CAA 资源记录
RFC 2782：SRV 记录
IANA：DNS 记录类型注册表
下一课预告：解析过程——递归与迭代到底怎么配合，一条查询从根走到权威的完整路径。