How to Bypass Blocks Using DNS: Smart DNS, DoH, and Why You Don’t Always Need a VPN.

The site you need is blocked. A colleague says “just use a VPN.” You install it, configure it, your speed drops in half — and then you find out all you needed was to change one DNS server. Two minutes instead of twenty.

Or the opposite: you changed DNS, it still won’t open. You try a VPN — that doesn’t work either. Because there’s DPI involved, and regular VPNs have been blocked for a while.

The difference between these cases is understanding exactly how the block works. Without that, you’re choosing tools blindly.

HOW COUNTRIES BLOCK SITES

Blocking isn’t a single technology. It’s several layers, and each one is harder to bypass than the last.

Level one: DNS blocking. The simplest and most common. The ISP configures its DNS servers to return a wrong answer for blocked domains — either the IP of a stub page saying “site blocked,” or simply NXDOMAIN. Technically the site is running, the IP is reachable — DNS is just lying.

This is how most blocks work in Lithuania, EU countries, and many others. The fix is trivial: switch DNS to 1.1.1.1 or 8.8.8.8 — and the block disappears.

Level two: IP blocking. The ISP blocks not the domain but the actual IP address of the server. DNS can return the correct answer, but packets to that IP never arrive — they get dropped at the routing level. Changing DNS won’t help here. You need a proxy or VPN.

Level three: DPI — Deep Packet Inspection. The ISP analyzes packet contents in real time. It sees not just the destination IP but the specific domain in the SNI field of the TLS handshake, the HTTP Host header, or even traffic patterns. This is how Russia’s TSPU (technical means of countering threats) and China’s Great Firewall work. Against DPI, neither a DNS change nor a regular VPN with an easily identifiable protocol will help. Traffic obfuscation is required.

Level four: URL or content-based blocking. Rare, usually combined with DPI. It blocks not the whole site but specific pages.

A separate issue — ISP DNS hijacking without any government blocklist involved. Many ISPs intercept NXDOMAIN responses (domain doesn’t exist) and instead of returning an error, they serve their own advertising page. You mistype a domain — instead of a standard browser error you see the ISP’s search page. This happens without your knowledge and without any official registry. Fixed by the same DNS switch to 1.1.1.1 or DoH.

Understanding the blocking level is the first step. Without it, you’re choosing tools blindly.

HOW TO IDENTIFY THE BLOCKING LEVEL

Most people jump straight to configuring things. The smarter move is to spend two minutes on diagnosis first. The right tool depends on the type of block, and getting this wrong means spending an hour configuring something that won’t help.

Step one — check DNS. Ask your ISP’s resolver and a public one, then compare the answers:

# Ask the ISP's DNS
dig @ISP_DNS blocked-site.com

# Ask a public DNS
dig @1.1.1.1 blocked-site.com
dig @8.8.8.8 blocked-site.com

Different answers — the ISP is spoofing DNS. Switching resolvers fixes the problem completely, no VPN needed.

Same answers — DNS isn’t the issue. Check direct IP reachability:

curl -v --connect-timeout 5 https://blocked-site.com
traceroute blocked-site.com

Traceroute cuts off at ISP nodes — IP block, you need a proxy or VPN. Connection establishes but immediately resets — DPI, you need obfuscation.

While you’re at it, check for DNS hijacking — whether the ISP is replacing nonexistent domains with ads:

# Query a domain that definitely doesn't exist
dig @ISP_DNS this-domain-definitely-does-not-exist-12345.com
dig @1.1.1.1 this-domain-definitely-does-not-exist-12345.com

The ISP resolver should return NXDOMAIN — the status meaning “domain doesn’t exist.” If it returns an IP instead — the ISP is intercepting NXDOMAIN responses and redirecting to its own page.

SMART DNS — WHAT IT IS AND HOW IT WORKS

Smart DNS is not a VPN and not encryption. It’s a DNS service that returns the IP of its own proxy server for certain domains instead of the real one. The browser goes to the proxy, the proxy makes the request from its own IP — which is located in another country — and returns the response to you.

Why do you need an IP from another country? Many blocks are geographic: the site is accessible from Germany but not from Russia or Belarus. The Smart DNS proxy is in a country where the site is open — and makes the request from there. The target site sees the proxy’s IP, not yours. The ISP sees a connection to the proxy, not to the blocked site.

The key difference from a VPN: only requests to blocked sites go through the proxy. All other traffic goes directly — no tunnel, no speed loss.

How it works:

1. You set your DNS to the Smart DNS provider’s server instead of the default
2. You request a blocked site
3. DNS returns the IP of the Smart DNS provider’s proxy
4. Your browser connects to the proxy
5. The proxy makes the request from an IP in the target country
6. You receive the content

Pros: fast, no VPN client setup needed, no effect on speed for other traffic, works on devices where a VPN can’t be configured (Smart TVs, game consoles, routers).

Cons: adds no encryption — if the site runs over HTTP, the ISP can see the content. For HTTPS sites the content is already encrypted by TLS, but the ISP sees the proxy’s IP and may infer you’re bypassing blocks. Only works against DNS blocks. Powerless against IP blocks and DPI. Requires trust in the Smart DNS provider — all traffic to blocked sites goes through them.

Setup on a Linux server — simply change the DNS:

# /etc/resolv.conf
nameserver SMART_DNS_PROVIDER_IP

Or via systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=SMART_DNS_PROVIDER_IP

DOH AS A BYPASS TOOL

DNS over HTTPS solves a different problem — it encrypts DNS queries. But this has an important side effect: the ISP can’t see which domains you’re resolving and can’t spoof the answer.

If the block works through DNS spoofing — DoH bypasses it automatically. You resolve through Cloudflare 1.1.1.1 or Google 8.8.8.8 over an encrypted channel on port 443. The ISP sees only HTTPS traffic — it can neither spoof the answer nor even tell it’s DNS.

It’s important to distinguish DoH from DoT. systemd-resolved only supports DoT — DNS over TLS on port 853. DoT also encrypts traffic and hides DNS queries from the ISP, but it runs on a dedicated port 853, which can be blocked. DoH runs on port 443 — the same as HTTPS — and blocking it without breaking all internet traffic is practically impossible.

For DoT via systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

systemctl restart systemd-resolved

Check that it’s working:

resolvectl status | grep "DNS over TLS"

For true DoH on port 443 — dnscrypt-proxy. A lightweight proxy with DoH support, available in standard repositories starting with Debian 13 and Ubuntu 25. On older distributions, install from GitHub releases:

apt install dnscrypt-proxy       # Debian 13+ / Ubuntu 25+
dnf install dnscrypt-proxy       # RHEL/Fedora

Configure upstream servers in the config file:

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:5300']
server_names = ['cloudflare', 'quad9']

systemctl enable --now dnscrypt-proxy

Point systemd-resolved at dnscrypt-proxy:

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1:5300
DNSOverTLS=no

systemctl restart systemd-resolved

dnscrypt-proxy proxies all queries through DoH on port 443. The ISP sees ordinary HTTPS traffic.

Limitations: DoH and DoT only work against DNS blocks. If the site is blocked by IP or via DPI — they won’t help. The ISP can’t see DNS queries, but it does see the destination IP and the SNI field in TLS.

VPN vs SMART DNS vs DOH — WHAT AND WHEN

The main mistake is choosing a tool before understanding what exactly is blocked. A VPN doesn’t help against DNS blocks any better than switching resolvers — it’s just slower and more expensive.

DNS block — the ISP is spoofing DNS responses. The most common type in the EU and most countries with moderate censorship. Solution: switch DNS to 1.1.1.1. Literally thirty seconds. DoH is the same thing plus query encryption. Smart DNS if you need an IP from another country. VPN works too, but it’s like using a sledgehammer to hang a picture.

IP block — the site’s IP is physically unreachable, packets get dropped. DNS has nothing to do with it — you can resolve through any server, the correct IP still won’t respond. You need a proxy or VPN.

DPI — deep packet inspection. The ISP sees not just the destination IP but the domain name in SNI, traffic patterns, protocol signatures. Changing DNS is useless — the query will resolve correctly, but the connection will still get reset. Standard WireGuard or OpenVPN is easily identified by its signatures. Only obfuscated traffic works: Shadowsocks, VLESS with reality, Trojan — protocols that impersonate ordinary HTTPS.

A separate trap when using a VPN — DNS leaks. The VPN is configured, traffic goes through the tunnel, but DNS queries keep resolving through the ISP, bypassing the VPN. This happens because many VPN clients create a tunnel for IP traffic but don’t touch the system DNS — it keeps using whichever resolver was configured before the connection. You think you’ve bypassed the block, but the ISP still sees every domain you request.

Check at dnsleaktest.com — the site shows which resolver your DNS queries are going through. If you see your ISP’s IP in the results instead of the VPN server — there’s a leak. Fix it in the VPN client settings (“DNS leak protection” or “Use VPN DNS”) or by forcing DoT/DoH on top of the VPN.

REALITY BY COUNTRY

Lithuania and most EU countries. Blocks exist — gambling, pirated content, some financial services. Implemented via DNS at the ISP level. No DPI. Solution: switching DNS to 1.1.1.1 closes the issue entirely.

Russia. Three levels simultaneously. Roskomnadzor maintains a registry — ISPs are required to block by DNS and IP. But the main tool is TSPU: DPI hardware installed at all major ISPs starting in 2019. TSPU was what throttled Twitter in 2021 and is what blocks VPN protocols now. Changing DNS helps against some blocks — the ones without IP blocking. But TSPU works deeper. Since 2023, standard WireGuard and OpenVPN are being blocked or throttled on many ISPs — their signatures are recognized. What works in 2026: Shadowsocks, VLESS with reality, Trojan. The core principle — traffic must be indistinguishable from regular HTTPS. Here’s how that’s achieved: a standard VPN protocol has a recognizable signature — a characteristic handshake, packet patterns, headers. DPI sees it and blocks it. Shadowsocks encrypts traffic so it looks like random noise. VLESS with reality goes further — it impersonates a real TLS connection to an actual site, mimicking its fingerprint down to the details of the TLS handshake. Trojan runs on top of real HTTPS and is literally indistinguishable from web traffic — because from the ISP’s perspective, it is web traffic.

China. The Great Firewall is the most technically sophisticated filtering system in the world. Public resolvers are blocked there (8.8.8.8 and 1.1.1.1 are unreachable). DPI is everywhere. Most VPN protocols are blocked. Only deeply obfuscated traffic works. DNS solutions are useless.

Belarus, Iran. A level between Russia and China. DPI exists but coverage is incomplete. Switching DNS + DoH helps in some cases. For reliable bypass — VPN with obfuscation.

PRACTICE: WHAT TO CONFIGURE ON A SERVER

Base level — DoT via systemd-resolved. Encrypts DNS traffic, hides queries from the ISP:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
FallbackDNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes

systemctl restart systemd-resolved
resolvectl status

DoH via dnscrypt-proxy — if DoT is being blocked by the ISP (port 853 closed). dnscrypt-proxy proxies queries through DoH on port 443. The ISP sees ordinary HTTPS traffic. Available in standard repos starting with Debian 13 / Ubuntu 25, on older systems install from GitHub releases.

apt install dnscrypt-proxy       # Debian 13+ / Ubuntu 25+
dnf install dnscrypt-proxy       # RHEL/Fedora

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:5300']
server_names = ['cloudflare', 'quad9']

systemctl enable --now dnscrypt-proxy

Then in systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1:5300
DNSOverTLS=no

systemctl restart systemd-resolved

Check that DNS blocks are being bypassed:

# Compare the answers
dig @8.8.8.8 blocked-site.com
dig blocked-site.com

If the answers match — encryption is working, the ISP isn’t spoofing responses.

WHY DNS IS NOT A SILVER BULLET

Imagine you’ve encrypted your address book. Nobody can see where you’re going. But when you drive out onto the street — the street sign and house number are visible to everyone around you.

That’s exactly how SNI works — Server Name Indication. It’s a field in the TLS handshake where the client sends the domain name it’s connecting to in plain text. The server needs this to know which certificate to present — one IP can serve hundreds of domains. Your DNS query is encrypted via DoH, but the domain name in SNI is visible to any observer along the way.

This is exactly how an ISP with DPI determines which domain you’re connecting to — even if the DNS query went over an encrypted channel. So DoH hides DNS queries, but doesn’t hide the actual connection to the blocked resource.

ECH — Encrypted Client Hello — encrypts SNI. Cloudflare supports it, Firefox supports it. But ISPs with DPI simply block connections with ECH as suspicious. Which itself tells you how seriously they take this issue.

The bottom line: DoH is good practice regardless, always enable it. But against DPI, DNS tools don’t help. That requires obfuscation at the protocol level.

One important nuance that often gets missed: DoH doesn’t eliminate the trust problem — it moves it. Before, your ISP saw all your DNS queries. With DoH, Cloudflare or Google sees them instead. You’ve just changed the observer.

Browser-level DoH goes further — it silently bypasses your local resolver. If you have ad filtering, malware blocking, or DNS monitoring configured at the network level, a browser with DoH enabled ignores all of that without telling you. Firefox uses Cloudflare, Chrome upgrades the system DNS to DoH — and your local Pi-hole or corporate firewall stops working for browser traffic.

The correct setup when you need both privacy and control is your own local resolver. dnscrypt-proxy or Unbound with DoT upstream to 1.1.1.1 gives you encrypted outgoing DNS traffic and full control over what gets filtered, logged, and blocked. You encrypt the traffic between yourself and the public resolver, while remaining in control of your own network.

In a corporate network, browser-level DoH should be disabled via group policy. Otherwise employees bypass corporate DNS — filtering, monitoring, blocking — simply by opening a browser with default settings. DoT is better in this context: DNS remains a distinct service that can be controlled and monitored, while still providing encryption.

In Chrome, disable DoH via registry:

HKLM\SOFTWARE\Policies\Google\Chrome\DnsOverHttpsMode = off

In Firefox via corporate policies.json:

{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

Locked: true matters — without it users can re-enable DoH via about:config.

One more scenario that rarely gets mentioned: a compromised router. If an attacker gains access to a router — they change the DNS to their own server in the DHCP settings. All devices on the network automatically receive their resolver and resolve through it. Manually changing DNS on a device helps, but not always — some devices forcibly take DNS from the router only and ignore manual settings.

Browser DoH bypasses this entirely — here’s why. A browser with DoH enabled doesn’t use the system resolver at all. It sends an encrypted DNS query directly to 1.1.1.1 or 8.8.8.8 over HTTPS. The router sees only HTTPS traffic on port 443 — spoofing it without a certificate is impossible. The attacker controls the DNS server the router distributes, but the browser never uses that DNS server. That’s exactly why browser DoH is a useful habit even on trusted networks.

CHECKLIST

Identify the blocking level before choosing a tool:

# DNS block?
dig @1.1.1.1 site.com
dig @ISP_dns site.com

# Is the IP reachable?
curl -v --connect-timeout 5 https://site.com

# Where does traceroute cut off?
traceroute site.com

Choose your tool:
— DNS block → switch DNS to 1.1.1.1 or enable DoH
— IP block → Smart DNS or VPN
— DPI → VPN with obfuscation (Shadowsocks, VLESS, Trojan)

Additionally:
— Enable DoH regardless — it encrypts DNS independent of any blocks
— For servers, configure a fallback DNS so you don’t depend on a single provider
— When using a VPN, check for DNS leaks at dnsleaktest.com

CONCLUSION

Not all blocks are created equal. DNS solutions — fast, lightweight, no infrastructure required — cover most cases in countries with moderate censorship. Where DPI is deployed, DNS tools are powerless and different approaches are needed.

Simple rule: first understand exactly how something is blocked. Then choose your tool. Not the other way around.