DigitalPlat FreeDomain 的 DNS 记录类型实战指南：A、CNAME、MX、TXT、CAA 的配置规则与 dig 验证方法

2026-09-04 13:29:25作者：裘晴惠Vivianne

本篇基于 DNS 记录类型教程展开，讲清在外部权威 DNS 服务中配置 A、AAAA、CNAME、MX、TXT、CAA、NS/SOA、PTR 等各类记录的格式、取值约束与常见陷阱，并给出每一步可复制的 dig 验证命令。读完本文，你能够为已注册的域名正确编排全套记录，并能在保存前用检查清单排除绝大多数配置错误。

一、前提：记录应该在哪个平台编辑

在讨论具体记录类型之前，先明确一个关键前提：资源记录（Resource Record）必须创建在托管区域（zone）的外部权威 DNS 服务上，而不是在域名注册平台里。教程索引中特别强调：只接受 nameserver 主机名的域名注册平台并不是记录编辑器——它负责登记授权名称服务器，真正的记录增删改查发生在外部权威 DNS 服务的控制台中。

本仓库教程贯穿一条工作规则：一次只做一处 DNS 变更，记录旧值，等待权威应答更新后再验证，确认无误才动下一层。后文各记录类型的示例域名 example.dpdns.org 均属于文档中的演示占位，实操前请替换为你自己的域名和真实服务器地址。

二、一条 DNS 记录的解剖

一条 DNS 记录由四个基本要素构成，部分记录类型还会带有优先级或其他参数：

Name（名称）：相对于所在区域的名称，区域顶点（apex）常用 @ 表示；
Type（类型）：记录类型，如 A、MX、TXT；
Value（值）：与类型对应的数据，如地址、目标主机名、文本字符串；
TTL（生存时间）：递归解析器可缓存该应答的最长秒数。

TTL 的含义在 TTL、缓存与传播章节中有系统讲解：递归解析器收到 example.dpdns.org. 3600 IN A 192.0.2.10 这类应答后，最长可在 3600 秒内直接复用缓存；权威记录更新不会抹掉已经下发的缓存。因此"为计划中的变更预留足够低的 TTL"是后文所有记录操作的通用纪律。

下面逐类讲解各记录类型的格式、约束与验证方法。

三、A 记录：主机名到 IPv4 地址的映射

A 记录把主机名映射到一个 IPv4 地址，是最基础的网站接入记录：

Name:  @
Type:  A
Value: 192.0.2.10
TTL:   3600

核心约束：

必须使用服务器的真实公网 IPv4 地址，不要使用 192.168.1.10 这类内网地址——公网解析器无法路由到内网地址，网站必然不可达；
Name 为 @ 表示区域顶点（即注册域名本身）。注意不同 DNS 控制台的命名习惯不同：有的自动补全域名后缀，此时填完整域名会生成 example.dpdns.org.example.dpdns.org 这样的错误名字，这一坑在子域名字节中也有提示，遵循所选界面自身的惯例即可。

验证命令：

dig A example.dpdns.org

配合命令参考，诊断时建议保留 dig 的完整输出（flags、authority、TTL 上下文），脚本中才使用 dig +short：

dig +short A example.dpdns.org

完整的输出模式还会展示 TTL 与 IN 类字段，dig A example.dpdns.org +noall +answer 可以只看应答区。

四、AAAA 记录：主机名到 IPv6 地址的映射

AAAA 记录把主机名映射到 IPv6 地址：

Name:  @
Type:  AAAA
Value: 2001:db8::10
TTL:   3600

关键判断标准：只有当服务器确实可以通过 IPv6 到达时才发布 AAAA 记录。如果 IPv6 路径实际是断的，偏好 IPv6 的客户端会先尝试 IPv6 再回退 IPv4，站点在用户看来会变得不稳定。因此"能发则发、发布则保证可达"，而不是为了双栈展示而盲目配置。

验证：

dig AAAA example.dpdns.org

故障排查章节中"只有部分用户看到新网站"一节也指出，IPv4 与 IPv6 指向不同服务器是常见症状之一，双栈记录需要分别验证。

五、CNAME 记录：把主机名变成别名

CNAME 让一个主机名成为另一个主机名的别名，典型用途是让 www 指向裸域：

Name:  www
Type:  CNAME
Value: example.dpdns.org
TTL:   3600

两条硬性规则：

CNAME 的目标必须是主机名，不能是 IP 地址；
带有 CNAME 的名称通常不能再有其他类型的记录（不能与 A、TXT 等并存于同一名称），这条规则在验证与服务记录章节中做 CNAME 验证时同样被重申。

一个常见网站编排是：

example.dpdns.org      A       192.0.2.10
www.example.dpdns.org  CNAME   example.dpdns.org

注意 DNS 只完成解析层面的指向，不会自动产生 HTTP 重定向——Web 服务器必须同时接受两个主机名，并在 Web 层把其中一个 301 到规范域名。

验证：

dig CNAME www.example.dpdns.org

六、MX 记录：邮件的收件路由

MX 记录把域名的收件邮件路由到邮件服务器：

Name:     @
Type:     MX
Priority: 10
Value:    mail.example.dpdns.org
TTL:      3600

规则与要点：

数值越小优先级越高，多路邮件服务器可用多条不同优先级的 MX 记录实现主备关系；
MX 的 Value 必须是主机名，且该主机名要有地址记录（A/AAAA）——不能写 CNAME，更不能直接把 IP 地址写在 MX 值里。

一套典型的双 MX 配置（示例来自邮件 DNS 章节）：

example.dpdns.org.  3600  MX  10  mx1.mail-system.example.
example.dpdns.org.  3600  MX  20  mx2.mail-system.example.

验证：

dig MX example.dpdns.org

MX 只负责收件路由。发件可信度由 SPF、DKIM、DMARC 三套基于 TXT 记录的机制承担，这些机制的完整部署流程在邮件 DNS 章节中展开，本篇不再赘述。

七、TXT 记录：所有权验证、邮件策略与服务配置

TXT 记录存放各类文本数据，用途包括所有权验证、SPF/DKIM/DMARC 邮件策略和服务配置参数：

Name:  @
Type:  TXT
Value: service-verification=replace-with-issued-value
TTL:   3600

两条操作纪律：

验证值必须原样照抄，不要"美化"或改写字符；
不要擅自合并多条 TXT 记录，除非服务文档明确要求。尤其是 SPF——每个名称只能发布一条 v=spf1 策略，把多条策略拆成多条 TXT 会破坏解析。

关于安全性，原教程澄清了一个常见误区：验证 token 本来就是设计为公开可读的（除非服务方另有说明），"记录不暴露机密"这条检查项针对的是其他数据——切勿把凭据、账号 ID 之类写进 TXT 值。

验证：

dig TXT example.dpdns.org

若为 DKIM 或 DMARC 这类子名称，则按具体名称查询，例如：

dig TXT selector1._domainkey.example.dpdns.org
dig TXT _dmarc.example.dpdns.org

八、CAA 记录：限制可为域名签发证书的 CA

CAA（Certificate Authority Authorization）记录限定哪些证书机构（CA）可以为该域名签发证书：

Name:  @
Type:  CAA
Flag:  0
Tag:   issue
Value: ca.example
TTL:   3600

字段说明：

Flag：0 表示普通指令（非临界标志位）；
Tag：issue 表示"只允许 Value 中的 CA 签发"；
Value：被许可 CA 的主机名。

最重要的风险提示：错误的 CAA 记录会直接阻断证书签发。因此 CAA 不是"顺手加上的安全加固"，而应当在你明确 HTTPS 部署实际使用的证书机构之后再加。如果你的 HTTPS 方案尚未确定 CA，建议暂缓配置。

验证：

dig CAA example.dpdns.org

九、NS 与 SOA：区域权威本身

NS 记录标识权威名称服务器，SOA 记录描述区域的权威信息与定时参数（刷新、重试、有效期等）。托管式 DNS 服务通常自行管理区域顶点的 NS 与 SOA 记录，你不需要（也不应该）手工改动。

理解 NS 记录时有一个容易混淆的层次问题：在子区域内部修改 NS 记录，并不必然改变父域的委派（delegation）。注册域名的 nameserver 变更必须通过域名注册服务完成，父域发布的是委派，解析器沿委派路径寻找权威。这一委派链条的核对方法见委派与外部名称服务器章节：

dig NS example.dpdns.org
dig +trace NS example.dpdns.org
dig @ns1.dns-service.example SOA example.dpdns.org

其中 dig +trace 从根开始跟踪整条解析路径，能帮你区分"父域委派问题"还是"子区域自身问题"；直接问权威服务器要 SOA，则可确认该服务器是否真的在发布这个区域。

十、PTR 记录：反向解析由 IP 所有者控制

PTR 记录把 IP 地址反向映射回主机名。它的特殊性在于控制权不在你的域名手里：公网 PTR 由 IP 地址所在网段的网络所有者（通常是云厂商或 ISP）管理，普通的正向 DNS 区域无法为服务器地址设置公网 PTR。如果你的邮件服务器需要反向解析，需要向持有该 IP 的提供商申请，而不是在自己的 DNS 控制台里找配置入口。

十一、保存记录前的安全检查清单

原教程给出了保存任何记录前的六项检查，建议固化为保存前的肌肉记忆：

名称是相对于预期区域写的（对照界面是否自动补全后缀）；
值的格式符合该类型的要求（A/AAAA 是地址，CNAME/MX 目标是主机名，TXT 原样照抄）；
TTL 与计划中的变更窗口匹配（迁移前按 TTL 章节的建议提前调低）；
同一名称下不存在相互冲突的 CNAME；
文档里的演示 IP（如 192.0.2.10、2001:db8::10）已被替换为真实服务器地址；
记录中没有写入任何不应公开的秘密数据。

十二、验证命令速查与排查路径

把各类型验证命令汇总如下（完整命令体系见命令参考）：

dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
dig MX example.dpdns.org
dig TXT example.dpdns.org
dig CAA example.dpdns.org
dig NS example.dpdns.org
dig +trace NS example.dpdns.org

验证时区分两种视角：dig A example.dpdns.org 问的是本机配置的递归解析器（含缓存），dig @ns1.dns-service.example A example.dpdns.org 问的是权威服务器本身。若权威应答已是新值而递归应答仍是旧值，说明区域正确、缓存仍在有效期内——此时等待比反复改记录更安全。若权威应答本身就是错的，按故障排查章节的路径从委派层向最终服务逐层核对，不要同时改动多个层面。