DNS Cloudflare, ce qu'il faut vérifier avant de modifier une zone

DNS Cloudflare désigne le plus souvent la gestion d’une zone DNS chez Cloudflare : le domaine pointe vers les nameservers Cloudflare, puis les enregistrements A, CNAME, MX, TXT ou AAAA sont administrés dans ce tableau de bord. Le point à ne pas confondre : 1.1.1.1 est un résolveur public, pas la zone DNS de votre domaine.

Pour une PME, l’intérêt est simple : centraliser les réglages du domaine, préparer le proxy web si besoin et garder une meilleure visibilité sur ce qui fait fonctionner le site, les sous-domaines et les emails. La mauvaise migration, elle, coupe vite un site ou une messagerie.

À quoi sert le DNS Cloudflare ?

Le DNS Cloudflare sert à publier les enregistrements qui indiquent où vont votre domaine, votre site, vos sous-domaines et certains services comme la messagerie. Concrètement, Cloudflare devient le DNS autoritatif de la zone si vous remplacez les nameservers chez le registrar, puis chaque requête suit les règles enregistrées.

Le mot “DNS” crée souvent une ambiguïté. Changer les DNS d’un poste vers 1.1.1.1 modifie le résolveur utilisé par cet ordinateur. Changer les nameservers d’un domaine vers Cloudflare modifie l’endroit où la zone officielle du domaine est administrée. Les deux actions sont liées au DNS, mais elles n’ont pas le même impact.

Les réglages à vérifier avant de changer les nameservers

Avant de basculer les nameservers, l’étape prioritaire consiste à comparer l’ancienne zone et la zone Cloudflare ligne par ligne. Il faut surtout éviter de ne recopier que le site principal. Les sous-domaines, outils SaaS, services de validation et enregistrements email sont souvent les éléments oubliés.

Pour approfondir ce point, consultez Exploration approfondie des protocoles LDAP, DNS et, qui traite plus précisément de exploration approfondie des protocoles ldap, dns et kerberos : fondements, fonctions et sécurisation.

Utilisez une grille courte avant validation :

La bonne pratique est de préparer un plan de retour arrière avant le clic final. Conservez une exportation de l’ancienne zone, notez les nameservers précédents et choisissez une fenêtre où l’impact métier sera limité.

Dans une petite structure, cette préparation évite surtout les diagnostics dispersés. Si le site répond mais que le CRM, la signature email ou un sous-domaine client ne fonctionne plus, le problème vient souvent d’un enregistrement secondaire oublié. Garder la zone source sous les yeux permet de corriger vite au lieu de chercher côté hébergement, navigateur ou antivirus.

Proxy Cloudflare ou DNS only : le choix à ne pas automatiser

Le proxy Cloudflare peut masquer l’adresse d’origine et faire passer le trafic web par Cloudflare, mais il ne convient pas à tous les enregistrements. Pour un site web, le proxy peut être utile. Pour un MX, un SPF, un DKIM ou beaucoup de services non HTTP, DNS only reste généralement le choix attendu.

Ne transformez pas tous les nuages en orange par réflexe. Dans un contexte PME, le bon arbitrage est pragmatique : proxy pour ce qui bénéficie réellement de Cloudflare, DNS only pour ce qui doit rester une résolution transparente.

Le bon réflexe consiste aussi à noter pourquoi chaque enregistrement est proxifié ou non. Cette petite documentation évite qu’un collègue “corrige” plus tard un réglage volontaire. Sur un domaine d’entreprise, la traçabilité DNS vaut presque autant que le réglage lui-même.

DNS Cloudflare et 1.1.1.1, la confusion classique

1.1.1.1 est le résolveur DNS public de Cloudflare. Vous pouvez le configurer sur un poste, un routeur ou un réseau pour résoudre les domaines consultés par les utilisateurs. Cela ne déplace pas la zone DNS de votre domaine et ne change pas les enregistrements publiés pour vos visiteurs.

À l’inverse, migrer une zone vers Cloudflare concerne votre domaine. C’est ce qui détermine où pointe www, où arrivent les emails et comment les sous-domaines sont résolus sur Internet. Mélanger ces deux notions conduit à de mauvais diagnostics : un poste peut utiliser 1.1.1.1 alors que la zone du domaine reste chez un autre fournisseur.

Comment tester la bascule sans attendre une panne utilisateur

Après le changement de nameservers, ne vous contentez pas d’ouvrir la page d’accueil. Testez le site principal, les sous-domaines, les redirections, les formulaires, l’envoi d’email, la réception d’email et les outils qui valident un domaine par TXT. La propagation peut être progressive, mais les gros oublis se voient souvent rapidement.

Un test propre part de plusieurs points de vue : un navigateur classique, une connexion mobile, un poste interne et un outil de résolution DNS. L’objectif n’est pas de prouver que tout a propagé partout, mais de détecter le mauvais enregistrement avant que les utilisateurs ne transforment l’incident en ticket urgent.

Les erreurs fréquentes lors d’une migration DNS

La première erreur consiste à valider trop vite la zone importée automatiquement. L’import peut manquer des entrées, confondre certains sous-domaines ou ne pas deviner l’usage réel d’un enregistrement. La deuxième erreur est d’oublier la messagerie : un site qui répond mais des emails qui disparaissent, c’est une migration incomplète.

Le DNS Cloudflare devient intéressant quand il apporte de la clarté opérationnelle, pas quand il est ajouté comme une couche magique. Si votre domaine porte un site, une messagerie et plusieurs outils métier, traitez la migration comme une intervention d’infrastructure : inventaire, bascule, contrôle et retour arrière.

La priorité concrète : vérifier la zone avant de toucher aux nameservers, puis conserver une trace datée de chaque changement appliqué, avec le responsable identifié.