[Dnssec-trigger] patch to fix the dnssec-trigger fallback issue

[Pavel Simerda]

----- Original Message -----
> From: "Paul Wouters" <paul at nohats.ca>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: dnssec-trigger at nlnetlabs.nl
> Sent: Thursday, August 14, 2014 4:18:29 PM
> Subject: Re: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
> 
> On Thu, 14 Aug 2014, Pavel Simerda wrote:
> 
> >>> Example 1: Probe fedora infrastructure over 443, then fedora
> >>> infrastructure
> >>> over 80 and then the root servers.
> >>
> >> That is bad.
> >
> > Are you saying that it is bad to *have* this option or that it is bad to
> > *choose* this option for your installation?
> 
> That's the same thing. Offering unwise options to users is bad, because
> they will end up using it.

Do you actually advocate hardcoding configuration in C just to prevent the
administrator from creating a configuration that you consider unwise? I would
rather be able to configure the software to my liking even if it was just for
testing purposes. But I agree that good defaults are a must.

> It's the "click to continue" soft fail.

I don't think administrative configuration and "click to continue" are
comparable in any way.

> >>> Example 2: Probe my own infrastructure server, no other fallbacks.
> >>
> >> I'm not sure how that use case is helpful to dnssec-trigger? We want to
> >> get working DNSSEC capable resolving going. If you want to somehow only
> >> use your infrastructure, even if it is broken, you should not use
> >> dnssec-trigger but use NM or equivalent to configure unbound directly.
> >
> > It would still provide the probing and the user would get consistent user
> > experience. Imagine a number of own infrastructure servers instead of one,
> > if you think the example is too simple.
> 
> The override is already there to go "INSECURE". We could possibly make
> it more clear to the user that the local infrastructure was broken and
> if they require its use they should override. And possibly not just call
> it INSECURE, but something like "force local insecure/broken" or
> something.
> 
> >>> And I also don't like that unbound's "forward off" has a side effect of
> >>> turning on full recursion. I would prefer if the "off" value would just
> >>> do what it says, i.e. remove all forwarders and if there was a separate
> >>> "direct" or "recursion" value/option that would turn on the full
> >>> recursion.
> >>
> >> You want a state where unbound would not be allowed to forward and
> >> not be allowed to recurse?
> >
> > Exactly. And I'm apparently not alone as dnssec-trigger seems to already
> > work around this limitation by setting 127.0.0.127.
> 
> unbound still answers to incoming queries from the cache in that state.
> So it is still a resolver for the client applications. I had they
> impression you wanted unbound to not answer at all.

Why would you have that impression? I'm just not entirely happy about the
messy configuration where you have to use "off" for "full recursion" and
"127.0.0.127" for "off" (or empty list, no recursion). But I see that it
technically works and I can live with it if it's too late to change it
to something more sane.

> >> As in be dead in the water? Can you explain why that would be useful to
> >> a user?
> >
> > There are periods of time when there's no secure DNS service for global
> > resolution available and there's no reason to keep bogus configuration
> > for the time. The user would receive failed responses faster and could
> > still successfully query the forwarders.
> 
> I don't understand this. What lingering bogus configuration? Your
> definition of "successfully query the forwarders" when those are broken
> for DNSSEC is not the same as my definition.

I'm not aware of a possibility to have different definitions, here.

> >>> Also in my opinion, if all probing fails, it would be better
> >>> to let unbound reject queries immediately rather than attempt a defunct
> >>> fallback.
> >>
> >> What is a defunct fallback?
> >
> > A fallback that doesn't reply. I don't know what's the exact current
> > behavior when probing fails for all fallbacks.
> >
> >> Often the TCP based fallback is slow and results in timeouts.
> >> It is still better then rejecting everything.
> >
> > Do you propose to use a random failed fallback? Is anything similar being
> > done already?
> 
> I would like to see unbound use one or a few persistent TCP connections
> to the upstream fallback resolvers, as that will greatly reduce the
> timed out queries to fallbacks that DO work but are too slow now because
> the local unbound builds a TCP handshake for every individual query.

That seems to be unrelated both to my question and to my concern about
what exactly happens when *none* of the dnstcp fallbacks are reachable. I'll
be happy if the draft gets implemented but I don't see any relation to any
of my questions/concerns.

Cheers,

Pavel