I fought my ISP's bad behavior and won(erichelgeson.github.io)
erichelgeson.github.io
I fought my ISP's bad behavior and won
http://erichelgeson.github.io/blog/2013/12/31/i-fought-my-isps-bad-behavior-and-won/
114 comments
Very nicely done: reporting this as abuse to the companies offering these affiliate programs seems quite appropriate, and it sounds like they reacted appropriately. One person complaining to an ISP is noise; one person making an abuse report is all it takes to get that ISP banned from the affiliate program.
If the ISP was being transparent about where they were going to source traffic I'm surprised that they ever got onto the affiliate program in the first place.
Cox does something similar but bypasses the the DNS records and just slipstreams in a response. I noticed Cox would redirect javascript requests to their own HTTP server and put in their own snippets, effectively doing mass javascript injection.
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)
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)
Comcast also injects JavaScript into HTML responses if they feel the need to send you a message.
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...
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...
Isn't that CFAA abuse on their side?
I had this happen to me and it pushed me to use a vpn for all personal Web traffic.
Rogers (Canada's Comcast) does the same thing, but for warning you about your bandwidth usage.
If your ISP and/or Aspira were making any significant amount of affiliate commissions, I would be surprised if the merchants do not take action against them for fraud.
This sounds like the same behaviour that Shawn Hogan got in trouble for with cookie stuffing http://en.wikipedia.org/wiki/Shawn_Hogan
This sounds like the same behaviour that Shawn Hogan got in trouble for with cookie stuffing http://en.wikipedia.org/wiki/Shawn_Hogan
I chatted with a company that investigates affiliate fraud, they may have a blog post up after the new year about this. Will submit it if/when they do.
The ISPs that I've heard of using this claim to be getting low to mid thousands per month in revenue from it. I'm not sure if that counts as a significant amount of commission, but...
Ahh... DigitalPoint, those were the days.
The cynical side of me says that the ISP is just going to redirect the author's traffic to the "pure" DNS server in the future (even when he or she directs traffic to the main one) unless they get in serious enough trouble with one of the companies this first time.
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).
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).
Eric, I am very sorry to see this happen to you. Unfortunately more and more companies are using our data for marketing purposes.
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.
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.
> It does require that you have trust in a 3rd party DNS provider like OpenDNS ...
The same OpenDNS that hijacks NXDOMAIN responses?
The same OpenDNS that hijacks NXDOMAIN responses?
I only said OpenDNS was one of the options. There are many DNSCrypt enabled servers not run by OpenDNS. Seems anytime someone event mentions OpenDNS the same arguments get brought back up. If you don't like OpenDNS, then use DNSCrypt with another server. Simple solution.
Only for the unregistered accounts IIRC. Can't you disable it after going thought the simple registration and claiming of IP address?
So only if you help them associate all of your internet traffic with a registration. Hm, sounds privacy-conscious.
As a ISP when we were considering using Aspira they claimed that no referral tokens would be replaced and that the only behavior was injecting a popup coupon window.
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.
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.
> Cash4Trafik
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.
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.
May I ask which ISP you work for?
Knowing that you consider tampering with nonmalicious subscriber traffic to be crossing a line is something I would pay a premium for.
Knowing that you consider tampering with nonmalicious subscriber traffic to be crossing a line is something I would pay a premium for.
Just a little Rural Wireless/Fiber+Metro Datacenter/whatever provider in Southeastern Wisconsin. I try to keep my personal opinion at least one step removed from their name just in case :-) My email is in my profile. If you need a connection in that geographic area hit me up and I'll see what we can do.
Yes, and conditioning your users to click on popups. Glad you chose not to!
Super shady stuff. I never rely on any ISP provided DNS servers. I'm glad you talked to the the etailers to let them know what was going on. These business practices do introduce latency, regardless of what he told you. Not to mention, they are highly unethical and dishonest.
A really shady ISP could intercept and redirect any outgoing port 53 traffic to their servers.
That's what my ISP does. What's worse is that sometimes their dns servers fail intermittently (something to do with fragmented packets and retrying DNS queries in TCP mode).
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.
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.
If that were the case, I would immediately terminate any relationship with them and out them in public. While technically possible, you're now talking about a whole other form of dishonest behavior. Some would say criminal.
This has been done. I'm not sure how prevalent it is now.
http://comcastisfuckingwithyourport53traffic.wordpress.com/
http://comcastisfuckingwithyourport53traffic.wordpress.com/
My ISP [1] actually does this. They offer an opt-out of NXDOMAIN hijacking, but silently proxy all port 53 traffic regardless.
This experience has taught me simply to distrust the DNS protocol in its current form and use DNSCrypt in all situations.
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/DNSCrypt is useless. Yeah, they can't see that you did a DNS A record lookup for www.example.com, but they can still see your subsequent TCP connection to the IP you received in your encrypted DNS response, and see the HTTP Host header that your browser sends. Even if it's a HTTPS connection, modern browsers leak the hostname then too, due to SNI.
Signing DNS responses has much more value than encrypting them.
If you set up DNSCrypt with OpenDNS, you're not improving the situation. You're just adding an additional third party that can see what you're doing.
Signing DNS responses has much more value than encrypting them.
If you set up DNSCrypt with OpenDNS, you're not improving the situation. You're just adding an additional third party that can see what you're doing.
Why do you keep posting this? It's irrelevant because the idea isn't to hide what site you're visiting, it's to prevent the ISP from modifying the DNS responses. Signing DNS responses would be helpful if that was actually enforced anywhere.
DNSCrypt is a perfectly fine solution for this threat model.
DNSCrypt is a perfectly fine solution for this threat model.
"Why do you keep posting this?"
I posted a similar comment twice in response to different people. There is nothing wrong with this.
The rest of your comment is irrelevant as it assumes I'm replying to the article rather than to the parent comment. The parent stated that he uses "DNSCrypt in all situations." I don't want people to think this is a good idea.
I posted a similar comment twice in response to different people. There is nothing wrong with this.
The rest of your comment is irrelevant as it assumes I'm replying to the article rather than to the parent comment. The parent stated that he uses "DNSCrypt in all situations." I don't want people to think this is a good idea.
Are you using Shaw's DNS servers? I don't remember dealing with NXDOMAIN issues when I had Shaw, but I have run my own DNS servers for a long time now.
It's been 7 years or so since I used Shaw.
It's been 7 years or so since I used Shaw.
It doesn't matter what DNS servers I specify; Shaw intercepts all DNS requests. I can even make up a nonexistent DNS server as long as it's internet-routable, and will get a valid response from Shaw. This works, for example:
dig @www.facebook.com news.ycombinator.comAll that means is that you're using their recursive DNS servers. They can configure these any way they choose. Stop using third party recursive DNS servers and you will not have problems with unwanted advertising and NXDOMAIN hijacking.
Run your own recurive DNS server (e.g. dnscache) on 127.0.0.1.
Alternatively, query authoritative servers directly. Use a port other than 53 if you really think your ISP is trying to filter your outgoing queries; I sincerely doubt they would bother.
192.5.6.30 is an authoritative .com server. Memorize that number.
dig +norecurse -b0.0.0.0#5353 news.ycombinator.com @192.5.6.30
The names on the right of the "NS" rows are the authoritative servers for ycombinator.com. (Cloudflare. No comment.)
192.5.6.30 has the IP addresses for those. You'll find them in the "ADDITIONAL SECTION". Let's say it lists 1.2.3.4 as an IP address.
dig +norecurse -b0.0.0.0#5353 news.ycombinator.com @1.2.3.4
And you should receive the IP address for news.ycombinator.com, or at least your next clue where to look (if the DNS admin has chosen to play games with CNAME).
This method can be automated.
Your ISP is not "intercept[ing] all DNS requests". You are sending your requests to your ISP's recursive DNS servers (why?), and those servers are feeding you whatever information the ISP chooses. Go figure, they are sending you bogus info to inject advertising. Solution: Stop sending your requests to your ISP's recursive DNS servers (or any third party recursive DNS servers). Send your requests to your own recursive DNS server running on 127.0.0.1, or send nonrecursive requests to authoritative DNS servers only.
Run your own recurive DNS server (e.g. dnscache) on 127.0.0.1.
Alternatively, query authoritative servers directly. Use a port other than 53 if you really think your ISP is trying to filter your outgoing queries; I sincerely doubt they would bother.
192.5.6.30 is an authoritative .com server. Memorize that number.
dig +norecurse -b0.0.0.0#5353 news.ycombinator.com @192.5.6.30
The names on the right of the "NS" rows are the authoritative servers for ycombinator.com. (Cloudflare. No comment.)
192.5.6.30 has the IP addresses for those. You'll find them in the "ADDITIONAL SECTION". Let's say it lists 1.2.3.4 as an IP address.
dig +norecurse -b0.0.0.0#5353 news.ycombinator.com @1.2.3.4
And you should receive the IP address for news.ycombinator.com, or at least your next clue where to look (if the DNS admin has chosen to play games with CNAME).
This method can be automated.
Your ISP is not "intercept[ing] all DNS requests". You are sending your requests to your ISP's recursive DNS servers (why?), and those servers are feeding you whatever information the ISP chooses. Go figure, they are sending you bogus info to inject advertising. Solution: Stop sending your requests to your ISP's recursive DNS servers (or any third party recursive DNS servers). Send your requests to your own recursive DNS server running on 127.0.0.1, or send nonrecursive requests to authoritative DNS servers only.
Did you even read his comment?
"dig @www.facebook.com news.ycombinator.com" does not use the ISP's DNS servers at all. It sends a DNS query to Facebook for Google, which should normally fail. His ISP hijacks the request and provides a response. In this scenario, the advice in your comment is pointless because they will hijack requests whether they are directly to authoritative servers or if they are to recursive servers.
"dig @www.facebook.com news.ycombinator.com" does not use the ISP's DNS servers at all. It sends a DNS query to Facebook for Google, which should normally fail. His ISP hijacks the request and provides a response. In this scenario, the advice in your comment is pointless because they will hijack requests whether they are directly to authoritative servers or if they are to recursive servers.
Yes, I read his comment.
""dig @www.facebook.com news.ycombinator.com" does not use the ISP's DNS servers at all"
Incorrect. The program he's using, dig, has to look up the numbers for facebook.com's authoritative servers first. And what DNS servers do you think it uses to do that? The defaults he has set: his ISP's.
"It sends a DNS query to Facebook for Google."
Incorrect again.
The "advice" I provided is not pointless. I would not provide pointless suggestions.
""dig @www.facebook.com news.ycombinator.com" does not use the ISP's DNS servers at all"
Incorrect. The program he's using, dig, has to look up the numbers for facebook.com's authoritative servers first. And what DNS servers do you think it uses to do that? The defaults he has set: his ISP's.
"It sends a DNS query to Facebook for Google."
Incorrect again.
The "advice" I provided is not pointless. I would not provide pointless suggestions.
"What aren't you getting?"
I am glad you asked. I am not getting what it is you are trying to say. I also do not get why you keep mentioning Google.
"The query for Facebooks server may use the ISPs DNS server, but that's not the problem."
Why is that not the problem?
If you query the ISP's DNS servers, then the ISP can send you bogus answers. By giving you bogus answer they can redirect your HTTP requests, which enables them to insert ads, among other things. I presume you would want to avoid this. I gave examples how you could do that. One way is to run your own recursive DNS server on 127.0.0.1. Another is to only query the proper authoritative servers.
Shaw uses a "DNS Redirect service". Customers can opt out.
https://community.shaw.ca/docs/DOC-1218
Even if a customer does not disable this "service", I believe Shaw will not interfere with packets sent to remote DNS servers other than Shaw's.
In any event, the reason I commented on this was because (unless the customer has changed his defaults)
dig @www.facebook.com news.ycombinator.com
sends queries to Shaw's DNS servers. So stop doing this.
Unless the customer opts out, these queries are going to get redirected.
If you wanted to test your theory (that Shaw is redirecting every DNS packet sent by evey customer, even ones not using Shaw's DNS servers), then the above invocation of dig will not test this. It sends queries to the Shaw DNS servers. Stop doing that.
Why does it send queries to Shaw's DNS servers? From the dig(1) manpage:
"SIMPLE USAGE A typical invocation of dig looks like:
If for some reason you wanted to send a query for news.ycombinator.com to the IP address for www.facebook.com (without using any recursive DNS servers like Shaw's which could give you bogus answers), then
dig +norecurse @31.13.75.17 news.ycombinator.com
would be the appropriate way to do it, assuming you choose to use dig.
I am glad you asked. I am not getting what it is you are trying to say. I also do not get why you keep mentioning Google.
"The query for Facebooks server may use the ISPs DNS server, but that's not the problem."
Why is that not the problem?
If you query the ISP's DNS servers, then the ISP can send you bogus answers. By giving you bogus answer they can redirect your HTTP requests, which enables them to insert ads, among other things. I presume you would want to avoid this. I gave examples how you could do that. One way is to run your own recursive DNS server on 127.0.0.1. Another is to only query the proper authoritative servers.
Shaw uses a "DNS Redirect service". Customers can opt out.
https://community.shaw.ca/docs/DOC-1218
Even if a customer does not disable this "service", I believe Shaw will not interfere with packets sent to remote DNS servers other than Shaw's.
In any event, the reason I commented on this was because (unless the customer has changed his defaults)
dig @www.facebook.com news.ycombinator.com
sends queries to Shaw's DNS servers. So stop doing this.
Unless the customer opts out, these queries are going to get redirected.
If you wanted to test your theory (that Shaw is redirecting every DNS packet sent by evey customer, even ones not using Shaw's DNS servers), then the above invocation of dig will not test this. It sends queries to the Shaw DNS servers. Stop doing that.
Why does it send queries to Shaw's DNS servers? From the dig(1) manpage:
"SIMPLE USAGE A typical invocation of dig looks like:
dig @server name type
where:
server
is the name or IP address of the name server to query. This can be
an IPv4 address in dotted-decimal notation or an IPv6 address in
colon-delimited notation. When the supplied server argument is a
hostname, dig resolves that name before querying that name server.
If no server argument is provided, dig consults /etc/resolv.conf
and queries the name servers listed there. The reply from the name
server that responds is displayed.If for some reason you wanted to send a query for news.ycombinator.com to the IP address for www.facebook.com (without using any recursive DNS servers like Shaw's which could give you bogus answers), then
dig +norecurse @31.13.75.17 news.ycombinator.com
would be the appropriate way to do it, assuming you choose to use dig.
Thanks for the explanation. Would you interpret these results as supporting evidence of my claim?
$ dig +short chaos txt version.bind @31.13.75.17
"PowerDNS Recursor 3.5.3 $Id$"
Your claim was they are proxying "all" port 53 traffic.
In effect, you are saying no customer can query any DNS server except Shaw's.
That sounds a bit extreme.
I have more questions. Can you run some tests?
You say you use DNSCrypt. Can you try it with port 53? Maybe something like
Now, without DNSCrypt, can you try using djbdns? For me at least, it is easier to understand what the software does. dig and the BIND libraries are far too complex for my liking.
Compile or get binaries for djbdns and use dnsq(1).
Finally, compile or get binaries for drill(1) from NLnet Labs.
I know that some ISP's block all traffic sent to port 25. But they have a compelling reason and hence a justification for doing that. Not true with proxying traffic to port 53. There's no harm in customers using DNS servers besides Shaw's.
In effect, you are saying no customer can query any DNS server except Shaw's.
That sounds a bit extreme.
I have more questions. Can you run some tests?
You say you use DNSCrypt. Can you try it with port 53? Maybe something like
dnscrypt-proxy --resolver-port=53
dnscrypt-proxy --resolver-port=53 --tcp-only
Now, without DNSCrypt, can you try using djbdns? For me at least, it is easier to understand what the software does. dig and the BIND libraries are far too complex for my liking.
Compile or get binaries for djbdns and use dnsq(1).
dnsq a news.ycombinator.com 31.13.75.17
Finally, compile or get binaries for drill(1) from NLnet Labs.
drill -t news.ycombinator.com @31.13.75.17
echo ". 1 in ns a.root.servers.net." > 1.tmp
echo "a.root.servers.net. 1 a 198.41.0.4" >> 1.tmp
echo > 2.tmp
drill -4ord -r1.tmp -tc2.tmp news.ycombinator.com @31.13.75.17
I know that some ISP's block all traffic sent to port 25. But they have a compelling reason and hence a justification for doing that. Not true with proxying traffic to port 53. There's no harm in customers using DNS servers besides Shaw's.
I've done some more tests [1] as you suggested. It looks like Shaw is routing all UDP/53 traffic to their DNS servers; I'd not considered TCP earlier. My optimistic guess as to their motivation for using such an invasive technique is that it was easy for them to deploy.
[1]: https://gist.github.com/0998a0dd2c0abca91c8bPersonally, I do not use DNS much at all except to do periodic bulk lookups for new domains I might visit.
I store all the DNS info I'll ever use[1] in .cdb files and also in my /etc/hosts file.
I do this for speed reasons, because HOSTS or tinydns on 127.xxx.xxx.xxx is always faster than DNS. But if I had an ISP like yours, it would be a necessity for other reasons.
Shaw is actually interfering with their customers' ability to lookup IP numbers. This is the most basic of all internet services.
And no one is complaining?
Anyway, you could do bulk lookups with TCP and then store the DNS info locally. That could reduce if not elimibate your need for DNS.
I've always thought that there should be DNS servers that can handle pipelined TCP queries, and this is one reason why.
If the idea of bulk lookups and not using DNS otherwise sounds intriguing and you want some examples of scripts to do bulk lookups, e.g. for HN sites, let me know. It sounds like you could really benefit from reducing your dependence on DNS.
1. For example, all the IP addresses for sites that appear on HN.
I store all the DNS info I'll ever use[1] in .cdb files and also in my /etc/hosts file.
I do this for speed reasons, because HOSTS or tinydns on 127.xxx.xxx.xxx is always faster than DNS. But if I had an ISP like yours, it would be a necessity for other reasons.
Shaw is actually interfering with their customers' ability to lookup IP numbers. This is the most basic of all internet services.
And no one is complaining?
Anyway, you could do bulk lookups with TCP and then store the DNS info locally. That could reduce if not elimibate your need for DNS.
I've always thought that there should be DNS servers that can handle pipelined TCP queries, and this is one reason why.
If the idea of bulk lookups and not using DNS otherwise sounds intriguing and you want some examples of scripts to do bulk lookups, e.g. for HN sites, let me know. It sounds like you could really benefit from reducing your dependence on DNS.
1. For example, all the IP addresses for sites that appear on HN.
Super shady stuff. I never rely on any ISP provided DNS servers
8.8.8.8 and 8.8.4.4 are anycast.
You don't trust your ISP, so you go for the one company whose entire profit model is build around ads and profiling their users, and who is known to cooperate (willingly and/or unwillingly) with the NSA in their logging programs? I'm not sure that's the right response...
If the NSA is your adversary, you should not be using DNS at all.
I don't see how this necessarily helps.
Edit: I did a little research on CDN resolution back in undergrad. One of the things that was most difficult to measure, or even define, was DNS "performance."
Just because Google anycasts its DNS network does not guarantee the best performance. Running namehelp[1] on many machines I often found that the "fastest" DNS server was not in the obvious set of DNS servers that you use.
So I guess the answer to the parent's question is: yes, possibly, but it's hard to define what "fastest" even means here. I would say that jrockway's response is even incorrect in his (implied) definite assertion that it cannot degrade your experience. If you want to know, you should measure from your endpoint. There is no other way.
[1] http://aqualab.cs.northwestern.edu/projects/namehelp
Edit: I did a little research on CDN resolution back in undergrad. One of the things that was most difficult to measure, or even define, was DNS "performance."
Just because Google anycasts its DNS network does not guarantee the best performance. Running namehelp[1] on many machines I often found that the "fastest" DNS server was not in the obvious set of DNS servers that you use.
So I guess the answer to the parent's question is: yes, possibly, but it's hard to define what "fastest" even means here. I would say that jrockway's response is even incorrect in his (implied) definite assertion that it cannot degrade your experience. If you want to know, you should measure from your endpoint. There is no other way.
[1] http://aqualab.cs.northwestern.edu/projects/namehelp
Interesting, just tried out namehelp.
It told me my the fastest option for me was Dyn's servers, but those have unacceptable to me anti-spyware "safe mode" blockouts. #2 on its list was Google DNS which I was already using.
The graphs for HTTP performance said namehelp's choices were degrading my performance on average by 11ms.
Good app to add to the toolchest though. It'll be interesting to try it out when I travel.
It told me my the fastest option for me was Dyn's servers, but those have unacceptable to me anti-spyware "safe mode" blockouts. #2 on its list was Google DNS which I was already using.
The graphs for HTTP performance said namehelp's choices were degrading my performance on average by 11ms.
Good app to add to the toolchest though. It'll be interesting to try it out when I travel.
And GOOG-owned. Spam from a small-scale ISP, or tracking by a big ad firm? You lose either way.
https://developers.google.com/speed/public-dns/privacy
"We built Google Public DNS to make the web faster and to retain as little information about usage as we could, while still being able to detect and fix problems. Google Public DNS does not permanently store personally identifiable information."
"We built Google Public DNS to make the web faster and to retain as little information about usage as we could, while still being able to detect and fix problems. Google Public DNS does not permanently store personally identifiable information."
"personally identifiable"
What other expectations for a DNS server do you have? If you do a lookup for example.com's A record, it's going to know that someone looked up the A record for example.com.
As I mention in a related comment, if you're worried about the NSA knowing what websites you visit, you must not use TCP/IP. TCP/IP has no provision for obscuring the source and destination of packets; you have to add that at another layer.
(To wax philosophical, it seems that we're outgrowing the Internet. Nobody was worried about protecting their browsing history from their ISP or the government when the Internet was designed, so when we start talking about "if you use XXX service, the NSA can find out", that's true of pretty much everything except for things specially designed to hide browsing history from the NSA. Even those can be suspected to be compromised, meaning you shouldn't even be here commenting if you're truly worried about what information a DNS server might collect from you.)
As I mention in a related comment, if you're worried about the NSA knowing what websites you visit, you must not use TCP/IP. TCP/IP has no provision for obscuring the source and destination of packets; you have to add that at another layer.
(To wax philosophical, it seems that we're outgrowing the Internet. Nobody was worried about protecting their browsing history from their ISP or the government when the Internet was designed, so when we start talking about "if you use XXX service, the NSA can find out", that's true of pretty much everything except for things specially designed to hide browsing history from the NSA. Even those can be suspected to be compromised, meaning you shouldn't even be here commenting if you're truly worried about what information a DNS server might collect from you.)
"does not permanently store personally identifiable information"
If your employer gave a shit, this would read: "does not store information". But it doesn't, and they don't, and you're a cheap shill.
If your employer gave a shit, this would read: "does not store information". But it doesn't, and they don't, and you're a cheap shill.
No. For example you set up your own resolvers and use those for your network's DNS needs. The source IP's from your resolvers recursive requests will be used to help CDNs and other geo-aware resolvers send you to the nearest appropriate site.
I think you would be hard pressed to find a public well known service that is depended on ISP CDNs.
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.
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.
No, good public DNS servers (like Google's) forward your subnet to the resolver to ensure that you get correct responses: https://en.wikipedia.org/wiki/Content_delivery_network#edns-...
"I will continue to monitor periodically their DNS entries and compare them with other public DNS servers."
This would make for a great watchdog site to provide visibility across different ISPs (and could also discourage other ISPs from pulling this crap).
This would make for a great watchdog site to provide visibility across different ISPs (and could also discourage other ISPs from pulling this crap).
I think so too, though CDN's will mess with the results a bit. It would be nice if DNS had a way to sign/validate/somehow know the record you got was correct. Especially on the apex record as it can happen before ssl.
It's interesting no one brought up DNSSEC[1]. Has anything happened there since 2010?
1. http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...
1. http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...
DNSSEC is great in theory, but after three years I still haven't deployed a live instance.
It is cumbersome to implement and maintain, requiring co-operation of registrars and frequent key regeneration.
It is also very, very chatty and imposes a considerable processing burden on the first-hop DNS resolver.
We need a signed DNS solution that isn't DNSSEC.
It is cumbersome to implement and maintain, requiring co-operation of registrars and frequent key regeneration.
It is also very, very chatty and imposes a considerable processing burden on the first-hop DNS resolver.
We need a signed DNS solution that isn't DNSSEC.
I was going to mention it, but I haven't found anyone using it or a usable implementation.
CDNs will indeed mess with the results, but it would still likely be possible to tell the difference between a legitimate result and a forged one, especially if you know something about the CDN structures used by major site. And the more people run it, the more likely you can detect anomalies, much like Perspectives does for SSL.
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).
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).
http://perspectives-project.org/
Perspectives is a new approach to helping computers communicate securely on the Internet. With Perspectives, public “network notary” servers regularly monitor the SSL certificates used by 100,000s+ websites to help your browser detect “man-in-the-middle” attacks without relying on certificate authorities.
Perspectives is a new approach to helping computers communicate securely on the Internet. With Perspectives, public “network notary” servers regularly monitor the SSL certificates used by 100,000s+ websites to help your browser detect “man-in-the-middle” attacks without relying on certificate authorities.
Isn't that exactly what DNSSEC is? Unfortunately not all that many domains are using it today.
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.
Strangely enough, the largest deployment of DNSSEC-enabled, customer-facing, recursive/caching nameservers in the United States is... Comcast. That's right, the same Comcast that, back in 2009, hijacked NXDOMAIN responses by default and returned A records pointing to servers that served up advertisement-laden search pages over http.
I was also impressed to see that my Comcast connection uses IPv6. Turns out they have (or will have) one of the the largest IPv6 network in the world - http://gigaom.com/2013/11/27/comcast-xfinity-broadband-is-no...
Comcast's IPv6 network for content from Netflix or YouTube is actually better than using IPv4. A while back I set up an IPv6 only machine just to see the difference, and it is night and day.
That being said, their network still leaves something to be desired, the IPv6 routes taken to get to the same IPv6/IPv4 host can sometimes be circuitous and I have noticed that they have a higher latency too. So there are upsides and downsides, but I hope it can only get better with time!
That being said, their network still leaves something to be desired, the IPv6 routes taken to get to the same IPv6/IPv4 host can sometimes be circuitous and I have noticed that they have a higher latency too. So there are upsides and downsides, but I hope it can only get better with time!
Sadly DNSSEC kinda sucks. Here's some earlier discussion on HN, with a lot of links. (Namedrop: tptacek is against DNSSEC and talks about it in the link.)
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.
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.
DNScrypt only protects from your host to your nameserver. Your nameserver can still be poisoned as it queries other nameservers.
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.
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.
"protects against DNS interception by my ISP"
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.
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.
>All you've done is add an additional third party that can view and log what you're doing.
You forgot the part where it's protecting against trashy ISPs like the one in this article.
You forgot the part where it's protecting against trashy ISPs like the one in this article.
I did not forget that. The privacy lost is worse than the supposed "protection" gained by using DNSCrypt. "Trashy" ISPs can (and do) still intercept and modify the HTTP traffic even if they can't intercept and modify the DNS traffic.
Is there a way we can choke companies like Apira by making a concerted distributed effort to disrupt the referral programs they exploit (either by reporting them or by feeding them false referrals somehow)?
Agree with this sentiment, but I think the effort would be better spent taking steps to switch to trusted DNS providers, as well as building layperson tools to monitor them.
Here it goes:
Behind a ISP-wide cache.
Any 'traceroute' passes by transtelco.net (ISP used to have their own infraestructure for voip services Megafon) now i have 5/6? DNS jumps! and all my traffic going to Transtelco.
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
As long as they don't tamper with the data I think an HTTP cache is perfectly OK. HTTP has loads of built-in mechanism for that kind of caching. It saves bandwidth upstream, not least for website owners, and may make your web browsing speed faster if the proxy is good.
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.
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.
Some of the big content providers like Netflix are even reportedly making caching deals for their content. Both the content provider and the ISP get better performance and less exterior bandwidth.
[deleted]
One a slightly related note, in Chrome extensions, it's possible to redirect DNS requests on a per-URL basis. This is how Media Hint works to allow non-US Netflix users access the US version of the site.
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.
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.
> I'm surprised we haven't seen similar behaviour from Chrome extensions
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.
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.
Over the holiday I did usual, fix/clean my grandmother's computer. She's been using chrome because I explained to her how much safer it is.
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.
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.
I had an extension that did that as well. I reported it to Amazon and left a 1 star review warning other users.
Interestingly, you might have benefitted more from keeping quiet about this. While the original retailers are losing money through this, you aren't really affected negatively by them doing it. In fact, with this additional revenue source, they might be able to support thinner margins on their broadband charges, saving you some money. You did the morally correct thing, but perhaps at a potential personal cost.
The affiliates are getting hurt hugely though. Affiliate profits are supposed to be for helping the purchase - through marketing efficiency. The ISP is doing none of that, they are simply mafiosoing affiliate dollars through hijack. Amazon would not like this, the ISP gives exactly 0% efficiency boost to the e-commerce process, they're just a gypsie snake.
Why did you have to end an otherwise good answer with a racist slur?
Why have you failed to visit an abortion clinic yet? You're not fit for children.
Gypsy: "An itinerant person or any person suspected of making a living from dishonest practices or theft; a member of a nomadic people, not necessarily Romani; a carny."
Gypsy: "An itinerant person or any person suspected of making a living from dishonest practices or theft; a member of a nomadic people, not necessarily Romani; a carny."
>you aren't really affected negatively by them doing it.
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.
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.
I'd like to try out this curl command. I'm not using macports, though. Like many people, I've switched to brew since some time. Is there a quick way to see if my curl install is compiled with 'ares' whatever that is?
ports > brew!
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...
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-aresAlso looks like MacOS 10.9 has ares by default.
Anyone know if Time Warner Cable does this?
+1 to OP, and +2 to companies who responded positively (and -3 to ISP, obviously)
Congratulations. What they were doing was absolutely evil in my opinion.
This is why you should encrypt your DNS.
Do you have a link to a usable encrypted DNS solution? I searched but didn't find anything actively used, but a lot of proposals.
DNSCrypt http://www.opendns.com/technology/dnscrypt/
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 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.
Better page: http://dnscrypt.org
You can easily setup a VPN and use the DNS servers on the other side. Connecting to the VPN can be done via IP.
[deleted]
Could you elaborate on this? How would encryption help? The DNS server would need to decrypt the request in order to service it.
VPN + HTTPS just for good measure
VPN + HTTPS for good measure