On Fri, Apr 17, 2020 at 07:27:58PM -0400, Rich Felker wrote:
> > No, I have not. Read my message again, then try:
> >
> > dig -t mx nist.gov
> > dig -t tlsa [_25._tcp.]nist-gov.mail.protection.outlook.com
>
> Missing the _25._tcp.
Yes.
> but either way it seems to be a misconfigured domain.
Well, there are millions of such domains. This particular
problem will be solved as Microsoft performs the necessary
upgrades to support inbound DANE by the end of 2021, but
the problem is not limited to them alone.
> I didn't dig into (pardon the unintended pun) what the problem
> is. Is your point that it would be avoided entirely by not doing the
> TLSA lookup (thereby not having to honor the servfail as a tempfail)
> if the MX isn't signed?
That's correct. RFC7672 spells this out, TLSA lookups are only done
when the MX host is in a signed zone.
>
> > But TLSA queries to unsigned domains still often run into lookup
> > failure. What then?
>
> Lookup failure is *always* tempfail. This is completely independent of
> DNSSEC or DANE. You cannot treat lookup failures as absence of a
> record. But I do see, if that's what you're trying to say by the
> above, how you can benefit from avoiding the lookups and thereby
> possibility of failure to begin with, so that you don't need a big
> table of broken domains to work around or whatnot (eew).
No such table is feasible at present.
> > But unsolicited TLSA queries into unsigned zones don't work
> > (sufficiently often to make attempting to do so impractical).
>
> Is this because of buggy auth nameservers that reply with servfail for
> RR types they're not aware of?
Some reply with NOTIMP (Microsoft), some simply don't respond, others
ServFail, ... And then, what Wietse said, what's the point exactly?
If the TLSA records offer no MiTM protection, why exactly should we
bother with the security theatre? (Please don't answer the rhetorical
question).
--
Viktor.
