核心要点： DNS 记录是您的域名与它所支撑的每一项互联网服务之间的桥梁。正确配置 A、CNAME、MX、TXT 和 CAA 记录，直接决定您的网站能否正常加载、电子邮件能否成功投递，以及 SSL 证书能否顺利签发。自 2024 年 2 月起，Google 和 Yahoo 已强制要求批量发信方必须启用 SPF/DKIM/DMARC 邮件身份验证——未正确配置邮件认证记录的域名，其邮件将被直接拒收。
完成域名注册后，真正让域名“跑起来”的，正是 DNS 记录。无论您是在上线网站、配置企业邮箱、接入 CDN，还是验证域名所有权，都必须扎实掌握各类 DNS 记录的用途及正确配置方法。
本指南详解全部 10 种核心 DNS 记录类型，涵盖精确的配置语法、真实场景示例，以及连资深管理员都容易踩坑的常见错误。同时，我们还会解读 2024 年生效的邮件身份验证强制要求，以及 CA/B 论坛正在强力推进的证书有效期大幅缩短时间表——每位域名持有者都必须为此做好准备。
快速对比表：全部 10 种 DNS 记录类型
在深入讲解每种记录之前，先整体把握全局：
| 记录类型 | 核心功能 | 示例值 | 使用频率 |
|---|---|---|---|
| A | 将域名解析为 IPv4 地址 | 192.0.2.1 | 极高 |
| AAAA | 将域名解析为 IPv6 地址 | 2001:db8::1 | 高 |
| CNAME | 将域名设为另一域名的别名 | cdn.example.com | 极高 |
| MX | 邮件路由 | mail.example.com（优先级 10） | 高 |
| TXT | 基于文本的验证数据 | v=spf1 include:… | 极高 |
| NS | 权威域名服务器委派 | ns1.cloudflare.com | 中等 |
| SOA | 区域权威元数据 | serial/refresh/retry | 低 |
| PTR | 将 IP 地址反向解析为域名 | mail.example.com | 中等 |
| SRV | 服务发现（主机 + 端口） | sip.example.com:5060 | 中等 |
| CAA | 限制 SSL 证书签发权限 | letsencrypt.org | 高（持续上升） |
1. A 记录：DNS 解析的基石
A 记录（地址记录） 是最基础的 DNS 记录类型，它将域名直接映射到一个 IPv4 地址，定义见 RFC 1035。
配置语法
example.com. 3600 IN A 192.0.2.1
字段说明：
example.com.—— 完全限定域名（末尾的点表示这是一个 FQDN）3600—— TTL（生存时间），单位为秒；指解析器缓存该记录的时间长度IN—— 类别（Internet，即互联网）A—— 记录类型192.0.2.1—— 目标 IPv4 地址
实际应用示例
单服务器托管：
example.com. 300 IN A 203.0.113.50
www.example.com. 300 IN A 203.0.113.50
轮询式负载均衡（多个 A 记录）：
example.com. 300 IN A 203.0.113.50
example.com. 300 IN A 203.0.113.51
example.com. 300 IN A 203.0.113.52
常见错误
- 在根域（zone apex）错误使用 CNAME 记录而非 A 记录。 DNS 规范（RFC 1034 第 3.6.2 节）明确禁止在根域名处设置 CNAME 记录，因为它会与 SOA 和 NS 记录冲突。根域应使用 A 记录（或你所用服务商提供的 ALIAS/ANAME 扁平化功能）。
- 迁移前将 TTL 设得过高。 若计划更换 IP 地址，请至少提前 48 小时将 TTL 降至 300 秒。
- 遗漏更新
@和www两条记录。 用户默认期望这两个地址都能正常访问。
2. AAAA 记录：IPv6 解析
AAAA 记录（定义于 RFC 3596）的作用与 A 记录相同，但将域名映射到 IPv6 地址。“AAAA”这一名称源于 IPv6 地址长度是 IPv4 的四倍。
配置语法
example.com. 3600 IN AAAA 2001:0db8:85a3::8a2e:0370:7334
实际示例
双栈配置（A 记录 + AAAA 记录并存）：
example.com. 300 IN A 203.0.113.50
example.com. 300 IN AAAA 2001:db8:1::50
常见错误
- 完全遗漏 AAAA 记录。 截至 2025 年，全球互联网流量中逾 40% 已使用 IPv6；移动网络（如 T-Mobile、Reliance Jio）默认启用 IPv6。
- 压缩表示法格式错误。 每个 IPv6 地址中
::简写仅能出现一次，例如2001::db8::1是非法格式。
3. CNAME 记录：域名别名
CNAME 记录（规范名称记录） 创建一个别名，将一个域名指向另一个域名。DNS 解析器随后会沿着这条链路查找最终的 A/AAAA 记录。
配置语法
blog.example.com. 3600 IN CNAME example.github.io.
实际应用示例
CDN 接入：
static.example.com. 300 IN CNAME d1234.cloudfront.net.
SaaS 平台托管：
shop.example.com. 3600 IN CNAME shops.myshopify.com.
help.example.com. 3600 IN CNAME example.zendesk.com.
常见错误
- 在根域（zone apex）使用 CNAME。 如前所述，
example.com. IN CNAME something.else.违反 RFC 规范。许多 DNS 服务商提供专有解决方案（例如 Cloudflare 的 CNAME Flattening、Amazon Route 53 的 ALIAS 记录、DNS Made Easy 的 ANAME 记录）。 - CNAME 与其他记录类型共存。 CNAME 记录不能与任何其他类型的记录（如 MX、TXT、A 等）共享同一名称。如果你希望
mail.example.com同时拥有 CNAME 和 MX 记录，这将无法生效——此时应改用 A 记录。 - CNAME 链式跳转。 虽然技术上允许，但多层 CNAME 跳转（例如 A → B → C）会增加解析延迟并降低稳定性。建议将跳转限制为单层。
4. MX 记录：电子邮件路由
MX 记录（邮件交换器） 告知发信邮件服务器，应将发往您域名的电子邮件投递到何处。每条 MX 记录都包含一个优先级值——数值越小，优先级越高。
配置语法
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
实际应用示例
Google Workspace：
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt4.aspmx.l.google.com.
Microsoft 365：
example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.
常见错误
- 将 MX 记录指向 CNAME。 RFC 2181 第 10.3 节明确规定，MX 记录的目标必须是 A 或 AAAA 记录，不能是 CNAME。尽管部分邮件服务器能容忍这种配置，但极易导致邮件投递失败。
- MX 目标缺少对应的 A/AAAA 记录。 如果
mail.example.com没有配置 A 记录，所有发往该域的邮件都将彻底无法送达。 - 盲目设置相同的优先级值。 多条 MX 记录优先级相同时，邮件服务器会随机分发流量，而非实现主备切换。如需主备机制，请务必使用不同优先级值。
5. TXT 记录：验证与身份认证
TXT 记录用于存储与域名关联的任意文本数据。最初设计用于存放人类可读的备注信息，如今已成为域名所有权验证、电子邮件身份认证（SPF、DKIM、DMARC）以及安全策略实施的关键基础设施。
配置语法
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
实际应用示例
域名所有权验证（Google Search Console）：
example.com. 3600 IN TXT "google-site-verification=abc123xyz..."
多个 TXT 记录（完全合法）：
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=abc123xyz"
example.com. 3600 IN TXT "facebook-domain-verification=def456"
常见错误
- 单个字符串超出 255 字符限制。 一条 TXT 记录可容纳多个 255 字节的字符串（拼接后总容量最高约 64KB），但部分 DNS 服务商仅提供一个字符串输入框。此时应将长值拆分为多个带引号的字符串：
"string1" "string2"。 - 配置了多个 SPF 记录。 你只能拥有一条以
v=spf1开头的 TXT 记录。存在多条 SPF 记录将触发 PermError 错误（RFC 7208 第 3.2 节）。请通过include:机制将所有 SPF 规则合并至单条记录中。
6. NS 记录：域名服务器委派
NS 记录（Name Server，域名服务器） 将一个 DNS 区域委派给特定的权威域名服务器。这类记录存在于两个层级：父区域（注册局）和您自己的区域。
配置语法
example.com. 86400 IN NS ns1.cloudflare.com.
example.com. 86400 IN NS ns2.cloudflare.com.
子域名委派：
api.example.com. 3600 IN NS ns1.api-provider.com.
api.example.com. 3600 IN NS ns2.api-provider.com.
常见错误
- 在 DNS 服务商处修改 NS 记录，而非在注册商处操作。 实际起委派作用的 NS 记录由父区域（即您的注册商 NamesLink）维护。仅在您自己的区域文件中更新 NS 记录，却不更改注册商处的设置，完全无效。
- 使用的域名服务器少于两台。 RFC 1034 建议至少配置两台地理位置分散的域名服务器，以保障冗余性。
7. SOA 记录：区域权威元数据
SOA 记录（Start of Authority，起始授权） 包含有关 DNS 区域的管理信息。每个区域必须且只能有一条 SOA 记录。它控制辅助域名服务器如何与主域名服务器同步。
配置语法
example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
2024052201 ; 序列号（格式：YYYYMMDDNN）
7200 ; 刷新间隔（2 小时）
3600 ; 重试间隔（1 小时）
1209600 ; 过期时间（14 天）
300 ; 最小 TTL / 负缓存时长
)
关键字段说明
| 字段 | 用途 | 推荐值 |
|---|---|---|
| Serial（序列号） | 版本号；每次修改区域配置后必须递增 | YYYYMMDDNN 格式 |
| Refresh（刷新间隔） | 辅助服务器检查主服务器更新的频率 | 3600–7200 秒 |
| Retry（重试间隔） | 刷新失败后，辅助服务器再次尝试的间隔 | 900–3600 秒 |
| Expire（过期时间） | 主服务器不可达时，辅助服务器停止响应查询的时间点 | 1209600 秒（14 天） |
| Minimum（最小 TTL） | 对“不存在”类响应（如 NXDOMAIN）的缓存时长 | 300–3600 秒 |
常见错误
- 忘记递增序列号。 辅助域名服务器通过比对序列号来判断是否需要执行区域传输。如果你修改了区域内容却未更新序列号，辅助服务器将继续提供过时的数据。
- 将 Expire 设得过低。 如果主服务器因维护临时下线，过低的 Expire 值会导致辅助服务器彻底停止响应你的域名查询。
8. PTR 记录：反向 DNS 查询
PTR 记录（指针记录） 将 IP 地址映射回域名——这与 A 记录的作用相反。它存在于特殊的 in-addr.arpa（IPv4）或 ip6.arpa（IPv6）区域中。
配置语法
50.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.
注意 IP 地址的八位组顺序是反转的：203.0.113.50 转换为 50.113.0.203.in-addr.arpa.
为什么 PTR 记录至关重要
- 邮件投递成功率。 接收邮件服务器会执行反向 DNS 查询，以验证发信服务器的身份。若 PTR 记录与服务器声明的 HELO/EHLO 主机名不一致，将导致邮件被判定为垃圾邮件并增加垃圾邮件评分。
- 日志记录与故障排查。 Traceroute 和日志分析工具依赖 PTR 记录，将原始 IP 地址转换为主机名进行显示。
常见错误
- 未向托管服务商申请配置 PTR 记录。 PTR 记录由 IP 地址段的所有者（你的 ISP 或云服务提供商）管理，而非由你域名的 DNS 区域控制。通常你需要提交工单，请他们为你配置。
- PTR 记录与 A 记录不匹配。 PTR 记录应解析为一个主机名，而该主机名必须拥有一个对应的 A 记录，且该 A 记录需指向同一 IP 地址（即“正向确认反向 DNS”，FCrDNS）。
9. SRV 记录：服务发现
SRV 记录（Service Record） 定义于 RFC 2782，用于让客户端自动发现特定服务所对应的主机名和端口号。它被广泛应用于 VoIP（SIP）、XMPP、LDAP 以及 Microsoft Active Directory 等场景。
配置语法
_service._protocol.example.com. TTL IN SRV 优先级 权重 端口 目标主机名
实际应用示例
SIP（VoIP）服务：
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 40 5060 sipserver2.example.com.
XMPP（Jabber）即时通讯：
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.
Microsoft 365 自动发现（Autodiscover）：
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 autodiscover.outlook.com.
各字段含义
- 优先级（Priority） — 数值越小，优先级越高（与 MX 记录类似），客户端会优先尝试该记录
- 权重（Weight） — 用于在相同优先级的多个目标之间分配流量（数值越大，分得流量越多）
- 端口（Port） — 服务所使用的 TCP 或 UDP 端口号
- 目标（Target） — 提供该服务的主机名（必须为 A 或 AAAA 记录，不可为 CNAME）
常见错误
- 遗漏下划线前缀。 服务名与协议名必须以下划线
_开头（例如_sip._tcp），否则客户端无法识别并查找该服务。 - 将目标指向 CNAME 记录。 与 MX 记录一样，SRV 的目标主机名必须直接解析为 A 或 AAAA 记录，不能是 CNAME。
10. CAA 记录：证书颁发机构授权
CAA 记录（Certificate Authority Authorization，证书颁发机构授权） 由 RFC 8659 定义，用于指定哪些证书颁发机构（CA）被允许为您的域名签发 SSL/TLS 证书。自 2017 年 9 月起（CA/B 论坛投票 Ballot 187），所有 CA 在签发证书前必须检查该域名的 CAA 记录。
配置语法
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
标签类型
| 标签 | 用途 |
|---|---|
issue | 授权某 CA 签发标准证书 |
issuewild | 授权某 CA 签发通配符证书 |
iodef | 安全事件报告端点（邮箱地址或 URL） |
实际应用示例
仅允许 Let’s Encrypt 和 DigiCert 签发证书：
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:certs@example.com"
禁止所有证书签发（适用于明确不应部署证书的域名）：
parked-domain.com. 3600 IN CAA 0 issue ";"
CA/B 论坛投票 SC-081v3：证书有效期缩减时间表
2025 年 4 月，CA/B 浏览器论坛通过投票 SC-081v3，强制大幅缩短 TLS 证书最大有效期：
| 生效日期 | 最大有效期 | 最大 DCV 复用期限 |
|---|---|---|
| 2026 年 3 月 15 日 | 200 天 | 200 天 |
| 2027 年 3 月 15 日 | 100 天 | 100 天 |
| 2029 年 3 月 15 日 | 47 天 | 10 天 |
这对您意味着：
- 自动化不再是可选项。 当证书有效期压缩至 47 天时，手动续期在运维层面已不可行。请立即部署 ACME 客户端（如 certbot、acme.sh）。
- CAA 记录的重要性进一步提升。 频繁的自动续期流程下，一条配置错误的 CAA 记录将直接导致证书签发失败，引发服务中断。
- 域名控制验证（DCV）复用窗口急剧收窄。 到 2029 年，您必须每 10 天重新证明一次域名所有权，因此稳定可靠的 DNS 基础设施变得至关重要。
若您正在为新项目挑选域名，选择一家提供强大 DNS 管理功能及 API 接口的注册商，将极大减轻后续运维负担。例如 Nameslink 在提供域名注册服务的同时，也开放 DNS API，让您从第一天起就能实现证书签发流程的全自动化。
邮件身份验证：SPF、DKIM 和 DMARC
2024 年谷歌/雅虎强制要求
自 2024 年 2 月 1 日起，谷歌和雅虎对批量发件人（即每日向 Gmail/雅虎邮箱地址发送超过 5,000 封邮件的发件人）实施严格的电子邮件身份验证要求：
- SPF 或 DKIM 身份验证 —— 所有发件人均须配置
- DMARC 策略 —— 批量发件人必须配置
- 一键退订功能 —— 营销类邮件必须提供
- 垃圾邮件投诉率低于 0.3% —— 强制执行的阈值
未合规的域名将面临临时错误（4xx）、直接拒收（5xx）或邮件被投递至垃圾邮件文件夹。
SPF（发件人策略框架）
SPF（RFC 7208）用于定义哪些邮件服务器被授权代表您的域名发送电子邮件。
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all"
机制解析：
v=spf1—— 版本标识符（必需，且只能出现一次）include:_spf.google.com—— 授权 Google Workspace 的邮件服务器include:sendgrid.net—— 授权 SendGrid 发送事务性邮件ip4:203.0.113.50—— 授权某一特定 IPv4 地址-all—— 拒绝所有其他来源（硬失败）
SPF 限定词参考表：
| 限定词 | 含义 | 建议 |
|---|---|---|
+all | 允许全部来源 | 绝对禁用 |
~all | 软失败（标记为可疑，但不拒收） | 测试阶段可接受 |
-all | 硬失败（直接拒绝） | 生产环境标准配置 |
?all | 中立（不作判断） | 实际无意义 |
关键限制：10 次 DNS 查询上限。 SPF 验证过程中最多允许进行 10 次 DNS 查询（含嵌套的 include）。超出将导致永久性错误（PermError）。您可通过以下命令监控当前查询次数：
dig +short TXT _spf.google.com
DKIM（域名密钥识别邮件）
DKIM（RFC 6376）为外发邮件添加加密签名，使收件人能够验证邮件在传输过程中未被篡改。
DKIM 公钥以 TXT 记录形式发布在特定选择器（selector）的子域名下：
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."
字段说明：
selector1—— 选择器名称（由您的电子邮件服务商设定；支持密钥轮换且不中断服务）_domainkey—— 固定命名空间v=DKIM1—— 版本号k=rsa—— 密钥类型（可选 rsa 或 ed25519）p=...—— Base64 编码的公钥
Google Workspace 的 DKIM 示例：
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
DMARC（基于域名的消息认证、报告与一致性协议）
DMARC（RFC 7489）将 SPF 和 DKIM 结合起来，通过一项策略告知邮件接收方：当身份验证失败时应如何处理，以及将报告发送至何处。
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; pct=100; adkim=s; aspf=s"
策略选项：
| 策略 | 行动 | 适用场景 |
|---|---|---|
p=none | 仅监控（收集报告） | 初次部署阶段；探索期 |
p=quarantine | 标记为垃圾邮件 | 过渡阶段；逐步建立信任 |
p=reject | 直接拒收 | 大规模发件人的生产环境标准 |
推荐的部署路径：
- 从
p=none开始——持续收集报告 2–4 周，识别所有合法的发信源 - 切换至
p=quarantine; pct=25——逐步提高生效比例 - 最终状态：
p=reject; pct=100——全面强制执行
完整的电子邮件身份验证配置
以下是在 Google Workspace 和 SendGrid 环境下，为域名配置的、可直接投入生产的电子邮件身份验证方案：
; SPF — 授权 Google 和 SendGrid
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
; DKIM — Google Workspace 密钥
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
; DKIM — SendGrid 密钥
s1._domainkey.example.com. 3600 IN TXT "k=rsa; t=s; p=MIGfMA0GCSqGSIb3..."
; DMARC — 全面执行策略并启用报告
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s"
决策树：你需要哪种 DNS 记录类型？
使用此决策框架，为任何场景快速确定最合适的记录类型：
你想实现什么功能？
|
|-- 将域名指向服务器 IP 地址？
| |-- IPv4 地址？ → A 记录
| |-- IPv6 地址？ → AAAA 记录
|
|-- 将域名指向另一个域名？
| |-- 在域名根节点（@）？ → A 记录 + 注册商提供的 ALIAS/CNAME 扁平化功能
| |-- 在子域名下？ → CNAME 记录
|
|-- 配置电子邮件服务？
| |-- 路由入站邮件？ → MX 记录
| |-- 授权发信服务器？ → TXT 记录（SPF）
| |-- 对发出的邮件进行数字签名？ → TXT 记录（DKIM，格式为 selector._domainkey）
| |-- 设置邮件身份验证策略？ → TXT 记录（DMARC，记录名 _dmarc）
| |-- 为邮件服务器启用反向 DNS？ → PTR 记录
|
|-- 管理 SSL/TLS 证书签发权限？
| → CAA 记录
|
|-- 通过主机名和端口发现某项服务？
| → SRV 记录
|
|-- 将子域名委派给其他 DNS 服务器？
| → NS 记录
|
|-- 向某个平台验证域名所有权？
| → TXT 记录（填写该平台提供的验证值）
完整实战配置：网站 + 邮箱 + 安全防护
以下是一套完整、可用于生产环境的 DNS 配置，适用于域名 example.com：网站托管在云服务器上，邮箱使用 Google Workspace，并遵循安全最佳实践：
; === 域名权威服务器 ===
example.com. 86400 IN SOA ns1.dnsprovider.com. admin.example.com. (
2024052201 7200 3600 1209600 300)
example.com. 86400 IN NS ns1.dnsprovider.com.
example.com. 86400 IN NS ns2.dnsprovider.com.
; === 网站 ===
example.com. 300 IN A 203.0.113.50
example.com. 300 IN AAAA 2001:db8:1::50
www.example.com. 300 IN CNAME example.com.
; === CDN / 静态资源 ===
static.example.com. 300 IN CNAME d1234abcd.cloudfront.net.
; === 邮箱路由（Google Workspace） ===
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt3.aspmx.l.google.com.
example.com. 3600 IN MX 10 alt4.aspmx.l.google.com.
; === 邮箱身份验证 ===
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all"
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"
; === 安全防护 ===
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
; === 服务发现 ===
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 autodiscover.outlook.com.
从零开始为新域名搭建 DNS 时，务必提前规划好全部记录，再上线部署——否则边用边配极易引发连锁问题。如果你还在挑选域名阶段，不妨借助支持 在 1,500+ 个 TLD 中批量查域名可用性 的工具，先锁定理想域名，再投入精力设计 DNS 架构。
故障排查工具与命令
dig（DNS 信息抓取器）
dig 命令是 Linux 和 macOS 系统上标准的 DNS 故障排查工具。
查询特定记录类型：
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com CAA
dig _dmarc.example.com TXT
向指定域名服务器发起查询（绕过缓存）：
dig @8.8.8.8 example.com A
dig @ns1.cloudflare.com example.com A +norecurse
追踪完整解析路径：
dig example.com A +trace
精简输出（仅显示答案部分）：
dig +short example.com A
# 输出：203.0.113.50
检查 SOA 序列号：
dig example.com SOA +short
# 输出：ns1.example.com. admin.example.com. 2024052201 7200 3600 1209600 300
nslookup（跨平台工具）
Windows、macOS 和 Linux 均支持：
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=CAA example.com 8.8.8.8
验证 SPF 查询次数
# 统计 SPF 链中涉及的总 DNS 查询次数
dig +short TXT example.com | grep spf
# 然后递归解析每个 include 条目：
dig +short TXT _spf.google.com
测试 DMARC 记录
dig +short TXT _dmarc.example.com
# 预期结果："v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"
检查 DNS 传播状态
完成 DNS 修改后，需在多个公共解析器上验证传播情况：
dig @8.8.8.8 example.com A +short # Google
dig @1.1.1.1 example.com A +short # Cloudflare
dig @208.67.222.222 example.com A +short # OpenDNS
dig @9.9.9.9 example.com A +short # Quad9
TTL 最佳实践
TTL（生存时间）控制 DNS 解析器缓存您记录的时间长度。选择合适的 TTL 值，本质上是在性能（TTL 越长，查询越少，用户解析越快）与灵活性（TTL 越短，配置变更传播越快）之间取得平衡。
推荐的 TTL 值
| 场景 | 推荐 TTL | 原因 |
|---|---|---|
| 稳定的生产环境记录 | 3600 秒（1 小时） | 缓存性能良好；变更可在 1 小时内完成全网传播 |
| 极少变动的记录（如 NS、MX 记录） | 86400 秒（24 小时） | 为稳定基础设施提供最长缓存周期 |
| 迁移前（变更前 48 小时起） | 300 秒（5 分钟） | 确保变更发生时能快速传播 |
| 迁移进行中 | 60–300 秒 | 最大限度降低陈旧缓存的影响 |
| 负载均衡的 A 记录 | 60–300 秒 | 支持快速故障转移 |
| 开发/测试环境 | 60 秒（1 分钟） | 支持高频快速迭代 |
迁移场景下的 TTL 策略
- 提前 48 小时： 将所有计划变更的记录 TTL 从 3600 秒降至 300 秒
- 等待旧 TTL 过期： 等待旧缓存自然清空（需等待等于原 TTL 的时长）
- 执行变更： 更新记录值
- 验证传播效果： 使用
dig命令向多个 DNS 解析器发起查询 - 稳定后： 将 TTL 恢复至生产环境推荐值（3600–86400 秒）
常见问题解答
我能否在同一子域名上同时设置 CNAME 和 MX 记录？
不可以。 DNS 规范（RFC 1034）明确规定：CNAME 记录不能与任何其他类型的记录共存于同一名称下。例如，若 mail.example.com 已配置 CNAME 记录，则无法再为其添加 MX、TXT 或 A 记录。如需在同一名称下使用其他记录类型，请改用 A 记录，而非 CNAME。
DNS 更改在全球范围内生效需要多长时间？
通常为 5 分钟至 48 小时，具体取决于您所修改记录此前设置的 TTL 值。例如，若旧记录 TTL 为 86400 秒（24 小时），部分解析器可能继续缓存旧值长达 24 小时。因此，在计划进行 DNS 变更前主动调低 TTL 至关重要。实践中，若 TTL 设为 300 秒，绝大多数用户将在 10 分钟内看到新配置生效。
我是否必须同时为 www 设置 A 记录和 CNAME 记录？
只需二者择一，不可同时设置。 标准做法是：在根域名（example.com）使用 A 记录，而在 www.example.com 使用指向 example.com 的 CNAME 记录。这样只需更新一次 IP 地址，即可同步生效于两个域名。当然，若您倾向更明确的控制权，也可分别为两者设置 A 记录。
如果我的域名未配置 CAA 记录，会发生什么？
任何证书颁发机构（CA）均可为您的域名签发证书。 缺少 CAA 记录即等同于默认授权所有 CA 签发证书。过去这种做法尚可接受，但随着证书有效期不断缩短及自动化签发日益普及，CAA 记录正变得愈发关键——它能有效防止他人（无论是恶意还是误操作）未经授权为您的域名申请证书。
如何判断 SPF 记录是否导致邮件投递失败？
查阅 DMARC 聚合报告，并借助诊断工具验证。 DMARC 报告（发送至 rua 指定邮箱）会详细列出您域名发出的每封邮件的 SPF 通过/失败情况。您也可手动检测：
# 检查 SPF 记录语法
dig +short TXT example.com | grep "v=spf1"
# 验证 DNS 查询次数（必须 ≤ 10 次）
# 可使用在线 SPF 验证工具，例如 mxtoolbox.com/spf.aspx
SPF 失败的常见原因包括：DNS 查询次数超出 10 次限制；遗漏第三方邮件发送方（如营销平台、CRM 系统或客服系统）；或错误使用 +all 而非更安全的 -all。
通过 DNS 配置理解域名价值
一个域名的 DNS 设置，能体现其运营成熟度。无论您是在评估某个域名的收购潜力、投资价值，还是进行竞品分析，检查其 DNS 记录都能揭示该域名背后的基础设施选择、邮件服务商、CDN 使用情况以及安全防护水平。
如果您需要全面评估一个域名的整体价值与运营历史，可借助功能完备的域名估值工具——该工具基于 22 项指标进行综合分析，在您手动开展技术性 DNS 分析的同时，提供结构化的估值参考。
参考资料与标准
概述
DNS 记录远不止是底层技术组件——它们是你域名所提供各项服务的实际运行支柱。本指南涵盖的十种记录类型，覆盖了从基础解析（A/AAAA）到邮件投递保障（MX/TXT，含 SPF/DKIM/DMARC），再到安全策略（CAA）的完整范围。
三大趋势正让掌握 DNS 变得比以往任何时候都更加紧迫：
- 2024 年电子邮件身份验证强制要求意味着：若 TXT 记录配置不当，你的企业邮件将直接被 Google 和 Yahoo 拒收。
- CA/B 论坛对证书有效期的持续压缩（截至 2029 年 3 月将缩短至 47 天），要求你的 DNS 基础设施必须支持稳定、自动化的证书续签。
- IPv6 采用率已越过临界点，这意味着面向移动用户占比高的网站，AAAA 记录已不再是可选项。
务必从一开始就配对 DNS。本指南中列出的配置模式代表当前行业最佳实践——每次将新域名投入生产环境时，请务必将其作为检查清单严格执行。