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
_______________________________________________
dnssec-trigger mailing list
[email protected]
http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
