[Dnssec-trigger] [PATCH] Automatic fallback to insecure mode
pspacek at redhat.com
Tue Dec 1 12:34:07 UTC 2015
On 30.11.2015 21:41, Paul Wouters wrote:
> On Mon, 30 Nov 2015, Philip Paeps 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.
>> I think this is a really terrible idea. I'm shocked that this is being
>> considered as a default configuration.
> Well, the alternatives are worse :(
> Fedora is going to basically be the first player to enable dnssec per
> default. We cannot afford this to turn into another "selinux" where
> at the first sign of trouble, people just disable the whole thing.
> So the idea is, enable the extra security but fallback to the current
> insecure status. Then when we gain more confidence, we can bring up the
> security until at some point we can turn this into a "hard fail".
> I do agree with you that we need a notification to the user, and a way
> for expert (dns) users to insist on having DNSSEC enabled in a way that
> dnssec-trigger guarantees it. We are trying to build all of this.
>> 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".
> We won't do it invisibly. Some kind of notification will be provided,
> but do note that 90% of users won't really know what to do with that
>> 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.
> We do want to go there, but early adopters causing a hard fail is not
> going to move anyone forward to universal deployment of dnssec.
>> 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
> It's more complicated than that. For instance, various parts of the OS
> are now independantly trying to deal with hotspot detection, so all of
> this requires coordination between the various OS parts.
>> dnssec-trigger is very valuable precisely because it tells the user that the
>> network cannot be trusted. That's its job.
> But the user cannot do much. Usually they have no real alternative
> network, so a popup at most warns them implicitely not to go to banking
> sites or anything important.
>> 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.
> Hardfail is just not going to work like that. Look at selinux. Look at
> browser overrides for SSL certificates that are somehow bad. Look at
> the default of allowing mixed https/http content on webpages. If
> browsers didn't do this, they would see their userbase dwindling. The
> situation with SSL and DNS is quite similar.
>> 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.
> Technically speaking, it is not a regression. For the 99.9% of users
> who are now not using dnssec on their own device, going into insecure
> mode is exactly how they are operating right now.
Thank you for summarizing this, Paul.
Once again, I would like to reiterate the point that *this is a temporary
measure*. It allows us to put dnssec-trigger and Unbound as validator
literally everywhere, into every network, without breaking 60 % of clients in
some way [1, page 22, table 11].
Imagine that we were DNSSEC fundamentalists and decided to break 60 % clients
in some way. That would cause a huge backlash against DNSSEC validation on end
Petr Spacek @ Red Hat
More information about the dnssec-trigger