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 `.`` 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 ., 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, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . 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, . [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, June 2025, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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]