]> Infoblox, Inc.

jmozley@infoblox.com

Old Dog Consulting

daniel@olddog.co.uk

Operations and Management Individual Submission SVCB HTTPS well-known service parameter 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. Status information for this document may be found at . Discussion of this document takes place on the Individual Submission Individual mailing list (), which is archived at . Subscribe at .

Introduction SVCB and HTTPS resource records let a client learn connection parameters for a service before connecting, such as the protocols it supports and alternative endpoints. They do not say which resources are available once connected. Well-known URIs give machine-readable metadata a conventional location under "/.well-known/". The IANA "Well-Known URIs" registry holds many such suffixes, for example "api-catalog" and "agent-card.json", registered by the Linux Foundation for the Agent2Agent protocol . A client that already knows the applicable suffix can construct the URI itself, but it cannot learn from the DNS which of the registered resources a particular service offers. The "well-known" SvcParamKey closes that gap. A service binding advertises the well-known URI suffixes available at its endpoint, so a client can retrieve the resource it needs directly after resolution, without probing. Each DNS record in an RRset carries its own list, so a hosted endpoint or an alternative protocol can advertise different resources. This facilitates allowing entities establishing connections to network services to use the SvcParamValue in making connectivity decisions by indicating available resources. As protocols such as can use different transport, or implementors may create custom protocol bindings to support different transport mechanisms or communication patterns, having "well-known" as an SvcParamKey supports this usage. In agent discovery, a client may not know which of several competing card formats an endpoint supports, so probing each possible well-known path adds multiple round trips at cold start. Example: supplier.webmesh.ai serves ten discovery paths across A2A, MCP, ANS, DID, Web Bot Auth, AI Catalog, UCP, and NANDA. Its SVCB record currently advertises none of them. A discovering client with no prior knowledge of this agent must either probe all ten paths or carry out-of-band knowledge of what the agent supports. Neither is cheap in terms of efficiency or maintenance. The well-known SvcParamKey eliminates that by making the DNS record self-describing: one field, resolved in the same query the client was already making. The service parameter is defined here as a general primitive so that other specifications can reference it. o DNS for AI Discovery is one user of this parameter, advertising the location of an agent's capability descriptor. o Editors note - Authors will add other in progress work.

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

The "well-known" SvcParamKey The "well-known" SvcParamKey advertises one or more well-known URI suffixes , each naming a resource under "/.well-known/" at the service endpoint. A client MAY retrieve any advertised resource. The list need not include every well-known resource available at the endpoint.

Wire Format The wire-format SvcParamValue consists of one or more entries concatenated without separators. Each entry is: a 2-octet unsigned length in network byte order, giving the length of the suffix in octets; then the suffix itself. A decoder reads entries until the SvcParamValue is exhausted. A value that ends inside an entry, or that contains a zero-length entry, does not have the expected format, so the RR is malformed (Section 2.2 of ).

Presentation Format

The value is a comma-separated list of one or more suffixes, using the character-string and list escaping rules of Section 2.1 and Appendix A.1 of . Empty items and whitespace around separators are not allowed. A suffix MUST only appear once in the list. Each decoded suffix MUST match this ABNF :

The segment-nz and segment rules are from Section 3.3 of . A suffix does not begin with "/", does not include the "/.well-known/" prefix, and carries no query or fragment component. A suffix may extend below a registered well-known name where that registration allows it, such as . Non-ASCII characters MUST be percent-encoded. Invalid percent escapes and segments equal to "." or "..", including their percent-encoded forms, MUST be rejected. Other percent-encoded octets MUST be preserved without decoding or normalisation. A value containing a suffix that fails these checks does not have the expected format, so the RR is malformed. Each decoded suffix is encoded as one length-prefixed entry (). Conversion in either direction MUST preserve suffix octets and list order, using the escaping rules for presentation output.

Examples The examples use the requested key name for illustration; no allocation is implied.

The first record advertises one resource at the owner name, "https://svc.example.com/.well-known/api-catalog". The second, with a hosted TargetName, advertises two resources at that host. Their wire-format SvcParamValues are, respectively, the first entry below and the second and third entries concatenated:

The suffix lengths are 11 and 15 octets; the two values are 13 and 30 octets. The following single-suffix value contains a literal comma:

Character-string decoding produces "foo/a\,b"; list decoding produces "foo/a,b". Its wire value is:

Interactions with Other SvcParamKeys The "well-known" key MAY appear alongside any other SvcParamKey. The "alpn" key selects the protocol used to retrieve a resource; the "port" key and the TargetName affect the origin (). Each ServiceMode record carries its own "well-known" value. The key MUST be ignored when it appears in an AliasMode record. If "well-known" is listed in "mandatory", a client that does not implement it MUST skip the record (Section 8 of ). This does not oblige a client to retrieve any advertised resource.

Resolving and Retrieving Advertised Resources A client forms the URI of an advertised resource by appending "/.well-known/" and the suffix to the origin of the service. For HTTPS records, the origin is that of the URI being resolved, as in Section 9 of ; the "port" key changes the connection port, not the origin. For SVCB records, the specification that maps the service to SVCB defines the scheme and authority. Where it does not, the origin is "https" at the TargetName (or the owner name when TargetName is "."), using the "port" key or 443.

Security Considerations The security and privacy considerations of and apply. The "well-known" parameter is conveyed in the DNS and has the same integrity properties as the enclosing record. The value is free text. It is deliberately not constrained to the suffixes in the IANA "Well-Known URIs" registry: an enumerated encoding would require DNS software to change each time a suffix is registered, and neither authoritative servers nor resolvers are positioned to validate it. A publisher, or an attacker able to alter records, can therefore advertise any string. Clients MUST treat an advertised suffix as metadata, not as a trust signal. A suffix that is well formed, or even registered, implies nothing about whether a resource exists at that location or whether its contents are trustworthy. A client MUST NOT relax endpoint authentication, destination restrictions, or redirect policy because a suffix was advertised in the DNS. Publishers MAY sign records carrying this key with DNSSEC . DNSSEC lets a validating resolver confirm that the record was published by the zone's authoritative source and was not altered in transit. It does not validate the suffix or the resource it names. Forged or hostile advertisements can induce unwanted requests or disclose client interests. Implementations SHOULD bound retrieval work rather than fetch every advertised resource. Publishing suffixes disclose information about a service; publishers SHOULD keep advertisements compact and related to making connections to network services.

IANA Considerations IANA is requested to add the following entry to the "Service Parameter Keys (SvcParamKeys)" registry, in the "DNS Service Bindings (SVCB)" registry group, per the procedure defined in Section 14.3 of : Number Name Meaning Format Reference Change Controller TBD well-known One or more well-known URI suffixes available at the service endpoint (This document) IETF This request does not register individual well-known URI suffixes. Testing before allocation can use the private-use SvcParamKey range of .

Open Issues This section lists questions on which the authors seek input, in particular from the DNSOP and HTTPBIS working groups. It will be removed before publication. Suffix-only values. This document carries the suffix without the "/.well-known/" prefix, matching the IANA registry and saving octets. The original registration request and the current DNS-AID draft use full paths. Wire encoding. A list of length-prefixed entries is proposed, as used by other list-valued SvcParamKeys. An existing DNS-AID implementation carries a single string at a private-use key. Implementer input is welcome. The "dohpath" key is the existing precedent for a path-valued parameter, but this key is single valued. HTTPBIS review. The designated experts asked for consultation with HTTPBIS before a renewed allocation request.

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. 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] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] 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. 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. 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] 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 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. Linux Foundation Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

Acknowledgments The authors also would like to thank the following people for their contributions: Scott Courtney