________________________________
From: Michel Le Bihan <[email protected]>
Sent: Monday, August 18, 2025 11:41 AM
...
1. What was the rationale for requiring ALPN identifiers in SVCB
records to uniquely identify the complete protocol suite, including
transport?
When choosing among the various endpoints, clients need to know which of those
endpoints support a compatible ALPN ID. For example, an HTTP/1.1-only client
should not attempt to connect to an HTTP/2-only server, even though both use
the same transport protocols. This means that ALPN IDs must be present in the
SVCB record.
Given that ALPN IDs must be present, including the transport explicitly would
normally be redundant. It would also create the possibility of illogical or
self-contradictory records, such as a record claiming to support HTTP/3 but not
QUIC.
At the time this design was selected (2020) [1], the only ALPN IDs that didn't
uniquely identify the transport were STUN/TURN (RFC 7443), which seemed
unlikely to use SVCB anyway.
2. Were alternative designs considered, such as:
* Having a separate SvcParam to indicate supported transports
Yes, that was the previous design.
* Allowing multiple transport protocols to be associated with a
single ALPN identifier within the SVCB framework
No, as this would create ambiguity about whether an endpoint is compatible with
the client.
* Using a structured ALPN value that could encode both application
protocol and transport
This can be done by registering unique ALPN values for each transport. For
example, DNS uses the ALPN IDs "dot" for TLS and "doq" for QUIC.
3. For protocols like XMPP that have chosen to reuse ALPN identifiers
across transports, what is the recommended approach for using SVCB
records?
I recommend allocating 4 new ALPN IDs, for XMPP (client/server) x (TLS/QUIC).
Clients and servers SHOULD offer both the old and new ALPN IDs (at least during
a transition period of several years), but only the new ones can appear in SVCB
records.
Many other arrangements are possible using custom SvcParams, but that will take
a lot more work to specify, understand, and implement, for no obvious benefit.
--Ben
[1] https://github.com/MikeBishop/dns-alt-svc/pull/116#issuecomment-595320955
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
