Hacker News Reader

Comment by deathanatos | Hacker News Reader

How do these avoid captive portals? I thought the thing about captive portals was that they intercepted DNS queries: that's what caused you to get the portal when you typed in "google.com". (i.e., it resolves all DNS entries to the portal's IP until you authenticate) Is this not correct? (I can receive arbitrary DNS, not just send?)

View on HN

I think most of them use HTTP, not DNS, given that DNS is often previously cached.

Yes in the case of Bluecoat for example, which also is used to setup paywalls sometimes, you hijack all HTTP/HTTPS traffic and redirect it to the bluecoat server. So DNS goes through and when the portal is submit nothing is done to permit DNS traffic in any type of firewall.

But maybe this is an example of a poor paywall.

Captive portals typically only capture A records, but custom servers like iodine will return results for any request type if the request starts with 'z'. As long as the captive portal supports unauthed recursing (which 99% of them do), you can still tunnel IP over DNS.

Almost all captive portals simply use MAC addresses for auth, so in practice it's much easier to spoof a host's MAC/IP and piggyback their authed session. IP over DNS is more useful for things like mobile providers where it's harder to spoof hardware identifiers, or networks that allow outbound DNS or have a DNS recursing resolver.

Somebody mentioned something about assuming networks that have deep packet inspection (really, it's almost always just application proxies on common ports) might not allow outbound DNS. Don't ever assume that the person who set up the network was smart, or that they didn't leave a hole for backwards compatibility with some legacy application. Almost all consumer-oriented networks have some hole you can use to get out to the internet.

HTTP hijacking is much more common than DNS. The reason for this is that hosts cache DNS results, so clients that just joined your network wouldn't get the redirect at all.

And yes, they probably should block excessive DNS traffic, but this is technically sophisticated to implement (now you're getting all stateful to determine what's excessive) and generally unnecessary.

It doesn't. You are correct. For any unencrypted WiFi but with a paywall / login page for actual usage - if the software is worth anything, DNS is hijacked and re-routed for unapproved clients.

It is really terrible software if it does hijack the DNS queries. That messes with all kinds of clients that cache DNS records.

A good system will allow DNS instead of poisoning the clients with thresholds to block DNS tunneling.

I would think non-NXDOMAIN answers with very short TTLs (to avoid contaminating the negative lookup cache) ought to be harmless to all but the very sloppiest clients, no?

No. First, clients may be sloppy or may have alerts triggered if the IP doesn't fall into the right range. The latter has nothing to do with poor code quality. That's the problem with hijacking DNS, you've moved well beyond web browsers into all kinds of applications that are loaded with custom code that have completely undefined behavior from your perspective. For all you know, the DNS responses you've tweaked will make the user's software completely unusable until the whole thing is restarted.

Second, what do you do when the client is configured to require DNSSEC responses?

Reply on news.ycombinator.com