Zero-Configuration Agent Discovery
draft-jakab-dawn-agent-discovery-mdns-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Loránd Jakab , Frank Brockners | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jakab-dawn-agent-discovery-mdns-00
Network Working Group L. Jakab
Internet-Draft F. Brockners
Intended status: Informational Cisco Systems
Expires: 7 January 2027 6 July 2026
Zero-Configuration Agent Discovery
draft-jakab-dawn-agent-discovery-mdns-00
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 retrieval of full agent metadata over the agent's native
transport. It gives a worked instantiation of that model for the
Agent2Agent (A2A) protocol, as an example.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jakab & Brockners Expires 7 January 2027 [Page 1]
Internet-Draft Agent Discovery via mDNS July 2026
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 . . . . . . . . . . . 4
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 . . . . . . 8
5.1.1. Carrying the Descriptor: TXT and SVCB . . . . . . . . 9
5.2. Two-Stage Discovery . . . . . . . . . . . . . . . . . . . 10
5.2.1. Stage 1: Browse (DNS-SD) . . . . . . . . . . . . . . 10
5.2.2. Stage 2: Retrieve and Connect . . . . . . . . . . . . 10
6. Instantiations . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. A2A . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Service Type and Protocol Identifier . . . . . . . . 11
6.1.2. AgentCard-to-DNS-SD Mapping . . . . . . . . . . . . . 11
6.1.3. Service Instance Name Encoding and Conflicts . . . . 13
6.1.4. TXT Record Keys . . . . . . . . . . . . . . . . . . . 13
6.1.5. Example . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Other Instantiations . . . . . . . . . . . . . . . . . . 15
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
8. Related work . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. LAD-A2A project . . . . . . . . . . . . . . . . . . . . . 16
8.2. OpenClaw project . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Jakab & Brockners Expires 7 January 2027 [Page 2]
Internet-Draft Agent Discovery via mDNS July 2026
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 small-to-medium sized networks, 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], generally assume
that the party that wishes to connect to an agent or agent 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.
Jakab & Brockners Expires 7 January 2027 [Page 3]
Internet-Draft Agent Discovery via mDNS July 2026
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].
For clarity, this document uses the following roles:
advertising agent: an agent that publishes a DNS-SD service instance
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. A
common theme across these use cases is that they involve small-to-
medium sized, operationally controlled, and at least somewhat trusted
networks.
* *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-
Jakab & Brockners Expires 7 January 2027 [Page 4]
Internet-Draft Agent Discovery via mDNS July 2026
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.
* *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.
Jakab & Brockners Expires 7 January 2027 [Page 5]
Internet-Draft Agent Discovery via mDNS July 2026
* *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.
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.
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.
Jakab & Brockners Expires 7 January 2027 [Page 6]
Internet-Draft Agent Discovery via mDNS July 2026
* *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.
* *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: Pointer to richer agent description:* The discovery
mechanism should allow a discovered service to provide a reference
to a more complete agent description, manifest, or capability
document. Retrieval, format, access control, and semantics of
that document 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 small-to-medium-scale local networks.
* *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].
Jakab & Brockners Expires 7 January 2027 [Page 7]
Internet-Draft Agent Discovery via mDNS July 2026
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.
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 a single "_agent._tcp"
service type and a minimal descriptor carried in DNS-SD records,
with the agent protocol named in a "proto" key (Section 5.1);
* a two-stage discovery flow that separates lightweight local
enumeration from full metadata retrieval (Section 5.2);
* a worked instantiation of the model for the A2A protocol,
including a mapping from AgentCard fields to DNS-SD records
(Section 6), given as an example. A2A is the only instantiation
included in this document, and the model is intended to
accommodate others.
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,
"_agent._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 "_agent._tcp" and learns the
protocol of each discovered agent from its descriptor. Following
[RFC6763], the application protocol identifier is "agent" and the
transport is TCP.
Jakab & Brockners Expires 7 January 2027 [Page 8]
Internet-Draft Agent Discovery via mDNS July 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 a TXT record carrying a small set of key/
value pairs. The descriptor always includes a "proto" key naming
the agent protocol (for example, "proto=a2a"), and a pointer to
the agent's full, authoritative description. It is deliberately
kept small: it carries only what a discovering party needs to
enumerate candidate agents, learn their protocol, and perform
lightweight selection. Protocol-specific keys can be defined per
protocol (see 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 retrieved over the agent protocol's own transport using the
advertised pointer.
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 "_agent._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 as an example; the same
pattern applies to other agent protocols (for example, the Model
Context Protocol) by assigning a "proto" value and, if needed,
defining protocol-specific descriptor keys.
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, and
their use with DNS-SD is described in [I-D.gakiwate-dnssd-use-svcb].
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.
Jakab & Brockners Expires 7 January 2027 [Page 9]
Internet-Draft Agent Discovery via mDNS July 2026
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 "_agent._tcp.local." and, for each
advertised instance, resolves the SRV and TXT records. From the
descriptor it learns the agent identifier, the agent protocol (the
"proto" key), the pointer to the full description, and any
lightweight selection hints. This is enough to filter candidate
agents, including by protocol, without retrieving metadata over the
agent's transport.
5.2.2. Stage 2: Retrieve and Connect
For a selected candidate, the discovering party retrieves the full
agent description from the advertised pointer (for A2A, the AgentCard
at "cardUrl"), validates it, 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]. From this point, interaction is governed entirely by
the agent protocol; DNS-SD plays no further role.
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. A representative example is the
Agent2Agent (A2A) protocol [A2A], in which 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.
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.
Jakab & Brockners Expires 7 January 2027 [Page 10]
Internet-Draft Agent Discovery via mDNS July 2026
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
"_agent._tcp" (Section 5.1), in the "local." domain when using mDNS
[RFC6762]. 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, not by the service
type.
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:
+=====================================+===========+================+
|Source field or value |DNS-SD |Transformation |
| |record | |
+=====================================+===========+================+
|(protocol identifier) |TXT key |Fixed value a2a,|
| |proto |marking the |
| | |instance as an |
| | |A2A agent |
+-------------------------------------+-----------+----------------+
|name |Service |Encoded as the |
| |instance |instance label |
| |name |(see |
| | |Section 6.1.3) |
+-------------------------------------+-----------+----------------+
|name |TXT key |Copied verbatim |
| |agentId |for explicit |
| | |identification |
+-------------------------------------+-----------+----------------+
|selected supportedInterfaces[].url |SRV target |The selected |
| |and port |interface URL |
| | |authority is |
| | |parsed into host|
| | |name and port |
+-------------------------------------+-----------+----------------+
|selected |TXT key |Copied verbatim |
|supportedInterfaces[].protocolBinding|a2aBinding |as an optional |
| | |selection hint |
+-------------------------------------+-----------+----------------+
Jakab & Brockners Expires 7 January 2027 [Page 11]
Internet-Draft Agent Discovery via mDNS July 2026
|selected |TXT key |Copied verbatim |
|supportedInterfaces[].protocolVersion|a2aProtoVer|as an optional |
| | |selection hint |
+-------------------------------------+-----------+----------------+
|AgentCard URI |TXT key |Full URL from |
| |cardUrl |which the |
| | |AgentCard |
| | |document is |
| | |retrieved |
+-------------------------------------+-----------+----------------+
|skills[].tags |TXT key |Skill tags |
| |caps |concatenated |
| | |into a comma- |
| | |separated list |
+-------------------------------------+-----------+----------------+
|version |TXT key ver|Copied verbatim |
+-------------------------------------+-----------+----------------+
|all other fields |(not |Obtained by |
| |advertised)|retrieving the |
| | |AgentCard via |
| | |cardUrl |
+-------------------------------------+-----------+----------------+
Table 1
For the SRV record, the advertising implementation selects one
supportedInterfaces entry to advertise. Unless local policy
specifies a different choice, the selected entry is the first entry
in the ordered supportedInterfaces list that the agent intends to
expose on the local link and whose URL scheme can be represented by
DNS-SD SRV rendezvous information, such as http or https. If the
selected URL does not include an explicit port, the port is inferred
from the URL scheme. The selected URL's path, query, fragment, and
scheme are not represented in the SRV record; the full selected
interface URL in the retrieved AgentCard remains authoritative for
A2A interaction.
The optional a2aBinding and a2aProtoVer TXT keys are only lightweight
selection hints. A discovering party still retrieves the AgentCard
at cardUrl and performs A2A protocol selection using the AgentCard's
supportedInterfaces list. Other per-interface values, such as
tenant, are not advertised in DNS-SD by this mapping and are learned
from the AgentCard. The cardUrl TXT key identifies the URL from
which the AgentCard itself can be retrieved.
Jakab & Brockners Expires 7 January 2027 [Page 12]
Internet-Draft Agent Discovery via mDNS July 2026
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
(<Instance>._agent._tcp.local.). The instance portion is encoded as
a single DNS label using the Net-Unicode/UTF-8 DNS-SD rules of
[RFC6763], Section 4.1.1. If the resulting label would exceed 63
octets, or otherwise cannot be represented as a single valid DNS
label, the advertising implementation does not silently truncate it.
Instead, it either does not advertise the instance or uses an
explicitly configured alternate DNS-SD instance name that fits within
the DNS label limit.
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
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._agent._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 advertising implementation that loses the name conflict
either chooses a new unique DNS-SD instance name, probes 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. In that case, the TXT
agentId value continues to carry the original AgentCard name as a
programmatically visible value, while the service instance name is
the link-local DNS-SD name selected after any conflict resolution.
The AgentCard retrieved from cardUrl remains the authoritative source
for the A2A agent metadata.
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 7 January 2027 [Page 13]
Internet-Draft Agent Discovery via mDNS July 2026
+=============+==========+=======================================+
| Key | Presence | Value |
+=============+==========+=======================================+
| proto | required | Agent protocol identifier; fixed |
| | | value a2a |
+-------------+----------+---------------------------------------+
| agentId | required | Verbatim AgentCard name, independent |
| | | of DNS-SD label changes |
+-------------+----------+---------------------------------------+
| cardUrl | required | Full URL from which the AgentCard |
| | | document is retrieved |
+-------------+----------+---------------------------------------+
| caps | optional | Comma-separated list of capability |
| | | tags from skills[].tags |
+-------------+----------+---------------------------------------+
| ver | optional | AgentCard version |
+-------------+----------+---------------------------------------+
| a2aBinding | optional | Selected |
| | | supportedInterfaces[].protocolBinding |
+-------------+----------+---------------------------------------+
| a2aProtoVer | optional | Selected |
| | | supportedInterfaces[].protocolVersion |
+-------------+----------+---------------------------------------+
Table 2: TXT record keys for an A2A agent under _agent._tcp
The descriptor is intentionally small. Fields such as the agent
description, full capability object, detailed skill definitions,
authentication schemes, and input and output modes are not placed in
DNS-SD records; they are retrieved from the AgentCard at cardUrl.
This keeps the advertisement within the size that DNS-SD carries
efficiently (see [RFC6763], Section 6.1, 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.
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 "https://room1.local:8002/.well-known/
agent-card.json", has AgentCard version "2.3.0", lists skill tags
"scheduling" and "calendar", and has a selected supportedInterfaces
entry using protocolBinding "JSONRPC" and protocolVersion "1.0".
Jakab & Brockners Expires 7 January 2027 [Page 14]
Internet-Draft Agent Discovery via mDNS July 2026
_agent._tcp.local. PTR sched._agent._tcp.local.
sched._agent._tcp.local. SRV 0 0 8002 room1.local.
sched._agent._tcp.local. TXT "proto=a2a" "agentId=sched"
"cardUrl=https://room1.local:8002/.well-known/agent-card.json"
"caps=scheduling,calendar" "ver=2.3.0"
"a2aBinding=JSONRPC" "a2aProtoVer=1.0"
A discovering party that browses "_agent._tcp.local." learns of the
"sched" instance, sees from "proto=a2a" that it speaks A2A, and, if
the advertised capabilities and interface hints are of interest,
retrieves the full AgentCard from the cardUrl value. It then applies
the A2A interface-selection rules to the AgentCard's
supportedInterfaces list before beginning an A2A session.
6.2. Other Instantiations
Instantiations of the model (Section 5.1) for agent protocols other
than A2A are left for future work. Under the architecture described
in this document, such an instantiation would use the shared
"_agent._tcp" service type, define a value for the proto TXT key,
identify any protocol-specific TXT keys used as lightweight selection
hints, and identify the pointer used to retrieve the protocol's full
agent description in the second stage (Section 5.2). A per-protocol
DNS-SD service type would be a different discovery architecture, not
an instantiation of the shared-service-type model described here.
7. Deployment Considerations
mDNS is, by design, limited to the local link [RFC6762]. The
approach described here therefore enumerates only agents that are
present on the same link as the discovering party. Discovery across
links is outside the scope of this document. It can be provided by
existing DNS-SD facilities for wide-area and aggregated service
discovery, without changing the descriptor or the two-stage flow
described here.
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.
Jakab & Brockners Expires 7 January 2027 [Page 15]
Internet-Draft Agent Discovery via mDNS July 2026
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 "_agent._tcp" service type.
* This document focuses on local agent discovery as a protocol-
independent model (Section 5.1), using a single "_agent._tcp"
service type 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 "_agent._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. 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.
Jakab & Brockners Expires 7 January 2027 [Page 16]
Internet-Draft Agent Discovery via mDNS July 2026
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 agentId and cardUrl, are therefore unauthenticated hints
and cannot be treated as proof of an agent's identity.
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. In particular, optional selection hints, such
as caps and ver for A2A, are advisory and can be forged. They are
not a basis for any security decision.
A pointer such as cardUrl causes a discovering party to retrieve 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.
Advertising agents expose their existence, and any metadata included
in their advertisements, to other hosts on the link. Operators who
consider the set of locally present agents, their names, or their
basic capabilities to be sensitive should account for this multicast
exposure and should minimize TXT record contents accordingly.
General mDNS and DNS-SD security considerations apply and are
discussed in [RFC6762] and [RFC6763].
10. IANA Considerations
This document makes no request of IANA.
Jakab & Brockners Expires 7 January 2027 [Page 17]
Internet-Draft Agent Discovery via mDNS July 2026
The model (Section 5.1) uses the underscored service name "agent"
with transport "tcp". Should this usage be progressed on the
standards track, it would be appropriate to register the "agent"
service name in the "Service Name and Transport Protocol Port Number
Registry" [RFC6335], following the underscored-service-name
conventions of [RFC8552]. No port number would be required, as the
port is conveyed per instance in the SRV record (see Section 6.1.2).
A registry for "proto" key values (the per-protocol agent
identifiers, such as "a2a") could likewise be established at that
time; this document does not define one.
11. References
11.1. Normative References
[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,
<https://www.rfc-editor.org/rfc/rfc6335>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
11.2. Informative References
[A2A] Linux Foundation, "Agent2Agent (A2A) Protocol
Specification, Version 1.0.1", 26 May 2026,
<https://github.com/a2aproject/A2A/blob/v1.0.1/docs/
specification.md>.
[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,
<https://datatracker.ietf.org/doc/html/draft-gakiwate-
dnssd-use-svcb-00>.
Jakab & Brockners Expires 7 January 2027 [Page 18]
Internet-Draft Agent Discovery via mDNS July 2026
[I-D.king-dawn-requirements]
King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-01,
28 April 2026, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
[LAD-A2A] LAD-A2A Contributors, "LAD-A2A: Local Agent Discovery for
A2A", 2025, <https://lad-a2a.org/>.
[MCP] MCP Community, "Model Context Protocol", n.d.,
<https://modelcontextprotocol.io/>.
[OpenClaw] OpenClaw, "OpenClaw Gateway: Bonjour discovery", 2026,
<https://docs.openclaw.ai/gateway/bonjour>.
[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,
<https://www.rfc-editor.org/rfc/rfc8552>.
[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, <https://www.rfc-editor.org/rfc/rfc9460>.
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
Jakab & Brockners Expires 7 January 2027 [Page 19]
Internet-Draft Agent Discovery via mDNS July 2026
Authors' Addresses
Lorand Jakab
Cisco Systems
Email: lojakab@cisco.com
Frank Brockners
Cisco Systems
Email: fbrockne@cisco.com
Jakab & Brockners Expires 7 January 2027 [Page 20]