Mirroristas/etcd
2
0
Fork 0
mirror of https://github.com/etcd-io/etcd.git synced 2024-09-27 06:25:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

clustering.md: SRV records in DNS SAN for TLS

Browse Source 
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 #8445; and now I understand the problem it's clear the docs have a hole here.
This commit is contained in:
John Morris 2018-06-26 11:51:58 -05:00 committed by GitHub
parent 8f6348a97d
commit b51d4a3d06
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/op-guide/clustering.md
View File

@ -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
@ -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.