I might be wrong, but wouldn't this not help the situation at airports where the AP resolves all DNS requests to a page that is like "pay for service!"?
I was under the impression that in those configurations the AP intercepts all the DNS packets and responds with a fixed IP.
It would be nice to get around port blocking filters though...
No, I think that's the firewall modifying the headers. I still encounter the portal page when I use a different DNS (although the portal hostname doesn't resolve). I'm not sure if they have even figured out how to do DNS authentication yet.
Not exactly. The general term for the system that captures your first page is "captive portal". The short version is they intercept your first Internet-bound web request and send you a HTTP redirect to their login site. Once you give the portal whatever it needs to authorize you the local firewall is configured to allow your traffic out.
Generally captive portals will leave your DNS alone. They don't really have a lot of choice about this: if they poison your name cache you won't be able to get to your home page. Windows used to (still may) hold on to names for a minimum period regardless of TTL. A fair number of laptops have custom DNS. Combine those two and you can almost always get correct recursive DNS and frequently UDP 53 out.
Not sure about this. I've tried to use OpenDNS behind a "buy my wireless for 24 hours" at an airport and I still got the page requesting me to buy a page.
Also, even when I pinged servers the IPs were resolving to their "purchase" page. Unfortunately, I didn't have an IP of a site on hand to see if I could request by IP out.
If the captive portal is rerouting every IP packet (apart from DNS lookups) from an unauthorized MAC to the same central server (so that it can spoof the HTTP redirect to the payment page), this is exactly what you'd expect to see.
It doesn't matter what DNS you're using - the DNS lookups should resolve to correct IPs otherwise your local DNS cache would be poisoned.
The captive portals I've seen don't tamper with HTTP headers at all, or were you referring to IP headers? As for DNS, I don't think there's any safe way to avoid providing unauthenticated hosts with working DNS.
I may be getting things confused here, but I usually see captive portals do HTTP redirection (looking from a sniffer). That would involve tampering with the headers, correct?
Just IP NAT on the dest address sending you to the portal server. So actually they do tamper with headers, but only IP headers. You don't actually get any traffic to the real site until after your machine has been exempted from the NAT rule (and presumably a drop rule for non-HTTP traffic). There's an open source captive portal called NoCat that you can poke at if you ever want to set one up yourself.
I was under the impression that in those configurations the AP intercepts all the DNS packets and responds with a fixed IP.
It would be nice to get around port blocking filters though...