]> Cisco Systems

lojakab@cisco.com

Cisco Systems

fbrockne@cisco.com

Internet mDNS DNS-SD Bonjour agent discovery A2A AgentCard zero configuration 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.

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 or the Model Context Protocol , 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.

Terminology This document uses the DNS-SD terminology of , in particular "service type", "service instance", "service instance name", "browse", and "resolve". It uses "AgentCard", "agent", and "session" as described in . 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.

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

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

DNS-SD and mDNS-Based Solution Approach DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) 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 (); a two-stage discovery flow that separates lightweight local enumeration from full metadata retrieval (); a worked instantiation of the model for the A2A protocol, including a mapping from AgentCard fields to DNS-SD records (), 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.

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: 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 , the application protocol identifier is "agent" and the transport is TCP. 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 ). A two-stage discovery flow (): 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. 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.

Carrying the Descriptor: TXT and SVCB This document uses a TXT record (, 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 can carry the same connection and parameter information in a more structured form, and their use with DNS-SD is described in . 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 , where SVCB is the primary carrier and TXT a fallback; supporting SVCB here aids compatibility with such wide-area mechanisms.

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.

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.

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 . From this point, interaction is governed entirely by the agent protocol; DNS-SD plays no further role.

Instantiations This section instantiates the model of for specific agent protocols. Protocols for communication between autonomous software agents are emerging rapidly. A representative example is the Agent2Agent (A2A) protocol , 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.

A2A This section describes the model of for version 1.0.1 of the A2A protocol . 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.

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" (), in the "local." domain when using mDNS . It is identified as an A2A agent by the descriptor key "proto=a2a" in its TXT record (see ). 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.

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 ). The mapping described in this document is: Source field or value DNS-SD record Transformation (protocol identifier) TXT key proto Fixed value a2a, marking the instance as an A2A agent name Service instance name Encoded as the instance label (see ) name TXT key agentId Copied verbatim for explicit identification selected supportedInterfaces[].url SRV target and port The selected interface URL authority is parsed into host name and port selected supportedInterfaces[].protocolBinding TXT key a2aBinding Copied verbatim as an optional selection hint selected supportedInterfaces[].protocolVersion TXT key a2aProtoVer Copied verbatim as an optional selection hint AgentCard URI TXT key cardUrl Full URL from which the AgentCard document is retrieved skills[].tags TXT key caps Skill tags concatenated into a comma-separated list version TXT key ver Copied verbatim all other fields (not advertised) Obtained by retrieving the AgentCard via cardUrl 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.

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

TXT Record Keys The TXT record carries the key/value pairs in , encoded per , Section 6. 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 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 , 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.

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

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.

Other Instantiations Instantiations of the model () 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 (). A per-protocol DNS-SD service type would be a different discovery architecture, not an instantiation of the shared-service-type model described here.

Deployment Considerations mDNS is, by design, limited to the local link . 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.

Related work

LAD-A2A project The LAD-A2A project 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 (), 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 (, ). 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.

OpenClaw project 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 . 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 of this document. OpenClaw is thus an independent instance of the general model of , arrived at for a different agent system, which illustrates that agent vendors are adopting mDNS/DNS-SD for the local-discovery step.

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

IANA Considerations This document makes no request of IANA. The model () 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" , following the underscored-service-name conventions of . No port number would be required, as the port is conveyed per instance in the SRV record (see ). 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.

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. 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. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Apple Inc Apple Inc DNS Service Discovery (DNS-SD) relies on a sequence of steps to enable the discovery and connection to local network services. The use of Service Binding (SVCB) resource records during the service discovery process enables service instances to advertise properties such as Application-Layer Protocol Negotiation (ALPN) identifiers and other endpoint configuration options. This document describes the use of SVCB / HTTPS RRs in the DNS Service Discovery process as an additional step to allow clients to connect to service instances optimally. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Infoblox, Inc. Infoblox, Inc. Unaffiliated Deutsche Telekom Amazon The document standardizes an approach for publishing AI agents in the Domain Name System (DNS) so that other agents can discover them. Discovery is then initiated based on one of three generic use cases, in increasing computational and latency cost: (1) the requestor knows both the organization and agent (2) the requestor knows the organization that provides a capability, but not the specific agent (3) the requestor knows the required capability, but not the organization or agent. Of these use cases only (1) and (2) are in scope for this document, although (3) can be derived from this specification. DNS for AI Discovery (DNS-AID) is designed so that, once a client has learned an organization's agents, subsequent transactions can utilize the first use case with the benefit of cacheable connectivity information that is learnable as an agentic skill. The mechanism uses Service Binding (SVCB) records for connectivity information and key meta data, a well known entry point using DNS-Based Service Discovery (DNS-SD) labels into an organization's agent index, and optionally DNS Security Extensions (DNSSEC) and DNS-Based Authentication of Named Entities (DANE) TLSA records for trust and security. DNS-AID provides consumers of agent services with a direct connection method for agentic workloads not mediated by a third party. Organizations can use the same approach across public and private networks networks, providing consistency and common operational models, including publishing agents that are hosted in service provider domains. This document introduces no new resource record types, opcodes, or response codes. Linux Foundation LAD-A2A Contributors OpenClaw MCP Community

Contributors Cisco Systems

natal@cisco.com

Cisco Systems

evoit@cisco.com

Cisco Systems

pkathail@cisco.com