Even an industrial tooling company in Estonia managed to find the secret DNSSEC-signed Google MX hosts. Official support and TLSA RRs would sure be nice:
venten․ee․ MX 10 mx1․smtp․goog․
@ MX 20 mx2․smtp․goog․
@ MX 30 mx3․smtp․goog․
@ MX 40 mx4․smtp․goog․
Conversation
Glad people are enthusiastic about this. IIUC the issue has always been resilience— when you have O(10^4) servers, keeping certs in sync is hard enough without the risk of hard failing closed.
4
1
Thing is, that in this case a "2 1 1" record that specifies the current Google issuer CA does not require "keeping certs in sync".
This is true even when the CA rolls over, since *multiple* TLSA RRs can cover the current and next CA during the rollover.
The certs roll normally.
2
2
Can also have multiple records even before rolling over if flexibility is desired. Also, considering that Google uses a 5 minute TTL for the google.com A/AAAA records, it's not like this needs to have a long TTL. Can use 1 minute so it's quick to detect/fix mistakes.
Google pins CAs for their web servers in Chromium and that has drastically higher latency for updates than 1 minute TTL DNS records. Even the CAs for updates are pinned, so unlike with this, it'd actually be quite fatal to completely screw that up. The risk for this is very low.
1