Something has been going on with DNS in Russia, and it’s been going on for a while.

For example, on September 8, 2021, Roskomnadzor (Russia’s federal media and communications regulator) blocked the public DNS resolvers 1.1.1.1 and 8.8.8.8 for an hour, from 21:00 to 22:00 Moscow time, at several major carriers using TSPU (technical means for combating threats). Independent researchers documented this fact. A few days later, telecom provider Rostelecom circulated an internal proposal to make this block permanent. In October 2024, Cloudflare enabled the TLS ECH extension by default, which hides the destination domain (SNI) during connection setup. Starting November 5, 2024, researchers documented blocking of TLS sessions carrying this signature, not through a TCP RST but through a silent packet drop after detection, which forces the browser to fall back to a regular, unencrypted connection.

We decided to test how different DNS resolvers behave in Russia across different resources, and what role TSPU plays in restricting them.

Our measurements

Filtering nodes

To isolate the filtering nodes (TSPU), we deployed our measurement infrastructure across five independent vantage points:

• Reference node (Spain, residential broadband).
• Reference node (Germany, Tier-1 backbone level).
• Measurement nodes inside Russia (Moscow and Saint Petersburg, Tier-2/Tier-3 data center level).
• Measurement node inside Russia (Saint Petersburg, residential end-user broadband level).

Domains

We queried resolvers across several groups of domains:

1. Blocked messengers: whatsapp.com, telegram.org, signal.org.
2. Blocked media outlets: meduza.io, bbc.com, novayagazeta.eu.
3. Technical resources: protonvpn.com, te-st.org, github.com.
4. Reference foreign domains (not blocked): microsoft.com, nvidia.com.
5. Degraded: youtube.com, apple.com.
6. Local Russian (working): ya.ru, vk.ru.
7. CDN infrastructure: cdnjs.cloudflare.com (Cloudflare), fastly.net, ajax.googleapis.com (Google), cdn.jsdelivr.net (goal: detect hosting-provider subnet blocks at the L3/L4 level, as opposed to targeted L7 filtering.)

DNS servers (resolvers)

• BigTech & public resolvers: Cloudflare, Google, Quad9, Cisco Umbrella, OpenDNS.
• Specialized and private DoH/DoT: NextDNS, Control D, AdGuard DNS, Mullvad DNS, LibreDNS.
• Russian: Yandex DNS, NSDI (National System of Domain Names), included not as “external” DNS under test but as a reference point for how a DNS resolver known to operate under Russian jurisdiction responds.

Measurement tools

• kdig: for queries over plain DNS, DoT, DoH, and DoQ;
• dig: for manual control of the EDNS Client Subnet field when testing the geographic-routing hypothesis;
• curl: to check directly what a specific IP address returns over HTTPS with a given SNI, independent of the resolver and its response.

Our targets

• L3/L4: IP blackholing of known resolvers’ subnets, blanket blocking of port 853, and injection of forged TCP RST packets to reset connections during session setup. (Port 853 is shared by DoT and DoQ; comparing how these two protocols behave on the same port lets us tell whether the port gets cut off entirely or the filter distinguishes a specific protocol/signature within it.)
• Active intercept: spoofing of A/AAAA responses by TSPU servers (DNS hijacking). To verify the interception point and prove that spoofing happens specifically at TSPU, we used network route tracing.

A “corrupted” DNS answer in this research can arise from one of two distinct causes, and we can’t lump them together in one table:

1. In-path interception (TSPU). Modification or dropping of traffic along the route between the client and the resolver. This only occurs if the request physically passes through a Russian carrier’s network. Signature: the result changes depending on the observation point for the same resolver (a Russian node sees a spoofed/dropped response, while a foreign node querying the same resolver gets a genuine answer).
2. Resolver-side compliance. The resolver operator itself builds a blocklist into its own response logic on its servers. Signature: the result is identical regardless of the client’s geolocation, because what gets filtered isn’t the route but the response point itself.

Telling these two cases apart matters, because each requires a different countermeasure. A VPN or traffic obfuscation solves the first case, but is powerless against the second: that one requires switching your DNS provider instead.

Our findings

We found no classic blocking, connection resets, or unreachable subnets at our test nodes. What we did find was an unexplained DNS response substitution at some resolvers for some domains. We covered these addresses in an earlier piece.

At the time, we called these addresses “RKN stubs.” But a closer look showed that description wasn’t quite accurate. These addresses serve real, working Cloudflare content, not an empty blackhole response. We verified this directly with curl, using an explicit SNI for signal.org through the address 8.47.69.6, and not just from a VPS but also over an ordinary home internet connection in Russia.

How we told “noise” from real anomalies

A first pass through the logs showed that for some domains, the response at the Russian node differed from the response at every foreign node we checked. Before interpreting anything, we had to clean this sample of noise; otherwise, the “repeated IP where it shouldn’t be” method produces false positives on any anycast/CDN service.

An important methodological observation: stability and high repeatability alone aren’t signs of interference. For example, whatsapp.com and youtube.com produce reproducible, node-dependent responses with 100% repeatability, and that’s exactly what you’d expect from ordinary geographic load balancing at the providers themselves, not from spoofing. The only way to tell an “anomaly” from “noise” is to compare against a control group. If the same thing happens with nvidia.com or microsoft.com, which aren’t currently blocked and show no signs of being blocked, the cause is probably not censorship.

After subtracting the “noise,” one notable family of responses remains in the data: 8.47.69.N / 8.6.112.N, where N is 0, 6, or 8. According to ARIN, 8.6.112.0/24 is registered to Cloudflare, Inc. (origin AS13335). That said, this network isn’t part of Cloudflare’s published IP Ranges list, which is meant for configuring allowlists on origin servers and doesn’t cover the company’s entire internal/product address space. In other words, finding an address outside the public list doesn’t mean the address belongs to someone else.

Signs of spoofing

We used a simple principle to detect spoofing automatically: if the same IP response repeats across several domains that have no shared physical infrastructure (for example, signal.org, which runs on Signal’s own servers, versus meduza.io and te-st.org, which sit behind Cloudflare), that’s statistically anomalous and points to a common source of spoofing rather than coincidence.

This method doesn’t rely on external IP-ownership databases and makes no assumptions about “correct” addresses in advance. It simply looks for repeats where none should exist, which lets us find anomalies without knowing in advance exactly what to look for. We manually checked whether each match we found was legitimate. Domains behind the same CDN provider can legitimately share an IP, and we counted those cases as coincidence, not spoofing. What helped us tell one from the other was looking at exactly which domains ended up grouped together.

How we ruled out AITM

A TLS certificate check showed that the connection to 8.8.8.8/1.1.1.1 is established with genuine Google/Cloudflare infrastructure (the certificates are valid and issued by legitimate CAs, Google Trust Services and SSL.com respectively), which rules out a classic AITM attack with a spoofed certificate on the path to the resolver itself. Route tracing confirms that traffic from the Russian nodes does in fact reach these providers’ own networks (AS15169 for Google), rather than being redirected to a third-party address.

This leads to the conclusion: the anomalous response at addresses 8.47.69.x/8.6.112.x isn’t the result of traffic interception along the route between the client and the Google/Cloudflare DNS; the connection to the resolver itself is genuine. If spoofing is happening at all, it’s built into the resolver’s own response logic (see the classification in section 2.4), or it’s legitimate infrastructure behavior that merely looks like spoofing from the outside.

The response looks like genuine Cloudflare

Cloudflare’s addressing scheme for domains under its protection uses two A records in two adjacent /24 blocks, sharing the same last octet:

signal.org            104.18.10.47 , 104.18.11.47   → octet 47
meduza.io             104.18.0.79  , 104.18.1.79    → octet 79
cdnjs.cloudflare.com  104.17.24.14 , 104.17.25.14   → octet 14
аномалия (класс B/C)  8.47.69.0    , 8.6.112.0      → octet 0
аномалия (класс A)    8.47.69.6    , 8.6.112.6      → octet 6
аномалия (AdGuard)    8.47.69.8    , 8.6.112.8      → octet 8

In all three variants, the anomalous response reproduces Cloudflare’s internal convention (paired /24 blocks with a shared last octet), rather than looking like the arbitrary IP substitution typical of an on-path injector (in such cases, TSPU usually returns a single fixed stub IP with no structure like this). This is an argument in favor of the response originating from Cloudflare’s own infrastructure rather than a third-party interceptor, but it isn’t conclusive proof.

Three different scenarios

Class A. A differential signal, blocked domains only, regardless of the encryption protocol

resolver	nodes	protocols	response	blocked domains hit	control domains hit
Google	RU-msk, RU-spb, EU-vpn-SPB	udp_53, dot_853, doh_443	8.47.69.6, 8.6.112.6	4	0
AdGuard	RU-spb	udp_53, dot_853, doq_853, doh_443	8.47.69.8, 8.6.112.8	4	0

Repeatability within class A ranges from 53.3% to 100%, reaching 100% for Google on RU-spb/doh_443. The key detail: for Google, this response shows up on RU-msk, RU-spb, and EU-vpn-spb (a VPN exit through home broadband in Saint Petersburg) and doesn’t show up on any node without a Russian route, meaning the effect depends specifically on the route, not on DNS as such. At the same time, cdnjs.cloudflare.com, included in the same test matrix, shows no change; only the blocked set is affected. This is the only class where the differential test (a reaction limited to blocked domains, with a clean control group) passes completely.

The DoT and DoH data matter here on their own: the 8.47.69.6 response also arrives over channels where the request content is encrypted (DoT/DoH). Inside a TLS session, TSPU can’t spoof a DNS answer without breaking the session (that would cause a validation error on the client, not a silent IP substitution), which means this particular response gets generated by whoever holds the session’s private key: Google’s own resolver (or whatever answers as the source for that resolver). This narrows the possible causes of the class A anomaly down to Google/Cloudflare actions responding to the request’s route. But why cdnjs.cloudflare.com would be excluded under this same logic remains an open question.

Class B. Resolver-side, the response doesn’t depend on the observing node, but it hits a control domain

Yandex and NSDI return this same response, 8.47.69.0, 8.6.112.0, from every measurement node. This affects 4 blocked domains as well as cdnjs.cloudflare.com, which isn’t on any blocklist. Repeatability ranges from 53.3% to 100% (maxing out at 100% for NSDI/FI-VPS).

The lack of route dependence here is expected and explainable at the infrastructure level. Yandex and NSDI always query their servers from within Russia, regardless of where you’re asking them from, so “the same answer from any node” doesn’t yet distinguish resolver-side censorship from a resolver-side quirk that has nothing to do with censorship (say, ECS/anycast routing at the upstream server itself). The one thing that doesn’t fit the neutral explanation is the involvement of cdnjs.cloudflare.com, a domain that isn’t blocked.

The “RKN list” hypothesis isn’t confirmed. This may be an infrastructure quirk in how Cloudflare responds to upstream queries from Russia. An important caveat: we haven’t yet directly tested whether Yandex’s/NSDI’s upstream server behaves the same way Cloudflare does.

Class C. Russia-specific, route-dependent, but hits the same control domain

Cloudflare (RU-msk, all protocols including DoH/DoT) and NextDNS (RU-msk + RU-spb, all 4 protocols) return that same 8.47.69.0, 8.6.112.0 only from the Russian nodes, and cdnjs.cloudflare.com gets hit again. Repeatability for Cloudflare/RU-msk is 100% across all three protocols.

Formally, class C is closer to our methodology’s “signature of in-path interception” (the result changes depending on the observation point), but the structure of the response and the involvement of DoH/DoT make the in-path injection theory unlikely, for the same reason as in class A. TSPU can’t modify an encrypted response without the client noticing. A more likely explanation is that geographic routing of the request to the upstream server (via EDNS Client Subnet or an anycast node) produces the same result as with Yandex and NSDI, but only shows up when the client’s address is Russian, not when only the resolver’s address is Russian.

What it means

• Class A (Google, AdGuard). The differential test passes completely, route dependence is confirmed, and the response arrives over encrypted transports too. The most likely explanation is logic on the resolver side, or at whatever source answers on behalf of the resolver, that depends on the request’s route rather than in-path injection.
• Class B (Yandex, NSDI). Reproduces Cloudflare’s addressing structure, but it affects cdnjs.cloudflare.com, which contradicts the Roskomnadzor-list theory. We haven’t yet had a chance to check whether these resolvers’ responses depend on the ECS field the same way Cloudflare’s do.
• Class C (Cloudflare, NextDNS). The same response, but only from Russian nodes, and it affects cdnjs.cloudflare.com too. A direct test showed that changing the declared subnet (Russian versus German) doesn’t change the response, so the cause isn’t the ECS content but the specific network path from the node to Cloudflare. For Cloudflare, the anomaly only shows up at the Moscow node. This differs from class A, where the anomaly hits both Russian nodes equally. Google and Cloudflare most likely handle this differently, and the two aren’t related.

What we haven’t studied yet

• Protocol coverage is uneven. NSDI doesn’t support encrypted transports (NOT_SUPPORTED for DoH/DoT/DoQ); comparisons involving NSDI are valid only for udp_53. Yandex’s DoH returns a 100% timeout rate, and DoQ doesn’t work either; comparisons involving Yandex are valid for udp_53 and dot_853, but not for DoH/DoQ.
• We only partly understand why spoofing happens specifically for these domains. For Cloudflare (class C), we identified the cause in section 3.7. We haven’t checked whether Google, AdGuard, Yandex, and NSDI show the same insensitivity to ECS content, so why they select the domains they do remains unclear.
• cdnjs.cloudflare.com remains an unexplained inconsistency across classes. If a single common cause were behind all this, the control domain’s involvement should be either constant or absent everywhere; instead, it depends on which DNS is used. This is the one finding that doesn’t fit either the “pure censorship” theory or the “pure infrastructure quirk” theory. Explaining it is a question for further research.

DNS Update, August 30, 2026
What’s happening with DNS in Russia since August 26?

Summary

• On August 29, from our home vantage point in St. Petersburg, open (unencrypted) DNS queries to Google, Cloudflare, and OpenDNS stopped getting through: they get dropped silently, with no response and no error, right as they left the provider’s network. Before that, on August 3, all three resolvers responded honestly from the same vantage point.
• The resolvers themselves are working. Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222) respond to ping, and the same query sent to the same port 53 over TCP instead of UDP returns real addresses. What specifically fails to get through is an unencrypted DNS query over UDP.
• On our VPS servers in Moscow and St. Petersburg, on August 29 the DNS resolvers responded to our queries the same way they did on August 5. Nothing has changed there yet.
• We did not find the redirection of queries to the NSDI resolver, which the tech community Zapret reported on, at any of our vantage points.
• NSDI still refused to hand out addresses for YouTube and WhatsApp, exactly as it did on August 3.
• The three anomalies we described earlier are repeating in the same form. Wikipedia still resolves normally from our vantage points.

What happened on August 26

On the evening of August 26, users started reporting that YouTube and other blocked sites had stopped loading, with a “domain does not exist” error. The next day, Habr published an analysis with measurements, the tech community collected user observations from different regions into a separate article, and discussion is ongoing on ntc.party.

Here’s how people describe it. TSPU (the deep packet inspection equipment that Roskomnadzor deploys at Russian internet providers) recognizes a DNS query inside a UDP packet and rewrites the destination address in it to the state resolver NSDI (195.208.5.1). NSDI then responds: for blocked domains it says “domain does not exist,” for everything else it returns real addresses. The response arrived from address 8.8.8.8, so from the outside it looks like a response from Google.

This is exactly what we looked for on August 2–5 and didn’t find at any of our vantage points. We repeated the measurement on August 29 at three points inside Russia: a VPS in Moscow, a VPS in St. Petersburg, and a home broadband connection in St. Petersburg.

August 29: at the home vantage point, open DNS to three resolvers (Google, Cloudflare, and OpenDNS) didn’t work

On August 3, 2026, from the home connection in St. Petersburg, Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222) responded over open UDP port 53 just as honestly as they do from vantage points outside Russia. On August 29, none of the three responded even once.

TSPU didn’t block DNS selectively. No responses came back for ya.ru, nvidia.com, or microsoft.com either (domains nobody blocks yet, which we keep on our list as a control group). TSPU apparently didn’t parse what was being asked. It looked at where the packet was going (UDP port 53 to Google, Cloudflare, or OpenDNS) and blocked it.

Back on August 2–5, we described substitution in some cases. The resolver would respond, but swap in a foreign address for specific domains. On August 29, something new appeared as well: the three resolvers didn’t respond anything at all.

The resolvers are still alive, though, and you can verify this in three steps. All three addresses respond to ping. DoT and DoH to Google, Cloudflare, and OpenDNS work from the same vantage point and return real addresses. And the same question about ya.ru, sent to the same three DNS servers on the same port 53 but over TCP, returns real Yandex addresses from all three. Same address, same port, same question. The only thing that differed was the transport.

So it isn’t the resolver that’s being blocked, but a narrow combination: a destination address from the list, the UDP protocol, port 53, and a DNS query inside the packet. Remove any one of these conditions and the packet gets through.

We also found the point where the packet died. A traceroute using a real DNS query to 8.8.8.8 and 1.1.1.1 passed five hops through the provider’s network and cut off right after the last of them, nothing responded beyond that. The same query addressed to Yandex crossed that boundary and continued for three more hops to the traffic exchange point. A plain traceroute to 8.8.8.8, with no DNS inside it, also crossed the boundary and reached Google’s network. In other words, the route worked, but an unencrypted DNS query to the target address didn’t get through the exit from the provider’s network. The measurement itself couldn’t identify which device was responsible. It only showed where the packet disappeared, but not whether it was TSPU, the provider’s own filter, or a filter belonging to a transit provider further up the chain. What pointed at TSPU was that the rule picked out the same three best-known public addresses and reacted to the packet’s content. That looked like a centrally rolled-out configuration, not something one provider set up on its own.

From the same vantage point, on August 29, queries over TCP, DoT, and DoH all got through untouched by this rule. This isn’t something to rely on as a safe fallback. Nothing prevented the rule from expanding to other transports, and subscribers of other providers had DoH disruptions by server name recorded in these same days. This is why our earlier recommendations remain relevant and have become necessary.

From the same home broadband vantage point, over open UDP, Quad9 (9.9.9.9), AdGuard (94.140.14.14), NextDNS (45.90.28.232), ControlD (76.76.2.0), Yandex, and NSDI itself all responded normally. What got hit were the three best-known public DNS addresses, the ones people set instead of their provider’s DNS most often.

We did not find redirection to NSDI at our vantage points

At the home vantage point, this showed up in a single pair of queries. NSDI responded normally for ya.ru with three real Yandex addresses. If our query about ya.ru to 8.8.8.8 was redirected to NSDI, we would have received the same addresses (redirection is set up so that a response does arrive). We received nothing. No redirection occured, the packet was simply dropped.

On the VPS, open UDP worked, and there the responses themselves didn’t line up. Take the five domains where we caught substitution before: signal.org, meduza.io, novayagazeta.eu, te-st.org, and cdnjs.cloudflare.com. Over open UDP from the VPS, Google returned 8.47.69.6 for these domains, while NSDI returned 8.47.69.0 for the same five. And youtube.com, queried through Google over open UDP, responded with real Google addresses, while NSDI refused to respond regarding this domain. In case of redirection, both responses would match.

Both signs above rely on comparing our own responses against each other, and that kind of comparison has a weak spot. During redirection, the return address gets rewritten back. The response arrived as if it came from 8.8.8.8, and there was no way to tell from that who actually put it together. What’s needed is an outside spectator, someone who saw exactly who came to them for a response. Such a spectator exists, and it was built specifically for debugging. Akamai has a service hostname, whoami.akamai.net, that works the opposite way from a normal domain: its server returns not the address of a website, but the address of whoever asked it the question. And the one asking isn’t your computer — it’s the resolver. If you query 8.8.8.8, the resolver goes further down the chain for the response and reaches Akamai’s server under its own identity. That’s how you find out whose network actually served the request.

We asked this hostname through 8.8.8.8 from the home vantage point over TCP (the one open transport to this resolver that still gets through from here), and got back 172.253.83.211, an address belonging to Google. The query reached Google, not any other network. If it had been redirected to NSDI, the returned address would have come from MSK-IX’s networks. This was exactly how ntc.party users caught the substitution in their discussion. What matters here isn’t whether the response matches 8.8.8.8 — it shouldn’t match, since resolvers query authoritative servers from other addresses when going outward. What matters is who owns the network behind the returned address, found through a whois lookup, specifically the netname and org fields.

This doesn’t disprove the users’ reports: the rule is rolling out unevenly, by provider and by region. Our three vantage points simply show different behavior from the same equipment. And they show a pattern worth keeping in mind: on home internet, TSPU filters more aggressively than in data centers. A measurement from a corporate server systematically underestimates what an ordinary home internet subscriber actually sees.

NSDI refuses the same way it refused on August 3

We queried both NSDI addresses directly, 195.208.4.1 and 195.208.5.1. Both responded to youtube.com and whatsapp.com with NXDOMAIN (“no such name”) carrying the aa flag and an empty AUTHORITY section. The aa flag declared: “I own this zone and I’m speaking about it as its authority.” It can be seen in both responses, even though Google holds the youtube.com zone and Meta holds whatsapp.com — NSDI has nothing to do with either one. An empty AUTHORITY section meant the server had not attached an SOA record. SOA is a zone’s administrative record, its passport: which server is the primary for the zone, who administers it, and how long responses about this zone can be cached. The standard requires attaching an SOA record to a “no such name” refusal, so the client knows exactly who said “no” and how long to remember it. Here, nobody signed off on the refusal. For ya.ru, the same servers respond with three real addresses and without the aa flag. NSDI filters selectively, and its signature is exactly what ntc.party users described last week: an NXDOMAIN refusal, the aa flag, an empty AUTHORITY section.

But this same refusal also showed up in our August 2–5 measurement, at all seven vantage points we measured from at the time: Moscow, St. Petersburg, Spain, Germany, Finland. Where you ask from doesn’t matter: NSDI itself is doing the filtering, not anything along the route to it.

Let’s break this down.

Out of the 27 domains on our list (19 from the earlier study plus 8 Wikipedia domains), NSDI refuses exactly two: youtube.com and whatsapp.com. We can confirm this, and it was already the case on August 3, three weeks before the August 26 wave. It resolves the other 25 domains, including ones blocked in Russia. For five of them it substitutes its own address from the 8.47.69.x range, and for the rest it returns real addresses.

As for redirecting queries meant for other resolvers over to NSDI — we did not find that at our vantage points. So what’s actually new in the last days of August is that, according to user reports, traffic from people who had switched away from their provider’s DNS started getting routed to it.

From the user’s side, these two cases look identical. Someone whose provider honestly forwards queries to NSDI, and someone whose queries to Google got redirected along the way, both get the same refusal from the same server.

Everything else is repeating as it did on August 3

Five domains — signal.org, meduza.io, novayagazeta.eu, te-st.org, and cdnjs.cloudflare.com — resolve from Russian vantage points not to their real addresses, but to addresses from the 8.47.69.x and 8.6.112.x ranges, which don’t belong to these sites. The third octet depends on which resolver you ask: .6 for Google, .8 for AdGuard, .0 for the rest. In our earlier analysis, we split this into three classes based on how each resolver responded and from which vantage points.

All three anomalies reproduced on August 29 in exactly the same form: same resolver, same vantage point, same address in the reply. Google returned 8.47.69.6 from all three of our Russian vantage points. Cloudflare returned 8.47.69.0 only from Moscow. AdGuard returned 8.47.69.8 only from the St. Petersburg VPS. cdnjs.cloudflare.com, which wasn’t blocked, still got caught by some resolvers and not by others. The individual responses that flicker between the real address and the substituted one are exactly the ones whose repeatability was already partial in early August, ranging from 60% to 93%.

We added eight more Wikipedia domains to our check after the overnight outage on August 28, which we covered separately on August 28. On August 29 we queried them through eleven resolvers (Google, Cloudflare, Quad9, OpenDNS, AdGuard, NextDNS, ControlD, Mullvad, LibreDNS, Yandex, NSDI) over four transports from the VPS (open UDP, DoT, DoH, DoQ) and over three from the home vantage point. Everywhere a resolver responded at all, it returned a real Wikimedia address: 185.15.58.x, 185.15.59.x, or 208.80.153.x, depending on which of Wikimedia’s data centers the query landed on. So far, no substitution. We didn’t measure during the night of the outage, so this doesn’t tell us anything about that.

How to check this yourself

The picture differs by provider. On our home connection, open DNS to the three resolvers (Google, Cloudflare, and OpenDNS) doesn’t work, while at both VPS servers, in St. Petersburg and in Moscow, everything works. So check your own network.

Ask 8.8.8.8 for the address of a blocked site, for example, dig www.youtube.com @8.8.8.8 on Linux and macOS, or nslookup youtube.com 8.8.8.8 on Windows. An NXDOMAIN response (on Windows, “Non-existent domain”) means substitution. No response at all means open DNS to that address doesn’t get through on your network. In that case, repeat the query over TCP: dig +tcp www.youtube.com @8.8.8.8, or on Windows, nslookup -vc youtube.com 8.8.8.8. If the TCP query gets a response, the transport is being cut, not the resolver. This is one way to check things, not a way to get around the block: a query over TCP is just as open and just as visible on the route as any other.

So what’s the bottom line? Is there blocking?

We still don’t know, and we’re continuing to dig. The three classes of anomaly we found each have a different explanation, and we haven’t found one explanation that covers all three: for Google, the effect hits both Russian nodes equally regardless of encryption protocol. For Cloudflare as a resolver, it hits only one of the two Russian nodes, and changing the client’s declared subnet doesn’t change the response.

The content at the substituted address turned out to be genuine and complete. That said, loading the same page normally in a browser, over the same home connection (without manually specifying the IP), was slow and lost some images and layout, so something is interfering with the site’s operation, just not completely and not for every request.

It looks like some requests don’t go through during a normal page load, even though the main address and main document load in full. We can’t say with 100% certainty whether this shows signs of blocking. We’ve written before about similar behavior (blocking of the genuine address at the SNI level), and the anomaly we found here backs up that earlier piece.

Decentralized systems (OpenNIC, Namecoin, Emercoin, GNU Name System), alternative protocols (DNSCrypt, ODoH), and lesser-known regional resolvers fall outside the scope of this study; they require different tooling and a separate investigation.

Technical recommendations

• Self-hosted DoH via a reverse proxy. Route requests through your own VPS. Traffic gets proxied through a web server (Nginx or Caddy) on port 443, with a legitimate TLS certificate, to a locally running dnscrypt-proxy. For TSPU’s signature analysis, this connection is indistinguishable from ordinary web browsing.
• Alternative protocols (ODoH). Deploy Oblivious DoH. This technology uses an intermediary proxy server to guarantee cryptographic separation: the proxy knows the client’s IP address but never sees the DNS request itself, while the final resolver sees the request but doesn’t know the client’s IP address.
• Traffic encapsulation (XTLS/obfuscation). Wrap system DNS requests (port 53) inside tunnels disguised as a TLS 1.3 handshake (VLESS+Reality protocols). This hides not just the destination domain from DPI but the DNS protocol’s own fingerprint (ALPN), making L7 filtering impossible.
• Local resolvers and split tunneling. To work around geo-blocks on Russian resources (banks, government services) while simultaneously bypassing censorship, we recommend using dnsmasq on home routers (OpenWrt, Keenetic). Direct requests to the .ru zone to go through the provider’s own DNS, and route everything else through an encrypted local tunnel (DoH/DNSCrypt).
• Drop plain DNS. Basic requests over port 53 are intercepted by TSPU for response spoofing (Layer 3). Configuring DoH (DNS over HTTPS) in modern browsers, or at the OS level, is the minimal baseline step. It doesn’t hide the SNI, but it does rule out getting served stub IPs.