4 ms·
"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
by 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 agoWhen 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).
- aendruk 13y agoThanks 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.
- gwu78 13y agoYour 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.