DNS-AID is one of the more interesting Agent SEO ideas because it moves discovery above the page request and into DNS.
That does not make it a universal priority.
As of July 13, 2026, DNS-AID is still an Internet-Draft rather than a broadly implemented web standard. The current draft, draft-mozleywilliams-dnsop-dnsaid-02, was published on May 27, 2026 and describes how publishers could use DNS SVCB records plus a well-known endpoint to help compatible clients discover agent capabilities earlier in the request flow.
For most websites, that means DNS-AID should be treated as optional discovery plumbing, not as a substitute for Technical SEO, robots.txt, Sitemap Checker, or Link Headers for AI Agents.
This article is the practical rollout guide that sits beside the DNS-AID wiki entry, the broader Agent SEO audit, and related discovery layers such as API Catalog SEO and MCP Server Card.
What DNS-AID Currently Means
The current IETF draft covers two core discovery cases:
| Discovery case | What the client already knows | What DNS-AID helps it find |
|---|---|---|
| Known agent | The specific agent hostname | Connectivity details and metadata pointers for that agent |
| Known organization | The organization’s domain | An organization-level index of available agents |
In practice, the model is:
- Query DNS for an SVCB record.
- Learn the target host, protocol suite, port, and metadata pointer.
- Fetch the referenced HTTP resource, such as an agent card or other capability document.
- Validate that the HTTP resource, TLS endpoint, and published capabilities all agree.
That is why DNS-AID is best understood as a discovery accelerator. It can point a compatible client toward real resources faster, but it does not remove the need for those resources to exist and stay accurate.
When DNS-AID Is Worth Testing
Use this fit check before adding it to a roadmap:
| Site type | DNS-AID fit | Better first move |
|---|---|---|
| Marketing site with articles only | Low | Improve crawlability, sitemaps, internal links, and content quality |
| Docs site with no public tools | Low to medium | Add Link Headers for AI Agents and maintain readable docs |
| Product site with a real agent endpoint or public API | Medium to high | Keep API docs, Auth.md and OAuth metadata, and discovery pages accurate first |
| Multi-agent or partner platform | High, but operationally demanding | Treat DNS-AID as one layer in a wider capability-discovery program |
If you do not have a stable agent endpoint, a maintained capability document, and someone who owns DNS operations, DNS-AID is probably premature.
Publish HTTP Discovery Before DNS
DNS-AID should point to honest, already-working resources. Publish these first:
| Asset | Why it should exist first |
|---|---|
robots.txt | Tells crawlers what is allowed before agent-specific work begins |
sitemap.xml | Gives canonical URL coverage for normal discovery |
| HTTP Link headers | Expose related resources from real page responses |
| Public docs or audit hub | Give humans and agents a visible explanation layer |
| API catalog, agent card, or capability page | Provide the actual machine-readable target |
This ordering matters because Google’s current AI optimization guidance still centers on useful content, crawlability, and ordinary search fundamentals. DNS-AID does not skip those requirements.
A Practical Rollout Workflow
1. Choose one public, low-risk endpoint
Start with a real endpoint that already belongs in your public product surface:
- an A2A agent card;
- an authenticated but documented capability hub;
- a real public API with its own API Catalog;
- an agent-readiness page that links to maintained documentation.
Do not start with private admin tools, unstable experiments, or hidden internal services.
2. Publish one agent SVCB record
The draft uses SVCB records for connectivity and metadata pointers. An illustrative record can look like this:
agent-name.example.com. 3600 IN SVCB 1 resource.example.net. (
alpn="a2a,h2"
port=443
well-known="/.well-known/agent-card.json"
)
This says a compatible client should talk to resource.example.net over the declared protocol suite and fetch the referenced metadata path there.
If you support multiple agent protocols, publish separate SVCB records per protocol suite rather than combining unrelated agent protocols in one alpn value.
3. Add an organization index only when you can maintain it
The draft also defines a well-known organization lookup at _index._agents.{domain}.
Illustrative example:
_index._agents.example.com. 3600 IN SVCB 1 agent-index.example.com (
alpn="h2"
port=443
)
This is useful only when the index behind it is real, current, and able to help a client choose among multiple published agents. If you have one experimental endpoint, skip the index.
4. Sign the zone and keep DNS public-data only
The draft treats DNSSEC and endpoint authentication as important trust layers. Operationally, that means:
- enable DNSSEC where your platform supports it;
- keep DNS records free of secrets or private endpoints;
- make sure the target hostname has valid TLS;
- keep the DNS target and HTTP metadata synchronized.
Cloudflare’s DNSSEC documentation is a practical reminder of the operational point: DNS answers are part of a trust chain, not just a naming convenience.
5. Validate the live stack, not just the record
Start with DNS:
dig agent-name.example.com SVCB
dig _index._agents.example.com SVCB
Then validate the referenced HTTP resources:
curl -I https://resource.example.net/.well-known/agent-card.json
curl -I https://example.com/.well-known/api-catalog
curl -I https://example.com/
Finally, review the surrounding public experience with Bot Simulator, Agent SEO audit, and ordinary Technical SEO checks. DNS-AID can be correct while the public page experience is still weak.
A Validation Checklist
Use this checklist before you call DNS-AID “ready”:
| Check | Pass condition |
|---|---|
| Record resolves | The expected SVCB RRset is publicly queryable |
| Target host works | The returned target hostname resolves and serves valid TLS |
| Metadata path works | The well-known or linked resource returns 200 |
| Capability data is current | The published card, catalog, or docs match the live service |
| HTTP discovery agrees | Link headers, docs, and DNS all point to the same resources |
| Auth is documented | Protected workflows link to accurate Auth.md and OAuth metadata or equivalent docs |
| No overclaim | Public copy does not promise rankings, citations, or guaranteed agent support |
Common Mistakes
Avoid these patterns:
- publishing a DNS record before the HTTP resource is stable;
- using DNS-AID for a content-only site with no real agent capability;
- pointing to a private or unmaintained hosted service;
- forgetting DNSSEC or certificate hygiene when asking clients to trust the record chain;
- treating the DNS record as proof that a capability is safe, authorized, or production-ready;
- implying that Google uses DNS-AID as a ranking or AI citation signal.
The pattern is only useful when it reduces ambiguity for a compatible client. If it creates more ambiguity, remove it.
What Fennec Users Should Do Next
If your site already has a real agent endpoint, use this order:
- Verify the basics with Technical SEO, robots.txt, and Sitemap Checker.
- Publish or review your Link Headers for AI Agents and any real API Catalog.
- Make sure capability and auth docs are public, current, and conservative.
- Add one DNS-AID record for one maintained endpoint.
- Test the full chain with Bot Simulator and the Agent SEO audit.
If your site is still mostly content and marketing pages, keep DNS-AID on the watch list and improve the simpler discovery layers first.
Sources
- IETF Internet-Draft: DNS for AI Discovery (draft-mozleywilliams-dnsop-dnsaid-02)
- RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- RFC 8552: Scoped Interpretation of DNS Resource Records through “Underscored” Naming of Attribute Leaves
- RFC 8615: Well-Known Uniform Resource Identifiers (URIs)
- Cloudflare Docs: DNSSEC
- Google Search Central: AI optimization guide
Q&A
Does DNS-AID improve Google rankings or AI citations?
No. DNS-AID is an emerging discovery pattern for compatible agents. It does not guarantee rankings, indexing, citations, or adoption.
Do content-only websites need DNS-AID?
Usually no. Content sites should first keep crawlability, sitemap hygiene, internal links, and useful machine-readable resources healthy.
What should I publish before testing DNS-AID?
Publish the ordinary HTTP discovery layer first: robots.txt, sitemap.xml, relevant Link headers, stable docs, and any real API or agent capability resources the DNS record will reference.
