Live data from Hacker News

I fought my ISP's bad behavior and won

erichelgeson.github.io

111–115 of 115 posts

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

#111
post #108

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…

"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 enab…

When you run dig @www.facebook.com news.ycombinator.com, it must query the default DNS for www.facebook.com; however, the ISP must return the real IP for www.facebook.com or the HTTPS establishment will fail because they cannot MiTM that connection.

So now dig has the actual IP for www.facebook.com, which it is now going to use for it's DNS query for news.ycombinator.com. The commenter observed this query is intercepted because it works (which it shouldn't).

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

#112
post #108

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…

"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 enab…

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$"
This happens despite having opted out via the form you mentioned.

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

#113
post #108

Earlier quoted context omitted.

"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 enab…

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$" This happens despite having opted out via the form you mentioned.

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

  dnscrypt-proxy --resolver-port=53
and

  dnscrypt-proxy --resolver-port=53 --tcp-only
DNSCrypt is built using public domain software written by a maths professor: namely, djbdns and curvecp.

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
If you get no response immediately, wait at least 60 seconds for a time out.

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'm genuinely curious about your situation. Shaw is no doubt playing games with their DNS, but I'm still not convinced they are "proxy[ing] all port 53 traffic".

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.

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

#114
post #113

Earlier quoted context omitted.

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$" This happens despite having opted out via the form you mentioned.

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 dnscrypt-proxy --resolver-port=53 and dnscrypt-proxy --resolver-port=53 --tcp-only DNSCrypt is built using public domain software writte…

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/0998a0dd2c0abca91c8b

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

#115
post #113

Earlier quoted context omitted.

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 dnscrypt-proxy --resolver-port=53 and dnscrypt-proxy --resolver-port=53 --tcp-only DNSCrypt is built using public domain software writte…

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/0998a0dd2c0abca91c8b

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

Post reply on HN