DNS-AID: How AI Agents Will Find and Trust You

Every protocol war in the agentic web so far has been about one question: what can an agent do once it reaches you. Model Context Protocol, App Intents, WebMCP, agent cards. They all answer the same thing, which is "here are my capabilities, here is how to call them."

A small group of DNS engineers, the people behind a new proposal called DNS for AI Discovery (DNS-AID), just stood up and asked the question everyone skipped. How does an autonomous agent find you in the first place, and how does it know the thing it found is actually you?

Their answer is to push discovery down into the plumbing of the internet itself. Not a new web standard, not another .well-known file. The Domain Name System. DNS-AID has been moving quietly through the IETF since February 2026, and this week it picked up a Linux Foundation project and public backing from Infoblox, Deutsche Telekom, Amazon, and GoDaddy. It also has a rival design fighting it for the same job. I read the draft so you don't have to, and I want to tell you what it is, exactly how new it is, and why the DNS layer is the part of the agentic web nobody was watching.

The 90-second version

Here is what was actually proposed, stripped of the press-release gloss:

• DNS-AID is an IETF Internet-Draft, draft-mozleywilliams-dnsop-dnsaid, authored by engineers at Infoblox and Deutsche Telekom, with an Amazon author added in the latest revision. It proposes a standard way to publish, and cryptographically vouch for, AI agents in the DNS.
• The mechanism: a domain publishes a small "leaf zone" under an _agents label, for example _agents.example.com, and an agent looks up a well-known entry point, _index._agents.example.com, to find a pointer to that organization's registry of agents.
• Those records are SVCB records, the general-purpose service-discovery record type from RFC 9460, carrying the address, port, and protocol an agent needs to connect in a single DNS lookup.
• The discovery zone is meant to be signed with DNSSEC, the chain of cryptographic signatures that lets a resolver prove a DNS answer is authentic and was not forged in transit.
• It explicitly reaches up to the protocol layer you already know. The draft asks IANA to register two protocol identifiers, mcp and a2a, tying DNS discovery directly to Anthropic's Model Context Protocol and Google's Agent2Agent.

Now the part the announcements bury. This is a proposal, not a standard. I will come back to exactly how raw it is, because it matters more than the demo videos suggest. First, why DNS at all.

The layer everyone forgot

Think about how a human finds a business. You do not memorize an IP address. You type a name, and a quiet system turns that name into a location and tells your browser it reached the right place. DNS has been the internet's name-to-location-to-trust layer for forty years.

Agents have had no equivalent. The whole agentic stack has been built top-down, capability-first, and it left a hole at the bottom. Walk up the layers:

At the top sit the action protocols. MCP and A2A define how an agent calls a tool or hands work to another agent. We wrote about the browser-side version of this in WebMCP: the standard your site needs.

Below that sit description files. An A2A "agent card", usually served at /.well-known/agent-card.json, is a document that says what an agent is, what it can do, and where to reach it. Useful, but it assumes you already know the domain to ask, and a JSON file over plain HTTPS carries no proof that the agent on the other end is the one the domain owner authorized.

Underneath all of it should be discovery and trust: given a name, find the agents, and verify they are legitimate before you let a machine act on them. That layer was empty. DNS-AID is a bid to fill it with the system already built for exactly this shape of problem.

The reframe worth keeping: capability protocols tell an agent what it can do once it arrives. DNS-AID is about arrival itself. And about whether that arrival can be trusted.

How it actually works

The clever move is that DNS-AID invents almost nothing. It rides on RFC 9460, the November 2023 standard that defined the SVCB record (Service Binding). Most people met SVCB through its sibling, the HTTPS record that speeds up the modern web. What RFC 9460 quietly also did was define SVCB as a general-purpose discovery record for any service, addressed with an underscore-prefixed label like _examplescheme.api.example.com. DNS-AID inherits that pattern wholesale.

So the flow looks like this:

1. An agent that wants to do business with example.com queries _index._agents.example.com. That is the well-known front door, the one label everyone agrees to look for.
2. It gets back an SVCB record in ServiceMode, which packs the target host, the port, address hints, and the supported protocol into one answer. No second round trip to go find connection details.
3. The protocol is named so the agent knows what it is talking to. The draft requests the identifiers mcp and a2a, and in the latest revision it moved the agent protocol out of the transport alpn field into a dedicated parameter so the two stop fighting over the same slot.
4. The agent's resolver checks the DNSSEC signatures. If the chain of trust does not validate, a well-behaved resolver treats the answer as bogus and refuses to act on it. That is the "know it's really you" half. Unsigned discovery data is, by design, not to be trusted for public use.

There is more in the DNS-AID draft. There are per-capability entry points like _a2a._agents.example.com and _mcp._agents.example.com, custom parameters for capability descriptors and policy bundles, and a challenge record for proving control. But the spine is the simple thing above: one signed lookup turns a domain name into a verified, connectable agent.

Why DNS, and not just another well-known file

The fair question is why bother, when an agent card at /.well-known/ already lists endpoints. My read, and I want to be clear this is analysis rather than something the draft proves, is that DNS brings three things the file approach cannot.

It is universal and ambient. Every connected device already speaks DNS, and it resolves before any HTTP connection exists. Discovery that lives in DNS works for protocols that are not HTTP at all, and it works at a layer agents already traverse on the way in.

It is cacheable at internet scale. DNS is the most heavily cached system humans have ever built. An agent directory that resolves like a hostname inherits that, instead of hammering a JSON endpoint.

Most importantly, it is authenticatable. This is the real prize. A .well-known file tells you what an agent claims. A DNSSEC-signed record tells you the domain owner cryptographically vouched for it. In a world where agents will act, spend, and sign on your behalf, the difference between "claims to be" and "provably authorized by the domain" is the entire ballgame. It is the same trust gap we keep circling in the new traffic class of agents acting on behalf of users.

DNS-AID does not replace agent cards or MCP. It sits under them. DNS answers find and trust, the card describes, the protocol acts.

This is not settled, and you should act like it

Here is where I have to take the air out of the room, because the coverage will not.

DNS-AID is an individual Internet-Draft. In IETF terms that means one or more people wrote it and posted it. It has not been adopted by the dnsop working group, and every page of it carries the standard line that it is "not endorsed by the IETF and has no formal standing in the IETF standards process." Targeting a working group is not the same as being accepted by one.

It is also brand new and moving fast. Its predecessor, a draft charmingly named BANDAID, appeared in October 2025. The DNS-AID line itself started in February 2026 and is already on its third revision in roughly three months, and the mechanics changed between those revisions. The well-known label, the parameter that carries the protocol name, the exact DNSSEC wording, all shifted. The mcp and a2a identifiers it leans on are provisional placeholders the authors themselves flag as "to be confirmed." Internet-Drafts expire every six months. This one is a snapshot, not a foundation.

And DNS-AID is not the only design on the table. A separate group from CNNIC, China's domain registry, has its own draft that solves the same problem a different way, by minting an entirely new DNS record type called AGENT instead of reusing SVCB. Two credible groups, two incompatible blueprints, zero working-group decision. The honest status of agent discovery in DNS as of mid-2026 is "contested," not "decided."

So no, do not re-architect anything around DNS-AID this quarter. Anyone selling you a DNS-AID compliance package today is selling you a bet on a draft.

What it means for you

With that caveat loud and clear, the direction is the signal, and the direction is worth your attention. None of these recommendations are sourced predictions. They are the same conclusion I keep arriving at from every corner of the agentic web, which is that machines are becoming a first-class audience for your infrastructure.

The thing every one of these proposals agrees on is that an agent has to be able to find you and trust you before it can do anything for you, or buy anything from you. That is true whether discovery ends up in DNS, in a well-known file, or in both. It is the same shift we documented for citations in Citation is the new position one, now reaching one layer deeper, into identity and addressability.

So the useful work is not implementing a draft. It is getting ready for the world the draft describes.

This quarter: turn on DNSSEC for your primary domains if you have not. It is good hygiene regardless of agents, and it is the prerequisite for every authenticated-discovery scheme being proposed, DNS-AID included. Most teams have never checked. Check.

This year: decide who owns "agent identity" at your company. When an autonomous agent shows up claiming to act for your brand, or when you deploy one that acts for your customers, someone needs to own how it is published, authorized, and revoked. Right now that is nobody's job. Make it somebody's.

Ongoing: keep your machine-readable surface clean and current. Whether an agent arrives through DNS, an agent card, or an always-on information agent, the brands that win the agentic web are the ones whose structured identity, capabilities, and endpoints are accurate, signed, and easy for a machine to parse. We make that case in depth in What is Answer Engine Optimization.

The honest version

I think DNS-AID is the most interesting bad idea I have read this year, and I mean that as a compliment. It might not win. The CNNIC approach might. Both might lose to a well-known-file convention that needs no IETF blessing at all. The specific records in this draft will almost certainly look different by the time anything ships, if it ships.

But the instinct underneath it is correct, and it is the instinct most marketing and infrastructure teams are sleeping through. The agentic web has spent two years answering "what can an agent do" and almost no time on "how does it find the right you, and prove it." DNS-AID drags that question into the open and points it at the one system built to answer it. Whether or not these exact records survive, the layer they are reaching for is real, and it is coming for the bottom of your stack.

Watch the draft. Sign your zones. And start treating your domain as something an AI will interrogate, because before long, one will.

Sources

• DNS for AI Discovery (DNS-AID), draft-mozleywilliams-dnsop-dnsaid (IETF Datatracker, individual draft, latest revision May 2026)
• BANDAID, the predecessor draft (IETF Datatracker, October 2025)
• RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS RRs) (IETF, Proposed Standard, November 2023)
• Service Binding Mapping for Agents, draft-zhang-aiproto-svcb-mapping-for-agents (CNNIC, the competing AGENT-record design)
• Linux Foundation announces the DNS-AID project (Linux Foundation)
• AI agents get their own phone directory, built atop DNS (The Register, May 2026)
• A guide to AI agent discovery (A2A Protocol docs, on agent cards and .well-known)
• A developer's guide to AI agent protocols (Google Developers Blog)