DNS-like Agent Discovery Architecture
draft-yao-dawn-agent-discovery-architect-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jiankang Yao , Guanggang Geng , Meiling Chen , Hongtao Li | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yao-dawn-agent-discovery-architect-00
Internet Engineering Task Force J. Yao
Internet-Draft CNNIC
Intended status: Standards Track G. Geng
Expires: 7 January 2027 Jinan University
M. Chen
China Mobile
H. Li
CNNIC
6 July 2026
DNS-like Agent Discovery Architecture
draft-yao-dawn-agent-discovery-architect-00
Abstract
This document defines a DNS-like three-tier agent-discovery
architecture for the Internet of Agents (IoA). It introduces three
core functional roles: Agent Root, Agent Registry, and Agent
Resolver.
Status of This Memo
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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
Yao, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Agent Discovery July 2026
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Agent Discovery Archtecture . . . . . . . . . . . . . . . . . 4
5. Capability Card Format . . . . . . . . . . . . . . . . . . . 6
6. DNS-like Design . . . . . . . . . . . . . . . . . . . . . . . 7
7. Congigure Agent Client to Discover Local Resolver . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 9
A.1. version 00 . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This draft proposes a three-tier DNS-like discovery architecture with
three distinct roles: Agent Root, Agent Registry and Agent Resolver.
This architecture aligns with the DNS hierarchical paradigm widely
accepted by the internet industry,
Each Agent holds an original FQDN as the registration prefix. After
registering to an Agent Registry with a fixed suffix domain, a
globally unique composite FQDN in the form `<prefix>.`<suffix>` is
generated, where the agents native domain becomes a subdomain of the
registry domain. Agent Root maintains a trusted whitelist of all
Agent Registry suffix domains and distributes the list to all Agent
Resolvers. Agent Resolvers synchronize all agent metadata from
registries via zone transfer or incremental DNS notifications, then
build local capability database. When an agent client requests
agents with specific capabilities, the resolver performs capability
matching and returns complete standardized Capability Card to the
requester.
Yao, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Agent Discovery July 2026
Capability Card adopts fixed JSON format to store DNS service
records, TLS CA certificate information and capability strings. Each
capability description string is limited to 200 characters maximum, a
nd multiple independent capabilities are stored as separate array
entries. Agent clients support two complementary mechanisms to
discover the local Agent Resolver endpoint: static preconfiguration
and DNS-SD dynamic lookup via reserved service label `_agent-
index._tcp`.
2. Terminology
This document makes use of the following terms:
Agent Root: Global top-tier trusted node responsible for managing
the whitelist of all valid Agent Registry suffix domains.
Agent Registry: Domain-level registration service with a fixed
permanent suffix domain, accepting agent registration and hosting
agent DNS records and Capability Card endpoints.
Agent Resolver: Distributed discovery node that stores global agent
metadata and processes capability search requests from agent
clients.
Registration Prefix: Native FQDN owned independently by an agent,
unchanged during registration, e.g., `agent-hotel.example`.
Registration Suffix: Fixed domain assigned to an Agent Registry,
e.g., `example-registry1.com`.
Composite Agent FQDN: Globally unique identity concatenated as
<prefix>.<suffix>, the agent’s native domain acts as a subdomain
of the registry domain.
Agent Client: Any agent instance initiating capability discovery
requests (e.g., Agent A).
Capability Card: Standard JSON document storing agent DNS service
records, TLS CA information and human-readable capability strings,
hosted via HTTPS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Yao, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Agent Discovery July 2026
3. Problem Statement
The anticipated massive deployment of Internet of Agents (IoA) will
bring millions to billions of intelligent agents globally in the
foreseeable future. Efficient, scalable, and standardized discovery
of massive distributed agents becomes a critical unresolved
challenge. The proposed discovery mechanisms should support fast
lookup, unified identity management, and large-scale horizontal
expansion for massive agent clusters. This document specifys a DNS-
like three-tier discovery architecture composed of three core roles:
Agent Root, Agent Registry, and Agent Resolver.
4. Agent Discovery Archtecture
The agent discovery architechture is shown below:
Global Top Trust Layer: Agent Root
+------------------------------------------+
| Agent Root (Global Trust Whitelist Node) |
| - Maintain all trusted Registry Suffixes |
| - Periodically push registry catalog |
+--------------------+---------------------+
^
|
v Periodic Sync (HTTPS/DNS Notify)
+-----------------------------------------------------------------------------+
| Middle Distributed Layer: Multiple Independent Agent Registry Nodes |
| |
| +------------------------+ +------------------------+ |
| | Agent Registry A | | Agent Registry B | |
| | Suffix: reg1.example | | Suffix: reg2.example | |
| | - Accept agent register| | - Accept agent register| |
| | - Generate composite | | - Generate composite | |
| | agent FQDN | | agent FQDN | |
| | - Host Capability Card | | - Host Capability Card | |
| +-----------+------------+ +-----------+------------+ |
| ^ ^ |
| | | |
| | Zone Transfer / DNS Incremental Sync | |
+-----------------------------------------------------------------------------+
| |
v v
+-----------------------------------------------------------------------------+
| Bottom Discovery Layer: Distributed Agent Resolver Cluster |
| |
| +------------------------+ +------------------------+ |
| | Agent Resolver X | | Agent Resolver Y | |
Yao, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Agent Discovery July 2026
| | - Store all agent data | | - Store all agent data | |
| | - Capability string | | - Capability string | |
| | matching engine | | matching engine | |
| | - Serve query API | | - Serve query API | |
| +-----------+------------+ +-----------+------------+ |
| ^ ^
| | | |
| | Client Capability Query (HTTPS API) | |
+-----------------------------------------------------------------------------+
| |
v v
+---------------------------------+ +---------------------------------+
| End Client Layer: Agent Client | | End Client Layer: Agent Client |
| (e.g. Agent A Query Party) | | (e.g. Agent A Query Party) |
| Discovery Modes: | | Discovery Modes: |
| 1. Static config resolver URL | | 1. Static config resolver URL |
| 2. DNS-SD _agent-index._tcp | | 2. DNS-SD _agent-index._tcp |
+---------------------------------+ +---------------------------------+
Fig 1. Agent Discovery Archtecture
The Fig1 shows a top-down hierarchical structure: Agent Root (top
layer), Distributed Agent Registry Cluster (middle layer),
Distributed Agent Resolver Cluster (bottom layer). The end agent
clients send capability queries to nearby local Resolvers.
Agent Root is the unique global trusted root node with mandatory
responsibilities: 1) Receive enrollment applications from new Agent
Registries and complete domain ownership validation; 2) Maintain a
persistent trusted whitelist of all registry suffix domains; 3)
Periodically push the full whitelist to online Agent Resolvers; 4)
Broadcast revocation signals to all Resolvers when a registry is
compromised or malicious.
Mandatory storage constraint: Agent Root MUST NOT store any business
agent data, only lightweight registry metadata including suffix
domain, operator information and sync endpoint to guarantee high
availability.
Yao, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Agent Discovery July 2026
Agent Registry owns a fixed permanent suffix domain. The core duties
are : 1) Process agent registration, update and unregistration
requests; 2) Generate composite global unique FQDN by concatenating
agent prefix and registry suffix; 3) Publish standard A, SVCB and SRV
records on local authoritative DNS servers for registered agents; 4)
Expose public HTTPS endpoints to serve each agent’s Capability Card;
5) Provide zone transfer and DNS incremental sync interfaces for
downstream Agent Resolvers; 6) Maintain agent registration expiration
time and online status.
Agent Resolver acts as the unified public entry for all capability
queries. The core duties are : 1) Periodically pull the latest
trusted registry whitelist from Agent Root; 2) Establish persistent
synchronization connections with each valid registry to pull all
agent metadata; 3) Build local index mapping composite agent FQDN to
full Capability Card and capability string list; 4) Accept capability
search requests from agent clients and execute capability matching;
5) Return complete Capability Card records of all matched agents to
query clients.
5. Capability Card Format
Capability Card is a mandatory fixed-format JSON file hosted via
HTTPS for every registered agent. Format constraints:
Yao, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Agent Discovery July 2026
- Each single capability string inside `capability_list`
MUST NOT exceed 200 UTF-8 characters;
- Multiple independent service capabilities are stored
as separate array items;
- Integrates SVCB/SRV service records, TLS CA fingerprint
and certificate validity window.
Practical example:
Prefix = agent-hotel.example
Suffix = example-registry1.com
Composite global unique agent identity: `agent-hotel.example.example-registry1.com
Template:
json
{
"agent_fqdn": "agent-hotel.example.example-registry1.com",
"dns_service_info": {
"svcb_record": "SVCB 0 mcp agent-hotel.example.example-registry1.com port=443 alpn=h2",
"srv_record": "_mcp._tcp.agent-hotel.example.example-registry1.com"
},
"network_endpoint": "https://agent-hotel.example.example-registry1.com/mcp/v1",
"tls_ca_info": {
"ca_sha256_fingerprint": "E3:4F:2A:89:11:CC:90:7B:...",
"cert_valid_until": "2027-12-31T23:59:59Z"
},
"capability_list": [
"capability1: Provide hotel room online booking, and order status query service",
"capability2: Provide real-time hotel room price inquiry service",
"capability3: Support hotel order cancellation and after-sales processing service"
],
"agent_online_status": "online",
"register_expire_time": "2027-12-31T23:59Z"
}
6. DNS-like Design
The term "DNS-like" used throughout this document indicates that the
proposed three-tier agent discovery architecture borrows core design
paradigms from the Domain Name System (DNS). Specifically, the
architecture adopts three key DNS design concepts: 1) DNS
hierarchical layered partitioning: It follows DNS’s tree-based tiered
delegation model to split global agent identity management into root,
registry, and resolver layers, enabling distributed horizontal
scaling of agent metadata. 2)DNS-style distributed data management:
Similar to how DNS separates authoritative data storage across
disjoint zones, agent registration information is decentralised and
Yao, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Agent Discovery July 2026
maintained by dedicated registry nodes without a single centralised
bottleneck. 3) DNS-inspired asynchronous data replication: The
solution employs zone-data synchronisation mechanisms analogous to
DNS zone transfers, allowing incremental, low-overhead propagation of
agent registration records across hierarchical nodes.
Communication between the Agent Root, Agent Registry, and Agent
Resolver components of this DNS-like three-tier agent discovery
architecture employs standard DNS protocol for data exchange.
Metadata associated with agents is stored and carried in the form of
DNS resource records across all hierarchical nodes. This design
choice leverages DNS’s well-specified wire format, mature message
processing logic, and proven zone s ynchronization mechanisms to
facilitate distributed agent information lookup and cross-layer data
replication.
7. Congigure Agent Client to Discover Local Resolver
Agent clients such as Agent A need to acquire the HTTPS endpoint
address of the local Agent Resolver before sending capability search
requests. Two discovery mechanisms are defined, with DNS-SD as the
recommended primary mode and static preconfiguration as fallback.
8. IANA Considerations
to be added.
9. Security Considerations
to be added
10. Acknowledgements
to be added
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Yao, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Agent Discovery July 2026
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", RFC 9665,
DOI 10.17487/RFC9665, June 2025,
<https://www.rfc-editor.org/info/rfc9665>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Change History
A.1. version 00
1. Initial draft to propose the Agent Discovery Architecture.
Authors' Addresses
Jiankang Yao
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing
Beijing, 100190
China
Phone: +86 10 59116505
Email: yaojk@cnnic.cn
Guanggang
Jinan University
China
Email: gggeng@jnu.edu.cn
Meiling
China Mobile
China
Email: chenmeiling@chinamobile.com
Yao, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Agent Discovery July 2026
Hongtao Li
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing
Beijing, 100190
China
Email: lihongtao@cnnic.cn
Yao, et al. Expires 7 January 2027 [Page 10]