摘要

  • 10 月 28 日的 IETF 个人草案提出用 mDNS 与 DNS-SD 找到附近的 A2A 代理和 MCP 服务，再取详细描述或建立会话。
  • 同链路的任何主机都能广播一条候选记录。记录里的名称、指针与摘要由广播者填写；客户端须在后续连接中核验服务身份。

门牌可以自己挂

手机进了陌生办公室，想找会议室代理，不必先知道主机名。DNS-SD 搜出本地服务，给出主机、端口和少量描述，再去取得完整资料。这就是 Jakab 与 Brockners 的新版草案要解决的摩擦。七月版本主要画出本地 A2A 路径；十月版加入 MCP、通用参数与跨链路发现。它仍是个人提案，尚无 IETF 正式采纳。

但门牌并非管理员逐一钉上。草案的安全章节写得干脆：在共享链路上，任何主机都能发布服务实例，TXT 字段也由它自己填写。它可以仿照别人的展示名称，指定一个 desc-ref，再给描述配上 desc-ref-digest。新增的摘要看起来像印章，却只是发现描述变化的提示。广播本身未获认证，摘要也跟着广播者走；拿它证明描述真实，等于让报名者自己盖录取章。

草案把工作分成两关。第一关只找候选地址；第二关才取得 A2A 描述或发起 MCP 握手，并按相应协议核验服务端。问题常出在两关之间：客户端会把 SRV 主机和端口与路径提示拼成 URL。如果来源是未经认证的组播记录，这个地址就带着广播者的选择。客户端须先检查方案、地址段、端口、跳转、凭据与跨域请求，再验证 TLS 身份。地址栏自动补出 https，不会替服务器证明身份。

对 MCP 而言，真正诱人的不是一张门牌，而是连接后列出的工具、资源和提示。客户端若把“在局域网里找到”当成“可以使用”，一个自报名称的主机就能把自己的工具放到工作台上。代理或网关把广播传到更远处，扩大的只是听众。RFC 9665的先到先得注册规则能防止后来者抢占已注册名称，却无法说明第一个注册者是谁。

自动发现还把本地服务清单公开给同链路主机。协议子类型缩小搜索结果，不能让广播隐形。管理者要决定在哪些网段和接口广播、哪些可选字段可以出现；客户端要决定连接前如何核验。谁能挂门牌，谁能进门，必须是两份决定。

来源：十月草案、七月草案、IETF 状态记录、mDNS RFC 6762、DNS-SD RFC 6763、服务注册 RFC 9665。