DNS-AID explained: what it is and why it isn't settled yet

DNS-AID is a proposed DNS-based mechanism for publishing which AI agents a domain operates, using SVCB and TXT records instead of a well-known HTTP path. It is backed by a new Linux Foundation project, but it is not an adopted IETF standard, and the exact record shape it specifies is not yet consistent across its own reference implementation.

What DNS-AID proposes

The pitch is straightforward: instead of an agent probing /.well-known/agent.json or a similar HTTP path to find out what a domain exposes, it queries DNS directly. DNS is already the layer every client resolves before making an HTTP request, it is cacheable, and it does not require the target server to be up. The mechanism leans on RFC 9460 (SVCB and HTTPS resource records), the same record type browsers already use for HTTP/3 and Encrypted Client Hello discovery, repurposed here to point at agent endpoints instead of web servers.

An index record at a well-known name lists the agents a domain publishes; per-agent records then carry the protocol and endpoint details for each one. That is the theory. The practice, as the next two sections show, has not converged yet.

Current spec status

The specification is draft-mozleywilliams-dnsop-dnsaid-02, last updated 2026-05-27. It is an individual Internet-Draft, authored by engineers from Infoblox, Deutsche Telekom, and Amazon. It has not been adopted by the IETF DNSOP working group. That distinction matters: an adopted working group document has group consensus behind its direction, while an individual draft is one team's proposal that may change shape entirely, or not progress at all, before (or instead of) adoption.

The same day, the Linux Foundation announced DNS-AID as a hosted project, initially developed by Infoblox, with Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Internet Systems Consortium, and WWT listed as initial members. A reference implementation shipped alongside the announcement: a Python SDK, a CLI, and an MCP server.

Infoblox has since announced Infoblox IQ, which it describes as the first production system built on DNS-AID and its companion MCP server. None of this makes the underlying draft an IETF standard. A Linux Foundation project and an IETF-track specification are different kinds of legitimacy, and coverage of the launch has largely blurred that line.

The record shape, and why it is not settled

One part of the convention is consistent everywhere we checked: an index record at _index._agents.<domain>, a TXT record listing the domain's published agents, something like agents=chat:mcp,billing:a2a,support:https. Both the draft text and the reference implementation's own docs agree on this part.

The per-agent record is where sources diverge. One documented shape, found in early informal commentary on the launch rather than in the draft text itself, has the protocol as a middle label in a name like _chatbot._mcp._agents.example.com. But the reference implementation's own quickstart shows a different, simpler pattern: an individual agent record directly at {agent-name}.{domain}, with no _agents zone and no protocol label, and only the index living under the well-known name. Two pieces of documentation for the same project describing two different DNS shapes is not a minor inconsistency; it is the kind of thing that breaks interoperability the moment a second implementation shows up.

We checked whether either shape actually exists in the wild by querying the project's own reference domains directly:

$ dig +noall +answer +authority TXT _index._agents.dns-aid.org
dns-aid.org.		3600	IN	SOA	ext-gm.infoblox.com. dns.infoblox.com. 14 10800 3600 1209600 3600

$ dig +noall +answer +authority TXT _index._agents.infoblox.com
_agents.infoblox.com.	3600	IN	SOA	ext-gm.infoblox.com. dns.infoblox.com. 1 10800 3600 1209600 3600

Both queries return only an SOA record in the authority section, meaning the name resolves but nothing is published there. Neither dns-aid.org nor infoblox.com, the project's own domains, has a live DNS-AID record as of this writing. If the standard-bearers have not published one, that is a stronger signal than any changelog about how far from settled this still is.

DNS-AID vs AID: two standards, one initialism

A separate, unrelated proposal called AID (Agent Identity and Discovery), from agentcommunity.org, solves a similar problem with a different, simpler shape: a single TXT record at _agent.<domain>, with an HTTPS .well-known/agent.json fallback. It has different backers, no Linux Foundation involvement, and no SVCB dependency. The two proposals share three letters and a goal, and coverage of either rarely mentions the other exists. If you see "AID" in an agent-discovery context, check which one before assuming it is DNS-AID.

Why nothing is live yet

The draft recommends DNSSEC-signing the zone that carries these records, so a validating resolver can confirm the records were not injected by an on-path attacker. That is a real prerequisite, not a formality: an unsigned agent discovery record is a spoofing vector, since anything an agent trusts as a source of truth for "which endpoints does this domain vouch for" needs to actually come from that domain's zone. Standing up DNSSEC correctly, on top of an already-unsettled record shape, is a second reason production adoption is behind the press coverage.

Should you do anything about this now

Not yet, for most domains. Publishing a record whose shape has not stabilized means republishing it again once the reference implementation and the draft agree with each other, and possibly a third time if the IETF working group adopts the draft with changes. The one exception is if you are directly building against the dns-aid-core reference implementation today and need to track its exact current behavior rather than the draft text.

If your domain already has SVCB or HTTPS records for other reasons (HTTP/3 discovery, Encrypted Client Hello), keep monitoring them regardless of what happens with DNS-AID. WebPixie's DNS monitoring tracks SVCB and HTTPS records alongside the rest of your service and security records, so a change to any of them, whether it is routine or the first sign someone is experimenting with agent discovery on your domain, shows up the same way a changed MX or CAA record would.