Published February 2026 12 min read

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.

Technical Infrastructure

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.

The resolution flow. 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:

  1. Index lookup — The request hits our GET /resolve/:agent_id endpoint. We check the KV edge cache first (key format: addr:{agent_id}). On a hit, we return the cached AgentAddr immediately — sub-millisecond.
  2. D1 fallback — On a cache miss, we query the agent_addrs table in Cloudflare D1. The record is returned and cached for future requests with the TTL specified in the AgentAddr.
  3. 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.
  4. AgentFacts fetch — The client fetches the full AgentFacts document from the facts_url (or private_url for privacy-sensitive queries). The VC envelope is verified against the signer's public key.
  5. Trust evaluation — The orchestrator evaluates trust certifications, reputation scores, and content flags against its policy requirements. Only agents that pass all checks proceed.
  6. 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.
Federation transparency. If the agent isn't found locally, the resolver checks federated peers via the CRDT gossip protocol. From the client's perspective, it's a single resolution call — the federation layer is invisible.

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.

< 50ms
Cached Resolution (p95)
< 200ms
Uncached Resolution (p95)
≤ 120 B
Core Pointer Target
< 1s
Revocation Propagation

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:

Further Reading

Continue Reading

Coming Soon

By Invitation Only