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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pavel,

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

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

Best regards,
   Wouter

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

iQIcBAEBAgAGBQJT7GSRAAoJEJ9vHC1+BF+Ns3gP/RRuIECXk/Z801CYKhhsXNvw
5x1uZA8UERF0wr8oreQSJsYRtaJFk6c902Q3vDyp1sJ5eOctMf1Q7wwfbDtDLIpv
JtTcv5a1u0dazbk3Guh80SluqD0tZOpssgZQZdSt6Vt7ahDlubRHqERfHCWPr1Lj
ZMnUPngEph5jEaAMC3byojWpvTcKxxhTYNIPpAsfln8eUfzkSfsI6+w8l6PSNdS4
MVleK2qAt7KBlzzDXgr3O/zoKhcfuImzVKrLhfAgYBiZT7yXfRQwck/xA2sJGLKZ
2saZdzzpnostC/X3QwzasGwDdytChnjbTeTzwwIEcySB3zpLJ4p9kHw52MoOACVH
TUMgz3M5mlSiIuiUvkfa1XDn0RixakPz0xeFIWEvN6dgtZlqp+7/d4rgtbhz1b+H
sbuf+UAnNN9cn/BRT8WCGmPhB1cnMLLxBOhON5KxJd0Q/uPdwWQMFvuKe2dfKCux
MBNNiKLRcCeFlFC/Z7ufEB62ogR3N3GKyD3StKPjHtLLDSi+NjA/juLBN0dSgERh
PMWpoqzNTopFHCfqOYOaLCY3/z8Mqk53FyqDhIH0ussoncsdb6ZVcw/nbZjeX/ew
0b1/pnpnP8pjGAu2cDhtEWbLod/yvVpwXdhalH7Y2VWme1RBDFSAGJf0pu+Y/b+W
nPx7IlMTS8n+OyULIjHa
=1FWo
-----END PGP SIGNATURE-----