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

[Paul Wouters]

On Thu, 14 Aug 2014, Tomas Hozza wrote:

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

I am worried about leaking my source IP trail to one single (fedora)
server. Using local caches actually makes it much harder to track my
whereabouts, precisely because they have cache. Even if all the local
wifi's used 8.8.8.8, my whereabouts wouldn't routed far up the network,
and hopefully would be more lost in the noise. Those queries would also
most likely go in plaintext (port 80) to the fallback server and not
over tls (port 443).

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

Offering the users too many dials and buttons is not good. We need to
look at DNS privacy concerns and make as many decisions for the users
as we can. Powerusers can always setup a VPN to their own infrastructure
and use their own DNS servers there.

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

Which, if you have used it at all, tends to cause many timeouts right
now, and I often have to go to INSECURE mode or bring up a VPN because
it becomes unworkable really fast.

> We are talking about trying to use the DNSSEC-enabled fallback
> infrastructure first.

I understand. And I have a problem with always sending out a pretty
unique/rare probe packet that identifies me if it is not required to do
so. The design of dnssec-trigger takes privacy into account. I went
around asking some big TLDs for certain test records, precisely because
it is better to ask TLD servers are not have OS specific probes send.

I believe it would be good not to send probes to fedora/rhel
infrastructure, unless you have no choice.

Additionally, probing when not needed puts load on the servers
too. Remember those fallback servers only talk TCP or TCP-SSL to
clients.

Paul