The Linux Foundation has accepted DNS-AID as a hosted project, formalising what has been an informal effort to give AI agents a discovery mechanism that uses the Domain Name System rather than yet another proprietary registry. The premise is simple. Every enterprise already runs DNS. Every agent runtime already resolves hostnames. If we publish agent endpoints and capability descriptors as DNS records, then agents can find each other and find tools without anyone deploying a new service mesh or signing up to a SaaS registry. The project joins a roster that already includes the CNCF, LF AI and Data, and the OpenSSF, which signals that the foundation wants agent infrastructure to follow the same vendor neutral pattern that Kubernetes and Linux itself enjoy.
How the records actually look
The specification reuses well understood record types. SRV records point to agent endpoints with ports and priorities, so an operator can publish something like _agent._tcp.payments.acme.example pointing to host and port pairs with weight and priority fields that load balancers and resolvers already understand. TXT records carry capability descriptors and signed metadata, typically as compact key value pairs that name the protocols an agent speaks, the schema versions it supports and the trust anchors that signed its manifest. URI records point to capability manifests in MCP, A2A or ACP formats hosted over HTTPS, so the DNS layer stays small while the rich descriptions live where they belong. DNSSEC provides integrity, which matters when an agent is about to call a tool that can move money or mutate a production database.
The maintainer group is small but deliberately cross vendor. Early contributors include engineers from Cloudflare and NS1 on the DNS side, infrastructure staff from Hugging Face and LangChain on the agent runtime side, and individual IETF regulars who have spent years on DANE, SVCB and HTTPS resource records. A draft has been submitted to the IETF as an individual submission and is expected to move to the DNSOP or ADD working group once the Linux Foundation incubation is announced publicly. The intent is to land an informational RFC within twelve to eighteen months, with reference resolvers in Go and Rust shipping under Apache 2.0 well before that.
Why DNS won this round again
The timing is not accidental. Snowflake acquired MCP governance company Natoma earlier this week, its sixth deal since June 2025, explicitly to give enterprises a way to control which agents can call which tools and data. Google has pitched its Agentic Data Cloud as the place where agents resolve data context. AWS has been quietly extending IAM with agent scoped roles, Microsoft has its own Entra Agent ID preview, and a long tail of vendors all have competing visions for how agents discover and authenticate to services. DNS-AID is the first proposal that is neutral, open and built on infrastructure every operator already runs, which is also the reason the hyperscalers have so far stayed silent about it rather than endorsing it.
The relationship to MCP, A2A and ACP is worth spelling out, because the three protocols are often conflated. MCP, the Model Context Protocol that Anthropic published and that Snowflake just doubled down on with Natoma, standardises how a single agent talks to a single tool server. A2A, the Agent to Agent protocol that Google has been pushing, standardises how two agents negotiate a task. ACP, the Agent Communication Protocol coming out of the LF AI and Data community, focuses on longer running multi agent conversations. None of them say anything about how an agent finds the tool server or the peer agent in the first place. DNS-AID fills that gap and stays out of the way of whatever wire protocol the parties end up speaking.
Where MCP, A2A and ACP fit
For data engineering teams the practical implication is that agent governance does not have to be a greenfield problem. We can publish internal agent records in our existing private DNS zones, with the same approval workflows we use for any new service. We can use DNSSEC and split horizon DNS to separate internal agents from external partner agents. We can monitor agent discovery traffic with the same DNS observability tools we already use for security, which means existing SIEM rules around NXDOMAIN spikes, unexpected TXT lookups and DNSSEC validation failures apply directly to agent traffic. That is much cheaper than standing up a new control plane, and it composes naturally with whatever MCP, A2A or proprietary protocols the agents themselves speak.
The obvious question is why DNS rather than a purpose built directory protocol. We have been here before. LDAP, UDDI, service registries inside every service mesh, the Kubernetes API as a de facto registry, and a parade of SaaS service catalogues have all tried to be the canonical place where software finds software. DNS keeps winning because it is already deployed, already cached at every layer of the network, already federated across organisational boundaries through delegation, and already understood by every operations team on the planet. A new directory protocol would need years to acquire those properties. DNS-AID gets them for free, at the cost of accepting the constraints of a record format that was designed in 1987.
What to publish on Monday morning
There are limits, and the project is honest about them. DNS is eventually consistent and cacheable, which is fine for service discovery but not for short lived credentials or fine grained authorisation. DNS-AID explicitly does not try to be an identity provider or a policy engine. It is the phone book; you still need an identity layer such as SPIFFE, an authorisation layer such as OPA or Cedar, and a runtime that enforces them. TXT record size limits mean large capability manifests have to live behind a URI record rather than in the zone itself. And split horizon DNS, while a feature for most enterprises, is a source of subtle bugs when an agent running in one network segment resolves a different endpoint from the same name than an agent running in another segment expects. The risk over the next year is that vendors will try to fill the identity and policy gaps with proprietary stacks, exactly the way they did with service meshes five years ago. The Linux Foundation home gives DNS-AID some protection from that, but only if enough operators adopt it as the default.
For us as data platform owners the action is small and concrete. Reserve a subdomain for agents, for example agents.internal.acme.example. Publish a handful of agent records as a pilot, starting with read only analytics agents that pose little blast radius. Wire one agent runtime, whether that is LangGraph, CrewAI or an in house orchestrator, to resolve them. Add the agent discovery zone to your existing DNS monitoring and to your change management process. If the pattern works at small scale, it will work at large scale, and you will have built the directory for your enterprise agent fleet without buying a new product. The operator take is blunt. Snowflake just paid for MCP governance, Google is selling agent context, and every vendor in the stack would prefer that the directory layer be theirs. DNS-AID is the boring, neutral, already deployed alternative, and boring usually wins in infrastructure. We would rather run a zone file than a renewal negotiation.
