[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: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>, dnssec-trigger at nlnetlabs.nl
> Sent: Wednesday, August 13, 2014 11:22:53 PM
> Subject: Re: [Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
> 
> 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.

Are you saying that it is bad to *have* this option or that it is bad to
*choose* this option for your installation?

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

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.

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

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

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

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

Ah, that's a good news.

Cheers,

Pavel