5 ms·

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 si

by aendruk 13y ago

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. [1]: Shaw Communications, chosen by the landlord. [2]: http://dnscrypt.org/

mhurron 13y ago
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.
- aendruk 13y ago
  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.com
  - gwu78 13y ago
    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 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.
    - ars_technician 13y ago
      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.
      - gwu78 13y ago
        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.
        ars_technician 13y ago
        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 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?
        deleted 13y ago
        [deleted]
        deleted 13y ago
        [deleted]
      - 13y ago
mike-cardwell 13y ago
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.
- ars_technician 13y ago
  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.
  - mike-cardwell 13y ago
    "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.

by aendruk 13y ago

mhurron 13y ago

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.

aendruk 13y ago
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.com
- gwu78 13y ago
  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 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.
  - ars_technician 13y ago
    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.
    - gwu78 13y ago
      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.
      - ars_technician 13y ago
        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 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?
      - deleted 13y ago
        [deleted]
      - deleted 13y ago
        [deleted]
    - 13y ago

mike-cardwell 13y ago

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.

ars_technician 13y ago
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.
- mike-cardwell 13y ago
  "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.