DNS-AID turns the internet’s existing DNS into a phone book for AI agents. Here is the record layout, the DNSSEC and DANE verification flow, a copy-paste dig walkthrough, and an honest adopt-or-wait verdict.
What is DNS-AID, in one sentence?
DNS-AID (DNS for AI Discovery) is an open naming convention that lets AI agents publish, find, and cryptographically verify each other using the internet’s existing DNS, with no new record types, no new servers, and no central registry. When people ask what is DNS-AID, the shortest honest answer is that it turns DNS into a phone book for agents: an organization publishes its agents as standard DNS records, and any other agent can look them up and confirm they are authentic.
DNS-AID was accepted as a Linux Foundation project on May 27, 2026, with a founding coalition that includes Cloudflare, GoDaddy, Equinix, Internet Systems Consortium (ISC), and Infoblox, building on code originally developed at Infoblox. The technical design is documented in the IETF individual draft draft-mozleywilliams-dnsop-dnsaid-02, titled “DNS for AI Discovery,” authored by Jim Mozley, Nic Williams, Behcet Sarikaya, Roland Schott, and Jeffrey Damick.
The reason this matters now is timing. AI agents have settled on protocols for how they talk to each other (MCP and A2A), but they had no agreed-upon way to find each other. Teams were stuck choosing between hardcoded endpoints that break on every reorganization and centralized agent registries that reintroduce lock-in and a single point of failure. DNS-AID explained simply is the missing discovery layer that sits underneath both options.
DNS-AID is a deterministic naming pattern (_name._protocol._agents.domain) layered on RFC 9460 SVCB records, TXT records, and TLSA records, verified with DNSSEC and DANE. It answers WHERE an agent lives; MCP and A2A still govern HOW agents communicate.
Where does DNS-AID sit in the agent stack?
DNS-AID is the discovery layer beneath MCP and A2A: it is the mechanism by which an agent finds out where a peer lives before any communication begins, while MCP and A2A define the conversation that happens afterward. Keeping these layers separate is the single most useful mental model for understanding the standard.
Think of it the way a browser works. DNS resolves example.com to an address; HTTPS then carries the actual page. DNS-AID does the same job for agents. It resolves a deterministic agent name to an endpoint, a protocol, and a pointer to a capability document, and then your agent connects over whatever protocol the record declared, whether that is MCP, A2A, plain HTTPS, or something else.
Because DNS-AID lives below the communication protocols, it does not compete with MCP or A2A; it feeds them. An MCP client that knows how to read DNS-AID records no longer needs a config file full of brittle server URLs. It resolves them at runtime, the same way your laptop resolves a website every time you open it.
This layering is also why DNS-AID is complementary to an AI agent registry rather than a strict replacement. A registry is a curated catalog with search, ratings, and governance; DNS-AID is the decentralized resolution and authenticity substrate. You can run a registry that publishes its entries as DNS-AID records, getting curation at the registry and verifiable resolution from DNS.
The clean separation: DNS-AID determines WHERE an agent is and proves the record is authentic. It is explicitly NOT a trust signal that the agent itself is safe to use.How does AI agent discovery via DNS actually work?
AI agent discovery via DNS works by publishing each agent at a deterministic address such as _chatbot._mcp._agents.example.com, where an SVCB record carries the protocol, port, and a link to a capability document, all signed with DNSSEC and optionally bound to a TLS certificate with DANE. A discovering agent performs a normal DNS lookup, validates the signatures, fetches the capability document, and connects.
The naming convention is the heart of it. DNS-AID uses the pattern _
The SVCB record (defined in RFC 9460) is where the machine-readable metadata lives. According to the project documentation, the key SvcParams include alpn (the communication protocol, such as mcp, a2a, or h2), port, cap (the capability document URI), cap-sha256 (an integrity hash so a fetched capability doc can be checked for tampering), policy (a governance and usage policy URL), realm (tenant or environment scope), and ipv4hint (an address hint that saves an extra lookup).
There are three discovery modes, matching the three things a requester might already know. Known agent: a single SVCB query to the agent’s name returns its endpoints and metadata. Known organization: a query to _index._agents.example.com returns an index of the org’s agents (carried in TXT records) so the requester can pick by capability before querying a specific record. Known capability only: search-based discovery, which the IETF draft notes is currently out of scope for the core spec.
| Field | Carries | Why it matters |
|---|---|---|
| alpn | Protocol: mcp, a2a, h2 | Tells the consumer how to talk to the agent |
| port | Service port number | Where to connect on the target host |
| cap | Capability document URI | Pointer to the full machine-readable capability spec |
| cap-sha256 | Hash of the capability doc | Detects tampering of the separately fetched doc |
| policy | Governance/usage policy URL | Surfaces terms and usage constraints |
| realm | Tenant or environment scope | Enables clean multi-tenant addressing |
| ipv4hint | IP address hint | Cuts an extra round-trip during resolution |
What does a DNS-AID lookup look like with dig?
You discover a DNS-AID agent with a standard dig query for the SVCB record at the deterministic agent name, then validate it with DNSSEC and check the matching TLSA record for DANE. No special client is required to see the records; dig is enough to inspect them. The example below is structural and illustrative (field values are placeholders), so you can map each part of a real response to the fields above.
Step one is the SVCB lookup. You ask DNS for the agent’s record at its deterministic name and read the SvcParams out of the answer. Step two is the DNSSEC check: the +dnssec flag returns the RRSIG signatures, and the ad (Authenticated Data) flag in the header tells you a validating resolver verified the chain of trust from the root down to this record. Step three is DANE: you query the TLSA record at the same service name and port so your client can pin the agent’s TLS certificate to what DNS asserts.
Once those three checks pass, you fetch the capability document at the cap URI, verify its SHA-256 against cap-sha256, and only then open the actual MCP or A2A session to the endpoint and port the SVCB record declared. That ordering matters: resolve, verify authenticity, verify integrity, then connect.
The project ships a Python SDK and CLI (pip install “dns-aid[all]”) with publish, discover, and verify commands, plus dns-aid doctor for diagnostics and a dns-aid-mcp server. Eight DNS backends ship in the box, including Route 53, Cloudflare, Azure DNS, Google Cloud DNS, NS1, Infoblox NIOS, RFC 2136, and BIND9.
# 1. Resolve the agent's SVCB record at its deterministic DNS-AID name
# Pattern: _<agent>._<protocol>._agents.<domain>
dig +short _chatbot._mcp._agents.example.com SVCB
# Illustrative answer (placeholders, not real values):
# 1 chatbot.example.com. (
# alpn="mcp"
# port=443
# cap="https://example.com/.well-known/agent/chatbot.json"
# cap-sha256="<base64-hash>"
# policy="https://example.com/agent-policy"
# ipv4hint=192.0.2.10 )
# 2. Re-run with DNSSEC so you get RRSIGs and the AD (Authenticated Data) flag
dig +dnssec _chatbot._mcp._agents.example.com SVCB
# ;; flags: qr rd ra ad; <-- 'ad' means the chain of trust validated
# ...SVCB record...
# ...RRSIG SVCB... <-- cryptographic signature over the record
# 3. DANE: pin the TLS cert by querying the TLSA record at host + port
dig +dnssec _443._tcp.chatbot.example.com TLSA
# 3 1 1 <sha256-of-cert-or-spki> <-- bind TLS to the DNS-published value
# 4. Only after DNSSEC + DANE validate: fetch the capability doc,
# verify its SHA-256 against cap-sha256, then connect over MCP/A2A.How does DNS-AID verify agents with DNSSEC and DANE?
DNS-AID verification is a two-part chain: DNSSEC (RFC 4033) cryptographically signs the records so a consumer can prove they came from the real zone owner and were not modified in transit, and DANE (TLSA records) binds the agent’s TLS certificate to the DNS data so the consumer can confirm it is connecting to the right endpoint. Together they give origin authentication, integrity, and certificate pinning without any external certificate authority decision.
DNSSEC is what makes DNS-AID trustworthy as a transport. Without it, anyone able to spoof a DNS answer could point an agent at a malicious endpoint. With it, the discovering agent walks the signature chain from the DNS root through the TLD to the org’s zone, and a single tampered byte breaks the validation. This is why the design only really works on DNSSEC-signed zones; an unsigned zone gives you discovery with no authenticity guarantee.
The cap-sha256 field extends integrity beyond the record itself. The full capability document is fetched out of band over HTTPS, so DNS-AID puts its hash inside the signed SVCB record. If the fetched document does not hash to that value, the consumer rejects it, even if the HTTPS connection looked fine.
The most important nuance, and the one the press releases gloss over, is what the IETF draft says explicitly: DNS-AID records are “a verifiable transport for agent metadata, not a trust signal in their own right.” In plain terms, DNS-AID proves the record authentically came from example.com. It does not prove that example.com’s agent is competent, safe, or honest. Consumers are expected to combine DNS-AID with out-of-band reputation and organizational policy systems for authorization.
“DNS-AID proves the record authentically came from the zone owner. It does not prove the agent behind it is safe to trust. Those are different problems.”
Paraphrasing draft-mozleywilliams-dnsop-dnsaid-02
DNS-AID vs agent registry vs hardcoded MCP/A2A endpoints
DNS-AID beats hardcoded endpoints on resilience and beats centralized registries on decentralization and lock-in, but a registry still wins on rich search, curation, and ratings, while hardcoded endpoints win on zero setup for a tiny static fleet. The right choice depends on scale, who controls discovery, and whether you can sign your DNS zones.
Hardcoded MCP or A2A endpoints are fine for a prototype with three known servers. They fall apart at scale: every URL change, subdomain migration, or new tenant means a redeploy, and there is no built-in authenticity check. A centralized agent registry fixes discovery and adds curation, but it becomes infrastructure you must run or depend on, a single point of failure, and a potential point of lock-in and gatekeeping.
DNS-AID’s pitch is that the resolution and authenticity layer should be decentralized infrastructure that already spans the globe, is cached everywhere, and has a 40-year operational track record: DNS. You keep control of your own agents by publishing in your own zone, and consumers verify with cryptography rather than trusting a registry operator. The trade-off is that DNS-AID itself does not give you fuzzy capability search or human-readable ratings; those belong in a registry layered on top.
Use the decision matrix below to choose, and note that these are not mutually exclusive. A mature setup often hardcodes nothing, publishes via DNS-AID for verifiable resolution, and runs a registry on top for discovery UX and governance.
Pros
Cons
| Dimension | Hardcoded MCP/A2A | Centralized agent registry | DNS-AID |
|---|---|---|---|
| Setup cost | Lowest (paste a URL) | Medium (onboard to registry) | Medium (sign zone, publish records) |
| Resilience to change | Poor (breaks on every move) | Good (registry tracks it) | Good (record updated in zone) |
| Decentralization | N/A | Centralized | Decentralized by design |
| Lock-in risk | Low but unscalable | High (registry operator) | Low (you own your zone) |
| Authenticity guarantee | None | Registry-asserted | Cryptographic (DNSSEC + DANE) |
| Capability search | None | Strong (catalog + ratings) | Limited (index + by-name today) |
| Best at scale | No | Yes, with trust in operator | Yes, if zones are DNSSEC-signed |
Should you adopt DNS-AID yet? An honest verdict
Verdict: publish now, depend later
Adopt DNS-AID now for publishing your own agents and for internal or partner discovery if your zones are DNSSEC-signed, but do not retire your registry or hardcoded fallbacks yet, because consumer-side support is still emerging and the spec is an early IETF individual draft. It is a low-risk, high-upside thing to start publishing, and a high-risk thing to depend on exclusively.
The momentum is real. Infoblox IQ launched on June 3, 2026 as the first major production system built on DNS-AID and MCP, and a Verisign-authored arXiv paper on June 1, 2026 argued that DNS is the right foundation for agent discoverability at internet scale because it already solves names, authentication, service endpoints, and security status globally. The founding coalition (Cloudflare, GoDaddy, Equinix, ISC, Infoblox) controls a meaningful slice of the world’s DNS, which matters enormously for a standard whose value is network effects.
The caution is equally real. The Linux Foundation only accepted the project on May 27, 2026, the spec is an individual Internet-Draft (explicitly not yet IETF-endorsed), and capability search, the thing most agent developers actually want, is not yet in scope. DANE adoption is the quiet blocker: if you cannot sign your zone and publish TLSA records, you lose the security story that makes DNS-AID better than a plain JSON file.
My concrete recommendation: standardize on the _name._protocol._agents.domain naming pattern internally today, publish your agents as DNS-AID records if your DNS supports DNSSEC, and add DNS-AID resolution as an additional discovery path in your clients while keeping registry and hardcoded fallbacks. Revisit exclusive reliance once the draft advances in dnsop and major MCP and A2A clients ship native DNS-AID resolvers.
Builder’s take
I have built agent discovery the hard way twice now. Hardcoded MCP endpoints rot the moment a vendor reorganizes a subdomain, and centralized registries become a single point of failure plus a single point of lock-in. DNS-AID is the first proposal that feels like it was designed by people who actually run infrastructure, because it reuses the layer that already solves global, decentralized, cache-friendly name resolution. Here is how I am thinking about it for Cyntr and Loomfeed.
- The killer property is that there is no new server to run. If you already operate DNSSEC-signed zones, DNS-AID is a deployment pattern, not a platform you have to adopt, host, and trust.
- Treat DNS-AID as discovery only. It tells you where an agent lives and proves the record is authentic; it does NOT tell you the agent is trustworthy. You still need reputation, policy, and authorization on top, which is exactly what the IETF draft says out loud.
- I would publish agents under DNS-AID today for internal and partner discovery, but I would not retire my registry or hardcoded fallbacks yet. The standard is an IETF individual draft and a 10-day-old Linux Foundation project; consumer support is still thin.
- The deterministic _name._protocol._agents.domain pattern is the part I would standardize on internally right now even before the spec finalizes, because it costs nothing and makes future migration trivial.
- Watch DANE adoption. DNS-AID’s security story leans on DNSSEC plus TLSA, and TLSA in the wild is still rare. If you cannot sign your zone, you get a phone book with no caller ID.
Frequently asked questions
DNS-AID (DNS for AI Discovery) is an open standard, hosted by the Linux Foundation since May 27, 2026, that lets AI agents publish, find, and verify each other using the existing DNS. It is a deterministic naming convention layered on RFC 9460 SVCB records, TXT records, and TLSA records, verified with DNSSEC and DANE, with no new record types or servers required.
An organization publishes each agent at a deterministic address like _chatbot._mcp._agents.example.com. The SVCB record there carries the protocol, port, and a link to a capability document. A discovering agent does a normal DNS lookup, validates the DNSSEC signatures and the DANE TLSA record, fetches and hash-checks the capability document, and then connects over MCP, A2A, or HTTPS.
No. DNS-AID sits one layer below MCP and A2A. It determines where an agent lives and proves the record is authentic; MCP and A2A govern how agents communicate once connected. DNS-AID feeds those protocols by resolving endpoints at runtime instead of relying on hardcoded URLs.
An agent registry is a centralized, curated catalog with search and ratings, which adds an operator you must trust and a single point of failure. DNS-AID is a decentralized resolution and authenticity layer published in your own DNS zone. They are complementary: a registry can publish its entries as DNS-AID records to get curation plus verifiable, decentralized resolution.
DNS-AID’s security comes from DNSSEC and DANE. DNSSEC (RFC 4033) signs the records so a consumer can prove they came from the real zone owner unmodified, and DANE (TLSA records) binds the agent’s TLS certificate to the DNS data. The IETF draft is clear that this verifies the transport of agent metadata, not the trustworthiness of the agent itself, so you still need reputation and policy controls on top.
Start publishing your agents as DNS-AID records now if your zones are DNSSEC-signed, and add DNS-AID resolution as an extra discovery path in your clients, but keep your registry and hardcoded fallbacks. The standard is promising and well-backed (Cloudflare, GoDaddy, Equinix, ISC, Infoblox), but it is an early IETF individual draft, capability search is not yet in scope, and broad consumer-side support is still emerging.
Primary sources
- Linux Foundation Announces DNS-AID Project to Advance Decentralized AI Agent Discovery — Linux Foundation
- DNS-AID lets AI agents find and verify each other through DNS — Help Net Security
- DNS-AID — AI Agent Discovery via DNS — DNS-AID Project
- draft-mozleywilliams-dnsop-dnsaid-02 – DNS for AI Discovery — IETF Datatracker
- AI Agent Discovery Gets Open DNS Standard: DNS-AID Launches Under Linux Foundation — Tech Times
- DNS-AID will make AI agents easier to discover, says Linux Foundation — InfoWorld
- AI agents get their own phone directory built atop DNS — The Register
- Discovering Agents for Discovery: The Case for DNS — arXiv (Verisign)
Last updated: June 6, 2026. Related: Identity Provenance.
