DNSSEC 深度解析：DNS安全扩展与邮件认证的信任根

DNS 自 1983 年由 Paul Mockapetris 设计以来，始终缺失一个关键的安全属性：数据完整性验证。传统的 DNS 协议（RFC 1034/1035）没有内建任何机制让解析器判断一条 A 记录或 MX 记录是否被篡改过——攻击者只需在递归解析器和权威服务器之间的路径上注入伪造的 DNS 响应，就能将流量重定向到恶意主机。这个攻击面被称为 DNS 缓存投毒（Cache Poisoning）。2008 年 Dan Kaminsky 在 Black Hat 上展示的著名漏洞将这个问题推到了极致——攻击者通过猜测 16 位事务 ID，可以在数秒内完成对任意域名的投毒。DNSSEC（DNS Security Extensions，RFC 4033/4034/4035）正是为终结这些问题而设计的协议扩展，它引入了基于公钥密码的数字签名来确保 DNS 应答的完整性和来源真实性。

在邮件安全领域，DNSSEC 的地位尤为特殊——它不是直接保护邮件传输的协议，而是作为下层信任基础设施支撑着 DANE（RFC 6698/7672）和 DMARC（RFC 7489）等多个邮件安全协议的运作。如果一台邮件服务器的解析器无法验证 DNSSEC 签名，那么 DANE 的 TLSA 记录就失去了信任依据，DMARC 报告的接收方也无法确认报告数据的来源真实性。理解 DNSSEC 的签名链验证机制，是把控邮件传输安全纵深防御体系的起点。

一、DNS 安全威胁模型：为什么需要 DNSSEC

DNS 面临的攻击向量可以分为三类。第一类是缓存投毒（Cache Poisoning）：攻击者向递归解析器发送伪造的 DNS 应答包。由于传统 DNS 应答只依赖 16 位的事务 ID 和源端口号进行匹配（总计约 2^32 种组合），在 Kaminsky 攻击中，攻击者同时对大量伪造的事务 ID 进行尝试，同时对权威服务器发起大量查询迫使解析器持续等待应答——最终只需数万次尝试即可命中正确的事务 ID，将恶意 IP 注入缓存。第二类是在途篡改（On-path Modification）：攻击者位于 DNS 查询路径上（如公共 Wi-Fi 热点、被攻陷的路由器），直接截获并修改 DNS 应答。第三类是域名劫持（Domain Hijacking）：攻击者通过社工或注册商漏洞获得域名控制权后修改 NS 记录。

DNSSEC 解决的是前两类问题：通过为每条 DNS 资源记录集（RRset）附加数字签名（RRSIG），解析器可以用域名的公钥（DNSKEY）验证签名的正确性。攻击者即使能伪造 DNS 应答包，也无法伪造合法的数字签名——因为他没有对应的私钥。

# 传统 DNS 查询：任何中间节点都可以篡改返回的 IP
$ dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34   # 未经签名保护，MITM 可替换

# DNSSEC 查询：签名验证失败时返回 SERVFAIL
$ dig +dnssec example.com A
;; flags: qr rd ra ad         # AD (Authenticated Data) 标志
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
example.com. 300 IN RRSIG A 13 2 300 ...  # 数字签名
;; 解析器验证 RRSIG → DNSKEY → DS 链，任一环节失败则 SERVFAIL

威胁类型	无 DNSSEC	有 DNSSEC
缓存投毒	高：Kaminsky 攻击成功率 100%（修补前）	无法伪造有效签名，SERVFAIL
在途篡改	高：MITM 即可完成	无法伪造有效签名，SERVFAIL
域名劫持	高：注册商层面安全问题	无法解决（非 DNS 协议层问题）
NSEC 遍历	N/A	中：可通过 NSEC3 缓解

二、核心资源记录：DNSKEY、RRSIG、DS、NSEC/NSEC3

DNSSEC 引入了四种核心资源记录类型，RFC 4034 对每一种都有精确定义。

DNSKEY：存储区域的公钥。每个 DNSSEC 签名区域至少包含两个 DNSKEY——KSK（Key Signing Key）和 ZSK（Zone Signing Key）。KSK 是一个长期密钥（推荐 1-2 年轮换），其公钥的哈希值通过 DS 记录提交到父区域，构成信任链的锚点。ZSK 是一个短期密钥（推荐 30-90 天轮换），用于实际签名区域内的所有 RRset。这种双层设计源于安全性考量：ZSK 频繁更换时无需修改父区域的 DS 记录（DS 只指向 KSK），KSK 可以存储在更安全的环境中（如 HSM）。DNSKEY RR 的标志位（Flags）区分 KSK（257）和 ZSK（256），协议字段（Protocol）固定为 3，算法字段（Algorithm）指示签名算法编号。

# 查询区域的 DNSKEY 记录
$ dig +dnssec DNSKEY ietf.org
;; ANSWER SECTION:
ietf.org. 3600 IN DNSKEY 256 3 13 (
    hmdyp1Dc6Tft8FddgafcxuyEs3Bmt73cz4d5i2w6lN4=
    ... )  ; ZSK, ECDSA P-256 (alg=13)
ietf.org. 3600 IN DNSKEY 257 3 13 (
    6s5AeqP2qQxq0XKPTB9AS4wG8GS4rCDM5tYPT4BtX4w=
    ... )  ; KSK, Flags=257 表示 SEP(Secure Entry Point)
ietf.org. 3600 IN RRSIG DNSKEY 13 2 3600 (
    20260715000000 20260625000000 54321 ietf.org.
    ... )  ; KSK 对 DNSKEY RRset 的签名

RRSIG：资源记录签名（Resource Record Signature）。每一条 RRSIG 记录对应一个具体的 RRset 类型和所有者名称，包含签名生成时间、过期时间、签名者名称（与 DNSKEY 的 owner name 对应）、密钥标签（Key Tag，指向用于签名的 DNSKEY）以及实际的加密签名数据。验证器通过以下流程验证一条数据：(1) 使用对应的 DNSKEY 公钥解密 RRSIG 的签名字段；(2) 将解密结果与 RRset 数据的哈希值比对；(3) 检查签名是否在有效期内（Inception ≤ 当前时间 ≤ Expiration）。任何一步失败都导致验证失败，解析器返回 SERVFAIL。

DS：委派签名者（Delegation Signer）。DS 记录存储在父区域中，包含子区域 KSK 的哈希值。DS 是信任链的关键一环——验证器从根区域的信任锚（Trust Anchor）开始，逐级验证子区域的 DS 记录→子区域的 DNSKEY→子区域数据的 RRSIG。父区域不对 DS 记录直接签名，DS 记录作为子区域在父区域中的普通 RRset 由父区域的 ZSK 签名。DS 记录的 Key Tag 用于标识对应的子区域 KSK，Digest Type 指示哈希算法（SHA-1=1 已废弃，SHA-256=2 为当前标准，SHA-384=4 为备选）。

# 查询父区域中子区域的 DS 记录
$ dig DS ietf.org
;; ANSWER SECTION:
ietf.org. 86400 IN DS 54321 13 2 (
    E06D44B80B8F1D39A95C0B0D7C65D08458E880409BB
    C683457104237C7F8EC8D )  ; KeyTag=54321, Alg=13(ECDSA P-256), Digest=SHA-256

# 从根信任锚开始逐级验证
$ dig +dnssec +trace ietf.org A
# 输出将展示根→org→ietf.org 的完整信任链建立过程
# 每一级都有 DS→DNSKEY→RRSIG 验证

NSEC/NSEC3：下一安全记录（Next Secure Record）。DNSSEC 需要一种机制来证明"某个名字不存在"——如果解析器查询一个不存在的域名，权威服务器返回 NXDOMAIN，但攻击者也可以伪造 NXDOMAIN 响应。NSEC 通过在区域中按字母顺序列出"下一个存在的名字"，验证器可以据此推断出"这两个名字之间没有任何记录"。问题在于 NSEC 本身暴露了区域中所有存在的名字——攻击者可以遍历整个区域。NSEC3（RFC 5155）通过用加盐哈希替代明文名字解决了这个问题，但增加了计算开销。

# NSEC 记录展示了 "下一个存在域名"
$ dig +dnssec NSEC ietf.org
;; ANSWER SECTION:
ietf.org. 3600 IN NSEC www.ietf.org. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY
# 表明 ietf.org 和 www.ietf.org 之间没有其他域名

# NSEC3：名字以哈希形式存储
$ dig +dnssec NSEC3PARAM ietf.org
;; ANSWER SECTION:
ietf.org. 3600 IN NSEC3PARAM 1 0 10 AB  # Hash算法=1, 不设Opt-out, 10次迭代, 盐='AB'

三、链式信任模型：从根锚到叶子域的签名链

DNSSEC 的信任模型是严格层级化的，与 DNS 委派结构一一对应。信任从根区域（.）的信任锚开始——递归解析器出厂时内置了根区域的 KSK 公钥（或哈希）。RFC 4033 将此定义为"信任锚"（Trust Anchor）。验证路径如下：

根区域 KSK（信任锚）→ 根区域 DNSKEY RRset 的 RRSIG（由根 KSK 签名）→ 根区域中 .org 的 DS 记录（由根 ZSK 签名）→ .org 区域 DNSKEY RRset 的 RRSIG（由 .org KSK 签名）→ .org 区域中 ietf.org 的 DS 记录（由 .org ZSK 签名）→ ietf.org 区域 DNSKEY RRset 的 RRSIG（由 ietf.org KSK 签名）→ ietf.org A 记录的 RRSIG（由 ietf.org ZSK 签名）。这条链上任一环节断裂，验证即失败。

# 使用 delv 进行完整的信任链验证（比 dig 更详细）
$ delv +vtrace ietf.org A
;; validating ietf.org/A: starting
;; validating ietf.org/DNSKEY: starting
;; validating ietf.org/DNSKEY: trying to validate with DS
;; validating org/DS: starting
;; validating org/DNSKEY: starting
;; validating org/DNSKEY: trying to validate with DS
;; validating ./DS: starting
;; validating ./DNSKEY: starting  ← 到达根信任锚
;; validated ./DNSKEY
;; validated org/DNSKEY
;; validated org/DS
;; validated ietf.org/DNSKEY
;; validated ietf.org/A: success

根区域的 KSK 由 ICANN 管理。2010 年根区域完成 DNSSEC 签名，2018 年完成了第一次根 KSK 轮转（RFC 8145 定义的信标系统用于检测哪些解析器尚未更新信任锚）。根区域当前使用算法 8（RSA/SHA-256），密钥长度 2048 位。

四、签名算法演进：从 RSA 到 Ed25519

DNSSEC 签名算法的发展反映了密码学工程在"安全强度 vs 签名尺寸 vs DNS 包大小限制"之间的持续权衡。DNS 应答包在 UDP 模式下受限于约 1232 字节（避免 IP 分片导致 PMTUD 问题），大尺寸签名会迫使回退到 TCP，增加延迟和服务器负载。

算法编号	名称	密钥长度	签名长度	安全性	RFC
5	RSA/SHA-1	1024-4096 bit	~128-512 byte	已废弃	3110
7	RSASHA1-NSEC3-SHA1	1024-4096 bit	~128-512 byte	已废弃	5155
8	RSA/SHA-256	1024-4096 bit	~128-512 byte	中（广泛使用）	5702
10	RSA/SHA-512	1024-4096 bit	~128-512 byte	高	5702
13	ECDSA P-256 / SHA-256	256 bit	~64 byte	高（推荐）	6605
14	ECDSA P-384 / SHA-384	384 bit	~96 byte	极高	6605
15	Ed25519	256 bit	~64 byte	极高（推荐）	8080
16	Ed448	456 bit	~114 byte	极高	8080

算法 13（ECDSA P-256）是当前部署最广泛的新一代算法。它的密钥仅 256 位（32 字节），签名仅约 64 字节，远小于 RSA 2048 位密钥产生的 ~256 字节签名，有效避免了 DNS 应答包的 IP 分片问题。算法 15（Ed25519，由 Daniel Bernstein 设计）作为更安全的替代方案正在获得采纳——EDNS0 扩展下的小包友好设计使其特别适合 DNSSEC 场景。Cloudflare 的 DNS 统计显示，截至 2026 年，约 62% 的 DNSSEC 签名域使用算法 13，约 18% 使用算法 8，约 12% 使用算法 15。

# Knot DNS 区域签名配置示例
# /etc/knot/knot.conf
template:
  - id: default
    dnssec-signing: on
    dnssec-policy:
      ksk-lifetime: 365d
      zsk-lifetime: 30d
      algorithm: ecdsap256sha256    # 算法 13
      # 切换到 Ed25519: algorithm: ed25519  # 算法 15

# BIND 9.16+ 区域签名配置示例
# /etc/bind/named.conf.options
dnssec-policy "standard" {
    keys {
        ksk key-directory lifetime P1Y algorithm 13;  # ECDSA P-256
        zsk key-directory lifetime P30D algorithm 13;
    };
    nsec3param iterations 0 optout no salt-length 8;
};

五、DNSSEC 与邮件安全：DANE 的信任底座

邮件安全协议栈对 DNSSEC 的依赖可以从两个维度理解。

DANE TLSA 记录验证（RFC 6698 / RFC 7672）：DANE 的安全性完全建立在 DNSSEC 之上。接收邮件服务器通过 TLSA 记录在 DNS 中公布其 TLS 证书的绑定信息；发送服务器查询 TLSA 记录时必须验证 DNSSEC 签名——如果签名验证失败或未签名，TLSA 记录不可信，DANE 验证回退到无保护的机会性 TLS。RFC 7672 明确规定 DANE for SMTP 的 TLSA 查询结果必须是 "DNSSEC-authenticated"，否则视为 DANE 不可用。RFC 6698 的定义同样适用于其他协议（如 HTTPS 的 DANE-EE 模式）。

DMARC 报告可信（RFC 7489）：DMARC 的 rua/rue 报告机制要求接收方向发送方反馈验证结果。这些报告通过邮件发送，其传输安全性同样受 DANE 保护。另外，DMARC 域名的 SPF/DKIM 验证结果本身在理论上也受 DNSSEC 保护——攻击者如果篡改了 SPF 记录（TXT RRset），DNSSEC 签名验证会检测出篡改。

邮件协议	对 DNSSEC 的依赖	失效后果
DANE for SMTP (RFC 7672)	强依赖：TLSA 必须 DNSSEC 签名	降级为机会性 TLS，MITM 可攻击
DANE 通用 (RFC 6698)	强依赖：TLSA 必须 DNSSEC 签名	TLSA 不可信，无法验证证书绑定
DMARC (RFC 7489)	弱依赖：SPF/DKIM 记录需 DNS 查询	SPF/DKIM 可能被投毒，误判邮件真实性
SPF (RFC 7208)	弱依赖：TXT RRset 签名保护查询	SPF 记录可被篡改，伪造发件人授权
DKIM (RFC 6376)	弱依赖：DKIM TXT 记录签名保护	公钥记录可被篡改，签名验证失效
MTA-STS (RFC 8461)	无直接依赖	MTA-STS 策略通过 HTTPS 获取，不依赖 DNSSEC

六、实战：验证一条 DANE TLSA 记录的完整 DNSSEC 信任链

以下操作演示从根信任锚出发，逐级验证 mailbox.org 邮件服务器的 DANE TLSA 记录。这个流程在邮件发送方的 Postfix DANE 验证模块内部自动执行。

# 步骤 1：查询 MX 记录（获取目标邮件服务器主机名）
$ dig +short MX mailbox.org
10 mx1.mailbox.org.
20 mx2.mailbox.org.

# 步骤 2：查询 TLSA 记录（_25._tcp 对应 SMTP 端口 25）
$ dig +dnssec TLSA _25._tcp.mx1.mailbox.org
;; flags: qr rd ra ad      # AD 标志 = DNSSEC 验证通过
;; ANSWER SECTION:
_25._tcp.mx1.mailbox.org. 600 IN TLSA 3 1 1 (
    AB12CD34EF56... )    # Usage=3(DANE-EE), Selector=1(SPKI), Matching=1(SHA-256)
_25._tcp.mx1.mailbox.org. 600 IN RRSIG TLSA 13 5 600 (
    20260715120000 20260625120000 12345 mailbox.org.
    ... )               # 由 mailbox.org 的 ZSK(alg=13) 签名

# 步骤 3：验证 TLSA 记录的 RRSIG → DNSKEY
$ dig +dnssec DNSKEY mailbox.org
;; ANSWER SECTION:
mailbox.org. 3600 IN DNSKEY 256 3 13 (...) ; ZSK, Key Tag=12345
mailbox.org. 3600 IN DNSKEY 257 3 13 (...) ; KSK

# 步骤 4：验证 mailbox.org 的 DNSKEY → DS → org
$ dig +dnssec DS mailbox.org
;; ANSWER SECTION:
mailbox.org. 86400 IN DS 12345 13 2 (
    FA1B2C3D4E5F... )    ; Key Tag=12345, 指向 mailbox.org 的 KSK
mailbox.org. 86400 IN RRSIG DS 8 1 86400 (...) ; 由 org 域 ZSK(alg=8) 签名

# 步骤 5：验证 org 的 DNSKEY → DS → 根
$ dig +dnssec DS org
;; ANSWER SECTION:
org. 86400 IN DS 9795 8 2 (
    5A6B7C8D... )       ; 指向 org 的 KSK(Key Tag=9795)

# 步骤 6：验证根 DNSKEY（信任锚）
$ dig +dnssec DNSKEY .
;; ANSWER SECTION:
. 172800 IN DNSKEY 256 3 8 (...) ; 根 ZSK
. 172800 IN DNSKEY 257 3 8 (...) ; 根 KSK(Key Tag=20326) - 信任锚

# 信任链完整路径：
# 根 KSK(DNSKEY) → org DS 的 RRSIG → org KSK(DNSKEY) → 
#   mailbox.org DS 的 RRSIG → mailbox.org KSK(DNSKEY) → 
#   _25._tcp.mx1.mailbox.org TLSA 的 RRSIG → TLSA 数据可信 ✓
#
# AD 标志的设置意味着递归解析器已经完成了以上所有验证

# 一行命令完成完整验证（delv 的 vtrace 模式）
$ delv +vtrace +dnssec _25._tcp.mx1.mailbox.org TLSA
;; validating _25._tcp.mx1.mailbox.org/TLSA: starting
;; validating mailbox.org/DNSKEY: trying to validate with DS
;; validating org/DS: validated
;; validated mailbox.org/DNSKEY
;; validated _25._tcp.mx1.mailbox.org/TLSA: success
; fully validated
_25._tcp.mx1.mailbox.org. 600 IN TLSA 3 1 1 AB12CD34EF56...

七、DNSSEC 部署的常见陷阱

DNSSEC 部署涉及多个持续运行的自动化流程，任何一个环节的故障都会导致整个域名的 DNS 解析失败（SERVFAIL）。RFC 6781（DNSSEC Operational Practices）提供了以下关键指导。

签名过期：最致命的故障。RRSIG 记录有一个固定的过期时间（Inception + Signature Validity Period）。如果签名服务器因故停止自动签名——比如 Knot DNS 的 autosign 守护进程崩溃、BIND 的 inline-signing 配置丢失、或系统时钟偏差——区域中所有记录的 RRSIG 将逐渐过期，最终所有查询返回 SERVFAIL。监控系统必须至少每天检查一次 RRSIG 剩余有效期。

# 检查 RRSIG 过期时间
$ dig +dnssec SOA example.com | grep "RRSIG.*SOA" | awk '{print $5,$6}'
20260715000000 20260625000000
# Inception=2026-06-25, Expiration=2026-07-15
# 如果 Expiration 在 72 小时内，触发告警

# 自动化监控脚本片段
#!/bin/bash
EXP_TS=$(dig +dnssec SOA example.com +short | grep RRSIG | awk '{print $6}')
NOW_TS=$(date -u +%Y%m%d%H%M%S)
if [ "$EXP_TS" -lt "$NOW_TS" ]; then
    echo "CRITICAL: RRSIG expired for example.com"
    exit 2
fi

KSK 轮转失败：KSK 轮转分为两步：首先向父区域提交新的 DS 记录（双 DS 阶段），等待 TTL 过期后删除旧 DS 记录，最后用新 KSK 重新签名区域的 DNSKEY RRset。如果在此过程中父区域的 DS 记录与子区域当前签名的 KSK 不匹配，信任链断裂。RFC 6781 Section 4.1.2 推荐使用"Double-Signature KSK Rollover"——在一个过渡期内同时使用新旧两个 KSK 签名 DNSKEY RRset，父区域同时发布两条 DS 记录。

# KSK 轮转安全流程（Double-Signature 方法）
# 阶段 1：生成新 KSK，但不提交 DS
dnssec-keygen -f KSK -a ECDSAP256SHA256 example.com

# 阶段 2：双 KSK 签名过渡期（至少旧 DS 记录的 TTL + 1 周）
# 在 named.conf 或 knot.conf 中启用双 KSK 签名
# 父区域中同时发布新旧两条 DS 记录

# 阶段 3：验证新 DS 已传播
$ dig +dnssec DS example.com @parent-ns
# 确认看到两条 DS 记录（Key Tag 不同）

# 阶段 4：删除旧 DS 记录和旧 KSK
# 确保旧 DS 记录的 TTL 完全过期后再继续

NSEC 遍历泄露：NSEC 允许攻击者通过遍历链式记录枚举区域中所有域名。使用 NSEC3（RFC 5155）并将 Opt-Out 标志设为 0、迭代次数设为 0（或极低值，如 1-5）可以在安全性和性能之间取得平衡。高迭代次数（如 150）会增加验证器的计算负担而对攻击者几乎没有额外阻力——攻击者可以预先计算完整的哈希字典。

UDP 包大小问题：DNSSEC 签名大幅增加了 DNS 应答包的体积。一条 DNSKEY RRset 可能达到 1-2KB，加上 RRSIG 可能超过 1232 字节的 EDNS0 安全上限。如果防火墙或中间网络设备阻止了 TCP 端口 53 或大 UDP 包，DNSSEC 验证将超时失败。部署 DNSSEC 必须确保网络设备允许 DNS over TCP（端口 53）通过，并向递归解析器正确通告 EDNS0 buffer size。

时钟同步：RRSIG 的有效性完全依赖系统时钟。如果签名服务器或验证解析器的系统时钟偏差超过签名有效期，将导致错误的正验证或错误的负验证。所有运行 DNSSEC 组件的服务器必须配置 NTP 同步。

八、DNSSEC 部署现状与邮件安全的未来

根据 APNIC 的全球 DNSSEC 验证率统计，截至 2026 年，全球约 37% 的终端用户通过支持 DNSSEC 验证的递归解析器访问互联网。欧洲地区部署率最高（北欧超过 90%，德国约 65%），亚太地区约 28%，北美约 35%。在 TLD 层面，约 93% 的 ccTLD 和国家顶级域已完成 DNSSEC 签名，但二级域名的签名率仍较低——全球前 100 万域名的 DNSSEC 签名率约为 6.8%。

DNSSEC 对邮件安全的未来影响将沿着两条路径展开。第一，随着 DANE adoption 的增长（目前德国 .de 域名的 SMTP DANE 部署率已达 18%，荷兰 .nl 约 14%），DNSSEC 作为 DANE 的前提条件的重要性持续提升。第二，DNSSEC 将为 B瑞MI（Brand Indicators for Message Identification）记录的安全查询提供信任基础——BIMI 的 SVG 标志文件 URL 如果托管在 DNSSEC 签名域上，可以有效防止标志被篡改。DNSSEC 不是邮件安全协议栈中的"可选项"，而是支撑整个基于 DNS 的邮件认证体系运作的基础信任层。

对于运维人员而言，理解 DNSSEC 的信任链验证机制，是排查 DANE 故障、理解 SPF/DKIM 查询可信度、确保 DMARC 报告可靠性的前置条件。域名的 DNSSEC 签名状态可以按如下方式快速检查，并应纳入日常运维监控。

# DNSViz 在线检测（生成可视化签名链）
# 访问 https://dnsviz.net/d/example.com/dnssec/

# 命令行快速诊断
$ dig +dnssec SOA example.com +short
# 如果返回 SOA 记录 + RRSIG → DNSSEC 已签名
# 如果仅返回 SOA 记录 → DNSSEC 未签名或验证失败

# 使用 DNSSEC 验证工具集
$ dnssectools check example.com
✓ example.com NS: dns1.example.com (RTT: 12ms)
✓ example.com DNSKEY: alg=13/ECDSAP256SHA256 (KSK+ZSK), keytag=54321
✓ example.com SOA: RRSIG valid, expires in 9d 14h
✓ DS at parent (.com): keytag=54321, alg=13, digest=2(SHA-256)
✓ Chain of trust: root → com → example.com — VERIFIED

参考来源：RFC 4033 - DNS Security Introduction and Requirements; RFC 4034 - Resource Records for the DNS Security Extensions; RFC 4035 - Protocol Modifications for the DNS Security Extensions; RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA; RFC 7672 - SMTP Security via Opportunistic DANE TLS; RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC); RFC 6781 - DNSSEC Operational Practices, Version 2; RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3); RFC 5702 - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC; RFC 6605 - Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC; RFC 8080 - Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC; APNIC Labs DNSSEC Validation Rate Statistics; IANA DNSSEC Algorithm Numbers Registry.

DNSSEC 深度解析 — RFC 4033/4034/4035：DNS 安全扩展与邮件认证的信任根

相关文章

📦 相关产品与方案