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.
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.
> 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.
(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.
Just make sure its not configured to be a public resolver, and only allow local network or whitelisted addresses.