]>

zhaochj@126.com

ART A2A agent discovery DNS-SD mDNS zeroconf 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.

Introduction The Agent2Agent (A2A) protocol 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 ). 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 . Zero-configuration discovery of link-local services is a solved problem: DNS-Based Service Discovery over Multicast DNS 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 (, Section 8.4.1) -- never from the discovery channel itself ().

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.

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 when, and only when, they appear in all capitals, as shown here. "Agent Card" and "A2A Server" are used as defined by .

Service Advertisement

Service Type An A2A Server that wishes to be discoverable on the local link SHOULD advertise a DNS-SD service of type: using the advertisement procedures of over mDNS . The service name "a2a" is to be registered with IANA ().

Instance Name The service instance name (the <Instance> portion of <Instance>._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 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 ().

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.

TXT Record Keys The TXT record of an "_a2a._tcp" advertisement uses the key/value syntax of Section 6 of . This document defines the following keys: TXT record keys for _a2a._tcp

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 , 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 is then https. Absent or any other value: http.

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.

Discovery Procedure A client discovers A2A agents on the local link as follows:

1. Browse for PTR records of _a2a._tcp.local. per .
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: ]]> where scheme is derived from the tls key (), 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 (, Section 8.4.1).
5. Proceed per . 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.

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 ) should leave the list. Durable records of agents belong to whatever registry the client maintains after admission, not to the discovery cache.

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 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; forbids sensitive content in them.

The considerations of and apply in full.

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 (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 (); 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 ).

No new registry is created; per , TXT keys are defined by the specification of the service type.

Implementation Status [[Note to the RFC Editor: this section is to be removed before publication, per .]] 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 were both learned from live multicast testing of this implementation.

References Normative References As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. A2A Project (Linux Foundation) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Acknowledgments The service type and the shape of the local-discovery use case were first proposed in the A2A community by the author of . This document profiles that proposal so that independent implementations interoperate, and adds the registration and security groundwork.