Don't forget to add TLSA records for black-hole MX hosts

Ralph Dolmans ralph at nlnetlabs.nl
Fri Mar 3 11:15:48 CET 2017


Hi Alex,

Sorry for the late reply, I was just pointed to this message.

Please note that internet.nl already does check the existence and
validity of TLSA records for all MX hosts, as part of the STARTTLS test.
In your example case it displays "no TLSA record found (DANE) ".

Regards,
-- Ralph



On 13-02-17 14:40, Alexander Dupuy wrote:
> 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#). 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) 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 at dukhovni.org
>> <mailto:ietf-dane at 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 <http://iis.se>" or "wia.cz", and there we
>> see that
>> only one of the two MX hosts has a TLSA record:
>>
>>    iis.se <http://iis.se>. IN MX 5 mx1.iis.se <http://mx1.iis.se>. ;
>> NOERROR AD=1
>>    iis.se <http://iis.se>. IN MX 5 mx2.iis.se <http://mx2.iis.se>. ;
>> NOERROR AD=1
>>    ;
>>    mx1.iis.se <http://mx1.iis.se>. IN A 91.226.36.35 ; NOERROR AD=1
>>    mx1.iis.se <http://mx1.iis.se>. IN AAAA 2a00:801:f0:106::35 ;
>> NOERROR AD=1
>>    _25._tcp.mx1.iis.se <http://tcp.mx1.iis.se>. IN TLSA 3 1 1
>> 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ;
>> NOERROR AD=1
>>    ;
>>    mx2.iis.se <http://mx2.iis.se>. IN A 91.226.37.39 ; NOERROR AD=1
>>    mx2.iis.se <http://mx2.iis.se>. IN AAAA 2001:67c:124c:2007::39 ;
>> NOERROR AD=1
>>    _25._tcp.mx2.iis.se <http://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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://mail.sys4.de/pipermail/dane-users/attachments/20170303/78973db5/attachment.asc>


More information about the dane-users mailing list