代表性面试主题

系统设计面试:如何设计可审计的 DNSSEC 密钥轮换控制平面?

系统设计困难
Offer.cc 编辑团队发布 更新

题干

你要为多租户 DNS 平台设计 DNSSEC 密钥轮换控制平面。如何保证 DS、DNSKEY、RRSIG 的时间顺序,支持故障恢复并留下可审计证据?

题目

为托管数万个签名区域的平台设计 DNSSEC 密钥轮换控制平面。它需要协调注册商的 DS、权威服务器的 DNSKEY/RRSIG,以及租户的变更审批;轮换期间不能让验证型解析器看到断裂信任链。

场景与约束

KSK 与 ZSK 生命周期不同,注册商 API 有延迟和重复请求风险,权威节点跨区域部署。控制平面必须支持幂等重试、暂停单个租户、审计每个状态转换,并在部分步骤失败时停止扩散。

核心考点

重点考察状态机、时间不变量、外部副作用编排和可观测性。答案应区分 DNSKEY 预发布、DS 发布、旧密钥撤回与签名覆盖窗口,不能把“生成新密钥”当成完成轮换。

参考解法

为每个区域建立持久化状态机:observeprepublishds-submitds-visiblesign-with-bothretire-oldverify。每一步记录期望版本、操作令牌、TTL 预算和证据快照。先把新 DNSKEY 发布到所有权威节点并等待其 TTL,再通过注册商提交 DS;确认父区 DS 在多个递归解析器可见后,保持新旧密钥同时签名一段安全窗口,最后撤回旧 DS 与旧 DNSKEY。

调度器按区域租约串行执行,外部调用使用幂等键和指数退避。任何验证器出现 SERVFAIL、DS/DNSKEY 不匹配或 RRSIG 过期,就冻结该区域,保留旧材料并触发人工审批。

关键细节

控制平面数据库保存期望状态,DNS 查询和注册商回读是事实来源;两者冲突时不能盲目覆盖。时间计算必须包含权威与递归缓存的 TTL、签名有效期和传播余量。密钥私料放在受控 KMS,日志只记录指纹、key tag、版本和操作者,不记录私钥。

常见误区

跨租户并行修改同一注册商对象;只检查权威节点而不检查父区 DS;轮换失败后立即删除旧密钥;把任务队列重试当成幂等;没有暂停和人工接管路径。

评估标准

高质量答案能画出控制平面、权威 DNS、注册商、递归验证器和审计存储的边界,写出至少三个安全不变量,并说明每个状态的进入、退出和回滚条件。还应给出成功率、SERVFAIL、传播延迟和卡住租约等指标。

追问

为什么 DS 发布通常要晚于 DNSKEY 预发布?

预发布让权威节点和缓存先拥有新 DNSKEY;父区 DS 随后指向它,验证器才会沿新链验证,减少 DS 已出现而 DNSKEY 尚不可见的窗口。

注册商返回超时但可能已经成功,如何重试?

用区域版本和请求幂等键查询注册商当前 DS,再决定重试;禁止根据单次超时直接提交第二个未知状态的变更。

什么时候允许自动撤回旧 DS?

只有新 DS 在目标递归解析器集合中持续可见、RRSIG 验证通过且 TTL 与签名窗口满足策略时,才允许自动进入撤回步骤,否则保持冻结。

公开来源

同类题目

相关面试工具

用 Solve 整理系统设计回答

从澄清需求开始,展开规模、架构、组件选择和取舍。

查看工具