Nothing about the site changed. The only difference is which resolver answered the question, and the rules that resolver was told to follow for your region.
A DNS answer is not a fixed fact written somewhere. It is a reply computed for the person asking, by the resolver they happen to be using. Change the resolver, and you can change the answer, including changing it to nothing.
Why the resolver is the lever
Every connection begins with a lookup, as how DNS actually works lays out: before your device can reach a site, it has to turn the name into an address. Whoever answers that question controls whether you get a usable address at all. That is what makes the resolver such an attractive control point. There is no need to inspect your traffic, break encryption, or block a range of addresses. Refuse the lookup, or answer it falsely, and the connection never even starts.
By default, the resolver answering your questions is the one your ISP handed you when you connected. It sits inside their network, under their jurisdiction, and does whatever the law and their policy require. When a regulator orders a site blocked, the cheapest way for an ISP to comply, by far, is to make their resolver stop returning the right answer for that name. This is why most everyday blocking, the court-ordered piracy and gambling lists, the "this site is not available" pages, happens at DNS and nowhere else.
The three ways a DNS block is done
All three are the same move, a resolver declining to hand back the true address. They differ only in what it returns instead, and how visible the block is to you.
| Method | What the resolver returns | How it feels |
|---|---|---|
| NXDOMAIN | "This name does not exist", even though it does | The site simply fails to load, as if it were down or misspelled |
| Redirect / block page | The address of a notice server instead of the real one | You land on a "blocked by order of..." page run by the ISP or regulator |
| Sinkhole | A dead or monitored address that goes nowhere useful | The connection hangs or quietly fails, with no explanation |
This is the same machinery as the ad-blocking you might switch on yourself. The technique is identical; the difference is who chose the list, and whether it was for you or against your wishes.
Why the same name gives different answers in different places
Here is the part that surprises people. A domain does not have one universal answer that everyone in the world receives. The reply you get is shaped by where you are asking from, and that happens for two very different reasons, one ordinary and one deliberate.
The ordinary reason is performance. Big sites are served from many data centres, and DNS is used to send you to a nearby one, so a lookup for the same name legitimately returns a different address in Frankfurt than in Sao Paulo. To do this well, resolvers can attach a rough hint of your location to the question they pass upstream, a feature called EDNS Client Subnet, which forwards a piece of your network address so the far end can pick a close server. It is useful, and it is also why "the same name" is already, quietly, a per-location answer before anyone censors anything. A privacy-minded resolver keeps that hint as coarse as possible or omits it, which is part of what your IP address gives away.
The deliberate reason is policy. Because answers are already computed per region, withholding one for a region is trivial. Your ISP's resolver serves a specific country or area, so it applies that area's blocklist and nobody else's. The result is the everyday experience of geographic blocking: a site that is perfectly reachable one country over returns nothing through your home connection, not because the site treats you differently, but because the resolver between you and it was instructed to, based purely on where it sits.
How to tell it is a DNS block, not a dead site
Geographic DNS blocking has a recognisable signature, because it is tied to which resolver you happen to be using at that moment, not to the site itself:
- It loads on your phone's mobile data but fails on your home Wi-Fi, because the two use different resolvers.
- It works on a friend's network across town but not yours, if they are with a different provider.
- It returns a "blocked by order of..." notice rather than a normal browser error.
- It springs back to life the moment you point your device at an independent resolver.
That last point is the whole tell. If changing the resolver changes whether the site exists, the site was never the problem. The answer was.
What encrypted DNS to an independent resolver changes
Two things, working together. First, you stop asking the resolver that was told to censor. When you point your device at an independent resolver outside your ISP's control, your question goes to a server with no obligation to apply your region's blocklist, so it returns the real address and the site loads. The block was a property of one resolver, and you simply stopped using it.
Second, encryption keeps the ISP from quietly re-imposing the block on the way. With plain DNS, even if you choose another resolver, your provider can read the request as it passes and inject a forged "blocked" reply before the real one arrives, the same trick described in DNS spoofing and cache poisoning. Wrapping the lookup in DoH, DoT, DoQ or DNSCrypt shuts that door: the network can no longer read which name you asked for, so it has nothing to match a forgery against and no clean way to swap the answer.
Together that removes the cheapest and most common form of blocking entirely. For the ordinary court-ordered DNS block, moving your lookups to an encrypted, independent resolver is usually the whole fix.
Where DNS encryption stops, honestly
It would be dishonest to call encrypted DNS a universal way around censorship, so we will not. It beats blocking done at the lookup. A determined censor has other layers, and a serious blocking regime stacks several of them:
- IP blocking. If the network drops traffic to the site's actual address, no amount of fixing the lookup helps; you found the right number, but the road to it is closed.
- SNI filtering. Even over HTTPS, the site name is usually still visible in plain text during the connection handshake, and networks block on it directly. Closing that leak is the job of Encrypted Client Hello, and it has to be supported on both ends.
- Blocking the resolver itself. Some networks block the known addresses or ports of public encrypted resolvers, so the encrypted lookup cannot leave at all.
When blocking moves past DNS like this, the tool that fits is one that relocates your whole vantage point rather than just your lookups, which is the honest case for a VPN, weighed against encrypted DNS in encrypted DNS vs VPN. Encrypted DNS is the right and sufficient answer to lookup-level blocking. It is one layer, and it is upfront about being one layer.
Stop asking the resolver that was told to say no
Point your device at an encrypted, independent resolver. Your lookups leave your provider's control and travel sealed, so the cheapest form of blocking has nothing to act on.
Set up encrypted DNSRelated: what your ISP can still see, what a resolver is, and how DNS actually works.