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

[Pavel Simerda]

----- Original Message -----
> From: "W.C.A. Wijngaards" <wouter at nlnetlabs.nl>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: "Tomas Hozza" <thozza at redhat.com>, dnssec-trigger at nlnetlabs.nl
> Sent: Wednesday, August 13, 2014 4:57:22 PM
> Subject: Re: patch to fix the dnssec-trigger fallback issue
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Pavel,
> 
> On 08/13/2014 04:31 PM, Pavel Simerda wrote:
> > Hi,
> > 
> > just found where the problem with not using the fallback
> > configuration was. All the details are in the Fedora bugzilla
> > ticket[1]. I didn't do any more extensive research but it
> > basically seems that after planning the direct probe we need to
> > also plan the tcpdns probe *before* the direct probe finishes and
> > prevents the tcpdns one from being planned.
> 
> You seem to want dnssec-trigger to probe in a different sequence of
> fallback methods?

Hi Wouter,

not really. I just wanted to use dnssec-trigger as expected and for
some reason I assumed the expected way is to prefer infrastructure
over full recursion. The bugzilla ticket was started because I failed
to test that the fallbacks work.

Given the (for me new) information that dnssec-trigger prefers full
recursion over any tcp/ssl servers, I'm now blocking packets from
UDP/TCP port 53 on the external interface using iptables. Everything
seems to work as expected now.

> At the design time the direct method was thought to be a better method
> than using a public-recursor fallback.

Sure, that won't be a problem for now and we can revisit this question
later.

> The traffic on authority servers was not considered a problem.

I don't have strong opinion on that and I probably just assume this was
a reason behind the assumed behavior. Let's ignore it for now.

> The bugzilla ticket is solving something which is not a bug but a
> feature.

To be precise, the bugzilla ticket was about a bug but one that isn't present
in the software. Let's see what evolves from it now.

> Designed in, as the order of the probes performed.

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.

Example 2: Probe my own infrastructure server, no other fallbacks.

But I'm aware that it may have been easier to do it the way it is now.

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. Also in my opinion, if all probing fails, it would be better
to let unbound reject queries immediately rather than attempt a defunct
fallback.

> The aim for the initial design was also to reduce load on that public
> resolver (hosted by us in the generic package).

I see.

> The direct (direct to authority servers) method works very often.

I guess we don't have any statistics for this, or do we? Does comparison
of hotspot probing and DNS probing give any useful results?

> And when it does it is very likely to produce DNSSEC support.

Indeed.

> Your patch also seems to have a race condition, I think, since you
> spawn both the direct and the dnstcp probes at the same time.

Yes, I wasn't aware that it creates a race, it was just a simple change
to get it going and it worked for my initial testing. Looking forward
to comments on the above.

Cheers,

Pavel

> Best regards,
>    Wouter
> 
> > Pavel
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109292
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJT63zSAAoJEJ9vHC1+BF+NLI0P/1/x29/8kZv5H9hdI6VQJBvp
> HjIVUZa5S/ajqLjwtPxXPoVTelwi5uLUSah+1kKc6tJA5oSMnPRuwy3xfVq1FD8J
> hP136PzTs8pt/1n9gcU+LPFExWshHQUjC7CHBHgDBt8WSYVqth12aAxAJPgmjsY4
> Jr+NmU4jRct/aoVn73fXNqEsJJ6lG0ByvmYETpobRhQncTX868fe0fxLMD5OjZjy
> B+uWDokS4Glh2PP5V9/3SuZZBSSFf55HpsnWup5vC+Zt0xuUDpTd4J6Xl4plrJQF
> dHaNUgyuiZfZd/osgnDK6PBTXlCH2mpxNo+w8qQx2+tiShmtaGXpq+Y2xQFs815I
> z9ZLr6CUfTXvxjyqQKdmyPyGh3858+pLqts98pGq/02R7BbId7BndfxttWg3VnJY
> O6a5HgXfbA5ogooQLY8AWgOvrp7maEYDYOfx1v7j1gSkEP4AMTga5IAC/HbBZu+O
> nH2sAuuedZqYPsTT5bkApn2epedepji28M67BjYGv3YjgWza4FtrMkgwPlOG63TW
> NjhpeLf6qE4MPrOW+PnJE1/mbVGIulhese5fTldjVI0ia4E3ZX0NpIRbJUpoi89s
> HF66Cgv7mVogXvT4Nfnh3NHOMNRTMVSk2r2SDafesdqJqy2A48e/VgewR5jNkMgU
> BNbOIR02lnHHduNGMKjB
> =h46h
> -----END PGP SIGNATURE-----
>