DNS 记录类型详解：A、CNAME、MX、TXT

域名系统（DNS）是互联网的骨干，将人类可读的域名转换为机器可读的 IP 地址和路由信息。理解 DNS 记录类型对于 Web 开发人员、系统管理员和任何管理域名的人来说都是必不可少的。本综合指南涵盖了每种主要的 DNS 记录类型，包括真实示例、dig/nslookup 命令和实用配置技巧。

1. DNS 工作原理

当你在浏览器中输入 example.com 这样的域名时，背后会发生一个复杂的解析过程。理解这个流程是诊断 DNS 问题的关键。

1步骤 1：浏览器检查其本地缓存中是否有之前解析过的 IP 地址。

2步骤 2：如果没有缓存，操作系统查询配置的递归解析器（通常是你的 ISP 或公共解析器如 8.8.8.8）。

3步骤 3：递归解析器检查其缓存。如果没有缓存记录，则开始解析链。

4步骤 4：解析器查询根域名服务器（如 a.root-servers.net），根服务器返回 .com 的 TLD 域名服务器地址。

5步骤 5：解析器查询 .com TLD 域名服务器，TLD 服务器返回 example.com 的权威域名服务器地址。

6步骤 6：解析器查询权威域名服务器，权威服务器返回实际的 DNS 记录（例如 A 记录，IP 为 93.184.216.34）。

7步骤 7：解析器缓存结果（遵循 TTL）并返回给浏览器。

DNS Resolution Flow:

Browser Cache → OS Cache → Recursive Resolver → Root Server → TLD Server → Authoritative Server
                                                    │              │              │
                                               "Ask .com"    "Ask ns1.         "Here is
                                                TLD server"   example.com"      93.184.216.34"

Example: Resolving www.example.com
┌──────────┐     ┌──────────────┐     ┌─────────────┐     ┌──────────┐     ┌──────────────┐
│  Browser  │────>│   Recursive  │────>│    Root      │     │  .com    │     │ Authoritative│
│  (client) │     │   Resolver   │     │   Server     │     │  TLD NS  │     │   NS         │
│           │<────│  (8.8.8.8)   │<────│(.root-servers│────>│(gtld-    │────>│(ns1.example  │
│           │     │              │     │  .net)       │     │servers)  │     │  .com)       │
└──────────┘     └──────────────┘     └─────────────┘     └──────────┘     └──────────────┘
  A: 93.184.216.34   Caches result         "Go ask         "Go ask         "A 93.184.216.34
   (TTL: 300s)       (TTL-based)          .com TLD"      ns1.example.com"   TTL 300"

递归解析器：代表客户端执行完整查询。示例：Google Public DNS（8.8.8.8）、Cloudflare（1.1.1.1）、你的 ISP DNS。

权威域名服务器：持有域名的实际 DNS 记录，是真实数据源。示例：ns1.example.com、Cloudflare 域名服务器、AWS Route 53。

整个过程通常在 100 毫秒内完成。各级缓存（浏览器、操作系统、解析器）大大减少了后续请求的查询时间。

2. A 记录（地址记录）

A 记录是最基本的 DNS 记录类型。它将域名直接映射到 IPv4 地址。每个网站至少需要一个 A 记录（或用于 IPv6 的 AAAA 记录）。

格式：<域名> <TTL> IN A <IPv4 地址>

example.com.     300    IN    A    93.184.216.34
www.example.com. 300    IN    A    93.184.216.34
api.example.com. 60     IN    A    203.0.113.50

# Multiple A records for load balancing:
example.com.     300    IN    A    93.184.216.34
example.com.     300    IN    A    93.184.216.35
example.com.     300    IN    A    93.184.216.36

TTL（生存时间）：以秒为单位。TTL 为 300 意味着解析器缓存此记录 5 分钟。较低的 TTL（60-300）允许更快的更改但增加 DNS 查询负载。较高的 TTL（3600-86400）减少负载但使更改传播更慢。

你可以为同一个域名设置多个 A 记录，用于轮询（round-robin）负载均衡。DNS 解析器会轮流返回各个地址。

提示：在迁移服务器之前，提前 24-48 小时将 A 记录的 TTL 降低到 60 秒。迁移完成后，可以将其恢复到 3600 或更高。

3. AAAA 记录（IPv6 地址记录）

AAAA 记录（读作"四 A"）是 A 记录的 IPv6 等价物。随着 IPv6 的普及，AAAA 记录变得越来越重要。

格式：<域名> <TTL> IN AAAA <IPv6 地址>

example.com.     300    IN    AAAA    2606:2800:0220:0001:0248:1893:25c8:1946
www.example.com. 300    IN    AAAA    2606:2800:0220:0001:0248:1893:25c8:1946

# Shortened IPv6 notation:
example.com.     300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946
# Full form:     2606:2800:0220:0001:0248:1893:25c8:1946

# Dual-stack configuration (A + AAAA):
example.com.     300    IN    A       93.184.216.34
example.com.     300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

IPv6 地址为 128 位长，以八组四位十六进制数字书写，各组用冒号分隔。前导零可以省略，连续的零组可以用 :: 替代。

最佳实践：同时配置 A 和 AAAA 记录（双栈），使你的域名可以通过 IPv4 和 IPv6 访问。大多数现代 CDN 和托管服务商自动支持双栈配置。

4. CNAME 记录（规范名称）

CNAME 记录创建从一个域名到另一个域名（"规范"名称）的别名。当解析器遇到 CNAME 时，它会使用目标域名重新开始查询。

格式：<别名> <TTL> IN CNAME <规范名称>

www.example.com.     300    IN    CNAME    example.com.
blog.example.com.    300    IN    CNAME    mysite.wordpress.com.
shop.example.com.    300    IN    CNAME    shops.myshopify.com.

# Resolution chain:
# Query: blog.example.com
#   → CNAME: mysite.wordpress.com
#     → A: 192.0.78.12  (WordPress resolves the final IP)

使用场景：将子域名指向第三方服务（CDN、SaaS 平台、托管服务商）。将 www 指向裸域。为长主机名创建便捷别名。

限制 1（根域名）：CNAME 记录不能设置在区域顶点（根域名）上。例如，你不能为 example.com 创建 CNAME —— 只能为子域名如 www.example.com。这是因为 CNAME 记录不能与其他记录类型共存，而根域名必须有 SOA 和 NS 记录。

限制 2（不可共存）：CNAME 记录不能与同一名称下的任何其他记录类型共存。如果 blog.example.com 有 CNAME，你不能同时为 blog.example.com 添加 MX 或 TXT 记录。

变通方案：某些 DNS 提供商提供 ALIAS 或 ANAME 记录（非标准），在区域顶点实现类似 CNAME 的功能。Cloudflare 称之为"CNAME 扁平化"。AWS Route 53 使用"Alias"记录。

5. MX 记录（邮件交换）

MX 记录指定哪些邮件服务器接受域名的电子邮件。它们对邮件投递至关重要。每个 MX 记录包含一个优先级值 —— 数字越低表示优先级越高。

格式：<域名> <TTL> IN MX <优先级> <邮件服务器>

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.
example.com.  3600  IN  MX  30  mail3.example.com.

优先级：邮件服务器首先尝试投递到优先级最低（最优先）的服务器。如果不可用，则回退到下一个。在此示例中，先尝试 mail1，然后 mail2，最后 mail3。

Google Workspace MX 记录：

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 MX 记录：

example.com.  3600  IN  MX  0   example-com.mail.protection.outlook.com.

重要提示：MX 记录必须指向主机名（A/AAAA 记录），绝不能指向 IP 地址或 CNAME。目标主机名必须有自己的 A 记录。

6. TXT 记录（文本记录）

TXT 记录存储与域名关联的任意文本数据。它们广泛用于邮件认证（SPF、DKIM、DMARC）、域名所有权验证和安全策略。

格式：<域名> <TTL> IN TXT "<文本字符串>"

SPF（发送方策略框架）：

SPF 指定哪些邮件服务器被授权代表你的域名发送邮件。它有助于防止邮件伪造。

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

v=spf1 — SPF 版本 1。include: — 授权这些第三方发送者。-all — 拒绝（硬失败）所有其他发送者。~all — 软失败（标记为可疑）。?all — 中性。

DKIM（域名密钥识别邮件）：

DKIM 为外发邮件添加数字签名。接收服务器使用 DNS 中发布的公钥验证签名。

google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

DMARC（基于域的消息认证）：

DMARC 告诉接收邮件服务器在 SPF 和 DKIM 检查失败时该怎么做。它还支持报告功能。

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

域名验证：

许多服务要求你添加 TXT 记录来证明域名所有权：

# Google：google-site-verification=xxxxxxxxxxxx
example.com.  3600  IN  TXT  "google-site-verification=Abc123XyZ..."

# Let's Encrypt：_acme-challenge.example.com TXT "random-token-string"
_acme-challenge.example.com.  300  IN  TXT  "gfj9Xq...Rg85nM"

# Microsoft 365：MS=ms12345678
example.com.  3600  IN  TXT  "MS=ms12345678"

# Facebook：facebook-domain-verification=xxxxxxxxxxxx
example.com.  3600  IN  TXT  "facebook-domain-verification=abc123def456"

7. NS 记录（域名服务器）

NS 记录指定哪些域名服务器对某个域名具有权威性。它们将 DNS 解析委托给指定的服务器。每个域名必须至少有两个 NS 记录以实现冗余。

格式：<域名> <TTL> IN NS <域名服务器>

example.com.  86400  IN  NS  ns1.example.com.
example.com.  86400  IN  NS  ns2.example.com.

# Common DNS provider nameservers:
# Cloudflare:  anna.ns.cloudflare.com, bob.ns.cloudflare.com
# AWS Route53: ns-123.awsdns-45.com, ns-678.awsdns-90.net
# Google:      ns-cloud-a1.googledomains.com, ns-cloud-a2.googledomains.com

NS 记录也用于子域名委托。你可以将子域名委托给不同的域名服务器：

# Subdomain delegation:
dev.example.com.  86400  IN  NS  ns1.dev-team.com.
dev.example.com.  86400  IN  NS  ns2.dev-team.com.

# This means all DNS queries for *.dev.example.com
# will be handled by ns1/ns2.dev-team.com

NS 记录通常有较高的 TTL（86400 = 24 小时），因为域名服务器变更不频繁。迁移 DNS 提供商时，还必须更新注册商级别的 NS 记录。

8. SOA 记录（权威起始）

每个 DNS 区域都有且仅有一个 SOA 记录。它包含区域的管理信息，包括主域名服务器、负责人邮箱以及区域传输的时间参数。

格式：<域名> <TTL> IN SOA <主 NS> <管理邮箱> (<序列号> <刷新> <重试> <过期> <最小 TTL>)

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
    2024121501  ; Serial number  (YYYYMMDDNN)
    7200        ; Refresh         (2 hours)
    3600        ; Retry           (1 hour)
    1209600     ; Expire          (14 days)
    300         ; Minimum TTL     (5 minutes, negative caching)
)

# Note: admin.example.com. means admin@example.com
# (the first dot replaces the @ symbol)

序列号：区域的版本号。每次更改时递增。常用格式：YYYYMMDDNN（例如 2024121501）。辅助域名服务器比较序列号来决定是否执行区域传输。

刷新（7200 = 2 小时）：辅助域名服务器多久检查一次主服务器的更新。

重试（3600 = 1 小时）：刷新失败后辅助服务器等待多久再重试。

过期（1209600 = 14 天）：如果辅助服务器无法联系主服务器，它继续提供区域服务的时长。超过此时间后，它将停止响应。

最小 TTL（300 = 5 分钟）：否定缓存（NXDOMAIN 响应）的默认 TTL。它告诉解析器缓存"记录不存在"这一事实的时长。

9. SRV 记录（服务记录）

SRV 记录指定服务的位置。它们包含协议、优先级、权重、端口和目标主机信息。SRV 记录支持服务发现，无需硬编码端口或主机名。

格式：_service._protocol.<域名> <TTL> IN SRV <优先级> <权重> <端口> <目标>

# SIP service over TCP:
_sip._tcp.example.com.     3600  IN  SRV  10  60  5060  sipserver.example.com.

# XMPP client service:
_xmpp-client._tcp.example.com.  3600  IN  SRV  5  0  5222  xmpp.example.com.

# Minecraft server:
_minecraft._tcp.mc.example.com. 3600  IN  SRV  0  5  25565  mc.example.com.

# Format breakdown:
# _sip._tcp.example.com.  3600  IN  SRV  10    60     5060   sipserver.example.com.
#  |     |                              priority weight  port   target
#  |     └── Protocol (TCP/UDP)
#  └── Service name

字段说明：Priority（优先级，越低越优先）、Weight（权重，用于相同优先级服务器间的负载均衡）、Port（服务端口号）、Target（提供服务的主机名）。

常见用途：Microsoft Active Directory、SIP/VoIP、XMPP/Jabber、Minecraft 服务器、CalDAV/CardDAV、LDAP。

SRV 记录由支持该协议的应用程序查询。Web 浏览器不使用 SRV 记录来处理 HTTP —— 那是通过 A/AAAA/CNAME 记录处理的。

10. PTR 记录（指针 / 反向 DNS）

PTR 记录将 IP 地址映射回域名 —— 是 A 记录的反向操作。它们存储在 in-addr.arpa（IPv4）或 ip6.arpa（IPv6）下的特殊区域中。反向 DNS 对邮件投递能力和网络诊断至关重要。

格式：<反转 IP>.in-addr.arpa. <TTL> IN PTR <域名>

# IPv4 reverse DNS:
34.216.184.93.in-addr.arpa.  3600  IN  PTR  example.com.

# How the IP is reversed:
# IP: 93.184.216.34
# Reversed: 34.216.184.93
# Full PTR name: 34.216.184.93.in-addr.arpa.

# IPv6 reverse DNS (each hex digit is separated):
# IP: 2001:0db8::1
# PTR: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

# Real-world example:
# $ dig -x 8.8.8.8
# 8.8.8.8.in-addr.arpa.  IN  PTR  dns.google.

邮件与 PTR：大多数邮件服务器会对连接服务器的 IP 执行反向 DNS 查询。如果没有 PTR 记录，或者它与正向（A 记录）查询不匹配，邮件可能会被拒绝或标记为垃圾邮件。

PTR 记录由 IP 地址块的所有者（通常是你的托管提供商或 ISP）管理。要设置 PTR 记录，你通常需要联系他们或使用他们的控制面板。

11. CAA 记录（证书颁发机构授权）

CAA 记录指定哪些证书颁发机构（CA）被允许为域名颁发 SSL/TLS 证书。它们提供了额外的安全层来防止证书误发。

格式：<域名> <TTL> IN CAA <标志> <标签> <值>

# Allow only Let's Encrypt to issue certificates:
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"

# Allow Let's Encrypt to issue wildcard certificates:
example.com.  3600  IN  CAA  0  issuewild  "letsencrypt.org"

# Report violations via email:
example.com.  3600  IN  CAA  0  iodef  "mailto:security@example.com"

# Allow multiple CAs:
example.com.  3600  IN  CAA  0  issue  "letsencrypt.org"
example.com.  3600  IN  CAA  0  issue  "amazon.com"
example.com.  3600  IN  CAA  0  issue  "digicert.com"

标签说明：issue — 授权 CA 为此域名颁发证书。issuewild — 授权 CA 颁发通配符证书。iodef — 指定接收违规报告的 URL 或邮箱。

如果没有 CAA 记录，任何 CA 都可以为该域名颁发证书。CA 在颁发前必须检查 CAA 记录（根据 RFC 8659）。设置 CAA 记录是推荐的安全最佳实践。

12. DNS 记录类型对比表

此表总结了所有主要 DNS 记录类型、用途、示例值和典型 TTL 设置。

记录类型	用途	示例值	典型 TTL
`A`	将域名映射到 IPv4 地址	`93.184.216.34`	300-3600
`AAAA`	将域名映射到 IPv6 地址	`2606:2800:220:1:248:1893:25c8:1946`	300-3600
`CNAME`	创建域名别名	`www.example.com -> example.com`	300-3600
`MX`	指定邮件服务器	`10 mail.example.com.`	3600
`TXT`	存储文本数据（SPF、DKIM 等）	`"v=spf1 include:_spf.google.com -all"`	3600
`NS`	委托域名服务器	`ns1.example.com.`	86400
`SOA`	区域权威信息	`ns1.example.com. admin.example.com. 2024121501 ...`	86400
`SRV`	服务发现（端口和协议）	`10 60 5060 sipserver.example.com.`	3600
`PTR`	反向 DNS 查询（IP 到域名）	`example.com.`	3600
`CAA`	证书颁发机构授权	`0 issue "letsencrypt.org"`	3600

13. DNS 查询工具与命令

这些命令行工具帮助你查询和调试 DNS 记录。每个系统管理员都应该熟悉它们。

dig（域信息搜索器）：

最强大的 DNS 查询工具。在 Linux/macOS 上可用。在 Windows 上通过 BIND 工具安装。

# Query A record
$ dig example.com A
;; ANSWER SECTION:
example.com.        300     IN      A       93.184.216.34

# Query MX records
$ dig example.com MX
;; ANSWER SECTION:
example.com.        3600    IN      MX      10 mail.example.com.

# Query TXT records (SPF, DKIM, DMARC)
$ dig example.com TXT
;; ANSWER SECTION:
example.com.        3600    IN      TXT     "v=spf1 include:_spf.google.com -all"

# Query specific nameserver
$ dig @8.8.8.8 example.com A

# Query all record types
$ dig example.com ANY

# Short output (just the answer)
$ dig +short example.com A
93.184.216.34

# Trace the full resolution path
$ dig +trace example.com A

# Query CNAME
$ dig www.example.com CNAME
;; ANSWER SECTION:
www.example.com.    300     IN      CNAME   example.com.

# Reverse DNS lookup
$ dig -x 93.184.216.34

nslookup：

在所有平台上可用（Windows、Linux、macOS）。比 dig 简单但细节较少。

# Basic A record lookup
$ nslookup example.com
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

# Query specific record type
$ nslookup -type=MX example.com
example.com     mail exchanger = 10 mail.example.com.

$ nslookup -type=TXT example.com
example.com     text = "v=spf1 include:_spf.google.com -all"

# Use specific DNS server
$ nslookup example.com 1.1.1.1

# Query NS records
$ nslookup -type=NS example.com
example.com     nameserver = ns1.example.com.
example.com     nameserver = ns2.example.com.

host：

简化的 DNS 查询工具，在 Linux/macOS 上可用。适合快速查询。

# Basic lookup
$ host example.com
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 10 mail.example.com.

# Query specific type
$ host -t MX example.com
example.com mail is handled by 10 mail.example.com.

$ host -t TXT example.com
example.com descriptive text "v=spf1 include:_spf.google.com -all"

# Reverse lookup
$ host 93.184.216.34
34.216.184.93.in-addr.arpa domain name pointer example.com.

# Verbose output
$ host -v example.com

在线工具：我们的 IP 计算器工具可以帮助你在 DNS 设置的同时理解网络配置。

试试我们的 IP 计算器进行网络分析

IP Calculator →

FAQ

A 记录和 CNAME 记录有什么区别？

A 记录将域名直接映射到 IPv4 地址（如 93.184.216.34），而 CNAME 记录将域名映射到另一个域名（别名）。A 记录用于最终目的地，而 CNAME 用于将一个名称指向另一个。CNAME 不能用于根域名（区域顶点）。

我可以为根域名（example.com）使用 CNAME 记录吗？

不可以。根据 DNS 规范（RFC 1034），CNAME 不能与其他记录类型共存，而根域名必须有 SOA 和 NS 记录。一些 DNS 提供商提供专有的变通方案，如 ALIAS 记录（DNS Made Easy）、ANAME 记录（Route 53）或 CNAME 扁平化（Cloudflare），可以实现类似效果。

Google Workspace 需要哪些 MX 记录？

Google Workspace 需要五个 MX 记录：ASPMX.L.GOOGLE.COM（优先级 1）、ALT1.ASPMX.L.GOOGLE.COM（优先级 5）、ALT2.ASPMX.L.GOOGLE.COM（优先级 5）、ALT3.ASPMX.L.GOOGLE.COM（优先级 10）和 ALT4.ASPMX.L.GOOGLE.COM（优先级 10）。这些在多个 Google 邮件服务器之间提供冗余。

SPF、DKIM 和 DMARC 如何协同工作？

SPF 指定哪些服务器可以为你的域名发送邮件。DKIM 为邮件添加加密签名，收件方可以通过 DNS 发布的公钥验证。DMARC 将 SPF 和 DKIM 结合在一起，告诉接收者在检查失败时该怎么做（无操作、隔离或拒绝）以及将报告发送到哪里。三者都应配置以实现完整的邮件认证。

DNS 更改需要多长时间才能传播？

DNS 传播取决于被更改记录的 TTL（生存时间）。如果旧记录的 TTL 为 3600（1 小时），所有解析器可能需要最多 1 小时才能获取更改。实际上，由于各级缓存，大多数更改在全球范围内 1-48 小时内传播。要加速传播，请在更改之前提前降低 TTL。