It did take a while to figure out what was causing the intermittent DNS failures. "My ISP is hijacking all port 53 traffic" was fairly low on my list of possibilities, I must admit.
Fortunately it's not that hard to run a local resolver that forwards queries to an external resolver on a vps on an alternate port.
I'd switch ISPs, but I live in a remote area and my only other choices would be satellite or cellular, so I'm stuck with them.
This experience has taught me simply to distrust the DNS protocol in its current form and use DNSCrypt in all situations.
[1]: Shaw Communications, chosen by the landlord.
[2]: http://dnscrypt.org/ Super shady stuff. I never rely on any ISP provided DNS servers
Google? No. Games? No. JS libraries? No.
Even if some might use CDNs, they are likely to also use geo-aware DNS servers. It cheap, don't cost anything, and can be combined with CDNs on ISP level.
This also shows a weakness in DNS. There is currently no
way to validate the DNS record you’re being served is what
the person hosting the website intended.
https://news.ycombinator.com/item?id=5937004
TLDR: DNSSEC is kinda complex and hacko, doesn't protect you as much as you might think, and introduces a whole new PKI that you should probably trust even less than the current ones. But read the links above for the real story.
I'm using DNSCrypt right now, which (correct me if I'm wrong) protects against DNS interception by my ISP, and seems like a whole lot less trouble than DNSSEC.
dnssec protects mostly from poisoning between nameservers. It does little to protect between a host and their namserver.
But in reality dnssec is not a solution, it's a problem. It will never be adopted in a meaningful way without major overhaul in spec.
Your ISP can still see the IP address of every web server that you connect to, and can still see the "Host" header that your browser sends in HTTP requests, and also in HTTPS requests (due to SNI) if you're using a reasonably modern OS/Browser combo.
All you've done is add an additional third party that can view and log what you're doing.
The snippet ended up being some sort of alert about upcoming maintenance, but using a malicious technique for a benign purpose is the path to the dark side. Use HTTPS!
(I use 8.8.8.8, it didn't help)
Here's the code they use: https://gist.github.com/ryankearney/4146814
And here's my (extremely short) writeup on it: http://blog.ryankearney.com/2013/01/comcast-caught-intercept...
I decided not to proceed with it because it seemed like a support nightmare and tampering with non-malicious subscriber traffic crosses a line.
Their marketing affiliates (such as Cash4Trafik) are always reaching out to CEO types at small ISPs and the money they bring (particularly when you are small) can be hard to pass up.
It may be the cynic in me after seeing abuses for companies like Cash4Gold, but "Cash4" anything does not instill any amount of trust in a brand, at least to me.
Knowing that you consider tampering with nonmalicious subscriber traffic to be crossing a line is something I would pay a premium for.
This would make for a great watchdog site to provide visibility across different ISPs (and could also discourage other ISPs from pulling this crap).
1. http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...
SSL, incidentally, seems like a major help here: you could detect common DNS hijackings by accessing the site via SSL. If you access https://amazon.com/ , an ISP hijacking the site would produce either a certificate error or a connection failure (depending on whether they even attempt to listen for SSL traffic).
traceroute to news.ycombinator.com (198.41.191.47), 30 hops max, 60 byte packets
1 customer-GDL-**-***.megared.net.mx << 177.230.**.*** Dynamic IP, GDL is the city of the company
2 10.0.28.62 (10.0.28.62) 8.939 ms 8.941 ms 8.935 ms
3 10.2.28.195 (10.2.28.195) 8.912 ms 8.903 ms 8.891 ms
4 pe-cob.megared.net.mx (189.199.117.***) 8.878 ms 8.866 ms 14.201 ms << COB is the user city
5 10.3.0.29 (10.3.0.29) 23.494 ms 23.483 ms 23.408 ms
6 10.3.0.13 (10.3.0.13) 22.842 ms 19.609 ms 19.596 ms
7 10.3.0.10 (10.3.0.10) 19.560 ms 19.555 ms 19.536 ms
8 201-174-24-233.transtelco.net (201.174.24.233) 19.527 ms 20.650 ms 19.468 ms
9 201-174-254-105.transtelco.net (201.174.254.105) 34.239 ms 31.793 ms 31.268 ms
10 fe3-5.br01.lax05.pccwbtn.net (63.218.73.25) 31.792 ms 31.736 ms 33.533 ms
11 any2ix.coresite.com (206.223.143.150) 32.834 ms 33.221 ms 33.429 ms
12 ae3-50g.cr1.lax1.us.nlayer.net (69.31.124.113) 41.288 ms 41.228 ms 41.231 ms
13 ae2-50g.ar1.lax1.us.nlayer.net (69.31.127.142) 42.632 ms ae1-50g.ar1.lax1.us.nlayer.net (69.31.127.138) 35.192 ms 33.860 ms
14 as13335.xe-11-0-6.ar1.lax1.us.nlayer.net (69.31.125.106) 35.143 ms 44.714 ms 44.666 ms
15 198.41.191.47 (198.41.191.47) 37.638 ms 37.239 ms 36.997 ms
Tampering with the data, however, is not OK at all. In the U.S. I believe it may make the ISP exempt from for example the safe harbor clauses in the DMCA.
This works well for me. But I have found that this is the kind of thing where an expert can pop in and say "have you considered risk X with solution Y?" and leave me dumbfounded.
So use at your own risk.
This sounds like the same behaviour that Shawn Hogan got in trouble for with cookie stuffing http://en.wikipedia.org/wiki/Shawn_Hogan
All is not lost though.
There are several ways you can protect yourself from these practices. The first thing I would do is get a router capable of using dnscrypt-proxy (http://www.opendns.com/technol.... Then you can be confident that your DNS traffic is not being modified by your ISP. It does require that you have trust in a 3rd party DNS provider like OpenDNS, but at the end of the day you have to trust someone to provide DNS lookups.
The second option is to setup DNSSEC so that you can verify where your DNS responses are coming from. While people will still be able to intercept what sites you're looking up, at least you know you're getting valid responses which is better than your situation is currently.
Third is to use both. =)
Anyhow, really awesome to see people standing against these practices. It takes users complaining to make change. The sad truth of the matter.
The same OpenDNS that hijacks NXDOMAIN responses?
I'm surprised we haven't seen similar behaviour from Chrome extensions. I'm sure it would be caught eventually, but this isn't exactly something that people tend to look for, so it would take a while for people to catch it.
The "Window Resizer" Chrome extension got a silent update a few weeks ago. It rewrote all the links on Google search result pages to point to a proxy that added affiliate links where possible.
I did a google search and realized something wasn't right. Uninstalled all the crapware apps that wormed their way in. And then I looked at the chrome extensions and low and behold there it was, more crapware.
I removed them and they re-added themselves. I had to run spybox s&d to remove it completely.
Moral of the story: chrome extensions are in some ways worse than toolbars.
Even if you are fine with your ISP committing fraud, you are negatively effected by the complexity (points of failure) and latency this adds to the network.
But seriously I don't know how brew works, though looks like the code supports the option: https://github.com/Homebrew/homebrew/blob/master/Library/For...
brew install curl --with-aresIt's fun while it lasts.
If anyone wants to do this in the future, I'd recommend just sending affiliate abuse emails with no notice to the ISP. Also, the future person may want to revise the [2] script to scan in a more surreptitious manner (change the order, add delays, simulate legit web traffic, etc).