This is the most forward-looking signal on the list, so let me set expectations. DNS-AID is an emerging proposal, not a settled standard. It is good to understand, and if you are technical, worth experimenting with. It is not yet table stakes.
What it is
DNS-AID, “DNS for AI Discovery,” is a way for AI agents to discover and verify your services straight from DNS, before they ever load a web page. The idea is to reuse the infrastructure that already maps names to machines, DNS, rather than invent a new central registry of AI agents.
Where it stands: DNS-AID is an active IETF Internet-Draft (draft-mozleywilliams-dnsop-dnsaid), originated at Infoblox with industry interest from GoDaddy, and it has a reference implementation moving toward the Linux Foundation. “Internet-Draft” is the important phrase. It is a credible, well-sponsored proposal working its way through the standards process, not a ratified RFC and not something the major AI engines consume today. Treat it as an early-mover signal.
Why it matters
DNS is fast, decentralized, and already trusted to point the world at the right servers. Publishing agent and service discovery information there means an AI agent can learn how to reach you, and confirm it is really you, at the DNS layer, without fetching and parsing a page first.
The trust half is the point. Anyone can put a record in a zone they do not control if there is nothing to stop them, which is why DNS-AID leans on DNSSEC. Without a cryptographic signature, a discovery record can be spoofed, and a record an agent cannot trust is worse than no record at all.
How it is structured
DNS-AID publishes agents under a structured underscore namespace in your zone, for example:
_index._agents.example.com # an enumerable index of your agents
_chatbot._mcp._agents.example.com # a specific agent and how to reach itThe primary record type is SVCB (RFC 9460), which carries connectivity and capability details. Plain TXT records are an explicit fallback where SVCB is not available. An agent resolves the record, then verifies the DNSSEC chain (and optionally JWS or DANE policy) before trusting it.
The full, current record schema lives in the IETF draft, which is the authoritative reference, and it is still evolving. If you implement now, follow the draft, not blog summaries.
The part you can act on today: DNSSEC
Even if you are not publishing DNS-AID records yet, the foundation it depends on, DNSSEC, is mature, available, and worth turning on. DNSSEC cryptographically signs your DNS so resolvers can verify the answers are genuine and unmodified. (It provides authentication and integrity, not encryption.)
Most registrars and DNS hosts (Cloudflare, Route 53, and others) can enable DNSSEC in a few clicks. Once it is on, confirm it is validating by checking for the AD (“Authenticated Data”) flag, defined in RFC 4035, which a validating resolver sets when it has verified the full chain of trust:
# Look for "ad" in the flags line of the response header.
dig +dnssec example.com A
# e.g. ;; flags: qr rd ra ad; <- the "ad" means the answer was validatedIf you see ad in the flags, your DNSSEC chain validates, which is the prerequisite for any DNS-AID records to be trustworthy later.
A note on naming
There is a separate, similarly named effort called “Agent Identity and Discovery (AID)” that is a different project. If you go reading, make sure you are looking at DNS-AID (the draft-mozleywilliams draft linked above), not the other one.