Skip to content

Commit

Permalink
clustering.md: SRV records in DNS SAN for TLS
Browse files Browse the repository at this point in the history
Using SRV discovery with TLS, the SRV record must be in the DNS SAN or clustering will fail.

This is a new requirement and may cause mysterious failures when upgrading from 3.1 to 3.2.  I was only able to fix this in our configuration after reading through etcd-io#8445; and now I understand the problem it's clear the docs have a hole here.
  • Loading branch information
zultron authored Jun 26, 2018
1 parent 8f6348a commit b51d4a3
Showing 1 changed file with 8 additions and 2 deletions.
10 changes: 8 additions & 2 deletions Documentation/op-guide/clustering.md
Original file line number Diff line number Diff line change
Expand Up @@ -342,8 +342,8 @@ etcdserver: discovery token ignored since a cluster has already been initialized
### DNS discovery

DNS [SRV records][rfc-srv] can be used as a discovery mechanism.
The `-discovery-srv` flag can be used to set the DNS domain name where the discovery SRV records can be found.
The following DNS SRV records are looked up in the listed order:
The `--discovery-srv` flag can be used to set the DNS domain name where the discovery SRV records can be found.
Setting `--discovery-srv example.com` causes DNS SRV records to be looked up in the listed order:

* _etcd-server-ssl._tcp.example.com
* _etcd-server._tcp.example.com
Expand All @@ -357,6 +357,12 @@ To help clients discover the etcd cluster, the following DNS SRV records are loo

If `_etcd-client-ssl._tcp.example.com` is found, clients will attempt to communicate with the etcd cluster over SSL/TLS.

If etcd is using TLS, the discovery SRV record (e.g. `example.com`) must be included in the SSL certificate DNS SAN along with the hostname, or clustering will fail with log messages like the following:

```
[...] rejected connection from "10.0.1.11:53162" (error "remote error: tls: bad certificate", ServerName "example.com")
```

If etcd is using TLS without a custom certificate authority, the discovery domain (e.g., example.com) must match the SRV record domain (e.g., infra1.example.com). This is to mitigate attacks that forge SRV records to point to a different domain; the domain would have a valid certificate under PKI but be controlled by an unknown third party.

The `-discovery-srv-name` flag additionally configures a suffix to the SRV name that is queried during discovery.
Expand Down

0 comments on commit b51d4a3

Please sign in to comment.