Slashdot Mirror
Comcast the Latest ISP To Try DNS Hijacking
A semi-anonymous reader writes "In the latest blow to DNS neutrality, Comcast is starting to redirect users to an ad-laden holding page when they try to connect to nonexistent domains. I have just received an email from them to that effect, tried it, and lo and behold, indeed there is the ugly DNS hijack page. The good news is that the opt-out is a more sensible registration based on cable modem MAC, rather than the deplorable 'cookie method' we just saw from Bell Canada. All you Comcast customers and friends of Comcast customers who want to get out of this, go here to opt out. Is there anything that can be done to stop (and reverse) this DNS breakage trend that the ISPs seem to be latching onto lately? Maybe the latest net neutrality bill will help." Update: 08/05 20:03 GMT by T : Here's a page from Comcast with (scant) details on the web-jacking program, which says that yesterday marked the national rollout.
You're IT for a business. You have employees who check their e-mail from home, accessing your stuff via a split tunnel VPN.
The computer tries to resolve internalmail.company.com, and normally this should fail, causing the computer to try the VPN's DNS server.
Instead, your employee's computer gets Comcast's search page server. Their mail client times out.
You get inundated with tech support calls.
If all you ever use is the web, that's the extent of your issue.
Now, say your im program is set to try several different dns addresses to connect. If one has been decommissioned (but the client not updated) and your IM will try to connect, possibly passing the username and password to the server that is returned by dns for "login2.whatever.com".
Even with the web, say you have a login for a store/bank/whatever, but the latest version of there page some web developer made a typo and instead of "placeyouwanttogo.com they put "placeyouwantogo.com" (notice the number of t's). Instead of giving you a "site not found" message, you've been redirected to an ISP page that gets all of the information you were trying to pass.
Now in my example, it's possible they could push you to a typo domain as well, but the point is dns is supposed to return "Hey this doesn't exist" to your client, which then should display an error message, determined by the application doing the dns request. If it's not http, it will look like you're trying to connect to a host and it will either be A) "Connection refused" B) Answer and confuse whatever application you are running or C) appear like a black hole and never connect.
I put on my robe and wizard hat..
I've always used a linux box as my firewall /router box at home, and I've been running BIND as a caching DNS server. Fortunately this won't affect me, as I totally bypass spamcast's bullshit.
Lawyers, MBA's, RIAA? A jedi fears not these things!
My ISP does this. They also have an 'opt-out' option, but you know what that does? It still doesn't send an NXDOMAIN response like it should. Instead it redirects me to a site that is serving the standard windows site-not-found page. A horrifying experience for this mac/linux user.
So I set up my own DNS server, which fixed the problem and sped up my internet connection since the ISP's DNS server was really slow.
It's a split tunnel VPN...
That means first it tries to use the internet, then it tries the VPN. If I lookup foo.bar, and foo.bar doesn't resolve, it then tries on the VPN's DNS. That helps keep external traffic off the VPN. Internal traffic is still safe.
Of course, if foo.bar instead of not resolving--points to comcast--then I never do the lookup...and the VPN ...is broken.
The name of the box is, of course, irrelevant. But you still have it wrong: Comcast's DNS server isn't affecting the company's internal DNS server, it is affecting their customer's box, who is your employee, making it so that they never query your internal DNS server.
This happens precisely because they don't know anything about the internal network, and yet they are telling your employee they do.
'Sensible' is a curse word.
I fail to see, using your scenario, why Comcast's DNS server would effect the company's internal DNS server, thus creating the conflict you alluded to. Since I'm not sure why Comcast would know anything about the company's internal network...
That's because you didn't pay attention to the scenario. We're talking about a split tunnel VPN. DNS resolution uses the following rules:
1) try the usual (external) DNS server first. If it resolves, use that IP address for the communication.
2) try the internal DNS (via the VPN) if step 1 returned NXDOMAIN, and if that resolves, use that IP address for the communication.
3) otherwise, return NXDOMAIN.
So if Comcast's external server returns a valid IP for the internal server, instead of NXDOMAIN, then your internal mail server will never be accessible to anyone using your company's VPN from a Comcast connection.
http://tools.ietf.org/html/draft-livingood-dns-redirect-00
note where author works.
HOLY FUCKING SHIT
STOP SUGGESTING OPENDNS, THEY DO THIS SHIT TOO.
Excuse my while I go blow a bloodvessel. Every single time a story like this comes up some idiot suggests OpenDNS and idiot mods initially mod them up.
I'd link where this happened last time but for the life of me I can't figure out how to view more than my several dozen posts.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
Comcast's version is an order of magnitude better than everybody else's.
a: There is a REAL opt-out, that puts your DHCP lease to point to a DNS resolver that doesn't do this. I'll have to do this when I get home. Compare this with, eg, Verizon's pitiful opt-out instructions involving manually changing DNS settings.
b: IF you had manually set your DNS resolver to a Comcast server, you are unaffected (they added new resolver addresses to do this), per previous discussions by the Comcast folks over at Broadband Reports.
c: It does NOT get *.whatever, only www.*.(TLD), thus even when you don't opt out, it is at least limited to web-related typos. This is actually a big deal, as I think Comcast is the first one NOT to do it for everything.
I don't like NXDOMAIN wildcarding (it was one of the motivations behind building the ICSI Netalyzr), but if an ISP is going to do it, Comcast's is actually well constructed to both limit collateral damage (it only gets www.*) and be able to be bypassed with a real opt-out.
Test your net with Netalyzr
The latency comes from two factors.
The biggest is because Comcast gives very long DHCP leases, and the change doesn't propagate to your system until your access device gets a new DHCP lease.
The second is they probably batch updates to the DHCP server to say who's opted-out.
If you want to have it go faster, after going to the opt-out site, reset your cable modem and your NAT box and it will probably take effect right away. If that doesn't work, wait an hour and try again.
Test your net with Netalyzr
No new legislation is needed. Just get the courts involved.
Exactly. This act is already illegal. It is called typo-squatting.
http://thomas.loc.gov/cgi-bin/query/z?c106:S.1255.IS:=
Specifically, see section 3, (2)(a), and probably (2)(b) as well.
Now we just need as many people as we can get, whom have a domain name which is trademarked, to press charges against comcast under this law for your own domain.
`(i) an award of statutory damages in the amount of--
`(I) not less than $1,000 or more than $100,000 per trademark per identifier, as the court considers just; or
`(II) if the court finds that the registration or use of the registered trademark as an identifier was willful, not less than $3,000 or more than $300,000 per trademark per identifier, as the court considers just; and
`(ii) full costs and reasonable attorney's fees.
Chances are since the main purpose of this change is for ad revenue, and not a willful infringement, only line (I) will apply.
Additionally, you probably can't get the 'bad faith' additions applied, unless you can somehow prove the ads served on their 'page not found' fake-page happen to be ads for your competition.
But a minimum of $1000 plus attorney fee's is pretty decent if you have nothing better to do...
First off, port 53 is NOT being redirected. Use your choice of port 53 provider - whether your own DNS, Level 3, OpenDNS, whatever. As for how it works, check out http://networkmanagement.comcast.net/DomainHelperLogic.htm and http://tools.ietf.org/html/draft-livingood-dns-redirect-00 for the precise details. The second document is a complete technical description.
A hard-coded IP address in the hosts file is often a bad idea. A simple example: when I'm on-site, company.com resolves to the internal (10.x.x.x) address, but when I'm off-site, company.com resolves to the public address. When employees are on-site, you want traffic to stay on the network, and using the external IP could cause your internal traffic to be routed out of your network and right back in.
Any reasonable split tunnel VPN program does exactly the opposite - prioritises the VPN DNS settings over the internet.
Not saying the setup Comcast has is good, just saying.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Yes, but it's poor practice to advertise anything but a webserver through a www.* IP name. If the host is doing something else, it should have another IP name for people accessing that function. Among other things, it makes it much easier to move that function off that machine without touching the webserver. www.* could affect things other than webservers, but it shouldn't, and mostly, it won't. That doesn't make what Comcast is doing *right*, but it does make it slightly less horribly awful. Slightly.
The page you get from Comcast (or whoever) is the same as getting the busy signal/number not found.
A busy signal doesn't try to sell you ads, so it makes sense. Also, we already have something that is the same as a busy signal -- it's called NXDOMAIN.
They're also irrelevant for mail delivery, as last time I checked, mail wasn't sent via HTTP.
Which is one of the main points here -- if it's HTTP, especially if it's HTML over HTTP to a web browser, then getting Comcast's page probably wouldn't bother you any more than getting Firefox's "not found" page. It might use slightly more bandwidth, but it wouldn't really be an issue.
The problem comes when you start doing things like mail delivery, or any number of other applications, which expect nonexistent domains to be, well, nonexistent. Many of them will never fire an HTTP request, and so could not even theoretically figure out WTF is going on -- they get a "connection refused", at best, and maybe they have to wait for a timeout, instead of an immediate domain-not-found error.
It's especially harmful for various applications which depend on actual domain-not-found results, such as various VPN setups. This is more or less exactly like the analogy given -- the payphone giving you your dime back depends on getting an actual, real busy signal and/or "not in service" result. Anything else, and it assumes you were successful, and does the wrong thing -- in this case, it eats your dime.
Don't thank God, thank a doctor!
We're talking about the DNS search, not actual routing. First you check the internet and then you search the VPN DNS. This is so that if $work is doing the same type of redirection (which is fine - it's their resources that they're serving, so if they don't want you going to playboy.com, that's their business) you can still reach the external network without using $work's resources. There's no reason why your employer's computer-use policies should interact with your home use, even when connected to the office over VPN.
This requires that your DNS is resolved via the internet before VPN. And requires that the internet DNS behaves properly.