摘要

  • Changshan Su 的 IETF 个人草案提出用本地 DNS-SD 记录寻找 AI 网关，并描述网关路径和所宣告的能力。
  • 草案把发现的服务称为“候选端点”：先确认信任，再发送请求或凭证。

笔记本电脑找到一台打印机，不必先开一场宪法会议。AI 客户端找到网关时，面对的问题贵得多：谁有权接收下一次请求所用的 API 密钥？

2026 年 10 月 26 日，Changshan Su 提交了《DNS-Based Service Discovery for AI Gateways》版本 00。这是一份个人 Internet-Draft；Datatracker 将其列为个人提案，没有 RFC 流程，也没有预定的 RFC 状态。_ai-gateway._tcp 是草案提出的服务名，文档说明它尚未获得 IANA 分配。

底层机制并不新。DNS-Based Service Discovery 用 PTR 记录列出服务实例，用 SRV 记录给出目标主机和 TCP 端口，用 TXT 记录放服务自己的短信息，再由 A 或 AAAA 记录给出主机地址。Su 为 AI 网关提议一组紧凑字段，描述挂载路径、传输安全、认证要求和所支持的协议。客户端可以据此知道一台机器宣称提供什么，而不用把某个固定地址写进配置。

记录空间被刻意压小：草案希望默认 TXT 载荷少于 200 字节，整条记录不得超过 400 字节。广播者能写下名字、端口、路径和几项自述。它装不下一部宪法；多塞几个字节也不会替它取得裁决权。

文件里最关键的词是“候选端点”。客户端已经解析了服务记录，但还没有信任这台机器，也没有批准它接收凭证。草案的顺序是浏览、解析、验证、连接、确认信任，然后才发请求。查询模型目录是可选步骤。API 密钥不能放进 TXT 记录。

这个顺序有现实理由：本地网络允许设备广播自己的存在，却不是裁判席，不能替用户决定谁可以花掉他的秘密。草案的安全章节指出，同一网络段上的参与者可以伪造 mDNS 广播、声称 auth=0，或把 SRV 指向自己控制的主机。记录里的 id 不是身份证。客户端应依靠用户确认、预先配置的信任规则，或经过验证的 TLS 服务器身份。除非用户或管理员明确批准可信本地环境，否则可重复使用的 API 密钥不得通过明文 HTTP 或 WebSocket 传输。新的明文广播也不得把已经通过 HTTPS 或 WSS 信任的网关降级。

RFC 6763 给 DNS-SD 的工作很明确：发现带名称的服务实例。RFC 6762 描述本地链路上的 mDNS，并说明名称冲突处理假定参与者愿意合作。这些机制都没有把“被发现的机器”变成有权消费客户端凭证的主体。门铃可以说“网关在这里”；钥匙的主人仍要决定开不开门。

因此，真正有用的是把三步分开。发现负责定位。TLS 身份帮助确认响应的是哪台服务器。客户端的信任规则决定这台服务器能否收到凭证。如果把三者压成一个绿色的“已找到”，目录条目就被偷换成了通行证。草案把额外的信任决定留给用户或管理员明确设定。

目前可见的是一份规范文本，不是现场报告：Datatracker 上只有一份个人 -00 草案。来源中没有互通测试、实现比较或部署数量；要判断实际采用情况，需要一份一手测试报告。眼下值得盯住的是这三项决定之间的接口。客户端弹出批准窗口时，应该明示用户正在批准的主机、端口、路径、TLS 状态和认证声明。“找到 AI 网关”是搜索结果；“允许它用我的密钥”是授权决定。

来源