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

[Philip Paeps]

On 2015-11-30 19:25:40 (+0530), Tomas Hozza <thozza at redhat.com> wrote:
> On 30.11.2015 14:20, Paul Wouters wrote:
>> Did you mean turning of validation instead of hardening? Hardening 
>> strips things out of additional data, I don't think that's what you 
>> want.
>
> AFAIK the only real way to turn off the validation in Unbound is not 
> to use validator module. This can not be done during runtime.

That is my understanding too.  I feel this is a good thing though.

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

I think this is a really terrible idea.  I'm shocked that this is being 
considered as a default configuration.

We should be moving towards more trustworthy DNS.  Deliberately and 
presumably invisibly turning off DNSSEC validation when it doesn't work 
is exactly the opposite of what should be done, and what dnssec-trigger 
does by default: "dear user, your network cannot be trusted; proceed 
with extreme caution or not at all".

I hadn't even considered the cache poisoning issue Paul points out.  
That just makes a bad solution seem even worse.

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

I have read your original email in this thread and I wonder why you want 
to bother with dnssec-trigger at all.  If trustworthiness of the DNS 
isn't required (or even desirable), you can run unbound as a pure cache 
without the validator module.

I agree that the present state of affairs (working DNSSEC but barely 
workable error reporting to application/presentation layer) is not 
perfect but I strongly feel we should be working on fixing the error 
reporting rather than working around broken network configurations that 
interfere with DNSSEC.

dnssec-trigger is very valuable precisely because it tells the user that 
the network cannot be trusted.  That's its job.  That's the way DNSSEC 
is supposed to work.  Either you can trust the data returned by the DNS 
or you need to tell the user that their network cannot be trusted.

Pretending that everything is fine when you know it isn't is not a 
'usable out-of-the-box experience' for regular users.  It's a regression 
in terms of their security.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information