Skip to content

Commit 0268204

Browse files
turt2liveuhoreg
andauthored
MSC4040: Update SRV service name to IANA registration (#4040)
* Update SRV service name to IANA registation * rrrrrrrrrr * Clarify step 3 changes Co-authored-by: Hubert Chathi <[email protected]> * Fix security considerations * Update SRV steps per matrix-org/matrix-spec#1615 --------- Co-authored-by: Hubert Chathi <[email protected]>
1 parent 6a3ab1d commit 0268204

File tree

1 file changed

+119
-0
lines changed

1 file changed

+119
-0
lines changed
Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# MSC4040: Update SRV service name to IANA registration
2+
3+
The Internet Assigned Numbers Authority (IANA) holds a registry of all service names and ports in use
4+
by Internet applications. Unfortunately, the service name `matrix` was registered an eternity ago for
5+
use in an unrelated project, which makes our usage of it improper at best. On August 4, 2023 our
6+
registration of port 8448 was accepted, with an included service name of `matrix-fed`. This MSC
7+
proposes a backwards-compatible change to use this newly registered service name.
8+
9+
The registrations with keyword "matrix" can be found [here](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=matrix).
10+
11+
This fixes https://github.com/matrix-org/matrix-spec/issues/400
12+
13+
See also https://github.com/matrix-org/matrix-spec/issues/1576
14+
15+
## Proposal
16+
17+
The [current specification](https://spec.matrix.org/v1.7/server-server-api/#resolving-server-names) for
18+
resolving server names requires an implementation to look up `_matrix._tcp` SRV records in some steps.
19+
Those steps become *deprecated* and new steps which use `_matrix-fed._tcp` are added immediately before
20+
each existing step.
21+
22+
Deprecation in context of this MSC is to discourage continued use, and to queue the affected steps for eventual
23+
removal from the specification under the [deprecation policy](https://spec.matrix.org/v1.7/#deprecation-policy).
24+
25+
The new steps thus become:
26+
27+
1. (unchanged) If the hostname is an IP literal, then that IP address should be used, together with the
28+
given port number, or 8448 if no port is given. The target server must present a valid certificate for
29+
the IP address. The `Host` header in the request should be set to the server name, including the port if
30+
the server name included one.
31+
32+
2. (unchanged) If the hostname is not an IP literal, and the server name includes an explicit port, resolve
33+
the hostname to an IP address using CNAME, AAAA or A records. Requests are made to the resolved IP address
34+
and given port with a `Host` header of the original server name (with port). The target server must present
35+
a valid certificate for the hostname.
36+
37+
3. (steps added/deprecated) If the hostname is not an IP literal, a regular HTTPS request is made to `https://<hostname>/.well-known/matrix/server`,
38+
expecting the schema defined later in this section. 30x redirects should be followed, however redirection
39+
loops should be avoided. Responses (successful or otherwise) to the `/.well-known` endpoint should be
40+
cached by the requesting server. Servers should respect the cache control headers present on the response,
41+
or use a sensible default when headers are not present. The recommended sensible default is 24 hours. Servers
42+
should additionally impose a maximum cache time for responses: 48 hours is recommended. Errors are recommended
43+
to be cached for up to an hour, and servers are encouraged to exponentially back off for repeated failures.
44+
The schema of the `/.well-known` request is later in this section. If the response is invalid (bad JSON,
45+
missing properties, non-200 response, etc), skip to step 4. If the response is valid, the `m.server`
46+
property is parsed as `<delegated_hostname>[:<delegated_port>]` and processed as follows:
47+
48+
1. (unchanged) If `<delegated_hostname>` is an IP literal, then that IP address should be used together
49+
with the `<delegated_port>` or 8448 if no port is provided. The target server must present a valid TLS
50+
certificate for the IP address. Requests must be made with a `Host` header containing the IP address,
51+
including the port if one was provided.
52+
53+
2. (unchanged) If `<delegated_hostname>` is not an IP literal, and `<delegated_port>` is present, an IP
54+
address is discovered by looking up CNAME, AAAA or A records for `<delegated_hostname>`. The resulting IP
55+
address is used, alongside the `<delegated_port>`. Requests must be made with a `Host` header of
56+
`<delegated_hostname>:<delegated_port>`. The target server must present a valid certificate for `<delegated_hostname>`.
57+
58+
3. **(ADDED)** If `<delegated_hostname>` is not an IP literal and no `<delegated_port>` is present, an
59+
SRV record is looked up for `_matrix-fed._tcp.<delegated_hostname>`. This may result in another hostname
60+
(to be resolved using AAAA or A records) and port. Requests should be made to the resolved IP address and
61+
port with a `Host` header containing the `<delegated_hostname>`. The target server must present a valid
62+
certificate for `<delegated_hostname>`.
63+
64+
4. **(DEPRECATED)** If `<delegated_hostname>` is not an IP literal and no `<delegated_port>` is present, an
65+
SRV record is looked up for `_matrix._tcp.<delegated_hostname>`. This may result in another hostname (to
66+
be resolved using AAAA or A records) and port. Requests should be made to the resolved IP address and port
67+
with a `Host` header containing the `<delegated_hostname>`. The target server must present a valid certificate
68+
for `<delegated_hostname>`.
69+
70+
5. (unchanged) If no SRV record is found, an IP address is resolved using CNAME, AAAA or A records. Requests
71+
are then made to the resolve IP address and a port of 8448, using a `Host` header of `<delegated_hostname>`.
72+
The target server must present a valid certificate for `<delegated_hostname>`.
73+
74+
4. **(ADDED)** If the `/.well-known` request resulted in an error response, a server is found by resolving
75+
an SRV record for `_matrix-fed._tcp.<hostname>`. This may result in a hostname (to be resolved using AAAA or A
76+
records) and port. Requests are made to the resolved IP address and port, with a `Host` header of `<hostname>`.
77+
The target server must present a valid certificate for `<hostname>`.
78+
79+
5. **(DEPRECATED)** If the `/.well-known` request resulted in an error response, a server is found by resolving
80+
an SRV record for `_matrix._tcp.<hostname>`. This may result in a hostname (to be resolved using AAAA or A
81+
records) and port. Requests are made to the resolved IP address and port, with a `Host` header of `<hostname>`.
82+
The target server must present a valid certificate for `<hostname>`.
83+
84+
6. (unchanged) If the `/.well-known` request returned an error response, and the SRV record was not found, an IP
85+
address is resolved using CNAME, AAAA and A records. Requests are made to the resolved IP address using port
86+
8448 and a `Host` header containing the `<hostname>`. The target server must present a valid certificate for
87+
`<hostname>`.
88+
89+
## Potential issues
90+
91+
Us using `matrix` as a service name has been an issue all along. This MSC aligns the specification with our
92+
formal IANA registration.
93+
94+
## Alternatives
95+
96+
We could modify our IANA registration further to pick a different name, however the service name needs to be
97+
descriptive and short. The author notes that `matrix-server` was attempted in registration, which was declined
98+
during Expert Review of the application.
99+
100+
`matrix` cannot be taken over via IANA process. It was assigned before dates were put on records in 2000.
101+
102+
Non-options for names include `mxfed`, `matrixf`, and similar.
103+
104+
A potential way forward is to remove SRV resolution entirely, however prior effort via
105+
[MSC3922](https://github.com/matrix-org/matrix-spec-proposals/pull/3922) are expected to be *rejected* instead
106+
(as of writing, August 4th, 2023).
107+
108+
## Security considerations
109+
110+
There is increased DNS load with this change, due to having to potentially look up 6+ records in the worst case
111+
scenario. DNS servers should be more than capable of caching, and handling such a spike of requests.
112+
113+
## Unstable prefix
114+
115+
None applicable.
116+
117+
## Dependencies
118+
119+
None applicable.

0 commit comments

Comments
 (0)