How a Domain Name Anchors Agent Discovery: The NANDA Index

An AI agent is only useful to other software if that software can find it. A domain name gives that lookup a stable starting point: whoever controls the domain can publish where its agents live, and anyone can check the claim against that domain. This post walks through that idea using the NANDA Index, a project for agent discovery, and a live Namefi demo.

Watch: Project NANDA, how AI agents find each other, starting with DNS

What the NANDA Index does

The NANDA Index maps a stable identifier, such as urn:air:<domain>:agent:<slug>, to the next place to look for an agent. According to the project README, it does not host agents. It tells you where to find them. The resolution chain has three hops:

Requester -> NANDA Index -> registry or card host -> agent runtime

The domain inside the identifier matters. The index's developer documentation says an entry with a domain goes live only after a DNS TXT proof, and the README says the identifier must be anchored to that domain.

How a domain proves ownership

After you create an account and an organization entry, the flow in the developer documentation has three steps:

1. Request a challenge for the organization entry. The index returns a TXT record name, _nanda-challenge.<domain>, and a value of the form nanda-verify=<token>.
2. Publish that record in the domain's DNS zone.
3. Ask the index to check it with POST /api/v1/orgs/<org_id>/verify-domain.

Passing this check requires edit access to the zone. That is the property a domain gives you: control of the name is something a third party can test. For more on this kind of record, see TXT records for SPF, DKIM and verification.

Skipping the index

The index is not the only route. The NANDA Index home page says that for enterprises that publish an AI Catalog at a well-known endpoint and own their domain, direct resolution already works and the index is not in the critical path.

An Internet-Draft from people associated with the project takes the same position. draft-raskar-agentic-web-federated-resolution-02, dated 28 October 2026, is an individual submission with Informational intended status. It is not an IETF standard and has no IETF endorsement. It says a client with a validated direct DNS path should use that path, and that a valid direct DNS record is normally stronger than a registry binding (sections 3.1 and 7.1). Enrollment and proof acquisition are out of scope (section 9.1). The registry is for cases where no usable DNS anchor exists.

For a domain owner, the practical reading is: publish under your own domain first. A registry entry is an extra path to the same place.

Worked example: namefi.io

Namefi is an ICANN-accredited registrar that records domain ownership on-chain. For this demo, the chain from identifier to endpoint is:

The endpoint needs no account and exposes two tools: searchAvailability and dnsOverHttp. These are lookup tools. This post does not describe any purchase or DNS-write feature.

The two files above are live, so you can follow the chain by hand:

curl -s https://namefi.io/.well-known/ai-catalog.json
curl -s https://namefi.io/.well-known/mcp/server-card.json

Through the index, resolution of the same identifier would use the documented resolve route. This will only return an entry after the identifier is registered, which has not happened yet:

curl "https://api.nandaindex.org/api/v1/resolve?locator=urn:air:namefi.io:agent:domains"

To see whether namefi.io has published a challenge record during enrollment:

dig +short TXT _nanda-challenge.namefi.io

What this does not cover

This is a discovery example. A catalog entry says where an agent can be reached. It does not grant the agent any permission, and it does not say who may call it. Keeping discovery, verification and authorization separate is covered in DNS helps agents find services while applications enforce authority. Namefi's existing MCP tools are described in Namefi MCP.

Sources and further reading

• NANDA Index, Developers: identifier form, the _nanda-challenge TXT record, nanda-verify=<token>, and verify-domain.
• NANDA Index, Home: direct resolution for enterprises with a well-known AI Catalog and their own domain.
• projnanda, nanda-index-v2 README: "does not host agents", the three-hop chain, and domain-anchored identifiers.
• Raskar, Sharaf and Chari, draft-raskar-agentic-web-federated-resolution-02 (28 October 2026, individual Internet-Draft): sections 3.1, 7.1 and 9.1.
• Namefi, AI Catalog and MCP server card: the live demo files.