摘要

  • IETF Datatracker 于 8 月 18 日批准 draft-ietf-dnssd-uld-00 成为 DNSSD 工作组文档，并确认它替代此前的个人草案；规范化后的技术正文没有变化。
  • ULD 将 SRP 注册、权威 DNS 和两个代理组合在一台首选链路内服务器上，目标是减少终端参与 mDNS 的成本，但安全章节目前仍只有 TODO。

这次更新最值得关注的不是新增了什么报文，而是谁开始对后续文本负责。

工作组草案历史显示，8 月 18 日 16:22:50 UTC，DNSSD 主席批准工作组 -00，新版本同时上线，并被记录为 draft-tlmk-infra-dnssd 的替代文档。去掉文档名、日期、到期日、仓库地址和页眉后，新旧正文哈希完全相同。因此，新闻边界是工作组正式接手，而不是协议机制在当天发生改变。

这项决定还有一段公开的程序修正。前身草案历史记载，主席曾在 IETF 126 现场举手示意后把草案标为已采用，随后承认应先在邮件列表发起采用征询，于是撤回状态并重新走程序。7 月 21 日征询发出，8 月 6 日正式变为“Adopted by a WG”。这个记录证明程序可以被复核和纠正，但不能被解释成所有技术异议都已解决。

ULD 工作草案针对的是局域网里一个常见却不显眼的成本。mDNS 让发布服务的每台设备监听并回答组播查询。在 Wi-Fi 上，组播帧在 MAC 层没有确认和重传，接入点也不会替睡眠终端缓存这些帧，而且通常使用较低的强制速率发送。电池设备要么频繁醒来，要么承担漏掉查询的风险；少量组播也可能占据不成比例的无线时隙。

ULD 的做法是把日常工作汇集到一台持续在线的服务器。这台服务器组合 SRP registrar、权威 DNS、Discovery Proxy 和 Advertising Proxy。支持 ULD 的客户端向服务器注册服务，通过单播查询 .local，并在服务器可用时停止自己在该链路上的日常 mDNS 参与。服务器继续与只支持 mDNS 的设备互通，使应用仍能使用熟悉的本地域名空间。

其中两块能力已经有正式规范。RFC 9665规定 Service Registration Protocol，包括带租期的服务注册。RFC 8766规定如何用从 mDNS 链路获得的信息回答单播 DNS 查询。ULD 所增加的是部署组合：服务器如何被发现、优先级如何确定、客户端何时迁移，以及兼容路径如何保留。

它并不淘汰 RFC 6762定义的 Multicast DNS。草案只说若获批准将更新该 RFC。ULD 服务器仍通过 mDNS 上的 DNS-SD 宣告自己，仍为旧设备做代理，客户端找不到可用服务器时也必须回退到 mDNS。改变的是有服务器时由谁承担常规发现，而不是立即关闭组播。

真正的控制面在服务器选择规则里。在受管理网络中，运营者必须明确配置哪台设备拥有基础设施服务器身份；同一链路最多只能有一台设备在 Router Advertisement 中宣告 ULD 选项。基础设施服务器优先级最高，其他设备可以较低优先级提供临时服务。客户端不仅要选一次，还要持续监测、寻找更优服务器，并在迁移时重新注册全部服务。

向单一首选服务器收敛，是为了解决名字冲突。若两个客户端向不同服务器注册同一个名字，两边可能都先接受，冲突到 mDNS 层才暴露，而且注册方未必能获得正确反馈。草案没有要求服务器之间复制所有注册状态，而是要求客户端用确定性规则选择同一个服务器。这样减少了一类分布式冲突，却增加了选择、故障检测和状态迁移的责任。

IPv6 客户端还要处理一种新的权威信号。基础设施服务器通过 RA 选项表明身份，客户端应以此发现服务器，或验证从 DNS-SD 获得的宣告，使 RA Guard 能保护这一角色。仅支持 IPv4 的客户端没有这条验证路径，只能通过 mDNS 查找服务器；服务器处理 .local 请求前则必须确认 IPv4 来源属于直连子网。

目前文本并不足以证明这套权威模型安全可靠。Security Considerations 章节只有 TODO，SNAC router 部分也未完成，IANA 服务名仍是占位符。公开材料没有给出独立实现、互操作测试、无线时隙、电池消耗、查询丢失或服务器切换时间的结果。草案本身也明确属于可能被修改、替代或放弃的 Internet-Draft，而非 RFC。

DNSSD 工作组章程说明了长期背景：mDNS 和 DNS-SD 已广泛用于家庭、园区和企业，但链路本地组播无法自然扩展到路由和多链路环境；发现范围扩大又会带来安全和隐私问题。ULD 先把范围放在本链路，但首选服务器仍可能决定客户端看见哪些服务，因此安全分析不能只是发布前补上的形式章节。

工作组状态意味着这项方案进入了可持续、可追踪的公开开发阶段。它并不意味着设备厂商已经采用，也不意味着 Wi-Fi 收益已经出现。眼下能够确认的结论只有一个：IETF 正式推进用本地单播服务器承接部分发现流量，同时服务器集中带来的控制和故障问题仍需用文本、实现和测量回答。

来源