Building DNS for AI Agents: Our NANDA Index Implementation
We explained why DNS fails for agents. Here's what we built instead — a production-grade Lean Index with Ed25519-signed records, KV-cached resolution, and rich agent metadata.
From DNS to Agent DNS
DNS maps domain names to IP addresses. It's been doing this brilliantly since 1983. But as we explored in Why DNS Fails for AI Agents, the agentic web needs something fundamentally different: a resolution system that carries trust, capabilities, and protocol metadata — not just addresses.
The NANDA Index paper from MIT Media Lab lays out this vision. We've now built it. Our nexartis-nanda-node is a production-grade NANDA Index node running on Cloudflare Workers — a three-layer resolution system that maps human-readable agent identifiers to cryptographically verifiable metadata and dynamically resolved endpoints.
Agent Name → NANDA Index → AgentAddr → AgentFacts → Agent Endpoint — three layers,
each purpose-built for a different concern: identity, metadata, and connection.AgentAddr: The Lean Record
At the core of the NANDA Index is the AgentAddr — a lightweight, signed pointer to an agent's metadata. Think of it as the agent equivalent of a DNS A record, but with built-in cryptographic verification and metadata pointers.
The NANDA paper targets ≤120 bytes for the core pointer fields of each AgentAddr record — an architectural constraint that enables efficient gossip-based federation (more on that in CRDT Gossip). Lean records mean fast sync, low bandwidth, and edge-cacheable resolution.
AgentAddr Record Structure
{
"agent_id": "@medical-coder",
"public_key_hex": "3b6a27bc...", // Ed25519 verification key
"facts_url": "https://agent.example/agentfacts.json",
"private_url": "https://private.example/facts", // optional
"resolver_url": "https://resolver.example/resolve", // optional
"ttl_seconds": 300,
"signature_hex": "a1b2c3d4...", // Ed25519 over canonical JSON
"signer_id": "did:web:nanda.nexartis.com"
}Every field serves a purpose. The facts_url points to the agent's full AgentFacts metadata — capabilities, trust certifications,
performance data. The private_url enables dual-path discovery where sensitive queries route
through privacy-preserving channels. And the signature_hex is an Ed25519 signature
over the canonical (sorted-key, no-whitespace) JSON serialization of the record.
AgentFacts v2: Rich Agent Metadata
An AgentAddr tells you where to find an agent's metadata. The AgentFacts document tells you everything else — what the agent does, how well it performs, who vouches for it, and how to connect.
Our v2 implementation upgrades AgentFacts from plain JSON to a schema-validated, JSON-LD document wrapped in a W3C Verifiable Credential v2 envelope. This means every AgentFact is cryptographically signed, tamper-evident, and machine-verifiable — the same standard used for digital diplomas and professional credentials, applied to AI agents.
Capabilities & Skills
Structured skill declarations with input/output modes, modalities, and authentication requirements. Compatible with OASF skill taxonomies.
Trust Certifications
Flags like kid-safe, HIPAA, SOC2 — machine-readable compliance markers that enable zero-trust policy evaluation.
Performance Metrics
90-day availability, p95 latency, performance scores — real behavioral data from the Observer network, not self-reported claims.
Content Flags
Descriptors like financial_advice, medical_content — enabling Agentic SafeSearch where orchestrators filter agents by content policy and
jurisdiction.
Revocation is sub-second via Bitstring Status List v1.0. When a credential is revoked — compromised key, failed audit, policy violation — the status list updates propagate through our KV-backed infrastructure in under one second, globally.
The Resolution Pipeline
When an orchestrator asks "find me a medical coding agent with HIPAA certification," here's what actually happens under the hood:
- Index lookup — The request hits our
GET /resolve/:agent_idendpoint. We check the KV edge cache first (key format:addr:{agent_id}). On a hit, we return the cached AgentAddr immediately — sub-millisecond. - D1 fallback — On a cache miss, we query the
agent_addrstable in Cloudflare D1. The record is returned and cached for future requests with the TTL specified in the AgentAddr. - Signature verification — The client verifies the Ed25519 signature against the embedded public key. If the signature doesn't match the canonical serialization, the record is rejected.
- AgentFacts fetch — The client fetches the full AgentFacts document from
the
facts_url(orprivate_urlfor privacy-sensitive queries). The VC envelope is verified against the signer's public key. - Trust evaluation — The orchestrator evaluates trust certifications, reputation scores, and content flags against its policy requirements. Only agents that pass all checks proceed.
- Adaptive resolution — If the AgentAddr includes a
resolver_url, the client can POST a context-aware resolution request for scored, ranked endpoint selection based on geography, load, and capability match.
Performance at the Edge
The entire NANDA Index runs on Cloudflare Workers — meaning resolution happens at the edge, in the datacenter closest to the requesting agent. Combined with KV caching, this delivers resolution latencies that DNS can't match for agent-level queries.
The lean-pointer design of AgentAddr records is key to this performance. By separating the core pointer (AgentAddr) from the rich metadata (AgentFacts), we keep the hot path extremely fast. The index handles resolution; the agent hosts its own facts. This separation mirrors how DNS separates name resolution from content delivery — but with the trust and capability layers that agents actually need.
Cache invalidation follows a cache-aside pattern: on AgentAddr update or revocation, the KV entry is deleted and lazily repopulated on the next read. Federation gossip updates also trigger cache invalidation for records received from peers, ensuring consistency across the mesh.
Getting Started
Registering an agent in the NANDA Index is straightforward. A single POST /register call with your agent's ID and metadata URL automatically generates
a signed AgentAddr, stores it in D1, and caches it at the edge.
For agents already using the A2A or MCP protocols, our Protocol Bridge can auto-detect your protocol and translate your existing metadata into AgentFacts — no manual mapping required.
The research foundations for this work are laid out in the MIT NANDA papers:
- Beyond DNS: Unlocking the Internet of AI Agents — the foundational NANDA Index architecture
- Using the NANDA Index Architecture in Practice — enterprise deployment patterns and ZTAA
- NANDA Adaptive Resolver — dynamic resolution architecture
Further Reading
- Agent Identity URI Scheme: Topology-Independent Naming and Capability-Based Discovery for Multi-Agent Systems (Jan 2026) — proposes a universal agent:// URI scheme for identity
- A Novel Zero-Trust Identity Framework for Agentic AI (May 2025) — decentralized authentication with Agent Naming Service (ANS) for capability-aware discovery
- AgentHub: A Registry for Discoverable, Verifiable, and Reproducible AI Agents (Oct 2025) — explores production agent registry requirements
- Decentralized Identifiers (DIDs) v1.0 — W3C Recommendation — the DID standard that informs our identity layer