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

[Tomas Hozza]

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

On 08/13/2014 11:22 PM, Paul Wouters wrote:
> 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.

I think "bad" is a point of view. Doing full recursion produces more
DNS queries (until cached) to the net, just asking the fallback server
produces one. Then further queries origin from that server. Also if the
fallback server does resolving for more users, the harder is to say who
originally asked for the name, right?

So it depends on how you put it and what is your intention. I understand
that you don't want to use "untrusted" 3rd party fallback
infrastructure, since you consider the authoritative servers more
trustworthy. Others may consider the other way around the better choice.

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

Nobody said that the infrastructure we want to use is broken. It is the
fall-back infrastructure configured in dnssec-trigger configuration.

We are talking about trying to use the DNSSEC-enabled fallback
infrastructure first. The "other fallbacks" stands for other fallback
mechanisms, like full recursion, etc., right Pavel?

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

I think that Pavel pointed out the use case already required by
dnssec-trigger when setting 127.0.0.127 as forwarder.

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

Regards,
- -- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT7JSbAAoJEMWIetUdnzwtptoIAL5HfiOFuRNRNYxc+dY2FGaz
iZcKumf+QPsjsUcxmmQQvOAUTPsGkBf4aCEdbmaTVUridNhEdAC7Cp9zHhsQVSfD
8+GArBI9LlDu7Ax1bv7tWlpx7FojUCJK+FI/E7BjHUW63Ogs/OYyjWg99ALlgK4u
ItDsPuZZnJpbcHC1HNtrPa2YstW635g41y2dR+PK5OueLRKs5SaIZ9OPgupnBSi5
aPGbDcddLTS1X8q+dMg19HAYIqkQm9xOq/JJmn23/JzgBrKob/0IXavMrS09pJEs
wgYShZ0TTb0jKYWpadHKzXRVl+H7nI258W3W1kgrG7f18FM0cByYlfKc7ckuywA=
=hyEl
-----END PGP SIGNATURE-----