Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Clarify limitations of SRV delegation in documentation #14959

Merged
merged 5 commits into from
Feb 8, 2023
Merged

Clarify limitations of SRV delegation in documentation #14959

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e4d9fff
clarify the implications of using SRV DNS delegation and what it does
williamkray Jan 31, 2023
e7cf319
include changelog file
williamkray Jan 31, 2023
73714e5
include credit in changelog
williamkray Jan 31, 2023
70ea387
fix contrib attribution formatting to make CI happy
williamkray Feb 7, 2023
2742972
fix contrib attribution formatting to make CI happy... again
williamkray Feb 7, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/14959.doc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Update delegation documentation to clarify that SRV DNS delegation does not eliminate all needs to serve files from .well-known locations. Contributed by @williamkray.
9 changes: 9 additions & 0 deletions docs/delegate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,15 @@ It is also possible to do delegation using a SRV DNS record. However, that is ge
not recommended, as it can be difficult to configure the TLS certificates correctly in
this case, and it offers little advantage over `.well-known` delegation.

Please keep in mind that server delegation is a function of server-server communication,
and as such using SRV DNS records will not cover use cases involving client-server comms.
This means setting global client settings (such as a Jitsi endpoint, or disabling
creating new rooms as encrypted by default, etc) will still require that you serve a file
from the `https://<server_name>/.well-known/` endpoints defined in the spec! If you are
considering using SRV DNS delegation to avoid serving files from this endpoint, consider
the impact that you will not be able to change those client-based default values globally,
and will be relegated to the featureset of the configuration of each individual client.

However, if you really need it, you can find some documentation on what such a
record should look like and how Synapse will use it in [the Matrix
specification](https://matrix.org/docs/spec/server_server/latest#resolving-server-names).
Expand Down