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

[Tomas Hozza]

On 30.11.2015 15:04, Paul Wouters wrote:
> 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.

I don't think the cache is trustworthy, but only the validated responses are. This will be achieved, since no responses will be validated in this scenario and no AD flag will be set.

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

The cache is flushed in that case too, but only the negative answers.

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

Sure, that seems reasonable.

> Paul

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

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc.                 http://cz.redhat.com