diff --git a/CHANGELOG.md b/CHANGELOG.md index 16b2d25f..ed443aa8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,16 @@ +# 2019-06-12 + +## Synapse v1.0 + +With [Synapse v1.0 now available](https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation) and most people being on at least Synapse v0.99, it's time to remove the `_matrix._tcp` DNS SRV record that we've been keeping for compatibility with old Synapse versions (<= 0.34). + +According to the [Server Discovery specification](https://matrix.org/docs/spec/server_server/r0.1.2.html#server-discovery), it's no harm to keep the DNS SRV record. But since it's not necessary for federating with the larger Matrix network anymore, you should be safe to get rid of it. + +**Note**: don't confuse the `_matrix._tcp` and `_matrix-identity._tcp` DNS SRV records. The latter, **must not** be removed. + +Besides this optional/non-urgent DNS change, assuming you're already on Synapse v0.99, upgrading to Synapse v1.0 should be as simple as [re-running the playbook](docs/maintenance-upgrading-services.md). + + # 2019-06-07 ## (BC Break) Facebook bridge configuration is now entirely managed by the playbook diff --git a/docs/configuring-dns.md b/docs/configuring-dns.md index 7638033b..678c1679 100644 --- a/docs/configuring-dns.md +++ b/docs/configuring-dns.md @@ -9,16 +9,12 @@ You do, however need to instruct the Matrix network that Matrix services for ``. As we discuss in [Server Delegation](howto-server-delegation.md), there are 2 different ways to set up such delegation: -- using a `https:///.well-known/matrix/server` file (on the base domain!) -- using DNS SRV records +- either by serving a `https:///.well-known/matrix/server` file (from the base domain!) +- or by using a `_matrix._tcp` DNS SRV record (don't confuse this with the `_matrix-identity._tcp` SRV record described below) This playbook mostly discusses the well-known file method, because it's easier to manage with regard to certificates. If you decide to go with the alternative method ([Server Delegation via a DNS SRV record (advanced)](howto-server-delegation.md#server-delegation-via-a-dns-srv-record-advanced)), please be aware that the general flow that this playbook guides you through may not match what you need to do. -To make matters worse, for backward compatibility until the Synapse server reaches v1.0, you need to set up a DNS SRV record anyway. -So don't be confused if the general flow of this playbook asks you for both DNS SRV records and for setting up a well-known file. -It's a temporary requirement during the Synapse v0.99/v1.0 transition. - ## General outline of DNS settings you need to do @@ -27,12 +23,8 @@ It's a temporary requirement during the Synapse v0.99/v1.0 transition. | A | `matrix` | - | - | - | `matrix-server-IP` | | CNAME | `riot` | - | - | - | `matrix.` | | CNAME | `dimension` | - | - | - | `matrix.` | -| SRV | `_matrix._tcp` | 10 | 0 | 8448 | `matrix.` | | SRV | `_matrix-identity._tcp` | 10 | 0 | 443 | `matrix.` | -The `_matrix._tcp` SRV record is a temporary measure and will not be necessary in the near future. -In fact, it will have to be removed at some point. To learn more about that, read below. - ## Subdomains setup @@ -44,23 +36,6 @@ If you'd rather instruct the playbook not to install Riot (`matrix_riot_web_enab The `dimension.` subdomain may be necessary, because this playbook could install the [Dimension integrations manager](http://dimension.t2bot.io/) for you. Dimension installation is disabled by default, because it's only possible to install it after the other Matrix services are working (see [Setting up Dimension](configuring-playbook-dimension.md) later). If you do not wish to set up Dimension, feel free to skip the `dimension.` DNS record. -## `_matrix._tcp` SRV record setup (temporary requirement) - -All services created by this playbook are meant to be installed on their own server (such as `matrix.`). - -To use a Matrix user identifier like `@:` while hosting services on `matrix.`, we need to instruct the Matrix network of such a delegation/redirection by means of setting up a DNS SRV record. - -The SRV record should look like this: -- Name: `_matrix._tcp` (use this text as-is) -- Content: `10 0 8448 matrix.` (replace `` with your own) - -A [new file-based mechanism for Federation Server Discovery](configuring-well-known.md#introduction-to-federation-server-discovery) is superseding the `_matrix._tcp` SRV record for our use case. **During the transition phase, you'll need to set up both mechanisms**. We'll instruct you how to set up the file-based mechanism after the [installation phase](installing.md) for this playbook. - -Doing delegation/redirection of Matrix services using a DNS SRV record (`_matrix._tcp`) is a **temporary measure** for our use-case, that will only be necessary before Synapse v1.0 is released. - -As more and more people upgrade to the Synapse v0.99 transitional release and just before the final Synapse v1.0 gets released, at some point in the near future **you will need to remove the `_matrix._tcp` SRV record** and leave only the [new file-based mechanism for Federation Server Discovery](configuring-well-known.md#introduction-to-federation-server-discovery) in place. - - ## `_matrix-identity._tcp` SRV record setup To make the [mxisd](https://github.com/kamax-io/mxisd) Identity Server (which this playbook installs for you) be authoritative for your domain name, set up one more SRV record that looks like this: diff --git a/docs/configuring-well-known.md b/docs/configuring-well-known.md index 50344c05..a8e81c73 100644 --- a/docs/configuring-well-known.md +++ b/docs/configuring-well-known.md @@ -17,13 +17,8 @@ As [per the Server-Server specification](https://matrix.org/docs/spec/server_ser Server delegation can be configured using DNS SRV records or by setting up a `/.well-known/matrix/server` file on the base domain (``). -We have discussed the DNS SRV record method already in the "`_matrix._tcp` SRV record setup (temporary requirement)" section of [Configuring DNS](configuring-dns.md). - -Both methods have their place and will continue to do so. Usually, you would need to use just one of these delegation methods. +Both methods have their place and will continue to do so. You only need to use just one of these delegation methods. For simplicity reasons, our setup advocates for the `/.well-known/matrix/server` method and guides you into using that. -For backward compatibility with older Synapse servers (< v0.99), however, for now you are also required to set up a `_matrix._tcp` DNS SRV record (in addition to the `/.well-known/matrix/server` file on the base domain). - -As the Synapse server progresses towards v1.0, only the `/.well-known/matrix/server` file will be used by us, unless you have a more special setup necessitating a DNS SRV record. At that future moment, you would need to remove the `_matrix._tcp` SRV record because Synapse v1.0+ will do the wrong thing if a SRV record exists. To learn how to set up `/.well-known/matrix/server`, read the Installing section below. diff --git a/roles/matrix-base/tasks/self_check_dns.yml b/roles/matrix-base/tasks/self_check_dns.yml index ceab00da..d17b2149 100644 --- a/roles/matrix-base/tasks/self_check_dns.yml +++ b/roles/matrix-base/tasks/self_check_dns.yml @@ -1,12 +1,7 @@ --- -- name: Determine DNS SRV records to check (Matrix) - set_fact: - dns_srv_record_checks: - - service_and_protocol: "_matrix._tcp" - domain: "{{ (matrix_domain + '.') }}" - expected_target: "{{ (matrix_server_fqn_matrix + '.') }}" - expected_port: 8448 +- set_fact: + dns_srv_record_checks: [] - block: - set_fact: