DNS hijacking: How Roskomnadzor, other countries' regulators, and proxy services themselves control your DNS requests

The material consists of two parts, and the second is more important than the first. In the first part, we break down how the state intercepts DNS queries: detailing the mechanics of Roskomnadzor (TSPU, NSDI, the story of the one-hour block of 1.1.1.1 and 8.8.8.8, the YouTube case in February 2026), and then — a comparison with China, Iran, Turkey, Kazakhstan, Pakistan, India, the UK, and the US: different jurisdictions where essentially similar techniques are applied on entirely different legal grounds — from direct state censorship to copyright infringement lawsuits.

In the second part — the very reason it's worth reading to the end, rather than stopping halfway through the list of countries. The first and most logical thought of almost anyone facing blocking at the state or ISP level is — "I'll just turn on a proxy or VPN, and the issue is resolved." In practice, this is no guarantee: the proxy service itself may well be engaging in the exact same DNS hijacking as the state DPI — only instead of blocking specific domains, it intercepts your entire DNS traffic and reroutes it to its own infrastructure, regardless of what resolver you explicitly set in your settings. We will break this down using a specific practical test, show a reproducible diagnostic method, and finally suggest where you can quickly check yourself for signs of such a DNS leak — using the Zloy Detect checker.

What exactly is DNS hijacking

The term "DNS hijacking" in a narrow sense means taking control of domain name resolution without the consent of the resource owner or user: spoofing a DNS server response, compromising a registrar, or attacking the resolver itself. But in the context of state internet regulation, this concept has long expanded and usually covers three technically different but functionally similar scenarios:

• DNS spoofing / poisoning — there is a device (a DPI box, an operator's edge router) on the network path between the user and the legitimate DNS server that either intercepts the UDP query and answers faster than the real server or simply prevents the response from reaching the user, substituting its own.
• Resolver-level filtering — the ISP or public DNS operator themselves administers the resolver and, upon the regulator's demand, does not return the correct IP for certain domains (NXDOMAIN, a stub/block page, a "grey" IP).
• Registry/administrative record deletion — the domain is physically removed from the authoritative database (registry, national domain name system), and the correct response simply ceases to exist anywhere within the controlled perimeter.

Below is a breakdown of how this works in Russia, and a comparison with the practices of a dozen and a half countries, from China to the UK.

Russia: from targeted blocking to sovereign infrastructure

What is TSPU

TSPU (Technical Means of Countering Threats) is essentially a DPI infrastructure ("black boxes") built directly into operators' networks. By 2025, TSPU coverage on broadband access in Russia approached 100% (for comparison, three years ago it was about 80%), and the total throughput capacity of the equipment is measured in terabits per second: Rostelecom, according to available data, reached a peak capacity of 16 Tbps with an average level of around 9 Tbps. DPI on this equipment analyzes traffic across the entire OSI model: for unencrypted protocols (HTTP, plain DNS), the full payload of the packet is available; for TLS — only metadata (SNI, JA3/JA4 fingerprints, behavioral patterns).

From DNS blocking to DPI and back

For a long time, DNS response spoofing in Russia was just one of several parallel mechanisms — along with IP blocking and packet filtering — and was perceived as the weakest and most easily bypassed tool: changing the DNS server to 8.8.8.8 or 1.1.1.1 usually solved the problem. The regulator reacted predictably: on September 8, 2021, public resolvers 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) themselves were blocked for an hour through TSPU across several major operators — an experiment that independent observers recorded and which, according to available data, was discussed by operators as a candidate for permanent implementation.

In parallel, work was underway to block encrypted DNS protocols. Back in 2019, a bill was discussed to ban encryption protocols that hide the name of a website (TLS 1.3, ESNI, DoH, DoT), and in February 2020, a government decree was signed granting Roskomnadzor (RKN) the corresponding authority.

At the same time, it is important to understand: DNS filtering at the operator level in the Russian model has long ceased to be the only or even the main line of defense — it is rather the first, cheapest screening line that takes some of the load off the DPI, which picks up everything else at the transport and application layers.

NSDI as a new lever: the February 2026 case

In February 2026, Roskomnadzor for the first time publicly applied NSDI (National Domain Name System) rather than the "traditional" TSPU+DPI bundle as an independent blocking tool. On February 10, the youtube.com domain was completely removed from the database of DNS servers controlled by RKN — meaning resolvers stopped returning any valid address for it. By February 11, according to independent estimates, at least 13 domains of major resources, including Facebook, Instagram, WhatsApp, and a number of media outlets, had been removed from the NSDI. Technologically, this differs from targeted DPI blocking of a specific domain: removing a record from the national address book is a rehearsal for a much more fundamental scenario — partial or complete isolation of the Runet from the global root DNS system in case such a political command is given. Observers interpreted this as a test of the "sovereign Runet" infrastructure, rather than a final solution to a technical problem: workarounds (VPNs, alternative resolvers) continued to work without changes.

At the end of 2025, RKN reported a 59% year-on-year increase in the volume of materials deleted at the agency's request, and a transition to traffic filtering using machine learning was announced for 2026 — with a budget of about 2.27 billion rubles for these purposes. This is symptomatic: the purely DNS/DPI signature-based blocking model is exhausting its effectiveness against the growing share of encrypted and obfuscated traffic, and the regulator is moving towards behavioral analysis — the same direction in which commercial proxy/VPN detection tools are developing.

Do you think only the Russian authorities engage in DNS hijacking?

DNS manipulation in the interests of the state or private copyright holders is a worldwide practice, differing more in the degree of process transparency and the scale of collateral damage than in the technique itself.

China: The Great Firewall — the gold standard of DNS poisoning

The Chinese Golden Shield / Great Firewall (GFW), conceptually laid down back in the late 1990s, remains the most studied and technically advanced censorship middleware system in the world. The DNS poisoning mechanism there works like a classic packet race: GFW edge nodes monitor DNS queries (mostly on unencrypted UDP) to domains from a blacklist and inject a fake response faster than the legitimate one can arrive — due to the lack of authentication in standard DNS, winning this race is technically easy. The fake response is cached by upstream resolvers and spreads further, which is why the "poisoning" effect sometimes goes far beyond China, affecting public resolvers around the world if their traffic ever passed through a Chinese transit node.

The scale of the system is well documented by academic measurements: while in 2010 researchers recorded about 9 fake IP addresses used in poisoned responses, later this number grew to 1,500 or more, and according to recent data, GFW operates a pool of 3,600 unique fake IPv4/IPv6 addresses. Long-term measurement projects (GFWatch and similar) have recorded up to 311,000 censored domains during daily testing of over 400 million domain names. DNS injection in GFW works in tandem with two other tools — TCP connection resets (RST injection) and IP blocking via BGP route injection at the border of autonomous systems ("null routing"), which physically drops all outbound traffic to blocked addresses. In 2025, NDSS researchers discovered a buffer overflow vulnerability (named Wallbleed) in the DNS-injecting subsystem of GFW, allowing leakage of the internal memory of the censoring equipment — a rare case where the censorship infrastructure itself turned out to be vulnerable to external analysis.

Iran: permanent DNS blocking as the norm

The Iranian model is technically simpler but indicative in its resilience: the blocking of Twitter in Iran is implemented precisely at the DNS level — a local resolver (for example, at the ISP Shatel) for a query to twitter.com has stably returned an intentionally invalid internal address for years, leading to a page with a censorship notification. The peculiarity of the Iranian case is that changing the resolver to a public one (like 8.8.8.8) does not always help — the interception of the DNS query occurs on the path, and not just at the ISP's resolver, which means it is closer to classic on-path hijacking, and not just a "bad" DNS server.

Turkey: the illustrative escalation of 2014

The Turkish case of 2014 is one of the clearest textbook examples of how DNS blocking fails technically and why regulators abandon it in favor of blunter tools. After the leak of a recording criticizing the Prime Minister, the authorities obliged ISPs to block Twitter, and the first implementation was extremely simple: ISPs stopped giving a valid response for the domain on their DNS servers. The bypass took hours — residents massively switched to Google Public DNS, and graffiti with the addresses 8.8.8.8 and 8.8.4.4 appeared around the city. Inside the country, Twitter traffic, according to some estimates, even grew by 130+% amid the publicity. The authorities reacted by blocking the IP addresses of the public DNS resolvers themselves, and then moved to IP blocking Twitter itself — this forced some users to switch to VPNs and Tor. Later, Turkey adopted broader censorship and surveillance legislation, focusing instead on URL filtering, which cannot be bypassed by a simple DNS change.

Kazakhstan: administrative blocking without trial and a MITM attempt

In Kazakhstan, since 2014, the blocking of resources can be carried out not only by a court decision but also at the request of the Prosecutor General's Office or the relevant ministry — without any judicial oversight at all. The result was statistically noticeable: while from 2014 to 2018 about 8,240 materials were blocked by a court decision, over the next three years alone, more than 50,000 materials were restricted at the request of state bodies without a trial. Separately stands the episode of 2019, when the state ISP obliged some subscribers to install a root certificate allowing the interception of TLS traffic (essentially a MITM attack) when accessing a number of websites, including social networks and email services — an experiment that drew international criticism specifically for undermining the encryption trust model, and not just for blocking access. In 2022, during mass protests, Kazakhstan resorted to complete internet shutdowns at the backbone level — DNS tools become redundant in such a situation.

Pakistan: from targeted blocking to "Great Firewall" ambitions

The Pakistani regulator PTA has for years practiced blocking by decision of administrative bodies and lawsuits: YouTube was completely blocked from 2012 to 2016, Wikipedia — for two days in 2023 due to controversial content, and according to data voiced in parliament, about 900,000 URLs were blocked at a certain point. A separate line is the periodic attempts to introduce a centralized national traffic filtering system modeled on the Chinese one (the "Great Firewall of Pakistan"), which met both technical criticism (the risk of degrading the entire national network) and lawsuits from civil activists challenging blockings without prior notification to website owners.

India: opacity and "patchwork" DNS censorship

The Indian model is distinguished by its scale and, at the same time, extreme opacity. Independent measurements (in particular, using the OONI methodology) show that Indian ISPs massively use DNS poisoning and IP blacklisting, but do so uncoordinatedly: the same site may be blocked by one operator and freely accessible by another. A separate study, which tested the DNS servers of six major ISPs across almost the entire visible domain name space (about 294 million domains), found not only politically sensitive resources blocked but also a significant number of malicious domains — which formally could be considered blocking "in the public interest" if the process were public.

United Kingdom: a conveyor belt of court orders

Since 2011 (the case of Twentieth Century Fox v. British Telecommunications), a streamlined blocking mechanism has been in place in the UK under Section 97A of the Copyright, Designs and Patents Act (CDPA). A lawsuit is filed by the copyright holder (usually associations like the Motion Picture Association) against the largest ISPs — BT, Sky, TalkTalk, Virgin Media, and others, which provide about 90% of broadband access in the country; the blocked site itself is not a party to the proceedings and cannot defend itself in court. Over the years, hundreds of domains (thousands if counting mirrors and proxies) have been blocked this way. It is noteworthy that an attempt to make blocking administrative rather than judicial (Sections 17-18 of the Digital Economy Act 2010, which assumed Ofcom powers) was scrapped by the government back in 2011 — due to cost estimates (over £8 million a year), the ease of bypass via VPN, and the risk of disproportionate harm to bona fide users. That is, Britain deliberately chose a slower but court-controlled process instead of an administrative one.

USA: the DNS blocking that never happened

It is telling that in the US itself, an attempt to legislate mandatory DNS blocking (the SOPA and PIPA bills, 2011-2012) failed — and one of the decisive arguments was purely technical: DNS filtering is incompatible with DNSSEC and systemically weakens the security of the entire domain name system, rather than simply being "inconvenient to bypass". After mass protests and a joint statement by White House administration officials, the sponsor of SOPA publicly dropped the DNS-blocking provisions in January 2012. This does not mean that the US has no mechanisms for interfering with domain names at all — the ICE agency has for years practiced domain seizures through registrars by court order, which is technically closer to "record revocation" than to DNS hijacking in the narrow sense, and was accompanied by high-profile mistakes (in particular, a 2011 case when ICE mistakenly blocked tens of thousands of domains on a shared IP address for several days).

The second front: when the proxy itself intercepts DNS

Why doesn't a proxy solve the DNS hijacking problem?

From all the above, an obvious conclusion suggests itself: if DNS is blocked at the state or operator level, then you just need to get a proxy or VPN — then the DNS query will go not to the ISP's resolver, but to wherever the user specifies, or to the resolver built into the service itself. The thought is logical and works in most cases. But it has a blind spot: the mere fact of using a proxy says nothing about what happens to the DNS query inside that proxy. And sometimes literally the same DNS hijacking happens there — it’s just that the operator of the interception is not RKN or the ISP's DPI box, but the proxy provider itself. Therefore, testing proxies for DNS nativeness is necessary every time.

When a Proxy itself engages in DNS hijacking: a real case breakdown

Below is an anonymized breakdown of our own technical test of a proxy service providing "residential" exit nodes — that is, IP addresses that are supposed to look like the real addresses of home subscribers of a specific Internet Service Provider. RCN, a real American cable operator operating in Pennsylvania and Illinois, was used as the reference network for testing.

The test methodology is simple and fully reproducible:

1. A unique (canary) subdomain is taken in a controlled authoritative DNS zone — one that has never been resolved before and could not have been cached on any intermediate resolver.
2. From a client operating through the tested proxy, a DNS query is sent to this subdomain, explicitly addressed to a specific resolver (public 8.8.8.8/1.1.1.1, the official DNS server of a specific ISP, or an arbitrary internal address).
3. On the authoritative server of the subdomain, the logs record which real IP and which Autonomous System (ASN) the query actually came from — this is who actually performed the resolving, regardless of what was specified by the client.

The result was stable and repeatable. When querying the official RCN DNS servers (ns1.dns.rcn.net and other addresses from their official pool) through the tested proxy, the responses were actually generated by Amazon and Cloudflare infrastructure — and not by the RCN network itself. Next — a control sample: 25 real IP addresses belonging to RCN ranges in Pennsylvania and Illinois (Nazareth, Allentown, Streamwood, Chicago) were taken from the database, and the same canary test was run through the proxy for each. The result: all 25 without a single exception were resolved not through the infrastructure corresponding to the declared address or region, but through just two fixed addresses on Amazon EC2 (18.215.55.101 and 44.217.58.170, both in the us-east-1 region).

Then the test was taken to the extreme specifically to exclude any alternative explanations: as the "DNS server" on the client, addresses that are deliberately invalid for external resolving were specified — public 1.1.1.1 and 8.8.8.8, as well as purely private RFC1918 addresses like 192.168.1.1, 10.0.0.1, 172.16.0.1, which in principle cannot be a valid external DNS server. The result did not change: the canary domain resolved through the exact same two AWS addresses as before — meaning the proxy client does not read or consider the specified resolver at all, but intercepts any outbound DNS query on the fly and replaces it with its own. A control check involving changing the proxy with the exact same local network (the L2 level was deliberately unchanged to exclude the influence of the tester's own equipment or network) showed a fundamentally different behavior: the DNS was resolved through the real RCN infrastructure — meaning the anomaly is localized specifically in the particular proxy product, and not in the test environment.

Why this is the exact same DNS hijacking, just private

Mechanically, there is no difference between what such a proxy add-on does and what TSPU, GFW, or, say, an "aggressive" transparent DNS proxy at the British ISP Sky (see the UK section above) does. In both cases, the device or service on the query path ignores what the user actually specified and replaces either the response itself or the source of the response with its own. The only difference is who does it and why: the state regulator — for the sake of blocking specific domains; the proxy provider — for the sake of centralized control (logging, caching, and in the worst case, selectively spoofing responses for specific domains) over all the DNS traffic of its clients.

How to check this yourself

The method described above (unique subdomain + explicitly specified resolver + verifying who actually answered on the authoritative server) is basic, and if desired, it can be repeated manually via dig and any controlled DNS domain. The same principle — only ready-made, without the need to spin up your own zone — underlies automatic DNS leak checkers: the client is given a unique test subdomain, and the service shows which real address and network the query came from, comparing this with what the client expected to see. If you want to quickly check whether DNS is being spoofed right now — manually or through the proxy/VPN you are using — there is the dnsdetect.zl0y.team checker for this: it analyzes DNS responses and estimates the probability that the resolving is not going where it should, including signs of using a proxy or VPN with anomalous DNS behavior.

Why everyone chooses DNS hijacking as a baseline and how to protect yourself

The overall pattern is visible to the naked eye. DNS turns out to be the first blocking tool almost everywhere for the same reason: it is the cheapest and fastest lever to deploy. You don't need to analyze packet payloads, you don't need to calculate CDN IP addresses that can change dozens of times a day — you just need to put the domain on a list once and force the resolver (your own or someone else's, as in the Quad9 case) to give an incorrect response.

But for the same reason, DNS blocking is the most unstable tool: it breaks when changing the resolver, via DoH/DoT, a local hosts file, or a VPN. That is why in all the analyzed jurisdictions where the stakes for the regulator are high (China, Russia, Turkey, partly Iran), the DNS level eventually becomes not the final barrier, but the first and cheapest filter that removes some of the load from heavier and more expensive mechanisms — DPI, SNI/TLS fingerprint inspection, RST injections, IP blocking, and null routing at the BGP level. The growth in the share of encrypted DNS traffic (DoH, DoT, and in the future DoQ over QUIC) and SNI concealment technologies (ECH) changes the very economics of blocking: regulators have to shift from simple domain list matching to fingerprinting encrypted sessions and behavioral traffic analysis — that is, to much more resource-intensive and less accurate methods, which is confirmed by RKN's announced transition to ML filtering for 2026.

For the end user, a practical conclusion follows from this: in the future, states and proxy providers are unlikely to abandon DNS hijacking, and blocking will only intensify. The former due to its simplicity as a baseline for controlling the users of their country (countries are increasingly looking at the successful experience of China's Great Firewall and adopting it), and the latter from the standpoint of economic efficiency. At the same time, there will always be technical means, such as ZloyRouter, that will help overcome these restrictions and substitute native DNS, automatically checking them every time for DNS hijacking. This is the eternal battle of shield and sword, water and fire — so it was, so it is, and so it will always be.