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

Paul Wouters paul at nohats.ca
Mon Nov 30 13:20:51 UTC 2015

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.

If you contaminate the unbound cache and/or force cache clears, then I consider that solution unworkable for me personally.


Sent from my iPhone

> On Nov 30, 2015, at 04:05, Tomas Hozza <thozza at redhat.com> wrote:
>> On 25.11.2015 16:23, Tomas Hozza wrote:
>> Hi.
>> In Fedora we had a discussions with GNOME and NetworkManager
>> developers about how to seamlessly integrate dnssec-trigger
>> and Unbound by default to the Workstation Product of Fedora.
>> The bottom line was that we should not use the panel applet
>> and rather do some better integration with NM and let GNOME
>> do some work.
>> Also some important decisions had been made, like automatic
>> switch to insecure mode when all attempts to use DNSSEC have
>> failed. This is mainly to NOT to break user experience and
>> rather fall back to the current state in which DNSSEC validation
>> is not done by default in Fedora.
>> Not having panel installed is the easy part, we split it into
>> separate sub-package which is not installed by default.
>> NM already implements the Captive Portal detection, GNOME
>> checks the connectivity state in NM and is able to
>> launch a browser window. Therefore we disabled the Captive
>> Portal detection in dnssec-trigger and also disabled the
>> login-action when installed on Workstation. Now such situation
>> need to be handled properly anyway in dnssec-trigger. By
>> properly I mean that for the time of hotspot login dnssec-trigger
>> should be switched to the hotspot signon mode. NM devels
>> will add the notifications on Connectivity state changes into
>> nm-dispatcher. This would allow us to call dnssec-trigger-control
>> from the dnssec-trigger Python script we use and switch
>> dnssec-trigger to the hotspot signon mode. The switch back
>> should be done also by calling dnssec-trigger-control to
>> reprobe. However my ideas how to do it may change once I start
>> testing it.
>> Some parts are still missing, but we are working on it.
>> We are restarting the effort to have Unbound and dnssec-trigger
>> installed and used by default from next Fedora (24), so you'll
>> see more emails from us :)
>> I started by implementing the automatic switch to insecure mode.
>> I added two new options:
>> 1. auto-insecure - which takes yes/no and makes dnssec-trigger to
>> switch to insecure mode in case DNSSEC can not be used on the
>> network. This is done without any user interaction.
>> 2. on-insecure-command - which takes string that will be run as
>> a command on switch to insecure mode. This seemed to be handy for
>> the future e.g. for triggering a notification to the user.
>> I'm also attaching two changes for dnssec-trigger-script,
>> which are more of a cosmetic changes to not scare users with
>> unnecessary warnings and errors.
>> Regards,
>> _______________________________________________
>> dnssec-trigger mailing list
>> dnssec-trigger at NLnetLabs.nl
>> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
> Hi.
> In Fedora we are currently discussing a different approach for
> insecure mode, which would leave the localhost address in resolv.conf,
> and rather set 'harden-dnssec-stripped' to 'no' in Unbound.
> Please wait with applying the changes I sent.
> Thanks ans sorry for the complications.
> Regards,
> -- 
> Tomas Hozza
> Software Engineer - EMEA ENG Developer Experience
> PGP: 1D9F3C2D
> UTC+1 (CET)
> Red Hat Inc.                 http://cz.redhat.com
> _______________________________________________
> dnssec-trigger mailing list
> dnssec-trigger at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger

More information about the dnssec-trigger mailing list