DNS-AID

DNS-AID 是“通过 DNS 做 AI discovery”这一设想的非正式叫法。截至本次复查，它不是已采用的 IETF 标准、不是注册 DNS record type，也不是主要 AI 服务商公开要求的发现机制。

它还不是被广泛采用的 Web 标准。更适合把它理解为 agent readiness 模式，而不是确定的排名因子。

可能的工作方式

私有实验可以发布 DNS TXT 记录，声明 discovery endpoint：

_ai.example.com TXT "aid=https://example.com/.well-known/ai-discovery.json"

这个例子只用于说明思路；其中 _ai label 与 aid= key 并非注册约定。只有客户端也实现同一套私有约定时，记录才会产生效果。

设计约束

• TXT record 存在实际长度、引号与分片限制。
• DNS 按 TTL 缓存，策略修改不会立即生效。
• DNSSEC 可以验证 DNS 数据，但不会自动证明所链接 HTTPS 文档可信。
• DNS 内容公开，并可能进入 passive DNS 数据库。
• 多份 discovery 文档很容易漂移并产生矛盾指令。

SEO 建议

DNS-AID 只能作为辅助信号。如果采用，应和这些资源保持一致：

• robots.txt
• sitemap.xml
• llms.txt
• HTTP Link headers
• 公开 API 文档

不要把敏感 URL 或 secret 放进 DNS。DNS 是公开基础设施。

优先采用成熟发现方式

增加实验性 DNS 信号前，先保证网站与 API 的标准入口可用：

1. 为公开内容提供可抓取 HTML、robots.txt、sitemap、canonical URL 与清晰导航。
2. 只有在协议明确定义时才使用标准 well-known resource。
3. 只有已知消费者理解对应 relation 时，才用 HTTP Link header 宣告资源。
4. 对可调用 API 发布 OpenAPI 或正式协议 metadata。
5. 对任何 DNS 实验记录负责人、版本、TTL、回滚和消费者测试。

验收标准

DNS-AID 能解析并不等于可上线。必须指出真实消费客户端、保存成功发现 trace，并测试 DNSSEC、HTTPS、过期缓存与 endpoint 失败场景。如果没有真实客户端消费，它只是额外维护成本，不是 agent readiness 能力。

相关概念

• 面向 AI Agents 的 Link Headers
• Agent Skills Index
• API Catalog SEO
• llms.txt

官方资源

目前还没有被广泛接受的官方 DNS-AID 规范。稳定基础是：

• RFC 1035: Domain Names - Implementation and Specification
• RFC 8615: Well-Known URIs