I don't like the idea that a handful of large companies are putting forth proposals that enshrine their platform as the mediator between every internet-bound agentic connection. You, and your business (your right to be discovered and transacted with) shouldn't be predicated on your relationship with said third party, nor dependent on their enforcement and structure of opaque terms of service. The internet already federated discovery in the 1980s. This project is the bet that we don't have to re-centralize it for AI.

Overview

DNS-AID is an IETF draft and an open-source reference implementation for using DNS, the same naming system that already underpins the rest of the internet, as the substrate AI agents use to find each other. Instead of every framework, vendor, and hyperscaler building (or buying into) yet another central registry of "where the agents are," agents publish themselves into the operator's existing DNS zone and resolve each other the way every other internet service already does.

The repo. The community site. The draft. They all sit on top of one observation: the world already solved decentralized, federated, sovereign service discovery in the 1980s. We've spent forty years scaling it. Adding agents as one more service type to the same machinery is cheaper than re-inventing it.

I wrote the landscape view of agent-discovery proposals in January: Agent Name Service, BANDAID, CATS, the various other drafts. This page is the focused writeup of the draft I've worked on inside that landscape, including the primitives shipping in the reference implementation and the open work currently in review.

What

Each agent publishes a small, standards-compliant set of DNS records under a name the operator already controls. At minimum: an SVCB record (RFC 9460) that carries the endpoint binding, plus a TLSA record (RFC 6698) that pins the agent's TLS certificate. The owner name is the agent's own FQDN (chat.example.com, billing.example.com, assistant.acme.test), not a synthetic underscore-prefixed leaf.

billing.example.com.           SVCB 1 . (alpn=h2 bap=mcp well-known=/.well-known/agent-card/billing.json cap-sha256=)
_443._tcp.billing.example.com. TLSA 3 1 1 

The SVCB record carries the endpoint binding (ALPN, port, IPv4/v6 hints) plus DNS-AID-specific SvcParamKeys that point at richer JSON metadata when a client wants it: well-known for the RFC 8615 path to the capability descriptor, cap-sha256 for its integrity hash, bap for the application-layer agent protocol, policy for the policy bundle, and realm for multi-tenant scoping.

An agent that speaks multiple protocols publishes one SVCB record per protocol in a single RRset; the client picks by alpn:

chat.example.com. SVCB 1 chat.example.com. (alpn=h2 bap=mcp   well-known=...)
chat.example.com. SVCB 1 chat.example.com. (alpn=h2 bap=a2a   well-known=...)
chat.example.com. SVCB 1 chat.example.com. (alpn=h2 bap=https well-known=...)

The SVCB TargetName can be in-bailiwick (pointing at infrastructure the same org runs, e.g. a gateway hostname inside example.com) or out-of-bailiwick (pointing at a hosting provider, e.g. x23yz89.agenthost.net). Both are first-class. That's what makes "list yourself in DNS, or point your DNS at someone who lists you" a single coherent shape rather than two different protocols.

The reference implementation lives at infobloxopen/dns-aid-core (Apache-2.0, on PyPI as dns-aid). It ships a Python SDK, a CLI, an MCP server that exposes the protocol as agent-callable tools, and backends for Route 53, Cloudflare, NS1, Google Cloud DNS, Infoblox NIOS + BloxOne, generic RFC 2136 DDNS, and a mock for tests.

The record formats above reflect the current -02 draft direction: flat agent FQDNs as the canonical owner, an optional walkable AliasMode at <name>._agents.<zone>, agent-protocol carried in bap with alpn reserved for TLS transport, and the well-known SvcParamKey for the RFC 8615 capability-descriptor handoff. They differ from what's printed in the -01 draft, which used underscore-prefixed leaves (_{name}._{protocol}._agents.<zone>). The integrity-hash key cap-sha256 and the capability-locator key cap both survive in -02; well-known was added alongside them as a sibling key specifically for the RFC 8615 path form (when the descriptor lives at /.well-known/<path>, publishers SHOULD use well-known; when it's a URN or non-RFC-8615 locator, cap is the home). The reference implementation tracks the migration.

Why

There is no shortage of agent-discovery proposals. There is also no consensus. Most proposals fall into one of three shapes, and all three have the same failure mode at the limit.

1. Centralized registry. Pick a vendor (or a consortium of vendors). Agents register with the vendor. Clients query the vendor's API. Migration is painful; interoperability is at the vendor's discretion; governance is whoever owns the registry. The internet built this once and called it AOL.

2. HTTP well-known endpoints alone. Agents publish a /.well-known/agent-card.json. Clients fetch by hostname. Fine for "I already know the hostname"; doesn't help for "I know the domain but not the service" or "I want to discover across domains." HTTP doesn't carry intent and HTTP doesn't have built-in delegation or DNSSEC.

3. New protocols layered above DNS. A new naming service, a new RR type, a new resolution algorithm. Buildable, but every operator must adopt new software, every middlebox must learn new traffic, every cache becomes a fragmentation surface.

The obvious objection to building on DNS is that it feels like the boring answer — a registry ships an API in a week, and a clean-slate protocol gets to design exactly the semantics agents want, while DNS makes you live inside SVCB, TXT, and TTLs you didn't choose. The reason to pay that cost: #1 and #3 buy their clean semantics by making someone adopt new infrastructure and trust a new operator, and #2 alone can't answer "I know the domain but not the service." DNS already has the delegation chain for sovereignty, DNSSEC for integrity, and a deployed operator ecosystem for federation — none of which a registry or a new protocol gets for free. So: use DNS the way DNS already works, layer JSON metadata on top via the existing HTTP /.well-known/ pattern, and add only the primitives genuinely missing for agents — a trust handshake, a query-time signal, a way for a multi-agent fan-out to be visible to caches.

The result, if it works, is that an agent published anywhere on the public internet is findable from anywhere else without asking permission from any single vendor. The day that stops being true — the day discovery routes through one company's API — is the day the whole exercise was pointless, so every design call below is made to keep it true.

How — The Primitives

A client of the protocol is always in one of three discovery states. The primitives are organized around what each state needs:

• Known Provider, Known Agent — direct lookup. One DNS query, one TLS validation, you're talking. (Primitives 1 + 2 below.)
• Known Provider, Unknown Agent — "I know whose agents I want, just not which one." Resolve the zone's index, then loop back to the known case. (Primitive 3.)
• Unknown Provider — "I don't know either." The substrate can't answer this. DNS is a name-resolution system, not a capability-matching system; there's no record at ?.?.? for "agents that do thing X." This case needs a search provider: a registry, marketplace, or semantic search service that has indexed cap-docs across the public internet and can do nearest-neighbor matching over capability descriptors, intent tags, embeddings, whatever the matching surface is.

The moment the search hands a client a domain + agent FQDN, the client is back in the known case, and the search provider is no longer in the trust path between the client and the agent. Search can be vendor-specific and can compete on ranking quality and freshness — but the instant it answers, you can walk away from it and still reach the agent. A search provider you can't fire isn't a search provider, it's a registry wearing a different hat.

The six primitives that follow address the first two cases. The third is left to the ecosystem.

1. SVCB Records for the Endpoint Binding (RFC 9460)

Each agent gets one SVCB record at its FQDN. The record carries the target host (in-bailiwick gateway, out-of-bailiwick hosting provider, or . for self-hosted), the ALPN, the port, IP hints, and DNS-AID-specific SvcParamKeys. A client that knows what it's looking for needs exactly one DNS query to find it. For multi-protocol agents, an RRset of SVCB records (one per protocol, keyed by alpn) sits at the same owner name.

2. TLSA Records for Certificate Pinning (RFC 6698)

The DANE pattern, used as designed. A TLSA record at _443._tcp.{target} pins the agent's TLS certificate (or its issuer) so the discoverer can validate the cert against DNS rather than relying purely on the WebPKI. With DNSSEC underneath, that gives the discoverer a chain-of-trust from the IANA root all the way to the agent's certificate. The SVCB record says where the agent is; the TLSA record says what cert it should be using. Together they're the canonical record set.

3. The Zone Index — "Known Provider, Unknown Agent"

_index._agents.{domain} is an SVCB record pointing at a gateway that serves a JSON index over HTTPS, using the well-known SvcParamKey to name the RFC 8615 .well-known/ path.

_index._agents.example.com. SVCB 1 gw.example.com. (alpn=h2 well-known=agent-index.json)

A client that knows the domain but not which agent it wants reads the index once, picks, then does a per-agent SVCB lookup. Optional, skippable, cheap when present. The JSON form (a meaningful shape change from the TXT-list approach in -01) allows richer per-entry metadata than a TXT record's name-and-protocol pair would.

The substrate is deliberately agnostic about where the index actually lives. The SVCB record is one indirection ("go ask this host") and the host can be anything an operator chooses. In practice that ends up looking like one of three deployment shapes:

• Self-hosted. The org runs the gateway. _index._agents.example.com points at gw.example.com, gw.example.com serves agent-index.json from its own .well-known/. Total control, total responsibility. Good fit if you already have an API gateway and a security team who'd object to anything else.
• Commercial agent-listing service. The org points the SVCB at a hosted provider that runs the index for them and exposes a console for adding/removing entries. GoDaddy ANS is one publicly-available example; solo.io's agent gateway is another in an adjacent shape. Same DNS contract: the substrate doesn't care that the gateway happens to be operated by a third party. The org keeps DNS control of _index._agents.{domain}; the provider operates the host the record points at.
• Hybrid. The org runs DNS but defers the JSON to a CDN or a SaaS, by pointing the SVCB TargetName out-of-bailiwick. The trust chain is still anchored in the org's DNSSEC-signed zone; the storage/serving layer is whoever they pick.

The point of letting the index live anywhere is that the org's right to be discovered doesn't bind them to a single platform. Switching providers is a DNS edit. Migrating off entirely is a DNS edit. The federated-by-default property the rest of DNS already has applies here too.

4. Custom SVCB Parameters for Substrate-Level Metadata

Alongside the standard SVCB SvcParamKeys (alpn, port, ipv4hint, ipv6hint, mandatory), DNS-AID layers a small set of agent-relevant keys:

• well-known — RFC 8615 well-known path on the same host as the SVCB target, where the agent's capability descriptor lives (the /.well-known/ prefix is implicit; added in -02 as a sibling to cap)
• cap — capability descriptor locator (URN, JSON-Ref, or other non-RFC-8615 form) for descriptors that aren't served from a /.well-known/ path
• cap-sha256 — base64url SHA-256 of the canonical capability document, for integrity (name unchanged from -01)
• policy — URI of the policy bundle (data handling, jurisdiction, terms)
• realm — multi-tenant scope identifier (matches the realm selector in the EDNS(0) hint work)

These currently sit in the IANA private-use range pending standardization. A mandatory= listing makes specific keys non-skippable for compliant clients (the standard SVCB pattern).

5. Domain Control Validation (DCV)

A stateless challenge/response over a _agents-challenge.{domain} TXT record. Lets one party prove zone control to another without a central authority: the agent-discovery equivalent of the ACME DNS-01 challenge. Merged in infobloxopen/dns-aid-core v0.20.0. Full writeup of the wire format and use cases: DCV — Proving an Agent Belongs to a Domain Without a Central Authority.

6. EDNS(0) Agent-Hint Signaling (Experimental)

A query-time channel from the client toward the substrate. Lets the client signal what kind of agent it's looking for so any hint-aware hop on the resolution path can narrow the result, serve a cached pre-filtered match, or short-circuit a search entirely. Two structural axes: substrate filters (Axis 1, participate in the cache key) and metering / lifecycle (Axis 2, drive request policy without fragmenting the cache). Design rationale: EDNS(0) for Agent Discovery.

How It Started

The conversation started where every IETF conversation starts: with a problem statement. draft-mozley-aidiscovery, the "AI Agent Discovery Problem Statement" authored by Jim Mozley with my contribution, framed what an agent-discovery substrate needs to do without yet committing to how. Three big requirements came out of it:

1. Discovery must work without a central authority. The internet's success at federation is the success to imitate.
2. Discovery must scale to multi-agent workflows. A single human asking a single agent is the easy case; a fan-out of agents asking many other agents is the design constraint.
3. Discovery must compose with existing trust primitives. DNSSEC, X.509, OIDC: already deployed, already understood, already operationally mature.

The DNS-centric answer to those requirements turned into the DNSOP draft, currently at revision -02.

In parallel with the draft, the reference implementation began. The OSS goals were specific: be the thing implementers can run, not just read. PyPI publish, a CLI for sysadmin work, an MCP server so agent runtimes can call the protocol as tools, backends for the major DNS providers, a test suite with adversarial-grade input coverage. The first six months produced the core protocol (publish, discover, verify) plus the cross-domain search path B for opt-in directory deployments. As of v0.20.0 (this week), DCV is in. The next step, EDNS(0) signaling, is in review.

How It's Going

Public progress measures in artifacts:

• The draft — on the public datatracker, looking for a WG-forming BOF in Vienna and hackathon activities. The text is what implementers cite; the conversations around it shape what the next revision will say.
• The reference implementation — Apache-2.0, v0.20.0 shipped with DCV this week. Public CI badges (OpenSSF Scorecard, OpenSSF Best Practices), and security-sensitive contributions routinely go through 2–3 review passes before merge.
• The community site at dns-aid.org: canonical landing for the project, separate from any vendor.
• Framework integrations — early-stage, but the LangChain Community PR is public, adding DnsAidPublishTool / DnsAidDiscoverTool / DnsAidUnpublishTool so a LangChain agent can use DNS-AID without bespoke integration code. More adapters will follow.
• Standards venues — DNSOP, cross-area sessions, agent-focused standards work, and DISPATCH meetings alongside related drafts. Beyond IETF: ISOC's upcoming presentation to the European Multi Stakeholder Platform on ICT Standardisation (the European Commission's coordination forum for ICT standards) carries an honourable mention for DAWN. And ITU-T Study Group 17 has convened Digital Identity Workshops in Geneva on trustable interoperable identities for both human and non-human (agentic) entities; DNS-AID was presented there as one of the proposed substrates for the non-human side.

What I watch most closely: the issue tracker and the review queue. The DCV review surfaced five exploitable paths in the first cut of the verifier, every one of which became a regression test before merge. Subsequent contributions (including the EDNS(0) work currently in review) have been built against the checklist that review produced.

DAWN at IETF 126 Vienna

The next public milestone is DAWN (Discovery of Agents, Workloads, and Named entities), a proposed IETF working group with a public charter draft on GitHub. DAWN's scope is broader than DNS-AID alone: it covers the discovery substrate generally, across centralized, distributed, and hybrid architectures, with terminology, problem-statement, requirements, gap-analysis, and information-model deliverables ahead of any specific protocol selection. The sentence the whole charter turns on:

An interoperable and generic discovery mechanism is needed that builds on existing protocols and tools, benefits from an established trust model, supports proven delegation and federation architectures, and allows organisations to independently publish discovery information.

A BoF at IETF 126 Vienna is targeted, with a hackathon at the same meeting demonstrating DNS-AID as one possible discovery approach to the DAWN problem statement, alongside other candidates. Whether the eventual DAWN work standardizes DNS-AID specifically or something adjacent, the relevant test isn't "did our draft win." The relevant test is whether the field converges on a substrate that's federated, sovereign, and uses the existing trust model. DNS-AID's role at Vienna is to demonstrate that DNS can already carry the load, with running code and a tractable spec.

What's Next

Three open work items are visibly on the horizon:

1. Re-verification scheduling for DCV. A successful verification proves zone control at the moment of verification. Directories listing agents as org-verified need a policy layer on top: a re-verification schedule, a way to expire stale listings, a way to attribute revocations. Open follow-up.
2. HMAC-bound stateless DCV tokens. Currently tokens are random nonces with domain= checked but not cryptographically bound. An HMAC design (challenger holds a signing key; token = HMAC(key, domain ‖ expiry ‖ nonce)) lets verify() detect tampering and removes per-issuance state. Reviewer-flagged follow-up.
3. Hint-aware deployments at scale. The EDNS(0) wire format is in review; the conversation about what programmable hops along the path actually look like (recursive resolvers, forwarders, hint-aware authoritatives) is the conversation that turns the design into deployments.

Less visibly: more drafts to refine, more IETF cycles, more interop tests with the other agent-discovery proposals in the space. The goal isn't to win the proposal beauty contest. The goal is to have a single, well-tested, broadly-adoptable substrate so the agent web doesn't end up as five mutually-incompatible registries with five lock-in stories.

Primary Sources

• draft-mozleywilliams-dnsop-dnsaid-02 — the IETF draft
• draft-mozley-aidiscovery — the problem statement
• infobloxopen/dns-aid-core — the reference implementation
• dns-aid.org — community site
• DAWN charter draft — proposed IETF working group, BoF targeted for IETF 126 Vienna