tileradotorg/synapse
1
0
Fork 0
forked from MirrorHub/synapse
Code Pull requests Activity

Reword sections of federate.md that explained delegation at time of Synapse 1.0 transition (#6601)

Browse source 
* Remove sections of federate.md explaining delegation at time of Synapse 1.0 transition

Signed-off-by: Aaron Raimist <aaron@raim.ist>

* Add changelog

Signed-off-by: Aaron Raimist <aaron@raim.ist>
This commit is contained in:
Aaron Raimist 2020-01-02 04:28:20 -06:00 committed by Richard van der Hoff
parent dc96943d51
commit 32779b59fa
2 changed files with 4 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelog.d/6601.doc Normal file
View file

@ -0,0 +1 @@
Reword sections of federate.md that explained delegation at time of Synapse 1.0 transition.

24
docs/federate.md
View file

@ -66,10 +66,6 @@ therefore cannot gain access to the necessary certificate. With .well-known,
federation servers will check for a valid TLS certificate for the delegated federation servers will check for a valid TLS certificate for the delegated
hostname (in our example: ``synapse.example.com``). hostname (in our example: ``synapse.example.com``).
.well-known support first appeared in Synapse v0.99.0. To federate with older
servers you may need to additionally configure SRV delegation. Alternatively,
encourage the server admin in question to upgrade :).
### DNS SRV delegation ### DNS SRV delegation
To use this delegation method, you need to have write access to your To use this delegation method, you need to have write access to your
@ -111,29 +107,15 @@ giving it a `server_name` of `example.com`, and once [ACME](acme.md) support is
it would automatically generate a valid TLS certificate for you via Let's Encrypt it would automatically generate a valid TLS certificate for you via Let's Encrypt
and no SRV record or .well-known URI would be needed. and no SRV record or .well-known URI would be needed.
This is the common case, although you can add an SRV record or
`.well-known/matrix/server` URI for completeness if you wish.
**However**, if your server does not listen on port 8448, or if your `server_name` **However**, if your server does not listen on port 8448, or if your `server_name`
does not point to the host that your homeserver runs on, you will need to let does not point to the host that your homeserver runs on, you will need to let
other servers know how to find it. The way to do this is via .well-known or an other servers know how to find it. The way to do this is via .well-known or an
SRV record. SRV record.
#### I have created a .well-known URI. Do I still need an SRV record? #### I have created a .well-known URI. Do I also need an SRV record?
As of Synapse 0.99, Synapse will first check for the existence of a .well-known No. You can use either `.well-known` delegation or use an SRV record for delegation. You
URI and follow any delegation it suggests. It will only then check for the do not need to use both to delegate to the same location.
existence of an SRV record.
That means that the SRV record will often be redundant. However, you should
remember that there may still be older versions of Synapse in the federation
which do not understand .well-known URIs, so if you removed your SRV record
you would no longer be able to federate with them.
It is therefore best to leave the SRV record in place for now. Synapse 0.34 and
earlier will follow the SRV record (and not care about the invalid
certificate). Synapse 0.99 and later will follow the .well-known URI, with the
correct certificate chain.
#### Can I manage my own certificates rather than having Synapse renew certificates itself? #### Can I manage my own certificates rather than having Synapse renew certificates itself?