| Internet-Draft | Abbreviated Title | October 2025 |
| Liang, et al. | Expires 12 April 2026 | [Page] |
This document describes AgentDNS, a root domain naming and service discovery system designed for Large Language Model (LLM) agents. Inspired by the traditional Domain Name System (DNS), AgentDNS enables agents to autonomously discover, resolve, and securely invoke third-party agent and tool services across different vendors. AgentDNS introduces a unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication and billing. The system aims to address interoperability, service discovery, and trust management challenges in large-scale agent collaboration ecosystems.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The rapid evolution of LLM agents across industries has introduced new challenges in enabling seamless multi-agent collaboration. Existing protocols such as the Model Context Protocol (MCP) [MCP-Spec] and Agent-to-Agent (A2A) protocol [A2A-Spec] have improved agent-tool interoperability and communication. However, these efforts lack a standardized root naming and discovery infrastructure to support autonomous cross-vendor interactions. As a result, collaborations between agents still demands significant manual effort, preventing the realization of true autonomous cooperation. The specific challenges are as follows:¶
To address these challenges, this document introduces AgentDNS, the first root domain naming and resolution system designed for LLM agents. Inspired by the Internet's DNS [RFC1035], AgentDNS introduces a unified namespace (agentdns://), natural language-based service discovery, and unified authentication and billing. As shown in Figure 1, AgentDNS is compatible with protocols such as MCP and A2A, allowing them to coexist seamlessly.¶
+-------------------------------------------+
| | AgentDNS Root Server | |
| +----------------------+ AgentDNS DB |
| | LLM | |
+-----------+-------------------------------+
|
+---------------+--------------+
| | |
v | v
+--------------------+ A2A +--------------------+
| Agents (Vendor A) | <-------> | Agents (Vendor B) |
| +----------------+ | | | +----------------+ |
| | Agent Framework| | | | | Agent Framework| |
| +----------------+ | | | +----------------+ |
| | LLM | | | | | LLM | |
+--------------------+ | +--------------------+
| | |
MCP | MCP
| | |
v | v
+--------------------------+ | +--------------------------+
| API & Enterprise Systems | | | API & Enterprise Systems |
+--------------------------+ | +--------------------------+
|
Organizational / Technological Boundary
With AgentDNS, agents can autonomously discover services, authenticate, and interoperate seamlessly across organizational boundaries. AgentDNS redefines the multi-agent collaboration ecosystem through four key functions:¶
Model Context Protocol. The Model Context Protocol (MCP) (Hou et al. 2025) is an open standard developed by Anthropic, designed to facilitate seamless interactions between LLM models and external tools, data sources, and services. Inspired by the concept of a universal adapter, MCP aims to simplify the integration process, much like how a USB-C port allows various devices to connect effortlessly. MCP operates on a client-server architecture. The AI application (such as a chatbot or an integrated development environment) acts as the host and runs an MCP client, while each external integration runs as an MCP server. The server exposes capabilities such as functions, data resources, or predefined prompts, and the client connects to it to utilize these capabilities. This design allows AI models to interact with external systems without directly accessing APIs, thereby enhancing security and reducing the complexity of custom integrations.¶
Agent-to-Agent Protocol. The Agent-to-Agent (A2A) protocol (Google 2025) is introduced by Google, aimed at enabling seamless communication and collaboration between LLM agents, regardless of their underlying frameworks or vendors. A2A was developed in collaboration with over 50 technology partners, including major companies like Atlassian, Salesforce, SAP, and MongoDB. This protocol uses HTTP-based APIs and JSON data format, ensuring compatibility and ease of integration with existing enterprise IT systems. It supports various communication patterns, including request-response, event-based communication, and streaming data exchange. A2A complements protocols like MCP, which focuses on providing tools and context for agents. A2A focuses on agent-to-agent communication, allowing them to work together more effectively.¶
AgentDNS is a root service system for agent service naming, discovery, and resolution, enabling seamless service discovery, cross-vendor interoperability, unified authentication and billing. As shown in Figure 2, the AgentDNS root server is the central hub of the entire system, which connects agent users (e.g., Agent A) with service providers (e.g., Agent Service B, Tool Service D). The AgentDNS root server comprises components including service registration, service proxy pool[RFC5625], service management, service search, service resolution, billing, authentication, etc. The core components are as follows:¶
+-----------------------------------------+
| AgentDNS Root Server |
| +----------------+ +--------------+ |
| | Resolution | | Search | |
| +----------------+ +--------------+ |
| | Billing | | Manage | |
| +----------------+ +--------------+ |
| | Authentication | | Registration | |
| +----------------+ +--------------+ |
| Service Proxy Pool |
| (Agent Svc B, C, Tool Svc D...) |
| |
| +------------------------+ |
| | AgentDNS API Server | |
| +------------------------+ |
+---------------------+-------------------+
▲ ▲
+--------------+ | |
| Agent A |---------------+ |
+--------------+ Natural Lang Query |
| |
| |
| +----------------------+
| | Service Registration |
| +----------------------+
| ▲
| |
| Service Call |
| (Proxy by AgentDns) +---------------------------+
+----------------------> | AgentSvcB, AgentSvcC, ... |
| Tool Service D ... |
+---------------------------+
Together, these components form the backbone of AgentDNS, providing a unified framework that supports natural language-driven discovery, protocol-aware interoperability, trustless authentication, and unified billing-paving the way for truly autonomous multi-agent ecosystems. Next, we will provide a detailed introduction to AgentDNS's service naming, service discovery, service resolution, and unified authentication and billing mechanisms.¶
The AgentDNS service naming system provides a structured and globally unique service identifier name for each registered agent or tool service. The identifier name follows the format as shown in Figure 3. The organization represents the name of the registering entity, such as a company, university, or research lab. Each organization must go through a registration and verification process to ensure uniqueness and authenticity. The category denotes the functional domain or classification of the agent service. This can be chosen manually by the developer or automatically generated by AgentDNS, and it supports hierarchical structures—allowing for multi-level categories using slashes (e.g., academic/nlp/summarization). Finally, the name is the unique identifier for the specific agent within the organization and category. This name must be explicitly defined by the developer. Together, this structured naming convention ensures precise identification, facilitates organized discovery, and supports scalable service management within the AgentDNS ecosystem.¶
Service Identifier Format:
agentdns://{organization}/{category}/{name}
| | | |
Prefix Organization Category Name
Example:
agentdns://example/academic/paperagent
The service discovery process is illustrated in Figure 4. In step 1, Agent A initiates a natural language query to the AgentDNS root server, describing the desired service. In the example, Agent A is looking for an intelligent Agent capable of analyzing academic papers. In step 2, upon receiving the request, AgentDNS searches through its registry of available services to identify those with the required capabilities. It returns a list of service identifiers along with corresponding metadata, such as the proxy's physical address, supported protocols, pricing information, and more. This discovery process employs a hybrid retrieval mechanism that combines keyword matching and RAG. Specifically, we construct a knowledge base using the capability descriptions of registered services. During service discovery, hybrid retrieval is performed over these capability descriptions to identify candidates that best match the user agent's intent. In step 3, after receiving the service information, Agent A uses the appropriate protocol and an authentication token issued by AgentDNS to directly access the physical proxy address and initiate a service call. Finally, in step 4, the AgentDNS proxy forwards the request to the actual service endpoint hosted by the vendor, ensuring seamless interaction between Agent A and the service provider.¶
+------------------+ +------------------------+
| Agent A | | AgentDNS Root Server |
+------------------+ +------------------------+
| ① Prompt: "I need an agent ▲
| for academic paper analysis." |
|----------------------------------------------------->|
| |
| ② Search Result: |
| agentdns://example/academic/paperagent |
|<-----------------------------------------------------|
| |
| v
| ③ Service call +------------------------+
|---------------------------------------> | paperagent proxy |
+------------------------+
|
| ④ Forward
v
+------------------------+
| paperagent |
+------------------------+
As previously mentioned, user agents can cache service identifier names and request the AgentDNS root server for updated metadata when needed. This functionality helps reduce the frequency of accessing AgentDNS, improving response times and lowering operational costs. The service resolution process is illustrated in Figure 5. In step 1, agent vendors update the metadata associated with their agent services. In step 2, Agent A sends a resolution request to the AgentDNS root server, providing the cached service identifier name to retrieve the latest information. In step 3, AgentDNS locates the most recent metadata based on the identifier and returns it to Agent A, ensuring that the service invocation uses up-to-date information.¶
+-------------+ +------------------------+
| paperagent | | AgentDNS Root Server |
+-------------+ +------------------------+
| ▲
① Metadata Update: |
Old metadata -> New metadata |
|------------------------------------------->|
|
|
② Service Resolution:
agentdns://example/academic/paperagent
|
|<-------------------------------------------|
v
+-------------+
| Agent A |
+-------------+
|
③ New metadata
|
v
(uses updated metadata)
AgentDNS introduces a unified authentication and billing mechanism by acting as a proxy layer between user agents and third-party services. As shown in Figure 6, when a user agent (e.g., Agent A) authenticates once with the AgentDNS root server using its own access key (Key A), it gains the ability to seamlessly invoke multiple external agent or tool services without needing to manage individual credentials for each provider. Internally, the AgentDNS root server maintains a service proxy pool that forwards user requests to the corresponding third-party services. For each thirdparty service, the proxy uses the appropriate authentication key (e.g., Key B, C, or D), which corresponds to the access control requirements of the service provider. This abstraction decouples the user agent from vendor-specific authentication logic. Moreover, billing is centralized: user agents are charged by AgentDNS based on their usage, while AgentDNS handles settlements with the respective thirdparty services. This model simplifies cross-vendor interoperability, enforces secure access, and enables consistent billing across a heterogeneous service ecosystem.¶
+--------+ +---------------------------+ +------------------+
| Agent | | AgentDNS Root Server | | Service B |
| A |------->| +-----------------------+ |------->| (via Key B) |
| | Key A | | Service Billing | | +------------------+
+--------+ | +-----------------------+ |
| +-----------------------+ | +------------------+
| | Authentication | |------->| Service C |
| +-----------------------+ | | (via Key C) |
| +-----------------------+ | +------------------+
| | Agent Service B | |
| +-----------------------+ | +------------------+
| +-----------------------+ |------->| Tool Service D |
| | Agent Service C | | | (via Key D) |
| +-----------------------+ | +------------------+
| +-----------------------+ |
| | Tool Service D | |
| +-----------------------+ |
| (Via Service Proxy Pool) |
+---------------------------+
In this section, we present a case study illustrating the interaction between an agent and the AgentDNS root server. The case demonstrates the complete agent workflow—from generating an action plan [huang2024understanding], to querying the AgentDNS root server for service discovery, and finally to executing the planned actions.¶
The full process is illustrated in Figure 7. After receiving a user request—such as “Help me research agent communication protocols and write a survey report”—the agent first invokes a LLM to generate an action plan. As shown in Figure 7, the generated plan in this case is structured in JSON format and consists of multiple steps. Each step includes a description of its purpose, whether it requires a service, and a natural language description of the desired service functionality. These services correspond to third-party agent or tool services. For example, Step 1 requires a search service to retrieve relevant keywords, while Step 3 calls for a standards retrieval service to query documents from organizations like IEEE (IEEE Standards Association 2025) [ieee2025] or ITU-T (International Telecommunication Union 2025) [itut2025].¶
+---------------------------------+ +------------------------------+ +------------------------------+
| Action Plan | | Service Discovery | | Action Execution |
| (Generated by LLM) | | (via AgentDNS Search) | | (Step by step) |
+---------------------------------+ +------------------------------+ +------------------------------+
| steps: | | agentdns://example/search/ | | Execute step 1 |
| 1. Use search engines... | | searchagent | | (Call searchagent) |
| tool_required: true | | - protocol: MCP | +------------------------------+
| tool_function: keyword search| | - cost: $1/million tokens | | Execute step 2 |
| | | - capability: keyword search| | (LLM + Prompt) |
| 2. Analyze communication... | +------------------------------+ +------------------------------+
| tool_required: false | | agentdns://example/standard/ | | Execute step 3 |
| | | standardagent | | (Call standardagent) |
| 3. Summarize standardization | | - protocol: MCP | +------------------------------+
| tool_required: true | | - cost: free | | Execute step 4 |
| tool_function: query IEEE... | | - capability: standard query| | (LLM + Prompt) |
| 4. Write the research report | +------------------------------+ +------------------------------+
+---------------------------------+ ^ ^
| | |
|----------------------------------------------|---------------------------------|
Uses AgentDNS Root Server
After generating the action plan, the agent submits a natural language query to the AgentDNS root server to discover suitable third-party services. For instance, in Step 1, the agent sends the tool function description directly to AgentDNS, which uses intelligent retrieval methods to identify matching services. Suppose AgentDNS returns a service named agentdns://example/search/searchagent; it also provides metadata such as the physical endpoint, supported protocols, service cost, capabilities, and available APIs. The agent uses this information to invoke the selected third-party service.¶
Following service discovery, the agent enters the action execution phase. During this stage, it executes the steps of the action plan in sequence. When a step requires a service, the agent uses the corresponding protocol to access the thirdparty service obtained from AgentDNS and passes the result to the next step. For steps that do not involve external services, the agent inputs the step purpose description, along with previous outputs and prompt instructions, into the LLM for generation. This process continues until all steps in the action plan are completed.¶
This case study presents a simplified example, while in practice, the structure and format of an action plan can be adapted to suit different needs. Importantly, the third-party service descriptions within the action plan are expressed in natural language, which means they are not tightly coupled with specific service identifiers, tool names, or endpoint URLs. AgentDNS plays a critical role in decoupling the foundational agent model from vendor-specific details such as service names, tool identifiers, and physical addresses, enabling more flexible and scalable agent architectures.¶
While AgentDNS addresses fundamental challenges in service discovery, interoperability, and billing in the agent ecosystem, numerous directions remain open for future exploration. These include decentralized and federated architecture, AgentDNS-compatible agent planning LLMs, privacy-preserving [RFC8932] and trusted discovery, as well as AgentDNS service discovery optimization. First, while the current design of AgentDNS adopts a centralized architecture, future iterations may benefit from decentralized or federated [huang2024aggregate] architecture, such as blockchain [karaarslan2018blockchain]. This would improve robustness, reduce the risk of single points of failure, and enhance trust in cross-organizational collaborations. Second, training and fine-tuning agent planning LLMs [wang2023describe] [hu2024agentgen] specifically compatible with AgentDNS is also an important direction. This can involve constructing agent planning datasets and fine-tuning LLMs to enhance their compatibility with AgentDNS. Alternatively, reinforcement learning techniques [wen2024reinforcing] [jin2025search] [qi2024webrl] [peiyuan2024agile] can be used to train agents to autonomously explore and optimize action sequences, dynamically selecting and combining various services registered in AgentDNS to maximize task success rates and efficiency. Third, security and privacy will remain central in crossvendor agent collaboration. Future directions may involve privacy-preserving search and resolution, using technologies such as homomorphic encryption [buban2025encrypted], differential privacy, and secure multi-party computation. AgentDNS could also integrate trust and reputation systems to allow agents to evaluate service quality and security risks before invocation. Finally, the optimization of AgentDNS service discovery and retrieval remains a critical area for improving system performance and user experience.¶
The rapid advancement of LLM agents has exposed critical gaps in cross-vendor service discovery, interoperability, and authentication, hindering the vision of autonomous multiagent collaboration. This document introduces AgentDNS, a unified root domain naming system designed to bridge these gaps by providing a semantically rich namespace, natural language-driven service discovery, protocol-aware interoperability, and trustless authentication and billing. By decoupling agent identifiers from physical addresses and embedding dynamic metadata resolution, AgentDNS enables agents to autonomously discover, resolve, and securely invoke services across organizational and technological boundaries. Our architecture and case studies demonstrate its potential to streamline multi-agent workflows, reduce manual overhead, and foster an open ecosystem for agent collaboration. Future works include decentralized and federated architecture, AgentDNS-compatible agent planning LLMs, privacy-preserving and trusted discovery, as well as AgentDNS service discovery optimization, etc.¶
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶