Network Working Group L. Jakab Internet-Draft F. Brockners Intended status: Informational Cisco Systems Expires: 1 May 2027 28 October 2026 Zero-Configuration Agent Discovery draft-jakab-dawn-agent-discovery-mdns-01 Abstract Protocols for communication between autonomous software agents typically discover agents through documents retrieved over HTTPS from a well-known URI. This model requires a discovering party to already know an agent's host name or URL, or to consult a centralized catalog. It provides no zero-configuration mechanism for enumerating agents that are present on a local network. This document describes how existing, widely deployed protocols, Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD), can be used to advertise and discover agents on a local link, with no new protocol machinery. It presents a general, protocol-independent two- stage discovery model in which lightweight enumeration over DNS-SD is followed by obtaining full agent metadata over the agent's native transport, whether by retrieving a description document or by connecting to the agent and performing its native handshake. The DNS-SD records carry a small set of discovery parameters that is shared with agent discovery in unicast DNS. The document gives worked instantiations of that model for the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP). 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 1 May 2027. Jakab & Brockners Expires 1 May 2027 [Page 1] Internet-Draft Zero-Configuration Agent Discovery October 2026 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases for Discovery of Local Agents . . . . . . . . . . . 5 4. Requirements for Discovery of Local Agents . . . . . . . . . 6 5. DNS-SD and mDNS-Based Solution Approach . . . . . . . . . . . 8 5.1. Agent or Agent Resource Discovery over DNS-SD . . . . . . 9 5.1.1. Carrying the Descriptor: TXT and SVCB . . . . . . . . 11 5.2. Two-Stage Discovery . . . . . . . . . . . . . . . . . . . 11 5.2.1. Stage 1: Browse (DNS-SD) . . . . . . . . . . . . . . 11 5.2.2. Stage 2: Obtain Description and Connect . . . . . . . 12 6. Instantiations . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. A2A . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Service Type and Protocol Identifier . . . . . . . . 13 6.1.2. AgentCard-to-DNS-SD Mapping . . . . . . . . . . . . . 13 6.1.3. Service Instance Name Encoding and Conflicts . . . . 15 6.1.4. TXT Record Keys . . . . . . . . . . . . . . . . . . . 16 6.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. MCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.1. Service Type and Protocol Identifier . . . . . . . . 20 6.2.2. MCP-to-DNS-SD Mapping . . . . . . . . . . . . . . . . 20 6.2.3. Service Instance Name Encoding and Conflicts . . . . 22 6.2.4. TXT Record Keys . . . . . . . . . . . . . . . . . . . 23 6.2.5. Example . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. Other Instantiations . . . . . . . . . . . . . . . . . . 24 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 25 7.1. Discovery Beyond the Local Link . . . . . . . . . . . . . 25 8. Related work . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. LAD-A2A project . . . . . . . . . . . . . . . . . . . . . 26 8.2. MCP DNS discovery . . . . . . . . . . . . . . . . . . . . 26 8.3. OpenClaw project . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 Jakab & Brockners Expires 1 May 2027 [Page 2] Internet-Draft Zero-Configuration Agent Discovery October 2026 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Changes Since Previous Revisions . . . . . . . . . . 32 A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 32 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction AI agents are increasingly being deployed not only as cloud-hosted services, but also as local services running within constrained environments such as developer workstations, laboratories, branch offices, industrial sites, meeting rooms, smart buildings, edge deployments, and other operationally controlled networks. In these environments, agents can provide capabilities such as local inference, device control, data access, workflow automation, observability, robotics coordination, or interaction with nearby tools and systems. For such deployments, agents, clients, orchestrators, and tools need a way to discover one another without relying on manual configuration, fixed addressing, or continuous connectivity to a central registry. Agents can be started and stopped dynamically, moved between hosts, assigned different network addresses, or deployed temporarily for a specific task, experiment, site, or operational context. A discovery mechanism can reduce configuration burden, improve resilience, and allow local agent ecosystems to form and adapt within the boundaries of the environment in which they operate. Agent discovery in these environments has a specific set of requirements. The discovery mechanism needs to be local in scope, suitable for networks ranging from a single link to a site, and usable in networks that are operationally controlled and at least somewhat trusted. It needs to support zero- or low-configuration operation, allow agents to advertise basic service availability, and enable clients to obtain enough information to connect to a more complete agent description or capability manifest. At the same time, discovery ought to avoid exposing sensitive details unnecessarily, ought not be treated as a substitute for authentication or authorization, and ought to allow deployments to apply local policy, segmentation, and access control. Agent communication protocols, including the Agent2Agent (A2A) protocol [A2A] or the Model Context Protocol (MCP) [MCP], generally assume that the party that wishes to connect to an agent or agent Jakab & Brockners Expires 1 May 2027 [Page 3] Internet-Draft Zero-Configuration Agent Discovery October 2026 resource already possesses the resource's host name or URL, or can query a catalog or registry service. Such protocols do not generally provide a mechanism for a party to enumerate agents that are reachable on the local network without prior knowledge of their addresses. This is a common situation when a person, device, or agent enters an unfamiliar local environment, such as a building, venue, home, lab, or operational site, whose local services may be fronted by agents. Because these environments are local, constrained, and operationally managed, a DNS-Based Service Discovery approach may be attractive. In particular, DNS-SD, and where appropriate its use with mDNS, provides a well-established model for discovering services on local networks without requiring prior knowledge of host addresses or a central discovery service. This document explores how a DNS-SD based mechanism could be applied to local agent discovery, while preserving the separation between discovery, agent description, and trust establishment. This document is Informational. It does not modify, and does not define a new profile of, the A2A protocol, the MCP protocol, the DNS protocol, mDNS, or DNS-SD. It describes one possible use of these existing protocols for agent discovery. 2. Terminology This document uses the DNS-SD terminology of [RFC6763], in particular "service type", "service instance", "service instance name", "browse", and "resolve". It uses "AgentCard", "agent", and "session" as described in [A2A], and "MCP server", "MCP endpoint", and "initialize" as described in [MCP]. Where this document refers generically to an advertised entity, the term "agent" is used to include an MCP server. This document adopts the agent-discovery terminology of [I-D.farrel-dawn-terminology] where it applies. In particular, the minimal descriptor that this document carries in DNS-SD records, defined in Section 5.1, is an instance of the "Minimum Discoverable Information" (MDI) of [I-D.farrel-dawn-terminology]: the minimum amount of information an entity needs to provide to become discoverable, acting as the common header that fronts the agent's fuller description. In the two-stage flow of Section 5.2, this MDI is the first-stage information that locates a local agent and points to the full description obtained in the second stage. For clarity, this document uses the following roles: advertising agent: an agent that publishes a DNS-SD service instance Jakab & Brockners Expires 1 May 2027 [Page 4] Internet-Draft Zero-Configuration Agent Discovery October 2026 for itself, directly or through an existing DNS-SD responder. discovering party: a client, often itself an agent acting on behalf of a user, that browses for an agent service type to enumerate advertising agents. 3. Use Cases for Discovery of Local Agents Local agent discovery can be useful in a range of use cases. In each of them, a client does not know in advance which agents are present, and the set changes with location and over time, so it cannot be configured ahead of time. A common theme across these use cases is that they involve operationally controlled and at least somewhat trusted networks, ranging from a single link to a site. * *Visitors in shops, venues, and offices:* A personal agent on a phone or laptop that joins the network of a shop, venue, or office may need to discover the agents that serve that place, such as wayfinding, ordering, or meeting services. The visitor knows neither their names nor any directory in advance. * *Developer and test environments:* A developer workstation, lab network, or test bench may run multiple local agents, such as coding agents, test agents, local model servers, browser automation agents, or tool adapters. Discovery reduces the need for static configuration and allows agents to be started, stopped, or moved dynamically. * *Local tool and capability servers:* An agent runtime may need to discover nearby tool servers, such as file indexers, database proxies, source-control helpers, observability tools, or device- control interfaces. Discovery enables an agent to locate available tools and then retrieve a more complete manifest or capability description. * *Edge and branch deployments:* A branch office, warehouse, retail site, factory cell, or other edge location may contain agents for local inference, sensor processing, caching, monitoring, or automation. Local discovery allows agents and orchestrators to operate even when connectivity to a central registry or cloud service is unavailable. * *Meeting-room and collaboration systems:* A meeting assistant or collaboration agent may need to discover room-local services, such as display agents, transcription agents, camera-control agents, whiteboard agents, or room-control systems. Discovery supports low-configuration pairing within a physical space. Jakab & Brockners Expires 1 May 2027 [Page 5] Internet-Draft Zero-Configuration Agent Discovery October 2026 * *Smart home and smart building environments:* A local automation agent may need to discover agents associated with lighting, climate, energy management, access control, appliances, or building systems. Discovery is useful because devices may join, leave, or change addresses over time. * *Robotics and autonomous systems labs:* A planner, controller, or operator agent may need to discover robot capability agents, such as navigation, mapping, perception, manipulation, docking, or telemetry services. Discovery helps support mobile or modular systems that join and leave the local network. * *Industrial and operational technology environments:* A site-local agent may need to discover equipment-facing agents, telemetry agents, digital-twin interfaces, or inspection systems within an industrial cell or plant-floor segment. * *Temporary, offline, or incident-response networks:* Field deployments, incident-response kits, emergency operations, or temporary collaboration networks may lack reliable DNS, Internet connectivity, or central registries. Local discovery can allow agents to find one another with minimal infrastructure. * *Vehicle, drone, and onboard networks:* An onboard orchestrator may need to discover local agents providing perception, diagnostics, planning, sensor access, or compute services. Discovery can support modular systems and component replacement without fixed addressing. * *Local inventory and observability:* An operator or management agent may need to determine which agent services are present on a local network segment. Discovery can provide a lightweight view of locally available agent endpoints and their basic service types. For a scenario that combines local discovery, as described in this document, with global discovery in unicast DNS, see the stadium use case in [I-D.blwm-dawn-common-discovery-parameters]. 4. Requirements for Discovery of Local Agents This section distills discovery-specific requirements derived from the use cases above. The requirements apply to the mechanism by which a client, orchestrator, tool, or other agent learns that a local agent service exists and obtains enough information to initiate further interaction. Jakab & Brockners Expires 1 May 2027 [Page 6] Internet-Draft Zero-Configuration Agent Discovery October 2026 Requirements related to authentication, authorization, task execution, safety policy, or agent behavior after discovery are outside the scope of discovery. The requirements below are stated descriptively; this document is Informational and uses no normative (BCP 14) language. * *REQ-1: Local discovery scope:* The discovery mechanism needs to support discovery of agent services within a local network or other bounded operational domain. It should not require Internet reachability. * *REQ-2: Low-configuration operation:* The discovery mechanism should minimize the need for static configuration, fixed IP addresses, preconfigured host names, or manually maintained endpoint lists. * *REQ-3: Operation without central infrastructure:* The discovery mechanism should be able to operate when a central registry, cloud service, or site-wide directory is unavailable. This is particularly important for temporary, offline, edge, vehicle, and incident-response networks. * *REQ-4: Dynamic availability:* The discovery mechanism needs to support agents that appear, disappear, restart, move between hosts, or change network addresses. The mechanism needs to provide a way for clients to determine that previously discovered information is no longer valid. * *REQ-5: Multiple agents and multiple instances:* The discovery mechanism needs to support multiple agent services on the same host, multiple hosts on the same local network, and multiple instances of the same agent service type. * *REQ-6: Basic rendezvous information:* The discovery mechanism needs to provide enough information for a client to initiate contact with a discovered agent service. This includes, or enables resolution of, the service endpoint, transport, and port or equivalent connection information. * *REQ-7: Service type identification:* The discovery mechanism should allow clients to distinguish different classes of agent services, such as agent runtimes, tool servers, model-serving agents, device-control agents, observability agents, or capability catalogs. Jakab & Brockners Expires 1 May 2027 [Page 7] Internet-Draft Zero-Configuration Agent Discovery October 2026 * *REQ-8: Minimal discovery metadata:* The discovery mechanism should support limited metadata sufficient for selection and bootstrapping, such as a protocol identifier, version, basic locality hint, or pointer to a more complete agent description. Discovery advertisements should avoid exposing detailed capabilities, sensitive operational context, user data, topology information, or security-sensitive configuration. * *REQ-9: Rendezvous to richer agent description:* The discovery mechanism should allow a discovered service to provide enough information to reach a more complete agent description or capability set, whether that description is a retrievable manifest or document, or is obtained by connecting to the service and performing its native handshake. Retrieval or connection, format, access control, and semantics of that description are separate from basic discovery unless specified elsewhere. * *REQ-10: Local policy compatibility:* The discovery mechanism should be compatible with local administrative controls, including network segmentation, service filtering, interface selection, and restrictions on which services are advertised or discoverable. * *REQ-11: Support for constrained operational environments:* The discovery mechanism should be usable in environments with limited administrative overhead, intermittent connectivity, changing device membership, and local networks ranging from a single link to a site. * *REQ-12: Discovery freshness:* The discovery mechanism needs to provide a way for clients to reason about the freshness of discovered information, for example through lifetimes, expiry, withdrawal, or rediscovery. A more general set of requirements for discovery of agents and agent related resources is found in [I-D.king-dawn-requirements]. 5. DNS-SD and mDNS-Based Solution Approach DNS-Based Service Discovery (DNS-SD) [RFC6763] over Multicast DNS (mDNS) [RFC6762] can address the discovery requirements listed above. DNS-SD over mDNS is a common zero-configuration service discovery technology on local links. It allows a service to advertise its presence, and a client to enumerate available service instances, with no pre-configuration and no central server. DNS-SD is, however, a general framework: by itself it neither names a service type for agents nor describes how to represent agent metadata in DNS-SD records. Jakab & Brockners Expires 1 May 2027 [Page 8] Internet-Draft Zero-Configuration Agent Discovery October 2026 This document describes how DNS-SD and mDNS can be used to discover agents. It does not define new protocol elements. It presents: * a general, protocol-independent model for advertising and discovering agents over DNS-SD, comprising only the "_agents._tcp" and "_agents._udp" service types, with per-protocol subtypes, and a minimal descriptor carried in DNS-SD records, with the agent protocol named in a "proto" key and the descriptor built from the common discovery parameters of [I-D.blwm-dawn-common-discovery-parameters] (Section 5.1); * a two-stage discovery flow that separates lightweight local enumeration from full metadata retrieval (Section 5.2); * worked instantiations of the model for A2A and MCP (Section 6). The model is intended to accommodate further agent protocols. The approach is intentionally compatible with existing DNS-SD tooling and infrastructure. It introduces no new DNS resource record types and requires no changes to mDNS, DNS-SD, or any agent protocol. 5.1. Agent or Agent Resource Discovery over DNS-SD The approach described in this document rests on a small, protocol- independent pattern. It has three elements: 1. A single, protocol-independent DNS-SD service type, "_agents._tcp", that identifies agents on the local link regardless of which agent protocol they speak. The specific agent protocol is not encoded in the service type; instead it is carried in a "proto" TXT key (see element 2), so that a discovering party browses once for "_agents._tcp" and learns the protocol of each discovered agent from its descriptor. A discovering party interested in only one agent protocol can instead browse a per-protocol subtype ([RFC6763], Section 7.1), such as "_a2a._sub._agents._tcp" or "_mcp._sub._agents._tcp"; a subtype names the same protocol as the "proto" key of the instances it lists. Following [RFC6763], Section 7, the service name is "agents", and the second label of the service type names the transport. Agents reachable over TCP use "_agents._tcp"; this includes HTTP-based agents that also offer HTTP/3 over QUIC, which list "h3" in the "alpn" key. The "_agents._udp" service type accommodates agents that are reachable only over a transport other than TCP, such as an agent protocol that runs solely over QUIC; no such protocol is in use today, so this document uses "_agents._tcp" throughout. Jakab & Brockners Expires 1 May 2027 [Page 9] Internet-Draft Zero-Configuration Agent Discovery October 2026 2. A minimal descriptor for each advertised agent, carried in the DNS-SD service instance: the instance name, an SRV record giving the host and port, and exactly one TXT record carrying a small set of key/value pairs. The keys are the common discovery parameters defined in [I-D.blwm-dawn-common-discovery-parameters], which uses the same parameters for DNS-SD and for unicast DNS. The descriptor always begins with a "txtvers" key ([RFC6763], Section 6.7) and includes a "proto" key naming the agent protocol (for example, "proto=a2a"), together with enough rendezvous information to reach the agent's full, authoritative description over the agent protocol's own transport. It is deliberately kept small, and is the Minimum Discoverable Information (MDI) for an agent on the local link: it carries only what a discovering party needs to enumerate candidate agents, learn their protocol, and perform lightweight selection. The parameters used for each protocol are described in Section 6. 3. A two-stage discovery flow (Section 5.2): the DNS-SD descriptor is used for local enumeration, and the full agent description is then obtained over the agent protocol's own transport. Depending on the protocol, this is done either by retrieving a description document (as in A2A) or by connecting to the agent and performing its native handshake (as in MCP). An agent that offers more than one agent protocol is advertised as one service instance per protocol, each with its own SRV and TXT records, rather than as a single instance listing several protocols. When the instances carry the same "desc-ref" value, a reference to an external descriptor of the agent, a discovering party that finds several of them can infer that they belong to the same agent. [I-D.blwm-dawn-common-discovery-parameters] gives an example of such an agent. The value of the pattern is that it reuses zero-configuration discovery and keeps agent-specific descriptions in the agent's native description format rather than attempting to encode them in DNS. A single "_agents._tcp" service type lets a discovering party enumerate all local agents in one browse operation, independent of protocol, and then select among them using the "proto" key and other hints. Section 6 instantiates the pattern for A2A and for the Model Context Protocol as examples; the same pattern applies to further agent protocols by assigning a "proto" value and the corresponding subtype name. Jakab & Brockners Expires 1 May 2027 [Page 10] Internet-Draft Zero-Configuration Agent Discovery October 2026 5.1.1. Carrying the Descriptor: TXT and SVCB This document uses a TXT record ([RFC6763], Section 6) as the default carrier for the descriptor's key/value pairs, because TXT records are supported by essentially all deployed mDNS/DNS-SD implementations, which is what makes the approach usable with no new software. Service Binding (SVCB) records [RFC9460] can carry the same connection and parameter information in a more structured form; [I-D.gakiwate-dnssd-use-svcb] describes how DNS-SD clients can use SVCB records to learn endpoint properties, such as ALPN identifiers. A deployment in which all participating implementations are known to support SVCB over mDNS may use SVCB for greater efficiency. Because SVCB support in mDNS responders and clients is not yet widespread, this document keeps TXT as the interoperable default and treats SVCB as a forward-looking option. This is the reverse of the wide-area DNS-AID approach [I-D.mozleywilliams-dnsop-dnsaid], where SVCB is the primary carrier and TXT a fallback; supporting SVCB here aids compatibility with such wide-area mechanisms. The key names are the same in both carriers: [I-D.blwm-dawn-common-discovery-parameters] defines each parameter for both TXT and SVCB, so a discovering party needs only one vocabulary, and documents the considerations for SVCB in detail, such as the SvcParamKey codes that remain private-use until IANA assigns them. Section 6.1.5 shows an A2A agent advertised with TXT and, for illustration, with SVCB. 5.2. Two-Stage Discovery Discovery proceeds in two stages. The first uses DNS-SD for lightweight, zero-configuration enumeration on the local link. The second uses the agent's native transport to retrieve the complete agent description and to begin a session. This follows the common DNS-SD pattern in which discovery provides rendezvous information and application protocols perform subsequent interaction. 5.2.1. Stage 1: Browse (DNS-SD) A discovering party browses for "_agents._tcp.local.", or for a per- protocol subtype such as "_a2a._sub._agents._tcp.local.", and, for each advertised instance, resolves the SRV and TXT records. From the descriptor it learns the agent protocol (the "proto" key), a reference to an external descriptor of the agent, if any (the "desc- ref" key), the rendezvous information for reaching the full description, and any lightweight selection hints. This is enough to filter candidate agents, including by protocol, without obtaining metadata over the agent's transport. Selecting agents by what they can do, such as their skills or tools, is left to the second stage, where the agent protocol describes these authoritatively. Carrying Jakab & Brockners Expires 1 May 2027 [Page 11] Internet-Draft Zero-Configuration Agent Discovery October 2026 capabilities in DNS-SD records would need a shared vocabulary, would change the records whenever the capabilities change, and would expose details that advertisements should avoid (REQ-8); see [I-D.blwm-dawn-common-discovery-parameters], Appendix B.3. If coarse categories prove necessary, DNS-SD subtypes can provide them, as the per-protocol subtypes do today. 5.2.2. Stage 2: Obtain Description and Connect For a selected candidate, the discovering party obtains the full agent description over the agent protocol's own transport, using the rendezvous information from the descriptor. The form this takes is protocol-specific: for A2A, the party retrieves and validates the AgentCard from a description document; for MCP, it connects to the MCP endpoint and performs the "initialize" handshake. It then selects the protocol-specific connection details (for A2A, an entry from supportedInterfaces), selects an authentication method, and initiates a session according to the agent protocol [A2A] [MCP]. From this point, interaction is governed entirely by the agent protocol; DNS-SD plays no further role. Where the agent protocol has a description document, the descriptor can carry a "desc-ref-digest" key, a digest of that document. A discovering party that already holds a description whose digest matches can reuse it instead of retrieving it again; a mismatch means only that the description has changed. 6. Instantiations This section instantiates the model of Section 5.1 for specific agent protocols. Protocols for communication between autonomous software agents are emerging rapidly. This document gives two instantiations as examples: the Agent2Agent (A2A) protocol [A2A] (Section 6.1) and the Model Context Protocol (MCP) [MCP] (Section 6.2). The two differ in an instructive way. In A2A, an agent publishes a description of itself, an AgentCard, as a JSON document served over HTTPS at a well-known URI, for example, "/.well-known/agent- card.json"; a party wishing to interact with an agent retrieves the AgentCard, selects an authentication method, and initiates a session. In MCP, there is no equivalent static description document: a party connects to the server's endpoint and learns the server's identity, protocol version, and capabilities from the live protocol handshake. The model accommodates both, because the second stage (Section 5.2) is defined as retrieval of the authoritative description by the agent protocol's own means, whether that is fetching a document or performing a handshake. Jakab & Brockners Expires 1 May 2027 [Page 12] Internet-Draft Zero-Configuration Agent Discovery October 2026 6.1. A2A This section describes the model of Section 5.1 for version 1.0.1 of the A2A protocol [A2A]. In that version, an AgentCard declares endpoint interfaces through the ordered supportedInterfaces list. This section is descriptive and does not define a required A2A encoding. 6.1.1. Service Type and Protocol Identifier An A2A agent that participates in local discovery is advertised as a DNS-SD service instance of the protocol-independent service type "_agents._tcp" (Section 5.1), in the "local." domain when using mDNS [RFC6762], and of its "_a2a" subtype. It is identified as an A2A agent by the descriptor key "proto=a2a" in its TXT record (see Section 6.1.4). No A2A-specific service type is defined; a discovering party distinguishes A2A agents from agents of other protocols by the "proto" key, or enumerates only A2A agents by browsing "_a2a._sub._agents._tcp". 6.1.2. AgentCard-to-DNS-SD Mapping The descriptor projects a minimal subset of AgentCard fields and associated publication information onto a DNS-SD service instance. It carries only what is useful for enumeration and lightweight selection; everything else is obtained by retrieving the full AgentCard (see Section 5.2). The mapping described in this document is: Jakab & Brockners Expires 1 May 2027 [Page 13] Internet-Draft Zero-Configuration Agent Discovery October 2026 +=================+=================+===============================+ | Source field or | DNS-SD record | Transformation | | value | | | +=================+=================+===============================+ | (protocol | TXT key proto, | Fixed value a2a, | | identifier) | subtype _a2a | marking the instance as | | | | an A2A agent | +-----------------+-----------------+-------------------------------+ | AgentCard name | Service | Encoded as the instance | | | instance name | label (see | | | | Section 6.1.3) | +-----------------+-----------------+-------------------------------+ | AgentCard name | TXT key title | Copied when the | | | | instance name differs | | | | from it | +-----------------+-----------------+-------------------------------+ | AgentCard URL | SRV target and | Host name and port at | | authority | port | which the AgentCard is | | | | served | +-----------------+-----------------+-------------------------------+ | AgentCard URL | TXT key well- | Suffix after "/.well- | | path | known | known/"; omitted when | | | | the AgentCard is at the | | | | A2A well-known path | +-----------------+-----------------+-------------------------------+ | AgentCard | TXT key desc- | Algorithm-prefixed | | document | ref-digest | digest of the | | | | AgentCard, as a | | | | freshness signal | +-----------------+-----------------+-------------------------------+ | (external | TXT key desc- | Reference to an | | descriptor) | ref | external descriptor of | | | | the agent, such as an | | | | ARD URN or an ANS name | +-----------------+-----------------+-------------------------------+ | interface | TXT key proto- | An A2A protocol version | | protocolVersion | ver | the agent supports, as | | | | an optional selection | | | | hint | +-----------------+-----------------+-------------------------------+ | all other | (not | Obtained by retrieving | | fields | advertised) | the AgentCard (see | | | | below) | +-----------------+-----------------+-------------------------------+ Table 1 Jakab & Brockners Expires 1 May 2027 [Page 14] Internet-Draft Zero-Configuration Agent Discovery October 2026 The SRV record gives the host name and port at which the AgentCard is served. Following [RFC6763], Section 6.3, they are not duplicated in the TXT record. A discovering party reconstructs the AgentCard URL from the SRV target host name and port and the well-known path, using the "https" scheme. When the "well-known" key is absent, the path is the A2A well-known AgentCard path "/.well-known/agent-card.json"; when it is present, the path is "/.well-known/" followed by its value. For example, an SRV record giving host "room1.local" and port 8002, with no "well-known" key, yields the AgentCard URL "https://room1.local:8002/.well-known/agent-card.json". If the port is the default for the scheme, an implementation may omit it from the reconstructed URL. An advertising implementation therefore only needs to include "well-known" when the AgentCard is served at a non- default location. The A2A endpoint URLs are not advertised. They are taken from the supportedInterfaces list of the retrieved AgentCard, which is authoritative for A2A interaction, and they need not share the AgentCard's host name or port. The protocol binding of each interface, and other per-interface values such as tenant, are likewise learned from the AgentCard. The optional "proto-ver" key is only a lightweight selection hint: a discovering party still retrieves the AgentCard and performs A2A interface selection using its supportedInterfaces list. 6.1.3. Service Instance Name Encoding and Conflicts The AgentCard name is used as the initial candidate for the "Instance" portion of the DNS-SD service instance name (._agents._tcp.local.). The A2A specification places no limits on the length or characters of name, while the instance portion is a single DNS label of UTF-8 text in Unicode Normalization Form C, at most 63 octets long and free of ASCII control characters ([RFC6763], Section 4.1.1); with non-ASCII characters taking up to four octets each, as few as 15 characters may fit. The advertising implementation therefore normalizes the name to Normalization Form C before checking it. If the name is empty, contains ASCII control characters, or is longer than 63 octets once encoded, the advertising implementation does not silently truncate or alter it. Instead, it either does not advertise the instance or uses an explicitly configured alternate DNS-SD instance name that meets these rules. With an alternate instance name, it can still carry an AgentCard name that is only too long in the "title" key, which allows up to 249 octets, so that a discovering party can display it. Literal dots and backslashes in the AgentCard name are part of the DNS-SD instance label, not label separators. Implementations that construct or parse DNS presentation-form names need to preserve label Jakab & Brockners Expires 1 May 2027 [Page 15] Internet-Draft Zero-Configuration Agent Discovery October 2026 boundaries. When the instance name is rendered in DNS presentation form, literal dots and backslashes in the instance portion are escaped following [RFC6763], Section 4.3. For example, the instance portion Lab.Agent\One is represented in a full presentation-form service instance name as Lab\.Agent\\One._agents._tcp.local.. If two agents attempt to advertise the same service instance name on the same link, the mDNS conflict-resolution behavior of [RFC6762] applies. An agent that registers with SRP (Section 7.1) meets the same situation when the registrar reports that another agent already holds the name ([RFC9665], Section 3.2.5.2). An advertising implementation that loses the name conflict either chooses a new unique DNS-SD instance name, probes or registers again, and advertises using that name, or fails to advertise if local policy forbids automatic renaming. The final service instance name can therefore differ from the AgentCard name. The advertising implementation can then include the "title" key with the AgentCard name, so that a discovering party can display the agent's name without retrieving the AgentCard. The retrieved AgentCard remains the authoritative source for the agent's name and other A2A metadata. A discovering party that needs to recognize the same agent across renamed instances, or across the instances of an agent that offers several protocols, relies on a shared "desc-ref" value, where present, rather than on the instance name or the "title" key. Instance names are unique only within a link; when advertisements from several links are made visible together (Section 7.1), different agents can appear with the same instance name, and a discovering party can tell them apart by their "desc-ref" values, where present. 6.1.4. TXT Record Keys The TXT record carries the key/value pairs in Table 2, encoded per [RFC6763], Section 6. Jakab & Brockners Expires 1 May 2027 [Page 16] Internet-Draft Zero-Configuration Agent Discovery October 2026 +=================+=============+============================+ | Key | Presence | Value | +=================+=============+============================+ | txtvers | always, | Version of the TXT record | | | first | format, 1 | +-----------------+-------------+----------------------------+ | proto | always | Agent protocol identifier; | | | | fixed value a2a | +-----------------+-------------+----------------------------+ | desc-ref | recommended | Reference to an external | | | | descriptor of the agent, | | | | shared by its instances | +-----------------+-------------+----------------------------+ | desc-ref-digest | recommended | Algorithm-prefixed digest | | | | of the AgentCard, such as | | | | sha-256:... | +-----------------+-------------+----------------------------+ | proto-ver | optional | An A2A protocol version | | | | the agent supports | +-----------------+-------------+----------------------------+ | well-known | when needed | AgentCard suffix under | | | | /.well-known/; omitted for | | | | agent-card.json | +-----------------+-------------+----------------------------+ | title | when needed | AgentCard name, when the | | | | instance name differs from | | | | it | +-----------------+-------------+----------------------------+ | alpn | optional | HTTP versions the endpoint | | | | supports, such as h2,h3 | +-----------------+-------------+----------------------------+ Table 2: TXT record keys for an A2A agent under _agents._tcp The keys, their values, and their requirement levels are defined in [I-D.blwm-dawn-common-discovery-parameters]. This document always includes "proto", because a discovering party that browses "_agents._tcp" learns the protocol of each instance only from this key. When "alpn" is absent, a discovering party uses HTTPS over TCP. Jakab & Brockners Expires 1 May 2027 [Page 17] Internet-Draft Zero-Configuration Agent Discovery October 2026 The descriptor is intentionally small. Fields such as the agent description and version, skills and their tags, authentication schemes, protocol bindings, and input and output modes are not placed in DNS-SD records; they are retrieved from the AgentCard. Capabilities in particular are not advertised: there is no shared vocabulary for them, and they change more often than DNS records should. This keeps the advertisement within the size that DNS-SD carries efficiently (see [RFC6763], Section 6.2, on TXT record sizing) and avoids exposing more agent metadata than enumeration requires. A discovering party can encounter advertisements from independent implementations. It should ignore TXT keys it does not recognize and should tolerate the absence of optional keys. Additional keys may be present; this document does not describe any beyond those above. As in [I-D.blwm-dawn-common-discovery-parameters], the key that names the agent protocol ("proto") is distinct from "alpn", which carries only the HTTP versions an endpoint supports and never names the agent protocol. No key names a protocol binding or transport; for A2A, these are learned from the AgentCard. 6.1.5. Example The following shows the DNS-SD records for an A2A room scheduling agent named "sched", running on host "room1.local" port 8002. Its AgentCard is published at the A2A well-known path "https://room1.local:8002/.well-known/agent-card.json", so the "well- known" key is omitted. It carries the descriptor reference "urn:air:example.com:rooms:sched", supports A2A protocol version "1.0", and advertises the digest of its current AgentCard. _agents._tcp.local. PTR sched._agents._tcp.local. _a2a._sub._agents._tcp.local. PTR sched._agents._tcp.local. sched._agents._tcp.local. SRV 0 0 8002 room1.local. sched._agents._tcp.local. TXT ( "txtvers=1" "proto=a2a" "proto-ver=1.0" "desc-ref=urn:air:example.com:rooms:sched" "desc-ref-digest=sha-256:" ) A discovering party that browses "_agents._tcp.local." or "_a2a._sub._agents._tcp.local." learns of the "sched" instance and sees from "proto=a2a" that it speaks A2A. If the agent is of interest, the party reconstructs the AgentCard URL from the SRV host and port and the default well-known path (no "well-known" key is Jakab & Brockners Expires 1 May 2027 [Page 18] Internet-Draft Zero-Configuration Agent Discovery October 2026 present). If it already holds an AgentCard whose digest matches "desc-ref-digest", it can reuse that AgentCard; otherwise it retrieves the full AgentCard. It then applies the A2A interface- selection rules to the AgentCard's supportedInterfaces list before beginning an A2A session. For illustration, the same instance can be advertised with SVCB (Section 5.1.1). An SVCB record at the service instance name takes the place of both the SRV record, through its TargetName and "port" parameter, and the TXT record, through its SvcParams. The "txtvers" key has no SVCB counterpart, and "alpn" is required in SVCB ([I-D.blwm-dawn-common-discovery-parameters]). A deployment that also serves discovering parties without SVCB support keeps the SRV and TXT records alongside the SVCB record. _agents._tcp.local. PTR sched._agents._tcp.local. _a2a._sub._agents._tcp.local. PTR sched._agents._tcp.local. sched._agents._tcp.local. SVCB 1 room1.local. ( port=8002 alpn=h2 proto=a2a proto-ver=1.0 desc-ref=urn:air:example.com:rooms:sched desc-ref-digest=sha-256: ) 6.2. MCP This section instantiates the model of Section 5.1 for the Model Context Protocol (MCP) [MCP]. It is descriptive and does not define a required MCP encoding. MCP differs from A2A in a way that shapes the instantiation. MCP defines two standard transports: a "stdio" transport, in which a client launches the server as a local subprocess, and a "Streamable HTTP" transport, in which the server exposes a single HTTP endpoint (the "MCP endpoint") that accepts client connections. A client must know which transport a server uses before it can connect; the transport is a property of the deployed server, not something negotiated once connected. The "stdio" transport has no network rendezvous and is out of scope for network discovery; only an MCP server reachable over the Streamable HTTP transport is meaningfully advertised on a local link. Furthermore, core MCP has no static, fetchable description document analogous to the A2A AgentCard. A client learns the server's identity, protocol version, and capabilities by connecting to the MCP endpoint and performing the MCP "initialize" handshake, in which client and server negotiate the protocol version, followed as needed by the "tools/list", "resources/ Jakab & Brockners Expires 1 May 2027 [Page 19] Internet-Draft Zero-Configuration Agent Discovery October 2026 list", and "prompts/list" operations. The second stage (Section 5.2) for MCP is therefore a live handshake against the endpoint, not the retrieval of a document. 6.2.1. Service Type and Protocol Identifier An MCP server that participates in local discovery is advertised as a DNS-SD service instance of the protocol-independent service type "_agents._tcp" (Section 5.1), in the "local." domain when using mDNS [RFC6762], and of its "_mcp" subtype. It is identified as an MCP server by the descriptor key "proto=mcp" in its TXT record (see Section 6.2.4). No MCP-specific service type is defined; a discovering party distinguishes MCP servers from agents of other protocols by the "proto" key, or enumerates only MCP servers by browsing "_mcp._sub._agents._tcp". Subtype names are scoped to their parent service type ([RFC6763], Section 16), so this subtype does not conflict with the unrelated "mcp" entry in the Service Name registry [RFC6335]. 6.2.2. MCP-to-DNS-SD Mapping The descriptor projects a minimal subset of the MCP server's publication information onto a DNS-SD service instance. It carries only what is useful for enumeration and lightweight selection; the authoritative identity, protocol version, and capability set are obtained by connecting to the MCP endpoint and performing the "initialize" handshake (see Section 5.2). The mapping described in this document is: Jakab & Brockners Expires 1 May 2027 [Page 20] Internet-Draft Zero-Configuration Agent Discovery October 2026 +==============+================+===================================+ | Source field | DNS-SD record | Transformation | | or value | | | +==============+================+===================================+ | (protocol | TXT key proto, | Fixed value mcp, marking the | | identifier) | subtype _mcp | instance as an MCP server | +--------------+----------------+-----------------------------------+ | server title | Service | Encoded as the instance | | or name | instance name | label (see Section 6.1.3) | +--------------+----------------+-----------------------------------+ | server title | TXT key title | Copied when the instance | | or name | | name differs from it | +--------------+----------------+-----------------------------------+ | MCP endpoint | SRV target and | The MCP endpoint URL | | authority | port | authority is parsed into | | | | host name and port | +--------------+----------------+-----------------------------------+ | MCP endpoint | TXT key path | Path of the MCP endpoint | | URL path | | URL; always present, because | | | | MCP defines no default | +--------------+----------------+-----------------------------------+ | (external | TXT key desc- | Reference to an external | | descriptor) | ref | descriptor of the agent, as | | | | for A2A | +--------------+----------------+-----------------------------------+ | MCP protocol | TXT key proto- | An MCP protocol version the | | version | ver | server supports, as an | | | | optional selection hint | +--------------+----------------+-----------------------------------+ | all other | (not | Obtained from the | | information | advertised) | "initialize" handshake at | | | | the MCP endpoint | +--------------+----------------+-----------------------------------+ Table 3 Jakab & Brockners Expires 1 May 2027 [Page 21] Internet-Draft Zero-Configuration Agent Discovery October 2026 For the SRV record, the advertising implementation uses the host name and port of the MCP endpoint. Following [RFC6763], Section 6.3, the host name and port are not duplicated in the TXT record. The MCP Streamable HTTP transport requires a server to provide a single HTTP endpoint path, but does not define a default one, so the "path" key, which carries the path component of the MCP endpoint URL, is always included. A discovering party reconstructs the MCP endpoint URL by combining the SRV target host name and port with the "path" value, using the "https" scheme. For example, an SRV record giving host "room1.local" and port 8003 together with "path=/api/mcp" yields the MCP endpoint URL "https://room1.local:8003/api/mcp". If the port is the default for the scheme, an implementation may omit it from the reconstructed URL. No transport key is advertised. The transport is a property of the deployed MCP server that a client needs to know before connecting, because MCP does not negotiate it once connected. The Streamable HTTP transport is, however, the only standard MCP transport that is reachable over the network (see above), so a discovering party uses Streamable HTTP for every MCP server it discovers through this mechanism. The optional "proto-ver" key is a lightweight selection hint only. It carries an MCP protocol version the server supports, in the MCP "YYYY-MM-DD" form. A discovering party still connects to the MCP endpoint and negotiates the protocol version through the MCP "initialize" handshake, which remains authoritative, so a discovering party does not rely on "proto-ver" in place of negotiation. 6.2.3. Service Instance Name Encoding and Conflicts The MCP server's display name is used as the initial candidate for the "Instance" portion of the DNS-SD service instance name: the title in the Implementation information the server reports in the "initialize" handshake, or its name when it has no title. The MCP specification intends name for programmatic or logical use and title for user interfaces, and an instance name is meant to be user-visible ([RFC6763], Section 4.1.1), so title is the better source. The result is encoded and conflict-resolved exactly as described for A2A in Section 6.1.3. When the instance name differs from the server's display name, the advertising implementation can include the display name in the "title" key, as for A2A. As with A2A, a shared "desc- ref" value, where present, rather than the instance name or the "title" key, lets a discovering party recognize the agent if the DNS- SD instance name changes after conflict resolution, and the name and title reported in the "initialize" handshake are authoritative. Jakab & Brockners Expires 1 May 2027 [Page 22] Internet-Draft Zero-Configuration Agent Discovery October 2026 6.2.4. TXT Record Keys The TXT record carries the key/value pairs in Table 4, encoded per [RFC6763], Section 6. +===========+===============+=======================================+ | Key | Presence | Value | +===========+===============+=======================================+ | txtvers | always, | Version of the TXT record format, 1 | | | first | | +-----------+---------------+---------------------------------------+ | proto | always | Agent protocol identifier; fixed | | | | value mcp | +-----------+---------------+---------------------------------------+ | path | always | Path of the MCP endpoint URL; host | | | | and port from SRV | +-----------+---------------+---------------------------------------+ | title | when needed | The server's display name, when the | | | | instance name differs from it | +-----------+---------------+---------------------------------------+ | desc-ref | recommended | Reference to an external descriptor | | | | of the agent, shared by its instances | +-----------+---------------+---------------------------------------+ | proto-ver | optional | An MCP protocol version the server | | | | supports, in YYYY-MM-DD form | +-----------+---------------+---------------------------------------+ | alpn | optional | HTTP versions the endpoint supports, | | | | such as h2,h3 | +-----------+---------------+---------------------------------------+ Table 4: TXT record keys for an MCP server under _agents._tcp The "proto" and "desc-ref" keys carry the same protocol-independent meaning as in the A2A mapping (Section 6.1.4); "path", combined with the SRV host and port, gives the MCP endpoint, the MCP second-stage rendezvous point. It is analogous in role to the A2A AgentCard location, but the endpoint is connected to and handshaked with rather than retrieved as a document. Because core MCP has no description document, the MCP descriptor carries neither "well-known" nor "desc- ref-digest". This mapping advertises no capability hint, for the same reasons as for A2A (Section 6.1.4). An MCP server's capabilities, and its tool, resource, and prompt lists, are dynamic and are obtained authoritatively from the "initialize" handshake and the "tools/list", "resources/list", and "prompts/list" operations in the second stage; a discovering party therefore enumerates MCP capabilities after connecting rather than from the descriptor. Jakab & Brockners Expires 1 May 2027 [Page 23] Internet-Draft Zero-Configuration Agent Discovery October 2026 A discovering party ignores TXT keys it does not recognize and tolerates the absence of optional keys, as described in Section 6.1.4. 6.2.5. Example The following shows the DNS-SD records for an MCP server named "notes", reachable at the Streamable HTTP endpoint "https://room1.local:8003/mcp" on host "room1.local" port 8003. It supports MCP protocol version "2025-11-25". _agents._tcp.local. PTR notes._agents._tcp.local. _mcp._sub._agents._tcp.local. PTR notes._agents._tcp.local. notes._agents._tcp.local. SRV 0 0 8003 room1.local. notes._agents._tcp.local. TXT ( "txtvers=1" "proto=mcp" "path=/mcp" "proto-ver=2025-11-25" "desc-ref=urn:air:example.com:rooms:notes" ) A discovering party that browses "_agents._tcp.local." or "_mcp._sub._agents._tcp.local." learns of the "notes" instance, sees from "proto=mcp" that it speaks MCP, reconstructs the MCP endpoint URL from the SRV host and port and the "path" value, connects using the Streamable HTTP transport, and performs the MCP "initialize" handshake to learn the server's authoritative identity, protocol version, and capabilities before using it. 6.3. Other Instantiations Instantiations of the model (Section 5.1) for agent protocols other than A2A and MCP are left for future work. Under the architecture described in this document, such an instantiation would use the shared "_agents._tcp" service type, define a value for the "proto" TXT key and the corresponding subtype, use the common parameters of [I-D.blwm-dawn-common-discovery-parameters] as lightweight selection hints, and identify how the protocol's full agent description is obtained in the second stage (Section 5.2). Per-protocol browsing uses a subtype of the shared service type; a per-protocol DNS-SD service type would be a different discovery architecture, not an instantiation of the shared-service-type model described here. Jakab & Brockners Expires 1 May 2027 [Page 24] Internet-Draft Zero-Configuration Agent Discovery October 2026 7. Deployment Considerations mDNS is, by design, limited to the local link [RFC6762]. On its own, the approach described here therefore enumerates only agents that are present on the same link as the discovering party. Section 7.1 describes how managed networks extend it beyond the link. Because the second stage uses the agent's own transport and authentication, the reachability of an agent's endpoint is independent of whether the agent was discovered through DNS-SD. Conversely, successful discovery does not imply that the discovered endpoint is reachable, authorized for use, or trusted. Managed networks may filter or constrain multicast traffic. Deployments that rely on DNS-SD over mDNS need to account for local network policy, interface selection, segmentation, and any service- routing or filtering functions that are present in the network. 7.1. Discovery Beyond the Local Link Managed networks, such as enterprise campus and branch networks, typically span many links, and the agents that a discovering party is interested in are not necessarily on its own link. Such networks can extend DNS-SD over mDNS beyond the link with network functions, such as mDNS gateways and proxies, that learn the advertisements on some links and make them available on others under central administration. The Discovery Proxy [RFC8766] is a standardized example: it answers unicast DNS-SD queries with the results of mDNS queries on the links it serves. Agents keep advertising over mDNS. These functions relay the agents' DNS-SD records, with the TXT record unchanged, so the descriptor and the two-stage flow are the same as on a single link. They also give the network operator a central point for visibility into the agents present in the network, and for applying local policy (REQ-10). Agent discovery in unicast DNS uses the same parameters [I-D.blwm-dawn-common-discovery-parameters], so a discovering party can interpret local and global advertisements in the same way. In networks where multicast is constrained, an agent can also register its DNS-SD records by unicast, with the Service Registration Protocol (SRP) [RFC9665]. SRP complements mDNS rather than replacing it: an agent that registers with SRP can keep advertising over mDNS, so discovery on its own link does not depend on the SRP registrar. The agent sends the same PTR, SRV, and TXT records as over mDNS, including the per-protocol subtype, in a single update to the registrar. The registrar publishes them in a unicast DNS domain for the lifetime of a lease, which the agent renews. Following [RFC9665], Section 6.3, that domain is preferably a dedicated subdomain, such as "dnssd.example.com", rather than the Jakab & Brockners Expires 1 May 2027 [Page 25] Internet-Draft Zero-Configuration Agent Discovery October 2026 organization's main zone. A discovering party that learns the domain, for example through DNS-SD domain enumeration ([RFC6763], Section 11), browses it with ordinary unicast DNS queries, and the descriptor and the two-stage flow are again unchanged. Like a gateway, the registrar gives the network operator a central point for visibility and local policy. 8. Related work 8.1. LAD-A2A project The LAD-A2A project [LAD-A2A] also advertises A2A agents on the local link over mDNS, and likewise positions local discovery as a bootstrap that precedes agent interaction. The two efforts are similar in objective and approach, but differ in emphasis: * LAD-A2A is broader in scope and describes the use of mDNS, well- known endpoints, and DHCP options for discovery. It also concentrates on application-layer trust, including TLS, signed AgentCards, decentralized identifiers, and explicit user consent. It uses an A2A-specific service type ("_a2a._tcp"), whereas this document uses the protocol-independent "_agents._tcp" service type with an "_a2a" subtype. * This document focuses on local agent discovery as a protocol- independent model (Section 5.1), using a single service name, "agents", across agent protocols with A2A as one instantiation, and describes a concrete AgentCard-to-DNS-SD field mapping and descriptor (Section 6.1.2, Section 6.1.4). The two approaches can coexist on the same link because DNS-SD service types are independent. An implementation that wants to be discoverable by clients following both approaches could advertise both "_agents._tcp" with proto=a2a and the A2A-specific service type used by LAD-A2A, but such dual advertisement is outside the scope of this document. 8.2. MCP DNS discovery [I-D.morrison-mcp-dns-discovery] describes a DNS-based first-stage rendezvous for Model Context Protocol servers, carried in unicast DNS TXT records at an underscore-prefixed label in the domain's own zone. It performs the same two-stage function as the mechanism described here, with domain rather than link scope. DNS-SD over mDNS enumerates the agents present on a link, whereas unicast DNS enumerates the agents published under a domain, so the two are complementary. The two-stage rendezvous abstraction (a lightweight step that locates a candidate, identifies its protocol family, and Jakab & Brockners Expires 1 May 2027 [Page 26] Internet-Draft Zero-Configuration Agent Discovery October 2026 points to an authoritative description) is not inherently link- scoped; this document instantiates it for the local link, while unicast DNS provides the analogous function at domain scope. 8.3. OpenClaw project OpenClaw [OpenClaw] is an existing deployment of the same pattern. Its gateway advertises a per-application DNS-SD service type (_openclaw-gw._tcp) over mDNS on the local link, carrying a small TXT descriptor of non-secret hints (a role marker, display name, endpoint and port, and a TLS fingerprint); clients, including the OpenClaw iOS and Android companion applications, browse for it to find and connect to a nearby gateway. OpenClaw also offers a wide-area mode using unicast DNS-SD for cross-network discovery, consistent with Section 7. Notably, its own guidance is that the TXT records are unauthenticated and that clients should rely on the resolved endpoint rather than trusting TXT hints, the same posture taken in Section 9 of this document. OpenClaw is thus an independent instance of the general model of Section 5.1, arrived at for a different agent system, which illustrates that agent vendors are adopting mDNS/DNS-SD for the local-discovery step. 9. Security Considerations mDNS and DNS-SD do not authenticate advertisements. On a shared local link, any host can publish an agent service instance, including one that impersonates another agent, and can populate the TXT keys with arbitrary values. The records described in this document, including the "desc-ref" and "title" keys and the reconstructed rendezvous location (the SRV host and port together with a "well- known" or "path" key), are therefore unauthenticated hints and cannot be treated as proof of an agent's identity. In particular, "desc- ref" refers to a descriptor of the agent without proving who operates it, and on the local link "desc-ref-digest" is only a freshness signal: because the advertisement is not authenticated, it provides no integrity protection for the description it refers to. Likewise, "title" is a display name chosen by the advertiser, which can imitate another agent, so a discovering party presents it as an unverified name. A per-protocol subtype narrows browse results but provides no confidentiality; the advertisement remains visible to every host on the link. Jakab & Brockners Expires 1 May 2027 [Page 27] Internet-Draft Zero-Configuration Agent Discovery October 2026 The same holds beyond the link (Section 7.1). A gateway or proxy relays advertisements without making them more trustworthy. SRP's first-come, first-served naming ([RFC9665], Section 3.2.4.1) only prevents another agent from taking over a name that is already registered; it does not establish who operates the agent that registered it. A registrar that accepts registrations only from within its administrative domain ([RFC9665], Section 6.1) limits who can register, but does not vouch for what they register. Trust is established in the second stage, not the first. A discovering party should treat the DNS-SD records only as a means of locating candidate agents, and should authenticate the agent when it connects, using the transport security and authentication mechanisms of the agent protocol. For A2A, this could include TLS server authentication and the authentication schemes declared in the retrieved AgentCard. For MCP, this could include TLS server authentication of the MCP endpoint and any authorization the server requires during or after the "initialize" handshake. In particular, optional selection hints, such as "proto-ver", are advisory and can be forged. They are not a basis for any security decision. Because the SRV host and port and a "well-known" or "path" key cause a discovering party to reconstruct and contact a URL learned from an unauthenticated multicast advertisement, implementations are advised to apply the same caution they would apply to any externally supplied URL. This includes applying local policy to accepted schemes, address ranges, ports, redirects, credentials, and cross-domain requests. In particular, the practice in this document of defaulting the scheme to "https" and, when the "well-known" key is absent, defaulting to the A2A well-known path, does not by itself provide any security guarantee; the reconstructed endpoint is still attacker- influenced and is authenticated only in the second stage. For MCP specifically, connecting to a discovered endpoint means initiating an MCP session with a server chosen from an unauthenticated advertisement. An MCP client should apply its usual protections for connecting to an untrusted MCP server, including validating the endpoint's TLS identity before trusting it, and should not treat tools, resources, or prompts subsequently enumerated from that server as trustworthy solely because the server was discovered on the local link. The MCP transport-security guidance, such as validating the "Origin" header and binding local servers appropriately, continues to apply and is independent of how the server was discovered. Advertising agents expose their existence, and any metadata included in their advertisements, to other hosts on the link and, when their advertisements are made visible beyond the link (Section 7.1), to the Jakab & Brockners Expires 1 May 2027 [Page 28] Internet-Draft Zero-Configuration Agent Discovery October 2026 hosts that can discover them there. Advertising implementations should therefore advertise by default only the keys that a discovering party needs to select and reach the agent, and provide a setting for which optional keys, such as "title", are included, as [OpenClaw] does with its discovery modes. Network operators who consider the set of agents present in their network, their names, or the protocols they speak to be sensitive should account for this exposure and apply local policy (REQ-10). General mDNS and DNS-SD security considerations apply and are discussed in [RFC6762] and [RFC6763]. 10. IANA Considerations IANA is requested to register the following service name in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]: Service Name: agents Transport Protocol(s): TCP, UDP Assignee: IESG (iesg@ietf.org) Contact: IETF Chair (chair@ietf.org) Description: Discovery of AI agents Reference: This document. Uses IP multicast when advertised with mDNS [RFC6762]. Port Number: None Assignment Notes: Defined subtypes: "_a2a", "_mcp". Defined TXT keys: see [I-D.blwm-dawn-common-discovery-parameters]. No port number is needed, because the port is conveyed per instance in the SRV record (see Section 6.1.2). This document uses "_agents._tcp" (Section 5.1). The "udp" registration accommodates agents that are reachable only over a transport other than TCP, such as QUIC (Section 5.1). The subtypes are recorded in the notes field, following [RFC6763], Section 16. Because "_tcp" and "_udp" are already registered in the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552], no registration is needed there. A registry for "proto" key values (the per-protocol agent identifiers, such as "a2a" and "mcp") is a matter for [I-D.blwm-dawn-common-discovery-parameters]; this document does not define one. Jakab & Brockners Expires 1 May 2027 [Page 29] Internet-Draft Zero-Configuration Agent Discovery October 2026 11. Acknowledgements The authors would like to thank Blake Morrison, Chris Hood, Jim Mozley, Michael Richardson, and Nic Williams for their feedback. 12. References 12.1. Normative References [I-D.blwm-dawn-common-discovery-parameters] Brockners, F., Jakab, L., Williams, N., and J. Mozley, "Common Agent DNS Discovery Parameters", Work in Progress, Internet-Draft, draft-blwm-dawn-common-discovery- parameters-00, 27 October 2026, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . 12.2. Informative References [A2A] Linux Foundation, "Agent2Agent (A2A) Protocol Specification, Version 1.0.1", 26 May 2026, . [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-farrel- dawn-terminology-05, 19 October 2026, . Jakab & Brockners Expires 1 May 2027 [Page 30] Internet-Draft Zero-Configuration Agent Discovery October 2026 [I-D.gakiwate-dnssd-use-svcb] Akiwate, G. and T. Pauly, "Use SVCB with DNS Service Discovery", Work in Progress, Internet-Draft, draft- gakiwate-dnssd-use-svcb-00, 28 February 2025, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet- Draft, draft-king-dawn-requirements-02, 19 October 2026, . [I-D.morrison-mcp-dns-discovery] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 21 October 2026, . [I-D.mozleywilliams-dnsop-dnsaid] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27 May 2026, . [LAD-A2A] LAD-A2A Contributors, "LAD-A2A: Local Agent Discovery for A2A", 2025, . [MCP] MCP Community, "Model Context Protocol Specification, Revision 2025-11-25", 25 November 2025, . [OpenClaw] OpenClaw, "OpenClaw Gateway: Bonjour discovery", 2026, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, . Jakab & Brockners Expires 1 May 2027 [Page 31] Internet-Draft Zero-Configuration Agent Discovery October 2026 [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, June 2025, . Appendix A. Changes Since Previous Revisions This section is to be removed before publishing as an RFC. A.1. Since -00 * Uses the common discovery parameters of [I-D.blwm-dawn-common-discovery-parameters], which are shared with agent discovery in unicast DNS, instead of defining its own keys. - Reworks the A2A keys: a2aProtoVer becomes proto-ver; the AgentCard location moves from the full URL in cardUrl to the suffix in well-known; and the AgentCard name moves from agentId to title, which is for display only and is carried only when the instance name differs from the name. - Drops the A2A keys caps, ver (the agent's own version), and a2aBinding, and adds desc-ref and desc-ref-digest. * Renames the service type from _agent._tcp to _agents._tcp, and adds the _a2a and _mcp subtypes for browsing one protocol. * Advertises an agent that offers several protocols as one instance per protocol, linked by desc-ref, with exactly one TXT record per instance, beginning with txtvers. * Points the A2A SRV record at the host that serves the AgentCard; the endpoint URLs now come from the AgentCard, and host and port are no longer repeated in TXT. * Adds an MCP instantiation, and generalizes the second stage to cover both retrieving a description document and performing a native handshake. * Specifies how a name that cannot be a DNS-SD instance name is handled, and takes MCP instance names from the server's title. Jakab & Brockners Expires 1 May 2027 [Page 32] Internet-Draft Zero-Configuration Agent Discovery October 2026 * Adds a use case for visitors in shops, venues, and offices, describes the target networks as ranging from a single link to a site, and points to the stadium use case of the common parameters draft. * Describes discovery beyond the local link, through mDNS gateways and proxies, such as the Discovery Proxy [RFC8766], and optionally through registration with SRP [RFC9665], including how instance names behave there; -00 left discovery across links out of scope. * States that selection by capability is left to the second stage, and why. * Relates the descriptor to the Minimum Discoverable Information of [I-D.farrel-dawn-terminology], adds MCP DNS discovery [I-D.morrison-mcp-dns-discovery] to the related work, and extends the Security Considerations to MCP, desc-ref, desc-ref-digest, title, subtypes, and discovery beyond the link, with advertising implementations, rather than operators, keeping advertisements minimal by default. * Requests registration of the agents service name for TCP and UDP, instead of making no request of IANA. * Adds Acknowledgements, and Toerless Eckert as a contributor. Contributors Alberto Rodriguez-Natal Cisco Systems Email: natal@cisco.com Eric Voit Cisco Systems Email: evoit@cisco.com Pradeep Kathail Cisco Systems Email: pkathail@cisco.com Toerless Eckert Futurewei USA Email: tte@cs.fau.de Jakab & Brockners Expires 1 May 2027 [Page 33] Internet-Draft Zero-Configuration Agent Discovery October 2026 Authors' Addresses Lorand Jakab Cisco Systems Email: lojakab@cisco.com Frank Brockners Cisco Systems Email: fbrockne@cisco.com Jakab & Brockners Expires 1 May 2027 [Page 34]