[Dnssec-trigger] patch to fix the dnssec-trigger fallback issue
wouter at nlnetlabs.nl
Thu Aug 14 07:26:13 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 08/13/2014 09:11 PM, Pavel Simerda wrote:
> ----- 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
> Hi Pavel,
> On 08/13/2014 04:31 PM, Pavel Simerda wrote:
>>>> just found where the problem with not using the fallback
>>>> configuration was. All the details are in the Fedora
>>>> bugzilla ticket. 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
> 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.
So this was confusion about the probe order. The other stuff makes
sense now; the bug ticket can be what it wants to be. Most of your
questions are answered by Paul.
When all probes fail, dnssec-trigger sets unbound to 127.0.0.127, or
to 'nothing', and reports to the user that there is no connectivity
("disconnected" or "DNSSEC fails" if packets got through).
>> 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
>> 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
> 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
>> But I'm aware that it may have been easier to do it the way it is
>> 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
> And when it does it is very likely to produce DNSSEC support.
> 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.
> Best regards, Wouter
>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=1109292
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the dnssec-trigger