DNS-AID: Phone book for AI agents

Contents

The Linux Foundation has announced the open-source project DNS-AID (DNS for AI Discovery). It is intended to make AI agents and agent-based services discoverable via the existing DNS infrastructure and to verify their identity. Instead of relying on central directories or fixed configured endpoints, DNS-AID uses established internet standards and the decentralized structure of the Domain Name System (DNS).

DNS-AID includes an open protocol and a reference implementation for publishing, searching, and verifying AI agents. Infoblox originally developed the project, which is now continuing under the umbrella of the Linux Foundation. In parallel, the IETF is developing the technical specification as an Internet-Draft. The goal is a standardized procedure with which AI agents can automatically find and use the services of other agents.

Publication via DNS Records

At its core, DNS-AID publishes information about agents as DNS records within a domain. Operators register their agents according to the schema _<agentname>._<protocol>._agents.<domain> in their DNS zone – for example, _chatbot._mcp._agents.example.com for an MCP-based chatbot. Other agents then retrieve this information via regular DNS queries and communicate directly with the target system. The project page describes the procedure as a universal discovery method for agents, comparable to the name resolution of websites via DNS.

According to the developers, DNS-AID manages without new DNS record types. The project relies on existing mechanisms such as Service Binding Records (SVCB, RFC 9460), TXT records, and the security standards DNSSEC and DANE/TLSA. SVCB records originally provide additional connection information for network services. DNS-AID uses SVCB records to publish agents, including their endpoints, protocol information, and references to further metadata. Capabilities can be provided directly via DNS records or via linked documents, depending on the implementation.

Three Ways to Discover

Agents can be discovered in three ways: by their name, by specific capabilities, or by a complete catalog of all agents in a domain. Searching for capabilities is suitable, for example, for finding an agent for tasks such as scheduling, support, or bookings within an organization or between partner companies. Alternatively, systems can retrieve an index entry that lists all published agents in a domain.

For trust verification, DNS-AID uses the existing DNS security infrastructure. Public DNS zones are to be signed with DNSSEC so that clients can cryptographically verify the authenticity of the records. Optionally, TLSA records according to the DANE procedure link TLS certificates directly to DNS records. Thus, according to the developers' vision, a continuous chain of trust is created from the DNS root zone to the individual agent.

Protocol-Independent and with Reference Implementation

The protocol does not commit to a specific form of agent communication. MCP, Agent-to-Agent Protocols (A2A), and HTTPS are mentioned, among others. Further protocols can be integrated via ALPN IDs in the SVCB records. ALPN (Application-Layer Protocol Negotiation) is already used today, for example, for negotiating HTTP/2 or HTTP/3.

A reference implementation is available with a Python SDK, a CLI tool, and an MCP server. It supports various DNS backends, including Cloudflare, AWS Route 53, NS1, Google Cloud DNS, and Infoblox NIOS, as well as all DNS servers that support RFC 2136 (Dynamic DNS). It also includes functions for publishing and searching agents, and for validating DNSSEC and DANE information.

The Linux Foundation explicitly describes DNS-AID as an open and vendor-neutral approach for discovering agents. Among the first supporters are Cloudflare, CSC, Equinix, GoDaddy, Indeed, Infoblox, the Internet Systems Consortium (ISC), and WWT.

(fo)