Merge pull request #9886 from zultron/patch-1

clustering.md:  SRV records in DNS SAN for TLS

Documentation/op-guide/clustering.md

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