From b51d4a3d06427a5b4b03112165a99d477d3dffc7 Mon Sep 17 00:00:00 2001 From: John Morris Date: Tue, 26 Jun 2018 11:51:58 -0500 Subject: [PATCH] clustering.md: SRV records in DNS SAN for TLS 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. --- Documentation/op-guide/clustering.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/op-guide/clustering.md b/Documentation/op-guide/clustering.md index a4eff26aa..feb8cacb6 100644 --- a/Documentation/op-guide/clustering.md +++ b/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.