On Fri, Apr 17, 2020 at 07:01:26PM -0400, Viktor Dukhovni wrote:
> On Fri, Apr 17, 2020 at 06:52:48PM -0400, Rich Felker wrote:
> 
> > > There are (unsigned) domains where any attempt to look up TLSA records
> > > times out or otherwise fails.  If DANE is to be downgrade-resistant, and
> > > if logging of DANE-verified connections is to mean anything in terms of
> > > actual resistance to downgrade attacks (otherwise opportunistic TLS is
> > > quite sufficient), then in fact validation is required, and TLSA lookups
> > > should not be attempted for MX hosts in unsigned zones.
> > 
> > I think you misinterpreted my above-quoted text to mean that you
> > should treat timeout/servfail/etc. as absence of TLSA records. That is
> > absolutely not what I mean or something I would ever advocate for.
> > Only a success or nxdomain result is actionable. Anything else is
> > necessarily tempfail, regardless of DNSSEC or DANE.
> 
> No, I have not.  Read my message again, then try:
> 
>     dig -t mx nist.gov
>     dig -t tlsa nist-gov.mail.protection.outlook.com

Missing the _25._tcp. but either way it seems to be a misconfigured
domain. 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?

> > If you have correct nameserver configuration that validates DNSSEC,
> > either success or nxdomain is proof that the result was signed or the
> > records are in a provably unsigned domain.
> 
> 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).

> > But it does not justify dropping all protections if you can't see it,
> > just dropping the ability to log (or rather, warning in the log that
> > all records look like potentially-unsigned ones).
> 
> 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?

Rich

Reply via email to