The wonderful Internet.nl http://internet.nl/ website and e-mail security and standards compliance checker, which was the first thing I thought of when I saw this message from Viktor, doesn’t currently check for TLSA records for MX hosts (although it does check for DNSSEC on the zones of MX hostnames, e.g. https://internet.nl/mail/dns-example.info/results# https://internet.nl/mail/dns-example.info/results#). It would be wonderful if that functionality could be added in a future update to their site. Does NLnet Labs https://internet.nl/partners/#NLnetLabs, which develops the software for this great checking tool, have a public repository for it? If so, I would be happy to submit a pull-request or patch to add that functionality.
@alex
p.s. could someone at Internet.nl http://internet.nl/ please add Verisign Public DNS (https://www.verisign.com/en_US/security-services/public-dns/index.xhtml https://www.verisign.com/en_US/security-services/public-dns/index.xhtml) to the list of DNSSEC-validating public DNS services at https://internet.nl/faqs/dnssec/? https://internet.nl/faqs/dnssec/? They are the first major public DNS service after Google Public DNS to provide this feature, present from day one of their service (even though they don’t mention it), and they should be listed.
On 2017-02-10, at 15:25, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
Some domains with DANE-TLSA records for their primary MX hosts neglect to publish DANE TLSA for secondary and/or "black-hole" (spam magnet) MX hosts.
Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA records (and SMTP connections to that host would time out). This gives an active on-path MiTM attacker opportunity to block connections to the working MX hosts, and accept unauthenticated connections to the black-hole MX host. After they were notified of the problem, they made changes, and now we see TLSA records associated with all the MX hosts, including "bh.nic.cz":
nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1 nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1 ; mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1 mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1 _25._tcp.mail.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1 ; mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1 mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; NOERROR AD=1 _25._tcp.mx.nic.cz. IN TLSA 3 1 1 aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; NOERROR AD=1 ; bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1 bh.nic.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bh.nic.cz. IN TLSA 3 1 1 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; NOERROR AD=1
I've not yet nagged "iis.se" or "wia.cz", and there we see that only one of the two MX hosts has a TLSA record:
iis.se. IN MX 5 mx1.iis.se. ; NOERROR AD=1 iis.se. IN MX 5 mx2.iis.se. ; NOERROR AD=1 ; mx1.iis.se. IN A 91.226.36.35 ; NOERROR AD=1 mx1.iis.se. IN AAAA 2a00:801:f0:106::35 ; NOERROR AD=1 _25._tcp.mx1.iis.se. IN TLSA 3 1 1 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; NOERROR AD=1 ; mx2.iis.se. IN A 91.226.37.39 ; NOERROR AD=1 mx2.iis.se. IN AAAA 2001:67c:124c:2007::39 ; NOERROR AD=1 _25._tcp.mx2.iis.se. IN TLSA ? ; NXDOMAIN AD=1
wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1 wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1 ; antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1 antispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; NOERROR AD=1 ; bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1 bntispam.wia.cz. IN AAAA ? ; NODATA AD=1 _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1
While during initial deployment it is natural to proceed incrementally and add TLSA records to one MX host at a time, and test thoroughly before moving on to the rest, the end-state should be to publish TLSA records for all MX hosts, not a proper subset.
-- Viktor.