[Dnssec-trigger] [PATCH] Automatic fallback to insecure mode

Paul Wouters paul at nohats.ca
Mon Nov 30 14:04:58 UTC 2015

On Mon, 30 Nov 2015, Tomas Hozza wrote:

> To be honest this seems like what we need - if the local resolvers are not usable for getting DNSSEC data, use them directly and ignore that they are not providing the data.

Well, it makes the cache untrusted and contaminated.

>> If you contaminate the unbound cache and/or force cache clears, then I consider that solution unworkable for me personally.
> We flush the cache on every network configuration change.

But there is an option to disable that, on my request, because as I
explained, 1) starting from a fresh cache increases the risk of cache
poisoning, and 2) it leaves a very veriably fingerprint when my
combination of software starts doing DNS queries. So I use that option
to disable the cache flush.

> Switch to insecure mode can happen only after network configuration change. In such situation there is nothing to contaminate, because the cache is flushed. Also after the switch to/from insecure mode the cache will have to be flushed.

I understand it works in the default deploymentment planned.

> Please be more specific about why this would not work for you. We will have to come up with some sensible behavior and defaults (and flushing cache is one of them IMO), because we want to move from the solution that worked for handful of hackers that knew what is happening, to the solution that will be used by default and has to be usable out-of-the-box for regular users.

This behaviour plus the option to disable cache flush should not be
allowed to be active at the same time. It leads to possible fraudulent
data in the unbound cache when the cache is expected to be trustworthy.


More information about the dnssec-trigger mailing list