Does Cloudflare DNS work in Russia or not?

Resolving works. It's important to separate two things: Cloudflare as DNS hosting (DNS only mode, 'grey cloud') and Cloudflare as proxy/CDN ('orange cloud'). DPI blocks at Russian ISPs hit proxied traffic - the TLS handshake stalls or fails. Pure DNS hosting isn't directly affected by these blocks. But then the question: if you're not turning the proxy on anyway, what's left of the move? A panel, an API and fast TTLs - I saw no point adding a third service to the chain for that.

Do I need to change NS records when switching hosting?

Most often - no, and this is the main mistake I see. Switching hosting means changing the A record (the IP address), not changing DNS hosting. My move from REG.RU hosting to Beget: the domain stayed at the registrar, the DNS zone stayed at the registrar, only the A records of dimaserbun.ru and www changed to the new IP. You touch NS only if you're deliberately moving the zone itself - to the host or to external DNS.

What TTL should the A record have?

In normal life the registrar's default is fine (at REG.RU it's 14400 seconds, 4 hours). Before any move - lower it to 300 seconds 24-48 hours before the switch: the old TTL must have time to expire at resolvers. Then the IP change propagates in minutes, not half a day. After the move you can put the TTL back.

Is DNS better kept at the registrar or at the host?

For a small site there's no speed difference: DNS resolving is cached, the user hits it rarely. The registrar has one advantage: you can change hosting as often as you like without touching the zone - only the A record. The host has another: one panel, and some records (SSL validation, subdomains) the host writes itself. I keep it at the registrar precisely for independence from the host.

Does changing DNS or IP affect SEO?

In 90% of cases - invisible to search engines. Occasionally a hosting IP change triggers a temporary recompute: positions dip for 2-3 weeks and come back. My move in April went without a dip - but the domain was young, there wasn't much to lose. Reduce risk with mechanics: lower TTL in advance, switch, verify 200 responses and the certificate, check Yandex Webmaster and GSC a few days later.

When is Cloudflare DNS actually justified?

A global audience where Russia is a small share; a real DDoS history where you need proxying; load balancing and geo-routing; frequent infrastructure experiments where the API and 300-second TTLs save time every day. For a local Russian B2B services site, usually none of these apply.

DNS for a Russian Site: Why I Didn't Move It to Cloudflare

When you write about Cloudflare in Russia, the most common follow-up question isn’t about CDN but about DNS: ‘and the zone - where do you put that, also not on Cloudflare?’. Here’s the full answer: on both my projects DNS lives at the registrar, I’ve never changed the NS records, and the spring move between hosting providers came down to one A record. Let’s break down why, and when Cloudflare DNS does make sense.

In brief

Registrar, DNS hosting and web hosting are three different roles. They can and often should be kept separate.

Switching hosting means changing the A record, not the NS. The zone stays put.

Before a move, lower TTL to 300 seconds 24-48 hours in advance - the switch propagates in minutes.

Cloudflare DNS by itself resolves in Russia; it’s proxied traffic that’s under DPI blocks.

But for a local RU site, moving the zone to Cloudflare adds a point of failure and gives almost nothing.

Three roles everyone confuses

A domain has three independent roles, and I keep them separated deliberately:

Role	Who I use	What it does
Registrar	REG.RU	Domain ownership, renewal, NS delegation
DNS hosting	REG.RU (registrar’s DNS)	Stores the zone: A, CNAME, MX, TXT
Web hosting	Beget	Serves the site at the IP from the A record

The domain dimaserbun.ru was bought at REG.RU for 169 rubles. Hosting was REG.RU at first too, then moved to Beget. The DNS zone was at the registrar and still is.

The confusion starts when these roles get glued together. The classic: someone switches hosting and first thing moves the NS records to the new host ‘because the guide says so’. Now the zone lives at the host, and the next move means transferring the entire zone with all the MX and TXT records, not changing one IP. Every extra transfer is a chance to lose a mail record or SPF.

What my move between hosts looked like

In April 2026 I moved the site from REG.RU hosting (Host-A, 388 RUB/month) to Beget (~400 RUB/month): REG.RU turned out slower and with more restrictions, and the site was young - painless to move. The entire DNS part of the move took two records and one wait:

A day before the switch - lowered the A records’ TTL from 14400 seconds (REG.RU default, 4 hours) to 300 seconds. This is the mandatory step people skip most often: until the old TTL expires at resolvers around the world, they’ll keep serving the old IP. Lowered in advance means the maximum ‘divergence’ at switch time is 5 minutes, not 4 hours.

At switch time - changed the A records for dimaserbun.ru and www.dimaserbun.ru to the Beget IP. That’s it. Didn’t touch NS, didn’t move the zone, didn’t re-register the domain.

Then - verifying 200 responses from the new IP, issuing Let’s Encrypt on the Beget side, watching Yandex Webmaster and GSC. No position dip after the move.

This is the argument for ‘zone at the registrar’: hosting became a consumable. Don’t like it - change the A record and leave. The host doesn’t hold you hostage via DNS.

What Cloudflare DNS would give - and why I passed

An honest list of what Cloudflare DNS actually gives for free:

Fast TTLs by default - changes propagate in minutes without manual preparation. Registrars’ default TTLs are an hour to four.
API - the zone can be changed by script, handy for frequent experiments.
Panel - the best in the industry, no argument there.
One step from the proxy - flip the ‘orange cloud’ and get CDN, cache and DDoS protection.

That last point is also the main trap for a Russian site. Let me take it apart carefully.

Cloudflare DNS and Cloudflare proxy are different things. The DPI blocks at Russian ISPs, which I wrote about separately, hit proxied traffic: the TLS handshake to Cloudflare’s edge servers stalls or fails. If you keep only the zone on Cloudflare in ‘DNS only’ mode, your traffic goes straight to your IP, and these blocks don’t touch it.

But then look at what’s left of the move: panel, API and TTLs. And what gets added:

A third entity in the chain. It was: registrar + host. Now: registrar + Cloudflare + host. Each entity is a separate account, a separate point of failure, a separate ‘where was this configured again?’ a year later.
Dependence on a service outside your control. For a site that earns money from a Russian audience, putting critical infrastructure on a service whose traffic in this country is already being throttled by DPI is a strange bet. Today they throttle the proxy; nobody knows what happens tomorrow, and the zone is the thing without which the site doesn’t resolve at all.
The temptation of ‘since we’ve moved - let’s turn the proxy on’. The orange cloud is one click away. And now part of your users on mobile carriers see an eternal loading spinner while you spend a week hunting for ‘why did conversion drop on Yandex Direct traffic’.

The gain doesn’t outweigh. I need fast TTLs twice a year - and that’s solved by manually lowering them a day before the work. An API for a zone of four records isn’t needed at all.

Practical checklist: moving hosting without changing DNS

Confirm where the zone lives: dig NS yourdomain.ru. If it’s the registrar’s NS - the zone is with them, great.
24-48 hours before the move, lower the A records’ TTL to 300 seconds.
Prepare the new hosting: files, database, SSL groundwork.
Change the A records (@ and www) to the new IP.
Check responses: curl -I against the new IP with a Host header, then by domain.
Issue SSL on the new hosting, verify the http → https and www → non-www redirects.
A few days later - Yandex Webmaster and GSC: there should be no crawl errors.
Put the TTL back if you want to ease the load on resolvers.

Notice what’s not on the list: NS records, a ‘domain transfer’, a letter to the registrar. Switching hosting is a one-line operation in the zone.

When Cloudflare DNS is the right choice

So this doesn’t look like ideology, here are the scenarios where I’d move the zone to Cloudflare myself:

A global project. Audience worldwide, Russia is single-digit percent. Proxy goes on, CDN and DDoS protection for free, DNS in the same place - logical.
A site under real attacks. Media, a competitive niche with a DDoS history - proxying through Cloudflare remains the cheapest shield, and the zone moves along with it.
Infrastructure as daily work. Dozens of subdomains, staging environments, load balancing - the API and instant TTLs save hours every week.

For a local Russian B2B services site - cleaning, furniture, construction - usually none of these fire. Zone at the registrar, A record pointing at the host, a Russian CDN if you need one at all: what Beget CDN does on shared - I broke it down with numbers.

Useful links

Is Cloudflare blocked in Russia in 2026? - about DPI, blocks and CDN choice.
Beget CDN on shared: what it actually does - Lighthouse 60 → 94 without a VPS and without touching NS.
OPcache on shared hosting - another infrastructure detail that ruins your day.

If you’re unsure where to keep your zone, or planning a zero-downtime hosting move - message me in Telegram @dimik90. I handle infrastructure decisions as part of a one-off audit and SEO services.