密码学与资源记录模型

01 · 公钥密码学基础

1.1 签名而非加密：DNSSEC的密码学选择

DNSSEC采用数字签名而非加密来保障安全。其逻辑是：区持有者用私钥对数据的摘要（哈希）签名，任何验证方用公开的公钥验证签名，从而确认"数据确实由持有者签发且未被篡改"。DNS的解析数据本身仍是明文（可被缓存、被观察），但每一条被签名的RRset都附带一个RRSIG，使伪造应答因缺省有效签名而被判定Bogus。

这一设计与TLS不同：TLS在传输层加密会话，DNSSEC在数据层绑定真实性。二者正交，因此"开启DNSSEC"并不等于"DNS流量被加密"——机密性仍需DoT/DoH提供（见子课题03）。

1.2 哈希、签名与RRSIG的构成要素

验证链路依赖两个密码学原语：哈希（摘要）将任意长度数据压缩为定长指纹；非对称签名用私钥对指纹签名、公钥验证。RRSIG记录本身携带"被签RRset类型、算法、标签数、原始TTL、签名有效期（inception/expiration）、key tag（密钥指纹）、签名者名、签名值"等字段（见§2.2）。这些字段使验证方能精确复现"应该被验证的数据窗口"，并拒绝过期或越界的签名。

1.3 密钥强度与选择原则

RFC 8624给出明确指引：新部署首选ECDSAP256SHA256（算法13）或RSASHA256（算法8），并建议逐步过渡到Ed25519（算法15）；RSA密钥长度推荐≥2048位（历史2048位为常见实践，早期1024位KSK已被认为偏弱）。椭圆曲线算法以更短签名提供同等/更高强度，显著降低UDP分片与TCP回退概率——这对受限网络尤为关键。

02 · 核心资源记录解析

2.1 DNSKEY —— 区的公钥

每个签名区在其区内发布一个或多个DNSKEY记录，携带区的公钥。关键字段：flags（256=ZSK区签名密钥；257=KSK密钥签名密钥/SEP）、protocol（固定为3）、algorithm（算法编号）、public key。区的DNSKEY RRset本身也被签名——由KSK签名，形成"密钥自证"闭环。父区则通过DS记录"背书"子区的KSK（flag 257）。

2.2 RRSIG —— RRset的数字签名

RRSIG记录覆盖一个RRset，字段含：被签类型（type covered）、算法、标签数（labels，用于通配符验证）、原始TTL、签名有效期（inception/expiration）、key tag（用于快速匹配签名所用DNSKEY）、签名者名（signer's name，即归属区）、以及二进制签名值。验证器用匹配DNSKEY重新计算并比对签名，同时检查有效期窗口。

2.3 DS —— 父区对子区KSK的委托摘要

DS（Delegation Signer）记录存放于父区，内容是对子区KSK的哈希摘要（含key tag、算法、digest type、digest），而非公钥本身。它把信任从父区"交接"到子区：验证器在父区看到DS，即可确认子区DNSKEY RRset中对应KSK是经父区认可的，从而延续链式信任。DS本身由父区用其KSK签名（在父区的RRSIG下）。

2.4 NSEC / NSEC3 —— 经认证的否定存在证明

经典DNS用"NXDOMAIN/No Data"表示"不存在"，但攻击者可以伪造否定应答实施"拒绝存在"攻击。DNSSEC必须能证明某名下确实不存在，即"经认证的否定存在证明（Authenticated Denial of Existence）"：

• NSEC（RFC 4034）：以有序链指向下一个存在的域名，并列出该名下所有记录类型，从而可证明"某域名/某类型不存在"。代价是会明文枚举整个区的所有域名。
• NSEC3（RFC 5155）：对域名做加盐哈希后再串链，缓解枚举，并支持Opt-Out（仅覆盖已签名的委托点），适合含大量未签名子委托的大型区。
• NSEC3PARAM：携带哈希算法、盐值、迭代次数等参数，供验证方复现哈希。

2.5 CDS / CDNSKEY —— 自动维护父区DS（RFC 7344/8078）

CDS与CDNSKEY是子区在自己区内发布的"自声明"记录，语义分别是"我希望父区发布的DS"和"对应的DNSKEY"。父区（或注册局自动化系统）读取子区CDS/CDNSKEY并据此增删改其DS，从而实现无需人工干预的密钥滚动——这是现代DNSSEC能"自动滚密钥"的核心机制（第4页详述）。RFC 8078进一步定义"this registry"（digest type 0的CDS）用于请求删除DS。

2.6 DLV（历史性，已不推荐）

DLV（DNSSEC Lookaside Validation，RFC 4431/5074）是早期在"父区未签名"时、通过独立信任锚旁路验证的过渡机制。随着根与主流TLD完成签名，DLV已退出主流实践，本课题仅作历史注记，不建议新部署采用。

$ dig +dnssec example.com DNSKEY | grep -E "DNSKEY|RRSIG" | head
example.com.      3600 IN DNSKEY 257 3 13 ( KSK, flag=257, alg=13 )
example.com.      3600 IN DNSKEY 256 3 13 ( ZSK, flag=256, alg=13 )
example.com.      3600 IN RRSIG  DNSKEY 13 2 3600 ( ... inception/exp ... keytag=12345 )
$ dig +dnssec com DS example.com
example.com. 86400 IN DS 12345 13 2 ( SHA-256 digest of KSK )

示例为说明性命令行与输出结构，实际值以真实区数据为准；生产环境应以 delv 做端到端验证（见第5、6页）。

03 · 算法与摘要状态（RFC 8624 / 9904）

RFC 8624（2019）给出了DNSSEC算法与DS摘要的"实现/使用"推荐；RFC 9904（2025）将这些状态纳入IANA注册表治理流程。下表汇总关键算法在当前注册表中的状态（"实现"指解析器/签名软件是否必须支持；"使用"指是否推荐用于新签名）：

DS摘要算法：SHA-1（1）MUST NOT用于新生成（验证仍须支持旧数据）；SHA-256（2）RECOMMENDED/MUST；SHA-384（4）MAY/RECOMMENDED。来源：RFC 8624 §3、IANA DNSSEC Algorithm Numbers 与 DS Digest Algorithms 注册表。注意：RFC 9904（2025-11）已废弃8624并将上述状态迁入IANA注册表治理，原有状态未变；引用时建议直接标注IANA注册表。算法淘汰须缓慢进行，避免整区退化为"等效未签名"。

04 · 签名与验证流程

验证一个RRset是否可信，验证器（递归解析器或终端）执行如下链路；任何一环失败即判Bogus：

4.1 关键匹配：Key Tag 与 Signer Name

RRSIG中的key tag是DNSKEY的简短指纹，用于快速定位"应由哪把公钥验证此签名"；signer name指明签名归属区，避免跨区误用。验证器必须确认RRSIG的签名者名与所验RRset所属区一致，且key tag指向的DNSKEY确实存在于该区并被相应KSK"背书"。

02B · RRSIG 字段结构详解（RFC 4034 §3）

RRSIG的报文字段顺序与语义必须精确掌握——故障排查（第6页）与实现审计都依赖对字段的逐项判读。RRSIG RDATA依次包含以下字段：

字段定义与"TTL钳制"规则见RFC 4034 §3；通配符labels语义见RFC 4035 §5.3.2。这两处是部署工具输出与手工排障时最易误读的位置。

05 · NSEC 与 NSEC3 的选型决策

NSEC与NSEC3各有取舍，选型取决于"隐私/区规模/运维复杂度"的权衡：

决策原则：在满足枚举缓解需求的前提下优先简单（NSEC）；若区含大量未签名委托或强枚举隐私要求，则采用NSEC3并务必配置充足的迭代次数与随机盐值。无论哪种，否定应答验证均依赖Aggressive NSEC缓存（RFC 8198）以提升性能。

06 · 实现要点与陷阱

• 通配符记录：*.example.com 的签名需按NSEC/NSEC3规则证明"更具体的名称不存在"，验证器据此接受通配符应答；配置错误会导致合法通配符被判Bogus。
• CNAME/DNAME：指向目标的记录须在同一验证域内被签名；跨区CNAME链每段都需各自验证。注意：CNAME与同名其他类型记录（RFC 4035 §2.4、RFC 6840 §4.4的约束）混存会导致验证失败，权威侧应保持"CNAME独占"规则。
• 标签计数（labels）：RRSIG的labels字段用于通配符与大小写/标签边界判定，膨胀（如国际化域名punycode）须正确计算。
• 签名有效期窗口：RRSIG inception/expiration须覆盖重签周期并有余量；时钟不同步的验证器可能误判过期。
• EDNS0缓冲区与分片：DNSSEC应答更大，易触发UDP分片与TCP回退；过短的EDNS0 UDP size或中间设备丢弃大包会导致验证失败（第6页故障排查重点）。
• 算法一致性：区签名算法与DS摘要算法须匹配；双算法过渡须先升DS摘要再滚KSK（RFC 8624/9904运维提示）。

本节参考来源（第2页）

以下为真实可查的权威来源，支撑本页关于记录语义、算法状态与NSEC/NSEC3的事实表述。