Disclaimer: /I work for a company that provides these services./ IMHO there is no need for any sort of DNS redirection after user authentication has taken place. We of course redirect UDP/TCP 53 to one of our servers along with 80 (http) 443 (https) 8080, 3128 (proxy) to the local hotspot *before* any authentication has occurred, but once this is completed the only reason any guest would use the local DNS server is if they were assigned a DHCP address. As far as our Routerboard/Mikrotik setup works, it'll masquerade for any non standard IP addresses that appear on the network (guests with static ip's assigned, corporate laptops etc) but once again after the authentication stage anything is allowed to pass unhindered. The only redirection that is used after authentication is for port 25 as 90% of user trying to send mail out via port 25 have no idea how to change their mail server, let alone why they might need to. It can be an issue as some systems use authentication on port 25. I would be interested to hear what people have to say about this, as the only other option I could think of would involve checking the incoming connection to see if the end user was trying to authenticate to a mail server before determining where to forward the connection onto (Layer 7 stuff, gets a bit tricky) Regards, Andrew Cox AccessPlus Head Network Administrator Jared Mauch wrote:
On Dec 7, 2009, at 5:29 PM, John Levine wrote:
Will be interesting to see if ISPs respond to a large scale thing like this taking hold by blocking UDP/TCP 53 like many now do with tcp/25 (albeit for other reasons). Therein lies the problem with some of the "net neturality" arguments .. there's a big difference between "doing it because it causes a problem for others", and "doing it because it robs me of revenue opportunities".
I do hear of ISPs blocking requests to random offsite DNS servers. For most consumer PCs, that's more likely to be a zombie doing DNS hijacking than anything legitimate. If they happen also to block 8.8.8.8 that's just an incidental side benefit.
I've found more and more hotel/edge networks blocking/capturing this traffic.
The biggest problem is they tend to break things horribly and fail things like the oarc entropy test.
They will often also return REFUSED (randomly) to valid well formed DNS queries.
While I support the capturing of malware compromised machines until they are repaired, I do think more intelligence needs to be applied when directing these systems.
Internet access in a hotel does not mean just UDP/53 to their selected hosts plus TCP/80, TCP/443.
The University of Michigan Hospitals have a guestnet wireless that is ghetto and blocks IMAP over SSL. Attempts to get them to correct this have fallen on deaf ears. I can't even VPN out to work around the sillyness, which typically works in other hotel/guestnet scenarios.
Providers to avoid: US Signal Corporation. (64.141.138.226 was my natted IP in a Hampton Inn depsite whois/swip).
- Jared