DNS-AID 是 Agent SEO 里比较值得关注的一条线，因为它把 discovery 从页面请求之前，前移到了 DNS 层。
但这并不意味着它应该成为所有站点的优先事项。
截至 2026 年 7 月 13 日，DNS-AID 仍然是 Internet-Draft，而不是一个被广泛实现的 Web 标准。当前版本 draft-mozleywilliams-dnsop-dnsaid-02 发布于 2026 年 5 月 27 日，描述的是发布方如何通过 DNS SVCB 记录和 well-known endpoint，让兼容客户端在请求页面之前更早发现 agent capability。
对大多数网站来说，这意味着 DNS-AID 更适合作为可选 discovery 基础设施，而不是替代 Technical SEO、robots.txt、Sitemap Checker 或 Link Headers for AI Agents 的核心做法。
这篇文章是对 DNS-AID wiki 词条、Agent SEO audit 以及 API Catalog SEO 与 MCP Server Card 这类 discovery 层的实操补充。
当前 DNS-AID 到底指什么
当前 IETF 草案主要覆盖两类 discovery 场景：
| Discovery 场景 | 客户端已知什么 | DNS-AID 帮它找到什么 |
|---|---|---|
| 已知具体 agent | 已知 agent hostname | 该 agent 的连接信息与元数据入口 |
| 已知组织域名 | 已知 organization domain | 组织级 agent index，帮助客户端挑选可用 agent |
实际流程通常是：
- 先查 DNS 里的 SVCB 记录。
- 读出 target host、protocol suite、port 和 metadata pointer。
- 再去抓对应的 HTTP 资源，例如 agent card 或 capability document。
- 最后验证 HTTP 资源、TLS endpoint 与发布的 capability 是否一致。
所以，DNS-AID 最适合被理解为 discovery 加速层。它可以让兼容客户端更快找到真实资源，但并不会减少你维护这些资源本身的责任。
什么情况下值得测试 DNS-AID
上 roadmap 之前，先做这个 fit check：
| 站点类型 | DNS-AID 适配度 | 更应该先做什么 |
|---|---|---|
| 纯营销站或文章站 | 低 | 先把 crawlability、sitemap、内链和内容质量做好 |
| 没有公开工具的文档站 | 低到中 | 先补 Link Headers for AI Agents 与可读文档 |
| 有真实 agent endpoint 或公开 API 的产品站 | 中到高 | 先把 API 文档、Auth.md 与 OAuth Metadata 和 discovery 页面维护准确 |
| 多 agent 或合作伙伴平台 | 高，但运维要求高 | 把 DNS-AID 当成更大 capability discovery 体系中的一层 |
如果你没有稳定的 agent endpoint、持续维护的 capability document，以及能负责 DNS 运维的人，DNS-AID 很可能还太早。
先把 HTTP Discovery 做好，再谈 DNS
DNS-AID 应该只指向真实、已上线、已维护的资源。建议先把这些层做好：
| 资源 | 为什么要先存在 |
|---|---|
robots.txt | 让 crawler 在 agent-specific 层之前先知道访问规则 |
sitemap.xml | 给常规 discovery 提供 canonical URL 覆盖 |
| HTTP Link headers | 直接在真实页面响应里暴露相关资源 |
| 公共文档或 audit hub | 为人类和 agent 提供可见的解释层 |
| API catalog、agent card 或 capability page | 作为 DNS 记录真正要指向的机器可读目标 |
这一步骤顺序很重要，因为 Google 当前的 AI optimization guide 仍然围绕有用内容、crawlability 和常规搜索基础，不会因为你加了 DNS-AID 就跳过这些要求。
一个务实的上线流程
1. 先选一个公开、低风险的 endpoint
从真正属于公开产品面的 endpoint 开始：
- A2A agent card；
- 有认证要求但有公开文档的 capability hub；
- 有真实 API Catalog 的公开 API；
- 会链接到维护中文档的 agent-readiness 页面。
不要从私有管理工具、不稳定实验项目或隐藏内部服务开始。
2. 先发布一条 agent SVCB 记录
草案使用 SVCB 记录承载连接信息和元数据入口。一个示意记录可以长这样：
agent-name.example.com. 3600 IN SVCB 1 resource.example.net. (
alpn="a2a,h2"
port=443
well-known="/.well-known/agent-card.json"
)
它表达的是：兼容客户端应按声明的 protocol suite 连接 resource.example.net，并在那里抓取对应的 metadata path。
如果你支持多个 agent protocol，请为每个 protocol suite 分开发布 SVCB 记录，不要把多个不相关的 agent protocol 塞进同一个 alpn 值里。
3. 只有能维护时，再加 organization index
草案还定义了 _index._agents.{domain} 这个组织级 well-known lookup。
示意例子：
_index._agents.example.com. 3600 IN SVCB 1 agent-index.example.com (
alpn="h2"
port=443
)
只有在 index 背后真的有可用、可维护、能帮助客户端从多个 published agents 中做选择的 registry 时，这层才有价值。如果你目前只有一个试验性 endpoint，就先不要加 index。
4. 开启 DNSSEC，并保持 DNS 里只有公开信息
草案把 DNSSEC 和 endpoint authentication 当成重要的信任层。落实到运维上，就是：
- 在你的平台支持时启用 DNSSEC；
- 不要把 secret 或 private endpoint 放进 DNS；
- 确保 target hostname 的 TLS 正常；
- 保持 DNS target 与 HTTP metadata 同步。
Cloudflare 的 DNSSEC 文档也提醒了同一个现实：DNS 响应是信任链的一部分，不只是命名便利。
5. 验证整条链，而不是只看记录存在
先验证 DNS：
dig agent-name.example.com SVCB
dig _index._agents.example.com SVCB
再验证引用到的 HTTP 资源：
curl -I https://resource.example.net/.well-known/agent-card.json
curl -I https://example.com/.well-known/api-catalog
curl -I https://example.com/
最后再用 Bot Simulator、Agent SEO audit 和常规 Technical SEO 检查整个公开站点体验。DNS-AID 本身正确，不代表页面公开面一定足够强。
上线前检查清单
在把 DNS-AID 叫做 ready 之前，至少确认这些：
| 检查项 | 通过条件 |
|---|---|
| 记录可解析 | 预期 SVCB RRset 可被公开查询 |
| Target host 正常 | 返回的 target hostname 可解析且 TLS 正常 |
| Metadata path 正常 | well-known 或链接资源返回 200 |
| Capability 数据是最新的 | 发布的 card、catalog 或 docs 与 live service 一致 |
| HTTP discovery 一致 | Link headers、docs 与 DNS 指向同一组资源 |
| Auth 已文档化 | 受保护流程有准确的 Auth.md 与 OAuth Metadata 或等效说明 |
| 没有过度承诺 | 公共文案没有承诺排名、引用或 guaranteed agent support |
常见错误
这些情况应避免：
- DNS 记录先发了，但 HTTP 资源还不稳定；
- 站点没有真实 agent capability，却把 DNS-AID 用在纯内容站上；
- 指向私有或无人维护的 hosted service；
- 在要求客户端信任记录链时，却忽略 DNSSEC 或证书卫生；
- 把 DNS 记录当成 capability 安全、授权或 production-ready 的证明；
- 暗示 Google 会把 DNS-AID 当作 ranking signal 或 AI citation signal。
只有当它真的减少兼容客户端的 discovery 歧义时，这个模式才有意义。反过来，如果它制造更多歧义，就应该删掉。
Fennec 用户下一步该做什么
如果你的站点已经有真实 agent endpoint，建议顺序是：
- 先用 Technical SEO、robots.txt 和 Sitemap Checker 验证基础层。
- 复核 Link Headers for AI Agents 与任何真实存在的 API Catalog。
- 确认 capability 和 auth 文档公开、最新、表述保守。
- 只为一个已维护 endpoint 增加一条 DNS-AID 记录。
- 再用 Bot Simulator 和 Agent SEO audit 验证整条链。
如果你的站点目前仍以内容页和营销页为主，就先把 DNS-AID 放在 watch list，优先改善更基础的 discovery 层。
参考资料
- IETF Internet-Draft: DNS for AI Discovery (draft-mozleywilliams-dnsop-dnsaid-02)
- RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- RFC 8552: Scoped Interpretation of DNS Resource Records through “Underscored” Naming of Attribute Leaves
- RFC 8615: Well-Known Uniform Resource Identifiers (URIs)
- Cloudflare Docs: DNSSEC
- Google Search Central: AI optimization guide
问答
DNS-AID 会提升 Google 排名或 AI 引用吗？
不会。DNS-AID 是面向兼容 agent 的新兴 discovery 模式，不保证排名、收录、引用或 adoption。
纯内容网站需要做 DNS-AID 吗？
通常不需要。内容站应先把 crawlability、sitemap、内链和真正有用的机器可读资源做好。
测试 DNS-AID 之前，应该先发布什么？
先把常规 HTTP discovery 层上线：robots.txt、sitemap.xml、相关 Link headers、稳定文档，以及 DNS 记录要指向的真实 API 或 agent capability 资源。
