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

[Paul Wouters]

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