more akin to DKIM than MX. AID discovers one endpoint per (host, protocol) pair. It's the bootstrap, not the catalog. The discovered endpoint is typically a gateway, and the application protocol handles enumeration from there. MCP has tools/list, A2A has agent cards, OpenAPI has its schema document. Those are all auth-aware and versionable, and DNS shouldn't try to replicate what they already do well.
For multiple protocol entry points, Section 2.5 defines protocol-specific subdomains (_agent._mcp.example.com, _agent._a2a.example.com). For organizational separation, operators subdivide by host with optional CNAME delegation. The other thing worth mentioning: the AID record optionally carries an Ed25519 public key, and the endpoint proves control of the corresponding private key via RFC 9421 HTTP Message Signatures. Same idea as DKIM, where DNS attests for something delivered via a different channel. That cross-channel property is something application-layer .well-known endpoints can't do for themselves. We wrote up the full case here: https://blog.agentcommunity.org/external_identity_anchor On Wed, Mar 18, 2026 at 8:40 AM Wes Hardaker <[email protected]> wrote: > Balazs Nemethi <[email protected]> writes: > > > AID does one thing: given a domain, find the agent endpoint and figure > out which > > protocol to speak. One TXT record at _agent.<domain>: > > How do you think this will scale when there are potentially many agents > that exist for a single domain name? The scale that some people are > predicting for things like this could likely grow beyond the point that > a DNS RR (of any type) can likely return. Certainly includes are one > option, or defining a endpoint of a particular protocol (URL) to > actually get the real list of agent end points would scale better? > > -- > Wes Hardaker > Google > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- *Balazs Nemethi* Founder, Agent Community <http://agentcommunity.org>
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
