>you aren't really affected negatively by them doing it.
Even if you are fine with your ISP committing fraud, you are negatively effected by the complexity (points of failure) and latency this adds to the network.
"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.
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.
I did not forget that. The privacy lost is worse than the supposed "protection" gained by using DNSCrypt. "Trashy" ISPs can (and do) still intercept and modify the HTTP traffic even if they can't intercept and modify the DNS traffic.
Interacted with you two days ago and your contribution there was ANOTHER brainless, complete shit one liner. Perhaps its time for you to look for another community?
It's the opinion of any academic philosopher who has ever reviewed her. It also has nothing to do with her individualistic/libertarian view - Nozick, for example, who shares many of the same conclusions wrote a detailed review of her books in which he exposed her arguments and philosophical analysis as barely at an undergraduate level.
One of her greatest sins is her perpetually trashing people like Kant whilst having no idea what theyve said - because she makes many of the very same points. pg does this too.
I would like to believe I would be the one trying to stop them. But, frankly, I've never had a loaded weapon pointed at my face. No one knows how they're going to respond with death knowing at their door. It's something you have to experience.
Do you not think someone would spot them sawing the door open? Also keep in mind that pilots are FLYING THE AIRPLANE. They can just start to do maneuvers that would make it impossible for attackers to even stay at the cockpit door, let alone take it apart.
"About twenty minutes after takeoff, as the flight crew carried on a casual conversation, Calloway entered the flight deck and commenced his attack. Every member of the crew took multiple hammer blows which fractured [the flight crew's] skulls. A lengthy struggle ensued with the flight engineer and captain as Tucker, also an ex-Navy pilot, performed extreme aerial maneuvers with the aircraft, at times flying upside down, with the intent to keep the hijacker off-balance."
Even if you are fine with your ISP committing fraud, you are negatively effected by the complexity (points of failure) and latency this adds to the network.