Three days after the Linux Foundation launched a new open standard for AI agent discovery, the company that wrote the first line of its code shipped a production system built on it — and the gap that prompted the standard in the first place is suddenly visible to anyone running a multi-agent platform.

The standard is called DNS-AID (Domain Name System for AI Discovery). Its premise is that the internet already solved the problem of finding things at scale forty years ago with DNS — and that the same infrastructure should handle AI agents. On May 27, the Linux Foundation formally accepted DNS-AID as a project, backed by a founding coalition that includes Cloudflare, GoDaddy, Equinix, Internet Systems Consortium, and Infoblox, among others. On June 3, Infoblox launched Infoblox IQ, an agentic operations layer for enterprise networking and security teams that is the first major production system built directly on the DNS-AID standard and its companion Model Context Protocol (MCP) server specification.

AI Agents Cannot Yet Find Each Other Without a Registry or Hardcode

The problem DNS-AID targets is mundane in description and expensive in practice. Today, when one AI agent needs to locate and verify another, the answer is almost always either a hardcoded URL — a fixed address that breaks the moment anything moves — or a proprietary registry operated by a single platform vendor. Neither approach scales beyond the platform it was built for. A developer running agents across Google Cloud, Azure, and an on-premises deployment cannot simply let those agents discover each other. Someone has to manually configure where each one lives, or pay a commercial intermediary to track them.

The scale of this friction is growing. Gartner’s 2026 data and analytics predictions forecast that by 2030, half of all AI agent deployment failures will stem from insufficient governance and broken interoperability between systems. NIST formally recognized the gap in February 2026 when it launched its AI Agent Standards Initiative, the first federal-level program specifically targeting identity, security, and interoperability standards for autonomous agents. DNS-AID is a direct candidate for what NIST is trying to formalize.

SVCB Records, DNSSEC, and a Naming Pattern That Requires No New Infrastructure

DNS-AID does not invent new DNS record types or require organizations to run new servers. Instead, it defines a naming convention layered on top of existing standards — specifically, RFC 9460 Service Binding (SVCB) records. An agent is published at a deterministic, human-readable DNS address in the form of the agent’s name, its protocol, and the word “agents” as labels nested under its organization’s domain. For example, an MCP-speaking chatbot at example.com would be published under a label like “_chatbot._mcp._agents.example.com.”

The SVCB record at that address carries the machine-readable metadata a discovering agent needs: the communication protocol, the service port, a URI pointing to a capability document, an integrity hash for that document, protocol version declarations, a governance policy URL, and a tenant scope identifier. When an agent elsewhere on the internet needs to find that chatbot, it sends a standard DNS query — nothing more. It needs no special client software, no account with a commercial registry, and no pre-arranged relationship with the domain’s operator.

DNSSEC — the cryptographic extension to DNS standardized in RFC 4033 — signs the entire record chain from the DNS root down to the individual agent entry. This means a discovering agent can cryptographically verify that the record it received is authentic and untampered, not a spoofed endpoint injected by an attacker. DANE (DNS-based Authentication of Named Entities) binds TLS certificates to those records, adding a second layer: even if an attacker intercepts the connection, they cannot present a valid certificate without controlling the domain’s DNS zone.

The security design matters because the threat is documented. A January 2026 analysis by Akamai described “dangling DNS” as one of the most underappreciated attack surfaces in AI deployments: when a DNS record still points to a cloud resource that no longer belongs to its original owner, an AI agent that blindly follows DNS resolution will connect to whatever attacker has reclaimed that endpoint. DNSSEC-signed agent records under DNS-AID address this vulnerability directly.

Three Discovery Modes and Eight Backends in the Reference Implementation

DNS-AID supports three progressively broader discovery modes. A direct lookup by agent name returns the endpoint for a specific agent the requester already knows about. A capability-based query searches for any agent on a given domain that offers a particular function, without requiring knowledge of specific agent names. A domain index crawl pulls the full catalog of a domain’s published agents from a well-known entry point — a TXT record serving as the starting point for traversal, located under the “_index._agents” label within the organization’s domain.

This three-tier structure maps directly onto how real interoperability scenarios work. An enterprise integration team that knows it wants to connect to a specific partner’s billing agent uses the first mode. A runtime orchestrator looking for any agent on a partner domain that can process invoices uses the second. A developer auditing what agents a domain exposes uses the third.

The reference implementation ships eight DNS provider backends: Amazon Route 53, Cloudflare, Infoblox NIOS, Infoblox Universal DDI, Azure DNS, Google Cloud DNS, NS1, and a self-hosted BIND9 option for local development. A Docker Compose setup with a local BIND9 server lets developers test the full stack without touching production DNS. The Python SDK, command-line interface, and MCP server are available today at dns-aid.org under the Linux Foundation’s governance.

How DNS-AID Relates to MCP, A2A, and the Agent Name Service

DNS-AID does not replace the communication protocols that AI agents use once they find each other. Anthropic’s Model Context Protocol (MCP) governs how agents interact with tools, data sources, and APIs. Google’s Agent-to-Agent (A2A) protocol governs how agents coordinate tasks with one another. DNS-AID sits one layer below both: it is the mechanism by which an agent finds out where a peer lives before any communication begins. The SVCB record declares which protocol the published agent speaks — MCP, A2A, HTTPS, or any future standard — so the discovering agent knows what to invoke once it connects.

GoDaddy, one of the founding coalition members, is simultaneously co-developing a complementary IETF draft called the Agent Name Service (ANS). Where DNS-AID handles capability discovery and endpoint resolution, ANS handles agent identity and naming using public key infrastructure. The two standards are designed to compose: ANS gives an agent a cryptographically verifiable name; DNS-AID tells other agents what that agent can do and how to reach it. Scott Courtney, GoDaddy’s VP of Engineering, described the combined approach as building the agentic internet on the same DNS and public-CA infrastructure that has carried the human web for thirty years — infrastructure that works precisely because no single operator owns it.

The IETF draft for DNS-AID (draft-mozleywilliams-dnsop-dnsaid-02, dated May 27, 2026) carries contributions from engineers at Deutsche Telekom and Amazon alongside Infoblox’s originating authors. The draft is currently in open review and carries an important qualification: DNS-AID provides a verifiable transport for agent metadata, not a guarantee that a discovered agent will behave predictably given that metadata. Discovery resolves where an agent lives; behavior is the responsibility of the application layer above it.

Why DNS Rather Than a New Protocol

The competing approaches to AI agent discovery each make different architectural trade-offs. Google’s A2A protocol publishes an Agent Card at the “.well-known/agent-card.json” path on a domain — a self-describing JSON file that any crawler can read, but one that requires the destination domain to serve it over HTTP. Microsoft Entra Agent ID is a managed enterprise directory with governance and conditional access, designed for large organizations that want centralized control within the Azure ecosystem. Centralized MCP Registry files provide a single catalog of available servers but concentrate control in whoever runs the registry. Several other IETF drafts, including APIX (API Index for Autonomous Agent Service Discovery), were also submitted in May 2026, reflecting the active state of the standards landscape.

DNS-AID’s architectural claim is that none of these approaches inherits the key properties that made DNS itself succeed at internet scale: global deployment in every resolver on the planet, built-in caching that distributes load automatically, a federated governance model where each domain operator controls their own zone, and decades of operational security practice. A paper published on arXiv on June 1, 2026 by engineers at Verisign — one of the world’s largest DNS operators — independently made the same argument, concluding that DNS is the right foundation for AI agent discoverability at internet scale because it already handles names, authentication, service endpoints, and security status mechanisms for the entire global internet.

The alternative — allowing each major AI platform to run its own agent registry — would replicate the app store dynamic that shaped mobile computing for the past two decades. An agent on Platform A could not find an agent on Platform B without passing through a commercial intermediary’s directory. DNS-AID is attempting to prevent that outcome by establishing a neutral, federated standard before proprietary registries solidify into de facto infrastructure.

Whether DNS-AID achieves the adoption necessary to do so is an open question. The IETF draft is not yet an RFC, and several well-resourced competing approaches are already deployed in production. Jim Zemlin, Linux Foundation CEO, has framed the stakes directly: without secure, open discovery infrastructure, the connectivity that AI agents provide becomes a liability rather than an asset. The standards that succeed at internet scale tend to be simple, early, and operational enough that everyone implements them without extensive deliberation. DNS itself qualified on all three counts. DNS-AID is trying to inherit those properties at a moment when the window to establish a neutral standard is still open.

Frequently Asked Questions

What is DNS-AID and how does AI agent discovery through DNS work?

DNS-AID (Domain Name System for AI Discovery) is an open standard, currently advancing as an IETF draft, that lets AI agents publish their endpoints and capabilities as DNS records — specifically RFC 9460 SVCB records — so other agents can find them without a centralized registry. A discovering agent sends a standard DNS query to a deterministic address structured around the agent’s name, protocol, and domain, and receives a signed record pointing to the agent’s endpoint, protocol, and capability document. DNSSEC cryptographically verifies the record’s authenticity end-to-end.

How is DNS-AID different from centralized AI agent registries?

Centralized registries require every participating agent to register with a single operator, creating a single point of failure, vendor dependency, and interoperability barriers between platforms. DNS-AID is federated by design: each domain operator publishes their own agents under their own DNS zone, with no central authority controlling the directory. The same DNS caching infrastructure that serves billions of requests per day handles discovery automatically, at no additional cost to participants.

What is the Model Context Protocol (MCP) and how does it relate to DNS-AID?

MCP is an open standard developed by Anthropic that governs how AI agents connect to external tools, data sources, and APIs. DNS-AID operates one layer below MCP: it tells an agent where an MCP server lives before any interaction begins. The SVCB record published under DNS-AID declares the protocol the agent speaks, allowing the discovering agent to know which protocol to invoke once it connects to the discovered endpoint.

Will DNS-AID work with existing DNS infrastructure, or does it require new servers?

DNS-AID requires no new DNS record types and no new servers. It is a naming convention layered on RFC 9460 SVCB, DNSSEC, and DANE — standards already supported by major DNS providers. The reference implementation ships backends for Amazon Route 53, Cloudflare, Azure DNS, Google Cloud DNS, Infoblox NIOS, NS1, and BIND9, allowing developers to use whichever DNS provider they already operate.