On Sun, 8 Dec 2013, Pavel Simerda wrote:
But of course, it
would be better not to have to rewrite /etc/resolv.conf.
Agreed.
The best solution blocks port 53/unbound from resolution on a new
network until NM has handled the sign-on.
I don't think I understand the idea.
1) We need to keep name resolution on the localhost side working.
No. You cannot. When on a hotspot, there is no valid "name resolution"
until you have authenticated. Any DNS lookups to applications _should_
fail, because there is no DNS that is trustworthy. This is when the user
sees warnings from IM clients or browsers or email clients saying
"something wrong with certifiacte" when presented with the ssl variant
of the hotspot. Resolution is better of getting servfails until the
hotspot has been validated and dns can be trusted.
2) We need to resolve external addresses via hotspot temporarily.
No. _only_ the addresses required for the hotspot authentication should
be resolved.
3) We need to avoid serving those external addresses from the cache when fully
connected.
Not just "when fully connected". Whenever!
From my perspective, the best way would be to teach 'unbound' to either cache
the hotspot-mode results separately or not cache them at all, which might be
even easier. I don't think blocking any unbound communication on firewall can
help.
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.
Yes, that would be theoretically possible but unless we really need to do
Firefox magic (which we apparently don't), I would rather avoid it. When the
only problem is unbound caching during the hotspot registration, then why don't
we just solve it there. It's so much easier than any magic and will eventually
be more universal.
I don't think we are agreeing about what the problem is. I am saying it
is a problem if _any_ application apart from the "hotspot signon" is
receiveing untrusted DNS that has been specificaly bypassed DNSSEC.
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.
Sounds like a solution, but not one I would prefer over simply solving the unbound cache
pollution problem. But anyway thanks very much, you helped me to sort my thoughts better.
Actually, you can view the "nocache" solution as a simplification of the
browser windows solution, as indeed we need to act at the same phases. The only
difference is whether we use a separate channel for name resolution, or we handle the
caching. Thanks.
Right.
Paul
_______________________________________________
dnssec-trigger mailing list
[email protected]
http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger
