[Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called

[Pavel Simerda]

----- Original Message -----
> From: "Paul Wouters" <paul at cypherpunks.ca>
> To: "Pavel Simerda" <psimerda at redhat.com>
> Cc: "Tomas Hozza" <thozza at redhat.com>, dnssec-trigger at NLnetLabs.nl
> Sent: Thursday, December 5, 2013 4:10:53 PM
> Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called
> 
> On Thu, 5 Dec 2013, Pavel Simerda wrote:
> 
> >> And for good reason. If you go from a polluted cache to enabling
> >> DNSSEC, you would have to validate the entire cache contents, or
> >> just flush it and start from scratch. You could not use any
> >> content in the cache since it had not been validated.
> >
> > Actually, when you change configuration at runtime, you should always flush
> > the cache for the respective subtree as well. For example when you remove
> > an insecure forward zone, the cache is polluted as well. I actually think
> > that unbound should flush the cache automatically to avoid that. As a
> > workaround, the cache can be flushed explicitly.
> 
> The way we implemented runtime forwards, eg from VPNs, we do flush the
> particular DNS domain from the cache - no need to flush everything.
> 
> Paul

I can imagine that temporarily polluting /etc/resolv.conf with global DNS information can be tempting at first, as it sort of implements a permissive mode without losing the whole unbound cache. And it indeed works for testing or technology previews.

But we need a rock solid solution and I don't think writing any other nameservers than 127.0.0.1 fits in this requirement. NetworkManager seems to be affected by changes to /etc/resolv.conf and 127.0.0.1 is easy to filter out at all levels. I've heard voices that selinux-based systems might want to pick up a single service that would be allowed write to /etc/resolv.conf and nobody says it will be dnssec-trigger.

And after all we do have some development power and we could fix (or let's say improve) unbound so that it can properly handle secure/insecure objects in the cache. In the meantime we can flush the cache as a workaround. This is not the only limitation of unbound that we found regarding real-world DNSSEC deployment and certainly not the only one we employ workarounds for.

In the long term, I would rather rely on a good RDNSS software (such as unbound with a couple of future improvements) than on hacks like dropping unbound temporarily from the name resolution process.

Pavel