Discovery of Agents With Names (DAWN) J. Jiménez Internet-Draft Ericsson Intended status: Standards Track J. Bu Expires: 3 May 2027 Google J. Arkko Ericsson 30 October 2026 Agent Resource Discovery (ARD): Initial Contact draft-jimenez-dawn-ard-initial-contact-00 Abstract In an agent system, agents need to discover other agents, tool servers, and skills. Agent Resource Discovery (ARD) defines a manifest listing such resources and a lookup interface over it. This document specifies how a client (such as an agent) initially discovers an ARD manifest. This discovery is performed through the use of DNS Service Binding records, DNS-Based Service Discovery (DNS- SD), HTTP link relations, or well-known URIs. Each mechanism yields a set of manifest URIs. The manifest format, the lookup interface, and the binding of a manifest to its publisher are specified in the companion ARD documents. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jimenez-dawn-ard-initial- contact/. Discussion of this document takes place on the Discovery of Agents With Names (DAWN) Working Group mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/. 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/. Jiménez, et al. Expires 3 May 2027 [Page 1] Internet-Draft ARD Initial Contact October 2026 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 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The Entry Point . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 5 4.1. Configured Entry Points . . . . . . . . . . . . . . . . . 6 4.2. DNS-Based Mechanisms . . . . . . . . . . . . . . . . . . 6 4.2.1. Organization Index Record . . . . . . . . . . . . . . 6 4.2.2. DNS-SD Service Type "_ard._tcp" . . . . . . . . . . . 7 4.3. Origin-Based Mechanisms . . . . . . . . . . . . . . . . . 8 4.3.1. Well-Known URI . . . . . . . . . . . . . . . . . . . 8 4.3.2. Link Relation . . . . . . . . . . . . . . . . . . . . 9 4.4. Local Network Mechanisms . . . . . . . . . . . . . . . . 10 4.4.1. Network-Provided Domain Name . . . . . . . . . . . . 10 4.4.2. Multicast DNS . . . . . . . . . . . . . . . . . . . . 10 5. Client Procedure . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Indirection Depth and Outcomes . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Entry Points and Authority . . . . . . . . . . . . . . . 13 6.2. Local Network Discovery . . . . . . . . . . . . . . . . . 13 6.3. Downgrade . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Well-Known URI Squatting . . . . . . . . . . . . . . . . 14 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 14 8.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 15 Jiménez, et al. Expires 3 May 2027 [Page 2] Internet-Draft ARD Initial Contact October 2026 8.3. Service Name . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Agent Resource Discovery (ARD) [ARD] defines the manifest, a document served over HTTPS in which a publisher lists agents, tool servers, and skills. Each entry points at the artifact that describes the resource in its native protocol, such as an Agent Card [A2A] or an MCP server description [MCP]. ARD also defines a lookup interface over the manifest. Both require the URI of the manifest. The ARD architecture is described in [ARD-ARCH]. [ARD] leaves the mechanisms by which a client obtains that URI to this document. The applicable IETF mechanisms, well-known URIs [RFC8615], web linking [RFC8288], Service Binding records [RFC9460], and DNS-SD [RFC6763] with Multicast DNS [RFC6762], each require an application-specific binding that defines the names to query, the parameters to publish, and the interpretation of the answer. This document defines the following mechanisms for obtaining the URI of an ARD manifest: * a Service Binding (SVCB) record [RFC9460] at the organization index name _index._agents. with an ARD manifest as its target (Section 4.2.1); * a DNS-SD service type [RFC6763], "_ard._tcp", for use over unicast DNS and Multicast DNS [RFC6762] (Section 4.2.2, Section 4.4.2); * a well-known URI [RFC8615] with the suffix "ard.json" (Section 4.3.1); * a link relation [RFC8288], "ard", whose target is an ARD manifest (Section 4.3.2). Jiménez, et al. Expires 3 May 2027 [Page 3] Internet-Draft ARD Initial Contact October 2026 Section 5 specifies how a client combines these mechanisms. The DAWN charter [DAWN-CHARTER] calls this step "initial discovery"; this document uses the term "initial contact" for the same step, and the term "manifest", from [ARD], for the catalog that the charter names as a service that furthers discovery. The mechanisms cover the three deployment contexts the charter identifies: the local network, an organization's own infrastructure, and discovery between organizations over the public Internet. This document does not specify the manifest representation, the lookup or search interfaces, the registration of entries, or how a manifest is bound to its publisher; these are specified in [ARD] and [I-D.jimenez-agent-directory]. It defines no new DNS resource record types, underscored node names, SvcParamKeys, or transport protocols. All entry point URIs use the "https" scheme. The mechanisms and the procedure do not depend on the manifest format; the well-known suffix, the media type, and the publisher check are the parts specific to ARD. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the DNS terminology of [RFC9499], the DNS-SD terms "service type", "service instance", "browse", and "resolve" from [RFC6763], and the HTTP terms "origin" and "authoritative" from Sections 4.3.1 and 4.3.3 of [RFC9110]. ARD manifest: A document listing agent resources in the format defined in [ARD]. Entry point: The URI of an ARD manifest, together with the source from which the client learned it (Section 3). An entry point is unverified until the client has retrieved the manifest and authenticated the origin. Publisher: The party that controls a domain name and publishes a manifest of agent resources under it. Client: Software that performs the procedure of this document to obtain an entry point. Jiménez, et al. Expires 3 May 2027 [Page 4] Internet-Draft ARD Initial Contact October 2026 Initial contact: The process by which a client obtains one or more entry points, starting from a domain name, a local network attachment, or configuration. 3. The Entry Point Every mechanism in this document yields zero or more entry points. An entry point consists of two elements: URI: The "https" URI [RFC9110] at which, according to the source, an ARD manifest is served in a representation defined by [ARD]. Source: The mechanism that produced the entry point and, where applicable, the DNS name or network interface from which it was obtained. The client retains the source to rank entry points (Section 5), to rate-limit failing sources, and to apply local policy. An entry point is unverified until the client has retrieved the manifest from the URI and authenticated the origin (Section 6); the outcomes of that retrieval are defined in Section 5.1. A DNS answer or a multicast response does not make a manifest authoritative for a publisher. The publisher of each entry is established from the entry itself, as specified in [ARD]; the host that serves the manifest establishes no publisher authority. A domain can publish more than one manifest. Each mechanism can return several entry points, and the client treats them as a set. A manifest can link to further manifests, and can consist of a single entry that points at a registry endpoint [ARD]; following those links is part of lookup and is outside the scope of this document. Initial contact ends at the manifest. 4. Discovery Mechanisms The well-known URI of Section 4.3.1 is mandatory to implement. A publisher that makes its manifest discoverable MUST serve it at the well-known URI, directly or through one redirect, and every client MUST implement the well-known fetch. The other mechanisms are OPTIONAL for publishers and supplement the well-known URI: they let a client learn an entry point before it connects, enumerate several manifests, or find a manifest without a domain name. A client that supports discovery of manifests on the local network MUST implement the Multicast DNS browse of Section 4.4.2. Jiménez, et al. Expires 3 May 2027 [Page 5] Internet-Draft ARD Initial Contact October 2026 The mechanisms of Section 4.2 and Section 4.3 take a domain name as input. The mechanisms of Section 4.4 require no domain name. 4.1. Configured Entry Points A client MAY be configured directly with one or more entry points, for instance by an operator, by a device profile, or by the application that includes the client. A configured entry point has the source "configuration", is tried before any discovered entry point, and is verified in the same way as a discovered entry point. Configuration is also used for manifests that a publisher does not advertise. A configured entry point is a URI. The client retrieves it directly; the DNS queries and HTTP requests of steps 2 to 5 of Section 5 do not apply to it. A client MAY be configured to use configured entry points only. Such a client does not perform the mechanisms of Section 4.2, Section 4.3, and Section 4.4. 4.2. DNS-Based Mechanisms DNS records allow a publisher to advertise an entry point before the client opens a connection, to send the client to a manifest host other than the domain apex without the redirect at the apex, and to enumerate several manifests. The well-known URI of Section 4.3.1 remains in place: the apex serves the manifest or redirects to it (Section 4). 4.2.1. Organization Index Record A publisher MAY publish a Service Binding (SVCB) record [RFC9460] at _index._agents. whose TargetName identifies a host that serves an ARD manifest at the well-known URI of Section 4.3.1 (this owner name is also used as an organization index pointer in [I-D.mozleywilliams-dnsop-dnsaid], which leaves the index document format out of scope). The following is an example for example.com: _index._agents.example.com. 3600 IN SVCB 1 ard.example.net. ( alpn="h2" ) The client forms the entry point as follows: * The scheme is "https". Jiménez, et al. Expires 3 May 2027 [Page 6] Internet-Draft ARD Initial Contact October 2026 * The authority is the TargetName, with the port from the "port" key or 443. The TargetName MUST be a host name without underscore labels, so that a publicly issued certificate can name it. A record whose TargetName is "." yields no entry point. * The path is "/.well-known/ard.json". The response determines whether a manifest is present. * Address records of the TargetName absent from the Additional section (Section 4.1 of [RFC9460]) are resolved by the client. * The "mandatory" key is processed as in Section 8 of [RFC9460]: a record whose mandatory list names a key the client does not implement is ignored. The "alpn", "port", "ipv4hint", and "ipv6hint" keys apply with their [RFC9460] semantics, and the "ech" key with its [RFC9848] semantics. Other keys are ignored. * One AliasMode indirection is followed (Section 2.4.2 of [RFC9460]); a second ends the attempt (Section 5.1). An AliasMode record whose TargetName is "." yields no entry point. In the example, the entry point is "https://ard.example.net/.well- known/ard.json". The client validates the TLS certificate for "ard.example.net" and records _index._agents.example.com as the source. An RRset MAY contain several ServiceMode records; each yields one entry point, and SvcPriority orders them. If the TargetName serves no manifest at the well-known path, the outcome is "no manifest" (Section 5.1); the host can still serve an index in another format, which this document does not interpret. 4.2.2. DNS-SD Service Type "_ard._tcp" A publisher MAY advertise manifests as DNS-SD service instances [RFC6763] of the service type "_ard._tcp", for instance to name and enumerate several manifests, or in networks that run DNS-SD. A client browses by querying PTR records at _ard._tcp. and resolves each service instance name to its SRV and TXT records. The following is an example for example.com with two manifests: _ard._tcp.example.com. 3600 IN PTR Travel._ard._tcp.example.com. _ard._tcp.example.com. 3600 IN PTR Tools._ard._tcp.example.com. Travel._ard._tcp.example.com. 3600 IN SRV 0 0 443 ( ard.example.net. ) Travel._ard._tcp.example.com. 3600 IN TXT ( "txtvers=1" "path=/.well-known/ard.json" ) Jiménez, et al. Expires 3 May 2027 [Page 7] Internet-Draft ARD Initial Contact October 2026 The TXT record carries the following keys, with the syntax of Section 6 of [RFC6763]: txtvers: The version of this key set. This document defines version 1. The key SHOULD be present and first in the record, as recommended in Section 6.7 of [RFC6763]; when absent, version 1 is assumed. A client MUST ignore records with a version it does not support. path: The path and optional query component of the entry point, as an absolute path [RFC3986]. When the key is absent, the path is "/.well-known/ard.json". The manifest at this path can differ from the manifest at the well-known URI of the same host. The client forms the entry point URI from the scheme "https", the SRV target as the host, the SRV port (omitted when it is 443), and the path. This document defines no "_ard._udp" service. The service name "ard" is registered in Section 8.3. Service instance names such as "Travel" are user-visible names; [RFC6763] allows them to change, and a server need not preserve their case ([RFC4343]). A client SHOULD NOT use an instance name as a persistent identifier of a manifest. 4.3. Origin-Based Mechanisms The mechanisms in this section use an HTTP request to the origin https:///. 4.3.1. Well-Known URI A publisher makes its manifest available at the well-known URI [RFC8615] with the suffix "ard.json". For the domain example.com, the well-known URI is: https://example.com/.well-known/ard.json Jiménez, et al. Expires 3 May 2027 [Page 8] Internet-Draft ARD Initial Contact October 2026 A publisher supporting this mechanism MUST respond to a GET request for this URI with an ARD manifest or with a redirect to one. The manifest carries the media type defined in [ARD], and a client SHOULD send it in the Accept header field. The client MUST follow at most one redirect (301, 302, 303, 307, or 308 with a Location field, Section 15.4 of [RFC9110]) and records the final URI as the entry point. After a redirect, the host of the entry point is the redirect target, and the source remains the origin that issued the redirect. A response with another media type, or a redirect to a further redirect, has the outcome "no manifest" (Section 5.1). A 404 (Not Found) response has the outcome "no manifest"; it MAY include Problem Details [RFC9457]. Responses to the well-known URI, including redirects and 404 responses, are cacheable under [RFC9111]. A client reuses a stored response while it is fresh (Section 5). A freshness lifetime of several hours is appropriate for a manifest whose location rarely changes. The scope of a well-known URI is its origin (Section 3 of [RFC8615]); a manifest at "https://example.com/.well-known/ard.json" provides no information about "https://agents.example.com/". A publisher with manifests on several hosts can serve a manifest at the apex that links to the others, or can enumerate them with DNS-SD (Section 4.2.2). The registration of the suffix is in Section 8.1. 4.3.2. Link Relation A publisher MAY include a link to a manifest in any HTTP response using the "ard" link relation [RFC8288] in a Link header field. The link target is an ARD manifest. A publisher supporting this mechanism SHOULD respond to a HEAD request for the root resource of its origin with a Link header field carrying the relation, as in the example of Section 3 of [RFC9727], where the "api-catalog" relation appears in the response to the root resource. The following is an example: HEAD / HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 1532 Link: ; rel="ard" Jiménez, et al. Expires 3 May 2027 [Page 9] Internet-Draft ARD Initial Contact October 2026 The client reads the Link field of the root response regardless of its status code. If the root resource redirects, the client follows one redirect (Section 5.1) and reads the Link field of the final response. A publisher that cannot set header fields MAY place the relation in an HTML link element of the root resource (Appendix A.1 of [RFC8288]); a client that retrieves the root resource with GET MAY read it. The procedure of Section 5 sends HEAD and reads the header field only. Links in a response from the publisher's own origin have that origin as their source. Links in third-party documents are entry points with the third party as their source. The registration of the relation is in Section 8.2. 4.4. Local Network Mechanisms 4.4.1. Network-Provided Domain Name A client without a domain name can obtain one from the network through the DHCPv4 Domain Name option (Section 3.17 of [RFC2132]), the DHCPv6 Domain Search List option [RFC3646], or the DNS Search List option in IPv6 Router Advertisements [RFC8106]. The client uses such a name as the domain name in the procedure of Section 5. The client records the network as the source of the name. A client can also learn browse domains through the domain enumeration of Section 11 of [RFC6763] and use each of them as the domain name. 4.4.2. Multicast DNS On the local link, a client browses for "_ard._tcp.local." over Multicast DNS [RFC6762], using the same PTR, SRV, and TXT records as in Section 4.2.2. Names under "local." do not appear in certificates issued by public CAs. A publisher that advertises over Multicast DNS SHOULD set the SRV target to a unicast DNS name for which it holds a certificate, so that the entry point URI names a host the client can authenticate. The client resolves such a target through unicast DNS and ignores address records for it in a multicast answer, since a Multicast DNS responder is authoritative only for names under "local." (Section 6 of [RFC6762]). TLS authenticates the host in either case (Section 6.1). A responder that accepts only "local." targets yields entry points the client cannot authenticate (Section 6.2). On a network without unicast DNS names or public certificates, the outcome for such entry points is "not permitted" unless local policy, such as a pinned key, allows the fetch (Section 5.1). The client stops collecting responses after a configured interval; responses received later are processed as new entry points. Where a Discovery Proxy [RFC8766] is deployed, the client can use Section 4.2.2 instead. Entry points learned over Multicast DNS carry the network interface as their source (Section 6.2). Jiménez, et al. Expires 3 May 2027 [Page 10] Internet-Draft ARD Initial Contact October 2026 [I-D.jakab-dawn-agent-discovery-mdns] describes browsing for individual agents under "_agent._tcp". The two service types are independent. 5. Client Procedure The procedure in this section is a RECOMMENDED default. The well- known fetch of step 4, the depth limits of Section 5.1, and the rate limiting below are requirements on every client. A client MAY reorder or omit the other steps under local policy. The procedure takes a domain name as input, written below, obtained from configuration, from the user, or from the network (Section 4.4.1). An internationalized domain name is used in its A-label form [RFC5890] in DNS owner names and in URIs. The procedure continues after a step returns an entry point; step 5 is performed only when steps 2 to 4 produce no manifest. A client without a domain name first tries to obtain one from the network (Section 4.4.1). If none is available, it performs step 1 and queries "_ard._tcp.local." over Multicast DNS (Section 4.4.2); steps 2 to 5 do not apply. 1. The client uses configured entry points (Section 4.1) first. 2. The client queries the SVCB record for _index._agents. (Section 4.2.1). 3. The client queries the PTR records at _ard._tcp. (Section 4.2.2). 4. The client requests https:///.well-known/ard.json (Section 4.3.1). This step MAY be performed in parallel with steps 2 and 3. 5. If steps 2 to 4 produce no manifest, the client sends a HEAD request to https:/// and examines the Link header field for the "ard" relation (Section 4.3.2). The procedure ends when every step has returned. A client attempts each distinct URI once per execution of the procedure and records all its sources. The default order of preference is: configuration, then DNS answers validated with DNSSEC [RFC4033], then responses from the publisher's own origin (steps 4 and 5), then unvalidated DNS answers, then Multicast DNS responses. An answer is validated when the client validated it or received it with the AD bit set from a trusted validating resolver over a secure channel (Section 4.9.3 of Jiménez, et al. Expires 3 May 2027 [Page 11] Internet-Draft ARD Initial Contact October 2026 [RFC4035]); Insecure and Indeterminate answers (Section 4.3 of [RFC4035]) are unvalidated, and Bogus answers are discarded. An entry point is validated when every answer used to form its URI was; address records do not count, since TLS authenticates the host. Within a level, entry points are ordered by step; within a source, by SvcPriority, or by SRV priority with weight as the tie-breaker. A client MAY reorder entry points under local policy. Entry points learned over Multicast DNS MUST rank last (Section 6.2). The order determines which entry point the client retrieves first and which sources it rate-limits; it confers no trust on the entries of a manifest (Section 6). An entry point fails when the outcome of its retrieval is "no manifest" (Section 5.1). A client MUST NOT retry a failed entry point from the same source before a back-off interval of at least 30 seconds. A client MUST NOT issue the DNS queries of steps 2 and 3 for the same domain name more often than the TTLs of the answers allow, including negative answers ([RFC2308]); a client that validates answers itself applies the same rule to its DNSKEY and DS queries. A client MUST NOT repeat the requests of steps 4 and 5 while a stored response is fresh ([RFC9111]). 5.1. Indirection Depth and Outcomes A client follows at most one AliasMode indirection in the DNS and at most one HTTP redirect per entry point, from any mechanism; the two limits are independent. A second indirection of either kind ends the attempt. This bounds the number of round trips and prevents an attacker who controls one record or one response from leading the client through a chain of indirections. Each attempt to retrieve an entry point has one of three outcomes: Manifest: The URI returned an ARD manifest from an authenticated origin. No manifest: The URI did not respond, returned a response that is not a manifest, exceeded the depth limit, or failed the checks of Section 6. The failure is attributed to the source. Not permitted: The client's own policy did not allow the fetch, for instance a host under "local." that no certificate can authenticate (Section 6.2), or a host not on an allow-list. The entry point is retained with its source, and no failure is attributed to the source. Jiménez, et al. Expires 3 May 2027 [Page 12] Internet-Draft ARD Initial Contact October 2026 6. Security Considerations Initial contact takes place before any authenticated relationship exists between the client and the publisher. In each mechanism, an attacker who controls the channel can direct the client to a manifest of the attacker's choosing. The mitigation is the same for all mechanisms: the client treats the result as unverified, retrieves the manifest from the URI, and authenticates the origin. Initial contact then delivers an ARD manifest from a TLS-authenticated host, together with a record of how the URI was learned. It establishes nothing about the publisher of any entry: [ARD] establishes the publisher of each entry from the entry itself, through a signature bound to the publisher's domain name. 6.1. Entry Points and Authority A client MUST authenticate the TLS server for the host named in the entry point URI (Section 4.3.3 of [RFC9110]). For the well-known URI, that host is the publisher's own domain. For the index record, for DNS-SD, and for a link whose target is on another origin, the host is taken from the answer or the link, and a spoofed answer can direct the client to a host for which the attacker holds a valid certificate. A client SHOULD validate DNS answers with DNSSEC [RFC4033] where the zone is signed and SHOULD rank unvalidated answers below validated ones (Section 5). This document does not establish that a manifest reached through _index._agents.example.com is published by "example.com", and the per-entry check of [ARD] does not take the source into account. The source serves the ranking and rate limiting of Section 5 and local policy such as an allow-list of hosts; it lets a client tell a manifest retrieved from the publisher's own origin from one reached through a DNS answer or a third-party link. Carrying a digest or a public key for the manifest in the DNS record, as [I-D.nemethi-dawn-aid] does for its objects, was considered and not adopted, since a manifest changes with every published entry. 6.2. Local Network Discovery Any host on the link can respond to a Multicast DNS query. A client MUST treat entry points learned over multicast as the least trusted source. It SHOULD prefer entry points whose URI names a host it can authenticate with a certificate, and MAY apply local policy, such as a pinned key or an allow-list of hosts. A manifest found over multicast does not establish that the agents listed in it are present on the network or operated by the network's owner. A multicast query produces a response from every matching host on the link; clients MUST follow the query rate limits of [RFC6762]. Jiménez, et al. Expires 3 May 2027 [Page 13] Internet-Draft ARD Initial Contact October 2026 6.3. Downgrade A client MUST NOT fall back to "http" when an "https" entry point fails, and MUST NOT accept an entry point whose scheme is "http". The "alpn" key in SVCB records selects the HTTP version; it does not affect the requirement for TLS. 6.4. Well-Known URI Squatting On shared hosting, the well-known URI can be served by a tenant rather than the domain owner (Section 4 of [RFC8615]). The per-entry publisher check of [ARD] applies to a manifest found through the well-known URI as to any other; a tenant can serve a manifest, but its entries will not pass the check as entries of the domain owner. 7. Privacy Considerations A DNS query for _index._agents.example.com or _ard._tcp.example.com reveals to the resolver, and to any observer on the path, that the client is querying for agent manifests of example.com. Encrypted DNS transports, discovered as described in [RFC9462], limit the observers to the resolver. The well-known fetch is indistinguishable from an ordinary connection to the domain. The TLS Server Name Indication reveals the TargetName host unless the "ech" key [RFC9848] is used, and DNSSEC validation adds DNSKEY and DS queries to the parent zones. Browsing over Multicast DNS reveals to all hosts on the link that the client is looking for agent manifests, and a responding host reveals that it advertises one. Deployments where this is a concern can use unicast DNS-SD through a Discovery Proxy [RFC8766] with access control on the zone, or configuration. The service instance names under _ard._tcp. can be enumerated by any party; they identify manifests that a publisher has chosen to make discoverable, and they need not identify people or individual agents; the publisher chooses the names. Retrieving the manifest reveals the client's address to the publisher. 8. IANA Considerations 8.1. Well-Known URI IANA is asked to register the following entry in the "Well-Known URIs" registry defined in [RFC8615]: URI suffix: ard.json Jiménez, et al. Expires 3 May 2027 [Page 14] Internet-Draft ARD Initial Contact October 2026 Change controller: IETF Specification document: This document, Section 4.3.1. The format of the resource is defined in [ARD]. Status: permanent Related information: The resource is an ARD manifest. 8.2. Link Relation IANA is asked to register the following entry in the "Link Relations" registry defined in [RFC8288]: Relation name: ard Description: Refers to an Agent Resource Discovery (ARD) manifest, a document listing agent resources. Reference: This document, Section 4.3.2. 8.3. Service Name IANA is asked to register the following service name in the "Service Name and Transport Protocol Port Number Registry" defined in [RFC6335], without an associated port number: Service name: ard Transport protocol: tcp Assignee: IESG Contact: IETF Chair Description: Agent Resource Discovery (ARD) manifest Jiménez, et al. Expires 3 May 2027 [Page 15] Internet-Draft ARD Initial Contact October 2026 Reference: This document, Section 4.2.2. 9. References 9.1. Normative References [ARD] Bu, J., Guha, R.V., Smith, S., Jiménez, J., and J. Damick, "Agent Resource Discovery (ARD): Manifest and Lookup", Work in Progress, Internet-Draft, draft-bu-dawn-ard- discovery, October 2026, . [ARD-ARCH] Bu, J., Guha, R.V., Arkko, J., and J. Jiménez, "Agent Resource Discovery (ARD) Architecture", Work in Progress, Internet-Draft, draft-bu-dawn-ard-architecture, October 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . Jiménez, et al. Expires 3 May 2027 [Page 16] Internet-Draft ARD Initial Contact October 2026 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9848] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", RFC 9848, DOI 10.17487/RFC9848, March 2026, . 9.2. Informative References Jiménez, et al. Expires 3 May 2027 [Page 17] Internet-Draft ARD Initial Contact October 2026 [A2A] Linux Foundation, "Agent2Agent (A2A) Protocol Specification", 2025, . [ARD-SPEC] ARD Project, "Agentic Resource Discovery Specification, v0.91", October 2026, . [DAWN-CHARTER] IETF, "Discovery of Agents With Names (DAWN) Charter", 2026, . [I-D.besleaga-agentic-knowledge-wellknown] Besleaga, A. N., "The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts", Work in Progress, Internet-Draft, draft-besleaga-agentic-knowledge- wellknown-01, 14 October 2026, . [I-D.cui-dawn-mdi-model] Cui, Y., "An Information Model for Minimum Discoverable Information (MDI)", Work in Progress, Internet-Draft, draft-cui-dawn-mdi-model-00, 3 July 2026, . [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-farrel- dawn-terminology-06, 28 October 2026, . [I-D.jakab-dawn-agent-discovery-mdns] Jakab, L. and F. Brockners, "Zero-Configuration Agent Discovery", Work in Progress, Internet-Draft, draft-jakab- dawn-agent-discovery-mdns-01, 28 October 2026, . [I-D.jimenez-agent-directory] Jimenez, J., "Agent Directory", Work in Progress, Internet-Draft, draft-jimenez-agent-directory-01, 8 May 2026, . Jiménez, et al. Expires 3 May 2027 [Page 18] Internet-Draft ARD Initial Contact October 2026 [I-D.jimenez-dawn-discovery-landscape] Jimenez, J., Feng, J., Arkko, J., Kühlewind, M., and R. Kandoi, "A Survey of AI Agent Discovery Mechanisms", Work in Progress, Internet-Draft, draft-jimenez-dawn-discovery- landscape-00, 3 July 2026, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet- Draft, draft-king-dawn-requirements-02, 19 October 2026, . [I-D.mk-dnsop-svcb-well-known] Mozley, J. and D. King, "An SVCB Service Parameter for Well-Known URI Paths", Work in Progress, Internet-Draft, draft-mk-dnsop-svcb-well-known-01, 19 October 2026, . [I-D.morrison-mcp-dns-discovery] Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", Work in Progress, Internet-Draft, draft-morrison-mcp-dns-discovery-09, 21 October 2026, . [I-D.mozleywilliams-dnsop-dnsaid] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27 May 2026, . [I-D.nemethi-dawn-aid] Nemethi, B., "Agent Identity and Discovery (AID)", Work in Progress, Internet-Draft, draft-nemethi-dawn-aid-00, 2 September 2026, . [I-D.pro-adp-agent-discovery] Lian, B., "Agent Discovery Protocol (ADP) v1.1 -- Well- Known Metadata and Interaction Layer", Work in Progress, Internet-Draft, draft-pro-adp-agent-discovery-02, 23 June 2026, . Jiménez, et al. Expires 3 May 2027 [Page 19] Internet-Draft ARD Initial Contact October 2026 [I-D.seethiraju-dawn-dan] Seethiraju, R. R., Thakar, S., Shyamsunder, K., and E. Osterweil, "DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery", Work in Progress, Internet-Draft, draft-seethiraju-dawn-dan-01, 30 October 2026, . [I-D.zahed-acap] Sarker, Z. and T. Reddy.K, "Agent Capability Advertisement Protocol (ACAP)", Work in Progress, Internet-Draft, draft- zahed-acap-00, 25 June 2026, . [MCP] Anthropic, "Model Context Protocol Specification", 2025, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, . [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, . [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, . Jiménez, et al. Expires 3 May 2027 [Page 20] Internet-Draft ARD Initial Contact October 2026 [RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2022, . [RFC9264] Wilde, E. and H. Van de Sompel, "Linkset: Media Types and a Link Relation Type for Link Sets", RFC 9264, DOI 10.17487/RFC9264, July 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9461] Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, . [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, November 2023, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [RFC9727] Smith, K., "api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs", RFC 9727, DOI 10.17487/RFC9727, June 2025, . Appendix A. Related Work [I-D.jimenez-dawn-discovery-landscape] surveys agent discovery mechanisms and separates lookup, name, description, trust, and interaction. Initial contact is the lookup component for the case where the result is a manifest. The entry point of Section 3 is a subset of the minimum discoverable information of [I-D.cui-dawn-mdi-model], the well-known URI is the predictable entry point that REQ-PROTO-4 of [I-D.king-dawn-requirements] asks for, and the terminology of [I-D.farrel-dawn-terminology] applies. DNS-AID [I-D.mozleywilliams-dnsop-dnsaid] publishes agents as SVCB records and an organization index under _index._agents., and leaves the data behind the index out of scope. Section 4.2.1 uses the index record with an ARD manifest as its target. [I-D.mk-dnsop-svcb-well-known] defines a SvcParamKey through which an Jiménez, et al. Expires 3 May 2027 [Page 21] Internet-Draft ARD Initial Contact October 2026 SVCB or HTTPS record announces the well-known URI suffixes a host serves; once the key is registered, the HTTPS record of a domain can announce the suffix of Section 4.3.1 before the client connects. The DNS-AID reference implementation follows an off-domain pointer only when the record is DNSSEC-validated or the manifest is signed against the domain's key set, and refuses redirects; Section 5.1 allows one redirect, and the trust decision for off-domain pointers is left to the publisher check of [ARD]. The ARD specification [ARD-SPEC], from which [ARD] derives, requires the well-known fetch of "/.well-known/ ard.json" and lists _entries._agents for a static entry source and _search._agents for a registry endpoint. [I-D.nemethi-dawn-aid], [I-D.morrison-mcp-dns-discovery], and [I-D.seethiraju-dawn-dan] locate individual agents or MCP servers through DNS records at _agent., at _mcp., or in new resource record types; none defines a manifest entry point. [I-D.jakab-dawn-agent-discovery-mdns] browses for agents on the local link under "_agent._tcp". [I-D.zahed-acap], [I-D.pro-adp-agent-discovery], and [I-D.besleaga-agentic-knowledge-wellknown] publish operator-level discovery documents at well-known URIs. The last publishes an [RFC9264] link set, which is the closest existing design to publishing an ARD manifest as an [RFC9727] API catalog (Appendix B). Section 4.1 of [RFC9176] lists how a CoRE endpoint finds a Resource Directory: configuration, a Router Advertisement option, DNS-SD, and multicast. Section 4.1, Section 4.4.1, Section 4.2.2, and Section 4.4.2 are the ARD counterparts. [RFC9461] and [RFC9462] are the SVCB mapping and the discovery procedure for encrypted DNS resolvers; Section 4.2.1 and Section 5 follow the same structure. Appendix B. Open Issues The following questions are to be settled before the document is stable. This section is to be removed before publication. 1. API catalog profile. A proposal on the ARD side is to publish the manifest as an [RFC9727] API catalog under "/.well-known/api- catalog" with an ARD profile. If adopted, this document registers no suffix. 2. Pointer label. This document uses _index._agents. for the organization index pointer (which is also used by [I-D.mozleywilliams-dnsop-dnsaid], whose reference implementation publishes _catalog._agents), whereas [ARD-SPEC] lists _entries._agents for a static manifest and _search._agents for a registry endpoint. Consolidating the underscored pointer label(s) and their [RFC8552] registration is a topic for DAWN. Jiménez, et al. Expires 3 May 2027 [Page 22] Internet-Draft ARD Initial Contact October 2026 3. Suffix and relation name. "ard.json" matches [ARD-SPEC] and deployed code. A suffix without the extension, "ard", was considered. The link relation name "ard" also matches [ARD-SPEC]; the registry expert may ask for a descriptive name such as "ard-manifest". 4. Reference status. [ARD] and [ARD-ARCH] are normative references to companion individual drafts submitted together with this document. 5. HTTPS record at the apex. An earlier version let the HTTPS record of a domain announce the suffix through the "well-known" SvcParamKey of [I-D.mk-dnsop-svcb-well-known]. The mechanism was removed because the key has no registered number, syntax, or encoding yet; it is to be reconsidered once the key is registered. 6. Registry endpoints. [ARD-SPEC] also points to a registry endpoint through _search._agents.. This document yields manifests only. Extending the entry point to registry endpoints is a question for DAWN. Acknowledgments The split of the ARD work into initial contact, lookup, and registration documents was proposed by Jari Arkko. R.V. Guha co- wrote the ARD specification this document builds on. Wes Hardaker and Sam Sharaf took part in the discussions that shaped the scope. The work of Jim Mozley and Daniel King on the organization index provided the DNS binding used here. The depth limit and the fixed outcomes follow a discussion on the DAWN list started by Enrique Somoza and continued by Francesco Marinoni Moretto and Balazs Nemethi. Authors' Addresses Jaime Jiménez Ericsson Email: jaime.jimenez@ericsson.com Junjie Bu Google Email: jbu@google.com Jari Arkko Ericsson Jiménez, et al. Expires 3 May 2027 [Page 23] Internet-Draft ARD Initial Contact October 2026 Email: jari.arkko@ericsson.com Jiménez, et al. Expires 3 May 2027 [Page 24]