摘要
draft-ietf-dnsop-delegation-mgmt-via-ddns-02提议让子域通过 SIG(0) 签名的 DNS UPDATE，把 NS、必要的胶水记录或 DS 的精确变更发给父区一侧由 DSYNC 指出的接收器。- 初次引导请求由新密钥自签。签名只能证明发送者持有对应私钥，不能证明这把密钥有权管理该子域。接收器必须先把它记为
known，完成另一次授权验证后才可升为trusted。 - 运营方应保存一份“权限转换记录”，连接旧密钥、引导方法、独立证据、政策判定、更新受理与父区实际发布。这是本文的治理建议，不是 DNSOP 的规范要求。
设想父区收到一条格式无误的消息：删除旧 KEY 集合，加入这把新公钥；为证明消息可靠，发送者又用新公钥对应的私钥签了名。验签通过，报文也没有被篡改。
但任何人都可以生成一对密钥，再用私钥签署“请信任这把公钥”。自签名证明的是对技术凭据的占有，不是域名持有人、当前 DNS 运营方或注册体系赋予的授权。若父区把两者当成同一件事，引导步骤便成了一个循环论证。
《通过 DDNS 自动管理 DNS 委派》第 02 版发布于 2026 年 6 月 17 日，目前是 DNSOP 工作组的活跃 Internet-Draft。它仍是可能修改、替换或过期的工作文件。渲染页眉写着 Standards Track，Datatracker 摘要的拟定 RFC 状态却为空。它不是 RFC，文件存在也不能证明任何注册局已经部署。
草案要解决的问题是真实的。子域改变权威名称服务器或 DNSSEC 材料后，父区可能仍保留旧的 NS、胶水或 DS。错误未必立刻造成整体中断：旧路径中只要还有一个可用，域名看起来便“正常”。实际冗余已经损失，下一次故障才会把隐患放大。
CDS、CSYNC 扫描器让父区周期性查看子域并验证其信号。新方案换了方向：子域最先知道自身配置发生变化，于是由它计算要增加、删除的记录，再发送安全 DNS UPDATE。父区用 DSYNC 声明是否接受这种机制、应送往哪个接收器及端口。扫描规模和发现延迟都可能下降，未签名子域也能参与。
它减少的是轮询成本，不是授权成本。
报文描述动作，政策决定谁能行动
与 NOTIFY 只提醒接收者“有东西变了”不同，UPDATE 带着发送者希望实施的具体差异。SIG(0) 保护整笔事务，使接收器可以依据已信任的公钥确认完整性与签名者对私钥的控制。
“已信任”是前提。草案明确指出，SIG(0) 所用签名原语可以与 DNSSEC 一样强，但信任模型不同。DNSSEC 通常沿签名链走向既定信任锚；这把 UPDATE 密钥则必须经过单独引导才被接收器接受。更强的算法无法替代“谁把权力交给它”的判断。
因此，UPDATE Receiver 不应是一条验签成功便直通父区主服务器的写入通道。它可以独立部署，也可以由父区或注册商等第三方运营；但它仍需限制允许变更的记录与名称范围，执行 CDS/CSYNC 所需的正确性检查，留下审计线索，并把获准请求交给父区实际的配置数据库或发布系统。
默认授权规则把密钥名称限制到具体子域。更新 child.parent. 时，签名密钥必须已经受信任，而且名称也必须准确等于 child.parent.。这样，一把被攻破的子域密钥不能改动另一个子域。若接收器允许注册商用一把密钥管理多数子域，它就必须另行证明每次请求针对该子域的授权；便利性也把风险扩大到一把共享凭据。
名称限制回答“能改哪个对象”，并不回答“这把密钥为何有权改”。
known 与 trusted 之间就是治理发生的位置
自签名引导报文到达后，接收器能确认新私钥确实存在于发送者手中。此时公钥可进入 known 状态。只有 DNSSEC 验证、多点观测或人工核验等被政策接受的步骤成功，它才升为 trusted。
这个中间状态保护着旧权力。引导请求虽然可能包含删除旧 KEY 集合的指令，接收器却不得在替代密钥验证通过前删除既有可信密钥。若验证失败，新密钥不能进入信任集合，旧密钥必须保留。
这条顺序阻止一种廉价攻击：攻击者提交自制密钥，要求先删旧钥；哪怕新钥最终未获批准，若删除即时生效，破坏已经完成。草案让未经授权的请求只成为待核验证据，而不能成为撤销命令。
界面和数据模型也要忠实呈现这种顺序。“已收到密钥”“正在验证”“验证失败”“已取得信任”“已被替换”不是同一个绿色状态。若系统只保留一栏当前 KEY，批准时覆盖掉候选记录，事后便无法解释哪项证据完成了权限转换。
不同引导方法证明的是不同主体
已签名子域可以在区顶点发布 SIG(0) 公钥，由父区通过 DNSSEC 链验证。子域本身未签名但至少一个权威名称服务器位于已签名区时，名称服务器运营方可以在自己的区内按专用名称重新发布该密钥。父区可验证这份发布，但过程依赖 DNS 服务商配合；草案只建议用另一个信号表达意图，没有规定服务商内部如何完成交接。
如果完全没有可用的签名链，unsigned 方法会在不同网络位置、不同时间，最好还通过不同传输方式，反复查询并比较 KEY。持续一致能提高临时中间人攻击的难度，却不能把权威服务器的当前控制者自动变成注册人。草案明确说，这条路径认证的是当时控制子域权威服务器的运营方，不是注册人，而且它是最弱的自动方法。
人工引导也被保留。它可能是一套已认证门户与注册资料核验，也可能只是邮件或表单。人工与自动不是强弱标签；真正决定强度的是核验谁、依据哪份权威记录、挑战如何绑定、账户如何恢复、例外由谁批准，以及证据保存多久。
所以父区应先定义准备授权的主体，再选择证明。DNS 服务运营方、域名注册人、注册商账户管理员和签名区控制者可能重合，也可能完全不同。一项正确证明不能悄悄替另一个主体背书。
“可选方法清单”也属于信任链
父区可以在 DSYNC 目标处发布 SVCB，并用 bootstrap 参数说明支持 at-apex、at-ns、unsigned 或 manual。子域据此选择可行路径，无须猜测父区流程。
清单本身却可能改变安全结果。若攻击者伪造未签名的 SVCB，隐藏较强方式，只留下 unsigned，即使后续多点检查全部通过，整个流程仍经历了降级。草案因此建议有 DNSSEC 的父区签署这条记录，并让子域优先选择自己能够满足的最强方式。
操作记录不能只写“最终采用 unsigned”。它还应保存当时公布的完整方法集、公告是否验证成功、子域有哪些能力、为何作出选择。否则，审核者只能看到被选考试的满分，却看不到考试题曾被人替换。
NOERROR 是受理回执，不是发布证明
一旦密钥获信任，接收器仍须检查更新的名称范围、记录类型、业务政策和正确性。返回 NOERROR 意味着 DNS UPDATE 已经收到并获接受，草案的措辞是：变更应当在未来某个时刻出现在父区。
这段时间差在迁移中十分重要。子域若在收到受理答复后立即撤掉旧服务器，而父区权威服务器尚未发布新 NS，原本正确的步骤也可能造成中断。DS 变更若被误判为已经生效，则可能出现 DNSSEC 验证失败。
至少应保留四个时间点：接收器知道密钥、接收器信任密钥、接收器受理更新、父区实际发布目标 RRset。BADKEY 可能说明密钥未知；密钥也可能已知但等待验证，或已明确失败；受信任请求仍可能被政策拒绝；受理请求仍可能滞留在配置系统。它们需要不同处置。
回复方向同样有密钥问题。父区需要验证子域，子域也需要验证 UPDATE Receiver 的响应密钥，才适合自动依赖密钥状态答复。父区未签名、又没有完成人工接收器密钥引导时，伪造答复可诱发不必要的重新引导。它不能直接让攻击者改写委派，却能制造拒绝服务和混乱。
留下一份权限转换记录
我建议每次初始引导和重新引导都生成一份受控访问的权限转换记录。这不是新增 DNS 记录，也不是草案规定的字段；它用来解释系统为何把 known 改成了 trusted。
记录首先固定父区、子域、DSYNC 回答及验证状态、接收器身份、软件与政策版本、旧可信密钥指纹、新候选密钥指纹、自签名请求摘要和签名时间窗口。所有对外公布的方法、子域可用能力、选择规则与最终方法都应在案。
证据部分明确被授权主体。DNSSEC 路径保存查询名称、签名链、验证器、时间与结果；unsigned 路径保存真正独立的观测点、时间、传输、完整答案指纹和一致性判定；人工路径引用认证会话、被核验的账户或注册权限、挑战、审批人、恢复与例外，但不把敏感个人资料公开。
决策部分逐项记录 known、验证开始、验证失败、trusted、替换与撤销，并证明新钥成功前旧钥未被删除。后续每条运行 UPDATE 再关联密钥、NS/胶水/DS 差异、检查结果、政策判定、答复及配置任务。最后，由独立观测写明目标记录何时真正出现在父区权威服务器。
DDNS 可以让委派更快收敛。要让它也更可信，就必须保留那道看似缓慢、实际上不可省略的转换：密钥可以自我介绍，权限不能自我授予。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance