On October 7, 2026, the Russian hosting provider Selectel blocked the account of the private DNS service Xbox DNS at the request of TsMU SSOP (the Center for Monitoring and Management of the Public Telecommunications Network, part of the structure of Roskomnadzor, also known as RKN, Russia’s internet and media regulator). The next day, TsMU SSOP sent the hosting provider a “mandatory order” with a deadline of just over 24 hours.

Xbox DNS’s case is part of a broader pattern. Pressure on hosting providers and their clients (developers of various services and owners of personal servers) has been building since December 2025. The authorities have clearly used TSPU (Russian “Technical Means for Countering Threats,” the DPI equipment installed in ISP networks) to fight private DNS services. At our residential broadband vantage point in St. Petersburg, the old address of the Zapret DNS service doesn’t respond over any protocol. From our other four vantage points (including two data centers in Russia), the server does respond, so it is up and running.

Below, we look at how the authorities pressure private services and their clients through hosting providers, what our measurements on October 11, 2026 showed, and what developers can do about it.

What happened

• December 2025. As Habr (a major Russian tech community site) reported, RKN sent the hosting provider Aeza a list of addresses in its network and demanded that Aeza remove VPNs from them within 24 hours. Otherwise, RKN threatened to block the entire hosting provider. Aeza required its clients to send a screenshot proving they had deleted the VPNs.
• June 2026. As part of the “Antifraud 2.0” package, the State Duma passed a ban on hosting providers supplying capacity for censorship circumvention tools. We analyzed these amendments in May. Putin signed Federal Law No. 210-FZ of June 26, 2026 “On Amendments to the Federal Law ‘On Communications’ and Certain Legislative Acts of the Russian Federation.”
• August–September 2026. RKN shifted from blocking individual VPNs to blocking entire hosting subnets. A hosting provider forwarded a TsMU SSOP order to the owner of a personal VPS. After the State Duma elections, at least ten VPN services reported a new wave of blocking. On September 23, Xbox DNS reported that UDP DNS queries to its two main addresses had stopped getting through. On September 30, it reported that three more of its proxy addresses had become unreachable from Russia.
• October 1. The Ministry of Digital Development (Mintsifry) published the “Antifraud 3.0” draft law for public discussion. The bill includes a one-year ban on renting servers (more on this below).
• October 7–9. Selectel blocked the Xbox DNS account at the request of TsMU SSOP (more on this below). On October 9, the Zapret project (an open-source DPI circumvention tool) launched its own Zapret DNS service.

Private DNS services with proxies (like Xbox DNS) and their difference from VPNs

A regular DNS resolver takes a website name and returns its real address. A DNS service with a proxy (Smart DNS) returns the address of its own proxy server for domains on a specific list. The browser or app connects to that proxy server, and the proxy forwards the connection to the real website. The website sees the request coming from the service’s proxy server instead of from Russia. Such a DNS service resolves all other domains as usual, and their traffic goes directly. For example, Comss DNS returns the address of its proxy instead of the real address of chatgpt.com, as the author of an article on Habr showed.

A regular VPN wraps all of a device’s traffic in an encrypted tunnel. Smart DNS redirects only requests to specific websites and adds no encryption of its own. As a result, users don’t need a VPN to reach services that Russia hasn’t blocked but that have withdrawn from Russia on their own. They simply enter the service’s DNS address in the settings of their device, phone, router, or game console.

Xbox DNS started as a way to connect to the Xbox console network (the service has no connection to Microsoft). Later, it opened access to popular AI services and other resources that Russia doesn’t block but that have cut off users from Russia themselves. People use such services as one way to get around restrictions, much like Cloudflare’s free WARP. In its order, TsMU SSOP described Xbox DNS resources as a means of accessing restricted information “using a VPN service.”

We checked what some private DNS services returned for AI domains on October 11.

Resolver	What it returns for chatgpt.com, claude.ai, gemini.google.com
NSDI, MSK-IX Public DNS	the websites’ real addresses, but the websites themselves restricts access for users from Russia
Xbox DNS	0.0.0.0: a placeholder address that accepts no connections, so the app gets an error immediately
Zapret DNS, GeoHide, Comss DNS	addresses of their own proxy servers
DNS-AI	proxy addresses for chatgpt.com and claude.ai, but only at the broadband and data center vantage points in St. Petersburg; real addresses at the Moscow data center and the EU vantage points

From our residential broadband vantage point in the EU, we connected directly to the Xbox DNS proxy and tried to reach various websites. The proxy connected us only to the Xbox server and refused to connect to chatgpt.com, example.com, nvidia.com, and meduza.io. In other words, it works from its own allowlist.

The service needs this list because some people misuse open proxies. Xbox DNS itself wrote that others resold its proxies in their own paid services and ran WARP traffic through them. On September 30, the service closed the port used for VLESS tunnels and domain fronting. With domain fronting, the client names one website to the proxy but requests a different one inside the encrypted connection. This way, the client bypasses blocking for free on someone else’s server.

How TsMU SSOP forces hosting providers to fight circumvention tools

On October 7, Selectel blocked the Xbox DNS account. The hosting provider told the service that it had received information from TsMU SSOP about “means of circumventing blocking” on the service’s addresses. Selectel cited clause 1.1 of its terms of use (archived copy), which prohibits actions that go against orders from government authorities. We identified Selectel as the hosting provider using open data: whois, autonomous system numbers, and the DNS servers of the xbox-dns.ru domain. That same evening, Xbox DNS restored some of its services. On October 8, TsMU SSOP (a division of the General Radio Frequency Center, or GRFC, an agency subordinate to RKN) sent Selectel a “mandatory order.” The order required Selectel to stop providing capacity on the service’s addresses by 16:00 on October 9 and to report back by the same deadline.

Government Resolution No. 1667 approved the Rules for Centralized Management of Communications Networks, which have been in force since March 1, 2026. The Rules list hosting providers among the parties that receive orders from TsMU SSOP. They require these parties to take all necessary measures to comply within the deadline set in the order itself. The Rules give hosting providers no way to challenge an order.

Xbox DNS had been closing loopholes on its own since December 2025. Still, Selectel blocked its account at the first signal from TsMU SSOP, even before the official order arrived. So even formal compliance doesn’t guarantee that the regulator won’t classify a service as a circumvention tool.

The authorities want to fine hosting providers and their clients

A hosting provider that fails to comply with a TsMU SSOP order is liable under Part 1 of Article 13.45 of the Code of Administrative Offenses (KoAP). A legal entity pays a fine of 40,000 to 120,000 rubles (about $480 to $1,450), and an official pays 10,000 to 30,000 rubles (about $120 to $360). In addition, since February 1, 2024, hosting providers may not operate without an entry in the RKN registry. For this violation, Part 1 of Article 13.54 of KoAP imposes a fine of 600,000 to 1 million rubles (about $7,240 to $12,070) on legal entities. For a hosting provider, cutting off a client is cheaper than risking its relationship with the regulator.

A hosting provider’s client has no appeal procedure at all: you either accept the demands or leave.

In the “Antifraud 3.0” draft law, the Ministry of Digital Development proposes making clients legally liable too. The bill would create a registry of people who host tools for accessing blocked resources and fail to comply with Article 15.8 (of the Federal Law “On Information”). If the bill passes (and there is little doubt it will), hosting providers will have to identify clients before renting them servers, ask about the intended use of the servers, and check clients against the registry. Clients on the registry will be denied capacity for one year. At the same time, the bill does not explicitly name installing a VPN or proxy as grounds for the ban. If the bill passes, its provisions will take effect on March 1, 2028. The bill is currently under public discussion and has not yet been submitted to the State Duma.

The authorities pressure owners of personal servers

In August 2026, a hosting provider forwarded a TsMU SSOP order to the owner of a VPS. The server connected two of the owner’s local networks via WireGuard and ran no public service. The TsMU order matches the regulator’s letter about Xbox DNS almost word for word. It has the same references to the law “On Communications” and the Rules, and the same wording: “stop using computing capacity to counteract (hinder) access restrictions.” The hosting provider’s support team told the client that it didn’t know what criteria TsMU SSOP uses for its checks. The hosting provider demanded that the owner disable WireGuard completely, so the VPS owner moved to another hosting provider.

This means that anyone who runs a VPN server for personal use at a Russian hosting provider can fall under the same procedure as a public service.

What we tested and how

We took measurements on October 11, 2026, from five vantage points:

• residential broadband in St. Petersburg;
• a data center in Moscow;
• a data center in St. Petersburg;
• baseline: residential broadband in the EU;
• baseline: a data center in the EU.

Only the three data center vantage points had IPv6, so we tested the resolvers’ IPv6 addresses only from there.

We queried each resolver over four transports, where supported: UDP on port 53, TCP on port 53, DNS over TLS (port 853), and DNS over HTTPS (port 443). We requested A records. We queried 30 domains on the resolvers’ primary addresses and 14 domains on secondary addresses, old addresses, and IPv6 addresses. We grouped the domains as follows:

• messengers: whatsapp.com, telegram.org, signal.org;
• media: meduza.io*, bbc.com, novayagazeta.eu;
• technical: protonvpn.com, te-st.org, github.com;
• control: microsoft.com, nvidia.com, example.com, ya.ru, vk.ru;
• “throttled”: youtube.com, apple.com;
• CDN: cdnjs.cloudflare.com, fastly.net, ajax.googleapis.com, cdn.jsdelivr.net;
• Wikipedia: ru.wikipedia.org, en.wikipedia.org, www.wikipedia.org, upload.wikimedia.org;
• AI: chatgpt.com, claude.ai, gemini.google.com;
• geo-restricted services: xsts.auth.xboxlive.com, open.spotify.com;
• utility: whoami.akamai.net.

We recorded the responses themselves and the latency and, when there was no response, the error type. The utility domain whoami.akamai.net shows the address the resolver used to fetch the answer upstream. We ran each vantage point three times. In most cases, our conclusions rely on the most frequent of the three responses. Where responses changed from run to run, we report the share of each response.

Resolver	Addresses	Server location	Network
Google, Cloudflare (baseline)	8.8.8.8, 1.1.1.1	anycast	AS15169, AS13335
NSDI	195.208.4.1, 195.208.5.1	Moscow	AS41740
MSK-IX Public DNS	62.76.76.62	Moscow, anycast	AS43832
Xbox DNS, current	111.88.96.54, 111.88.96.55, 111.88.96.56 and IPv6	Moscow	AS50340, Selectel
Xbox DNS, old	111.88.96.50, 111.88.96.51; 87.228.47.200, 87.228.47.201	Moscow; St. Petersburg	AS50340, AS49505, Selectel
Zapret DNS, current	83.217.211.149	Netherlands	AS41745, network registered in Russia
Zapret DNS, old	144.31.82.230	Finland	AS207957
Comss DNS	83.220.169.155, 212.109.195.93	Moscow	AS29182
DNS-AI	192.144.59.14, 186.246.49.127	Moscow and Leningrad Region	AS48282, AS35278
GeoHide	193.233.112.67, 193.233.112.68	Finland	AS34665

We took the list of private DNS services from Zapret GUI and the old Xbox DNS addresses from the service’s channel. We sent only individual queries to published addresses and didn’t scan ports.

Our measurement has limitations: one vantage point of each type, no mobile vantage point, and a single day. So everything we say about blocking applies to our vantage points on October 11.

The old Zapret DNS IP address is blocked

At our residential broadband vantage point in St. Petersburg, the old Zapret DNS address 144.31.82.230 didn’t respond for any of the 14 domains. UDP queries got no response, and TCP connections failed to establish on port 53, for DoT, and for DoH: the packets are silently dropped. From the other four vantage points (including both data centers in Russia), the same address responded over all transports.

The block covers the entire address, regardless of the name. TCP on port 53 doesn’t get through either, even though it carries neither TLS nor the service name. Most likely, TSPU is blocking the address.

The new address 83.217.211.149, with the same name dns.zapret.moe, gets through over DoT and DoH from the same vantage point.

How the Xbox DNS addresses that the service reported as blocked respond

On October 11, at our residential broadband vantage point in St. Petersburg, the old Xbox DNS addresses 111.88.96.50 and 111.88.96.51 responded over UDP, TCP, and DoT, just as they did at the other vantage points. The Xbox DNS proxy addresses 87.228.47.194, 87.228.47.198, and 87.228.47.202 (which the service said it had lost on September 30) accepted connections on port 443 from both the St. Petersburg broadband vantage point and the EU broadband vantage point.

At our St. Petersburg broadband vantage point, we didn’t detect the blocking that the service reported. The rules for these addresses may have been lifted, or they may not apply everywhere: RKN rolls them out across TSPU unevenly. We see something similar with Google and Cloudflare: on August 29, UDP queries to them failed from this vantage point, but on October 11 they went through.

The DoT port on the old addresses 87.228.47.200 and 87.228.47.201 is closed for all five vantage points, including both in the EU. This is a configuration choice by Xbox DNS itself.

Where Xbox DNS gets its answers

A whoami.akamai.net query through Xbox DNS showed that the service fetches answers from the addresses 193.232.166.60 and .61 in the MSK-IX network (the Moscow Internet Exchange) and sends some queries through Cloudflare. At all our vantage points, MSK-IX Public DNS sends its upstream queries from addresses that also end in .60 and .61, while NSDI uses different addresses. Most likely, Xbox DNS gets its answers from an MSK-IX Public DNS node that our vantage points don’t reach. This matches the service’s statement that “DNS will serve MSK-IX.”

What NSDI returns

For youtube.com and whatsapp.com, NSDI (Russia’s National Domain Name System, the state-run DNS infrastructure) returned “no such domain” (NXDOMAIN) with the authoritative answer flag set and no SOA record. It responded this way at all five vantage points, including both in the EU. This is the same signature we described in August. MSK-IX Public DNS and Xbox DNS return real addresses for the same domains, so Xbox DNS doesn’t get its answers from NSDI.

Why MSK-IX Public DNS responds poorly to an EU data center

From our EU data center vantage point, MSK-IX Public DNS answered 37 of 90 queries over UDP and 39 of 90 over TCP. The domain makes no difference: answers and gaps come in streaks over time. For example, seven domains in a row got no answer, and then six in a row did. “No answer” means silence: MSK-IX sends no refusal, and the response simply never arrives. The same MSK-IX node answered all queries from EU residential broadband. The other Russian resolvers, including NSDI, responded normally from the EU data center vantage point.

Possible explanations:

• A restriction on the path to the MSK-IX node. Russia restricts the networks of several large foreign hosting providers, as users described on ntc.party (a forum about censorship circumvention) and on Habr. These restrictions work intermittently. Queries to the public DNS node and to the NSDI node take different paths, so the restriction may have kicked in on the path to MSK-IX but not on the path to NSDI.
• MSK-IX itself rate-limits queries from hosting networks. Such a limit would also produce silence instead of refusals, as well as streaks over time. Our query rate was low: no more than one query every 7.6 seconds.
• Shutting out external observers. Researchers and monitoring systems usually measure from data centers. Restricting these networks makes it harder to observe the Russian internet from outside. We saw something similar during the elections, when the Remote Electronic Voting portal blocked server and foreign addresses.

Our data can’t distinguish between the first two explanations. For anyone observing the Russian internet from abroad, the result is the same: MSK-IX Public DNS responds unreliably to a foreign data center.

Why Russian users get different Cloudflare addresses

For websites behind Cloudflare (including meduza.io, signal.org, and chatgpt.com), Russian resolvers returned the addresses 8.47.69.0 and 8.6.112.0 from all five vantage points. These resolvers are NSDI, MSK-IX Public DNS, Xbox DNS, Comss DNS, and GeoHide. Google and Cloudflare returned neighboring addresses from the same blocks (for Google, 8.47.69.5 and 8.6.112.5). However, they returned these addresses only to the Russian vantage points and gave the EU vantage points different addresses. We already recorded this anomaly in August.

Spoofing by Russian resolvers can’t explain this. RKN doesn’t control Google, yet Google returns these addresses only to queries from Russian vantage points. So the choice is made by a party that sees the client’s country, most likely Cloudflare itself. For meduza.io, novayagazeta.eu, and signal.org (all blocked in Russia), no Russian resolver returned a placeholder: they all returned the same Cloudflare addresses.

The ARIN registry shows that Level 3 (Lumen) transferred both blocks, 8.47.69.0/24 and 8.6.112.0/24, to Cloudflare in 2019. The abuse contact for 8.6.112.0/24 is [email protected], which ties the block to WARP. These blocks don’t appear in Cloudflare’s published list of proxy addresses, but the company’s documentation states that it also uses other ranges for various products and services. On the Cloudflare forum, users reported that the TLS connection and headers go through these addresses, but content downloads hang.

In June 2025, Cloudflare reported that since June 9, 2025, Russian ISPs have allowed users to download only the first 16 KB from websites under its protection. Russian authorities gave the company no explanation. Cloudflare has not explained why Russian users get separate addresses.

This setup is convenient for the Russian side. If all websites behind Cloudflare sit on two blocks of 256 addresses for Russian users, it’s easier to throttle or block them all at once.

Why services under pressure restrict themselves

After the TsMU SSOP order, Xbox DNS returns 0.0.0.0 for chatgpt.com, claude.ai, and gemini.google.com. This address accepts no connections. Xbox DNS responds this way at all our vantage points. MSK-IX Public DNS and Cloudflare (where the service gets its answers) return real addresses for these domains. So Xbox DNS sets 0.0.0.0 itself.

Why the service cut off AI services. TsMU SSOP demanded that the service stop using capacity to circumvent restrictions. AI services sit behind large CDNs: in our measurement, chatgpt.com resolves to Cloudflare addresses. Domain fronting usually runs through such CDNs. The service probably closed exactly the routes that made its infrastructure easiest to use as a VPN tunnel.

Why the DNS returns 0.0.0.0 instead of the real address. Hypotheses:

• 0.0.0.0 is a common placeholder for blocking domains: Pi-hole, for example, returns it for blocked queries by default. Users usually set it up on their own devices to block ads. Here, the service sets it on its own server under pressure;
• the app gets a refusal immediately and never reaches the website, which would otherwise respond with its own unsupported-region error;
• an inspector can see that the service returns nothing for these domains.

The service has probably kept Xbox Live, the reason it was created in the first place.

Recommendations for developers of private DNS services, proxies, and VPNs

1. Spread your infrastructure across different hosting providers and accounts. Xbox DNS put DNS, encrypted DNS, and proxies on different addresses, but a single account block took everything down at once. Keep DNS, proxies, the website, and billing with different hosting providers.
2. Prepare your move in advance. Give users a hostname for DoH and DoT instead of a bare IP. Keep backup addresses and a mechanism that pushes them to clients automatically. Then users won’t notice when the address changes.
3. Vet hosting providers before renting. Look up their autonomous system in public discussions on ntc.party and Habr, and test the reachability of their networks from Russian networks yourself. Choose small, low-profile hosting providers outside Russian jurisdiction, as we advised in May. Distribute nodes across several hosting providers: a small hosting provider’s network is easier to block entirely.
4. Use obfuscated protocols and keep a backup one ready. VLESS+Reality, Hysteria2, Shadowsocks-2022, and AmneziaWG are harder to detect than plain WireGuard, which got the VPS owner in our example caught.
5. Build several resolvers into your apps. If one doesn’t respond, the app switches to another automatically. Use well-known public DNS services, lesser-known ones, and your own.
6. Test your service from mobile and home connections, since they behave differently. Repeat queries and count the share of responses instead of relying on a single response.