The Linux Foundation now hosts DNS-AID.
This project aims to use DNS as a decentralized directory for AI agents. It originated at the American company Infoblox.
DNS-AID (DNS AI Discovery) is the subject of an IETF draft. In its first version, published in October 2025, it was still called BANDAID (Brokered Agent Network for DNS AI Discovery). The foundations were laid nonetheless: the goal was to define a model for leveraging namespace spaces and DNS records—SVCB, initially—for the exchange of metadata and the declaration of capabilities.
This initial draft had four signatories, from Infoblox, Deutsche Telekom, and the IEEE. In the latest version, dated May 27, 2026, a fifth signatory from Amazon was added.
Two discovery mechanisms, from the zero trust by default
Although not officially a member of the Linux Foundation–hosted project, Amazon contributes to the development of the reference implementation of DNS-AID. Its GitHub repository has been open since January. The three designated maintainers work at Infoblox.
This implementation follows two discovery scenarios: one in which both the organization and the agent providing a given capability are known; the other where only the organization is known. In either case, once a client has learned about the agents, all transactions can leverage the first scenario, thanks to caching of connectivity information or learning through a skill.
Discovery can be performed either purely via DNS (the default) or through an HTTP index.
The DNS approach works when the target domain is known. It has the advantage of operating with an in-memory list (upon which Python predicates are applied) and of incorporating JWS and DNSSEC verifications. Its major steps are:
- Query the index of agents and the protocols associated with them
- For each agent, query the SVCB record
- If a capability file URI is present, fetch that file (JSON)
- Otherwise, retrieve capabilities from a TXT record
The second option uses a local JSON index stored in the .well-known directory. The truth source is then a back-end directory. It is suitable when the target domain is unknown, or when one wishes to leverage inter-domain signals (security scores, trust metrics, popularity indicators, etc.) that DNS alone cannot provide.
Aside from Infoblox UDDI and NIOS, DNS-AID can leverage CloudFlare, AWS Route 53, Google Cloud DNS, IBM Cloud DNS… and any server compliant with RFC 2136.
The integration with agent frameworks can be achieved via the Python library or via MCP (publication and discovery of agents, DNSSEC and DANE validation).
DNS-AID is not alone in the field
Decentralized by design, DNS-AID distinguishes itself from initiatives such as GoDaddy’s ANS. Compared with the Google A2A + UDP pair, it benefits from a universal discovery mechanism (not limited to Google). And it does not entail domain fees, unlike the ICANN–driven gTLD .agent under consideration. As for the ai.txt and llm.txt options, they do not provide integrity verification.
A handful of features have been built into the reference implementation, listed in the order in which they were added:
- Management of A2A maps
- Diagnostic API and MCP server
- Establishment of the capability verification chain (JSON document → A2A map → HTTP index → TXT record)
- Compilation of JSON policy documents into RPZ
- Integration with Infoblox Threat Defense for DNS-level access control (blocked domains incorporated into named lists and linked to security policies)
- Default streamable HTTP on the MCP client of the SDK (instead of JSON-RPC POST)
- Completion of the OpenTelemetry integration
