DNS 域名解析原理、资源记录类型、PTR 反向解析与邮件安全认证

一、DNS 是什么？

1.1 DNS 的定义

DNS 全称：

Domain Name System

中文称为：域名系统。

DNS 是一种分布式、层次化的命名系统，主要用于将域名映射到 IP 地址，也可以保存邮件路由、服务发现、证书验证等信息。

例如：

用户访问：

https://www.example.com

        |
        v

DNS 查询：

www.example.com

        |
        v

返回 IP：

203.0.113.10

        |
        v

浏览器连接服务器

这里的 203.0.113.10 是文档示例 IP。

DNS 不只负责域名到 IP 的转换，还能完成：

• 域名到 IPv4 地址的解析。
• 域名到 IPv6 地址的解析。
• IP 地址到域名的反向解析。
• 邮件服务器发现。
• 域名别名配置。
• 域名所有权验证。
• 邮件安全认证。
• 服务端口发现。
• DNSSEC 安全验证。
• HTTPS 服务参数发现。

---

1.2 DNS 使用什么端口？

DNS 传统上使用：

UDP 53
TCP 53

UDP 53：

通常用于普通 DNS 查询。

TCP 53：

用于需要 TCP 的 DNS 查询、部分较大响应、区域传送等场景。

现代 DNS 还支持：

协议	常见端口	作用
DNS over UDP	UDP 53	传统 DNS 查询
DNS over TCP	TCP 53	DNS 查询和区域传送
DNS over TLS（DoT）	TCP 853	加密 DNS 查询
DNS over HTTPS（DoH）	HTTPS，通常 443	通过 HTTPS 传输 DNS 查询
DNS over QUIC（DoQ）	UDP 853	通过 QUIC 加密 DNS 查询

注意：DoH、DoT 主要保护客户端与所使用的 DNS 解析服务之间的通信，并不自动保证 DNS 返回的数据可信。DNSSEC 解决的是另一类数据真实性和完整性问题。

---

二、DNS 的层级结构

DNS 是树状层级结构。

例如：

                  .
                根域
                  |
         +--------+--------+
         |        |        |
        com      net      org
         |
      example
         |
    +----+-----+
    |          |
   www        mail

完整域名：

www.example.com.

最后的 . 表示 DNS 根域。

从右向左看：

部分	含义
.	根域
com	顶级域名（TLD）
example	二级域名
www	子域名或主机名

在 DNS 区域文件中，完整域名通常以末尾的点表示绝对域名。

例如：

mail.example.com.

如果省略末尾的点，某些 DNS 配置系统可能将其视为相对名称，自动附加当前区域名。

但 GoDaddy 等 DNS 控制面板通常会自动处理域名后缀。

---

三、DNS 完整解析流程

假设浏览器访问：

https://www.example.com

3.1 第一步：浏览器查询缓存

浏览器首先可能查询自身的 DNS 缓存。

如果存在有效缓存，则不需要重新向外部 DNS 查询。

3.2 第二步：操作系统解析

如果浏览器没有缓存，会通过操作系统的名称解析机制查询。

可能涉及：

• Hosts 文件。
• 系统 DNS 缓存。
• 本地 DNS 解析服务。
• 配置的递归 DNS 服务器。

例如 Linux：

/etc/hosts
/etc/resolv.conf

注意：不同 Linux 发行版可能通过 systemd-resolved、NetworkManager 等管理 DNS。

3.3 第三步：递归 DNS 服务器查询

如果没有缓存结果，递归解析器需要寻找目标域名的权威 DNS 服务器。

简化流程：

客户端
   |
   v
递归 DNS 服务器
   |
   v
根 DNS 服务器
   |
   | 返回 .com 的相关 NS 信息
   v
.com 顶级域 DNS
   |
   | 返回 example.com 的委派信息
   v
example.com 权威 DNS
   |
   | 返回 www.example.com 的 A/AAAA
   v
递归 DNS 服务器
   |
   v
客户端

实际递归解析器会利用缓存、DNSSEC 验证、并行查询等机制优化过程。

什么是递归 DNS？

递归 DNS 负责帮助客户端寻找最终答案。

常见公共递归 DNS：

1.1.1.1
8.8.8.8
9.9.9.9

什么是权威 DNS？

权威 DNS 负责提供某个 DNS 区域的权威记录。

例如：

example.com

使用 GoDaddy 的权威 DNS，那么对应 DNS 区域中的 A、MX、TXT 等记录由 GoDaddy 的 DNS 服务提供。

域名注册商与权威 DNS 服务商可以是不同的公司。

例如：

域名注册商：GoDaddy

权威 DNS：Cloudflare

网站服务器：AWS

这是完全正常的架构。

---

四、DNS 资源记录（Resource Record）基础

DNS 中保存的数据称为资源记录：

Resource Record

简称 RR。

一条 DNS 记录通常具有以下信息：

NAME   TTL   CLASS   TYPE   RDATA

例如：

www.example.com. 3600 IN A 203.0.113.10

含义：

字段	值	说明
NAME	www.example.com.	记录名称
TTL	3600	缓存时间，单位秒
CLASS	IN	Internet 类
TYPE	A	IPv4 地址记录
RDATA	203.0.113.10	记录数据

GoDaddy 管理界面通常将这些字段显示为：

Type
Name
Value
TTL

其中：

@

通常代表当前 DNS 区域的根名称（Zone Apex）。

例如在 example.com 的 DNS 管理页面中：

@

表示：

example.com

而：

www

表示：

www.example.com

---

五、DNS 常见记录类型总览

DNS 的资源记录类型由 IANA 维护注册表。

严格来说，DNS 存在大量历史、实验性、专用及现代扩展记录类型，不是所有类型都能在 GoDaddy 普通 DNS 面板中手动创建。

下面先列出实际运维中最重要的类型。

类型	全称或含义	主要用途
A	Address	域名指向 IPv4
AAAA	IPv6 Address	域名指向 IPv6
CNAME	Canonical Name	域名别名
MX	Mail Exchange	指定收件邮件服务器
TXT	Text	文本验证及各种协议策略
NS	Name Server	指定权威 DNS
SOA	Start of Authority	DNS 区域权威管理信息
PTR	Pointer	反向解析
SRV	Service	服务地址和端口发现
CAA	Certification Authority Authorization	限制允许签发证书的 CA
DS	Delegation Signer	DNSSEC 父子区域信任链接
DNSKEY	DNS Public Key	DNSSEC 公钥
RRSIG	DNSSEC Signature	DNSSEC 数字签名
NSEC	Next Secure	DNSSEC 不存在性证明
NSEC3	Hashed Next Secure	DNSSEC 哈希不存在性证明
NSEC3PARAM	NSEC3 Parameters	NSEC3 参数
TLSA	TLS Authentication	DANE TLS 证书关联
SSHFP	SSH Fingerprint	SSH 公钥指纹
NAPTR	Naming Authority Pointer	规则重写及服务发现
DNAME	Delegation Name	DNS 子树别名
HTTPS	HTTPS Service Binding	HTTPS 服务参数
SVCB	Service Binding	通用服务绑定
LOC	Location	地理位置信息
RP	Responsible Person	域名负责人员信息
CERT	Certificate	DNS 中的证书相关数据
OPENPGPKEY	OpenPGP Key	发布 OpenPGP 公钥
SMIMEA	S/MIME Association	S/MIME 证书关联
CDS	Child DS	子区域向父区域发布 DS 更新意图
CDNSKEY	Child DNSKEY	子区域向父区域发布 DNSKEY 更新意图
CSYNC	Child Synchronization	子区域委派数据同步
ZONEMD	Zone Message Digest	DNS 区域数据摘要
DHCID	DHCP Identifier	DHCP 与 DNS 更新冲突检测
IPSECKEY	IPsec Key	IPsec 密钥发现
HIP	Host Identity Protocol	主机身份协议
AFSDB	AFS Database	AFS 数据库服务定位
KX	Key Exchanger	密钥交换服务器定位
HINFO	Host Information	主机硬件和操作系统描述

下面分别介绍。

---

六、A 记录：IPv4 正向解析

6.1 A 记录是什么？

A 记录用于将域名映射到 IPv4 地址。

例如：

example.com. 3600 IN A 203.0.113.10

表示：

example.com
      |
      v
203.0.113.10

6.2 GoDaddy 配置

字段	值
Type	A
Name	@
Value	203.0.113.10
TTL	600

查询：

dig example.com A

也可以：

nslookup example.com

6.3 多个 A 记录

例如：

example.com. IN A 203.0.113.10
example.com. IN A 203.0.113.11

DNS 可以返回多个 IPv4 地址。

客户端可能根据自身策略选择其中一个地址。

注意：

多个 A 记录不等于具有健康检查和故障自动切换能力的负载均衡系统。

---

七、AAAA 记录：IPv6 正向解析

AAAA 记录用于将域名映射到 IPv6 地址。

例如：

example.com. IN AAAA 2001:db8::10

表示：

example.com
      |
      v
2001:db8::10

查询：

dig example.com AAAA

GoDaddy 配置：

字段	值
Type	AAAA
Name	@
Value	2001:db8::10

IPv4 和 IPv6 可以同时配置：

example.com. IN A    203.0.113.10
example.com. IN AAAA 2001:db8::10

客户端可以根据网络支持情况选择 IPv4 或 IPv6。

---

八、CNAME 记录：域名别名

8.1 CNAME 是什么？

CNAME 用于将一个域名设置为另一个域名的别名。

例如：

www.example.com. IN CNAME example.com.

查询：

www.example.com
      |
      v
example.com
      |
      v
203.0.113.10

查询：

dig www.example.com CNAME

8.2 GoDaddy 配置

字段	值
Type	CNAME
Name	www
Value	example.com

8.3 CNAME 的重要限制

同一个 DNS 名称存在 CNAME 时，通常不能同时存在其他普通资源记录。

错误示例：

www.example.com. IN CNAME example.com.
www.example.com. IN A 203.0.113.10

另外，区域根名称通常不能配置标准 CNAME。

因为区域根必须同时存在 SOA、NS 等记录。

例如：

example.com

通常不能直接配置为普通 CNAME。

一些 DNS 服务商提供 ALIAS、ANAME 或 CNAME Flattening 等功能来解决类似需求。

这些是服务商功能，不应与标准 CNAME 记录完全混淆。

---

九、MX 记录：邮件服务器解析

MX 全称：

Mail Exchange

用于指定负责接收某个域名邮件的服务器。

例如：

example.com. IN MX 10 mail.example.com.

同时配置：

mail.example.com. IN A 203.0.113.20

邮件发送流程：

发件邮件服务器
       |
       v
查询 example.com 的 MX
       |
       v
mail.example.com
       |
       v
查询 mail.example.com 的 A/AAAA
       |
       v
连接收件邮件服务器

查询：

dig example.com MX

9.1 MX 优先级

例如：

example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.

数值越小，优先级越高。

10 优先于 20

MX 的目标应该是能够解析为地址的主机名，不应指向 CNAME。

MX 主要用于邮件接收路由，不决定哪些服务器有权发送邮件。

---

十、TXT 记录：文本与域名验证

TXT 是一种通用文本记录。

例如：

example.com. IN TXT "hello world"

TXT 本身没有固定业务含义。

不同应用协议会规定特定名称和文本格式。

常见用途：

• SPF 邮件发件授权。
• DMARC 邮件安全策略。
• DKIM 公钥发布。
• Let's Encrypt DNS-01 验证。
• Google Search Console 域名验证。
• Microsoft 365 域名验证。
• 其他第三方服务所有权验证。

例如：

_acme-challenge.example.com. IN TXT "验证值"

用于 Let's Encrypt DNS-01。

查询：

dig example.com TXT

查询 DMARC：

dig _dmarc.example.com TXT

注意：SPF、DKIM、DMARC 是通过特定 TXT 记录实现的邮件认证机制，并不是三个独立的常规 DNS RR 类型。

历史上曾定义专门的 SPF RR 类型，但现代 SPF 使用 TXT 记录。

---

十一、NS 记录：权威 DNS 服务器

NS 全称：

Name Server

用于标识某个 DNS 区域的权威名称服务器。

例如：

example.com. IN NS ns1.example-dns.net.
example.com. IN NS ns2.example-dns.net.

查询：

dig example.com NS

NS 记录与 DNS 委派密切相关。

例如：

.com 顶级域
      |
      v
example.com 的权威 DNS
      |
      v
example.com 的 DNS 记录

如果将域名从 GoDaddy DNS 迁移到 Cloudflare DNS，通常需要在注册商的 Nameservers 设置中更换权威名称服务器。

注意区分：

1. 注册商层面的 Nameservers 设置。
2. DNS 区域内部的 NS 资源记录。

两者相关，但不是完全相同的操作。

---

十二、SOA 记录：DNS 区域起始授权信息

这是 GoDaddy 默认记录中非常重要的一种。

12.1 SOA 是什么？

SOA 全称：

Start of Authority

中文可理解为：

DNS 区域权威起始记录。

每个正常的 DNS 区域都需要 SOA 记录。

它记录该区域的基本管理和同步信息。

例如：

example.com. IN SOA ns1.example-dns.net. admin.example.com. (
    2026100801
    28800
    7200
    604800
    600
)

以上只是示例，不代表 GoDaddy 当前实际配置。

12.2 SOA 字段详解

SOA 包含七个主要字段。

1. MNAME：主名称服务器

例如：

ns1.example-dns.net.

表示该区域指定的主权威名称服务器。

它不一定等于某个用户可直接访问的管理主机。

2. RNAME：管理员邮箱

例如：

admin.example.com.

在传统 SOA 格式中通常表示：

admin@example.com

SOA 中的 RNAME 使用 DNS 域名格式表达邮箱信息。

3. SERIAL：区域序列号

例如：

2026100801

用于标识 DNS 区域数据版本。

传统主从 DNS 架构中，从服务器可以比较序列号判断区域是否更新。

常见编号形式：

YYYYMMDDNN

例如：

2026100801

但这不是强制格式，很多托管 DNS 使用自动递增序列号。

4. REFRESH：刷新间隔

例如：

28800

单位为秒。

表示传统从权威服务器多久检查一次主服务器的区域序列号。

28800 秒 = 8 小时

5. RETRY：重试间隔

例如：

7200

表示从服务器刷新失败后，等待多久再次尝试。

7200 秒 = 2 小时

6. EXPIRE：过期时间

例如：

604800

表示从服务器在无法与主服务器成功同步的情况下，区域数据允许继续被视为有效的期限。

604800 秒 = 7 天

超过期限后，传统从服务器不能继续把过期区域当作有效权威数据提供。

7. MINIMUM：负缓存相关参数

例如：

600

在现代 DNS 中，SOA MINIMUM 主要用于确定否定响应的缓存时间。

例如：

NXDOMAIN

表示域名不存在。

否定缓存 TTL 通常由 SOA MINIMUM 和 SOA 记录 TTL 中较小的值决定。

注意：SOA MINIMUM 不应简单理解为所有 DNS 记录的最小 TTL。

---

12.3 为什么 GoDaddy 默认存在 SOA？

因为 GoDaddy 如果为域名提供权威 DNS 托管，就必须维护相应 DNS 区域的 SOA 信息。

SOA 用于：

1. 标识 DNS 区域的权威管理信息。
2. 记录区域版本号。
3. 支持传统主从 DNS 区域同步。
4. 定义相关刷新、重试和过期参数。
5. 为否定缓存提供参数。

因此：

GoDaddy 默认 SOA 是正常的 DNS 基础设施记录，不是多余记录。

通常不需要手动删除或修改。

GoDaddy 对 SOA 的修改权限取决于产品和管理方式，部分 Premium DNS 账户可修改某些字段，但不能随意添加或删除 SOA。

查询：

dig example.com SOA

---

十三、PTR 记录：DNS 反向解析

PTR 是本篇笔记的重点。

13.1 PTR 是什么？

PTR 全称：

Pointer

PTR 是 DNS 资源记录的一种。

它常用于 IP 地址到域名的反向解析。

正向解析：

域名 --> IP

反向解析：

IP --> 域名

例如：

正向解析：

mail.example.com
       |
       v
203.0.113.20

反向解析：

203.0.113.20
       |
       v
mail.example.com

PTR 不局限于反向 DNS 场景，但 IP 反向解析是最常见用途。

---

13.2 IPv4 反向解析为什么需要反转 IP？

DNS 本身是按照域名层级进行查询的。

IPv4 反向解析使用：

in-addr.arpa

例如 IP：

203.0.113.20

反向解析名称为：

20.113.0.203.in-addr.arpa.

为什么要反转？

IPv4 地址从左向右表示网络地址层级，而 DNS 域名的层级从右向左组织。

通过反转 IPv4 地址的八位组，可以将 IP 地址层级映射到 DNS 命名空间。

例如：

203.0.113.20
      |
      v
20.113.0.203.in-addr.arpa

对应 PTR：

20.113.0.203.in-addr.arpa. IN PTR mail.example.com.

查询：

dig -x 203.0.113.20

或者：

host 203.0.113.20

可能返回：

20.113.0.203.in-addr.arpa domain name pointer mail.example.com.

---

13.3 PTR 为什么不是在普通域名 DNS 中配置？

假设你在 GoDaddy 购买了：

example.com

又在云服务商购买了一台服务器：

公网 IP：203.0.113.20

你控制的两个对象不同：

example.com
    |
    +-- 域名 DNS 管理权

203.0.113.20
    |
    +-- 公网 IP 地址分配和反向 DNS 管理权

GoDaddy 管理：

example.com

不意味着它管理：

113.0.203.in-addr.arpa

后者属于 IP 地址反向 DNS 体系。

通常由：

• 云服务器提供商。
• 数据中心。
• ISP。
• IP 地址持有者。
• 获得反向 DNS 委派的机构。

负责配置。

因此：

购买域名并不自动获得任意公网 IP 的 PTR 修改权限。

---

13.4 如何正确配置 PTR？

假设：

域名：mail.example.com

服务器 IP：203.0.113.20

第一步：配置正向 A 记录

在 GoDaddy 中：

Type	Name	Value
A	mail	203.0.113.20

结果：

mail.example.com --> 203.0.113.20

第二步：向 IP 服务商配置反向 PTR

例如在云服务器提供商的 Reverse DNS 或 rDNS 设置中：

IP：
203.0.113.20

PTR：
mail.example.com

最终：

203.0.113.20 --> mail.example.com

第三步：验证正向解析

dig mail.example.com A +short

预期：

203.0.113.20

第四步：验证反向解析

dig -x 203.0.113.20 +short

预期：

mail.example.com.

---

13.5 什么是 FCrDNS？

FCrDNS 全称：

Forward-Confirmed Reverse DNS

中文可理解为：

正向确认的反向 DNS。

验证流程：

203.0.113.20
       |
       | PTR 查询
       v
mail.example.com
       |
       | A 查询
       v
203.0.113.20

如果反向解析得到的域名，再进行正向解析时能够解析回原始 IP，则满足常见的 FCrDNS 检查。

例如：

PTR：
203.0.113.20 --> mail.example.com

A：
mail.example.com --> 203.0.113.20

这是匹配的。

不匹配的例子：

PTR：
203.0.113.20 --> mail.example.com

A：
mail.example.com --> 198.51.100.50

反向得到的域名没有解析回原始 IP。

注意：

FCrDNS 只是正反向 DNS 一致性检查，不是加密身份认证。

它不能单独证明服务器安全或发件人可信。

---

13.6 PTR 在邮件服务器中的作用

邮件服务器是 PTR 最重要的实际应用场景之一。

假设：

发件服务器：

mail.example.com

公网 IP：

203.0.113.20

当服务器向 Gmail、Outlook 等邮件系统发送邮件时，对方可能执行：

1. 查询发件 IP 的 PTR。
2. 检查 PTR 是否存在。
3. 检查 PTR 是否指向合理的主机名。
4. 查询该主机名的 A/AAAA。
5. 检查是否能够解析回发件 IP。
6. 结合 SPF、DKIM、DMARC、IP 信誉等进行判断。

示意：

mail.example.com
       |
       | SMTP 发件
       v
目标邮件服务器
       |
       v
获取连接来源 IP
       |
       v
PTR 反向解析
       |
       v
mail.example.com
       |
       v
A 正向解析
       |
       v
203.0.113.20

配置合理的 PTR 有助于邮件投递。

但：

PTR 正确并不保证邮件一定进入收件箱。

邮件服务商还会考虑：

• SPF。
• DKIM。
• DMARC。
• IP 信誉。
• 域名信誉。
• 发信行为。
• 垃圾邮件内容。
• SMTP HELO/EHLO 名称。
• 其他反垃圾邮件策略。

---

13.7 PTR 是否必须与域名相同？

不需要与发件邮箱域名完全相同。

例如：

发件邮箱：
user@example.com

邮件服务器：
smtp.example.net

PTR：
203.0.113.20 --> smtp.example.net

只要邮件服务器的主机名、正反向解析和发信身份配置合理，就可以正常使用。

PTR 指向的是主机名，不一定是邮件地址中的域名。

---

13.8 IPv6 PTR 反向解析

IPv6 反向解析使用：

ip6.arpa

IPv6 地址不是按照 IPv4 的四个八位组反转，而是按照十六进制半字节（nibble）逐个反转。

例如：

2001:db8::1

展开为：

2001:0db8:0000:0000:0000:0000:0000:0001

将每个十六进制字符反向排列，并用点分隔，最后添加：

ip6.arpa.

得到：

1.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.

查询时不需要手工转换：

dig -x 2001:db8::1

dig 会自动构造 IPv6 反向查询名称。

---

十四、SPF：邮件发件服务器授权

SPF 全称：

Sender Policy Framework

用于声明哪些服务器有权使用某个域名作为 SMTP 信封发件域名。

SPF 通常使用 TXT 记录。

例如：

example.com. IN TXT "v=spf1 ip4:203.0.113.20 -all"

含义：

v=spf1

表示 SPF 版本。

ip4:203.0.113.20

允许该 IPv4 地址发送对应域名的邮件。

-all

表示其他未匹配来源不被授权。

常见 SPF 机制：

机制	作用
ip4	授权 IPv4 地址或网段
ip6	授权 IPv6 地址或网段
a	根据指定域名的地址记录匹配
mx	根据指定域名的 MX 主机地址匹配
include	引用另一个域名的 SPF 授权策略
exists	根据 DNS 查询结果匹配
all	匹配所有剩余来源
redirect	将 SPF 策略评估转向其他域名

常见限定符：

+  Pass
-  Fail
~  SoftFail
?  Neutral

注意：

SPF 验证的是 SMTP MAIL FROM 或 HELO/EHLO 相关身份，不是简单验证用户在邮件客户端看到的 From 地址。

---

十五、DKIM：邮件数字签名

DKIM 全称：

DomainKeys Identified Mail

DKIM 通过数字签名保护选定的邮件头字段和邮件正文。

基本过程：

发件邮件服务器
       |
       | 使用 DKIM 私钥签名
       v
发送邮件
       |
       v
收件邮件服务器
       |
       | 查询 DNS 中的 DKIM 公钥
       v
验证邮件签名

DKIM 公钥通常发布在 TXT 记录中。

例如：

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

其中：

selector1

称为 Selector（选择器）。

_domainkey

是 DKIM 使用的特定 DNS 名称结构。

p=

包含 DKIM 公钥数据。

DKIM 能够证明邮件的相关签名内容未被修改，并验证签名域名。

但 DKIM 单独通过，并不一定说明邮件显示的 From 域名通过了 DMARC 对齐检查。

---

十六、DMARC：邮件认证策略

DMARC 全称：

Domain-based Message Authentication, Reporting and Conformance

它建立在 SPF 和 DKIM 基础上。

DMARC 主要解决：

邮件显示的 From 域名，是否与通过认证的 SPF 或 DKIM 域名保持符合规则的对齐关系？

DMARC 还允许域名所有者发布失败处理策略，并接收认证报告。

---

16.1 GoDaddy 默认的 _dmarc TXT 记录

你提供的记录：

Name:

_dmarc

Value:

v=DMARC1;p=reject;adkim=r;aspf=r;rua=mailto:dmarc+rua@onsecuresever.net

完整 DNS 名称：

_dmarc.example.com

注意：

你提供的 onsecuresever.net 与 GoDaddy 官方示例的 onsecureserver.net 拼写不同。

另外，GoDaddy 官方示例的报告地址还使用了不同的邮箱本地部分。

因此不能直接将你提供的地址当作 GoDaddy 官方默认地址。

应核对实际记录来源及报告收件方是否有效。

---

16.2 v=DMARC1

v=DMARC1

表示：

DMARC Version 1

即 DMARC 策略记录的版本标识。

---

16.3 p=reject

p=reject

表示：

域名所有者要求接收方拒绝未通过 DMARC 检查的邮件。

常见策略：

策略	含义
none	监控，不要求基于 DMARC 失败采取特殊处置
quarantine	请求将失败邮件隔离，例如放入垃圾邮件
reject	请求拒绝失败邮件

注意：

DMARC 策略是域名发布的处理请求，最终处理仍由接收邮件系统决定。

p=reject 的风险

如果域名实际使用了邮件服务，但没有正确配置 SPF、DKIM 或域名对齐，合法邮件也可能被拒绝。

因此不能在不了解发信系统的情况下随意使用严格策略。

---

16.4 adkim=r

adkim=r

表示：

DKIM Relaxed Alignment

即 DKIM 宽松域名对齐。

例如：

邮件 From：

user@example.com

DKIM 签名域：

d=mail.example.com

在适用的组织域规则下，两者可以满足宽松对齐。

如果配置：

adkim=s

表示严格对齐，要求 DKIM 签名域与 From 域名完全一致。

---

16.5 aspf=r

aspf=r

表示：

SPF Relaxed Alignment

即 SPF 宽松域名对齐。

例如：

邮件 From：

user@example.com

SPF 认证域：

mail.example.com

在适用的组织域规则下，可以满足宽松对齐。

如果配置：

aspf=s

表示严格对齐。

---

16.6 rua=mailto:...

例如：

rua=mailto:dmarc+rua@onsecuresever.net

表示：

接收 DMARC 聚合报告的邮箱地址。

聚合报告通常包含：

• 发件 IP。
• 邮件数量。
• SPF 检查结果。
• DKIM 检查结果。
• DMARC 对齐结果。
• 接收方处理情况。

这些报告主要用于了解哪些系统正在以你的域名发送邮件，以及邮件认证是否正确。

注意：

1. rua 并不是把所有实际邮件转发给该地址。
2. rua 通常接收汇总报告，不是每一封邮件的正文。
3. 使用其他域名作为报告接收地址时，可能需要接收域名发布额外的授权 DNS 记录。
4. 如果报告邮箱错误、无法接收或缺少必要授权，报告可能无法送达。

---

16.7 DMARC 如何判断邮件通过？

假设邮件显示：

From: user@example.com

DMARC 要求至少满足以下条件之一：

条件 A：

SPF 认证通过，并且 SPF 认证域与 From 域满足 DMARC 对齐要求。

或者：

条件 B：

DKIM 验证通过，并且 DKIM 签名域与 From 域满足 DMARC 对齐要求。

简化公式：

DMARC Pass
    =
(SPF Pass AND SPF Aligned)
    OR
(DKIM Pass AND DKIM Aligned)

因此：

• SPF 通过但域名不对齐，可能 DMARC 失败。
• DKIM 通过但域名不对齐，可能 DMARC 失败。
• 只要其中一条路径通过并对齐，通常即可通过 DMARC。

---

16.8 为什么 GoDaddy 默认添加 DMARC？

主要是为了帮助域名所有者建立邮件认证策略，减少域名被冒用发送欺诈邮件的风险。

但需要特别注意：

DMARC 并不能完全阻止所有形式的邮件伪造。

它主要约束使用受保护 From 域名的邮件认证和对齐。

也不能阻止攻击者注册外观相似的其他域名。

如果你准备使用：

• 自建 Postfix。
• Microsoft 365。
• Google Workspace。
• 企业邮箱。
• 邮件营销平台。

应该根据实际发件架构检查 SPF、DKIM、DMARC 配置。

---

十七、CAA 记录：限制证书颁发机构

CAA 全称：

Certification Authority Authorization

用于声明哪些 CA 被允许为域名签发证书。

例如：

example.com. IN CAA 0 issue "letsencrypt.org"

表示授权 Let's Encrypt 为域名签发普通证书。

常见参数：

issue

控制普通证书签发授权。

issuewild

控制通配符证书签发授权。

iodef

提供与证书签发策略违规有关的报告联系信息。

例如：

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"

查询：

dig example.com CAA

注意：

CAA 主要约束 CA 的签发行为，不是浏览器在每次 HTTPS 连接时验证证书的替代机制。

---

十八、SRV 记录：服务发现

SRV 记录用于发现服务的：

• 主机名。
• 端口。
• 优先级。
• 权重。

格式：

_service._protocol.name

例如：

_sip._tcp.example.com. IN SRV 10 20 5060 sip.example.com.

字段：

Priority = 10

Weight = 20

Port = 5060

Target = sip.example.com

常用于：

• SIP。
• LDAP。
• Kerberos。
• XMPP。
• 某些游戏服务。
• 企业内部服务发现。

查询：

dig _sip._tcp.example.com SRV

SRV 并不意味着所有应用都会自动使用它，应用程序必须支持对应服务发现规则。

---

十九、NAPTR 记录

NAPTR 全称：

Naming Authority Pointer

主要用于基于规则的名称重写和服务发现。

常见于：

• SIP。
• ENUM。
• 电信服务。
• 某些复杂服务发现体系。

NAPTR 可以结合 SRV 记录使用。

简化流程：

查询 NAPTR
     |
     v
确定服务协议和下一步查询规则
     |
     v
查询 SRV
     |
     v
获取服务器和端口
     |
     v
查询 A/AAAA

查询：

dig example.com NAPTR

---

二十、DNSSEC 相关记录

DNSSEC 全称：

Domain Name System Security Extensions

用于对 DNS 数据提供来源认证和完整性验证。

DNSSEC 不负责加密 DNS 查询内容。

主要记录：

20.1 DNSKEY

保存 DNSSEC 公钥。

20.2 RRSIG

保存 DNSSEC 对资源记录集的数字签名。

20.3 DS

Delegation Signer。

用于将父区域与子区域的 DNSSEC 信任关系连接起来。

20.4 NSEC

用于证明某些 DNS 名称或记录类型不存在。

20.5 NSEC3

通过哈希名称等机制提供不存在性证明。

20.6 NSEC3PARAM

保存 NSEC3 使用的参数。

DNSSEC 简化信任链：

DNS Root
    |
    | DS / DNSKEY
    v
.com
    |
    | DS / DNSKEY
    v
example.com
    |
    | RRSIG
    v
A / AAAA / MX / TXT 等记录

启用 DNSSEC 时，注册商和权威 DNS 服务商之间的 DS 等配置必须正确。

错误的 DNSSEC 配置可能导致验证型解析器返回 SERVFAIL。

---

二十一、HTTPS 和 SVCB 记录

HTTPS 和 SVCB 是较新的 DNS 服务绑定记录类型。

它们不是网站的 TLS 证书本身。

21.1 HTTPS 记录

可以向客户端提供 HTTPS 服务相关信息，例如：

• 支持的 ALPN 协议。
• 可选端口。
• IPv4/IPv6 地址提示。
• ECH 相关配置。

示例：

example.com. IN HTTPS 1 . alpn="h2,h3"

这里表示 HTTPS 服务参数信息。

支持 HTTPS RR 的客户端可以利用它优化连接。

不支持的客户端仍可能通过传统 A/AAAA 查询连接网站。

21.2 SVCB 记录

SVCB 是更通用的服务绑定机制。

可用于服务端点和连接参数发现。

例如某些加密 DNS 服务发现方案会使用 SVCB。

查询：

dig example.com HTTPS

---

二十二、其他 DNS 记录类型

以下记录在普通网站部署中不常用，但在专门场景中有价值。

类型	作用
DNAME	为某个 DNS 子树提供别名
TLSA	使用 DANE 关联 TLS 证书或公钥
SSHFP	发布 SSH 主机密钥指纹
CERT	在 DNS 中保存证书相关数据
OPENPGPKEY	发布 OpenPGP 公钥
SMIMEA	S/MIME 证书关联
LOC	保存地理位置信息
RP	指定负责人员
HINFO	主机硬件和操作系统信息
AFSDB	AFS 数据库服务定位
KX	密钥交换服务器信息
IPSECKEY	IPsec 密钥信息
HIP	Host Identity Protocol 信息
DHCID	DHCP 动态 DNS 更新冲突检测
CDS	子区域请求父区域更新 DS
CDNSKEY	子区域发布 DNSKEY 更新意图
CSYNC	子区域委派同步
ZONEMD	DNS 区域内容摘要

还有历史遗留或已废弃的类型，例如：

MD
MF
A6
NXT
NSAP
NSAP-PTR

这些类型一般不应作为新系统的首选方案。

此外：

• AXFR、IXFR 是区域传送查询类型。
• ANY 是特殊查询类型。
• OPT 是 EDNS 使用的伪资源记录。

它们不能简单理解为 GoDaddy 面板里可随意添加的普通业务记录。

完整 DNS 类型注册表应参考 IANA。

---

二十三、DNS TTL 是什么？

TTL 全称：

Time To Live

表示 DNS 结果允许被缓存的时间。

例如：

example.com. 3600 IN A 203.0.113.10

TTL：

3600 秒 = 1 小时

表示缓存解析器可以在相应时间范围内复用该结果。

常见 TTL：

TTL	时间
60	1 分钟
300	5 分钟
600	10 分钟
1800	30 分钟
3600	1 小时
86400	24 小时

TTL 越短，通常越方便进行 DNS 变更。

但会增加查询频率。

注意：

修改 DNS 记录后，不代表全世界立即获得新结果。

已有缓存可能继续保留旧数据直到 TTL 到期。

部分解析器还可能实施自己的缓存策略。

---

二十四、GoDaddy DNS 实际配置案例

假设你购买了：

example.com

拥有：

网站服务器：
203.0.113.10

邮件服务器：
203.0.113.20

可以配置：

Type	Name	Value	作用
A	@	203.0.113.10	主域名 IPv4
CNAME	www	example.com	www 别名
A	mail	203.0.113.20	邮件服务器 IPv4
MX	@	10 mail.example.com	收件服务器
TXT	@	v=spf1 ip4:203.0.113.20 -all	SPF 授权
TXT	selector1._domainkey	DKIM 公钥记录	DKIM 验证
TXT	_dmarc	v=DMARC1; p=reject	DMARC 策略
CAA	@	0 issue "letsencrypt.org"	CA 签发限制
SOA	@	DNS 服务商管理	区域管理信息
NS	@	权威 DNS 服务器	域名委派

另外在 IP 提供商处配置：

PTR：

203.0.113.20 --> mail.example.com

最终结构：

example.com
    |
    +-- A
    |    |
    |    +-- 203.0.113.10
    |
    +-- www CNAME
    |    |
    |    +-- example.com
    |
    +-- MX
    |    |
    |    +-- mail.example.com
    |
    +-- SPF TXT
    |
    +-- DKIM TXT
    |
    +-- DMARC TXT
    |
    +-- CAA
    |
    +-- SOA
    |
    +-- NS

公网 IP 反向 DNS 区域
    |
    +-- PTR
         |
         +-- mail.example.com

---

二十五、Linux DNS 排查命令

25.1 查询 A 记录

dig example.com A

25.2 查询 AAAA 记录

dig example.com AAAA

25.3 查询 CNAME

dig www.example.com CNAME

25.4 查询 MX

dig example.com MX

25.5 查询 TXT

dig example.com TXT

25.6 查询 DMARC

dig _dmarc.example.com TXT

25.7 查询 DKIM

dig selector1._domainkey.example.com TXT

25.8 查询 NS

dig example.com NS

25.9 查询 SOA

dig example.com SOA

25.10 查询 PTR

dig -x 203.0.113.20

25.11 查询 CAA

dig example.com CAA

25.12 查询 DNSSEC

dig example.com DNSKEY +dnssec

25.13 指定 DNS 服务器查询

例如 Cloudflare：

dig @1.1.1.1 example.com A

Google：

dig @8.8.8.8 example.com A

25.14 查看完整 DNS 追踪

dig +trace example.com

这个命令可以观察从根域到目标权威 DNS 的委派和查询过程。

25.15 查询权威服务器

dig example.com NS +short

然后指定某台权威 DNS：

dig @ns1.example-dns.net example.com A +norecurse

其中名称服务器地址需要替换成实际查询到的权威 DNS。

---

二十六、常见问题

Q1：A 记录和 PTR 记录有什么区别？

A：

域名 --> IPv4

PTR：

IPv4 --> 域名

两者分别属于不同的查询方向。

Q2：配置了 A 记录会自动产生 PTR 吗？

不会。

正向解析与反向解析由不同 DNS 区域管理。

Q3：在 GoDaddy 买了域名，能不能直接配置公网 IP 的 PTR？

通常不能。

除非 GoDaddy 同时管理对应 IP 的反向 DNS 区域，或你获得了相应的反向 DNS 委派。

一般应向云服务器厂商或 IP 提供商配置。

Q4：没有 PTR，网站 HTTPS 会受影响吗？

通常不会。

普通浏览器访问 HTTPS 网站主要依赖正向 DNS 解析、网络连接和 TLS 证书验证。

PTR 通常不是 HTTPS 网站正常工作的必要条件。

Q5：没有 PTR，邮件会受影响吗？

可能。

许多邮件接收系统会检查发件 IP 的反向解析。

没有合理的 PTR 可能降低邮件投递成功率。

Q6：SOA 可以删除吗？

正常 DNS 区域需要 SOA。

GoDaddy 托管 DNS 中的 SOA 通常由系统管理，不应该删除。

Q7：DMARC 的 p=reject 是不是最安全？

它是严格的失败邮件处理策略之一。

但如果合法发信服务没有正确配置 SPF、DKIM 和对齐，可能导致合法邮件被拒绝。

因此需要根据实际邮件系统进行配置。

Q8：DNSSEC 和 HTTPS 有什么区别？

DNSSEC：

验证 DNS 数据来源和完整性。

HTTPS：

验证 TLS 服务器身份并保护 HTTP 通信。

两者解决不同层面的问题，可以配合使用。

---

二十七、最终总结

27.1 DNS 最常见记录

A       域名 --> IPv4

AAAA    域名 --> IPv6

CNAME   域名 --> 另一个域名

MX      域名 --> 邮件接收服务器

TXT     文本策略和验证信息

NS      权威 DNS 服务器

SOA     DNS 区域管理信息

PTR     IP --> 域名

CAA     限制证书签发 CA

SRV     服务主机和端口发现

27.2 PTR 的核心原理

正向 DNS：

mail.example.com
       |
       v
203.0.113.20


反向 DNS：

203.0.113.20
       |
       v
mail.example.com

公网 IP 的 PTR 通常由 IP 服务商配置。

邮件服务器推荐保持正反向解析合理一致。

27.3 GoDaddy 默认 SOA

SOA 用于管理 DNS 区域的：

主权威服务器
管理员联系信息
区域序列号
刷新间隔
重试间隔
过期时间
否定缓存参数

它是 DNS 区域的基础记录。

27.4 GoDaddy 默认 DMARC

例如：

v=DMARC1;p=reject;adkim=r;aspf=r;rua=mailto:report@example.com

表示：

v=DMARC1
    DMARC 版本

p=reject
    请求拒绝 DMARC 失败邮件

adkim=r
    DKIM 宽松对齐

aspf=r
    SPF 宽松对齐

rua=mailto:...
    聚合报告接收地址

DMARC 的核心目的是：

通过 SPF/DKIM 认证与 From 域名对齐，帮助减少域名被冒用发送邮件的风险。

---

参考资料

1. IANA DNS Resource Record Types
   https://www.iana.org/assignments/dns-parameters

2. RFC 1034 — Domain Names Concepts and Facilities
   https://www.rfc-editor.org/rfc/rfc1034

3. RFC 1035 — Domain Names Implementation and Specification
   https://www.rfc-editor.org/rfc/rfc1035

4. RFC 2317 — Classless IN-ADDR.ARPA Delegation
   https://www.rfc-editor.org/rfc/rfc2317

5. RFC 7208 — SPF
   https://www.rfc-editor.org/rfc/rfc7208

6. RFC 6376 — DKIM
   https://www.rfc-editor.org/rfc/rfc6376

7. RFC 7489 — DMARC 原始规范
   https://www.rfc-editor.org/rfc/rfc7489

8. RFC 8659 — CAA
   https://www.rfc-editor.org/rfc/rfc8659

9. RFC 9460 — SVCB and HTTPS DNS Records
   https://www.rfc-editor.org/rfc/rfc9460

10. GoDaddy DNS 帮助中心
    https://www.godaddy.com/help