Clarify usage of SRV record mechanics #15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem Description
The spec currently (v1.7) states that for the Server-Server API, the server discovery might work via a well-known URI or via SRV records. SRV records (as per RFC 2782) allow defining a priority & weight for automatic fallback & weighted selection of multiple servers (similar to MX records have).
However, the spec does not clarify, if those rules should apply. More important, the spec does not state, when a re-selection should be applied (when first connecting to the server; every day;
The well-known method was introduced after the SRV record specification was introduced, but it does not support fallback & weighted selection at all.
Certificate Validation
As of now, when using SRV record delegation, the target servers still need to serve the certificate for the Matrix hostname (e.g. example.com SRV-deleagates to matrix1.example.com & matrix2.example.com, then both need to have a valid cert for example.com). This makes SRV delegation a little bit harder to use, especially for delegation to 3rd parties. However, assuming strong mutual authentication in the Client-Server connection and enforcing E2EE, this restriction might be useless (see this summary).
Implementation Status
Discovery Implementations
Servers using SRV records
Possible Solutions
Discussions in Matrix Room