On Mon, Nov 09, 2015 at 04:32:09PM +0000, Viktor Dukhovni wrote:
> If you want a more comprehensive list of domains with DNS problems,
> ... I just happen to have one. :-)
To put that list of ~230 broken domains in context, I've surveyed
over 5 million domains, and found ~100 thousand domains that are
DNSSEC signed with at least one primary MX host also DNSSEC signed.
This survey has identified over 9400 domains where at least one
primary MX host has working TLSA records, of which over 9200 have
TLSA records for all their MX hosts.
There are also at present 15 domains with TLSA records that don't
match the server certificate, or where the host does not actually
have working STARTTLS. Finally, 10 domains have unsupported TLSA
records with certificate usage PKIX-EE(1).
So on the whole, that 230 number is not particularly large. If we
exclude the bunch of domains that share the mail.mil MX host, and
limit ourselves to domains that send enough mail to have appeared
in the Gmail transparency support some time in the last couple of
years, we end up with just:
gencat.cat
uspto.gov
linuxcontainers.org
patriotguard.org
sourceware.org
and the only one of these with persistent DNS problems is
"patriotguard.org", the remaining DNS issues are intermittent to
minor (do not actually stop unbound, for example, from resolving
all the relevant records).
So among domains to which the vast majority of users are likely to
ever send email, there problems are concentrated on just two MX
host clusters, one serving mail.mil et. al, and another for
patriotguard.
On the positive side, domains with working DANE that have appeared
in Google's transparency report now number 29. This is still a
small number, but it is growing, most notably with comcast.net,
added last week.
So, bottom line, most users can enable DANE verification and not
run into delivery issues. Once a few large providers start enforcing
DANE checks, any domains with DNS or TLSA record content problems
will have a strong incentive to fix the problem on the receiving
end.
I would also like to encourage more of the administrators on this
list to publish TLSA records, but keep in mind that this is an
operational commitment, not a fashion statement. Once you publish
TLSA records you MUST keep them accurate while performing future
key/certificate updates (or changing issuing CAs if you're using
DANE-TA(2) TLSA records).
See,
https://dane.sys4.de/common_mistakes#3
https://dane.sys4.de/common_mistakes#6
https://tools.ietf.org/html/rfc7671#section-5.1
https://tools.ietf.org/html/rfc7671#section-5.2
https://tools.ietf.org/html/rfc7671#section-8.1
https://tools.ietf.org/html/rfc7671#section-8.4
Understand how long it takes your domain's secondary nameservers
to pick up changes in the master zone. Document your particular
key/certificate rollover process in a manner that will ensure it
is followed when you're ready to replace your server's private key
and/or certificate chain.
If you can do that, please go ahead and publish TLSA records for
the MX hosts of your DNSSEC signed domains. If that's too complex
at this time, wait. The documentation and tools will improve, and
it is better to not publish at all than to publish broken records
that create problems for both senders (other domains) and receivers
(you).
--
Viktor.
