DNS-Based Service Discovery for Agent2Agent (A2A) Protocol Agents

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. 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

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 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).¶

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

_a2a._tcp

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<card-path>
   

   ¶

   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 <card-path> 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.¶

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 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

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