01 · 签名工作流概述
DNSSEC区的签名有两种主流工作流，选择取决于运维模型与基础设施：
| 模式 | 工作方式 | 优点 | 局限 |
|---|---|---|---|
| 离线预签名 （Pre-signing） | 在区文件落盘前，由签名工具（如BIND dnssec-signzone）批量生成RRSIG/NSEC，输出完整已签区，再由权威服务器直接发布。 | 私钥可完全离线保管，抗私钥泄露；实现简单、对权威服务器无特殊要求。 | 动态记录（频繁变更）需频繁重签或整区批处理；响应实时变更不灵活。 |
| 在线动态签名 （On-the-fly） | 权威服务器（如Knot DNS、PowerDNS、BIND inline-signing）在应答时实时生成签名，私钥在线或经安全模块访问。 | 支持动态更新、通配符与否定应答即时正确；适合大规模/高频变更区。 | 私钥在线风险更高，须配合HSM/密钥隔离与严格访问控制。 |
演进趋势：早期DNSSEC以离线预签为主（当时服务器不够安全、密钥需离线）。如今主流权威软件普遍支持inline-signing，使"动态签名"成为降低运维复杂度、提升正确性的主流选择；但私钥在线须以HSM（硬件安全模块）或密钥分片/隔离为前提。无论哪种模式，签名有效期窗口与重签节奏都须纳入监控（第6页）。
02 · 密钥模型取舍：ZSK / KSK / CSK
区签名涉及两类密钥角色，部署时可采用分离或合并模型：
- ZSK（区签名密钥，flag 256）：用于签署区内普通RRset，按RFC 6781建议相对高频轮转（如按月/按季度），因泄露影响面可控且不影响父区DS。
- KSK（密钥签名密钥，flag 257）：仅签署本区DNSKEY RRset，并被父区DS"背书"；轮转须同步父区DS，流程更重，故低频（如按年）。
- CSK（Combined Signing Key）：单一密钥同时承担ZSK与KSK角色（flag 257）。简化密钥数量与轮转，但每次轮转都需父区DS配合，适合中小区或追求最简运维的场景。
| 模型 | 密钥数量 | 轮转影响 | 适用 |
|---|---|---|---|
| ZSK+KSK 分离 | 2（含待轮转时暂存） | ZSK可独立高频轮转，不触碰父区DS；KSK低频轮转 | 大型/规范化运营区，推荐默认 |
| CSK 单一 | 1 | 每次轮转都须父区DS配合 | 中小区、追求极简运维 |
注：KSK轮转的"父区DS同步"是DNSSEC部署正确性的关键路径；RFC 7344/8078的CDS/CDNSKEY机制正是为消除这一人工步骤而设计（见§05与第4页）。
03 · 主流签名工具与方案对比
不同权威平台对DNSSEC的支持度与运维模型差异显著，选型应结合团队能力与动态性需求：
| 方案 | 签名方式 | 密钥管理 | 自动化程度 |
|---|---|---|---|
| BIND （named / dnssec-*） | dnssec-signzone离线签名 + inline-signing在线签名；9.16+支持dnssec-policy策略化自动签名 | dnssec-keygen / auto-dnssec / dnssec-policy；管理密钥与轮转 | 很高（policy驱动全自动） |
| Knot DNS | 在线动态签名（keymgr） | keymgr集中管理密钥生命周期与轮转 | 很高（内置KSK/ZSK自动轮转） |
| PowerDNS （Authoritative） | 在线签名（records+crypto），支持HSM | 经API/后端管理；强调自动化降低复杂度 | 很高（DS通过CDS自动提交） |
| OpenDNSSEC | 与权威解耦的签名引擎（与BIND/NSD配合） | KASP策略驱动密钥与签名全生命周期 | 高（策略化、可HSM） |
| ldns / 脚本 | dnssec-signzone类工具/自研脚本 | 手工或半自动 | 低（适合教学/小域） |
# BIND 离线签名示例（示意） dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com. # 生成 ZSK dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE example.com. # 生成 KSK dnssec-signzone -S -o example.com -t example.com.zone # 签名并输出 zone.signed # 现代 BIND 更常用 inline-signing + auto-dnssec maintain，由 named 自动签与轮转
以上命令为说明性结构；实际参数（密钥长度、目录、算法）以各软件官方文档为准。本课题不提供可直接运行于未授权系统的脚本。
3.1 现代自动化：dnssec-policy（BIND 9.16+）与云托管签约
BIND 9.16起引入dnssec-policy声明，把"密钥生成—签名—轮转—CDS发布"整合为由named自动执行的策略，替代早期手工dnssec-keygen/dnssec-signzone流程；Unbound等验证器侧亦普遍内置根锚与RFC 5011自动更新。对不自建权威的场景，主流云DNS提供托管签约（私钥由平台托管，用户只需在注册商处确认DS）：
| 方案类型 | 代表 | 密钥保管 | DS对接 |
|---|---|---|---|
| 自管权威+策略驱动 | BIND 9.16+ dnssec-policy；Knot keymgr；OpenDNSSEC KASP | 本地/HSM | CDS自动或人工 |
| 托管DNS一键签约 | Cloudflare DNSSEC（自动向注册商推送DS）、AWS Route 53、Azure DNS、Google Cloud DNS 等 | 平台托管（其HSM/密钥体系） | 多为自动（取决于注册商API支持） |
; BIND 9.16+ dnssec-policy 示例（示意，策略值须按RFC 6781/7583测算）
options {
dnssec-validation auto; // 递归侧：自动信任锚
};
zone "example.com" {
type primary;
dnssec-policy standard; // 引用内置或自定义策略
inline-signing yes;
}; // named自动生成ZSK/KSK、定时重签并按RFC 7583窗口轮转说明：dnssec-policy为BIND 9.16+能力（ISC官方文档）；托管DNS签约能力以各服务商官方文档为准。选用托管方案时应评估其密钥保管的合规与审计条款。