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

[Paul Wouters]

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. It's the "click to continue" soft fail.

>>> 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.

>> 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.

>>> 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's why I wrote the tcp-edns-query-chain draft.

Paul