Do not ask for _matrix._tcp SRV records anymore

With most people on Synapse v0.99+ and Synapse v1.0 now available,
we should no longer try to be backward compatible with Synapse 0.34,
because this just complicates the instructions for no good reason.

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

docs/configuring-dns.md

@@ -9,16 +9,12 @@ You do, however need to instruct the Matrix network that Matrix services for `<y
 over to `matrix.<your-domain>`.
 As we discuss in [Server Delegation](howto-server-delegation.md), there are 2 different ways to set up such delegation:
 
-- using a `https://<your-domain>/.well-known/matrix/server` file (on the base domain!)
-- using DNS SRV records
+- either by serving a `https://<your-domain>/.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.<your-domain>` |
 | CNAME | `dimension`             | -        | -      | -    | `matrix.<your-domain>` |
-| SRV   | `_matrix._tcp`          | 10       | 0      | 8448 | `matrix.<your-domain>` |
 | SRV   | `_matrix-identity._tcp` | 10       | 0      | 443  | `matrix.<your-domain>` |
 
-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.<your-domain>` 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.<your-domain>` 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.<your-domain>`).
-
-To use a Matrix user identifier like `@<username>:<your-domain>` while hosting services on `matrix.<your-domain>`, 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.<your-domain>` (replace `<your-domain>` 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:

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 (`<your-domain.com>`).
 
-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.
 

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: