# DNS for AI Discovery DNS-AID [1 · Discover](/category/discover/) | DNS for AI Discovery | | --- | | Category | [Discover](/category/discover/) | | Governed by | IETF dnsop working group Internet-Draft (individual submission track, not yet WG-adopted) | | Status | Internet-Draft, Standards Track intended status | | Phase | draft | | Implementation | unknown | | Adoption | claimed — Infoblox and GoDaddy joint press release | | Version | draft-mozleywilliams-dnsop-dnsaid-02 (2026-05-27) | | Specification | [https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/](https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/) | | Found at | _index._agents. (SVCB); _agent-name. (SVCB) | | Acronym collisions | AID (Agent Identity and Discovery, a separate, unrelated agentcommunity.org spec that also does DNS-first discovery) | | Last checked | 2026-09-06 | [Discover](/category/discover/) DNS for AI Discovery (DNS-AID) standardizes publishing AI agents in the Domain Name System so other agents can discover them, using DNS Service Binding (SVCB) records for connectivity and key metadata, a well-known DNS-SD-style entry point (_index._agents.) into an organization's agent index, and optionally DNSSEC and DANE TLSA records for trust [[1]](#ref-1). It is an IETF Internet-Draft in the dnsop working group's area (individual submission, not yet WG-adopted), authored by engineers at Infoblox, Deutsche Telekom and Amazon, current revision -02 dated 27 May 2026 with intended status Standards Track [[1]](#ref-1). ## Overview It solves the "given a domain, where is the agent and which protocol does it speak" problem entirely within DNS, so that once a client has resolved an organization's agents once, subsequent lookups are cacheable and require no extra round trip beyond ordinary DNS resolution [[1]](#ref-1). The mechanism defines two record shapes: an SVCB record at an individual agent's owner name carrying TargetName, alpn, well-known (a well-known URI path per RFC 8615) and other SvcParamKeys, and an SVCB record at the fixed label _index._agents. pointing to an organization-wide index [[1]](#ref-1). A TXT-record fallback and a DNSSEC/DANE-authenticated TLSA companion record are both discussed but explicitly not the primary mechanism [[1]](#ref-1). The document introduces no new DNS resource record types, opcodes, or response codes -- it is a usage convention over existing SVCB/TXT/TLSA record types [[1]](#ref-1). DNS-AID does not itself define authentication or authorization beyond DANE-based TLS endpoint verification, does not define the schema of the capability descriptor referenced by well-known (that is out of scope), and use case 3 (discovery by capability alone, with neither organization nor agent known) is explicitly out of scope for this document, though the authors note it "can be derived" from the spec [[1]](#ref-1). Current state: as of 27 May 2026 this is a dnsop-area individual Internet-Draft, expiring 28 November 2026 unless refreshed [[1]](#ref-1). Infoblox and GoDaddy issued a joint press release on 14 May 2026 announcing support for "open standards for AI agent discovery, identity and verification" that names this effort [[2]](#ref-2), but that is a vendor-support announcement, not evidence of production deployments; no independent implementation count was found. Two other agentic-web specifications explicitly build on it: ADP (draft-pro-adp) delegates its entire DNS discovery layer to DNS-AID rather than duplicating it [[3]](#ref-3), and ARD's informative discussion of federated query resolution names DNS-AID as a way to "discover authoritative registries for specific domains" [[3]](#ref-3). What is disputed or unknown: whether DNS-AID's SVCB-based approach and the separately-authored AID specification's flat TXT-record approach (see aid) will converge, coexist, or one will win out -- no evidence of coordination between the two projects was found. Adoption is recorded as "claimed" (by the Infoblox/GoDaddy announcement) rather than measured, since no independent DNS probe of a domain sample was run for this record. ## Discovery and probe DNS SVCB records at the agent's owner name; DNS-SD-style well-known labels _agents/_index for an organization index; optional TXT fallback and DNSSEC/DANE TLSA for trust · _index._agents. (SVCB); _agent-name. (SVCB) ``` DNS SVCB query for _index._agents.{domain}, then SVCB query for the target agent owner name it returns parse: SVCB RRset present with alpn/well-known/cap SvcParamKeys; absence of TargetName error and presence of at least one SvcParamKey confirms an agent record on absent: Domain publishes no DNS-AID SVCB records; DNS-AID cannot be used to bootstrap discovery for this domain ``` Not probed live: not-http. DNS SVCB records; the HTTP well-known form is covered by the aid rule. ## History - 2026-09-05 — seeded from Exa Agent research run - 2026-09-06 — verified against draft-mozleywilliams-dnsop-dnsaid-02 spec text via datatracker.ietf.org ## Instances - [Infoblox / DNS-AID project (Linux Foundation)](https://www.linuxfoundation.org/press/linux-foundation-announces-dns-aid-project-to-advance-decentralized-ai-agent-discovery) · Observed 2026-05-27 · registry - [Infoblox / GoDaddy joint support announcement](https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx) · Observed 2026-05-14 · business - [Infoblox DNS-AID reference implementation](https://github.com/cherbst-IB/dns-aid-core) · Observed 2026-05-12 · service Every instance with its source is listed on the [instances page](/instances/). ## See also - Not to be confused with: AID (Agent Identity and Discovery, a separate, unrelated agentcommunity.org spec that also does DNS-first discovery) ## References - draft-mozleywilliams-dnsop-dnsaid-02 (27 May 2026, IETF dnsop, authors from Infoblox, Deutsche Telekom, Amazon) defines SVCB records at an agent's owner name plus a well-known DNS-SD-style _index._agents. organization index, with optional TXT fallback and DANE TLSA for endpoint authentication. — [https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/](https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid/) (2026-05-27) VERIFIED - Infoblox and GoDaddy jointly announced support for open standards for AI agent discovery, identity and verification, naming this DNS-based approach. — [https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx](https://aboutus.godaddy.net/newsroom/news-releases/press-release-details/2026/Infoblox-and-GoDaddy-Support-Open-Standards-for-AI-Agent-Discovery-Identity-and-Verification-2026-0acKMntvOC/default.aspx) (2026-05-14) REPORTED - ARD v0.91 itself names DNS-AID as a candidate mechanism for federated routing ("leveraging DNS-AID to discover authoritative registries for specific domains"), and ADP (draft-pro-adp) explicitly delegates its DNS layer to DNS-AID. — [https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md](https://raw.githubusercontent.com/ards-project/ard-spec/main/spec/ard.md) (2026-08-26) VERIFIED Disputed: Two IETF drafts now build on top of DNS-AID's SVCB mechanism (ADP explicitly, ARD's informative discussion) while a third, unrelated spec (AID, agentcommunity.org) independently chose the DNS TXT record at _agent. for the same job. The two are not compatible: DNS-AID uses SVCB records with a _agents/_index label structure; AID (agentcommunity) uses a flat TXT record. No evidence found that these projects coordinate. [JSON](/data/protocols/dns-aid.json) · [Markdown](/protocols/dns-aid/index.md)