]> Ericsson

jaime.jimenez@ericsson.com

Google

jbu@google.com

Ericsson

jari.arkko@ericsson.com

Internet Discovery of Agents With Names (DAWN) agent discovery well-known URI SVCB DNS-SD mDNS DAWN 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 Status information for this document may be found at . Discussion of this document takes place on the Discovery of Agents With Names (DAWN) Working Group mailing list (), which is archived at . Subscribe at .

Introduction Agent Resource Discovery (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 or an MCP server description . ARD also defines a lookup interface over the manifest. Both require the URI of the manifest. The ARD architecture is described in . leaves the mechanisms by which a client obtains that URI to this document. The applicable IETF mechanisms, well-known URIs , web linking , Service Binding records , and DNS-SD with Multicast DNS , 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 at the organization index name _index._agents.<domain> with an ARD manifest as its target ();
• a DNS-SD service type , "_ard._tcp", for use over unicast DNS and Multicast DNS (, );
• a well-known URI with the suffix "ard.json" ();
• a link relation , "ard", whose target is an ARD manifest ().

specifies how a client combines these mechanisms. The DAWN charter calls this step "initial discovery"; this document uses the term "initial contact" for the same step, and the term "manifest", from , 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 and . 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.

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. This document uses the DNS terminology of , the DNS-SD terms "service type", "service instance", "browse", and "resolve" from , and the HTTP terms "origin" and "authoritative" from Sections and of .

ARD manifest:

A document listing agent resources in the format defined in .

Entry point:

The URI of an ARD manifest, together with the source from which the client learned it (). 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.

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.

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 at which, according to the source, an ARD manifest is served in a representation defined by .

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 (), 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 (); the outcomes of that retrieval are defined in . 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 ; 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 ; following those links is part of lookup and is outside the scope of this document. Initial contact ends at the manifest.

Discovery Mechanisms The well-known URI of 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 . The mechanisms of and take a domain name as input. The mechanisms of require no domain name.

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

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 remains in place: the apex serves the manifest or redirects to it ().

Organization Index Record A publisher MAY publish a Service Binding (SVCB) record at _index._agents.<domain> whose TargetName identifies a host that serves an ARD manifest at the well-known URI of (this owner name is also used as an organization index pointer in , which leaves the index document format out of scope). The following is an example for example.com: 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 () are resolved by the client.
• The "mandatory" key is processed as in : 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 semantics, and the "ech" key with its semantics. Other keys are ignored.
• One AliasMode indirection is followed (); a second ends the attempt (). 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" (); the host can still serve an index in another format, which this document does not interpret.

DNS-SD Service Type "_ard._tcp" A publisher MAY advertise manifests as DNS-SD service instances 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: The TXT record carries the following keys, with the syntax of :

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 ; 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 . 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 . Service instance names such as "Travel" are user-visible names; allows them to change, and a server need not preserve their case (). A client SHOULD NOT use an instance name as a persistent identifier of a manifest.

Origin-Based Mechanisms The mechanisms in this section use an HTTP request to the origin https://<domain>/.

Well-Known URI A publisher makes its manifest available at the well-known URI with the suffix "ard.json". For the domain example.com, the well-known URI is: 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 , 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, ) 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" (). A 404 (Not Found) response has the outcome "no manifest"; it MAY include Problem Details . Responses to the well-known URI, including redirects and 404 responses, are cacheable under . A client reuses a stored response while it is fresh (). 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 (); 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 (). The registration of the suffix is in .

Link Relation A publisher MAY include a link to a manifest in any HTTP response using the "ard" link relation 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 , where the "api-catalog" relation appears in the response to the root resource. The following is an example: ; 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 () 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 (); a client that retrieves the root resource with GET MAY read it. The procedure of 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 .

Local Network Mechanisms

Network-Provided Domain Name A client without a domain name can obtain one from the network through the DHCPv4 Domain Name option (), the DHCPv6 Domain Search List option , or the DNS Search List option in IPv6 Router Advertisements . The client uses such a name as the domain name in the procedure of . The client records the network as the source of the name. A client can also learn browse domains through the domain enumeration of and use each of them as the domain name.

Multicast DNS On the local link, a client browses for "_ard._tcp.local." over Multicast DNS , using the same PTR, SRV, and TXT records as in . 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." (). TLS authenticates the host in either case (). A responder that accepts only "local." targets yields entry points the client cannot authenticate (). 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 (). The client stops collecting responses after a configured interval; responses received later are processed as new entry points. Where a Discovery Proxy is deployed, the client can use instead. Entry points learned over Multicast DNS carry the network interface as their source (). describes browsing for individual agents under "_agent._tcp". The two service types are independent.

Client Procedure The procedure in this section is a RECOMMENDED default. The well-known fetch of step 4, the depth limits of , 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 (). An internationalized domain name is used in its A-label form 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 (). If none is available, it performs step 1 and queries "_ard._tcp.local." over Multicast DNS (); steps 2 to 5 do not apply.

1. The client uses configured entry points () first.
2. The client queries the SVCB record for _index._agents.<domain> ().
3. The client queries the PTR records at _ard._tcp.<domain> ().
4. The client requests https://<domain>/.well-known/ard.json (). 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://<domain>/ and examines the Link header field for the "ard" relation ().

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 , 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 (); Insecure and Indeterminate answers () 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 (). 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 (). An entry point fails when the outcome of its retrieval is "no manifest" (). 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 (); 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 ().

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 . 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 (), or a host not on an allow-list. The entry point is retained with its source, and no failure is attributed to the source.

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: establishes the publisher of each entry from the entry itself, through a signature bound to the publisher's domain name.

Entry Points and Authority A client MUST authenticate the TLS server for the host named in the entry point URI (). 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 where the zone is signed and SHOULD rank unvalidated answers below validated ones (). 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 does not take the source into account. The source serves the ranking and rate limiting of 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 does for its objects, was considered and not adopted, since a manifest changes with every published entry.

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 .

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.

Well-Known URI Squatting On shared hosting, the well-known URI can be served by a tenant rather than the domain owner (). The per-entry publisher check of 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.

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 , 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 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 with access control on the zone, or configuration. The service instance names under _ard._tcp.<domain> 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.

IANA Considerations

Well-Known URI IANA is asked to register the following entry in the "Well-Known URIs" registry defined in :

URI suffix:

ard.json

Change controller:

IETF

Specification document:

This document, . The format of the resource is defined in .

Status:

permanent

Related information:

The resource is an ARD manifest.

Link Relation IANA is asked to register the following entry in the "Link Relations" registry defined in :

Relation name:

ard

Description:

Refers to an Agent Resource Discovery (ARD) manifest, a document listing agent resources.

Reference:

This document, .

Service Name IANA is asked to register the following service name in the "Service Name and Transport Protocol Port Number Registry" defined in , without an associated port number:

Service name:

ard

Transport protocol:

tcp

Assignee:

IESG

Contact:

IETF Chair

Description:

Agent Resource Discovery (ARD) manifest

Reference:

This document, .

References Normative References RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [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] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. 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. To use TLS Encrypted ClientHello (ECH), the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR). 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. Informative References Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK] This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client. This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links. The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published Application Programming Interfaces (APIs). A request to the api-catalog resource will return a document providing information about, and links to, the Publisher's APIs. 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. 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. Open Agent Registry, Inc. Agent Identity and Discovery (AID) answers one question: given a domain, where is the agent and which protocol should a client speak? An AID client queries a DNS TXT record at the well-known subdomain _agent.<domain> and learns the service endpoint URI, protocol token, authentication hint, and optional metadata for that agent. This document defines the AID v2 (`aid2`) record format, client discovery algorithm, exact-host lookup rules, endpoint-proof (PKA) handshake using Ed25519 HTTP Message Signatures, security requirements, and IANA registrations for the `_agent` DNS node name and the `agent` service name. The legacy `aid1` record format is retained as a compatibility format for clients migrating from earlier deployments. AID is intentionally small; after discovery, protocol- specific mechanisms such as MCP or A2A handle communication and capability negotiation. Verisign Verisign Verisign Verisign The agentic AI ecosystem includes many different technologies and operations. One important aspect is the ability to establish connections between AI agents. In single-platform approaches, the processes and metadata with which AI agents discover, locate, and connect to each other are typically managed by their common platform. This document describes an inter-domain mechanism to enable AI agents to locate and connect to each other using necessary metadata and secure DNS associations, in a similar fashion to the way that DNS- Based Authentication of Named Entities (DANE), RFC6698, does for Transport Layer Security. This is accomplished through two new Resource Record (RR) types: AI Discovery Association (AIDISCA) and AI Index (AIINDEX). 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 obtaining full agent metadata over the agent's native transport, whether by retrieving a description document or by connecting to the agent and performing its native handshake. The DNS-SD records carry a small set of discovery parameters that is shared with agent discovery in unicast DNS. The document gives worked instantiations of that model for the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP). Alter Meridian Pty Ltd This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp.<domain> advertises an MCP server's endpoint URL, agent protocol family, transport binding, cryptographic identity, and capability profile. _org-alter.<domain> advertises the operator's canonical organisational identity, including its legal entity, registry identifier, regions of operation, and any regulatory framework under which it must refuse external automated access. _alter.<domain> publishes an Ed25519-signed envelope binding a ~handle to a public key, an IdentityLog root reference, and a revocation commitment. DNSSEC validation is REQUIRED for the envelope record, and a DANE TLSA pin on the MCP endpoint is REQUIRED where resolving an envelope and opening an MCP session are one recognition transaction. The mechanism complements HTTPS-based discovery, and follows the precedent set by DKIM, SPF, DMARC, and MTA-STS. A companion alter: URI scheme is provisionally registered with IANA. Nokia Nokia This document specifies the Agent Capability Advertisement Protocol (ACAP), a REST-like protocol built on HTTP/3 that defines a structured registry and exchange format for Agent Capability Documents (ACDs). ACAP enables the discovery of AI agents deployed across different administrative domains on the Internet. Each agent exposes an ACAP endpoint, hosted at a well-known URI, that serves ACDs describing the capabilities, authentication requirements, and operational metadata for agents within that domain. ACAP supports three core operations: retrieval, registration, and capability-based search. In deployments where multiple agent operators share hosting infrastructure, ACDs are cryptographically signed to enable secure, decentralized agent discovery. aipair.ai This document defines the Agent Discovery Protocol (ADP) v1.1, a layered protocol for discovering, verifying, and interacting with AI Agents on the Internet. ADP delegates DNS discovery to DNS-AID (SVCB records) and defines a Well-Known JSON metadata format, an Ed25519-based identity model, and the Agent Gateway Protocol (AGP) for real-time WebSocket messaging. The protocol is designed to be decentralized, standards-based, and incremental — clients escalate from DNS to HTTP to WebSocket only as needed. Independent This document defines the "knowledge-linkset" well-known URI, at which a web origin publishes one link set describing the knowledge artefacts it makes available: graph serializations, a JSON-LD context, an agent-facing text file, a chunk export, a change ledger, and related resources. Each artefact link may carry a SHA-256 digest, expressed with the syntax of HTTP digest fields, so that a client can check that a retrieved artefact is the one the publisher described. A profile URI identifies the conventions the link set follows. The mechanism defines no new media type and no new link relation type: a page points at the resource with the existing "describedby" relation. The profile URI is registered in the IANA "Profile URIs" registry. This document requests no IANA action. Ericsson Ericsson Ericsson Ericsson Ericsson This document surveys mechanisms for AI agent discovery being developed at the IETF, at AAIF, at 3GPP, and in open-source projects. It compares them by discovery model, scope, dynamism, cross-domain reach, and semantic capability. It identifies gaps, overlaps, and conflicts between the approaches to inform future standardization work. Old Dog Consulting China Mobile Deutsche Telekom Infoblox The proliferation of distributed Artificial Intelligence (AI) systems and agents has created a need for interoperable mechanisms for components of AI systems to discover each other. This document defines terminology for Discovery of Agents With Names (DAWN), focusing on the terms necessary to describe the discovery of information about AI systems and resources (e.g., AI agents). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. Old Dog Consulting Old Dog Consulting The proliferation of distributed systems, Artificial Intelligence (AI) agents, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents With Names (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. Tsinghua University The Discovery of Agents, Workloads, and Named Entities (DAWN) terminology document defines Minimum Discoverable Information (MDI) as the minimum information an entity must provide to be discoverable, but does not define its field-level content. The DAWN requirements and problem-statement documents identify the need for a standardized minimum structure; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document proposes a small, encoding-neutral information model, in the sense of RFC 3444, for MDI: three mandatory elements, a short set of recommended and optional elements, and the minimal constraints that hold among them. It is a minimum common subset and a mapping target for richer descriptors -- not a new card format and not a discovery protocol. Ericsson This document defines the Agent Directory (AD), a service where agents register their identity, capabilities, and reachable endpoints and where clients discover them by capability. The AD adapts the Constrained RESTful Environments (CoRE) Resource Directory (RFC 9176) from constrained IoT devices to software agents, reusing its registration, lookup, and soft-state lifecycle model. The AD uses HTTP and JSON. MCP and A2A define how agents interact; this document defines how they are found. ARD Project IETF Linux Foundation Anthropic

Related Work 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 is a subset of the minimum discoverable information of , the well-known URI is the predictable entry point that REQ-PROTO-4 of asks for, and the terminology of applies. DNS-AID publishes agents as SVCB records and an organization index under _index._agents.<domain>, and leaves the data behind the index out of scope. uses the index record with an ARD manifest as its target. defines a SvcParamKey through which an 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 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; allows one redirect, and the trust decision for off-domain pointers is left to the publisher check of . The ARD specification , from which 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. , , and locate individual agents or MCP servers through DNS records at _agent.<domain>, at _mcp.<domain>, or in new resource record types; none defines a manifest entry point. browses for agents on the local link under "_agent._tcp". , , and publish operator-level discovery documents at well-known URIs. The last publishes an link set, which is the closest existing design to publishing an ARD manifest as an API catalog (). lists how a CoRE endpoint finds a Resource Directory: configuration, a Router Advertisement option, DNS-SD, and multicast. , , , and are the ARD counterparts. and are the SVCB mapping and the discovery procedure for encrypted DNS resolvers; and follow the same structure.

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 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.<domain> for the organization index pointer (which is also used by , whose reference implementation publishes _catalog._agents), whereas lists _entries._agents for a static manifest and _search._agents for a registry endpoint. Consolidating the underscored pointer label(s) and their registration is a topic for DAWN.
3. Suffix and relation name. "ard.json" matches and deployed code. A suffix without the extension, "ard", was considered. The link relation name "ard" also matches ; the registry expert may ask for a descriptive name such as "ard-manifest".
4. Reference status. and 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 . 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. also points to a registry endpoint through _search._agents.<domain>. 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.