Migrer son DNS vers Cloudflare est aujourd'hui l'une des décisions d'infrastructure les plus rentables : quelques minutes de bascule des serveurs de noms suffisent pour gagner en performance, en résilience et en visibilité. Ce guide complet 2026 détaille chaque étape d'une Cloudflare DNS configuration maîtrisée, depuis l'inventaire des enregistrements existants jusqu'à la validation post-migration : import des zones A, AAAA, CNAME, MX et TXT, activation de DNSSEC, arbitrage entre proxy orange et mode gris, choix de TTL cohérents avec vos fenêtres de maintenance, protection DDoS et lecture des analytics. Vous y trouverez aussi les pièges classiques — enregistrements oubliés, e-mails cassés par un proxy mal placé, propagation mal anticipée — et les contrôles à effectuer avant de couper l'ancien fournisseur. Destiné aux administrateurs système, DevOps et responsables infrastructure, il vise l'autonomie opérationnelle plutôt que la simple recette à copier.

Configurer son DNS sur Cloudflare réduit le temps de propagation moyen à moins de 5 secondes contre 24 à 48 heures chez un registrar classique, et place votre zone sous la protection d'un réseau Anycast couvrant 330 points de présence dans 120 pays. En 2026, Cloudflare gère plus de 28 % des requêtes DNS mondiales — ce n'est pas un choix anodin, c'est devenu la référence de facto pour toute infrastructure web sérieuse. Ce guide détaille chaque étape de la migration : transfert de zone, choix du mode proxy, activation de DNSSEC, configuration des enregistrements critiques (SPF, DMARC, MX) et bonnes pratiques pour ne pas casser la production lors du basculement.

À retenir

  • Propagation quasi-immédiate : Cloudflare propage les changements DNS en moins de 5 secondes via son réseau Anycast mondial, contre 24-48h chez la plupart des registrars.
  • Mode proxy (orange) vs DNS seul (gris) : le mode orange cache l'IP d'origine et active WAF + DDoS ; le mode gris ne fait que la résolution DNS sans protection supplémentaire.
  • DNSSEC en un clic : Cloudflare génère et publie automatiquement les enregistrements DS auprès du TLD — activez-le systématiquement, c'est gratuit et signé en ECDSA.
  • TTL minimal 60 s pendant la migration : abaissez le TTL 24h avant le basculement pour que la révocation de l'ancienne zone soit rapide et sans coupure observable.
  • Nameservers non personnalisables sur le plan gratuit : les nameservers Cloudflare (ex. alice.ns.cloudflare.com) ne peuvent être personnalisés qu'à partir du plan Business ou Enterprise.

Pourquoi migrer son DNS sur Cloudflare en 2026 ?

Cloudflare n'est plus simplement un CDN : c'est une plateforme de connectivité qui fournit résolution DNS autoritaire, anycast global, protection DDoS volumétrique, proxy applicatif et Zero Trust réseau depuis une interface unifiée. Migrer son DNS ici, c'est poser la première brique d'une stratégie de sécurité périmétrique cohérente, sans ajouter d'équipement physique ni augmenter la latence de résolution.

La résolution DNS Cloudflare s'appuie sur un réseau de 330 points de présence (PoP) distribués en Anycast : la requête est traitée par le nœud le plus proche géographiquement, ce qui réduit la latence de résolution à 10-20 ms en Europe occidentale. À titre de comparaison, un DNS hébergé chez un registrar français classique répond en 80-150 ms depuis l'Asie. Pour un service SaaS avec des utilisateurs internationaux, l'impact sur le Time-to-First-Byte est mesurable.

Prérequis avant de commencer

Avant tout transfert, exportez la zone DNS actuelle au format BIND (fichier .zone ou .txt) depuis votre registrar. Cloudflare propose un outil d'import automatique qui lit ce format — mais il ne récupère jamais à 100 % les enregistrements complexes comme les enregistrements CAA ou certains enregistrements TLSA. Vérifiez manuellement après import.

Listez tous les sous-domaines en production, y compris ceux utilisés pour les MX (mail), les enregistrements SPF/DKIM/DMARC, les enregistrements de validation SSL chez Let's Encrypt ou DigiCert, et les CNAME de services tiers (Stripe, HubSpot, Intercom). Un enregistrement manqué après la bascule peut couper un service critique de façon silencieuse.

Retour terrain : Sur un projet de migration DNS pour un client e-commerce mid-market, l'oubli d'un enregistrement _dmarc pointant vers un sous-domaine tiers a déclenché un rejet massif des emails transactionnels pendant 4 heures. L'export BIND ne contenait pas cet enregistrement car il avait été ajouté manuellement dans l'interface du registrar six mois plus tôt. Depuis, on fait systématiquement un dig AXFR avant toute migration pour récupérer la zone complète.

Procédure de migration DNS Cloudflare étape par étape

La migration se déroule en quatre phases distinctes : création du compte et import de zone, vérification des enregistrements, abaissement du TTL, puis délégation NS. Ne les condensez pas — chaque phase a une fonction précise et les sauter génère des coupures évitables.

Phase 1 — Créer le compte et importer la zone

Créez un compte Cloudflare, ajoutez votre domaine et laissez le scan automatique s'exécuter. Cloudflare interroge les serveurs de noms actuels et tente de récupérer tous les enregistrements visibles publiquement. Le scan prend 60 à 90 secondes. Comparez le résultat avec votre export BIND : tout enregistrement présent dans l'export mais absent de l'interface Cloudflare doit être ajouté manuellement avant de continuer.

Phase 2 — Choisir le mode proxy pour chaque enregistrement

Cloudflare propose deux modes pour les enregistrements A, AAAA et CNAME : proxy activé (icône orange) ou DNS seul (icône grise). En mode proxy, le trafic HTTP/HTTPS transite par les serveurs Cloudflare — l'IP d'origine est masquée, le WAF et la protection DDoS sont actifs. En mode DNS seul, Cloudflare ne fait que résoudre l'IP : aucune protection applicative, l'IP du serveur est exposée publiquement.

Règle pratique : activez le proxy orange sur tous les enregistrements web (www, apex, app, api). Laissez en gris les enregistrements MX, les sous-domaines de validation ACME, les enregistrements SMTP (mail), les enregistrements de monitoring externe, et tout service qui nécessite une connexion TCP non-HTTP (bases de données, SSH, FTP). Le proxy Cloudflare ne supporte que les protocoles HTTP/HTTPS sur les ports standards.

Type d'enregistrement Mode recommandé Raison
A/AAAA — site web Proxy orange ☁️ Protection WAF + DDoS + cache CDN
A/AAAA — serveur mail DNS seul (gris) SMTP ne passe pas par le proxy Cloudflare
CNAME — www Proxy orange ☁️ Même bénéfice que A/AAAA web
MX DNS seul (gris) Forcément gris — pas de proxy sur MX
TXT (SPF, DKIM, DMARC) DNS seul (gris) Enregistrements de texte, pas de trafic
A — sous-domaine FTP/SSH DNS seul (gris) TCP non-HTTP non supporté
CNAME — validation SSL ACME DNS seul (gris) Les CA interrogent directement le DNS

Phase 3 — Abaisser le TTL 24h avant le basculement

Toujours chez votre registrar actuel, abaissez le TTL de tous les enregistrements critiques à 60 secondes (ou la valeur minimale autorisée, souvent 300 secondes). Attendez que l'ancien TTL expire — si vos enregistrements avaient un TTL de 86400 s (24h), attendez 24h avant de déléguer les NS. C'est la règle absolue pour une migration sans coupure.

Phase 4 — Déléguer les nameservers

Cloudflare vous fournit deux nameservers dédiés à votre zone (exemple : alice.ns.cloudflare.com et bob.ns.cloudflare.com). Rendez-vous dans l'interface de gestion de votre registrar et remplacez les nameservers actuels par ceux de Cloudflare. La propagation de la délégation NS prend entre 1 et 48h selon le TLD — pour les .fr gérés par l'AFNIC, comptez généralement 2 à 4h.

Activer DNSSEC : pourquoi et comment ?

DNSSEC (DNS Security Extensions) protège contre le cache poisoning et l'usurpation de réponses DNS. Sans DNSSEC, un attaquant en position man-in-the-middle peut forger une réponse DNS et rediriger le trafic vers un serveur malveillant — sans que le client ne détecte l'anomalie. Avec DNSSEC, chaque réponse est signée cryptographiquement et le résolveur peut vérifier l'authenticité de la chaîne de signatures.

Cloudflare rend l'activation de DNSSEC triviale : dans l'onglet DNS → DNSSEC de votre dashboard, activez l'option. Cloudflare génère les clés (algorithme ECDSA P-256, recommandé par le NIST), signe la zone et vous fournit l'enregistrement DS à publier auprès de votre registrar. La procédure de publication du DS varie selon le registrar — certains ont une interface graphique, d'autres nécessitent un ticket support. Pour les domaines .fr, l'AFNIC permet la publication du DS directement via les interfaces des bureaux d'enregistrement accrédités.

Vérifiez l'activation avec l'outil DNSSEC Analyzer de Verisign : une chaîne de confiance valide affiche des icônes vertes du TLD jusqu'à votre zone. Un enregistrement DS publié mais pas encore activé chez Cloudflare bloque la résolution — ne publiez le DS qu'après avoir activé DNSSEC dans le dashboard.

Configuration des enregistrements email : SPF, DKIM, DMARC

La migration DNS est l'occasion de vérifier et corriger la configuration email. Un enregistrement SPF mal formaté ou un DMARC manquant feront chuter le taux de délivrabilité après la migration — les grandes messageries (Gmail, Microsoft 365, Orange) vérifient ces enregistrements à chaque réception de mail sortant.

L'enregistrement SPF doit lister tous les serveurs autorisés à envoyer du mail pour votre domaine. Format type : v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all. Le -all (fail strict) est préférable au ~all (softfail) en production — il rejette explicitement les mails provenant de sources non autorisées. Attention : un enregistrement SPF ne peut pas dépasser 10 résolutions DNS récursives, sinon il est invalide.

DMARC est le mécanisme qui dit aux serveurs de réception quoi faire des mails qui échouent SPF ou DKIM. Un enregistrement minimal : v=DMARC1; p=quarantine; rua=mailto:[email protected]. Commencez par p=none (monitoring) pendant 2 semaines pour analyser les rapports avant de passer en p=quarantine ou p=reject.

Optimiser les TTL et la politique de cache

Une fois la migration terminée et la zone stable, remontez les TTL à des valeurs raisonnables. Cloudflare recommande 300 secondes (5 min) pour les enregistrements susceptibles de changer et 86400 secondes (24h) pour les enregistrements stables comme MX et TXT. Des TTL trop bas augmentent la charge sur les résolveurs récursifs et génèrent plus de requêtes autoritaires — sans bénéfice réel si votre infrastructure ne change pas fréquemment.

Cloudflare impose un TTL minimum de 60 secondes en mode proxy (orange) indépendamment de la valeur que vous configurez. En mode DNS seul (gris), vous pouvez descendre jusqu'à 60 secondes sur le plan gratuit. Sur les plans payants, le TTL automatique est géré par Cloudflare en fonction de la charge réseau.

Comment gérer les redirections et les règles de page ?

Cloudflare propose les Page Rules (en voie de dépréciation au profit des newer Redirect Rules) pour configurer des redirections HTTP, forcer HTTPS, ou modifier des comportements de cache par URL. La règle la plus commune : forcer HTTPS sur tous les sous-domaines via une règle http://*votredomaine.fr/* → Always Use HTTPS. En 2026, cette option est configurable directement dans SSL/TLS → Edge Certificates sans passer par les Page Rules.

Les Redirect Rules remplacent les Page Rules pour les redirections 301/302. Elles supportent des expressions complexes (regex, headers HTTP, pays d'origine) et sont plus performantes car traitées au niveau du réseau edge avant toute résolution. Pour une migration de domaine (ex. ancienne-marque.fr → nouvelle-marque.fr), configurez la redirection dans les Redirect Rules plutôt que dans votre serveur web — la latence est inférieure à 1 ms contre 50-100 ms si la requête doit atteindre votre origine.

Résolution des problèmes courants après migration

Les incidents les plus fréquents après un transfert DNS vers Cloudflare suivent des patterns répétitifs : erreur 522 (connexion timeout vers l'origine), erreur 525 (SSL handshake échoué), ou coupure email silencieuse. Chacun a une cause précise et une résolution rapide si on connaît les vecteurs.

L'erreur 522 indique que Cloudflare atteint votre serveur d'origine mais que la connexion TCP expire. Causes typiques : firewall qui bloque les IP Cloudflare (publiées sur cloudflare.com/ips), serveur en surcharge, ou timeout applicatif trop court. Solution : whitelistez les plages IP Cloudflare dans votre pare-feu et assurez-vous que le serveur écoute sur les ports 80/443.

L'erreur 525 vient d'un certificat SSL invalide ou expiré côté origine — Cloudflare essaie d'établir une connexion SSL avec votre serveur mais le handshake échoue. Vérifiez que votre certificat d'origine est valide et que le mode SSL Cloudflare est réglé sur "Full (strict)" (qui vérifie le certificat d'origine) et non "Flexible" (qui ne chiffre pas la connexion origine).

Surveillance et analytics DNS

Cloudflare fournit des analytics DNS dans l'onglet Analytics → DNS : volume de requêtes par type (A, AAAA, MX, TXT), requêtes résolues vs bloquées (si DNS Firewall actif), et breakdown géographique. Ces données sont utiles pour détecter des activités anormales — une augmentation soudaine des requêtes MX ou TXT peut indiquer une tentative d'énumération de zone ou une reconnaissance pré-attaque.

Pour une surveillance plus fine, activez les DNS logs via Cloudflare Logpush (plan Business+) vers un SIEM ou un bucket S3. Cela permet de corréler les requêtes DNS avec les logs WAF et les events de sécurité réseau — une chaîne d'audit complète que peu d'infrastructures ont sans payer une solution dédiée.

Intégration avec le reste de l'écosystème Cloudflare

La configuration DNS est la fondation de tous les autres services Cloudflare. Une fois la zone déléguée et les enregistrements proxy activés, vous pouvez empiler :

  • WAF : protection applicative des endpoints HTTP/HTTPS — voir notre guide sur la configuration du WAF Cloudflare.
  • Zero Trust / ZTNA : remplacement du VPN pour les accès internes — détaillé dans notre article sur Cloudflare Zero Trust.
  • Tunnel : exposer un service interne sans ouvrir de port — cf. Cloudflare Tunnel.
  • Cloud Network Security : pour une vision plus large des architectures VPC + WAF + DDoS, consultez notre guide Cloud Network Security.

Cette intégration est particulièrement pertinente pour les entreprises qui mettent en œuvre une stratégie Zero Trust Architecture — le DNS Cloudflare devient le point de contrôle initial de tout flux réseau.

Questions fréquentes sur la configuration DNS Cloudflare

Peut-on utiliser Cloudflare DNS sans activer le proxy ?

Oui, et c'est même recommandé pour certains enregistrements. Cloudflare en mode DNS seul (icône grise) fonctionne comme n'importe quel DNS autoritaire rapide : résolution Anycast mondiale, analytics DNS, DNSSEC. Il n'y a ni WAF, ni cache CDN, ni protection DDoS. Utilisez ce mode pour les enregistrements non-HTTP (mail, SSH, bases de données) et le mode proxy pour les endpoints web.

Combien de temps prend la propagation après le changement de nameservers ?

La propagation dépend du TTL de l'enregistrement NS chez l'ancien fournisseur et du TLD concerné. Pour les .com, .org et .net, comptez 2 à 12 heures. Pour les .fr (AFNIC), entre 2 et 6 heures. Avec un TTL de 60 secondes préconfiguré sur vos enregistrements A/CNAME, les changements d'IP propagent en moins de 2 minutes une fois la délégation NS active.

Cloudflare expose-t-il l'IP d'origine si le proxy est désactivé ?

Oui. En mode DNS seul (icône grise), la réponse DNS contient directement l'IP de votre serveur. Quiconque fait un dig A votre-domaine.fr voit votre IP réelle. En mode proxy orange, Cloudflare retourne ses propres IP Anycast — votre IP d'origine reste invisible. C'est pourquoi il ne faut jamais laisser le sous-domaine mail en proxy : cela exposerait l'IP d'un serveur différent, ce qui casse le SMTP.

Est-il possible de gérer le DNS Cloudflare via API ou Terraform ?

Absolument. L'API Cloudflare (v4) expose des endpoints complets pour créer, modifier et supprimer des enregistrements DNS par zone ID. Le provider Terraform officiel (cloudflare/cloudflare) permet de gérer toute la configuration DNS en Infrastructure as Code. C'est la méthode recommandée pour les environnements multi-domaines ou les équipes qui pratiquent GitOps — chaque changement DNS passe par une PR et une pipeline CI.

DNSSEC peut-il casser la résolution si mal configuré ?

Oui. Le cas le plus fréquent : l'enregistrement DS est publié auprès du registrar mais Cloudflare n'a pas encore signé la zone, ou vice-versa. Les résolveurs DNSSEC-validants (comme 8.8.8.8 ou 1.1.1.1) rejettent alors toutes les réponses pour votre domaine avec un code SERVFAIL. Pour éviter cela, activez d'abord DNSSEC dans le dashboard Cloudflare, vérifiez que la zone est bien signée (avec dig DNSKEY votredomaine.fr), puis publiez le DS. Ne jamais faire l'inverse.

Cloudflare for SaaS : utiliser Cloudflare comme proxy pour les clients

Cloudflare for SaaS est une fonctionnalité moins connue qui permet aux éditeurs SaaS de permettre à leurs clients d'utiliser leur propre domaine personnalisé tout en bénéficiant de l'infrastructure Cloudflare. Si vous développez un produit SaaS où vos clients veulent pointer portail.clientxyz.fr vers votre plateforme, Cloudflare for SaaS automatise la gestion des certificats SSL et le routage sans que vous ayez à gérer des certificats individuels pour chaque client.

Le mécanisme fonctionne avec un enregistrement CNAME côté client : le client ajoute un CNAME dans sa propre zone DNS pointant vers votre domaine de fallback Cloudflare. Cloudflare émet automatiquement un certificat SSL (via DCV) pour le domaine personnalisé du client et route le trafic vers votre origin. Vous gérez un seul origin, Cloudflare gère des centaines de certificats et de custom hostnames — c'est un gain opérationnel considérable pour les éditeurs SaaS multi-tenant.

Enregistrements DNS avancés : CAA, TLSA, SRV et DS

Au-delà des enregistrements classiques (A, AAAA, CNAME, MX, TXT), Cloudflare supporte les enregistrements avancés qui renforcent la sécurité de votre zone. L'enregistrement CAA (Certification Authority Authorization) spécifie quelles autorités de certification sont autorisées à émettre des certificats pour votre domaine. Une configuration CAA stricte prévient l'émission frauduleuse de certificats même si une CA est compromise.

Exemple de configuration CAA restrictive : votredomaine.fr. CAA 0 issue "letsencrypt.org" suivi de votredomaine.fr. CAA 0 issuewild ";" (interdit les wildcard certificates de toute CA). Cette combinaison garantit que seul Let's Encrypt peut émettre des certificats pour votre domaine, et uniquement des certificats non-wildcard. Les grandes organisations ajoutent aussi un enregistrement iodef pour recevoir des notifications des CAs en cas de tentative d'émission suspecte.

L'enregistrement SRV est utilisé par les applications qui doivent autodécouvrir leurs endpoints de service : SIP, XMPP, Minecraft, et de nombreuses applications d'entreprise utilisent SRV pour annoncer le port et le protocole d'un service. Cloudflare supporte les SRV en mode DNS seul (pas en proxy) — vérifiez que votre application utilise ce format avant de migrer.

Automatiser la gestion DNS avec l'API Cloudflare et Terraform

La gestion manuelle des enregistrements DNS dans l'interface Cloudflare est acceptable pour les petites zones, mais devient un risque opérationnel pour les environnements avec des dizaines de domaines et des centaines d'enregistrements. L'API REST Cloudflare v4 permet d'automatiser toutes les opérations DNS : création, modification, suppression, export de zone et audit de configuration.

Le provider Terraform Cloudflare (registry.terraform.io/providers/cloudflare/cloudflare) est mature et largement adopté en 2026. Il couvre les enregistrements DNS, les Page Rules, les Custom Rules WAF, les tunnels et la configuration Zero Trust — toute l'infrastructure Cloudflare en Infrastructure as Code. Les équipes qui pratiquent GitOps passent tous leurs changements DNS par une PR Git avec revue, ce qui crée un audit trail naturel et évite les modifications ad hoc en production.

Pour les équipes qui utilisent Ansible, le module community.general.cloudflare_dns permet d'intégrer la gestion DNS dans les playbooks d'infrastructure. C'est particulièrement utile lors du provisioning automatique de nouveaux environnements client dans un modèle SaaS — chaque nouvel environnement crée automatiquement ses enregistrements DNS via le playbook Ansible.

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Aller plus loin sur Cloudflare

Votre infrastructure cloud est-elle correctement sécurisée ?
Demandez un audit Cloud Security ou contactez-nous directement.