[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Discovering captive portal API URL via DNS?
In general, I think that the code on a client system that is intentionally interacting with a Captive Portal (for discovery, etc), will need to use the locally-provisioned DNS. That is probably Do53, but could be DoT/DoH in the future; it would, however, be expected to be under the control of the portal if there is a portal present. Even if a system is strictly using DoT/DoH for other use cases, it needs to have some local exceptions for this kind of "system" traffic. A good example is the ipv4only.arpa lookup on DNS64 networks.
—Tommy
> On Sep 4, 2019, at 7:16 AM, Michael Richardson <[email protected]> wrote:
>
>
> Lorenzo Colitti <[email protected]> wrote:
> mcr> that things like DoT/DoH can not be used by the captive portal
> mcr> client. (I just want to make the assumption explicit. I'm not
> mcr> complaining about it)
>
>> That's not really an assumption - the fact that the captive portal
>> client can't do DoT/DoH is mostly true today, because unless the portal
>> is open, 443 and 853 are likely to be blocked. By and large, DoT / DoH
>> clients probably already know not to attempt them on captive portals.
>
> Well, a captive portal could leave HTTPS to cloudflare open, the same way
> that they might leave Do53 open to themselves, or to quadX. That works today
> for some portals.
>
> And if the portal doesn't let just *any* Do53, but only to known public
> resolvers (which they can even proxy if they want), then they can be sure to
> defeat DNS-VPN mechanisms.
>
> Some portals today *do* depend upon creating answers for names that aren't
> real. That fails today if you do DNSSEC validation. Of course, some still
> depend upon lying about all DNS requests, and but we have agreed that this is
> bad.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | network architect [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails [
>
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals