From c52a6cd45080e1c2ada15e2a6733ff19b54fe2e2 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 1 Nov 2022 10:02:35 +0000 Subject: [PATCH 1/3] Remove SRV discovery --- proposals/0000-remove-srv-discovery.md | 84 ++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 proposals/0000-remove-srv-discovery.md diff --git a/proposals/0000-remove-srv-discovery.md b/proposals/0000-remove-srv-discovery.md new file mode 100644 index 000000000..328bd2587 --- /dev/null +++ b/proposals/0000-remove-srv-discovery.md @@ -0,0 +1,84 @@ +# MSC0000: Removing SRV records from homeserver discovery + +Currently when [resolving server names](https://spec.matrix.org/v1.4/server-server-api/#resolving-server-names), +homeservers (or any implementation trying to locate a server, such as integration managers or widgets +using [OpenID Connect validation](https://spec.matrix.org/v1.4/server-server-api/#openid)) must support +an ability to resolve SRV DNS records. Aside from this being difficult in the case of widgets (for example), +SRV records typically cause deployment issues due to them not working "as expected" by server administrators. + +In addition to SRV records not "properly" supporting CNAMEs, TLS certificates are difficult to configure +correctly and often lead to issues with the wrong certificate being presented. These sorts of issues +come up often enough that [Synapse's documentation](https://matrix-org.github.io/synapse/v1.70/delegate.html#srv-dns-record-delegation) +doesn't even explain how to use SRV records, instead referencing the specification itself and citing that +.well-known is often what administrators are looking for. The documentation additionally calls it +"SRV delegation", further indicating that the use of SRV records is complex (it's not true delegation, +unlike what is possible with .well-known). + +This proposal removes all reference of SRV records from the homeserver discovery specification, and +a plan to handle the rollout of such an invasive change. + +## Proposal + +In short, the [current rules](https://spec.matrix.org/v1.4/server-server-api/#resolving-server-names) +which reference SRV records are deleted. This leads to the following discovery mechanism: + +*Note*: Some details, such as caching and certificate presentation, are excluded. They are unchanged. + +1. If the hostname is an IP literal, then that IP address should be used. If a port number is given then + it should be used, otherwise using port 8448. The `Host` header in the request is set to the server name + (which is the IP address), with port number if explicitly given. +2. If the hostname is *not* an IP literal, but does have an explicit port, resolve the name using A or + AAAA records to an IP and use that with the explicit port. The `Host` header in the request is set to + the server name, with port number. +3. If the hostname is *not* an IP literal, a regular HTTPS request is made to the .well-known endpoint + on that domain. The hostname presented by this endpoint is called the "delegated hostname" and repeats + discovery steps 1 & 2 above. It does not repeat step 3 (this step) as that could cause infinite loops + or needless delays in discovery. +4. Server discovery fails and the server is presumed offline or invalid if it has not been resolved to + a usable IP and port by this step. + +Clearly this would cause disruption in the larger ecosystem as some servers might still be using SRV +records to identify themselves. Readers of this proposal are encouraged to proactively change over to +.well-known to identify if there are legitimate reasons for keeping SRV records, even if this proposal +is still in a draft/unapproved state. + +In order to not cause massive breaking changes in the ecosystem, this proposal first deprecates SRV +discovery for a minimum of 1 calendar year from the time of the spec release itself. Afterwards, at the +discretion of the Spec Core Team (SCT), SRV discovery can be removed without notice. + +Homeserver authors (Synapse, Dendrite, Conduit, etc) are encouraged to use the deprecation period to +help their users transition to .well-known discovery, and if reading this proposal before it is accepted +then to help identify any legitimate reason to keep SRV discovery in the specification (for example, a +user of theirs is completely unable to switch to .well-known - the case would be discussed to determine +if it's a reasonable blocker for this proposal). + +The Matrix.org Foundation would also be engaged in helping users move over to .well-known through the +normal channels (blog posts, changelog on Synapse, social media, etc). + +## Potential issues + +As identified, this change could impact legitimate usage of SRV records for discovery - this proposal +exists to give readers, homeserver authors, etc time to identify these cases before the proposal is put +up for final comment period (thus proposing it for acceptance). If legitimate cases of SRV records are +found, this proposal may be declined or rejected (per normal process). + +## Alternatives + +This may be a good time to design new discovery mechanisms, however that would have an even larger +impact on the ecosystem. Additionally, .well-known appears to be the (current) industry standard +for this mechanism. + +## Security considerations + +Removing SRV discovery could mean a higher rate of homeservers being delegated to third party providers +or being targets of takeover attempts, however given Synapse (the most populous homeserver implementation) +already strongly recommends .well-known over SRV, this issue is considered trivial in nature. + +## Unstable prefix + +No unstable prefix is possible for this proposal. Instead, a migration period is explicitly proposed +as an alternative. + +## Dependencies + +None relevant. From 38a6ae2ffaa6003441fec0794d2ebcf0729840d2 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 1 Nov 2022 10:05:04 +0000 Subject: [PATCH 2/3] Assign number --- ...{0000-remove-srv-discovery.md => 3922-remove-srv-discovery.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{0000-remove-srv-discovery.md => 3922-remove-srv-discovery.md} (100%) diff --git a/proposals/0000-remove-srv-discovery.md b/proposals/3922-remove-srv-discovery.md similarity index 100% rename from proposals/0000-remove-srv-discovery.md rename to proposals/3922-remove-srv-discovery.md From f7b3d2525006f38698f644645bc79dd845404c21 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Tue, 1 Nov 2022 10:46:33 +0000 Subject: [PATCH 3/3] Update proposals/3922-remove-srv-discovery.md Co-authored-by: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> --- proposals/3922-remove-srv-discovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3922-remove-srv-discovery.md b/proposals/3922-remove-srv-discovery.md index 328bd2587..c2b87ea0c 100644 --- a/proposals/3922-remove-srv-discovery.md +++ b/proposals/3922-remove-srv-discovery.md @@ -1,4 +1,4 @@ -# MSC0000: Removing SRV records from homeserver discovery +# MSC3922: Removing SRV records from homeserver discovery Currently when [resolving server names](https://spec.matrix.org/v1.4/server-server-api/#resolving-server-names), homeservers (or any implementation trying to locate a server, such as integration managers or widgets