摘要

  • draft-ietf-dnssd-uld-00 让同一链路上的客户端收敛到一台首选 ULD 服务器；当首选项变化时，迁移中的客户端必须向新服务器重新注册自己的全部服务。
  • “选中了正确服务器”与“原有服务完整存续”是两项不同的证明。交接凭证应记录旧、新服务器，切换触发因素，预期清单，逐项注册与租约结果，代理两侧可见性，IPv4/IPv6 差异以及回退状态。

最容易漏掉的是局部成功

全面中断通常不难发现。DNS 查询连续超时，SRP 租约无法续期，DNS Push 会话断开，告警很快就会出现。更麻烦的是四项服务回来三项：网关在线，新服务器响应正常，大多数设备工作，只有一台打印机、一个房间控制器或一个 IPv4 终端看不到原来的条目。

这种状态不能用“服务器健康”解释。服务器可以健康，也可以按照规则成为首选，但它持有的目录仍不完整。

2026 年 8 月 18 日发布的 draft-ietf-dnssd-uld-00 是 IETF DNSSD 工作组的活跃草案。它提出 Unicast Local Discovery（ULD），让主机在本地链路上通过单播 SRP 和 DNS 注册、查找服务，同时与仍使用 mDNS 的设备互通。文档以 Standards Track 为目标，若获批准将更新 RFC 6762，但目前不是 RFC；安全考虑、SNAC 路由器处理和 IANA 服务名仍有待完成。

ULD 把五个逻辑部分放在一项服务中：SRP 注册器、权威 DNS 服务器、.local 区、从 mDNS 收集记录的 Discovery Proxy，以及把 SRP 区内容发布回 mDNS 的 Advertising Proxy。对于共享记录，服务器通常返回权威区与发现代理视图的并集；对唯一记录则可把 SRP 区视为完整来源。

这套组合保证了兼容路径，却也说明为什么一次成功查询不等于完整性。单播客户端、只使用 mDNS 的设备、IPv4 终端和 IPv6 终端可能从不同路径看到目录。只验证其中一条路径，无法证明服务已经在整条链路上恢复。

选举规则不搬运登记状态

每台 ULD 服务器用 DNS-SD 公布 pri 数值，数值越小越优先。草案把基础设施服务器设为 0，有线非受限临时服务器设为 100，Wi-Fi 非受限临时服务器设为 200，受限设备分配更高数值；优先级相同时，以数值更小的 IPv6 链路本地地址决定。

基础设施服务器还在 IPv6 Router Advertisement 中携带 ULD 选项。IPv6 客户端必须用该选项发现基础设施服务器，或核验先从 DNS-SD 得知的基础设施身份。草案提到使用 RA Guard 保护这项指定。

在受管网络里，网络运营者必须明确启用基础设施身份，并确保一条链路最多只有一台路由器发布 ULD RA 选项。在家庭等非受管网络中，已经承担实际网关职责的 CE 路由器可以默认认领这一身份；不是明确主网关的设备不得在没有显式配置时自行认领。

客户端先寻找基础设施服务器，找不到时再从临时服务器中选择；没有可用服务器便回退到 mDNS。一旦采用 ULD，客户端应停止在该链路上直接参与 mDNS，把 .local 操作交给所选服务器。

这不是一次性决定。查询持续失败、SRP 租约刷新失败或 DNS Push 会话丢失，都要求客户端重新开始发现。使用临时服务器的客户端还要持续寻找优先级更高的新候选。因此，旧服务器故障与新基础设施服务器出现，虽然原因不同，却会走向相同动作：迁移，并向新服务器重新注册全部服务。

草案附录 C 解释了为何选择客户端收敛。若多台独立 SRP 服务器各自接受相同名称，冲突可能直到 mDNS 层才暴露，甚至无法正确反馈给客户端。另一种办法是服务器间复制状态；ULD 00 没有选择它，而是假设每条链路最终有一台稳定的基础设施服务器，让所有客户端依照确定规则选中同一台。

一份已经过期的 SRP Replication 草案可以用作对照。复制方案希望在服务器消失时保存登记状态、降低冲突并减少客户端感知到的切换。它不是当前 ULD 机制的一部分。恰恰因为 ULD 把责任放回客户端，才需要单独证明客户端是否真的重放了完整状态。

“重新注册全部”还缺一个可核对对象

一条 SRP 更新被接受，只能证明该次更新成功，不能证明客户端把所有预期服务都送了过去。新服务器里有四条记录，也不能说明旧服务器原本应该有四条还是五条。一次浏览查询列出若干服务，更不能说明 Advertising Proxy 已经把相同内容正确暴露给 mDNS 设备。

交接首先应限定范围。ULD 每条链路分别维护实例和 .local 区；多宿主设备可能在一块接口上使用 ULD，在另一块接口上回退 mDNS。凭证要写明链路、接口、地址族和观测时段，而不是只给整个设备一个“迁移完成”标志。

随后记录选择过程：旧、新服务器的链路本地地址，公布的 pri，基础设施或临时身份，以及平局时使用的地址比较结果。切换原因也要明确区分：持续故障、租约刷新失败、Push 会话丢失、优先级更高的服务器出现，还是运维人员主动变更。

新服务器为何有资格成为基础设施同样需要出处。受管网络可以引用配置变更与批准记录；家庭网络可以记录其网关职责。是否观察到 ULD RA 选项、哪条 RA Guard 策略适用，也应写入。但这两项都不能被夸大为服务器认证。ULD 草案允许自签名证书，建议客户端不要拒绝，并明确说这里的 TLS 不以服务器认证为目标。

核心是交接前后的清单对账。客户端在迁移前为规范化的服务描述生成承诺值；迁移后逐项记录接受、拒绝、名称冲突、超时、租约期限与重试结果。新服务器可以给出相应的区域摘要。验证端分别查看单播结果、Discovery Proxy 的输入，以及 Advertising Proxy 在 mDNS 侧的输出。

双栈环境必须拆开观察。基础设施发现依赖 IPv6 RA，而 IPv4-only 客户端通过 mDNS 寻找服务器；若首选服务器无法通过 IPv4 到达，这类客户端还要回退 mDNS。只用一台双栈笔记本测试，无法代表全部客户端。

例外并非一律失败。设备在切换时主动撤下某项服务，可以是有意决定；发生冲突后改名，也可以是正确处置；IPv4 客户端回退 mDNS，可能完全符合草案。治理问题在于这些结果不能被隐藏在一个成功率里，必须注明“撤下、改名、等待、失败或回退”。

凭证不能变成本地生活档案

服务名称可能暴露房间、人名、设备型号与活动规律。为了连续性而永久集中保存完整 .local 清单，会把审计工具变成不必要的监控数据库。

更克制的方式是保存加盐摘要、按宽泛服务类型统计的数量和少量异常代码。完整比对集与盐只在客户端或受保护的运维域短期保留。长期记录保留交接编号、前后数量、差异、耗时和证明初始清单未被事后改写的密码学承诺即可。

保留期应覆盖租约和缓存更新周期，并容纳延迟上报的故障。调查窗口结束后，应删除不再必要的具体名称。凭证的目的，是解释一次服务器交接，不是重建用户的本地设备史。

现有证据支持到哪里

工作组草案明确规定了选择、持续监测与迁移后全量重注册，因此可以严谨地说：服务器收敛与服务连续性是两个步骤。草案没有规定本文提出的交接凭证，也没有提供多厂商互通数据、丢失比例或恢复时间。

RFC 7113 记录了 RA Guard 的实现局限；SRP 用公钥和 SIG(0) 保护登记控制权，却不提供跨两台服务器的整体清单证明。ULD 的权威回答只针对链路范围的 .local，不能被描述成公共 DNS 委派或全局名称权力。

判断完成的标准因此应非常具体：每项预期服务要么重新可见，要么被明确撤回，要么留下可核查的异常。服务器选对了，只是交接的开始；目录是否存续，才是交接的结论。

来源

  1. ULD 工作组草案
  2. ULD 文档历史
  3. 冻结版 00 HTML
  4. 冻结版 00 文本
  5. Datatracker 文档 API
  6. DNSSD ULD 工作仓库
  7. IETF 126 ULD 演示文稿
  8. DNSSD 工作组章程
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — RA Guard 实施建议
  17. RFC 4861 — IPv6 Neighbor Discovery
  18. Advertising Proxy 草案
  19. Time Since Received 草案
  20. 已过期 SRP Replication 草案