Zero-Configuration Agent Discovery

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

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

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

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

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

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

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

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

_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:<base64url-digest>"
)

_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:<base64url-digest>
)

_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"
)

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

8. Related work

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

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

11. Acknowledgements

The authors would like to thank Blake Morrison, Chris Hood, Jim Mozley, Michael Richardson, and Nic Williams for their feedback.¶

12. References

Appendix A. Changes Since Previous Revisions

This section is to be removed before publishing as an RFC.¶

Contributors

Authors' Addresses