]> Cisco

fbrockne@cisco.com

Cisco

lojakab@cisco.com

Infoblox, Inc.

nic@infoblox.com

Infoblox

jmozley@infoblox.com

int dawn DNS AI DAWN Discovery This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the DAWN Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Several approaches to agent discovery use DNS, and this document is scoped to those approaches. Local discovery uses mDNS/DNS-SD to find agents advertised within a local network or discovery domain, while global discovery uses DNS names resolvable beyond that domain. Applications can combine these scopes, for example, by discovering a local available network service and globally accessible service to complete a task. These scenarios require consistent discovery parameters so that agents can interpret endpoint and descriptor information across both scopes. This document specifies a common set of parameters for DNS-based global discovery and mDNS/DNS-SD local discovery, supporting either scope and their combination while keeping discovery records concise. A discovering agent needs to answer three questions from the DNS record alone, before subsequent discovery processes: How do I connect? Protocol and transport. What am I connecting to? A stable location I can cache and recognize later. Is what I know still current? Has the descriptor changed? This document defines a set of parameters that answers these. Everything else (capability taxonomy, business metadata, authorization details, etc.) comes from interaction beyond the initial discovery.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Key Set Parameter keys are divided into two groups, those that carry baseline information for discovery , and those that are important in some cases as necessary to support discovery . The intent is to support discovery via DNS with the minimum information needed and not to overload DNS records with information that is provided by other communication layers and protocols.

Key Summary Baseline discovery information: Key TXT SVCB Description alpn MAY MUST HTTP versions txtvers MUST N/A Text record format version proto SHOULD SHOULD Agent protocol Optional discovery information that is use case specific depending on the agent protocol and discovery process: Key TXT SVCB Description desc-ref SHOULD SHOULD Stable descriptor locator desc-ref-digest SHOULD SHOULD Descriptor locator digest (see note 1) proto-ver MAY MAY App protocol version path MAY MAY Endpoint path well-known MAY MAY .well-known suffix title MAY MAY Display name Notes: When the endpoint has a descriptor reference, at the protocol's default location or named by well-known.

Key Definitions Key definitions presented in the same order as and .

alpn The application-layer protocols the endpoint supports for connection setup, identified by ALPN protocol identifiers (), for example h2 and h3 for HTTP, with semantics. It never carries the agent protocol, which is carried by proto. For SVCB records, the alpn SvcParamKey is defined in . For TXT records, the value is a comma-separated list of ALPN protocol identifiers in order of preference, for example alpn=h2,h3.

txtvers Version number for the DNS text record format.

SVCB Record Wire Format Not applicable. txtvers has no SvcParamKey registration and MUST NOT appear in an SVCB record.

SVCB Record Presentation Format Not applicable, for the same reason as above. The value is a decimal integer in US-ASCII digits, with no sign and no leading zeros other than the single digit "0" itself, following the version-tag convention of :

txtvers MUST be the first key/value pair in the TXT record (), so that a client can determine how to interpret the rest of the record before parsing it. This document starts numbering at txtvers=1; a change to the meaning of an existing key would increment the value, while adding a new key that older clients can safely ignore does not require a new one. Examples This key has no SVCB representation; only the TXT record string is shown. The TXT record string is txtvers=1.

proto The single agent protocol offered by this DNS-SD instance or SVCB record, e.g. a2a or mcp. An endpoint that offers several protocols is advertised once per protocol (i.e. one protocol per record in a DNS RRset), and a DNS-SD subtype (_a2a._sub), when used, names the same protocol. The proto SvcParamKey is single-valued, not a list. Agent protocols run over a transport identified nu the alpn so they are not themselves entries in the IANA Service Name and Transport Protocol Port Number Registry and a proto value is not required to be registered in, or validated against, that registry. Each decoded value MUST match this ABNF :

SVCB Record Wire Format The wire-format SvcParamValue is the US-ASCII octets of the protocol identifier. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

SVCB Record Presentation Format

The value is the protocol identifier in US-ASCII.

TXT Record Format In a TXT record the string is "proto=" followed by the value, with no further escaping.

Examples SVCB record example.

The corresponding TXT record string is proto=mcp.

desc-ref A descriptor reference for the agent being discovered. Different standards and specifications my use descriptors of different formats, such as an URN or an ANSName. This is not any form of universal agent identifier, rather it is used to facilitate discovery by specific implementations. It is not authenticated, so it provides information on locating or using the agent without proving who runs it. For a discovering entity to properly interact with an agent it needs to discover where the agent instance is and a descriptor of the agent to be used in subsequent stages of discovery. In some standards, the descriptor might be hosted at the same location as the agent instance in a fixed location specified as part of that standard, in which case no extra info may be needed. In other standards the descriptor may be hosted somewhere else, or the location of the descriptor might vary, then two references are needed - one to the location of the agent instance (that is the domain name) and one to the location of the descriptor. The format is not constrained. Examples could include: - ARD URN: urn:air:agent-name.example.com:travel:bookings - ANS ANSName: "ans://v1.5.0.support.example.com" This document places no constraint on its contents beyond excluding the NUL octet; a descriptor reference's own format (e.g. a URN, or URI) is defined by the standard that specifies it, not by this document.

SVCB Record Wire Format The wire-format SvcParamValue is the UTF-8 octets of the reference to the descriptor. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

SVCB Record Presentation Format

The value is a single character-string, using the escaping rules of and . It is not a list, so "," is an ordinary character within the locator value.

TXT Record Format In a TXT record the string is "desc-ref=" followed by the value, with no further escaping.

Examples SVCB record example.

The corresponding TXT record string is desc-ref=urn:air:agent-name.example.com:travel:bookings.

desc-ref-digest An algorithm-prefixed digest of the descriptor reference, used as a freshness signal. This consists of a value from the Named Information Hash Algorithm Registry , colon, and hash value (e.g. sha-256:<base64url>). A client whose cached descriptor matches MAY assume the descriptor has not changed; a mismatch means the descriptor changed, not that the endpoint is hostile. A change in the digest is not a security signal. It means the descriptor reference changed and indicates this to a discovering entity, which MAY use this as a signal to take decisions regarding connecting to the end point. If the digest doesn't match what's cached, the discovering agent SHOULD perform actions such as: Re-fetch information from the descriptor and/or other parameters such well-known, or Query an organizational index such as _index._agents.<domain> from or _agent._tcp.local. from to see if the agent record has changed, or Escalate to the application layer if it needs to decide whether the prior desc-ref descriptor is still valid, such as the descriptor altering because of a version change The desc-ref-digest SvcParamKey is single-valued: its SvcParamValue is one digest, not a list. Each decoded value MUST match this ABNF :

hash-alg is a name from the Named Information Hash Algorithm Registry (e.g. sha-256); base64url-value is the digest encoded per , with padding included if the registry entry's output length requires it. A value whose hash-alg is not a registered name, or whose base64url-value does not decode to the length that algorithm produces, does not have the expected format, so the RR is malformed (). In a TXT record, a client ignores a desc-ref-digest that fails this check.

SVCB Record Wire Format The wire-format SvcParamValue is the UTF-8 octets of the digest value (hash algorithm name, ":", Base64url digest). Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

SVCB Record Presentation Format

The value is a single character-string, using the escaping rules of and . The ":" separating hash-alg from base64url-value is an ordinary character and needs no escaping.

TXT Record Format In a TXT record the string is "desc-ref-digest=" followed by the value, with no further escaping.

Examples SVCB record example.

The corresponding TXT record string is desc-ref-digest=sha-256:base64urlvalue==.

proto-ver The version of proto the endpoint supports, in that protocol's own syntax (A2A 1.0, MCP 2025-11-25). It is a selection hint only; the protocol's own negotiation settles compatibility. The proto-ver SvcParamKey is single-valued: its SvcParamValue is one version identifier, not a list. The value is an opaque character-string in the syntax that protocol's own specification defines for its version identifiers; this document does not otherwise constrain its contents beyond excluding the NUL octet.

SVCB Record Wire Format The wire-format SvcParamValue is the UTF-8 octets of the version identifier. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

SVCB Record Presentation Format

The value is a single character-string, using the escaping rules of and . It is not a list, so "," is an ordinary character within the version identifier.

TXT Record Format In a TXT record the string is "proto-ver=" followed by the value, with no further escaping

Examples SVCB record example.

The corresponding TXT record string is proto-ver=2025-11-25.

path The HTTP path of the protocol endpoint (e.g. /mcp), as _http._tcp carries it (). Needed when the endpoint does not supply a description, such as with MCP version 2026-07-28. A client builds the URL from the SRV or SVCB target and port plus this path; host and port never appear in the TXT record (). The path SvcParamKey is single-valued: its SvcParamValue is one path, not a list. The value is the path component only. The scheme and authority come from the SVCB or SRV target and port, and a query or fragment is not permitted. Each decoded value MUST match this ABNF :

The segment-nz and segment rules are from . Non-ASCII characters MUST be percent-encoded. Invalid percent escapes and segments equal to "." or "..", including their percent-encoded forms, MUST be rejected. Other percent-encoded octets and any trailing "/" MUST be preserved without decoding or normalisation. A value that fails these checks does not have the expected format, so the RR is malformed (). In a TXT record, a client ignores a path that fails these checks.

SVCB Record Wire Format The wire-format SvcParamValue is the octets of the path. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

SVCB Record Presentation Format

The value is a single character-string, using the escaping rules of and . It is not a list, so "," is an ordinary character within the path.

TXT Record Format In a TXT record the string is "path=" followed by the same value, with no further escaping. Each string in a TXT record holds at most 255 octets (), so the path is limited to 250 octets. All of an instance's key/value strings share one TXT record, which DNS-SD recommends keeping to 200 octets or less, and under 400 octets to fit in a single 512-byte DNS message (); in practice a path is therefore much shorter than 250 octets.

Examples SVCB record example.

The corresponding TXT record string is path=/mcp.

well-known The descriptor's suffix under /.well-known/ (e.g. agent-card.json), as defines it for SVCB records. Omitted when the descriptor is at the protocol's default location.

title A human-readable name for the endpoint, for display only, such as the name a client shows in a list of discovered agents. The value typically comes from the descriptor, for example the A2A Agent Card name or the MCP title. In DNS-SD the service instance name normally serves this purpose, so title is useful mainly when the two differ: after an mDNS name conflict renamed the instance, or when the descriptor's name cannot be an instance name (). In unicast DNS, owner names are host names, so title is the only display name available before the descriptor is fetched. The value is not authenticated. A client displays it as an unverified name and does not use it to identify or correlate agents. (see ). The title SvcParamKey is single-valued. The value is UTF-8 text in Unicode Normalization Form C, with no control characters. Each decoded value MUST match this ABNF :

The UTF8-2, UTF8-3, and UTF8-4 rules are from ; the C1 control characters U+0080 to U+009F are not allowed. A value that fails these checks makes the RR malformed (). In a TXT record, a client ignores a title that fails these checks.

Wire Format The wire-format SvcParamValue is the UTF-8 octets of the value, and its extent is given by the SvcParamValue length field of the enclosing SvcParam (). A zero-length value is malformed.

Presentation Format

The value is a single character-string, using the escaping rules of and the character-string grammar of , which allows only visible ASCII unescaped: non-ASCII octets are written as \DDD escapes. It is not a list, so "," is an ordinary character within the title.

TXT Format In a TXT record the string is "title=" followed by the UTF-8 octets of the value, with no further escaping. Each string in a TXT record holds at most 255 octets (), so the title is limited to 249 octets. All of an instance's key/value strings share one TXT record, which DNS-SD recommends keeping to 200 octets or less (), so a title is best kept short.

Examples shows title="Travel Bookings" in an SVCB record, and the corresponding TXT record string title=Travel Bookings. A title with non-ASCII characters, such as "Café Orders", is title="Caf\195\169 Orders" in SVCB presentation format, while the TXT string carries the UTF-8 octets directly.

Applicability to Index Records An index of AI resources may be published using a well known DNS label within an organizational domain to indicate the presence of a catalog or agent registry. _index._agents.<domain> (unicast) or the browse-domain PTR target (DNS-SD) SHOULD carry: alpn, proto, well-known - how to talk to the index and where to fetch its descriptor if the specification uses well-known desc-ref and desc-ref-digest - if needed to locate the index in addition to the domain name

SVCB and TXT encoding Same key names in both. SVCB uses numeric codes (private-use until IANA assigns); TXT uses the string names directly. Sharing names means a client doesn't need two vocabularies. Until IANA assigns codes, mandatory=proto won't work reliably across implementations because the numeric value may differ. TXT at the same owner name is the interoperability fallback. Examples of records can be seen in and : Individual agent - unicast:

Individual agent - DNS-SD/mDNS, one instance per protocol (PTR to browse, SRV for host/port, TXT primary):

One instance per protocol rather than proto=a2a,mcp in one TXT. Browse _agents._tcp for every agent, or the _a2a._sub / _mcp._sub subtype for one protocol. IF both instances carry the same desc-ref, a client that sees both can infer they are one agent. The MCP instance has no well-known or location-digest yet, because MCP has no settled location descriptor (Server Cards, SEP-2127, still open). It carries path=/mcp instead: MCP requires a single endpoint path but defines no default, so without path a client could not reach the server. The A2A instance needs no path, because its endpoint URL comes from the Agent Card.

Open questions This section lists questions on which the authors seek input. It will be removed before publication.

Security Considerations The title key carries a display name chosen by whoever publishes the record. It is not authenticated, so an advertiser can use a title that imitates another agent or a trusted organization, such as "Official Stadium Taxi". Clients present it as an unverified name, do not use it to identify or authorize an agent, and rely on subsequent processes for those purposes. A client that shows titles to users also needs to consider visually confusable characters.

IANA Considerations This section will be revised based on consensus of the parameter keys and value.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Infoblox, Inc. Old Dog Consulting This document defines the "well-known" Service Parameter Key (SvcParamKey) for SVCB and HTTPS resource records. It carries one or more well-known URI suffixes, identifying resources under "/.well- known/" that are available at the service endpoint. It specifies the presentation and wire formats and requests registration of the key with IANA. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. 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. 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. 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. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] GoDaddy OWASP DistributedApps.ai OWASP Cisco Systems Autonomous AI agents now invoke one another across organizational boundaries over protocols such as the Model Context Protocol (MCP) and Agent2Agent (A2A). A relying party has no interoperable way to bind a discoverable agent endpoint to the holder of its domain (optionally verified as a legal entity), a specific software release, and an auditable issuance history. This document specifies the architecture of Agent Name Service version 2 (ANS v2), an identity layer, anchored in DNS domains, that binds an agent endpoint to its domain holder, its release, and its history. ANS v2 composes systems the Internet already runs (the DNS with DNSSEC; the Web PKI, with DANE where operators publish it; and an append-only transparency log) and introduces no new root of trust. Every ANS v2 agent carries a versioned name rooted in a DNS domain that the registrant controls. When a registrant registers an agent, the Registration Authority (RA) checks the registrant's control of that domain, can issue an Identity Certificate that binds the versioned name to the agent's key, and submits a signed registration record to a Merkle-tree transparency log. Under the current specifications, a new version is a new registration and a new log entry, so a verifier can pin an agent to a specific release. Any third party can detect a rewritten log by computing, from the log's public tiles, a consistency proof between two of its signed checkpoints. For discovery, ANS v2 adopts the SVCB records and SvcParams of DNS for AI Discovery (DNS-AID) as its default format, and keeps an older TXT-based format only as an opt-in profile. Beyond those discovery records, ANS v2 specifies one DNS record, an "_ans-badge" TXT record that points to the agent's transparency-log entry; the log seals the fingerprint of the agent server's certificate, and operators can add DANE records. With these records, a verifier resolves an agent, authenticates its TLS endpoint, and confirms that the presented name, version, and key match a logged registration. This document also states a threat model covering agent impersonation, DNS spoofing, CA and Registration Authority compromise, version rollback, agent card tampering, and log rewriting, and names what each ANS check does and does not prevent. The reference registry, transparency log, verifier, JSON Schemas, SDKs, and CLI are open source. 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. Cisco Systems Cisco Systems 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. 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.

Stadium Use Case This appendix illustrates how a user's personal agent can use local-network and global discovery, separately and together, during a stadium visit. The examples show how the discovery parameters described in this document apply to these scenarios.

Local Services in the Stadium When the user enters the stadium, the user's personal agent can browse the venue's local DNS-SD domain to discover agent services advertised on the stadium network. The available services may vary with the user's location and the services enabled for the event. These services provide information and capabilities relevant to the stadium visit. For example, a live-statistics service could provide statistics and updates through MCP or A2A. A replay service could provide access to venue media through MCP, with the media delivered using MOQ. If the replay service is accessible only through the stadium's Wi-Fi network, the user's device must connect to that network to use it.

Food Ordering Through Local and Global Services During the game, the user might ask, "Have two burgers and two soft drinks delivered to seat 34B." The personal agent could use a local food-ordering service offered by the stadium or consider a global food-ordering service. A local service could support ordering from stadium vendors and delivery to the user's seat. Global providers could complement these vendors by arranging a meal for pickup outside the venue or delivery to the user's home after the event. The personal agent must account for venue access and delivery restrictions: discovering a global food-delivery service does not imply that the service can deliver to a stadium seat. The selected food-ordering agent would maintain order state and coordinate payment and delivery. The personal agent could also combine information from local and global services, such as using venue-specific pickup instructions when arranging an order through a global provider.

Transportation Through Local and Global Services After the game, the user might ask, "Get me home as quickly as possible." The personal agent could consider both local and global transportation services. The stadium could offer a local transportation service that provides access to a preferred set of ride-share and taxi companies selected by the venue. Booking through this service could provide negotiated rates or discounts unavailable through direct bookings. The service could obtain offers from participating companies and help arrange pickup at a designated meeting point. Global transportation services could provide additional options, including ride-share services, taxis, buses, and metro connections. The personal agent could combine these options with local information from the stadium, such as guidance to the most appropriate exit or pickup location. Local services would therefore complement global services even when the transportation itself is arranged through a global provider. The stadium's transportation service could expose both A2A and MCP endpoints. Following the one-instance-per-protocol approach in , it would advertise a separate DNS-SD instance for each protocol. Both instances would carry the same desc-ref value, allowing the personal agent to correlate them as protocol endpoints of the same logical service. The A2A endpoint could support goal-oriented interaction, while the MCP endpoint could provide access to tools or resources. The personal agent could select the protocol appropriate to the task and its own capabilities.

Complementary Discovery Scopes These scenarios illustrate two complementary discovery scopes. Local DNS-SD discovery identifies services advertised within the venue's local discovery domain, while global DNS discovery identifies services through globally resolvable names. The personal agent can use services discovered through either scope or combine them to fulfill the user's request. Each endpoint's application protocol is conveyed using proto. When the same logical service supports both A2A and MCP, it is advertised through separate protocol instances that can be correlated using desc-ref.

Design Alternatives Considered This appendix records alternatives that were considered while designing the parameters in this document but were not adopted, with the reasons for each. All of them are plausible, and several appear in earlier versions of related drafts. The entries show which trade-offs have already been weighed, and what new information would justify revisiting a decision. They run from the most general question, what DNS should carry at all, to the most specific, key syntax.

Relying on HTTP Alone A2A and MCP both run over HTTP, so DNS could limit itself to locating an HTTP server, as HTTPS records already do, and leave the agent layer to bootstrap itself from .well-known resources. Each layer would then carry only what is needed to bootstrap the next one. That is sufficient when a client already knows which endpoint it wants. It is not sufficient for discovery. Browsing _agents._tcp on a busy local network can return many instances, and without a hint in the advertisement a client has to complete a TLS handshake and an application-layer exchange with every candidate just to discard most of them. The parameters in are therefore limited to what a client needs to choose an endpoint before connecting: the agent protocol and HTTP versions, where to find the endpoint or its descriptor, which logical agent the endpoint belongs to, and whether a cached descriptor is still current. Everything else is left to the descriptor and the agent protocol. The saving is largest for local discovery. In global discovery a client often starts from a single known name, and the parameters mainly provide the freshness check of desc-ref-digest and a vocabulary shared with local discovery. Relying on HTTP alone would also tie agent discovery to HTTP. A2A and MCP run over HTTP today, but future agent protocols might not, and this document is not meant to exclude them. Because proto identifies the agent protocol independently of HTTP, a client can select such a protocol in the same way, and keys that apply only to HTTP, such as path and well-known, are omitted for it.

A Dedicated Resource Record Type A new RR type for agent discovery could carry structured data without the constraints of TXT key/value strings. Before any deployment could use it, however, authoritative servers, provisioning systems, DNS hosting interfaces, and mDNS implementations would all need to support it. The record types that DNS-SD already uses (PTR, SRV, and TXT ) and SVCB are deployed today and can hold the small set of parameters in . This document therefore defines conventions for existing record types and introduces no new ones.

Capabilities in DNS Records Advertising what an agent can do, for example caps=bookings,refunds, would let a client filter candidates by function. There is no shared vocabulary for such values, and examples tend to mix protocol features, such as MCP tools, resources, and prompts, with business categories, which serve different purposes. Capabilities also change more often than DNS records should: the tools an MCP server offers are listed at run time through the protocol itself and can change during a session. Long capability lists also strain the size limits of TXT records (). Capabilities are therefore left to the descriptor and to the agent protocol. If coarse categories are needed in the future, DNS-SD subtypes () can filter at query time, which a TXT key cannot: a client has to receive and parse every TXT record before it can apply a key-based filter.

Agent Protocol in ALPN The agent protocol could be carried in the alpn SvcParam, as in alpn=h2,mcp. ALPN identifiers name the protocol that runs directly over TLS, and the alpn SvcParam lists alternatives a client can choose from, not the layers of a protocol stack (). A value of alpn=h2,mcp therefore advertises either HTTP/2 or a protocol named mcp running directly over TLS, whereas A2A and MCP both run over HTTP. In this document, alpn carries only the HTTP versions an endpoint supports, and the agent protocol is carried in proto ().

Per-Protocol Service Types A DNS-SD service type identifies "what the service does and what application protocol it uses to do it" (), which suggests one service type per agent protocol, such as _a2a._tcp and _mcp._tcp. This raises several problems: Every service type needs its own entry in the Service Name registry . The name mcp is already registered for an unrelated protocol, so MCP would need a different name, such as mcp-ai, which would then differ from the protocol's own name. No single service type would cover all agents. An agent using a new protocol could not be discovered until its service type was registered and clients were updated to browse for it. mDNS gateways and proxies that forward selected service types would need to be reconfigured for every new protocol, whereas a single service type needs to be permitted only once. Instance names are unique only within a service type, so two unrelated agents could advertise the same name under _a2a._tcp and _mcp-ai._tcp, and a client merging the two lists would take them for one agent. DNS-SD resolves this with a "flagship" service type that reserves the name across all related types (), which amounts to a generic service type after all. This document uses one generic service type, _agents._tcp, which needs a single registration, and DNS-SD subtypes such as _a2a._sub._agents._tcp for protocol-specific browsing (). The subtype namespace is separate for each service type, so _mcp is available as a subtype of _agents._tcp even though mcp is a registered Service Name. Encoding the protocol as an extra label in front of the instance name, as in _mcp.agent-name._agents._tcp, does not work either: the instance portion of a Service Instance Name is a single DNS label (), and subtypes provide the selection such a label was meant to provide.

Multiple TXT Records per Instance A service instance that offers two protocols could carry a separate TXT record for each, one containing proto=a2a and its keys, and the other proto=mcp and its keys. DNS-SD allows multiple TXT records only when each describes "a different variant of the same logical service, offered using the same underlying protocol on the same port", and advises future protocol designs not to follow the example of the only service type that uses them (). Multiple records also cannot reduce traffic, since a responder that sends any member of the TXT RRset "MUST send the entire RRSet" (). Implementations also disagree. Apple's mDNSResponder publishes multiple TXT records and returns all of them; Avahi refuses to publish a second record and keeps only the first when resolving; python-zeroconf keeps only the last. The same advertisement can therefore present a different protocol to each client, and none of these implementations reports the discrepancy. This document uses exactly one TXT record per service instance.

Several Protocols in One Instance A single instance could list all the protocols it offers, as in proto=a2a,mcp, with protocol-specific keys distinguished by a prefix, such as a2a-card and mcp-path. This is compact, but the protocols then share one host and port, every protocol-specific key needs a prefix, and a client interested in one protocol still receives and parses the keys of the others. A change to one protocol, such as a new version or its withdrawal, also changes the record that clients of the other protocols have cached. This document advertises one instance per protocol instead (), and instances of the same logical agent carry the same desc-ref, so a client that sees several of them can tell they belong together. The unit of multiplicity is the instance, not the record or the key.

Parallel Value Lists Keys with parallel lists, such as proto=mcp,a2a ver=1,2, associate values by position. The association is fragile, because a missing or extra item silently shifts every value after it, and it cannot express two versions of the same protocol. Repeating a key does not provide a hierarchy either, since a DNS-SD client ignores all but the first occurrence of a key in a TXT record (). With one protocol per instance (), each key has a single meaning and no values need to be associated across keys.

A Single Version Key A single ver key would conflate three different versions: of the TXT record format, which txtvers carries (); of the agent protocol, which proto-ver carries; and of the agent's implementation. The implementation version is left to the descriptor, so that a software upgrade does not require a change to DNS.

No Protocol Version in DNS Leaving protocol versions out of DNS would keep records smaller, but a client that supports only some versions of a protocol would have to contact every candidate to find out which ones it can use. The proto-ver key is therefore an optional selection hint (), and the agent protocol's own negotiation still determines compatibility.

Full URLs in TXT Records A TXT key could carry the complete URL of an endpoint or descriptor, as in cardUrl=https://agent.example.com/.well-known/agent-card.json. This duplicates the host and port that the SRV record already carries, which DNS-SD prohibits (), and URLs are among the longest values a TXT record would hold. This document carries only the path (path) or the .well-known suffix (well-known), and a client builds the URL from the target and port of the SRV or SVCB record, the way the _http._tcp service carries path (). Carrying only a path also leaves a single source for the host a client connects to: any policy the client applies to the SRV or SVCB target, such as permitted hosts or address ranges, also covers the URL it builds, and a value that is not a path, such as a complete URL, is ignored ().

Different Key Names per Encoding TXT keys could follow their own conventions, such as camelCase names like cardUrl and a2aProtoVer, with different names for the same parameters in SVCB. SvcParamKey names are limited to lowercase letters, digits, and hyphens, with at most 63 characters (), while TXT keys are case-insensitive and are recommended to be no more than nine characters long (). Names that satisfy both rules can be used unchanged in both encodings, so a client needs only one vocabulary, and a parameter means the same thing in local and global discovery. The one key longer than nine characters, well-known, keeps the name used for the corresponding SVCB parameter.

Use of desc-ref desc-ref was chosen after discussion on several possible names including cap (for capability) and locator (to locate agent description or capability). Naming it as a description reference was chosen as it is generic and allows the parameter to support different protocols and specifications without the name referring to a single property of a description.

Use of desc-ref and well-known Agent protocols may use .well-known URI suffixes and hence in some cases this does not need to be specified. However, more than one well-known suffix might be used and offered as alternatives during discovery (with a preference order) to discovering entities, or this may be used in conjunction with an agent descriptor that is not a well-known suffix and contained in the parameter. Having both desc-ref and well-known allows for these use cases and flexibility in supporting multiple agent protocols.

Acknowledgments The authors would like to thank Ben Schwartz and Scott Courtney for their feedback and discussion.