The wonderful 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#). It would be wonderful if that functionality could be added in a future update to their site. Does NLnet Labs, 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 please add Verisign Public DNS (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/? 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.