An SVCB Service Parameter for Well-Known URI Paths

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SVCB and HTTPS resource records [RFC9460] 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 [RFC8615] give machine-readable metadata a conventional location under "/.well-known/". The IANA "Well-Known URIs" registry holds many such suffixes, for example "api-catalog" [RFC9727] and "agent-card.json", registered by the Linux Foundation for the Agent2Agent protocol [A2A]. 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.¶

The service parameter is defined here as a general primitive so that other specifications can reference it.¶

o DNS for AI Discovery [I-D.mozleywilliams-dnsop-dnsaid] 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.¶

2. The "well-known" SvcParamKey

The "well-known" SvcParamKey advertises one or more well-known URI suffixes [RFC8615], 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.¶

well-known="suffix[,suffix]*"

wk-suffix = segment-nz *( "/" segment )

svc.example.com. 3600 IN HTTPS 1 . (
    alpn="h2,h3"
    well-known="api-catalog"
)
agent.example.com. 3600 IN SVCB 1 host.provider.example (
    alpn="h2,h3"
    well-known="agent-card.json,api-catalog"
)

00 0b | ASCII("api-catalog")
00 0f | ASCII("agent-card.json")
00 0b | ASCII("api-catalog")

well-known="foo/a\\,b"

00 07 | ASCII("foo/a,b")

3. 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 (Section 4).¶

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 [RFC9460]). This does not oblige a client to retrieve any advertised resource.¶

4. 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 [RFC9460]; 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.¶

5. Security Considerations

The security and privacy considerations of [RFC9460] and [RFC8615] 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 [RFC4033]. 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 discloses information about a service; publishers SHOULD keep advertisements compact.¶

6. 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 [RFC9460]:¶

This request does not register individual well-known URI suffixes. Testing before allocation can use the private-use SvcParamKey range of [RFC9460].¶

7. Open Issues

This section is to be removed before publishing as an RFC.¶

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

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

2. 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 [RFC9461] is the existing precedent for a path-valued parameter, but this key is single valued.¶

3. HTTPBIS review. The designated experts asked for consultation with HTTPBIS before a renewed allocation request.¶

8. References

Authors' Addresses