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

[Paul Wouters]

On Fri, 6 Dec 2013, Pavel Simerda wrote:

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


I don't think it is as much of a hack as you think. But of course, it
would be better not to have to rewrite /etc/resolv.conf.

The best solution blocks port 53/unbound from resolution on a new
network until NM has handled the sign-on. This can require a hot
spot sign on using some browser window that is isolated from any
running firefox, uses its own resolving - for example using libunbound
in insecure mode that is terminated with the browser window when done.

This would prevent any and all race conditions to our secure unbound
cache, and would require no resolving. But that "browser window" would
have to not use any libc gethostbyname() or get_addr_info() calls - just
libunbound calls. The system unbound daemon would return SERVFAILs until
its port 53 block is lifted - or it could be put explicitely into "cache
only" mode.

Paul