Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I fought my ISP's bad behavior and won

erichelgeson.github.io

Post reply on HN
Print view View original

101–110 of 115 posts

Re: I fought my ISP's bad behavior and won

#101

Post by ars_technician »

neil_s wrote: post #36

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.

>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.

Re: I fought my ISP's bad behavior and won

#102

Post by jauer »

click170 wrote: post #54
jauer wrote: post #40

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 mo…

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.

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.

Re: I fought my ISP's bad behavior and won

#103

Post by mike-cardwell »

ars_technician wrote: post #99
mike-cardwell wrote: post #92

Earlier quoted context omitted.

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…

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.

"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.

Re: I fought my ISP's bad behavior and won

#104

Post by mike-cardwell »

ars_technician wrote: post #98
mike-cardwell wrote: post #93

Earlier quoted context omitted.

"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.

>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.

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.

Re: I fought my ISP's bad behavior and won

#105

Post by gwu78 »

ars_technician wrote: post #100
gwu78 wrote: post #97

Earlier quoted context omitted.

All 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…

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 serv…

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.

Re: I fought my ISP's bad behavior and won

#106

Post by goldenkey »

emilv wrote: post #95
goldenkey wrote: post #42

Earlier quoted context omitted.

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."

Re: I fought my ISP's bad behavior and won

#107

Post by ars_technician »

gwu78 wrote: post #105
ars_technician wrote: post #100

Earlier quoted context omitted.

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 serv…

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 pointl…

What aren't you getting? The query for Facebooks server may use the ISPs DNS server, but that's not the problem. It's when dig's request is actually sent to that resolved address that the ISP intercepted the request.

That's exactly what that dig '@' symbol does. Why are you contending the very basic functionality of dig? Instead of a glib remark devoid of any evidence, I will provide you a link so you can understand. Read the first line of the synopsis of the man page: http://linux.die.net/man/1/dig

The server after the @ symbol is the one the DNS query for 'Google.com' is sent to, which is the IP address of www.facebook.com. That is the packet that is being hijacked. Get it?

Re: I fought my ISP's bad behavior and won

#108

Post by gwu78 »

ars_technician wrote: post #100
gwu78 wrote: post #97

Earlier quoted context omitted.

All 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…

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 serv…

"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:

            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.

Re: I fought my ISP's bad behavior and won

#109

Post by [deleted] »

gwu78 wrote: post #105
ars_technician wrote: post #100

Earlier quoted context omitted.

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 serv…

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 pointl…

[deleted]

Re: I fought my ISP's bad behavior and won

#110

Post by [deleted] »

gwu78 wrote: post #105
ars_technician wrote: post #100

Earlier quoted context omitted.

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 serv…

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 pointl…

[deleted]
Post reply on HN