DNS 域名系统 | 原理、类型及解析时效

DNS 域名系统

1. DNS 概述

1.1 域名系统简介

DNS（Domain Name System，域名系统）是互联网中用于将人类可读的域名（例如 www.example.com）转换为计算机可理解的 IP 地址（例如 192.168.1.1）的分布式数据库系统。DNS 充当互联网中的"电话簿"角色，将用户输入的域名映射到实际的网络地址，使计算机能够定位并连接至目标服务器。

DNS 还有另一层含义：DNS（Domain Name Server，域名服务器）是执行域名解析任务的专用服务器。域名便于人类记忆，但网络中的计算机之间仅能识别 IP 地址，二者之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器完成。

1.2 域名解析工作原理

域名解析的工作流程如下：

说明：IP 地址相当于家庭地址（如"湖北省武汉市 xxx 小区 101 室"），域名相当于人名。DNS 的作用即是将人名与地址绑定，使他人无需记忆复杂地址即可找到目标。

2. DNS 记录类型

DNS 记录是 DNS 数据库中存储的域名与 IP 地址之间的映射关系。常见的 DNS 记录类型如下表所示：

2.1 A 记录（Address Record）

A 记录用于将域名或主机名映射到 IPv4 地址。通过设置 A 记录，可将特定域名直接指向一个具体的 IP 地址，使用户通过该域名访问对应的服务器或网络资源。

设置步骤：

注意事项：

• A 记录的目标地址只能使用 IP 地址，不支持域名。
• 同一域名可设置多条 A 记录实现轮询负载均衡。

2.2 AAAA 记录（IPv6 Address Record）

AAAA 记录用于将域名映射到 IPv6 地址，功能与 A 记录类似，区别在于目标地址为 IPv6 格式。随着 IPv6 的普及，AAAA 记录在双栈部署中具有重要作用。

AAAA 记录名称由来（"四个 A"的含义）：

AAAA 记录之所以被称为"四个 A"，是因为 IPv6 地址长度是 IPv4 地址的 4 倍。DNS 协议最早定义 A 记录时，用于将域名映射到 32 位的 IPv4 地址。后来需要支持 128 位的 IPv6 地址，需要一个新的记录类型。设计者选择了 AAAA（quad-A），取"四个 A"之意——4 x 32 位 = 128 位，正好对应 IPv6 地址的长度。这是一种助记符设计，方便记忆和理解两者之间的关系。

该记录类型最初在 RFC 1886（1996 年）中定义，后由 RFC 3596（2003 年）更新替代。IANA 分配的类型值为 28。

2.3 CNAME 记录（Canonical Name Record）

CNAME 记录用于将一个域名映射到另一个域名（即设置别名）。当目标域名的 IP 地址发生变化时，只需更新目标域名的 DNS 记录，无需修改所有引用该域名的 CNAME 记录，从而简化域名管理。

典型应用场景：

• 同时提供 WWW 和 MAIL 服务的计算机可设置多个 CNAME 别名指向同一个 A 记录主机名。
• CDN（Content Delivery Network，内容分发网络）加速服务通常要求用户域名设置 CNAME 指向 CDN 提供商提供的域名。

限制条件：

CDN 场景示例：

用户域名 www.dd.com 的服务器 IP 为 1.1.1.1，购买 CDN 服务后，CDN 提供商分配域名 www.dd.cdn.com。用户需将 www.dd.com 设置 CNAME 指向 www.dd.cdn.com：

www.dd.com → www.dd.cdn.com → CDN节点IP

当用户访问 www.dd.com 时，本地 DNS 获取 CNAME 指向的 www.dd.cdn.com，再通过 DNS 调度系统智能解析到距离客户端地理位置最近（或负载最低）的 CDN 服务器 IP，从而降低访问延迟。

CNAME 为什么被称为"别名"：

CNAME 是 Canonical Name 的缩写，canonical 意为"规范的、正式的、真实的"。该记录类型定义于 RFC 1034。RFC 2181 的明确说明：该文档专门指出"CNAME"一词常被误用。严格而言，CNAME 记录右侧的值才是真正的"规范名称"，左侧的标签只是该规范名称的一个别名。

解析器查询左侧域名时，收到的是"请去查另一个域名"的指示，随后以右侧域名为目标重新发起查询，直至获得 A 或 AAAA 记录。

以记录为例：

• blog.example.com —— 别名
• example.com —— 规范名称（真实名称）

类比理解：若某人的正式姓名为"张三"，“小张"是其别名。询问"小张的住址"时，得到的回答是"小张就是张三，请查张三的住址”。CNAME 记录中的左侧即"小张"，右侧即"张三"。

因此，CNAME 记录名称本身取自右侧的"规范名称"，而整条记录的功能是为左侧域名提供一个别名机制，故在日常表述中常直接称其为"别名记录"。

2.4 NS 记录（Name Server Record）

NS 记录用于指定该域名由哪个 DNS 服务器进行权威解析。注册域名时，系统会分配默认的 DNS 服务器，每个域名的 NS 记录地址通常以如下形式出现：

ns1.domain.com
ns2.domain.com

NS 记录的目标地址可以使用域名或 IP 地址。注意：仅一级域名（顶级域名）才拥有 NS 记录，子域名查询不会返回 NS 记录。

2.5 MX 记录（Mail Exchanger Record）

MX 记录用于指定负责处理发往该域名邮件的邮件服务器。MX 记录允许设置优先级，数值越小优先级越高。当存在多个邮件服务器时，邮件投递系统根据优先级决定投递目标服务器。

关键规则：

• MX 记录的目标域名必须能够映射到 A 记录或 AAAA 记录。
• 根据 RFC 2181，MX 记录原则上禁止指向 CNAME 记录。
• MX 记录的目标地址可以使用域名或 IP 地址。

2.6 TXT 记录（Text Record）

TXT 记录用于在 DNS 中存储文本信息。常见用途包括：

• SPF（Sender Policy Framework）反垃圾邮件：SPF 记录写在 DNS 的 TXT 记录中，用于声明哪些邮件服务器被授权代表该域名发送邮件，防止发件人域名伪造。
• 域名验证：部分服务（如 Google Workspace、Microsoft 365）使用 TXT 记录验证域名所有权。
• DMARC / DKIM：邮件认证相关配置也可存储在 TXT 记录中。

示例：

admin IN TXT "管理员, 电话：XXXXXXXXXXX"
mail IN TXT "邮件主机，存放在 xxx, 管理人：AAA"

2.7 PTR 记录（Pointer Record）

PTR 记录用于将 IP 地址反向解析为域名，是 A 记录的反向映射。PTR 记录主要应用于邮件服务器场景：邮件服务器在接收邮件时会检查发件服务器的 IP 地址并进行反向解析，若解析结果与发件域名匹配则接受邮件，否则可能拒绝接收。

PTR 记录的查询需要使用 in-addr.arpa 域（IPv4）或 ip6.arpa 域（IPv6）。

2.8 SOA 记录（Start of Authority Record）

SOA 记录记录域名的授权信息，包括主服务器名称、管理员邮箱、数据库版本序号及刷新参数等。每个域名在权威 DNS 服务器上必须存在一条 SOA 记录。

SOA 记录的字段结构如下：

域名. TTL IN SOA 主服务器名 管理员邮箱 序列号 刷新间隔 重试间隔 过期时间 最小TTL

各字段含义：

3. TTL 值

3.1 TTL 原理

TTL（Time-To-Live，生存时间）是 IP 协议首部中的一个 8 位字段，用于限制数据包在网络中的最大存活时间。在 DNS 语境下，TTL 表示一条域名解析记录在 DNS 服务器中的缓存有效期（单位为秒）。

TTL 的原始设计目的是防止数据包因路由错误陷入无限循环：每个路由器在处理数据包时将 TTL 值减 1，当 TTL 减至 0 时，路由器丢弃该数据包并向发送者返回 ICMP 超时报文。

在 DNS 缓存机制中，TTL 的作用如下：

• DNS 服务器收到解析请求后，向域名的 NS 服务器查询并获得解析记录。
• 该记录将在 DNS 服务器中缓存 TTL 指定的时间。
• 在缓存有效期内，相同域名的解析请求将直接返回缓存结果，不再向 NS 服务器发起查询。
• 缓存过期后，DNS 服务器将重新向 NS 服务器发起查询以更新记录。

3.2 TTL 设置策略

增大 TTL 值：

• 适用于域名记录长期不变的稳定场景。
• 增大 TTL 可减少 DNS 查询次数，降低解析延迟，提升网站访问速度。
• 一般建议将 TTL 设置为较大值（如 86400 秒，即 1 天）。

减小 TTL 值：

• 适用于计划进行 DNS 记录变更（如更换服务器 IP）的场景。
• 较小的 TTL 可加速全球 DNS 缓存更新，减少新旧服务器并存期间的访问不一致问题。
• 建议在变更前提前将 TTL 设置为较小值（如 60 秒）。

DNS 记录变更的标准操作流程：

常见操作系统的默认 TTL 初值：

4. 泛域名与泛解析

泛域名是指在一个域名根下，以 *.domain.com 的形式表示该域名根下所有尚未显式创建的子域名。

泛解析是将 *.domain.com 的 A 记录解析到指定 IP 地址的操作。设置泛解析后，访问任意前缀的 domain.com 子域名均可解析到同一目标服务器。

示例：

*.example.com → 192.0.2.1

上述配置后，aaa.example.com、bbb.example.com 等任意子域名均解析至 192.0.2.1。

注意事项：

• 泛解析优先级低于显式定义的子域名记录。例如，若同时存在 www.example.com 的 A 记录和 *.example.com 的泛解析，则 www.example.com 优先匹配显式 A 记录。
• 泛解析不适用于 MX、NS 等记录类型。

5. 域名绑定

域名绑定是指将域名指向服务器 IP 地址的操作，即通过设置 A 记录或 CNAME 记录，使域名解析到指定服务器的 IP 地址。

6. 域名转向

域名转向（Domain Forwarding / Domain Redirect）又称域名指向或域名转发，当用户在浏览器地址栏输入域名时，自动跳转到指定的另一个域名或 URL。常见的转向方式包括：

• 301 永久重定向：搜索引擎会将权重传递至目标 URL，适用于域名迁移场景。
• 302 临时重定向：搜索引擎不会传递权重，适用于临时跳转场景。

通常使用简短易记的域名转向至复杂难记的域名，以提升用户体验。

7. A 记录与 CNAME 记录对比

7.1 基本区别

7.2 管理便利性对比

场景：一台服务器托管多个域名，服务器 IP 为 1.1.1.1

使用 A 记录方案：

www.yy.com → 1.1.1.1
www.cc.com → 1.1.1.1
www.xx.com → 1.1.1.1
www.kk.com → 1.1.1.1

当服务器 IP 变更为 2.2.2.2 时，需逐一修改所有 A 记录。

使用 CNAME 方案：

www.yy.com → www.xx.com → 1.1.1.1
www.cc.com → www.xx.com → 1.1.1.1
www.kk.com → www.xx.com → 1.1.1.1

其中 www.xx.com 设置 A 记录指向 1.1.1.1。当服务器 IP 变更为 2.2.2.2 时，仅需修改 www.xx.com 的 A 记录，所有 CNAME 别名自动生效，无需逐一修改。

7.3 SEO 注意事项

• A 记录支持根域名（example.com）直接解析，无需输入 www 前缀即可访问。
• CNAME 记录通常需要 www 等子域名前缀，部分搜索引擎工具可能对根域名的 CNAME 支持有限。
• 可通过 301 重定向将根域名流量统一至 www 子域名，避免权重分散。
• 部分云服务商建议优先使用 CNAME 记录绑定域名，便于后续维护。

8. DNS 查询工具 dig

dig（Domain Information Groper）是类 Unix 系统下的命令行 DNS 查询工具，支持查询 A 记录、AAAA 记录、CNAME 记录、MX 记录、NS 记录等多种 DNS 记录类型。

8.1 基本查询

执行 dig www.baidu.com 将输出六段信息：

第一段：查询参数与统计信息

; <<>> DiG 9.10.6 <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17163
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 7

字段说明：

第二段：查询问题段（QUESTION SECTION）

;; QUESTION SECTION:
;www.baidu.com. IN A

• www.baidu.com.：查询的域名（末尾的点号表示完全限定域名 FQDN）
• IN：类别关键字（Internet）
• A：记录类型

第三段：答案段（ANSWER SECTION）

;; ANSWER SECTION:
www.baidu.com. 600 IN CNAME www.a.shifen.com.
www.a.shifen.com. 600 IN A 14.215.177.38
www.a.shifen.com. 600 IN A 14.215.177.39

字段说明（每行格式：域名 TTL IN 记录类型 记录值）：

上述结果显示：www.baidu.com 设置了 CNAME 别名指向 www.a.shifen.com，该别名对应两条 A 记录（14.215.177.38 和 14.215.177.39）。

第四段：授权段（AUTHORITY SECTION）

;; AUTHORITY SECTION:
a.shifen.com. 714 IN NS ns1.a.shifen.com.
a.shifen.com. 714 IN NS ns5.a.shifen.com.
a.shifen.com. 714 IN NS ns2.a.shifen.com.
a.shifen.com. 714 IN NS ns4.a.shifen.com.
a.shifen.com. 714 IN NS ns3.a.shifen.com.

返回 a.shifen.com 的 5 条 NS 记录，即负责管理该域名的 5 个权威 DNS 服务器。

第五段：附加段（ADDITIONAL SECTION）

;; ADDITIONAL SECTION:
ns1.a.shifen.com. 165 IN A 110.242.68.42
ns2.a.shifen.com. 162 IN A 220.181.33.32
ns3.a.shifen.com. 396 IN A 112.80.255.253
ns4.a.shifen.com. 101 IN A 14.215.177.229
ns5.a.shifen.com. 589 IN A 180.76.76.95
ns5.a.shifen.com. 119 IN AAAA 240e:940:603:a:0:ff:b08d:239d
ns5.a.shifen.com. 119 IN AAAA 240e:bf:b801:1006:0:ff:b04f:346b

返回 NS 记录中各服务器主机名对应的 A 记录和 AAAA 记录（IP 地址）。

第六段：查询统计信息

;; Query time: 5 msec
;; SERVER: 202.103.24.68#53(202.103.24.68)
;; WHEN: Thu Jun 23 10:48:49 CST 2022
;; MSG SIZE rcvd: 316

8.2 直接显示寻址结果

使用 +short 参数可简化输出，直接返回域名对应的 IP 地址或别名：

# 直接显示www.baidu.com对应的IP地址和CNAME
dig +short www.baidu.com
# 输出:
# www.a.shifen.com.
# 14.215.177.39
# 14.215.177.38

8.3 向特定 DNS 服务器查询

使用 @ 参数指定查询的 DNS 服务器地址：

# 向Google公共DNS服务器查询
dig @8.8.8.8 www.baidu.com

不同 DNS 服务器可能返回不同的解析结果（因各服务器缓存状态和地理位置差异），这属于正常现象，不代表某台服务器存在错误。

仅显示 ANSWER SECTION 内容可使用 +noall +answer 参数：

# 仅显示答案段内容
dig @8.8.8.8 www.baidu.com +noall +answer

8.4 查询 A 记录

# 查询www.baidu.com的A记录
dig a www.baidu.com

执行结果（部分）：

;; QUESTION SECTION:
;www.baidu.com. IN A

;; ANSWER SECTION:
www.baidu.com. 600 IN CNAME www.a.shifen.com.
www.a.shifen.com. 600 IN A 14.215.177.39
www.a.shifen.com. 600 IN A 14.215.177.38

8.5 查询 AAAA 记录

# 查询ns5.a.shifen.com的AAAA记录(IPv6)
dig aaaa ns5.a.shifen.com.

执行结果（部分）：

;; QUESTION SECTION:
;ns5.a.shifen.com.INAAAA

;; ANSWER SECTION:
ns5.a.shifen.com.600INAAAA240e:940:603:a:0:ff:b08d:239d
ns5.a.shifen.com.600INAAAA240e:bf:b801:1006:0:ff:b04f:346b

8.6 查询 CNAME 记录

# 查询www.baidu.com的CNAME记录
dig cname www.baidu.com

执行结果（部分）：

;; ANSWER SECTION:
www.baidu.com. 600 IN CNAME www.a.shifen.com.

8.7 查询 MX 记录

# 查询www.baidu.com的MX记录
dig mx www.baidu.com

执行结果（部分）：

;; ANSWER SECTION:
www.baidu.com.350INCNAMEwww.a.shifen.com.

;; AUTHORITY SECTION:
a.shifen.com.600INSOAns1.a.shifen.com. baidu_dns_master.baidu.com. 2206230007 5 5 2592000 3600

上述结果显示 www.baidu.com 存在 CNAME 别名指向 www.a.shifen.com，而 a.shifen.com 的 SOA 记录表明其权威服务器信息。需注意：若 MX 记录查询返回的是 CNAME 而非 MX 记录，说明该域名未直接配置 MX 记录（MX 可能配置在 CNAME 指向的目标域名上）。

8.8 查询 NS 记录

# 查询baidu.com的NS记录
dig ns baidu.com

执行结果（部分）：

;; ANSWER SECTION:
baidu.com.86400INNSns7.baidu.com.
baidu.com.86400INNSns4.baidu.com.
baidu.com.86400INNSns2.baidu.com.
baidu.com.86400INNSns3.baidu.com.
baidu.com.86400INNSdns.baidu.com.

baidu.com 共有 5 条 NS 记录，分别指向 ns7.baidu.com、ns4.baidu.com、ns2.baidu.com、ns3.baidu.com、dns.baidu.com。

注意： dig ns www.baidu.com 无法查询到 NS 记录，因为 NS 记录仅存在于顶级域名（一级域名）层级。

8.9 查询 PTR 记录

使用 -x 参数进行 IP 地址反向解析：

# 查询192.30.252.153的反向解析域名
dig -x 192.30.252.153

执行结果（部分）：

;; ANSWER SECTION:
153.252.30.192.in-addr.arpa. 3315 INPTRlb-192-30-252-153-iad.github.com.

查询结果表明 IP 192.30.252.153 反向解析得到的域名为 lb-192-30-252-153-iad.github.com（GitHub 的二级域名）。

8.10 查询 SOA 记录

# 查询baidu.com的SOA记录
dig soa baidu.com

执行结果（部分）：

;; ANSWER SECTION:
baidu.com.7200INSOAdns.baidu.com. sa.baidu.com. 2012145453 300 300 2592000 7200

8.11 查看 DNS 主从同步参数

通过 SOA 记录可了解 DNS 主从服务器的同步配置：

# 查询www.baidu.com的SOA记录以查看主从同步参数
dig -t soa www.baidu.com

SOA 记录格式为：

主服务器名 管理员邮箱 序列号 刷新间隔 重试间隔 过期时间 最小TTL

以 baidu.com 的 SOA 记录为例：

dns.baidu.com. sa.baidu.com. 2012145453 300 300 2592000 7200

各参数含义：

9. DNS 缓存与解析时效

9.1 域名缓存机制

DNS 缓存是提升域名解析效率的关键机制。当 DNS 服务器下发解析结果时，会附带 TTL 值指定缓存有效期。缓存不仅存在于 DNS 服务器端，也存在于用户终端（操作系统级别）。

解析域名时的查询顺序为：

9.2 缓存清除方法

Windows 系统：

查看 DNS 缓存：

# 查看当前DNS缓存内容
ipconfig /displaydns

清除 DNS 缓存：

# 清除DNS缓存并重新获取解析
ipconfig /flushdns

Linux 系统：

未安装 DNS 缓存服务（如 nscd、systemd-resolved）的 Linux 系统通常无本地 DNS 缓存。缓存可能来源于中间节点（如路由器/ISP DNS 服务器），可通过 nslookup 查看当前使用的 DNS 服务器地址：

# 查看域名解析结果及使用的DNS服务器
nslookup www.example.com

若使用 BIND 作为 DNS 服务器，可通过以下命令清除缓存：

# 清除BIND DNS服务器的缓存
rndc -s 127.0.0.1 flush

9.3 本地 Hosts 文件

本地 Hosts 文件提供域名到 IP 地址的静态映射，优先级高于 DNS 服务器查询。

Windows 路径：

C:\\Windows\\System32\\drivers\\etc\\hosts

Linux 路径：

/etc/hosts

Hosts 文件格式：

# IP地址 域名
1.1.1.1 www.dd.com
1.1.1.1 baidu.com

配置后可通过 ping 命令验证：

# 测试域名解析是否生效
ping www.dd.com

9.4 内网与外网缓存差异

内网环境： 自建 DNS 服务器可完全控制缓存 TTL。若需快速切换域名指向，可预先将 TTL 设为较小值（如 30 秒），等待所有客户端缓存过期后再修改记录。

外网环境： 用户域名解析经过运营商 DNS 服务器，运营商可能强制设置最小缓存时间（如 1 小时），导致自行设置的短 TTL 不生效。此时无法保证所有用户终端实现秒级切换，但大部分地区的解析更新可在较短时间内生效。

9.5 权威服务器与中间节点

在某些网络架构中（如存在 DMZ 隔离区域的内网），域名解析可能经过中间节点（如网关路由器）进行递归查询转发。可通过 dig 命令观察响应中的 SERVER 字段和 AA（Authoritative Answer）标志位判断是否为权威应答：

# 观察DNS查询经过的服务器及是否为权威应答
dig www.baidu.com
# 若显示 "SERVER: 192.168.3.1#53(192.168.3.1)" 且标注 "非权威应答"，
# 说明请求经由中间节点（如路由器）递归查询后返回

10. DNS 安全与加密传输

10.1 DNSSEC（DNS Security Extensions）

DNSSEC 是一组 DNS 扩展规范（RFC 4033~RFC 4035），为 DNS 查询提供身份验证和数据完整性保护。传统 DNS 协议在设计时未考虑安全性，查询响应未经数字签名，容易受到缓存投毒（Cache Poisoning）、DNS 劫持（DNS Hijacking）和中间人攻击（MITM）等威胁。

DNSSEC 通过以下机制增强安全性：

• 数据签名：域名所有者使用私钥对 DNS 记录进行数字签名，解析器使用对应的公钥验证签名真实性。
• 链式信任：从根域（.）开始，通过 DS 记录（Delegation Signer）在父域与子域之间建立信任链，逐级向下验证至目标域名。
• 防缓存投毒：由于响应数据带有签名，攻击者无法伪造虚假的 DNS 响应注入缓存。

部署现状：根域和大多数顶级域（.com、.net、.org 等）已启用 DNSSEC 签名。部分域名注册商和 DNS 托管服务商提供一键启用 DNSSEC 的功能。启用后需确保注册商处配置的 DS 记录与权威 DNS 服务器上的 DNSKEY 记录匹配。

10.2 DNS over HTTPS（DoH，RFC 8484）

DoH 是将 DNS 查询封装在 HTTPS 请求中进行传输的协议。传统 DNS 查询以明文 UDP 数据包传输，容易被网络中间节点窃听或篡改。DoH 利用 TLS 加密通道保护 DNS 查询隐私，同时利用 HTTPS 的端口 443 规避防火墙对 DNS 端口 53 的干扰。

特点：

• 查询内容对网络中间节点不可见，防止 DNS 窃听和劫持。
• 使用端口 443（HTTPS 默认端口），可绕过部分网络对 DNS 端口的封锁。
• 由 Mozilla、Google 等厂商推动，Firefox、Chrome 等浏览器已原生支持 DoH 配置。
• 可能引发隐私权衡：使用运营商 DNS 时运营商可记录查询日志，改用公共 DoH 服务（如 Cloudflare 1.1.1.1、Google 8.8.8.8）则将日志控制权转移至第三方。

配置方式：

• 浏览器级别：在浏览器设置中启用 “加密 DNS” 或 “安全 DNS” 选项。
• 操作系统级别：Windows 10/11 支持通过设置 > 网络和 Internet > 高级网络设置 > DNS 客户端设置配置 DoH。
• 系统级别 DNS 服务：可使用 systemd-resolved（Linux）配合 DoH 后端，或使用 dnsmasq、unbound 等 DNS 服务器软件支持 DoH 转发。

10.3 DNS over TLS（DoT，RFC 7858）

DoT 是使用 TLS 加密通道传输 DNS 查询的协议，运行于 TCP 端口 853。与 DoH 类似，DoT 也为 DNS 查询提供传输层加密保护，防止窃听和篡改。

DoH 与 DoT 对比：

选择建议：

• 在需要浏览器层面直接配置的场景中，DoH 更为方便。
• 在服务器端部署统一 DNS 加密的场景中，DoT 部署更为轻量。
• 两者可并行部署，客户端优先使用 DoH，降级使用 DoT，最终降级为传统明文 DNS。

10.4 EDNS0（Extension Mechanisms for DNS）

EDNS0（RFC 6891）是 DNS 扩展机制，允许 DNS 协议在不改变基础协议的前提下进行扩展。EDNS0 通过引入 OPT 伪资源记录实现以下能力：

• 扩展消息大小：默认 DNS 消息最大 512 字节（UDP），EDNS0 允许客户端声明支持更大的 UDP 消息尺寸（通常可达 4096 字节），减少因消息截断导致的 TCP 回退。
• DNSSEC 标志位（DO 标志）：客户端通过 EDNS0 的 DO 标志位声明支持 DNSSEC 验证，服务器在响应中附带 RRSIG 记录。
• 客户端端口子集（CPF）和 Cookie 选项：用于缓解 DNS 放大攻击和身份验证。

现代 DNS 解析器（如 systemd-resolved、unbound、bind9）默认启用 EDNS0 支持。

11. CNAME 记录机制

11.1 AAAA 记录名称由来

AAAA 记录之所以被称为"四个 A"，是因为 IPv6 地址长度是 IPv4 地址的 4 倍。DNS 协议最早定义 A 记录时，用于将域名映射到 32 位的 IPv4 地址。后来需要支持 128 位的 IPv6 地址，需要一个新的记录类型。设计者选择了 AAAA（quad-A），取"四个 A"之意——4 x 32 位 = 128 位，正好对应 IPv6 地址的长度。这是一种助记符设计，方便记忆和理解两者之间的关系。

该记录类型最初在 RFC 1886（1996 年）中定义，后由 RFC 3596（2003 年）更新替代。IANA 分配的类型值为 28。

11.2 CNAME 别名语义解析

CNAME 是 Canonical Name 的缩写，canonical 意为"规范的、正式的、真实的"。该记录类型定义于 RFC 1034。RFC 2181 专门指出"CNAME"一词常被误用。严格而言，CNAME 记录右侧的值才是真正的"规范名称"，左侧的标签只是该规范名称的一个别名。

解析器查询左侧域名时，收到的是"请去查另一个域名"的指示，随后以右侧域名为目标重新发起查询，直至获得 A 或 AAAA 记录。

以记录为例：

• blog.example.com —— 别名
• example.com —— 规范名称（真实名称）

因此，CNAME 记录名称本身取自右侧的"规范名称"，而整条记录的功能是为左侧域名提供一个别名机制，故在日常表述中常直接称其为"别名记录"。

11.3 CNAME 独占节点规则与记录冲突

CNAME 不能与 MX、NS、A、AAAA、TXT 等记录共存，是因为 DNS 协议规定：一旦某个主机名下存在 CNAME 记录，该节点上的其他资源记录集将被视为无效，解析器必须改用 CNAME 指向的目标域名继续查询。

11.3.1 协议层面：CNAME 独占节点

RFC 1034 第 3.6.2 节明确规定：

若某节点存在 CNAME 记录，则该节点不得存在其他任何数据。

RFC 2181 第 10.1 节进一步强调：CNAME 记录所在节点上，除 DNSSEC 相关记录（如 RRSIG、NSEC）外，不得出现其他任何类型的记录。

这意味着在 DNS 数据结构中，一个主机名（节点）要么直接持有资源记录，要么作为别名指向另一个主机名，二者不可兼得。

11.3.2 解析流程层面：CNAME 具有最高优先级

当解析器查询某主机名时，若该主机名下存在 CNAME 记录，解析器会优先返回 CNAME 记录，并自动转向查询 CNAME 指向的目标域名，而不再查询原主机名下的其他记录。

以 www.example.com 为例，若同时存在：

当邮件服务器查询 www.example.com 的 MX 记录时，权威服务器会返回 CNAME 记录而非 MX 记录。解析器随后转向 cdn.example.net 查询 MX，而 cdn.example.net 通常并无邮件相关配置，导致邮件投递失败。

11.3.3 对各类记录的具体影响

RFC 2181 第 10.3 节还特别指出：MX 记录和 NS 记录的值本身也不应指向 CNAME 记录，因为 DNS 的附加段处理（additional section processing）不会为别名展开地址记录，会导致每次查询都产生额外请求，某些严格实现的邮件服务器甚至会直接拒绝投递。

11.3.4 根域名的特殊限制

根域名（区域顶点，即 @）必须包含 SOA 和 NS 记录，因此按协议禁止设置 CNAME 记录。部分云解析服务商虽然允许在 @ 记录上强制共存 CNAME 与 MX / TXT，但会明确提示存在邮箱收信异常或 TXT 校验失败的风险，且通常不在服务等级协议保障范围内。

11.3.5 替代方案

若需在同一主机名下实现类似 CNAME 的指向效果，可采用以下方案：

• ALIAS / ANAME 记录（又称 CNAME Flattening）：由权威服务器在服务端将 CNAME 目标解析为 A / AAAA 记录后直接返回，客户端感知不到 CNAME 的存在，因此不与其他记录冲突。
• 使用子域名：将 CNAME 配置在 www 等子域名上，根域名保留 MX、TXT 等记录。
• 直接使用 A / AAAA 记录：适用于 IP 地址固定的场景。

11.4 ALIAS / ANAME 机制

ALIAS / ANAME 能绕过冲突，是因为它把 CNAME 的解析动作从客户端转移到了权威 DNS 服务器内部：对外返回的是 A / AAAA 记录，而非 CNAME 记录，因此不触发 RFC 1034 的独占规则。

11.4.1 CNAME 的冲突根源

当客户端查询某主机名时，若存在 CNAME 记录，权威服务器会返回 CNAME 记录本身，客户端必须再发起一次查询去解析目标域名。由于 CNAME 在协议层面具有独占性，该节点上的 MX、TXT 等记录会被解析器忽略。

11.4.2 ALIAS / ANAME 的绕过方式

权威服务器在收到查询请求后，内部执行以下步骤：

客户端收到的响应中只有 A / AAAA 记录，完全感知不到 CNAME 的存在。由于返回的是地址记录而非 CNAME 记录，MX、TXT、NS 等其他记录类型不受影响，可以正常共存。

11.4.3 关键差异对比

11.4.4 术语说明

ALIAS、ANAME、CNAME Flattening 本质上是同一机制的不同命名：

• ALIAS：DNS Made Easy、DNSimple、NS1 等使用，强调"别名"语义
• ANAME：Name.com 等使用，全称 “Address NAME”，强调解析为地址
• CNAME Flattening：Cloudflare 使用，强调将 CNAME 链"压平"为 A 记录

11.4.5 注意事项

• 非 RFC 标准：ALIAS / ANAME 是各 DNS 服务商的私有功能，不同服务商的实现细节和限制可能不同，迁移服务商时需重新配置。
• 区域传输问题：部分服务商的 ALIAS 记录不包含在 outgoing zone transfer 中，使用辅助 DNS 时需注意兼容性。
• 第三方验证场景：若 CNAME 目标用于第三方服务的域名所有权验证（如某些 SSL 证书验证），开启展平可能导致验证失败，因为响应中不再直接返回 CNAME 记录。
• TTL 取值：展平后的 A / AAAA 记录 TTL 通常取 CNAME 记录 TTL 与目标记录 TTL 中的较小值。

11.5 CNAME Flattening（展平）机制

11.5.1 展平的含义

"展平"指 CNAME Flattening：权威 DNS 服务器在收到查询时，不在响应中返回 CNAME 记录本身，而是由服务器内部递归解析 CNAME 目标，直到获得最终的 A / AAAA 记录，再将该 IP 地址直接返回给客户端。

假设存在如下配置：

若未展平，客户端查询 example.com 的 A 记录时，响应中会先出现 CNAME，客户端或递归解析器需继续查询 cdn.provider.net、edge.provider.net，才能获得 203.0.113.10。

开启展平后，权威服务器内部完成上述链式解析，直接返回：

客户端只看到 A 记录，不再感知 CNAME 链。

11.5.2 展平后 TTL 的取值

展平后的 A / AAAA 记录 TTL 通常取 CNAME 记录 TTL 与目标记录 TTL 中的较小值，原因在于缓存一致性：

若采用较大值，可能出现目标 IP 已失效但展平记录仍未过期的情况；取较小值可保证展平结果不会比原始记录更"长寿"。

11.6 Cloudflare 与 AWS Route 53 的 ALIAS / ANAME 实现对比

配置建议：

• 若域名使用 Cloudflare 且需将根域名指向第三方 CDN、PaaS 或任意外部服务，直接使用 CNAME 并依赖展平即可。
• 若域名使用 Route 53 且目标是 AWS 资源，优先使用 Alias 记录，可获得自动 IP 更新、健康检查集成和查询费用优化。
• 若第三方服务依赖直接返回 CNAME 记录进行域名验证，应关闭全局展平或对该记录禁用展平，否则验证可能失败。
• Route 53 Alias 不能以 CNAME 记录作为 zone apex 目标；若同区域内目标为 CNAME，需改用指向最终 A / AAAA 记录或其他非 CNAME 类型记录。

11.7 第三方域名验证（SSL 证书）展平失败处理

在使用第三方服务（如 SSL 证书申请、域名所有权验证）时，部分服务商要求查询域名的 CNAME 记录以验证所有权。若已开启 CNAME Flattening，权威服务器返回的是 A / AAAA 记录而非 CNAME 记录，导致第三方验证失败。

11.7.1 问题诊断

当 SSL 证书申请或域名验证提示"未找到 CNAME 记录"或"验证失败"时，可通过以下命令诊断：

若递归查询返回 CNAME 记录，而权威查询返回 A 记录（或反之），则说明展平已生效。

11.7.2 Cloudflare 场景处理

方案一：关闭全局展平

在 Cloudflare 控制面板中：

方案二：对特定记录禁用展平

Cloudflare 支持对单条 CNAME 记录禁用展平：

方案三：使用独立子域名进行验证

将验证记录配置在独立子域名上（如 verify.example.com），该子域名不启用展平：

11.7.3 AWS Route 53 场景处理

方案一：使用非 Alias 记录

在 Route 53 中，不创建 Alias 记录，而是创建标准的 CNAME 记录：

方案二：使用独立子域名

与 Cloudflare 类似，将验证记录配置在独立子域名上，避免与 Alias 记录冲突。

方案三：使用 Route 53 Health Check 集成

若需要健康检查与域名验证共存，可考虑：

11.7.4 通用最佳实践

• 验证前暂停展平：在进行第三方域名验证前，临时关闭展平功能，验证完成后再重新启用。
• 使用独立子域名：将验证记录（如 _dnsauth.example.com）配置在独立子域名上，避免与主域名的展平配置冲突。
• 检查 TTL 影响：关闭展平后，注意 CNAME 记录的 TTL 设置，确保验证结果能及时生效。
• 记录变更流程：将展平开关纳入变更管理流程，避免因展平配置遗漏导致生产环境问题。

DNS 各种记录类型解析时效

1 TTL 基础概念

TTL（Time to Live，生存时间）是 DNS 资源记录在递归 DNS 服务器缓存中的有效存活时长，单位为秒（s），遵循 [RFC 1035] 标准定义。权威 DNS 服务器在返回资源记录时附带 TTL 值，递归解析器在 TTL 有效期内直接响应查询，过期后需重新向权威服务器获取最新记录。

TTL 的分层缓存机制如下：

• 本地 DNS 缓存：客户端操作系统级缓存。Windows 默认 TTL 为 120 s；Linux systemd-resolved 服务通过 CacheMaxAgeSec 参数配置（默认上限 3600 s）。
• 递归 DNS 缓存：ISP/运营商节点缓存，典型保留时长 = TTL 设定值。
• 权威 DNS：域名注册商 NS 服务器记录，即时生效。

IANA 建议公共 DNS 服务的最小 TTL 值不低于 30 s；[RFC 2308] 规定否定缓存最小 TTL 为 300 s。

2 DNS 记录类型总览

IANA 维护的 DNS 资源记录类型注册表中，目前已有 200+ 种记录类型。以下按功能类别分组，详述各类记录的用途、格式、TTL 特性及推荐配置。

3 基础地址记录

3.1 A 记录（Type 1）

• 定义：[RFC 1035] — 将域名映射到 32 位 IPv4 地址。
• 格式示例：

example.com. 3600 IN A 192.0.2.1

• TTL 特性：无协议级默认值，由域名注册商/托管平台设定。全球 TOP10 域名注册商平均默认 TTL 为 7200 s（2 小时）。
• 推荐配置：
  • 生产环境稳定服务：86400 s（24 小时）
  • 灰度发布阶段：300 s（5 分钟）
  • 应急故障切换：60 s（1 分钟）

3.2 AAAA 记录（Type 28）

• 定义：[RFC 3596] — 将域名映射到 128 位 IPv6 地址。
• 格式示例：

example.com. 3600 IN AAAA 2001:db8::1

• TTL 特性：与 A 记录相同，无协议级默认值。
• 推荐配置：与 A 记录一致。IPv6 部署初期建议较低 TTL（3600 s），稳定后提升至 86400 s。

4 别名记录

4.1 CNAME 记录（Type 5）

• 定义：[RFC 1035] — 将一个域名别名指向另一个域名（规范名）。
• 格式示例：

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

• TTL 特性：CNAME 记录的 TTL 即为其别名目标的缓存时长。注意：CNAME 记录会覆盖同名称的其他记录类型（如 MX、TXT），需谨慎使用。
• 推荐配置：
  • CDN/云服务接入：300–3600 s
  • 稳定别名：86400 s

4.2 DNAME 记录（Type 39）

• 定义：[RFC 2672] — 重定向一个域名及其所有子域名到另一个域名（子树级别名）。
• 格式示例：

old.example.com. 3600 IN DNAME new.example.com.

• TTL 特性：与 CNAME 类似，但作用于整个子域树。
• 推荐配置：迁移场景建议 3600 s，稳定后 86400 s。

4.3 ANAME / ALIAS 记录

• 定义：draft-ietf-dnsop-aname — 实现 CNAME 展平（CNAME Flattening），解决根域名（apex domain）使用 CNAME 与其他记录冲突的问题。
• TTL 特性：由服务商实现，通常默认 300 s（Cloudflare）或 15 min（部分平台）。
• 推荐配置：与 A/AAAA 记录保持一致。

5 邮件相关记录

5.1 MX 记录（Type 15）

• 定义：[RFC 1035] — 指定域名的邮件服务器地址及优先级（数值越小优先级越高）。
• 格式示例：

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

• TTL 特性：无协议级默认值。邮件服务变更频率较低，通常配置较高 TTL。
• 推荐配置：
  • 稳定邮件服务：14400–86400 s（4–24 小时）
  • 金融行业典型配置：14400 s（4 小时）

5.2 SPF / DKIM / DMARC（基于 TXT 记录）

• 定义：这些并非独立的 DNS 记录类型，而是存储在 TXT 记录中的特定格式文本。
  • SPF（Sender Policy Framework）：[RFC 7208] — 指定允许代发该域邮件的服务器。
  • DKIM（DomainKeys Identified Mail）：[RFC 6376] — 邮件数字签名验证。
  • DMARC（Domain-based Message Authentication）：[RFC 7489] — 邮件域名策略报告与处置。
• 格式示例：

example.com. 3600 IN TXT "v=spf1 mx a ~all"

• TTL 特性：继承 TXT 记录的 TTL 设置。邮件安全策略变更频率低，建议较高 TTL。
• 推荐配置：3600–86400 s。修改 SPF/DMARC 策略前建议提前调低至 300 s。

6 域名服务器记录

6.1 NS 记录（Type 2）

• 定义：[RFC 1035] — 指定负责该域名的权威 DNS 服务器。
• 格式示例：

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

• TTL 特性：NS 记录的 TTL 由父区域（如 .com TLD）控制。子域 NS 记录的 TTL 通常由注册商设定。
• 推荐配置：86400 s（24 小时）。NS 记录变更需等待旧 TTL 过期后全局生效，建议提前规划。

6.2 SOA 记录（Type 6）

• 定义：[RFC 1035] / [RFC 2308] — 标记 DNS 区域的权威信息，包含主服务器、管理员邮箱、序列号等元数据。
• 格式示例：

example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
2024061201 ; Serial
3600 ; Refresh
900 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)

• TTL 字段说明：
  • Refresh（刷新间隔）：从区 2 服务器轮询主服务器的间隔，默认 3600 s。
  • Retry（重试间隔）：刷新失败后的重试间隔，默认 900 s。
  • Expire（过期时间）：从区 2 服务器无法联系主服务器时的过期时间，默认 604800 s（7 天）。
  • Minimum TTL（最小 TTL）：否定缓存的默认 TTL，也是区域内其他记录未显式设置 TTL 时的默认值。

7 反向解析记录

7.1 PTR 记录（Type 12）

• 定义：[RFC 1035] — 将 IP 地址映射到域名（反向 DNS 解析）。
• 格式示例：

1.2.3.4.in-addr.arpa. 3600 IN PTR example.com.

• TTL 特性：PTR 记录由 IP 地址的 ASN 持有者管理，通常 TTL 较高。
• 推荐配置：3600–86400 s。邮件服务器反垃圾验证依赖 PTR，建议保持稳定。

8 服务发现记录

8.1 SRV 记录（Type 33）

• 定义：[RFC 2782] — 指定特定服务的服务器位置，包含优先级、权重、端口和目标主机。
• 格式示例：

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.

• 字段说明：
  • Priority（优先级）：数值越小优先级越高。
  • Weight（权重）：同等优先级下的负载均衡权重。
  • Port（端口）：服务监听的 TCP/UDP 端口。
  • Target（目标）：服务所在主机域名。
• 推荐配置：300–3600 s。服务发现场景建议较低 TTL 以快速响应拓扑变更。

8.2 AFSDB 记录（Type 18）

• 定义：[RFC 1183] — 指定 AFS（Andrew File System）数据库服务器的位置。
• 格式示例：

example.com. 3600 IN AFSDB 1 afsdb.example.com.

• TTL 特性：内部文件系统使用，TTL 由内部策略决定，通常 3600–86400 s。

8.3 SVCB 记录（Type 64）

• 定义：[RFC 9460] — 服务绑定（Service Binding）记录，提供协议与端点信息，优化客户端连接决策。支持多端点冗余和参数传递。
• 格式示例：

example.com. 3600 IN SVCB 1 .

• TTL 特性：新兴记录类型，TTL 建议 300–3600 s。配合 HTTPS 记录使用可实现 QUIC/HTTP3 快速切换。
• 注意事项：部分老旧 DNS 解析器可能不支持 SVCB，需渐进式部署。

8.4 HTTPS 记录（Type 65）

• 定义：[RFC 9460] — SVCB 的特化版本，专门描述 HTTPS 服务的建联信息。
• 格式示例：

example.com. 3600 IN HTTPS 1 "alpn=h2,h3; no-default-alpn; ipv4hint=93.184.216.34;"

• TTL 特性：与 SVCB 相同，建议 300–3600 s。
• 关系：HTTPS 记录是 SVCB 的别名（HTTPS 的 svcparam 集合是 SVCB 的子集）。

9 安全与认证记录

9.1 CAA 记录（Type 257）

• 定义：[RFC 6844] — 证书颁发机构授权（Certification Authority Authorization），控制允许为域名颁发证书的 CA 机构。
• 格式示例：

example.com. 600 IN CAA 0 issue "letsencrypt.org"
example.com. 600 IN CAA 0 issuewild "sectigo.com"
example.com. 600 IN CAA 0 iodef "mailto:security@example.com"

• 字段说明：
  • flag：0（忽略不识别的指令）或 128（必须理解，否则拒绝签发）。
  • tag：issue（授权普通证书）、issuewild（授权通配符证书）、iodef（违规通知）。
  • value：CA 的域名标识或违规通知邮箱/URL。
• TTL 特性：从 2017 年 9 月 8 日起，CA/Browser Forum 187 号提案要求所有 CA 强制检查 CAA 记录。腾讯云等服务商默认 TTL 为 600 s。
• 推荐配置：600–3600 s。CAA 记录变更生效快，建议 600 s。

9.2 DNSSEC 系列记录

DNSSEC（DNS Security Extensions）通过数字签名保障 DNS 响应完整性与真实性，涉及以下记录类型：

9.2.1 DNSKEY 记录（Type 48）

• 定义：[RFC 4034] — 存储域的公钥，用于验证 RRSIG 签名。
• 格式示例：

example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3… )

• TTL 特性：密钥轮转频率低，建议高 TTL（86400 s）。ZSK（签名密钥）可低于 KSK（密钥签名密钥）。

9.2.2 DS 记录（Type 43）

• 定义：[RFC 4034] — 委托签名者（Delegation Signer），存储在父区域中，指向子域的 DNSKEY。
• TTL 特性：由 TLD/父区域管理，TTL 通常较高（86400 s）。变更需等待父区域刷新。

9.2.3 RRSIG 记录（Type 46）

• 定义：[RFC 4034] — DNSSEC 资源记录集签名。每条签名覆盖一个 RRset。
• TTL 特性：RRSIG 的 TTL 应等于被签名 RRset 的原始 TTL。签名有效期通常为 30 天（由 RRSIG 记录中的 Expiration 字段控制）。

9.2.4 NSEC 记录（Type 47）

• 定义：[RFC 4034] / [RFC 4035] — 提供否定存在证明（证明某名称在区域中确实不存在）。
• TTL 特性：应等于 SOA 的 Minimum TTL 字段值。[RFC 8198] 建议递归解析器在收到否定响应时使用 SOA Minimum 字段作为否定缓存 TTL。

9.2.5 NSEC3 记录（Type 50）

• 定义：[RFC 5155] — NSEC 的改进版，对域名进行哈希加密，防止区域枚举攻击。
• TTL 特性：与 NSEC 相同，等于 SOA Minimum TTL。

9.2.6 TLSA 记录（Type 52）

• 定义：[RFC 6698] — TLS 证书关联（TLSA），用于 DANE（DNS-based Authentication of Named Entities）协议。
• 格式示例：

_25._tcp.example.com. 3600 IN TLSA 3 1 1 <certificate-hash>

• 字段说明：
  • Certificate Usage（证书用法）：0–3，定义证书匹配方式。
  • Selector（选择器）：0（完整证书）或 1（公钥）。
  • Matching Type（匹配类型）：0（SHA-256）或 1（SHA-512）。
• 推荐配置：3600–86400 s。DANE 部署场景建议与证书有效期对齐。

9.2.7 SSHFP 记录（Type 44）

• 定义：[RFC 4255] — 存储 SSH 服务器的公钥指纹，用于 SSH 连接验证。
• 格式示例：

example.com. 3600 IN SSHFP 1 1 abcdef1234567890…

• 字段说明：
  • Algorithm（算法）：1 = RSA，2 = DSA，3 = ECDSA，4 = ED25519。
  • Fingerprint Type（指纹类型）：1 = SHA-1，2 = SHA-256。
• 推荐配置：86400 s。SSH 服务器密钥变更频率极低。

9.2.8 CERT 记录（Type 37）

• 定义：[RFC 4398] — 存储证书（PKIX、SPKI、PGP 等），用于 X.509 证书在 DNS 中的发布。
• TTL 特性：较少使用，TTL 由部署策略决定，通常 3600–86400 s。

9.2.9 OPENPGPKEY 记录（Type 61）

• 定义：[RFC 7929] — 存储 OpenPGP 公钥，用于将域名与 OpenPGP 密钥关联。
• TTL 特性：密钥轮转频率低，建议 86400 s。

9.3 CSYNC 记录（Type 65）

• 定义：[RFC 7477] — 区域同步（Child Synchronization），用于在父/子区域之间同步 NS 和 DS 记录。
• TTL 特性：新兴记录，TTL 建议 3600 s。

10 命名与路由记录

10.1 NAPTR 记录（Type 35）

• 定义：[RFC 3403] — 命名权威指针（Naming Authority Pointer），用于 ENUM 查询，将电话号码映射到网络服务。
• 格式示例：

example.com. 3600 IN NAPTR 100 10 "u" "E2U+sip" "!" "!.*!sip:user@example.com!" .

• 字段说明：
  • Order（顺序）：数值越小优先处理。
  • Preference（偏好）：同等 Order 下的优先级。
  • Flags（标志）：u（返回 URI）、s（返回服务名）等。
  • Services（服务）：如 E2U+sip。
  • RegExp（正则表达式）：用于转换查询。
  • Replacement（替换）：替代域名。
• 推荐配置：3600–86400 s。ENUM 服务变更频率低。

11 其他记录

11.1 HINFO 记录（Type 13）

• 定义：[RFC 1035] — 主机信息记录，存储主机 CPU 和操作系统信息。
• 格式示例：

example.com. 86400 IN HINFO "Intel Xeon" "Linux 5.15"

• 安全建议：暴露主机信息可能带来安全风险，生产环境建议删除或留空。

11.2 OPT 记录（Type 41）

• 定义：[RFC 6891] — EDNS0（Extension Mechanisms for DNS）选项记录，用于扩展 DNS 报文大小和添加扩展功能。
• TTL 特性：OPT 记录不缓存，TTL 字段被解释为 EXTENDED-RCODE 和 VERSION 等标志位，无实际 TTL 含义。

11.3 ANY 查询（Type 255）

• 定义：[RFC 1035] — 返回区域中所有记录类型。注意：[RFC 8482] 已禁止将 ANY 用于放大攻击，现代解析器对 ANY 查询返回有限结果。
• TTL 特性：不适用（ANY 是查询类型，非存储记录）。

11.4 AXFR / IXFR 记录

• 定义：[RFC 1035] / [RFC 1996] — 区域传输（全量/增量），用于主从 DNS 服务器同步。
• TTL 特性：不适用（传输协议级别操作，非资源记录）。

12 TTL 配置最佳实践

12.1 各记录类型 TTL 推荐速查表

12.2 TTL 变更管理流程

dig +nocmd +nocomment +ttlid example.com ANY

12.3 特殊场景策略

12.4 行业基准数据（来源：DNSPerf 2023 年度报告）

• 全球 TOP10 域名注册商平均默认 TTL：7200 s（2 小时）
• 金融行业典型配置：14400 s（4 小时）
• CDN 服务商推荐值：300–3600 s（动态调整）

13 DNS 记录类型编号表

以下为 IANA 注册的常用 DNS 记录类型及其编号（非 exhaustive，仅列常用类型）：

注：SPF 记录类型（Type 99）已在 [RFC 7208] 中被标记为"已归档"（Historic），实际部署中 SPF 策略统一使用 TXT 记录存储。

14 参考资料

• [RFC 1035] — Domain Names – Implementation and Specification
• [RFC 2308] — Negative Caching of DNS Queries
• [RFC 2672] — DNAME RR
• [RFC 2782] — A RR for Assigning Locators (SRV)
• [RFC 3123] — The APL RR
• [RFC 3403] — The Naming Authority Pointer (NAPTR) DNS Record
• [RFC 3596] — DNS Extensions to Support IPng
• [RFC 4034] — DNS Security Extensions (DNSSEC) Resource Records
• [RFC 4035] — Protocol Specifications
• [RFC 4255] — DNS RR for SSH Public Key Fingerprints
• [RFC 4398] — Storage of Certificates in the DNS
• [RFC 4701] — A Method for Storing IPsec Key Management Info in DNS
• [RFC 5155] — DNS Security Extension Naming Authority Privilege
• [RFC 6698] — DNS-Based Authentication of Named Entities (DANE)
• [RFC 6844] — Certification Authority Authorization (CAA)
• [RFC 6891] — Extension Mechanisms for DNS (EDNS0)
• [RFC 7208] — Sender Policy Framework (SPF)
• [RFC 7477] — Child Synchronization (CSYNC)
• [RFC 7489] — DMARC
• [RFC 7929] — OpenPGP Key Records in DNS
• [RFC 8198] — Authoritative DNS Using DNSSEC with Ed25519 and Ed448
• [RFC 8482] — Prohibiting Any Queries in the DNS
• [RFC 9460] — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS)
• IANA — DNS Resource Record (RR) TYPEs Registry: https://www.iana.org/assignments/dns-parameters
• DNSPerf — State of the Internet/LAN Report 2023

注：本文为“DNS 域名系统 ”相关合辑。 略作重排，如有内容异常，请看原文。

参考资料

• DNS 原理入门 — 阮一峰
• DNS 查询原理详解 – 阮一峰
• DNS 基础之通过 dig 命令理解 DNS 域名解析
• 一文弄懂什么是 DNS、A 记录、CNAME 以及使用方法
• RFC 8484 – DNS Queries over HTTPS (DoH)
• RFC 7858 – DNS over TLS (DoT)
• RFC 4033~RFC 4035 – DNS Security Extensions
• RFC 6891 – Extension Mechanisms for DNS (EDNS0)
• RFC 2181 – Clarifications to the DNS Specification
• CNAME Lookup – MxToolbox

• DNS A 记录 NS 记录 CNAME 记录 TXT 记录 TTL 值_a 记录 ttl-CSDN 博客 https://blog.csdn.net/silentpebble/article/details/44196083
• A 记录和 CNAME 记录的区别_没有 a 记录只有 cname-CSDN 博客_ https://blog.csdn.net/aaaaaab_/article/details/86678464
• 简单的解释下什么是 CNAME？-CSDN 博客 https://blog.csdn.net/DD_orz/article/details/100034049
• DNS 基础之通过 dig 命令理解 DNS 域名解析中的 A 记录，AAAA 记录，CNAME 记录，MX 记录，NS 记录_dig cname-CSDN 博客 https://blog.csdn.net/zxl1990_ok/article/details/125432123
• 一文弄懂什么是 DNS、A 记录、CNAME 以及使用方法_dns cname-CSDN 博客 https://blog.csdn.net/weixin_43820024/article/details/132116370