Skip to content
Snippets Groups Projects
Unverified Commit 61b457e3 authored by Brendan Abolivier's avatar Brendan Abolivier
Browse files

Incorporate review

parent a0d2f9d0
No related branches found
No related tags found
No related merge requests found
# Delegation
For a more flexible configuration, you can have `server_name`
resources (eg: `@user:example.com`) served by a different host and
port (eg: `synapse.example.com:443`).
Without configuring delegation, homeservers will expect the server
responsible for resources using e.g. `example.com` as their `server_name`
(e.g. `@user:example.com`) to be served at `example.com:8448`.
Without configuring delegation, the matrix federation will
expect to find your server via `example.com:8448`. The following methods
allow you retain a `server_name` of `example.com` so that your user IDs, room
aliases, etc continue to look like `*:example.com`, whilst having your
federation traffic routed to a different server (e.g. `synapse.example.com`).
Delegation is a Matrix feature allowing a homeserver admin to retain a
`server_name` of `example.com` so that your user IDs, room aliases, etc
continue to look like `*:example.com`, whilst having your federation
traffic routed to a different server and/or port (e.g. `synapse.example.com:443`).
## .well-known delegation
......@@ -38,11 +37,8 @@ should return:
Note, specifying a port is optional. If no port is specified, then it defaults
to 8448.
Most installations will not need to configure .well-known. However, it can be
useful in cases where the admin is hosting on behalf of someone else and
therefore cannot gain access to the necessary certificate. With .well-known,
federation servers will check for a valid TLS certificate for the delegated
hostname (in our example: `synapse.example.com`).
With .well-known, federation servers will check for a valid TLS certificate
for the delegated hostname (in our example: `synapse.example.com`).
## SRV DNS record delegation
......
......@@ -17,13 +17,13 @@ on port 8448. The preferred way to do that is by using a reverse proxy,
see [reverse_proxy.md](<reverse_proxy.md>) for instructions on how to
correctly set one up.
In some cases you might not want Synapse to be running on the machine that
has the `server_name` as its public DNS hostname, or federation traffic
to use port than 8448 (e.g. you want to use `example.com` as your `server_name`
but want Synapse to be reachable on `synapse.example.com:443`). This can
be done using delegation, which allows an admin to dictate where federation
traffic should be sent, see [delegate.md](<delegate.md>) for instructions on
how to set this up.
In some cases you might not want to run Synapse on the machine that has
the `server_name` as its public DNS hostname, or you might want federation
traffic to use a different port than 8448. For example, you might want to
have your user names look like `@user:example.com`, but you want to run
Synapse on `synapse.example.com` on port 443. This can be done using
delegation, which allows an admin to control where federation traffic should
be sent. See [delegate.md](delegate.md) for instructions on how to set this up.
Once federation has been configured, you should be able to join a room over
federation. A good place to start is `#synapse:matrix.org` - a room for
......@@ -31,7 +31,7 @@ Synapse admins.
## Troubleshooting
You can use the [federation tester](<https://matrix.org/federationtester>)
You can use the [federation tester](https://matrix.org/federationtester)
to check if your homeserver is configured correctly. Alternatively try the
[JSON API used by the federation tester](https://matrix.org/federationtester/api/report?server_name=DOMAIN).
Note that you'll have to modify this URL to replace `DOMAIN` with your
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment