----- Original Message ----- > From: "Paul Wouters" <[email protected]> > To: "Pavel Simerda" <[email protected]> > Cc: "Tomas Hozza" <[email protected]>, [email protected] > 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 _______________________________________________ dnssec-trigger mailing list [email protected] http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
