DNS‑AID vs ANS：AI 代理身份与发现的两项新开放标准

Infoblox 和 GoDaddy 认为，如果没有开放标准，AI 代理生态很可能被少数平台控制——这些平台将决定哪些代理能被发现、哪些身份可信 。

因此，两家公司提出基于 DNS 的开放架构，其中包括两个不同但互补的组成部分：

• DNS‑AID（DNS for AI Discovery）：AI 代理发现层
• ANS（Agent Name Service）：AI 代理身份与信任层

简单来说，它们帮助系统回答三个关键问题：

• 这个代理是谁？
• 它能做什么？
• 是否可信？

DNS‑AID：让 AI 代理可以被发现

由 Infoblox 推动的 DNS‑AID 主要解决“发现（discovery）”问题。

该提案定义了一种结构化的 DNS 命名空间和记录模型，使组织可以在自己的域名系统中发布 AI 代理的相关元数据，例如：

• 代理接口地址
• 支持的协议
• 功能或能力描述

这些信息会存储在域名对应的 DNS 记录中。其他系统只需要查询 DNS，就能获得与该代理交互所需的信息 。

DNS‑AID 的目标包括：

• 在互联网范围内实现 AI 代理的可扩展发现
• 标准化代理之间的元数据交换
• 在没有中心化目录的情况下实现互操作

由于 DNS 本身就是互联网最成熟、全球分布式的命名系统之一，它被认为是实现大规模代理发现的自然基础设施 。

ANS：为 AI 代理建立身份与信任

如果说 DNS‑AID 解决的是“如何找到代理”，那么 ANS（Agent Name Service） 解决的是 “如何验证代理是谁”。

ANS 的核心思想是：把 AI 代理的身份 绑定到一个组织拥有的域名。

在该体系中：

• 组织首先证明自己拥有某个域名
• 代理身份通过加密证书与该域名绑定
• 其他系统在交互前可以验证这条身份信任链

ANS 草案将其描述为一种 “以域名为锚点的 AI 代理信任层”，特别适用于代理跨组织协作的场景，因为此时没有单一平台能够提供统一的信任体系 。

为什么选择 DNS 作为基础

这两个标准都刻意建立在 DNS（域名系统） 之上，而不是重新创建一个新的命名或注册系统。

原因在于 DNS 已经具备多项关键能力：

• 全球统一的分层命名体系
• 去中心化治理结构
• 几乎所有互联网系统都已部署
• 支持安全扩展（如 DNSSEC）

更重要的是，DNS 与 域名所有权 紧密相关。

例如，如果一家公司拥有 example.com，它就可以在该域名下发布 AI 代理相关记录。其他系统只要查询 DNS，就能验证代理是否属于该公司 。

这种模式与今天互联网中的许多安全机制类似，例如：

• HTTPS/TLS 证书
• 电子邮件身份验证（SPF、DKIM、DMARC）
• 服务发现机制

因此，把 AI 代理身份绑定到域名，被认为是互联网原生且可扩展的方案。

为什么通过 IETF 推进

DNS‑AID 和 ANS 目前都作为 IETF（互联网工程任务组）互联网草案推进。

IETF 是负责制定许多互联网基础协议标准的组织，例如 TCP/IP、HTTP 和 DNS 本身。

所谓 Internet‑Draft（互联网草案）意味着：

• 规范仍在早期讨论阶段
• 任何企业或研究机构都可以参与评审
• 协议可能在过程中被修改

通过 IETF 推进有几个重要意义：

• 技术规范完全公开
• 多家厂商可以实现兼容系统
• 基础设施不会被某个公司独占

不过需要注意的是，这些文档 目前仍是草案，并未成为正式互联网标准 。

避免 AI 代理生态被单一平台控制

推动这些标准的一个重要动机，是避免未来出现 单一平台控制 AI 代理生态 的情况。

如果代理的身份、发现和验证完全依赖某个平台的注册中心或市场，那么该平台实际上可以决定：

• 哪些代理可以被发现
• 哪些代理被认为可信
• 代理之间如何交互

而基于 DNS 的开放标准则提供了另一种模式：

任何拥有域名的组织都可以 自行发布和验证自己的 AI 代理，就像今天部署网站一样。

这种方式将权力从平台运营商转移到 域名所有权与开放协议，有助于保持互联网生态的互操作性与开放性 。

接下来可能发生什么

DNS‑AID 和 ANS 代表的是为未来 “代理互联网” 打基础的一部分。

如果这些标准最终被广泛采用，它们可能成为更大技术栈中的组成部分，例如：

• 代理之间的通信协议
• 信任与身份验证系统
• 访问控制与安全策略

但目前来看，这些方案仍处于实验性阶段。它们是否能成为真正的互联网标准，很大程度上取决于云厂商、AI 平台和互联网基础设施公司的实际采用情况。