课题研究 DNS解析安全 子课题02 · 第4页 / 共8页
02六大核心研究子课题 · DNSSEC部署与验证

密钥管理与轮换

DNSSEC的安全性在根本上取决于密钥的"可轮换、可撤销、可恢复"。本页系统梳理ZSK/KSK/CSK三类密钥的轮换类型、RFC 7583给出的安全时序模型、CDS/CDNSKEY(RFC 7344/8078)驱动的自动滚密钥机制、应急(密钥泄露)快速轮转剧本,以及轮转中易致全网解析中断的关键风险点。

密钥轮换ZSK/KSKRFC 7583CDS自动应急轮转研究状态:深度研究中
所属课题DNS解析安全 · 子课题02
聚焦轮转类型 / 时序模型 / 自动化
核心依据RFC 6781/7583/7344/8078/5011

01 · 为何需要轮换

长期不变的密钥会累积三类风险,使"定期轮换"成为DNSSEC运维的硬性要求:

  • 密钥寿命与算力演进:密码学强度随时间下降,需以轮换引入更长密钥/更强算法(RFC 9364路线图)。
  • 私钥泄露:一旦签名私钥泄露,攻击者可为任意记录伪造有效签名,必须快速轮换(应急轮转)。
  • 运营韧性:定期演练轮转,确保"真出事时能换";根KSK轮转(2018)即是对全生态轮换能力的一次压力测试。

ZSK与KSK的轮换频率差异:ZSK仅签普通数据、泄露影响限于本区且不影响父区DS,故可按RFC 6781相对高频(如按月/季)轮转;KSK被父区DS背书,轮转须同步父区,故低频(如按年)。这也是采用ZSK/KSK分离的核心理由——把"高频低风险"与"低频高影响"解耦。

02 · 轮转类型(RFC 6781)

RFC 6781定义了DNSSEC密钥轮转的基本方法,按"是否双签名/双DS重叠"区分:

类型方法适用
ZSK Pre-Publish
(预发布)
先将新ZSK发布(不立即签名),待全网缓存旧签名失效后,再切换新ZSK签名并撤销旧ZSK,全程新旧重叠。ZSK常规轮转,安全且平滑
ZSK Double-Signature新旧ZSK同时签署RRset一段时间,再撤旧。短重叠窗口的ZSK轮转
KSK Double-DS父区同时保留新旧DS(双DS),待验证器接纳新KSK后撤旧DS。KSK常规轮转(须父区配合)
CSK 轮转单一密钥同时是KSK与ZSK,轮转须走KSK路径(双DS)。单一密钥模型
算法轮转引入新算法(如从RSA迁移到ECDSA),须先升DS摘要再滚KSK,否则验证失败。算法升级(RFC 8624/9904)

原则:轮转全程须保证"任一时刻,验证器都能用至少一个可信密钥验证链",并以重叠期覆盖缓存与父区传播延迟。算法轮转尤其危险——RFC 8624/9904明确"升级DS算法须先于KSK轮转"。

03 · 安全时序模型(RFC 7583)

RFC 7583给出密钥轮转各阶段的"最小安全等待窗口",核心是等待各类TTL与缓存、父区传播、RFC 5011接纳延迟充分过期。关键命名间隔包括:

间隔(RFC 7583)含义对本课题的意义
Signature ValidityRRSIG的有效期长度(inception→expiration)。决定重签频率;轮转须覆盖至少一个完整有效期。
Publication Interval新密钥发布到开始使用之间的等待。确保旧缓存失效、新密钥被看见。
Registration Delay向父区提交/生效DS所需时间。KSK轮转的关键路径,常由注册商/注册局时效决定。
DNSKEY / DS TTL本区DNSKEY与父区DS记录的TTL。决定了"撤旧"前必须等待的缓存失效时间。
RFC 5011 hold-down自动接纳新信任锚前的持续观察期(RFC 5011 §4.2规定为30天)。根/关键KSK滚动必须预留此窗口,否则部分验证器不认新锚。

RFC 7583给出的是"下限公式"而非固定数字——实际秒数须结合本区各TTL与运营时效计算。本课题不替读者代算具体值,仅强调"按RFC 7583逐间隔求和得到安全轮转总时长"。

KSK/ZSK 轮转的阶段时序(重叠与等待)
各阶段以TTL与父区传播为界,确保任一时刻链可验证
说明:ZSK轮转不涉及父区DS(由KSK背书),阶段更短;KSK/算法轮转须走双DS并等待RFC 5011接纳(≈30天)。

3.1 轮转方法的选择细节

  • 为什么ZSK推荐Pre-Publish而非Double-Signature:Double-Signature要求全量RRset被两把ZSK同时签名,应答需携带双份RRSIG(显著放大应答体积,触发分片风险);Pre-Publish只多发布一把待命DNSKEY,应答体积基本不变,故RFC 6781 §4.1.1将Pre-Publish列为ZSK轮转推荐方法。
  • KSK为什么只能走Double-DS:KSK只签DNSKEY RRset,无法对"两把KSK的DNSKEY RRset双签"完成平滑过渡——因为父区DS一次只能指向一把KSK的摘要。过渡的正确形式是父区同时挂新旧两把DS(Double-DS),验证器分别信任,过渡期结束再撤旧DS。
  • CSK轮转的注意事项:CSK兼具ZSK与KSK角色,轮转必须同时满足"DNSKEY双签重叠(ZSK面)"与"父区Double-DS(KSK面)"两个条件,实际复杂度不低于分离模型,故大型运营仍推荐ZSK/KSK分离。

04 · CDS / CDNSKEY 自动滚密钥(RFC 7344 / 8078)

CDS/CDNSKEY机制把"父区DS维护"从人工操作变为子区自驱动:子区在自身区发布CDS(期望的DS)与CDNSKEY(对应的DNSKEY),父区自动化系统定期读取并据此增删改DS。配合RFC 8078的语义,可实现:

  • 常规KSK轮转:新KSK就绪后发布新CDS,父区自动加入新DS(双DS),待接纳后子区再撤旧CDS,父区随之撤旧DS。
  • 撤销签名(去DNSSEC):发布digest type 0的CDS("this registry",RFC 8078),父区据此摘除DS并摘链——这是"安全撤销"而非粗暴删除。
  • 降低人为错误:人工提交DS是Bogus的首要诱因之一;自动化使DS与DNSKEY始终一致。

先决条件:CDS/CDNSKEY自动同步依赖注册局/注册商支持自动采纳。当前越来越多主流注册局已支持,但仍有部分需人工确认;本课题建议优先选择支持CDS自动化的注册商,并把"是否支持CDS"作为DNSSEC可运维性的选型硬指标。

05 · 应急(Emergency)轮转

当私钥泄露或算法被宣布不安全时,须以最小延迟完成轮转,RFC 6781将此类称为"应急轮转(Emergency Rollover)":

  • ZSK应急:立即用新ZSK重签全区的RRset并发布新ZSK(无需长预发布),待旧RRSIG失效即可;对父区DS无影响。
  • KSK/CSK应急:须立即发布新KSK并提交父区新DS(双DS),但因RFC 5011接纳需≈30天,旧KSK在接纳完成前不可撤,否则部分验证器将失去信任锚导致全网解析失败。
  • 缓解:提前部署多个受信KSK、使用HSM隔离私钥、建立"演练过"的应急剧本,把MTTR压到最低。

应急的最大陷阱:在RFC 5011接纳窗口未到期前撤除旧KSK/旧DS,会使仍只认旧锚的验证器立即把整个区判为Bogus。根KSK 2018轮转中,旧锚直到2019-01-11才被撤销,正是为避免此类中断。应急≠可跳过安全等待窗口。

06 · 常规 KSK 轮转剧本(分阶段)

阶段动作等待/校验
P1生成新KSK,发布入本区DNSKEY RRset(双KSK)。—
P2通过CDS或人工提交,使父区发布新DS(双DS)。等Registration Delay与DS TTL。
P3用新KSK重签DNSKEY RRset(双KSK签名);等待RFC 5011接纳(≈30天)。确认验证器已认新锚。
P4撤销旧KSK的签名与旧DS(发布旧DS的CDS删除 / 撤旧DS)。等DNSKEY/DS TTL与旧RRSIG失效。
P5轮转完成;归档旧密钥(留作回滚备用一段时间)。监控验证仍为Secure。

ZSK轮转可省去P2/P3的父区DS与RFC 5011环节,频次更高、影响更小;CSK轮转按KSK路径执行。具体等待秒数依RFC 7583与本区TTL计算。

07 · 轮转关键风险点

  • 算法轮转顺序错误:未先升DS摘要就滚KSK,导致新KSK无对应DS → 全链Bogus(RFC 8624/9904明确禁止)。
  • RFC 5011窗口被压缩:撤旧锚早于接纳完成,依赖旧锚的验证器解析中断。
  • 父区DS不同步:人工环节遗漏或延迟,双DS未真正建立。
  • 签名有效期与轮转周期错配:RRSIG过快过期而重签/轮转滞后。
  • 缺少演练:仅在泄露时才首次轮转,易在压力下出错。

本节参考来源(第4页)

以下为真实可查的权威来源,支撑本页关于轮转类型、时序、CDS与应急的事实表述。

[1]

RFC 6781 — DNSSEC Operational Practices(轮转方法与应急轮转):rfc-editor.org/rfc/rfc6781

[2]

RFC 7583 — DNSSEC Key Rollover Timing Considerations(时序模型):rfc-editor.org/rfc/rfc7583

[3]

RFC 7344 — Automating DNSSEC Delegation Trust Maintenance(CDS/CDNSKEY):rfc-editor.org/rfc/rfc7344

[4]

RFC 8078 — Managing DS Records from the Parent via CDS/CDNSKEY:rfc-editor.org/rfc/rfc8078

[5]

RFC 5011 — Automated Updates of DNSSEC Trust Anchors(信任锚自动更新/30天接纳):rfc-editor.org/rfc/rfc5011

[6]

RFC 8624 / 9904 — 算法实现与选用指南(算法轮转顺序约束):rfc-editor.org/rfc/rfc8624

[7]

ICANN — Review of the 2018 DNSSEC KSK Rollover(根KSK轮转实践与时间窗):icann.org/.../review-2018-dnssec-ksk-rollover.pdf

[8]

ISC KB — Root KSK Rollover in BIND(RFC 5011 30天接纳与managed-keys):kb.isc.org/docs/aa-01525

‹ 上页:区域签名部署实战
子课题分页12345678
下页:验证体系与递归侧部署 ›