How One Man Fought His ISP's Bad Behavior and Won 181
An anonymous reader writes "Eric Helgeson documents his experience with an unscrupulous ISP that was injecting affiliate IDs into the URLs for online retailers. 'It appears that the method they were using was to poison the A record of retailers and do a 301 redirect back to the www cname. This is due to the way apex, or 'naked' domain names work.' Upon contacting the ISP, they offered him access to two DNS servers that don't perform the injection, but they showed no indication that they would stop, or opt-out any other subscribers. (It was also the only wireless provider in his area, so he couldn't just switch to a competitor.) Helgeson then sent the data he gathered to the affiliate programs of major retailers on the assumption that they'd be upset by this as well. He was right, and they put a stop to it. He says, 'ISP's ask you to not do crummy things on their networks, so how about they don't do the same to their customers?'"
Comment removed (Score:5, Informative)
Re: Use public DNS (Score:4, Informative)
Personally use 4.2.2.[1-6]
I think they are provided by Level 3. Get great response time here in the Canadian Prairies.
I've never trusted my ISP's DNS servers.
Not wireless (Score:5, Informative)
(It was also the only wireless provider in his area, so he couldn't just switch to a competitor.)
No, the blog says:
You may be asking why don’t I switch ISPs? Well they are the only one besides a wireless provider in my area.
Which means there are 2 ISPs. The one he's using is not wireless, and the other one is wireless.
Re:Use public DNS (Score:5, Informative)
You can try this [google.com] tool to check your existing DNS for performance and behaviour. Google's is very well behaved by the way, so please don't spread FUD.
Re:Use public DNS (Score:5, Informative)
I should add that both Google DNS and OpenDNS support DNS-SEC which is nice as well. OpenDNS also supports a form of DNS request encryption which hides even the sites you go to.
Re:Use public DNS (Score:2, Informative)
Other dns servers as well.
Cisco
128.107.241.185
192.135.250.69
Verizon (Level3) Nameservers
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
SpeakEasy Nameservers
66.93.87.2
216.231.41.2
216.254.95.2
64.81.45.2
64.81.111.2
64.81.127.2
64.81.79.2
64.81.159.2
66.92.64.2
66.92.224.2
66.92.159.2
64.81.79.2
64.81.159.2
64.81.127.2
64.81.45.2
216.27.175.2
66.92.159.2
66.93.87.2
ORSC Public Access DNS Nameservers
199.166.24.253
199.166.27.253
199.166.28.10
199.166.29.3
199.166.31.3
195.117.6.25
204.57.55.100
Sprintlink General DNS
204.117.214.10
199.2.252.10
204.97.212.10
Comcast
75.75.75.75
75.75.75.76
Never know when a server will be unreachable. It's nice to have a list saved locally you can lookup.
Re:Illegal behavior (Score:3, Informative)
It would have been better to contact FBI and report this fraud. Whoever the hell runs fwdsnp.com needs to spend some time in jail.
This isn't just plain fraud, it's wire fraud [cornell.edu]. The penalty for it is up to 20 years in prison.
Re:Use public DNS (Score:2, Informative)
The privacy policy for Google Public DNS is different than that for the rest of Google. It's also public. You can, you know, read it, then you can stop spreading FUD. https://developers.google.com/speed/public-dns/privacy
Re:Illegal behavior (Score:4, Informative)
I think you are confused.
It was a CORPORATION that was scamming money out of affiliate links, so everything is A-OK!
Of course, we punish the little people for exactly the same thing:
http://www.justice.gov/usao/can/news/2012/2012_06_19_kennedy.sentenced.press.html
Both Amazon and other affiliates (Score:5, Informative)
First of all, Amazon doesn't get a very high percentage of affiliate tagged traffic/purchases. If every ISP would do this, it would get 100% and the whole business model wouldn't work any more. Amazon would have to pay out way too many affiliate bonuses. Second, any affiliate that the user might choose, would lose out because their tag would get replaced by that of the ISP.
Re:Use public DNS (Score:4, Informative)
If a DNS reply passes DNSSEC validation, I can be confident the response is what the zone administrator wanted it to be and it hasn't been tampered with. DNSCurve provides no such assurance.
Widespread DNSSEC and client-side validation would kill OpenDNS's business model, which revolves around tampering with DNS responses. DNSCurve continues to allow them to do this.
Re:What exactly happened? (Score:5, Informative)
Short, simplistic answer: the ISP found a way to fraudulently skim a percentage from online retailers for every purchase made by the ISP customers.
Slightly more detailed answer: the ISP directed users looking for online merchants like "amazon.com" to it's own bogus server. That bogus server then re-directs the user's browser to the merchant's server in such a way the consumer doesn't notice and the merchant thinks the customer is following a product referral from an advertising partner. Thus the ISP collects a kickback intended for people who make product recommendations and referrals, without actually having made any recommendation or referral.
Re:Public DNS considered harmful (Score:4, Informative)
Let's get this misunderstanding sorted out. Because that sentence is indeed describing a non-existent problem. In reality anycast DNS is not part of the problem, it is part of the solution.
/64 for each resolver.
Anycast DNS works by having a large number of resolvers spread throughout the world with the same IP address on each of them. A request from a client to this IP will reach the closest of those resolvers. What happens next is that the resolver will query authoritative servers (unless it already has a cached result). If the request from the resolver to the authoritative server was send using the anycast IP as source IP, it would not work. The reason it would not work is, that the reply from the authoritative server would be sent to the closest resolver, which is not necessarily the same as the one, which is closest to the client. You'd have most replies end up at the wrong resolver, which would simply discard it, as it would look like a failed poisoning attempt.
In order to solve that problem you have to give each of those resolvers two IP addresses. It will have the anycast IP address (which is the same on all servers in the pool) and a unicast IP address, which is different on each of those resolvers. The client will still use the anycast IP in order to send a query to the resolver, but the resolver will then use its unicast IP when sending the request to the authoritative server. That way the reply from the authoritative server will make it back to the correct resolver.
Incidentally this also solves the geolocation problem mentioned. The authoritative servers will indeed see different IP addresses depending on which resolver in the pool the request came through. The content providers just have to figure out the geographic location of each of those resolvers, which is mostly the same they have to do for the resolvers for any ISP. Additionally providers of resolvers such as Google do have an incentive to make this easy to figure out, since that will make their resolvers provide a faster overall experience.
The above is of course slightly simplified, because any well operated resolver is dual stack. That means it need both IPv4 and IPv6 addresses. The anycast addresses can be separate pools such that each resolver has only one anycast address, which is either IPv4 or IPv6. Alternatively you can let one resolver be part of one IPv4 anycast pool and of one IPv6 anycast pool. However the unicast side of these resolvers need to be dual stack, so each resolver needs at least two unicast addresses, one IPv4 and one IPv6.
You could even assign multiple unicast addresses to each resolver. The extra addresses could be used to provide additional protection against poisoning. An attack would then have to not only guess a request ID and port number, but also the IP address. Alas that is really not feasible with IPv4 due to shortage of addresses, but for IPv6 you could easily affort a
If you want to know the IPv6 unicast address of the resolver you are currently using, I have a special domain for that. If you look up the AAAA record for the domain mydnsv6.kasperd.net, it will actually respond with the IPv6 unicast address of the resolver you are using (or server error if the resolver has no IPv6 address). I could have made an identical service to find the IPv4 unicast address of the resolver, but I didn't have a spare IPv4 address to host the authoritative server on.