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


> 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