In general, you should avoid adding path-parameters if possible. "dohpath" was only needed for DoH because (1) we needed to be able to bootstrap from a bare domain name for compatibility with pre-existing DNS configuration practices and (2) we were unable to agree on a .well-known configuration approach.
Path-parameters have several problems: - SVCB does not presume secure resolution, so the path parameter could be modified by an attacker. It is generally not authenticated. - If the path changes, updating the DNS to reflect the change is more difficult than updating a .well-known file. - Escaping of special characters in path names and in DNS zone files is different, creating potential for confusion. - They lose the flexibility of paths to represent multiple distinct resources or services on a single origin. In general, SVCB is designed to represent the authority portion of a URI, with the rest being known "a priori" to the client. --Ben ________________________________ From: Mike Bishop <[email protected]> Sent: Tuesday, August 19, 2025 3:47 PM To: Michel Le Bihan <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Path Parameter Considerations for SVCB Records (rfc9460) Responding with no hats, but off the top of my head, DNS-over-CoAP defines a similar-in-spirit but different-in-format "docpath" element. (See https: //datatracker. ietf. org/doc/html/draft-ietf-core-dns-over-coap. ) I think there could Responding with no hats, but off the top of my head, DNS-over-CoAP defines a similar-in-spirit but different-in-format "docpath" element. (See https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap__;!!Bt8RZUm9aw!57_fDeHV3EErOr6N9EnFxU4gfxlUjnLhR7eSuc1CmPeuNDg7eFGoLHvWaXxJOiNh5IwNd73QIgfBJNnj$>.) I think there could be some value in a more generic "protocol endpoint represented by a URI path, not just a host:port tuple" SvcParam, but no one has defined one yet. However, note that it's possible for one SVCB record to indicate multiple protocol options, and those multiple protocols might reside at differing paths, as in this example indicating colocated DoC and DoH support: _dns.example.org. 429 IN SVCB 1 dns.example.org ( alpn=h3,co dohpath=/{?dns} docpath ) So such a SvcParam would probably need the ability to represent a dictionary of ALPNs and the paths associated with each. At that point, it could be simpler to define a SvcParam per protocol as has already been done for DoH/DoC. However, if you have a suite of related protocols where you can be confident the path would be the same, you could certainly define a SvcParam which applied to all of those at once. ________________________________ From: Michel Le Bihan <[email protected]> Sent: Tuesday, August 19, 2025 3:11 PM To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Path Parameter Considerations for SVCB Records (rfc9460) Dear IETF DNSOP Working Group, Thank you for your response to my previous inquiry regarding ALPN identifier requirements in RFC 9460. I would like to raise a related question concerning path parameters in SVCB records. In addition to the TLS/TCP and QUIC transports discussed in my previous email, XMPP also supports WebSocket (RFC 7395) and BOSH (XEP-0206) as transport mechanisms. These protocols require path information that is currently discovered through well-known URIs (e.g., https://im.example.org/.well-known/host-meta<https://urldefense.com/v3/__https://im.example.org/.well-known/host-meta__;!!Bt8RZUm9aw!57_fDeHV3EErOr6N9EnFxU4gfxlUjnLhR7eSuc1CmPeuNDg7eFGoLHvWaXxJOiNh5IwNd73QIp30dwzy$> <https://im.example.org/.well-known/host-meta<https://urldefense.com/v3/__https://im.example.org/.well-known/host-meta__;!!Bt8RZUm9aw!57_fDeHV3EErOr6N9EnFxU4gfxlUjnLhR7eSuc1CmPeuNDg7eFGoLHvWaXxJOiNh5IwNd73QIp30dwzy$>>). I note that DNS over HTTPS addressed a similar requirement by introducing the "dohpath" SvcParamKey (RFC 9461). However, creating protocol-specific path parameters for each application protocol that requires them seems to present scalability concerns. My questions are: 1. Has consideration been given to a generic path parameter that could be used across multiple protocols, rather than protocol-specific keys like "dohpath"? 2. What is the recommended approach for protocols that require path information when using SVCB records? Should each protocol: * Define its own path SvcParamKey (following the DoH precedent)? * Continue relying on well-known URIs for path discovery? * Consider an alternative mechanism? 3. Are there architectural reasons for preferring protocol-specific path parameters over a generic solution? Your guidance on this matter would be valuable for ensuring consistent implementation approaches across protocols that require path information in their service bindings. Best regards, Michel Le Bihan
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
