Network Working Group C. Zhao Internet-Draft 19 August 2026 Intended status: Informational Expires: 20 February 2027 DNS-Based Service Discovery for Agent2Agent (A2A) Protocol Agents draft-zhao-a2a-dns-sd-00 Abstract The Agent2Agent (A2A) protocol defines how two agents communicate once one knows the other's URL, and how an agent's self-description (the Agent Card) is retrieved from a well-known URI at that URL. It does not define how agents on the same host or local network find each other in the first place. This document profiles DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) for that purpose: it defines the "a2a" service type, the TXT record keys used with it, the discovery procedure, and the security model under which discovery results are treated as hints whose trust is established by Agent Card verification, not by the discovery channel. It also requests IANA registration of the "a2a" service name. 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 20 February 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. Zhao Expires 20 February 2027 [Page 1] Internet-Draft A2A DNS-SD August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Service Advertisement . . . . . . . . . . . . . . . . . . . . 3 3.1. Service Type . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Instance Name . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Port . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. TXT Record Keys . . . . . . . . . . . . . . . . . . . . . 4 4. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Agent2Agent (A2A) protocol [A2A] standardises the conversation between two agents: task lifecycle, messages, artifacts, and push notifications. Its discovery story is deliberately minimal: given an agent's URL, a client retrieves the Agent Card from the well-known URI "/.well-known/agent-card.json" (registered with IANA per [RFC8615]). This is resolution, not discovery -- it answers "what can the agent at this address do", not "which agents are reachable from here". The gap is most visible in the smallest deployments. A developer machine running several A2A servers, or a LAN segment hosting a fleet of them, has no standard way for those agents (or for a gateway managing them) to learn of one another; addresses are exchanged by hand. The community has requested exactly this capability [A2A-DISCUSS]. Zero-configuration discovery of link-local services is a solved problem: DNS-Based Service Discovery [RFC6763] over Multicast DNS [RFC6762] is deployed at enormous scale (network printers, media Zhao Expires 20 February 2027 [Page 2] Internet-Draft A2A DNS-SD August 2026 devices). This document applies it to A2A, defining nothing new beyond a service type and three TXT keys. Everything else -- record types, browsing, name resolution -- is used exactly as specified by DNS-SD. Discovery over multicast DNS is trivially spoofable, so this profile is strict about what discovery means: a discovered instance is a hint that an agent may exist at an address. All trust decisions are made from the Agent Card retrieved from that address -- including its signatures ([A2A], Section 8.4.1) -- never from the discovery channel itself (Section 6). 1.1. Applicability This profile targets the link-local scope: a single host or a single network segment. It is complementary to, and does not compete with, directory- or registry-based discovery of agents across networks, which is out of scope for this document. The relationship is the familiar one from printing: a device is discovered on the link with DNS-SD, while global catalogues remain a separate concern. 2. Conventions and Definitions 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. "Agent Card" and "A2A Server" are used as defined by [A2A]. 3. Service Advertisement 3.1. Service Type An A2A Server that wishes to be discoverable on the local link SHOULD advertise a DNS-SD service of type: _a2a._tcp using the advertisement procedures of [RFC6763] over mDNS [RFC6762]. The service name "a2a" is to be registered with IANA (Section 7). Zhao Expires 20 February 2027 [Page 3] Internet-Draft A2A DNS-SD August 2026 3.2. Instance Name The service instance name (the portion of ._a2a._tcp.local.) SHOULD be a human-readable name for the agent, and SHOULD match the name field of the advertised Agent Card where practical. Instance names are user-visible labels per Section 4.1.1 of [RFC6763] and carry no protocol semantics. Note that mDNS responder implementations commonly rewrite characters in instance names (for example, . becomes -). Implementations MUST NOT rely on byte-exact instance names for any purpose, including recognising their own advertisement (Section 5). 3.3. Port The advertised port MUST be the TCP port at which the HTTP endpoint serving the Agent Card (and the A2A service itself, if co-located) is reachable on the advertised host. 3.4. TXT Record Keys The TXT record of an "_a2a._tcp" advertisement uses the key/value syntax of Section 6 of [RFC6763]. This document defines the following keys: Zhao Expires 20 February 2027 [Page 4] Internet-Draft A2A DNS-SD August 2026 +=======+=============+=======================================+ | Key | Requirement | Value | +=======+=============+=======================================+ | card | RECOMMENDED | Absolute path of the Agent Card on | | | | the advertised host and port. | | | | Default when absent: /.well-known/ | | | | agent-card.json. | +-------+-------------+---------------------------------------+ | proto | OPTIONAL | The protocol binding of the | | | | advertised endpoint, matching an | | | | AgentInterface.protocolBinding value | | | | of [A2A], compared case-insensitively | | | | (for example, jsonrpc). | +-------+-------------+---------------------------------------+ | v | OPTIONAL | The A2A protocol version implemented | | | | (for example, 1.0). | +-------+-------------+---------------------------------------+ | tls | OPTIONAL | If present with value 1, the endpoint | | | | requires HTTPS; the URI scheme used | | | | in Section 4 is then https. Absent | | | | or any other value: http. | +-------+-------------+---------------------------------------+ Table 1: TXT record keys for _a2a._tcp Keys not defined here MUST be ignored when not understood. The TXT record MUST NOT carry credentials, tokens, or any information whose disclosure to the local link is sensitive; everything in the advertisement is broadcast in cleartext to all link neighbours. The card, proto, and v keys are advisory conveniences. The authoritative statement of an agent's interfaces, bindings, and protocol version is the Agent Card itself; on any disagreement the Agent Card wins. 4. Discovery Procedure A client discovers A2A agents on the local link as follows: 1. Browse for PTR records of _a2a._tcp.local. per [RFC6763]. 2. For each discovered instance, resolve its SRV and TXT records, and the address records (A/AAAA) of the SRV target. 3. Construct the Agent Card URI: scheme://host:port Zhao Expires 20 February 2027 [Page 5] Internet-Draft A2A DNS-SD August 2026 where scheme is derived from the tls key (Section 3.4), host is an address obtained in step 2 (implementations MAY prefer a routable address over the mDNS hostname, whose .local suffix some resolver stacks cannot process), port is the SRV port, and is the card TXT value or its default. 4. Retrieve the Agent Card with an HTTP GET and validate it, including signature verification where signatures are present ([A2A], Section 8.4.1). 5. Proceed per [A2A]. Nothing about subsequent A2A interaction is modified by this profile. A client MUST treat the outcome of steps 1-3 as unauthenticated input. In particular, a client MUST NOT record a discovered instance in any persistent registry, address book, or trust store on the basis of the advertisement alone; steps 4-5 (and whatever admission policy the client applies to new agents) always intervene. 5. Implementation Notes These notes record behaviour observed in a running implementation of this profile; they are guidance, not protocol requirements. Self-recognition: An agent that both advertises and browses will discover its own advertisement, with an instance name possibly rewritten by the mDNS responder ('.' replaced by '-', among others). Filtering out oneself by exact string comparison therefore fails; implementations should compare normalised names (for example, after removing non-alphanumeric characters) or match on advertised port and local interface addresses. Address selection: SRV targets are mDNS hostnames ending in .local, which HTTP client stacks without an mDNS-aware resolver cannot connect to. Preferring an IPv4/IPv6 address from the additional records avoids the problem. Churn: Discovery lists should reflect the present: an instance whose advertisement goes away (a "goodbye" packet, per [RFC6762]) should leave the list. Durable records of agents belong to whatever registry the client maintains after admission, not to the discovery cache. Zhao Expires 20 February 2027 [Page 6] Internet-Draft A2A DNS-SD August 2026 6. Security Considerations mDNS provides no origin authentication: any node on the link can advertise any instance name, and can answer faster than the honest node. This profile therefore assigns the discovery channel no trust whatsoever: * Discovery output is a hint -- an address worth probing -- never an identity. Identity claims live in the Agent Card, and their verification (TLS where the tls key is set, and Agent Card signatures per [A2A] Section 8.4.1) is what upgrades a hint into an identified peer. An unsigned card retrieved over cleartext HTTP from a discovered address establishes nothing beyond "something answered". * Admission is a separate act. Discovering an agent MUST NOT imply registering, trusting, or routing work to it. Deployments that maintain a roster of admitted agents should gate admission on their own policy (human review, signature verification against known keys, or both). * The advertisement itself leaks presence: on a hostile link, announcing _a2a._tcp reveals that an A2A endpoint exists and on which port. Deployments for which this is unacceptable should not advertise (advertisement is a SHOULD, not a MUST), or should scope advertisement to trusted interfaces. * TXT records are cleartext broadcast; Section 3.4 forbids sensitive content in them. The considerations of [RFC6762] and [RFC6763] apply in full. 7. IANA Considerations IANA is requested to register the following service name in the Service Name and Transport Protocol Port Number Registry, per the procedures of [RFC6335] (service name without port number assignment): Service Name: a2a Transport Protocol: tcp Description: Agent2Agent (A2A) protocol agent discovery Assignee: [[EDITOR NOTE: coordination with the A2A Project (Linux Zhao Expires 20 February 2027 [Page 7] Internet-Draft A2A DNS-SD August 2026 Foundation) is in progress ([A2A-DISCUSS]); the project, as change controller of the associated well-known URI registration, is the preferred assignee. The author stands as assignee of last resort.]] Reference: This document. Defined TXT keys: card, proto, v, tls (see Section 3.4). No new registry is created; per [RFC6763], TXT keys are defined by the specification of the service type. 8. Implementation Status [[Note to the RFC Editor: this section is to be removed before publication, per [RFC7942].]] One independent implementation exists as of August 2026, in a governance-gateway product for A2A agents. It advertises _a2a._tcp on startup, browses continuously, surfaces discovered instances in an operator console for one-click probing (retrieval and inspection of the Agent Card prior to admission), and interoperates with stock Bonjour/Avahi responder stacks. The self-recognition and address selection notes of Section 5 were both learned from live multicast testing of this implementation. 9. References 9.1. Normative References [A2A] A2A Project (Linux Foundation), "Agent2Agent (A2A) Protocol Specification, Version 1.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Zhao Expires 20 February 2027 [Page 8] Internet-Draft A2A DNS-SD August 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [A2A-DISCUSS] "Agent automatic discovery (on local machine / k8s), a2aproject/A2A issue 378", 2025, . [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, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . Acknowledgments The service type and the shape of the local-discovery use case were first proposed in the A2A community by the author of [A2A-DISCUSS]. This document profiles that proposal so that independent implementations interoperate, and adds the registration and security groundwork. Author's Address Changjun Zhao Email: zhaochj@126.com Zhao Expires 20 February 2027 [Page 9]