DNS 记录解释器 —— 18 种常见记录，语法、例子、真实坑一站全

<name> <ttl> IN A <ipv4-address>

把域名解析成一个 IPv4 地址。互联网最基础的一条记录，任何通过 IPv4 提供服务的域名根域或子域至少有一条 A 记录。

• 把 example.com 指到你的 Web 服务器 IP 203.0.113.10。
• 同一个名字配多条 A 记录做 DNS 轮询。
• 地域 / 延迟解析，让 DNS 服务端按用户位置返回最近的 A。

• TTL 太长（比如 86400）意味着搬服务要等整整一天才能彻底切过去 —— 迁移前一天先降到 300。
• 加第二条 A 不等于自动 failover，只是轮询。真要故障切要带健康检查的 DNS（Route53、NS1）。
• 根域上挂 A 没问题，但不能同时挂 CNAME —— 两个记录会冲突。

example.com.     300  IN A     203.0.113.10
www.example.com. 300  IN A     203.0.113.10
api.example.com. 60   IN A     198.51.100.5

<name> <ttl> IN AAAA <ipv6-address>

把域名解析成一个 IPv6 地址。A 记录的 IPv6 兄弟，双栈服务必须有，想被 IPv6-only 网络（移动运营商、校园网）访问到的服务也必须有。

• 双栈 Web 服务器：同一个名字下 A 和 AAAA 各一条。
• CDN 边缘：Cloudflare / Fastly 免费送 AAAA。
• 给走 NAT64 移动网络的客户端开 IPv6-only API 端点。

• 服务端在 IPv6 上监听了但防火墙把它丢了 —— 客户端会先卡一阵再回退 IPv4（Happy Eyeballs 暂时掩盖问题）。
• AAAA 的反向解析挂在 ip6.arpa，不是 in-addr.arpa —— 配 PTR 时很容易忘。
• 一些老牌企业代理还在把 AAAA 从响应里剥掉 —— 一定要在公司网外测一遍。

example.com.     300  IN AAAA  2001:db8::1
www.example.com. 300  IN AAAA  2606:4700::6810:84e5
api.example.com. 60   IN AAAA  2001:db8:1::a

<alias> <ttl> IN CNAME <canonical-name>

把一个名字别名到另一个规范名上，解析器会沿着链一路追到最终的 A/AAAA。常用来把子域指到 SaaS 端点，不用写死它的 IP。

• shop.example.com → mystore.shopify.com（Shopify 换 IP 跟你无关）。
• docs.example.com → example.gitbook.io。
• cdn.example.com → d1234abcd.cloudfront.net。

• 根域（example.com 本身）不能挂 CNAME —— 跟必备的 SOA / NS 记录冲突。要么用 ALIAS / ANAME，要么换支持 CNAME flatten 的服务商。
• 一个名字一旦挂了 CNAME 就不能再挂其他记录（MX、TXT 全都不行）。两个都要？把服务挪到子域。
• CNAME 链拖慢解析，还会让一些校验工具撞墙 —— 控制在一跳之内。
• 某些应用会因 CNAME 丢掉原 Host 头的语义 —— 确认目标服务认你这个域名。

www.example.com.  300 IN CNAME example.com.
shop.example.com. 300 IN CNAME mystore.shopify.com.
docs.example.com. 300 IN CNAME example.gitbook.io.

<zone> <ttl> IN NS <nameserver>

声明哪些 NS 服务器对一个区域或子区域是权威的。每个区域根上必备，也用来把子区域委托给另一家解析商。

• example.com 根上的 NS 指向 ns1/ns2/ns3/ns4.cloudflare.com。
• 把 dev.example.com 委托给单独的 Route53 区域给开发团队管。
• 通过把 asia.example.com 委托到区域服务商做 GeoDNS。

• Glue 记录（NS 本身在同一区域内时，注册商那边要补 A/AAAA）漏配会变成 "lame delegation"。
• 注册商（父域）那边的 NS 必须和区域内部的 NS 一致 —— 不一致就会偶发解析失败。
• 迁移时把所有 NS 全删了，整个 TTL 周期解析全挂。
• 子域 NS 委托只在父域上这个子域名没有其他记录时生效。

example.com. 86400 IN NS ns1.cloudflare.com.
example.com. 86400 IN NS ns2.cloudflare.com.
dev.example.com. 86400 IN NS ns-1234.awsdns-25.org.

<zone> <ttl> IN SOA <primary-ns> <admin-email> ( <serial> <refresh> <retry> <expire> <minimum> )

Start Of Authority —— 每个区域有且只有一条，声明主 NS、管理员邮箱、以及次级 NS 用来同步的一组定时器。serial 是触发区域传输的变更标记。

• 改完区域文件 serial 加一，让次级 NS 拉新数据。
• 调 minimum TTL 控制 NXDOMAIN 的负缓存时间。
• Hidden master 架构：SOA 指向不对外的主 NS，对外只暴露次级 NS。

• 改完不把 serial 加一，次级 NS 永远拉不到新数据。
• 管理员邮箱用点代替 @（hostmaster.example.com.）—— 很容易写错。
• minimum TTL 设太高，删除记录会在负缓存里残留那么久。
• 一个区域里出现两条 SOA 是硬错 —— 控制台 UI 一般不让你犯，手写 zone 文件就有人栽。

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
              2026052601 ; serial (YYYYMMDDnn)
              7200 3600 1209600 3600 )

<reverse-name>.in-addr.arpa. <ttl> IN PTR <hostname>

反向解析 —— 把 IP 反查回域名。邮件服务器靠它做发件 IP 健全性检查，日志靠它显示可读主机名，SSH 的反查选项也用。

• 发件 SMTP 必须正反向解析一致，大多数邮件供应商才肯收件。
• 日志分析：nginx access log 显示域名而不是裸 IP。
• traceroute 路径有反向解析，看跳点诊断顺畅得多。

• PTR 一般不由你控制 —— ISP / 云厂商管。AWS 在 EC2 控制台改，Azure 在 portal 改。
• PTR 配在 in-addr.arpa（IPv4）或 ip6.arpa（IPv6）的反向区域，不在你的正向区域里。
• 正反向不一致（FCrDNS 失败），SPF / DKIM / DMARC 再全也照样进垃圾箱。
• 云主机默认 PTR 长这样 ec2-203-0-113-10.compute-1.amazonaws.com —— 上生产发邮件前必须改掉。

10.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.
1.0.0.0.0.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. 3600 IN PTR mail.example.com.

_service._proto.<name> <ttl> IN SRV <priority> <weight> <port> <target>

服务定位记录 —— 让客户端通过 DNS 同时拿到服务的主机和端口（LDAP、XMPP、SIP、Minecraft、Matrix 都用）。带优先级和权重，能在 DNS 层做负载均衡。

• XMPP：_xmpp-client._tcp.example.com → SRV → talk.example.com:5222。
• AD 域控发现用 SRV（_ldap._tcp）。
• Minecraft 服开 SRV，玩家只输入域名就能进，不用带 :25565。

• 服务名必须下划线打头（_sip 而不是 sip）—— 不然客户端根本不认。
• 目标必须是有 A/AAAA 的域名 —— 不能是 IP，也不能是 CNAME。
• HTTP/HTTPS（浏览器）不查 SRV —— 只有特定协议查。Web 别放 SRV 上。
• weight 为 0 意思是 "只有别人都没了才用我"，特别容易误读成默认值。

_xmpp-client._tcp.example.com. 3600 IN SRV 10 5 5222 talk.example.com.
_sip._tls.example.com.         3600 IN SRV 10 60 5061 sipgw1.example.com.
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25565 mc1.example.com.

<apex> <ttl> IN ALIAS <target>

部分服务商（DNSimple、Namecheap 等）特有的记录类型 —— 在根域 flatten 一个目标域名，服务端解析后以 A/AAAA 形式返回。让你能在根域指向 SaaS 那种类似 CNAME 的目标，而 CNAME 在根域是非法的。

• 根域 example.com → mystore.myshopify.com，且不影响根上的 MX / TXT。
• 根域 example.com → d12345.cloudfront.net，给 CloudFront 上的静态站用。
• 根域 example.com → app.netlify.com，把 apex 托管在 Netlify。

• 不在任何 RFC 里 —— 只有支持它的服务商才有。换 DNS 服务商可能要重建。
• TTL 用的是 DNS 服务商的策略，不是目标的 —— 目标 IP 切的瞬间可能拿到过期结果。
• 一些服务商按查询次数收钱，因为解析是服务端做的。
• 目标自己换 IP 时，你完全依赖 DNS 服务商勤刷新。

example.com. 60 IN ALIAS mystore.myshopify.com.
example.com. 60 IN ALIAS d12345.cloudfront.net.
example.com. 60 IN ALIAS app.netlify.com.

<apex> <ttl> IN ANAME <target>

另一种服务商专属的 apex flatten 记录（DNS Made Easy、easyDNS 用），功能上等价于 ALIAS。服务端解析目标，根域上返回 A/AAAA。

• 根域 → ELB / ALB 目标，不影响根上的 MX。
• 根域 → Heroku herokudns.com 端点。
• 根域 → 只暴露域名的自建 CDN。

• 和 ALIAS 一样 —— 非标，会锁定服务商。
• 一些服务商界面叫 ANAME，底层其实是定期把 A 刷一遍 —— 看实际 TTL 行为。
• 目标离 DNS 服务商远的话，服务端解析会拖延迟。

example.com. 60 IN ANAME myapp.herokudns.com.
example.com. 60 IN ANAME lb-1234.us-east-1.elb.amazonaws.com.
example.com. 60 IN ANAME cdn.example-provider.net.

<name> <ttl> IN MX <priority> <mail-server>

列出域名的收件服务器，按优先级排序（数字越小越优先）。没 MX 这个域名根本收不了邮件。

• 把 @example.com 的邮件挂到 Google Workspace。
• 多供应商容灾：主用 Microsoft 365，备用 Mailgun 缓存。
• Null MX（优先级 0，目标 "."）明确声明这个域不收邮件。

• MX 目标必须是有 A/AAAA 的域名 —— 不能是 IP 字面量，也不能是 CNAME（RFC 说 SHOULD NOT，大量服务商直接 MUST NOT）。
• 配完 MX 不补 SPF / DKIM / DMARC，外发邮件直接进垃圾箱。
• 两条 MX 优先级一样，客户端就随机挑 —— 那是负载均衡的预期行为，不是 bug。
• 配新 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 0  .                      ; Null MX, no mail

<name> <ttl> IN TXT "<text>"

存任意文本 —— 早年随便写，现在基本都是机器解析的策略串：SPF、DKIM、DMARC、域名归属验证、BIMI 选择器。

• Google Workspace / Microsoft 365 / Cloudflare 的域名归属验证。
• SPF 策略：v=spf1 include:_spf.google.com ~all。
• BIMI 选择器，让邮件列表里显示品牌 LOGO。

• 单个 TXT 字符串上限 255 字符 —— 长 DKIM key 要拆成多个引号串拼在同一条记录里（解析器会自己拼）。
• 同名多条 SPF 记录直接非法 —— 合并成一条用 include。
• TXT 查询有 10 次 DNS lookup 上限 —— SPF include 太多就会校验失败。
• 验证 TXT 配完别删 —— 服务商几个月后可能重新校验，删了就破。

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=abcdef123456"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

<selector>._domainkey.<name> <ttl> IN TXT "v=DKIM1; k=rsa; p=<base64-public-key>"

DomainKeys Identified Mail —— 验证邮件签名用的公钥。挂在 <selector>._domainkey.<域名> 下的 TXT 记录里。收件服务器拉它来验签传入邮件里的 DKIM-Signature 头。

• Google Workspace 给你 2048 位 key 和 google._domainkey 之类的 selector。
• SendGrid / Mailgun 给每个客户单独的 selector（s1._domainkey、s2._domainkey）。
• 换 key 时先加新 selector，老的再下，避免断签。

• 2048 位 key 超出 TXT 的 255 字符上限 —— 在同一条记录里拆成多个引号段（解析器会自己拼）。
• TXT 值里有尾部空白或换行就验签不过 —— 复制粘贴小心点。
• 一个 selector 下挂多条 DKIM 就签不出去 —— 一个 selector 一把 key。
• 换 key 不重叠保留，老 key 签的邮件验签失败 —— 至少保留一个 TTL 周期。

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

_dmarc.<name> <ttl> IN TXT "v=DMARC1; p=<policy>; rua=mailto:<reports>"

基于域名的邮件认证、报告、一致性 —— 告诉收件方 SPF 或 DKIM 失败时该怎么处理（none / quarantine / reject），以及把聚合报告发到哪里。

• 先用观察模式：p=none + rua= 收数据，不影响投递。
• 报告干净后逐步收紧到 p=quarantine 再到 p=reject。
• 迁移期可以让根域 p=quarantine，子域 sp=reject。

• 不观察就直接上 p=reject，会把忘记纳管的内部发件源（CRM、ATS、计费系统）一起干掉。
• 记录名搞错 —— 必须是 _dmarc.example.com，不是 dmarc.example.com。
• pct=10 意思是 "对 10% 失败的邮件执行策略" —— 灰度上线时好用，忘了改回来就尴尬。
• rua 邮箱必须在同一个域，或者收件端有授权记录 —— 跨域汇报两端都要配。

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

<name> <ttl> IN TXT "v=spf1 <mechanisms> <qualifier>all"

Sender Policy Framework —— 一条 TXT 记录，列出哪些服务器有权以这个域名发邮件。早年有专门的 SPF 记录类型，2014 年废了；现在 SPF 都在 TXT 里。

• 纯 Google：v=spf1 include:_spf.google.com ~all
• Google + SendGrid + 自己 MX：v=spf1 include:_spf.google.com include:sendgrid.net mx ~all
• 完全不发邮件：v=spf1 -all（再配合 null MX 显式拒收）。

• 同名两条 SPF 直接违规 —— 合并成一条带多个 include。
• SPF 解析有 10 次 DNS 查询上限 —— include 链太多直接校验失败，用工具拍平。
• ~all（softfail）vs -all（fail）—— 先 ~all，DMARC 全绿后再切 -all。
• 转发邮件会破 SPF —— 转发服务用 SRS，或者那条路径靠 DKIM 撑。

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

<name> <ttl> IN CAA <flags> <tag> "<value>"

CA 授权记录 —— 告诉 CA 哪些机构可以为这个域名签证书。CA 签发前必须查 CAA；用来减少错签和恶意签证书。

• 只允许 Let's Encrypt 签：CAA 0 issue "letsencrypt.org"。
• 根域只让 DigiCert 签，*.dev 子域只让 Let's Encrypt 签。
• 收签发失败报告：CAA 0 iodef "mailto:security@example.com"。

• 续证前加 CAA —— 当前 CA 不在 CAA 里就会续签失败。
• 子域的 CAA 覆盖父域 —— 一不小心就把单个子域锁出来。
• 通配符签发要用 issuewild 标签，不是 issue（例如 CAA 0 issuewild "letsencrypt.org"）。
• 有些 CA 签发时忽略 CAA 但会记录违规 —— 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"

_<port>._<proto>.<name> <ttl> IN TLSA <usage> <selector> <match-type> <cert-data>

DANE TLSA 记录 —— 在 DNS 里 pin 一个 TLS 证书或公钥，靠 DNSSEC 验证。客户端不用走 CA 信任链就能验证证书。主要用于 SMTP STARTTLS 加固。

• SMTP DANE：pin 住 MX 的证书，让机会性 STARTTLS 变成强制 TLS。
• 支持 DANE 的浏览器（罕见，多走插件）做高安全 HTTPS。
• XMPP 联邦节点之间的 server-to-server TLS pinning。

• 区域必须开 DNSSEC —— 没 DNSSEC，TLSA 直接被忽略。
• 换证书时不同步更新 TLSA，证书一切几个小时后邮件就投递失败。
• Selector 0（整证书）vs 1（SPKI）—— SPKI 在 key 不变续证时不用动；选 selector 1 运维省事。
• 浏览器基本不强制 TLSA —— 别指望 HTTPS DANE 真对终端用户生效。

_25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abcdef0123456789...
_443._tcp.www.example.com. 3600 IN TLSA 3 1 1 1234567890abcdef...
_5269._tcp.xmpp.example.com. 3600 IN TLSA 3 1 1 fedcba9876543210...

<name> <ttl> IN HTTPS <priority> <target> <params>

HTTPS 服务绑定记录 —— 让域名在 DNS 层就广播 HTTPS 的现代参数（ALPN、ECH、IP 提示、端口），客户端能省一个回程，直接走 HTTP/2 或 HTTP/3。

• 广告 HTTP/3（h3），让 Chrome / Safari 跳过 HTTP/2 的 Alt-Svc 一次往返。
• Encrypted Client Hello（ECH）的 key 通过 ech= 参数发布。
• Cloudflare 开启 HTTP/3 后会自动发布 HTTPS 记录 —— 客户端透明拿到。

• 浏览器支持参差 —— Chrome / Safari 认，老客户端忽略。别只靠这一路。
• priority 0 = AliasMode（委托给另一个名字）；priority ≥ 1 = ServiceMode。两种模式容易混。
• ALPN 列表写错升级会悄悄失败 —— 只写服务端真的支持的协议。
• 一些老的解析器会把未知记录类型丢掉 —— 用 dig +short HTTPS 验一下。

example.com. 300 IN HTTPS 1 . alpn="h3,h2"
example.com. 300 IN HTTPS 1 . alpn="h3" ipv4hint=203.0.113.10 ipv6hint=2001:db8::1
cdn.example.com. 300 IN HTTPS 0 svc.cloudflare.com.

<name> <ttl> IN SVCB <priority> <target> <params>

Service Binding 记录 —— HTTPS 记录的协议无关父类。给非 HTTP 协议（DoH、DoQ、自定义服务）在 DNS 层发布端点参数用。

• DoH（DNS over HTTPS）端点发现，给解析器用。
• DoQ（DNS over QUIC）端点广告。
• 自定义协议需要在 DNS 里同时给 ALPN、端口、IP 提示。

• 坑跟 HTTPS 一样 —— 部署比 HTTPS 还新，老解析器奇葩行为更多。
• HTTP/HTTPS 服务用 HTTPS 记录，不要用 SVCB —— 格式一样但浏览器只看 HTTPS。
• ServiceMode 和 AliasMode 的 priority 语义新手第一次都栽。

_dns.example.com. 300 IN SVCB 1 dns.example.com. alpn="dot"
_dns.example.com. 300 IN SVCB 1 dns.example.com. alpn="h2,h3" port=443
_dns.example.com. 300 IN SVCB 0 cloud.example.com.