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.
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.
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.
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.
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.
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 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:
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.
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.
"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"
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
"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."
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.)
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.
Comments
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.
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/
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.
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.
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.
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 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:
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.
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.
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.
"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.
Thanks for the explanation. Would you interpret these results as supporting evidence of my claim?
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
and 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).
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.
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.
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.
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.
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-...
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.
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
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.
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."
"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.)
"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.
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.