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

[Paul Wouters]

On Wed, 13 Aug 2014, Pavel Simerda wrote:

> In my opinion, it would be much nicer to have an ordered list of configured
> probes including the full recursion probe. That way any distribution and
> user could use any probe order.
>
> Example 1: Probe fedora infrastructure over 443, then fedora infrastructure
> over 80 and then the root servers.

That is bad. It would leave a privacy trail on the fedora server
whenever I logon to a network where I'll never use the fedora
infrastructure. It should ONLY be probed when I have a need for it.
We avoid probing anything that's not the root or a large TLD server
in the hopes that our queries are not leaving too many fingerprints
on the net.

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

> 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? As in be dead in the water? Can you explain
why that would be useful to a user?

> 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? Often the TCP based fallback is slow and
results in timeouts. It is still better then rejecting everything. And
once unbound implements draft-ietf-dnsop-edns-chain-query those problems
would hopefully go away as it would only require on consistent open TCP
connection.

Paul