6 ms·

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 Goo

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]
gwu78 13y ago
"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 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.
- ars_technician 13y ago
  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).

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]

gwu78 13y ago

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

ars_technician 13y ago
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).