Hacker News Reader

Comment by belorn | Hacker News Reader

It is times like this that I recommend technically inclined people to try setting up your own dns resolver and see how minimal impact a few/handful of milliseconds on first access has on the internet experience. Practically all popular domains also uses some form of anycast network, so the benefit of a single large shared resolver that caches the dns answers has steadily decreased each year.

Just make sure its not configured to be a public resolver, and only allow local network or whitelisted addresses.

View on HN

Setting up your own recursive DNS resolver to circumvent ISP blocks is pointless unless you do so on a VPS or something, because otherwise, your ISP will just hijack the recursive queries it makes. And DNSSEC doesn't help if the ISP just wants to block you from learning the real IP.

I’ve heard this before. Is there a way to reliably detect if this is occurring or case studies of where this has occurred?

Edit: I assume dns over https prevents this also, right?

DNSSEC would reveal that it's happening straight away, but that doesn't get you the IP address.

Of course, as mentioned putting your recursive DNS server on a cheap VPS somewhere that doesn't hack your connection would.

Yes, DoH prevents that, unless the DoH provider is in on it too, which most of the major ones are now, as this article is about.

There are lots of providers that aren’t CloudFlare/Google/etc: https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-av...

(There’s lots of smaller providers, but lots operated by governments, ccTLD administrators, and other major organizations)

I only bring this up because the idea that the major providers “are” the internet is the only reason this is a possible and a problem in the first place.

> your ISP will just hijack the recursive queries it makes

This level of deep packet inspection and injection is not what ISPs commonly do in my experience. At this point, it is much easier to just block the service's IP addresses than deep-inspect DNS traffic and match the query identifier and stuff to inject a false response. Why spend that engineering time when people will just fix the DNS server and can access the site directly? Might as well force people to set up a full tunnel (such as a VPN) to bypass the block, if your ISP or court order shows this level of motivation anyway.

Insofar as I've experienced these things: fetching the mapping yourself, from a server not operated by your ISP, will circumvent DNS blocks your ISP was ordered to put in place.

Currently I've got live access to one such blocking mechanism:

   $ dig +short thepiratebay.org
   195.121.82.125
   $ dig +short +trace thepiratebay.org | tail -1
   A 162.159.137.6 from server 172.64.35.164 in 5 ms.

The +trace option makes dig trace the delegations from root server ("who is .org?") until authoritative answer ("who is piratebay.org?"), basically this makes it a recursive resolver whereas in the default case it just asks your configured nameserver.

The first IP address is a block page (accessible from outside the network, if anyone wants to take a look), the second one of the real IP addresses

> At this point, it is much easier to just block the service's IP addresses than deep-inspect DNS traffic and match the query identifier and stuff to inject a false response. Why spend that engineering time when people will just fix the DNS server and can access the site directly?

Because IP addresses can change frequently, and also because if a site is behind a CDN, that would cause a lot of collateral damage.

> The first IP address is a block page (accessible from outside the network, if anyone wants to take a look), the second one of the real IP addresses

Okay, so your ISP's particular blocking mechanism doesn't hijack recursive queries. But others do.

Could you give a example of such ISP? I have seen ISP block all DNS traffic beyond to their own server, but those have been fairly locked networks like hotel wifi. It is much cheaper, safer, and less fragile to just block everything and force customers to the isp own servers. DPI and traffic injection carries risk of false positives and minor engineering mistakes can create large support costs, and would really only be beneficial if the intention is to hide the fact of the block.

> It is much cheaper, safer, and less fragile to just block everything and force customers to the isp own servers.

Sure, that's common too. But that also precludes you from running your own recursive resolver to circumvent their blocks.

DJB was right.

This was a big surprise for me when I set up a local DNS for work. Everything suddenly felt much snappier.

https://docs.pi-hole.net/guides/dns/unbound/

Reply on news.ycombinator.com