摘要

  • RFC 9665 的先到先得命名把未占用名称绑定给第一把被接受的 SIG(0) 密钥；它证明后续更新来自同一持钥者，不证明其组织身份或业务授权。
  • 可辩护的运行证据必须从网络准入和注册器发现一路跟到权威节点、递归解析、端点认证与真实应用事务，不能把 NoError 当作终点。

一台设备第一次接入办公网络，登记了一个看起来属于财务部门的服务名。更新结构正确，SIG(0) 签名有效，名称此前无人占用，注册器于是接受。协议事实很清楚：这把钥匙先到了。

管理事实却仍然空白。设备可能是财务团队批准的，也可能只是能进入该网络的陌生终端；名字可能符合资产规范，也可能只是碰巧好听；服务可能安全可用，也可能在登记后根本没有监听端口。

RFC 9665 没有混淆这些问题。真正容易混淆的是运营报表。

第一把钥匙只赢得一个有限权利

Service Registration Protocol 把 DNS Update、DNS-SD、SIG(0) 和更新租约组合成自动登记流程。请求者生成设备唯一密钥，把公钥放进 KEY 记录，并用私钥签署更新。注册器在名称空闲时接受首次声明；只要 KEY 租约仍有效，其他密钥就不能修改同一主机名或服务实例名。

这是一种无需预共享秘密的连续性机制。它回答“现在的请求是否来自最初占名的密钥”，而不是“这把密钥是否属于某公司、某员工、某品牌或某项被批准的业务”。持钥证明也不会检查固件、端口、应用行为或用户交易。

设备应把密钥放在稳定存储中并长期保留。恢复出厂或所有权转移可以触发删钥换钥，但新钥匙不会自动继承旧名字。旧 KEY 租约未过期时，新设备要换名、等待或收到 YXDomain。所以密钥重置策略必须同时规定资产交接、命名后果、租约等待和支持流程。

一条原子更新包含多个层次

SRP Update 在一个 DNS Update 中带一份主机描述，以及零个或多个服务描述和服务发现指令。它不发送普通 RFC 2136 的显式先决条件；注册器依据 RFC 9665 隐式核对记录关系、同一公钥、SIG(0)、租约、冲突和消息形状，然后整体接受或整体拒绝。

原子性防止“主机有了、服务只写了一半”这类中间状态，却没有跨越发布链。接收更新的注册器可以是 hidden primary，并不直接回答用户查询。数据还要经过日志、签名、复制、次级权威或广告代理。每一个环节都有自己的状态和失败方式。

因此，NoError 是入站回执，不是公开可见回执。权威回答是 DNS 可见性回执，不是端点身份回执。端口握手成功也不是应用事务完成。现实层不能自动继承上一层的权威。

服务时钟和名称时钟故意不同

PTR、SRV、A、AAAA、TXT 等服务记录通常使用较短的普通租约，RFC 9665 给出的典型量级是两小时。KEY 记录的 KEY-LEASE 通常更长，典型量级是十四天。设备短时断线后，服务可从发现界面消失，但名字仍留给原持钥者。

“服务不存在、名称仍保留”是正确状态，不是冲突。若仪表盘只显示一个“已注册”，就会把设计意图误报成清理失败或可用性成功。证据需要保存请求与获批的两个时长、起点、续租、密钥指纹和到期结果。

TTL 又是第三只钟。租约到期后，权威端必须停止回答相应记录；但此前递归服务器取得的答案仍可在剩余 TTL 内出现。反过来，短 TTL 也不会缩短权威端的 KEY 所有权。调查时要分别查权威视图、缓存视图和实际服务。

注册器与请求者的认证方向并不对称

SIG(0) 让注册器验证请求者。基础规范没有给请求者规定一种自动验证注册器响应的机制。注册器必须支持 DNS-over-TLS，能力足够的请求者也应使用，但在没有可验证密钥分发的情况下，这只是机会式隐私，不能写成“注册器身份已认证”。

取证记录应说明注册器地址从哪里来：人工配置、域枚举、网络加入参数还是约束网络提供的列表；应记录 TLS 是否使用、证书或固定密钥是否实际验证、是否回退到明文 TCP。

准入也不是由签名独自完成。SRP 本身除 FCFS 外没有组织授权语义，所以注册器应限制管理域之外的源。TCP 依赖握手抵抗离路径伪造时，不能无条件接受 TCP Fast Open 负载；UDP 约束网络则依赖路由器的源地址和入接口过滤。

不要让“先到”占据组织门面

如果把 SRP 直接开放在组织顶级区域，自动请求者可能抢占 www、mail、smtp 等敏感名称。更安全的做法是使用专用发现子域，并维护禁用名称字典。子域不必好看，因为它的价值是限制权力，而不是营销。

普通 DNS Update 路径也可能破坏承诺。另一套凭据若能修改 SRP 创建的记录，就能绕过第一把密钥的所有权。两套授权应分离对象和区域，或明确优先级与审计规则。

service.arpa. 也不是全球信任标志。它由本地网络提供；使用外部递归解析器的设备可能看不到正确答案。其名称不应被当作可获得全球 PKI 身份的主机名。应用层仍要选择自己的端点认证方式。公开 KEY 还可能成为跟踪设备的稳定标识，隐藏它时必须兼顾 DNSSEC 一致性。

一份完整回执应长什么样

先记录网络加入、源接口、登记域、注册器发现方式、地址和传输；再保存原始更新、主机—服务关系、KEY 指纹、算法、签名结果、名称冲突、获批租约和响应。之后关联 hidden primary 日志、区域签名与复制、各权威节点回答、递归观察和剩余 TTL。

最后才是服务本身：端点身份如何验证，执行了什么无破坏性的应用事务，结果是什么。只有把这些事实用同一登记标识和时间窗连接起来，管理层才能知道“成功”到底停在哪一层。

来源