Agent Resource Discovery (ARD): Initial Contact

Internet-Draft	ARD Initial Contact	October 2026
Jiménez, et al.	Expires 3 May 2027	[Page]

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

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

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

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

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.<domain> 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".¶
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.<domain> 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"
)

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://<domain>/.¶

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

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: <https://agents.example.com/manifest>; rel="ard"

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

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

The client uses configured entry points (Section 4.1) first.¶
The client queries the SVCB record for _index._agents.<domain> (Section 4.2.1).¶
The client queries the PTR records at _ard._tcp.<domain> (Section 4.2.2).¶
The client requests https://<domain>/.well-known/ard.json (Section 4.3.1). This step MAY be performed in parallel with steps 2 and 3.¶
If steps 2 to 4 produce no manifest, the client sends a HEAD request to https://<domain>/ 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 [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.¶

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

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

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, <https://datatracker.ietf.org/doc/draft-bu-dawn-ard-discovery/>.
[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, <https://datatracker.ietf.org/doc/draft-bu-dawn-ard-architecture/>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2308]: Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/rfc/rfc2308>.
[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, <https://www.rfc-editor.org/rfc/rfc3986>.
[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, <https://www.rfc-editor.org/rfc/rfc4033>.
[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, <https://www.rfc-editor.org/rfc/rfc4035>.
[RFC5890]: Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.
[RFC6335]: Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/rfc/rfc6335>.
[RFC6762]: Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/rfc/rfc6762>.
[RFC6763]: Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/rfc/rfc6763>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8288]: Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/rfc/rfc8288>.
[RFC8615]: Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.
[RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.
[RFC9460]: Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[RFC9848]: Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", RFC 9848, DOI 10.17487/RFC9848, March 2026, <https://www.rfc-editor.org/rfc/rfc9848>.

9.2. Informative References

[A2A]: Linux Foundation, "Agent2Agent (A2A) Protocol Specification", 2025, <https://a2a-protocol.org/latest/specification/>.
[ARD-SPEC]: ARD Project, "Agentic Resource Discovery Specification, v0.91", October 2026, <https://agenticresourcediscovery.org/spec/>.
[DAWN-CHARTER]: IETF, "Discovery of Agents With Names (DAWN) Charter", 2026, <https://datatracker.ietf.org/doc/charter-ietf-dawn/>.
[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, <https://datatracker.ietf.org/doc/html/draft-besleaga-agentic-knowledge-wellknown-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-cui-dawn-mdi-model-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-farrel-dawn-terminology-06>.
[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, <https://datatracker.ietf.org/doc/html/draft-jakab-dawn-agent-discovery-mdns-01>.
[I-D.jimenez-agent-directory]: Jimenez, J., "Agent Directory", Work in Progress, Internet-Draft, draft-jimenez-agent-directory-01, 8 May 2026, <https://datatracker.ietf.org/doc/html/draft-jimenez-agent-directory-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-jimenez-dawn-discovery-landscape-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements-02>.
[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, <https://datatracker.ietf.org/doc/html/draft-mk-dnsop-svcb-well-known-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery-09>.
[I-D.mozleywilliams-dnsop-dnsaid]: Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27 May 2026, <https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-dnsaid-02>.
[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, <https://datatracker.ietf.org/doc/html/draft-nemethi-dawn-aid-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-pro-adp-agent-discovery-02>.
[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, <https://datatracker.ietf.org/doc/html/draft-seethiraju-dawn-dan-01>.
[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, <https://datatracker.ietf.org/doc/html/draft-zahed-acap-00>.
[MCP]: Anthropic, "Model Context Protocol Specification", 2025, <https://modelcontextprotocol.io/specification/>.
[RFC2132]: Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/rfc/rfc2132>.
[RFC3646]: Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/rfc/rfc3646>.
[RFC4343]: Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/rfc/rfc4343>.
[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, <https://www.rfc-editor.org/rfc/rfc8106>.
[RFC8552]: Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.
[RFC8766]: Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, <https://www.rfc-editor.org/rfc/rfc8766>.
[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, <https://www.rfc-editor.org/rfc/rfc9176>.
[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, <https://www.rfc-editor.org/rfc/rfc9264>.
[RFC9457]: Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.
[RFC9461]: Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.
[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, <https://www.rfc-editor.org/rfc/rfc9462>.
[RFC9499]: Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/rfc/rfc9499>.
[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, <https://www.rfc-editor.org/rfc/rfc9727>.

Agent Resource Discovery (ARD): Initial Contact

Abstract

About This Document

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Conventions and Definitions

3. The Entry Point