[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: Friday, December 6, 2013 9:52:18 PM
> Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called
> 
> 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.

That's ok, we're each looking at it from a different perspective.

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

2) We need to resolve external addresses via hotspot temporarily.

3) We need to avoid serving those external addresses from the cache when fully connected.

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

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

Pavel