I’ve built my site to be found by AI agents six different ways. A scanner called “is it agent ready” still flagged it for a seventh: no DNS-AID records. DNS-AID is a new way to publish AI agents in DNS so other agents can discover them, and it’s the discovery layer I hadn’t touched yet. So I went to add the records. My DNS host physically couldn’t create them.
This isn’t a how-to. I can’t hand you the steps to publish DNS-AID records, because on the hosting most sites actually run, you can’t. That failure is the whole point of this post. I’ve already implemented Google’s Agentic Resource Discovery spec and I’m exposing agent tools with WebMCP, so this is someone who wants to be agent-ready telling you where the frontier actually stops today. DNS-AID became a Linux Foundation project in May 2026, so this is a real standard with real backing, not a thought experiment.
Key Takeaways
- DNS-AID publishes AI agents in DNS via SVCB records, is Linux Foundation-backed, and needs no new record types or servers.
- It sits below MCP and A2A as the discovery layer: where an agent lives, resolved before any protocol handshake.
- The blocker for most sites isn’t effort, it’s whether their DNS host supports SVCB records. Many, including cPanel hosts, don’t.
- Don’t advertise agent endpoints you don’t actually run.
- Do the agent-readiness work that’s consumable today: entities, MCP,
.well-known, clean content.
What DNS-AID Actually Is (and Why It’s Not Hype)
DNS-AID isn’t a whitepaper or a startup pitch. It’s a Linux Foundation project built on top of an existing IETF standard, and it solves a real problem. Here’s what it does, how it works, and where it sits relative to the agent protocols you’ve already heard about.
The problem it solves: agents can’t find each other
Right now, one AI agent finds another through hardcoded URLs, a centralized registry, or manual configuration. All three are brittle. Hardcoded URLs break when endpoints move, registries put a middleman between every pair of agents, and manual config doesn’t scale past a handful of integrations.
DNS-AID uses the naming system that the entire internet already trusts. Instead of a new overlay network, agents get a predictable DNS address anchored to a domain you already control. This is the DNS layer, sitting below the HTTP-based .well-known approach I wrote about: an agent resolves where a peer lives before it makes a single HTTP request.
How it works: a naming convention on SVCB records
DNS-AID invents no new record types and requires no new servers. It’s a naming convention layered on RFC 9460 Service Binding (SVCB) records, signed with DNSSEC so a resolver can trust the answer. The draft is explicit on this point: it introduces no new resource record types, opcodes, or response codes. (IETF)
Agents live under an _agents namespace on a domain you already control. An organization publishes a discovery entry point at _index._agents.{yourdomain}, and individual agents sit at leaves beneath that namespace, like _a2a._agents.{yourdomain} for one that speaks A2A. The SVCB record at that name carries the connection details, and its alpn parameter declares the protocol, so a requesting agent knows what it’s about to talk to before it connects. (The exact leaf naming is still settling as the draft moves, but the _agents anchor and SVCB mechanism are the stable parts.)
_a2a._agents.example.com. 3600 IN SVCB 1 agent.example.com. (
alpn=a2a ; protocol: Agent-to-Agent
port=443 ; where to connect
mandatory=alpn,port ; these params are required
)Read it as: “an agent speaking A2A lives at agent.example.com on port 443.” One query returns the location and the protocol in a single authenticated answer.
Where it sits: below MCP and A2A, not instead of them
DNS-AID doesn’t compete with MCP or A2A. It’s the layer underneath both. Anthropic’s Model Context Protocol governs how an agent uses tools and data. Google’s Agent-to-Agent protocol governs how agents coordinate tasks. DNS-AID answers the question that comes before either one: where does this agent live? The SVCB record just declares which protocol the agent at that address speaks, so discovery and handshake stay cleanly separated.
So I Tried to Publish the Records
I already point agents at real endpoints. I just needed to advertise them in DNS. On paper this is a 20-minute job: add a couple of SVCB records, sign the zone, done. It did not go that way.
Step one: find where my DNS actually lives
The first thing most site owners get wrong is assuming DNS is managed at the registrar. Mine isn’t. I register toddmorourke.com at Namecheap, but the nameservers delegate to my host, KnownHost, which manages DNS in cPanel. Namecheap’s own panel says it plainly: manage host records in your cPanel account.
So the rule for publishing DNS-AID records: you edit them wherever your nameservers point, not necessarily where you bought the domain. For a lot of people that’s a hosting control panel they’ve barely opened. Mine was cPanel’s Zone Editor. That’s where the wall showed up.
Step two: the record type doesn’t exist in my panel
DNS-AID needs an SVCB record. cPanel can’t make one. The Zone Editor’s Add Record dropdown offers exactly these types: A, AAAA, CAA, CNAME, DMARC, MX, SRV, and TXT. No SVCB. No HTTPS. The one record type the entire standard depends on is the one type the most common shared-hosting DNS panel doesn’t expose.
This isn’t a setting I missed or a permission I needed to flip. The option isn’t there. cPanel’s UI simply doesn’t build SVCB or HTTPS records, and cPanel runs a very large share of the world’s shared hosting. So for a huge population of sites, DNS-AID is unreachable from the panel where they’d have to publish it.
The two ways out, and why I took neither yet
There are exactly two ways around this, and I passed on both for now. One: open a support ticket asking KnownHost to hand-add a raw SVCB record in the backend zone file, for a record type their own UI can’t even display back to me. Two: move DNS to a provider like Cloudflare, which supports SVCB and HTTPS records natively and does DNSSEC in one click.
Cloudflare is the clean long-term answer. But migrating nameservers to satisfy one checkbox on one scanner, for a standard this young, isn’t worth it yet, especially because I don’t have a live A2A endpoint to point an _a2a record at. Publishing a record that advertises an agent I don’t run would be worse than publishing nothing. For someone whose whole argument is about being genuinely agent-ready, a hollow record is the wrong move.
The Bigger Point: “Agent-Ready” Is a Spec, Not Yet a Reality
The interesting finding here isn’t my host. It’s what my host represents. There’s a real gap between agent-readiness as a published standard and agent-readiness as something the average site can actually deploy this year.
“Any DNS server that supports SVCB” is doing a lot of work
DNS-AID’s pitch is that you can adopt it on any DNS server that supports DNSSEC and SVCB. That sentence sounds inclusive. It isn’t. cPanel can’t make an SVCB record, and cPanel sits in front of a massive slice of the small-business web. So in practice, DNS-AID is deployable today mostly by people already on Cloudflare, on managed DNS, or running their own nameservers.
That’s the technically sophisticated end of the web. It’s not the local service business, the solo consultant, or the small store on shared hosting, which are exactly the sites that most need a standardized way to be found. Agent-readiness is quietly stratifying by infrastructure, not by effort. You can do everything right and still be locked out by the control panel your host happened to ship.
What I’d actually do, and what you should do today
Don’t scramble to publish DNS-AID records right now. I’m not, and I build these signals for a living. The standard is young, most hosts can’t serve it, and there’s no meaningful population of agents querying for it yet. Chasing it today is effort spent ahead of the payoff.
Spend that effort on the agent-readiness work that’s already deployable and already consumed. Structured entities, an MCP endpoint, .well-known discovery, and clean content an LLM can actually parse all pay off now. I run a machine-readable entity map and publish an Open Knowledge Format bundle for exactly this reason. I also serve those pages as markdown when an agent asks for it, which took a small plugin, not a platform migration. When your DNS host adds SVCB support, or you move to one that has it, publish the honest _https or _index record first, sign the zone, and only add _a2a or _mcp records once there’s a real endpoint behind them.
Conclusion
DNS-AID is a real step toward a web where agents find each other without middlemen. It’s just landed ahead of the hosting most sites run on. The standard is sound; the distribution isn’t there yet.
Next Steps
- Find where your DNS is actually managed (often your host, not your registrar).
- Check whether that provider can create SVCB records at all.
- Prioritize deployable signals now: structured entities, an MCP endpoint,
.well-knowndiscovery. - Revisit DNS-AID when your host adds SVCB support or you move DNS to a provider like Cloudflare.
Frequently Asked Questions
What is DNS-AID?
DNS-AID is a Linux Foundation project that lets AI agents discover each other through DNS. It defines a naming convention on top of standard SVCB records (RFC 9460), signed with DNSSEC, so an agent can look up where a peer lives and which protocol it speaks without a central registry.
How is DNS-AID different from an A2A Agent Card or llms.txt?
They work at different layers. An A2A Agent Card and llms.txt are files served over HTTP, so an agent has to already reach your site to read them. DNS-AID works in DNS, one step earlier: it’s how an agent finds where your agent lives before it makes any HTTP request.
Do I need new DNS software to publish DNS-AID records?
No. DNS-AID adds no new record types and no new servers. It reuses SVCB, TXT, and TLSA records. The catch is that your DNS host still has to let you create SVCB records and enable DNSSEC, and many shared hosts, including cPanel-based ones, currently can’t create SVCB records at all.
Why can’t I create SVCB or HTTPS records in cPanel?
cPanel’s Zone Editor only exposes A, AAAA, CAA, CNAME, DMARC, MX, SRV, and TXT records. SVCB and HTTPS aren’t in the interface, so you can’t build the record DNS-AID requires. Your options are asking your host to add it in the backend zone or moving DNS to a provider like Cloudflare.
Does DNS-AID replace MCP or A2A?
No. DNS-AID is the discovery layer beneath them. MCP governs how an agent uses tools and data; A2A governs how agents coordinate. DNS-AID only answers where an agent lives and which of those protocols it speaks, then gets out of the way for the actual conversation.
Is DNS-AID an official standard?
Partly. It became a Linux Foundation project in May 2026 and is built on RFC 9460, which is a ratified standard for SVCB records. The DNS-AID naming convention itself is an active IETF draft, not yet a finished RFC, so expect details to keep moving.
