default local DNS caching name server
dcbw at redhat.com
Mon Apr 14 15:32:49 UTC 2014
On Mon, 2014-04-14 at 10:21 -0400, Paul Wouters wrote:
> > Or how would you suggest this is solved. For arguments sake lets
> > say:
> > SSID: myawesomeopenhotspot
> > DHCP provides no domain-name info.
> > I CNAME all records to my.hotspot. until authenticated.
> If this does not do http(s) redirection, than it is a very very broken
> setup. You would also need to block port 53 to prevent people using
> 184.108.40.206 to bypass your authentication. So I do not see this in the wild
> (and I've done the hard work of sitting in many coffee shops for
> science). hotspots tend to intercept port 80 to a mini web server that
> only serves a redirect, sometimes without any DNS name, often with a DNS
> name only resolvable by using their DNS. And that is fully supported by
> the current solution.
Many of the captive portals I've seen block all access to anything
except the portal login. You don't get to ping anything, you don't get
to DNS anything (let alone 220.127.116.11) and you certainly don't get to send
traffic outside the portal. Only when you've authenticated does it
release you. Sometimes that's done with VLANs and DHCP renewal,
sometimes it's done internally with firewall rules or something.
But another scenario I've seen: older Netgear routers which intercept
"www.routerlogin.net" as the setup page. The instructions literally
1) connect your computer to the router with a cable
2) go to www.routerlogin.net
3) follow the setup guide instructions
Any idea how dnssec-trigger + unbound would handle this? Since it's
router setup, maybe spawning the whole new window for the "portal" would
work, but you'd want to make sure the window didn't go away or DNS
didn't change until the user was done setting up the router.
More information about the devel