Re: [dane] Behavior in the face of no answer?

[Andrew Sullivan <[e-mail]>]

On Fri, May 04, 2012 at 04:03:54PM -0400, Paul Wouters wrote:
> 
> How many months until Rogers (or OpenDNS, or...) starts spitting out AD=1
> on their DNS rewriting schemes?

I wasn't arguing that you should trust it, or that this is a good
state of affairs.  But we can't write the specification such that it
is incompatible with DNSSEC as specified, however little I personally
like the AD bit.

> So your scenario really only happens when you bring up a VPN and connect
> back to a trusted network. At that point, you can trust the AD bit, but
> you also no longer have DNS breakage/filtering happening, so the point
> is moot.

As Martin Rex argues elsewhere in this thread, a NOTIMP response to an
RR you don't know is not obviously inconsistent with RFCs 1034 and
1035.  Ekr's position would cause a system that depended on
intermediate-resolver validation, the AD bit, and a resolver that can't
handle unknown RRTYPEs, to cause all TLS negotiation to fail for
TLSA-aware clients.  This isn't "will cause TLSA not to work", it's
"can't use TLS at all on that system".  I have no idea whether there
are such configurations in the wild, but they're pefectly acceptable
under the standards we have.  It seems to me, therefore, that one
needs to be able to turn off TLSA use under such circumstances, if
we're going to say that such failures must "fail hard".

> The other scenario is an application talking to the local resolver that
> returns the AD bit, which just moves the DNS connectivity problem from the
> application to the local resolver, but runs into the same hard/soft
> fail issue, except the browser knows even less about the reasons for
> the failure or success, and can give less feedback to the user to make
> an educated guess as to the severity of the failure to be hard or soft.

Yes.

A


-- 
Andrew Sullivan
[e-mail]