From john at klam.ca  Sat Apr  1 20:23:00 2017
From: john at klam.ca (John Allen)
Date: Sat, 1 Apr 2017 14:23:00 -0400
Subject: certbot renew-hook for tlsa generation
Message-ID: <bf372eb4-e943-c52a-5f7e-ea7d013d2c69@klam.ca>

if anybody is interested I have created a automatic TLSA generator and
installer (bind only for the moment). you can find it here
https://github.com/zzz2002/Certbot-renew-hook

I still have to do the documentation. it can be run as a renew-hook for
letsencrypt (certbot) or standalone.

WARNING it still being worked on, but whats there seems to work. let me
know of any problems, suggestions


From john at klam.ca  Thu Apr 13 05:42:55 2017
From: john at klam.ca (John Allen)
Date: Wed, 12 Apr 2017 23:42:55 -0400
Subject: Lestencrypt "renew-hook"
Message-ID: <7c3aa9b5-44ad-8323-976a-8dd2a737b26c@klam.ca>

I have just put the latest version of the above up on github
https://github.com/zzz2002/Certbot_TLSAgen_Hook

Anybody with time on their hand,wold yo mind taking a look and letting
me know what wrong with it/ what doesn't work/what could be done better....

Happy Easter to those who celebrate it this weekend, to those who don't
have a good & safe weekend, enjoy yourselves.

JohnA


From john at klam.ca  Thu Apr 20 15:27:49 2017
From: john at klam.ca (John Allen)
Date: Thu, 20 Apr 2017 09:27:49 -0400
Subject: ?
Message-ID: <f3d05221-e2ea-df58-564c-d680105b52d5@klam.ca>

Is the following assumption reasonable?

if there are multiple TLSA dane-ee (type 3) records for a particular
service, none of which match the current generated record, they can
(maybe should) be deleted.

The same "rule" can be could be applied to dane type 2 records.



From john at klam.ca  Thu Apr 20 15:34:27 2017
From: john at klam.ca (John Allen)
Date: Thu, 20 Apr 2017 09:34:27 -0400
Subject: Assumption abot TLSA records
Message-ID: <7d7a5f63-6edf-60f4-bb3e-8e6268fbc82f@klam.ca>

Is the following assumption reasonable?

if there are multiple TLSA dane-ee (type 3) records for a particular
service, none of which match the current generated record, they can
(maybe should) be deleted.

The same "rule" can be could be applied to dane type 2 records.


From john at klam.ca  Thu Apr 20 15:36:34 2017
From: john at klam.ca (John Allen)
Date: Thu, 20 Apr 2017 09:36:34 -0400
Subject: Assumption about TLSA records
Message-ID: <0ea1bb7c-53d9-05c9-776b-4399baae6fca@klam.ca>

Is the following assumption reasonable?

if there are multiple TLSA dane-ee (type 3) records for a particular
service, none of which match the current generated record, they can
(maybe should) be deleted.

The same "rule" can be could be applied to dane type 2 records.


From john at klam.ca  Thu Apr 20 16:40:44 2017
From: john at klam.ca (John)
Date: Thu, 20 Apr 2017 10:40:44 -0400
Subject: Assumptions
Message-ID: <b37a52dc-10da-31c5-3825-fb628e8eeb81@klam.ca>

Are the following assumptions reasonable?

if there are multiple TLSA dane-ee (type 3) records for a particular 
service, none of which match the current generated record, they can 
(maybe should) be deleted.

The same "rule" can be could be applied to dane type 2 records.


From patrickdk at patrickdk.com  Thu Apr 20 16:50:33 2017
From: patrickdk at patrickdk.com (Patrick Domack)
Date: Thu, 20 Apr 2017 10:50:33 -0400
Subject: Assumptions
In-Reply-To: <b37a52dc-10da-31c5-3825-fb628e8eeb81@klam.ca>
Message-ID: <20170420105033.Horde.AFAgOM_SE1YCRpQ4hURpfRq@mail.patrickdk.com>

I don't see how that is valid at all. It can be used as a hint, but  
not a hard rule.

I publish 3 records, past certificate that is rotated out, current,  
and the next certificate I will roll in.
You should be publishing your standby/failover certificate, if you  
want to handle a compromised certificate case.



Quoting John <john at klam.ca>:

> Are the following assumptions reasonable?
>
> if there are multiple TLSA dane-ee (type 3) records for a particular  
> service, none of which match the current generated record, they can  
> (maybe should) be deleted.
>
> The same "rule" can be could be applied to dane type 2 records.




From ietf-dane at dukhovni.org  Thu Apr 20 16:52:19 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 20 Apr 2017 14:52:19 +0000
Subject: Assumption about TLSA records
In-Reply-To: <f3d05221-e2ea-df58-564c-d680105b52d5@klam.ca>
 <7d7a5f63-6edf-60f4-bb3e-8e6268fbc82f@klam.ca>
 <0ea1bb7c-53d9-05c9-776b-4399baae6fca@klam.ca>
Message-ID: <20170420145219.GJ25754@mournblade.imrryr.org>

On Thu, Apr 20, 2017 at 09:27:49AM -0400, John Allen wrote:
On Thu, Apr 20, 2017 at 09:34:27AM -0400, John Allen wrote:
On Thu, Apr 20, 2017 at 09:36:34AM -0400, John Allen wrote:

> Is the following assumption reasonable?
> 
> if there are multiple TLSA dane-ee (type 3) records for a particular
> service, none of which match the current generated record, they can
> (maybe should) be deleted.
> 
> The same "rule" can be could be applied to dane type 2 records.

At all times, TLSA *RRsets* whose TTL has not yet expired (vended
by either the primary or a secondary nameserver) need to contain
at least one RR which matches the *current* certificate chain of
the SMTP server.

To achieve this, the TLSA RRset stored in the master database
needs the both the *current* certificate chain and any *new*
certificate chain planned for deployment within the cache
lifetime of recently served DNS responses.

There is no logical or de jure requirement to serve TLSA records
that match *old* no longer deployed certificate chains.  As soon
as the certificate chain is replaced the old records should go.

In other words, the TLSA records reflect current and near-future
certificate chain state, they need not and should not retain past
state.

-- 
	Viktor.

P.S.  I deliberately said nothing about the certificate usage value,
      it should be clear why.

From john at klam.ca  Thu Apr 20 17:40:20 2017
From: john at klam.ca (John)
Date: Thu, 20 Apr 2017 11:40:20 -0400
Subject: Assumption about TLSA records
In-Reply-To: <20170420145219.GJ25754@mournblade.imrryr.org>
References: <20170420145219.GJ25754@mournblade.imrryr.org>
Message-ID: <15b8c0576a0.2787.14d9188d684ea7b6d1324cf92af46b48@klam.ca>

Thanks for speedy reply.
I am assuming that past threads on TLSA records still hold. Therefore 
3/1/1, with optional  2/1/1 depending upon root cert provenance.


On April 20, 2017 10:52:38 AM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> On Thu, Apr 20, 2017 at 09:27:49AM -0400, John Allen wrote:
> On Thu, Apr 20, 2017 at 09:34:27AM -0400, John Allen wrote:
> On Thu, Apr 20, 2017 at 09:36:34AM -0400, John Allen wrote:
>
>> Is the following assumption reasonable?
>>
>> if there are multiple TLSA dane-ee (type 3) records for a particular
>> service, none of which match the current generated record, they can
>> (maybe should) be deleted.
>>
>> The same "rule" can be could be applied to dane type 2 records.
>
> At all times, TLSA *RRsets* whose TTL has not yet expired (vended
> by either the primary or a secondary nameserver) need to contain
> at least one RR which matches the *current* certificate chain of
> the SMTP server.
>
> To achieve this, the TLSA RRset stored in the master database
> needs the both the *current* certificate chain and any *new*
> certificate chain planned for deployment within the cache
> lifetime of recently served DNS responses.
>
> There is no logical or de jure requirement to serve TLSA records
> that match *old* no longer deployed certificate chains.  As soon
> as the certificate chain is replaced the old records should go.
>
> In other words, the TLSA records reflect current and near-future
> certificate chain state, they need not and should not retain past
> state.
>
> --
> 	Viktor.
>
> P.S.  I deliberately said nothing about the certificate usage value,
>       it should be clear why.



From ietf-dane at dukhovni.org  Thu Apr 20 18:01:41 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 20 Apr 2017 12:01:41 -0400
Subject: Assumption about TLSA records
In-Reply-To: <15b8c0576a0.2787.14d9188d684ea7b6d1324cf92af46b48@klam.ca>
References: <20170420145219.GJ25754@mournblade.imrryr.org>
 <15b8c0576a0.2787.14d9188d684ea7b6d1324cf92af46b48@klam.ca>
Message-ID: <20170420160141.GA1018@straasha.imrryr.org>

On Thu, Apr 20, 2017 at 11:40:20AM -0400, John wrote:

> I am assuming that past threads on TLSA records still hold. Therefore 
> 3/1/1, with optional  2/1/1 depending upon root cert provenance.

The provenance of the root cert is irrelevant.  From a public CA
(let's face it "everyone" is using Let's Encrypt lately) you'd
typically use an intermediate CA as your DANE trust anchor.

For a private issuing CA it is more typical to see leaf certs issued
directly by a root CA, but still use whatever CA is the direct
issuer as the DANE trust-anchor.

I recommend using a private issuer CA for port 25.  It is much too
easy for backbone operators to mess with BGP routes, MiTM CA "domain
validation" challenges and walk away with a fraudulent certificate.
Perhaps some day "Certificate Transparency" will help detect the
fraud after-the-fact, but "DV" certificates don't provide much more
security value than the $0 you pay form them.

You can think of "Let's Encrypt" as opportunistic security for the
World-Wide Web.   The party doing the unauthenticated leap of faith
key pinning is the CA, and then everyone else piggy-backs on the
CA's success or failure (of course there are many CAs).

Now certainly not having a cert at all and doing HTTP in the clear
is less secure than using a "DV" certificate, and "DV" certificates
do protect against passive monitoring.  So the "DV" ecosystem is
doing some good.  But "DV" cannot protect against targetted active
attack, and "EV" does not scale.

So, for DANE, though use of "Let's Encrypt" with a combination of
"3 1 1" + "2 1 1" TLSA records is a good place to start, a private
CA is better.  We just need to make using a private CA much easier
than it currently is.  I'd like to enhance the "postfix tls" CLI
to support an issuing trust-anchor some time this year.

If you're wealthy enough to afford "EV" certs, you can of course
use an EV-only intermediate for your "2 1 1" (or perhaps in that
case "2 0 1") TLSA record.  One might hope that "EV" certificate
issuance is much more resistant to MiTM or other attempts to
obtain fraudulent certificates.

-- 
	Viktor.

From john at klam.ca  Wed Apr 26 18:29:35 2017
From: john at klam.ca (john)
Date: Wed, 26 Apr 2017 12:29:35 -0400
Subject: Letsencrypt renew-hook
Message-ID: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>

I have been working on a renew-hook for letsencrypt/certbot.

The idea was that it would generate new TLSA records when the 
certificates were updated, automatically install them and automatically 
remove the old ones after a suitable delay.

While I was putting it together I made some assumptions about the 
environment that TLSA records would be found in, in particular the DNS 
configuration. It seems I am probably wrong.

Is an automatic TLSA update system worth doing? Are the prerequisites 
that I think might make it work too onerous.  Eg. Linux servers, need 
SRV records in order to determine the port and host for each TLSA record.

John A


From patrickdk at patrickdk.com  Wed Apr 26 18:33:15 2017
From: patrickdk at patrickdk.com (Patrick Domack)
Date: Wed, 26 Apr 2017 12:33:15 -0400
Subject: Letsencrypt renew-hook
In-Reply-To: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
Message-ID: <20170426123315.Horde.ZjFT4C1mG9V7fG3d2hXa0OD@mail.patrickdk.com>

I'm not sure what you mean by linux servers need SRV records. SRV is  
not a linux thing, and linux doesn't need them.

It could be whatever application you are using needs SRV records though.

My use case is for https (really for my own personal use) and smtp,  
and my hook script to install and remove tlsa records works perfect,  
and no SRV records are used.


Quoting john <john at klam.ca>:

> I have been working on a renew-hook for letsencrypt/certbot.
>
> The idea was that it would generate new TLSA records when the  
> certificates were updated, automatically install them and  
> automatically remove the old ones after a suitable delay.
>
> While I was putting it together I made some assumptions about the  
> environment that TLSA records would be found in, in particular the  
> DNS configuration. It seems I am probably wrong.
>
> Is an automatic TLSA update system worth doing? Are the  
> prerequisites that I think might make it work too onerous.  Eg.  
> Linux servers, need SRV records in order to determine the port and  
> host for each TLSA record.
>
> John A




From ietf-dane at dukhovni.org  Wed Apr 26 19:01:37 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 26 Apr 2017 13:01:37 -0400
Subject: Letsencrypt renew-hook
In-Reply-To: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
References: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
Message-ID: <DA51E78F-DFA5-4572-B743-5796F3980191@dukhovni.org>


> On Apr 26, 2017, at 12:29 PM, john <john at klam.ca> wrote:
> 
> Is an automatic TLSA update system worth doing?

Portability across multiple deployment architectures may be difficult,
so a tool for the public is difficult.  It is certainly worth doing for
your own private deployment.

> Linux servers, need SRV records in order to determine the port and host for each TLSA record.

For SMTP the port is always 25, and the hostnames come from the MX records,
and you already need the hostnames for the certificate.

For XMPP, indeed the hostnames and ports may come from the appropriate SRV
records.  Once again, you'll need the hostnames to obtain the requisite
certificates, with our without TLSA records in the picture.

Of course the hostnames could be in a separate configuration file, and be
used to manage all of the underlying configurations:

	* Generate the SRV and MX records
	* Configure certbot
	* Automate TLSA record creation

all from a single primary source managed by the administrator.

-- 
	Viktor.


From john at klam.ca  Wed Apr 26 19:31:30 2017
From: john at klam.ca (john)
Date: Wed, 26 Apr 2017 13:31:30 -0400
Subject: Letsencrypt renew-hook
In-Reply-To: <DA51E78F-DFA5-4572-B743-5796F3980191@dukhovni.org>
References: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
 <DA51E78F-DFA5-4572-B743-5796F3980191@dukhovni.org>
Message-ID: <1c02edbf-a273-f468-67ff-6323f486948c@klam.ca>

The problem is not mail servers, they tend to be fairly conventional in 
their setup, certainly for smtp/25. It is all the other stuff.

I started this because as a SOHO/small business I want to automate 
everything I can. Partly because I am away from the office fairly often, 
secondly if I can automate things they don't get overlooked until 
someone or something (eg your DANE check) complains.

 From the your tone, Victor, you sound as though you may already know of 
a better solution.

JohnA



On 2017-04-26 1:01 PM, Viktor Dukhovni wrote:
>> On Apr 26, 2017, at 12:29 PM, john <john at klam.ca> wrote:
>>
>> Is an automatic TLSA update system worth doing?
> Portability across multiple deployment architectures may be difficult,
> so a tool for the public is difficult.  It is certainly worth doing for
> your own private deployment.
>
>> Linux servers, need SRV records in order to determine the port and host for each TLSA record.
> For SMTP the port is always 25, and the hostnames come from the MX records,
> and you already need the hostnames for the certificate.
>
> For XMPP, indeed the hostnames and ports may come from the appropriate SRV
> records.  Once again, you'll need the hostnames to obtain the requisite
> certificates, with our without TLSA records in the picture.
>
> Of course the hostnames could be in a separate configuration file, and be
> used to manage all of the underlying configurations:
>
> 	* Generate the SRV and MX records
> 	* Configure certbot
> 	* Automate TLSA record creation
>
> all from a single primary source managed by the administrator.
>


From ietf-dane at dukhovni.org  Wed Apr 26 19:36:11 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 26 Apr 2017 13:36:11 -0400
Subject: Letsencrypt renew-hook
In-Reply-To: <1c02edbf-a273-f468-67ff-6323f486948c@klam.ca>
References: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
 <DA51E78F-DFA5-4572-B743-5796F3980191@dukhovni.org>
 <1c02edbf-a273-f468-67ff-6323f486948c@klam.ca>
Message-ID: <0B7FDFCF-D97A-4F72-815D-85863C7ED559@dukhovni.org>


> On Apr 26, 2017, at 1:31 PM, john <john at klam.ca> wrote:
> 
> From your tone, Victor, you sound as though you may already know of a better solution.

An design principle is not a solution.  I don't have a concrete
alternative.  All I'm saying is that I'd gather the key data in
one place, manage it there, and drive multiple systems from a
common data store.

-- 
	Viktor.


From john at klam.ca  Wed Apr 26 22:21:15 2017
From: john at klam.ca (John)
Date: Wed, 26 Apr 2017 16:21:15 -0400
Subject: CLOSED Letsencrypt renew-hook
In-Reply-To: <0B7FDFCF-D97A-4F72-815D-85863C7ED559@dukhovni.org>
References: <24f3f256-936b-fb47-588f-7b630ee2b422@klam.ca>
 <DA51E78F-DFA5-4572-B743-5796F3980191@dukhovni.org>
 <1c02edbf-a273-f468-67ff-6323f486948c@klam.ca>
 <0B7FDFCF-D97A-4F72-815D-85863C7ED559@dukhovni.org>
Message-ID: <9da29ef1-e2ec-0f6a-54c7-0d739831556f@klam.ca>

''' /chuckle ''' /Which is what I thought I could use the DNS for. you 
live and learn

Thanks for the input.

JohnA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.sys4.de/pipermail/dane-users/attachments/20170426/a61a2ec6/attachment-0001.html>

From john at klam.ca  Sat Apr 29 17:53:00 2017
From: john at klam.ca (John)
Date: Sat, 29 Apr 2017 11:53:00 -0400
Subject: OT. renew-hook
Message-ID: <67a8c8a7-f6ec-06c5-9bab-f9ded439fa0a@klam.ca>

I have written a renew-hook for letsencrypt, and it does not need SRV 
records.

It seems to work but I have limited facility/ability to test.

If there is anybody out there interested would they try it, test it and 
let me know whats wrong with it.

Its a bash script, and should probably be rewritten in something a 
little more tamper proof. I am currently brushing up on my C++ and 
looking into Python, suggestions as to language welcome.

renew-hook <https://github.com/zzz2002/Certbot_TLSAgen_Hook>

JohnA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.sys4.de/pipermail/dane-users/attachments/20170429/830d5692/attachment.html>

From ietf-dane at dukhovni.org  Sun Apr 30 02:31:52 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 30 Apr 2017 00:31:52 +0000
Subject: Update on stats (axc.nl DNS issues resolved this month)
Message-ID: <20170430003152.GD22954@mournblade.imrryr.org>

As of today I count 168708 domains with correct DANE TLSA records
for SMTP.  As expected the bulk of the DANE domains are hosted the
handful of DNS/hosting providers who've enabled DANE support in
bulk for the domains they host.  The top 10 MX host providers by
domain count are:

   69372 domeneshop.no
   58498 transip.nl
   18224 udmedia.de
    6769 bhosted.nl
    1824 nederhost.net
     993 ec-elements.com
     494 core-networks.de
     365 networking4all.net
     337 bit.nl
     328 omc-mail.com

The real numbers are surely larger, because I don't have access to
the full zone data for most ccTLDs.  However, this month, I was
able to obtain nearly comprehensive domain lists for .no, .nl and
.de, which accounts for the unusually large increase over the previous
month's totals.

There are 2529 unique zones in which the underlying MX hosts are
found, this counts each of the above providers as just one zone,
so is a measure of the breadth of adoption in terms of servers
deployed.  Alternatively, a similar number is seen in the count
(2644) of distinct MX host server certificates that support the
same ~168000 domains.  

A related number is 3795 TLSA RRsets found for MX host TCP port 25.
This includes secondary MX hosts and domains none of whose primary
MX hosts have TLSA records.  

The number of domains that at some point were listed in Gmail's
email transparency report is 105 (this is my ad-hoc criterion for
a domain being a large-enough actively used email domain).  Of
these, 53 are in recent reports (April 2017):

  gmx.at              jpberlin.de         bhosted.nl
  nic.br              lrz.de              ouderportaal.nl
  registro.br         mail.de             overheid.nl
  gmx.ch              posteo.de           pathe.nl
  open.ch             ruhr-uni-bochum.de  xs4all.nl
  anubisnetworks.com  tum.de              domeneshop.no
  gmx.com             uni-erlangen.de     webcruitermail.no
  mail.com            unitymedia.de       debian.org
  solvinity.com       web.de              freebsd.org
  t-2.com             enron.email         gentoo.org
  trashmail.com       octopuce.fr         ietf.org
  xfinity.com         comcast.net         isc.org
  nic.cz              dd24.net            netbsd.org
  bayern.de           gmx.net             openssl.org
  bund.de             hr-manager.net      samba.org
  elster.de           t-2.net             torproject.org
  fau.de              xs4all.net          asf.com.pt
  gmx.de              asp4all.nl

Of the ~168000 domains, 737 have "partial" TLSA records, that cover
only a subset of the MX hosts.  While this protects traffic to some
of the MX hosts, such domains are still vulnerable to the usual
active attacks via the remaining MX hosts.

The number of domains with incorrect TLSA records or failure to
advertise STARTTLS (even though TLSA records are published) stands
today at 73 (~10 are recent additions that may be resolved soon,
the remaining ~60 are the for now stable population of broken
domains).  This month I'm posting the list of the 40 underlying MX
hosts that serve these domains and whose TLSA records don't match
reality.

    Hall of Shame:

    mail.dipietro.id.au        mx.quentindavid.fr         mail.jekuiken.nl
    mail.pgp.inf.br            servmail.fr                mail.myzt.nl
    mail.digitalwebpros.com    mail.nonoserver.info       bounder.steelyard.nl
    demo.liveconfig.com        mail.laukas.lt             mx.wm.net.nz
    ny-do.pieterpottie.com     mx.datenknoten.me          kitsune.one
    diablo.sgt.com             mx.giesen.me               baobrien.org
    tusk.sgt.com               mail.castleturing.net      beerstra.org
    mx.bels.cz                 datawebb.dafcorp.net       smtp.copi.org
    mail.enzevalos.de          anubis.delphij.net         eumembers.datacentrix.org
    mail.manima.de             dorothy.goldenhairdafo.net smtp3.amadigi.ovh
    www.mtg.de                 hs.kuzenkov.net            protector.rajmax.si
    mx1.spamsponge.de          oostergo.net               email.themcintyres.us
    gamepixel.eu               ren.warunek.net
    mail.thomspooren.eu        mail.e-rave.nl

The number of domains with bad DNSSEC support is 263.  With axc.nl
(the previous #1) resolved this month, the top 13 DNS providers with
problem domains, after a 5-way tie for 8th place are:

    37 infracom.nl	 - Was slated to be resolved in March, delayed...
    18 loopia.se
    18 active24.cz
    14 jsr-it.nl
    13 rdw.nl
     9 cas-com.net
     8 metaregistrar.nl
     6 tiscomhosting.nl
     6 pfsc.com
     6 ovh.net

Around 50 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries.  Only 6 of these
DNS-broken domains appear in historical Google Email transparency
reports:

  tjce.jus.br
  trt1.jus.br
  trtrj.jus.br
  tse.jus.br
  amsterdam.nl
  rzd.ru

The associated DNS lookup issues are:

  _25._tcp.ims1.rzd.ru. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.ims1.rzd.ru/dnssec/
  _25._tcp.ims2.rzd.ru. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.ims2.rzd.ru/dnssec/
  _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.lalavava.tse.jus.br/dnssec/
  _25._tcp.mx1.trt1.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trt1.jus.br/dnssec/
  _25._tcp.mx1.trtrj.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trtrj.jus.br/dnssec/
  _25._tcp.mx2.tjce.jus.br. IN TLSA ? ; SOA signature failure: http://dnsviz.net/d/_25._tcp.mx2.tjce.jus.br/dnssec/
  _25._tcp.mxin1.amsterdam.nl. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mxin1.amsterdam.nl/dnssec/

   [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>,
     Much of the TLSA non-response issue seems to be related to a
     "feature" of Arbor Networks firewalls, that enables droping
     of  DNS requests for all but the most common RRtypes.  Do not
     make the mistake of enabling this firewall "feature". ]

The oldest outstanding DNS issue is another SOA signature issue
at truman.edu dating back to Nov/2014:

  http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/

I hope some day soon they'll start missing email they care about
and take the time to resolve the problem.

-- 
	Viktor.