Cloudflare DNS fonctionne en Russie ou pas ?

La résolution fonctionne. Il faut séparer deux choses : Cloudflare comme hébergement DNS (mode DNS only, 'nuage gris') et Cloudflare comme proxy/CDN ('nuage orange'). Les blocages DPI chez les FAI russes frappent le trafic proxifié - le handshake TLS traîne ou échoue. L'hébergement DNS pur n'est pas directement touché par ces blocages. Mais alors la question se pose : si on n'active pas le proxy de toute façon, que reste-t-il du transfert ? Le panneau, l'API et des TTL rapides - ajouter un troisième service dans la chaîne pour ça, je n'y ai pas vu de sens.

Faut-il changer les enregistrements NS quand on change d'hébergeur ?

Le plus souvent - non, et c'est l'erreur principale que je vois. Changer d'hébergeur, c'est changer l'enregistrement A (l'adresse IP), pas l'hébergement DNS. Ma migration de l'hébergement REG.RU vers Beget : le domaine est resté chez le registrar, la zone DNS est restée chez le registrar, seuls les enregistrements A de dimaserbun.ru et www ont changé vers le nouvel IP. On ne touche aux NS que si on transfère consciemment la zone elle-même - vers l'hébergeur ou un DNS externe.

Quel TTL mettre sur l'enregistrement A ?

En temps normal, le défaut du registrar convient (chez REG.RU c'est 14400 secondes, 4 heures). Avant toute migration - abaisser à 300 secondes 24-48 heures avant le basculement : l'ancien TTL doit avoir le temps d'expirer chez les résolveurs. Alors le changement d'IP se propage en minutes, pas en une demi-journée. Après la migration, on peut remonter le TTL.

Le DNS, mieux vaut le garder chez le registrar ou chez l'hébergeur ?

Pour un petit site, aucune différence de vitesse : la résolution DNS est mise en cache, l'utilisateur la sollicite rarement. Chez le registrar, un avantage : on peut changer d'hébergeur autant qu'on veut sans toucher la zone - juste l'enregistrement A. Chez l'hébergeur, un autre : un seul panneau, et une partie des enregistrements (validation SSL, sous-domaines) est posée par l'hébergeur lui-même. Je garde chez le registrar précisément pour l'indépendance vis-à-vis de l'hébergeur.

Changer de DNS ou d'IP influence le SEO ?

Dans 90 % des cas - invisible pour les moteurs. Rarement, un changement d'IP d'hébergement déclenche un recalcul temporaire : les positions baissent 2-3 semaines puis reviennent. Ma migration en avril s'est passée sans baisse - mais le domaine était jeune, il n'y avait pas grand-chose à perdre. Réduisez les risques par la mécanique : abaisser le TTL en avance, basculer, vérifier les réponses 200 et le certificat, regarder Yandex Webmaster et la GSC quelques jours après.

Quand Cloudflare DNS est-il quand même justifié ?

Audience globale où la Russie est une petite part ; vrai historique DDoS où le proxy est nécessaire ; répartition de charge et routage géographique ; expérimentations d'infrastructure fréquentes où l'API et un TTL de 300 secondes font gagner du temps chaque jour. Pour un site B2B local russe de services, aucun de ces points n'est habituellement rempli.

DNS d'un site russe : pourquoi je ne l'ai pas transféré sur Cloudflare

Quand on écrit sur Cloudflare en Russie, la question retour la plus fréquente ne porte pas sur le CDN mais sur le DNS : ‘et la zone, on la met où, pas sur Cloudflare non plus ?’. Je réponds en détail : sur mes deux projets, le DNS vit chez le registrar, je n’ai jamais changé les enregistrements NS, et la migration de printemps entre hébergeurs s’est résumée à un seul enregistrement A. Je décortique pourquoi, et quand Cloudflare DNS a quand même du sens.

En bref

Registrar, hébergement DNS et hébergement web - trois rôles différents. On peut et on doit souvent les séparer.

Changer d’hébergeur, c’est changer l’enregistrement A, pas les NS. La zone reste en place.

Avant une migration, abaissez le TTL à 300 secondes 24-48 heures avant - le basculement se propage en minutes.

Cloudflare DNS en soi se résout en Russie ; sous blocages DPI - le trafic proxifié.

Mais pour un site RU local, transférer la zone sur Cloudflare ajoute un point de défaillance et n’apporte presque rien.

Trois rôles que tout le monde confond

Un domaine a trois rôles indépendants, et chez moi ils sont séparés consciemment :

Rôle	Chez moi	Ce qu’il fait
Registrar	REG.RU	Propriété du domaine, renouvellement, délégation NS
Hébergement DNS	REG.RU (DNS du registrar)	Stocke la zone : A, CNAME, MX, TXT
Hébergement web	Beget	Sert le site à l’IP de l’enregistrement A

Le domaine dimaserbun.ru a été acheté chez REG.RU pour 169 RUB. L’hébergement était d’abord chez REG.RU aussi, puis a migré vers Beget. La zone DNS était chez le registrar et y est restée.

La confusion commence quand on colle ces rôles ensemble. Le classique : quelqu’un change d’hébergeur et transfère d’abord les enregistrements NS vers le nouvel hébergeur, ‘parce que c’est écrit dans le tutoriel’. Maintenant la zone vit chez l’hébergeur, et la migration suivante, c’est le transfert de toute la zone avec tous les MX et TXT, pas le changement d’un seul IP. Chaque transfert superflu, c’est une chance de perdre un enregistrement mail ou le SPF.

À quoi a ressemblé ma migration entre hébergeurs

En avril 2026 j’ai déplacé le site de l’hébergement REG.RU (Host-A, 388 RUB/mois) vers Beget (~400 RUB/mois) : REG.RU s’est avéré plus lent et plus limité, et le site était jeune - migration indolore. Toute la partie DNS de la migration a tenu en deux enregistrements et une attente :

La veille du basculement - j’ai abaissé le TTL des enregistrements A de 14400 secondes (défaut REG.RU, 4 heures) à 300 secondes. C’est l’étape obligatoire qu’on saute le plus souvent : tant que l’ancien TTL n’a pas expiré chez les résolveurs du monde entier, ils gardent l’ancien IP. Abaissé en avance - au moment du basculement, la ‘divergence’ maximale sera de 5 minutes, pas de 4 heures.

Au moment du basculement - j’ai changé l’enregistrement A de dimaserbun.ru et www.dimaserbun.ru vers l’IP de Beget. C’est tout. Pas touché aux NS, pas transféré la zone, pas réenregistré le domaine.

Ensuite - vérification des réponses 200 depuis le nouvel IP, émission du Let’s Encrypt côté Beget, contrôle de Yandex Webmaster et de la GSC. Aucune baisse de positions après la migration.

C’est justement l’argument pour ‘la zone chez le registrar’ : l’hébergement est devenu un consommable. Pas satisfait - on change l’enregistrement A et on s’en va. L’hébergeur ne vous tient pas par le DNS.

Ce que Cloudflare DNS aurait donné - et pourquoi je n’y suis pas allé

Liste honnête de ce que Cloudflare DNS donne réellement gratuitement :

TTL rapides par défaut - les changements se propagent en minutes sans préparation manuelle. Chez les registrars, les TTL par défaut sont d’une à quatre heures.
API - la zone se modifie par script, pratique pour les expérimentations fréquentes.
Panneau - le meilleur de l’industrie, je ne vais pas discuter.
Un pas jusqu’au proxy - on active le ‘nuage orange’ et on obtient CDN, cache et protection DDoS.

Le dernier point est en même temps le piège principal pour un site russe. Je décortique soigneusement.

Cloudflare DNS et le proxy Cloudflare sont deux choses différentes. Les blocages DPI chez les FAI russes, sur lesquels j’ai écrit à part, frappent le trafic proxifié : le handshake TLS vers les serveurs edge de Cloudflare traîne ou échoue. Si on ne garde sur Cloudflare que la zone en mode ‘DNS only’, votre trafic va directement vers votre IP, et ces blocages ne le concernent pas.

Mais alors regardons ce qui reste du transfert : le panneau, l’API et les TTL. Et ce qui s’ajoute :

Une troisième entité dans la chaîne. Avant : registrar + hébergeur. Après : registrar + Cloudflare + hébergeur. Chaque entité, c’est un compte à part, un point de défaillance à part, un ‘et ça se configure où déjà ?’ un an plus tard.
Une dépendance à un service hors de la zone de contrôle. Pour un site qui gagne sa vie sur une audience russe, poser l’infrastructure critique sur un service dont le trafic dans ce pays est déjà étouffé par le DPI - un pari étrange. Aujourd’hui on étouffe le proxy, ce qui arrivera demain, personne ne le sait, et la zone, c’est ce sans quoi le site ne se résout pas du tout.
La tentation ‘puisqu’on a transféré - activons le proxy’. Le nuage orange est à un clic. Et voilà qu’une partie des utilisateurs sur opérateurs mobiles voit un chargement éternel, et vous cherchez pendant une semaine ‘pourquoi la conversion du trafic Direct a chuté’.

Le gain ne compense pas. Les TTL rapides, j’en ai besoin deux fois par an - et ça se règle par un abaissement manuel la veille des travaux. Une API pour une zone de quatre enregistrements, aucun besoin.

Check-list pratique : migrer d’hébergeur sans changer de DNS

Vérifiez où vit la zone : dig NS votredomaine.ru. Si ce sont les NS du registrar - la zone est chez lui, parfait.
24-48 heures avant la migration, abaissez le TTL des enregistrements A à 300 secondes.
Préparez la plateforme chez le nouvel hébergeur : fichiers, base, préparation SSL.
Changez les enregistrements A (@ et www) vers le nouvel IP.
Vérifiez les réponses : curl -I sur le nouvel IP avec l’en-tête Host, puis via le domaine.
Émettez le SSL chez le nouvel hébergeur, vérifiez les redirections http → https et www → sans www.
Quelques jours après - Yandex Webmaster et GSC : il ne doit pas y avoir d’erreurs d’exploration.
Remontez le TTL si vous voulez soulager les résolveurs.

Notez ce qui manque dans la liste : les enregistrements NS, le ‘transfert de domaine’, la lettre au registrar. Changer d’hébergeur est une opération au niveau d’une ligne dans la zone.

Quand Cloudflare DNS est le bon choix

Pour que ça ne ressemble pas à de l’idéologie, les scénarios où je transférerais moi-même la zone sur Cloudflare :

Projet global. Audience dans le monde entier, la Russie fait quelques pourcents. Le proxy s’active, CDN et protection DDoS gratuits, DNS au même endroit - logique.
Site sous attaques réelles. Média, niche concurrentielle avec historique DDoS - le proxy via Cloudflare reste le bouclier le moins cher, et la zone déménage avec lui.
L’infrastructure comme travail quotidien. Des dizaines de sous-domaines, des stagings, de la répartition de charge - l’API et les TTL instantanés font gagner des heures chaque semaine.

Pour un site B2B local russe de services - nettoyage, mobilier, construction - aucun scénario ne se déclenche d’habitude. Zone chez le registrar, enregistrement A vers l’hébergeur, CDN russe si tant est qu’il en faut un : ce que donne Beget CDN sur du shared - je l’ai décortiqué avec des chiffres.

Liens utiles

Cloudflare en Russie en 2026 : bloqué ? - sur le DPI, les blocages et le choix du CDN.
Beget CDN sur mutualisé : ce que ça donne vraiment - Lighthouse 60 → 94 sans VPS et sans changer les NS.
OPcache sur hébergement mutualisé - encore un détail d’infrastructure qui gâche la vie.

Si vous hésitez sur l’emplacement de la zone ou planifiez une migration d’hébergement sans interruption - écrivez-moi sur Telegram @dimik90. Les décisions d’infrastructure, je les traite dans le cadre d’un audit ponctuel et du SEO.