Migrer ses DNS vers Cloudflare est aujourd'hui l'une des décisions les plus stratégiques qu'un responsable informatique ou un propriétaire de domaine puisse prendre pour renforcer la sécurité, la disponibilité et la performance de son infrastructure numérique. En 2026, face à la multiplication des attaques par déni de service distribué (DDoS), des tentatives de détournement de DNS (DNS hijacking) et des campagnes de phishing sophistiquées, s'appuyer sur un réseau anycast mondial comptant plus de 300 points de présence représente un avantage défensif considérable. Cloudflare propose un service DNS autoritaire gratuit, ultra-rapide (moins de 11 ms en médiane mondiale), doté de DNSSEC intégré, de la protection DDoS automatique et d'un proxy transparent qui masque les adresses IP d'origine derrière son réseau. Ce guide détaille chaque étape de la migration, de l'inventaire préalable jusqu'à la supervision des logs DNS, en passant par la configuration DNSSEC, SPF, DKIM, DMARC et les zones avancées multi-niveaux. Que vous gériez un site vitrine, une boutique e-commerce ou une infrastructure d'entreprise soumise à NIS 2 ou DORA, ce guide vous permettra de sécuriser votre domaine de bout en bout avec les meilleures pratiques opérationnelles actuelles.

\n\n

Pourquoi migrer ses DNS vers Cloudflare

\n

Les DNS sont le carnet d'adresses d'Internet : toute requête vers votre domaine passe par eux. Un DNS lent, mal configuré ou non protégé expose votre infrastructure à des attaques graves. Cloudflare résout ces problèmes à plusieurs niveaux.

\n

La protection DDoS est automatique et incluse dans le plan gratuit. Le réseau absorbe les volumétriques jusqu'à plusieurs terabits par seconde sans intervention manuelle. Contrairement aux solutions hébergées chez votre registrar, Cloudflare dispose d'une capacité de scrubbing distribuée sur l'ensemble de son backbone anycast.

\n

La performance anycast réduit la latence de résolution DNS. Chaque requête est traitée par le PoP le plus proche géographiquement. Cloudflare exploite plus de 300 villes dans le monde, ce qui garantit des temps de réponse inférieurs à 20 ms pour la quasi-totalité des utilisateurs français et européens.

\n

Le DNSSEC gratuit est activable en quelques clics. Il signe cryptographiquement vos enregistrements DNS, empêchant toute falsification en transit (attaque man-in-the-middle au niveau DNS). En 2026, le DNSSEC est devenu un prérequis de conformité pour les entités soumises à NIS 2.

\n

La gestion unifiée du DNS, du proxy, du certificat TLS et du pare-feu applicatif depuis une seule interface réduit la surface d'erreur opérationnelle. Vous n'avez plus besoin de jongler entre plusieurs panneaux de contrôle pour sécuriser un domaine.

\n

Enfin, l'API Cloudflare permet d'automatiser toute modification DNS via Terraform, Ansible ou vos pipelines CI/CD, ce qui est essentiel pour les équipes DevSecOps. Pour aller plus loin sur l'audit de votre infrastructure existante avant migration, consultez notre guide d'audit d'infrastructure.

\n\n

Prérequis et inventaire DNS avant migration

\n

Avant de toucher aux nameservers, un inventaire exhaustif est indispensable. Une migration DNS précipitée peut interrompre des services critiques : messagerie, webhooks, authentification SSO, API tierces. Comptez entre 30 minutes et 2 heures pour un domaine de taille moyenne.

\n

Exportez d'abord votre zone DNS actuelle. Si votre registrar ou hébergeur DNS actuel propose l'export AXFR ou un fichier BIND, téléchargez-le. Sinon, utilisez dig AXFR example.com @ns1.votre-dns-actuel.com pour récupérer tous les enregistrements.

\n

Les enregistrements A pointent une racine ou un sous-domaine vers une IPv4. Les AAAA font de même pour IPv6. Les CNAME aliasent un nom vers un autre nom — attention, un CNAME à la racine du domaine est interdit par le RFC 1034 (Cloudflare contourne cela avec le CNAME Flattening). Les MX définissent les serveurs de messagerie entrants, avec une priorité numérique. Les TXT transportent des métadonnées : SPF, DKIM, DMARC, vérification de propriété Google/Microsoft.

\n

Vérifiez les TTL actuels. Si votre TTL est de 86400 secondes (24h), abaissez-le à 300 secondes (5 min) 24h avant la migration. Cela accélère la propagation lors du changement de nameservers. Notez tous les sous-domaines actifs, y compris ceux utilisés par des services tiers (Stripe, Mailchimp, HubSpot, etc.). Ces sous-domaines auront besoin d'un enregistrement CNAME dans Cloudflare.

\n

Documentez également les enregistrements SRV (VoIP, messagerie instantanée), CAA (autorisation de certification TLS) et PTR (reverse DNS, géré par votre hébergeur). Les enregistrements PTR ne sont pas gérés par Cloudflare mais par le fournisseur de l'adresse IP.

\n\n

Ajouter son domaine dans Cloudflare

\n

Créez un compte sur cloudflare.com si ce n'est pas déjà fait. Depuis le tableau de bord, cliquez sur "Add a site" et saisissez votre domaine racine (exemple : monentreprise.fr, sans www). Cloudflare effectue immédiatement un scan automatique de votre zone DNS en interrogeant vos nameservers actuels.

\n

Choisissez le plan adapté. Le plan Free inclut le DNS managé, le proxy, le WAF basique et le DNSSEC. Le plan Pro (20$/mois) ajoute le WAF avancé, l'optimisation des images et les analytics avancés. Les plans Business et Enterprise ajoutent le support prioritaire, les SLA contractuels et les fonctionnalités Zero Trust.

\n

Cloudflare vous présente ensuite la liste des enregistrements détectés. Comparez minutieusement avec votre inventaire. Ajoutez manuellement tout enregistrement manquant avant de continuer. C'est l'étape la plus critique : un enregistrement MX oublié signifie une perte de messagerie après la propagation.

\n

Une fois la zone validée, Cloudflare vous fournit deux nameservers dédiés (ex : aria.ns.cloudflare.com et brad.ns.cloudflare.com). Rendez-vous chez votre registrar (OVH, Gandi, Namecheap, IONOS…) et remplacez les nameservers existants par ceux fournis par Cloudflare. La propagation DNS prend généralement entre 15 minutes et 48 heures selon les TTL et les résolveurs. Suivez la progression depuis l'onglet "Overview" de Cloudflare.

\n

Pour les domaines sous .fr gérés par l'AFNIC, le changement de nameservers peut prendre jusqu'à 24h supplémentaires en raison du processus de validation du registrar accrédité. Prévoyez la migration hors des heures de pointe (nuit ou week-end).

\n\n

Configurer les enregistrements DNS dans Cloudflare

\n

Une fois le domaine actif dans Cloudflare, l'onglet DNS vous permet de gérer tous vos enregistrements. La décision la plus importante concerne le proxy Cloudflare, représenté par l'icône orange (nuage orange) ou grise (nuage gris).

\n

Le proxy orange (activé) signifie que le trafic HTTP/HTTPS transite par le réseau Cloudflare. Votre IP d'origine est masquée, la protection DDoS est active, et les fonctionnalités WAF, cache et optimisation s'appliquent. C'est le mode recommandé pour tous les sous-domaines servant du contenu web.

\n

Le proxy gris (DNS only) signifie que Cloudflare résout simplement le nom vers votre IP sans proxy. À utiliser pour les sous-domaines non-HTTP (serveurs de messagerie, FTP, enregistrements SRV, sous-domaines utilisés par des services qui ne supportent pas le proxy Cloudflare comme certains CDN tiers).

\n

Pour les TTL, lorsque le proxy orange est actif, Cloudflare force un TTL de 300 secondes indépendamment de votre paramétrage — c'est normal. Pour les enregistrements en gris, vous pouvez définir des TTL de 1 min à 1 jour. Privilégiez 5 min (300s) pour les enregistrements qui changent fréquemment, et 1h (3600s) pour les enregistrements stables.

\n

Les wildcards (*.mondomaine.fr) sont supportés. Ils matchent tous les sous-domaines non définis explicitement. Utilisez-les avec précaution : un wildcard en orange proxy peut exposer des sous-domaines non intentionnels via Cloudflare. Préférez des enregistrements explicites pour les sous-domaines sensibles.

\n

La documentation officielle de référence est disponible sur developers.cloudflare.com/dns.

\n\n

Activer DNSSEC dans Cloudflare

\n

Le DNSSEC (Domain Name System Security Extensions) ajoute une couche de signatures cryptographiques à vos enregistrements DNS. Sans DNSSEC, un attaquant capable d'intercepter les réponses DNS peut rediriger vos utilisateurs vers des serveurs malveillants (cache poisoning, BGP hijacking). Le DNSSEC empêche cette falsification en permettant au résolveur de vérifier l'authenticité de chaque enregistrement.

\n

Dans Cloudflare, activez DNSSEC depuis l'onglet DNS → DNSSEC. Cloudflare génère automatiquement les clés KSK (Key Signing Key) et ZSK (Zone Signing Key) et signe l'ensemble de votre zone. Vous n'avez qu'à copier l'enregistrement DS (Delegation Signer) fourni par Cloudflare et le coller dans l'interface de votre registrar.

\n

Le DS record ressemble à : example.fr. 3600 IN DS 2371 13 2 1F987C.... Le champ "Algorithm" indique l'algorithme de signature : Cloudflare utilise ECDSA avec P-256 (algorithme 13), plus moderne et performant que RSA-256 (algorithme 8). Le champ "Digest Type" 2 correspond à SHA-256.

\n

Chez OVH, rendez-vous dans "Domaines → votre domaine → DNSSEC" et collez les valeurs. Chez Gandi, utilisez l'onglet "DNSSEC" de la fiche domaine. La propagation du DS record prend jusqu'à 48h. Vérifiez l'activation avec dig +dnssec A example.fr : les réponses doivent inclure un flag AD (Authenticated Data).

\n

Une fois DNSSEC actif, ne modifiez jamais les nameservers sans désactiver DNSSEC d'abord. Changer de nameservers sans retirer le DS record provoque une rupture DNSSEC qui rend votre domaine inaccessible pour les résolveurs validants. La documentation détaillée est disponible sur developers.cloudflare.com/dns/dnssec.

\n

Pour les organisations soumises à NIS 2, le DNSSEC est fortement recommandé comme mesure de sécurité des systèmes d'information. Notre page NIS 2 détaille les obligations applicables.

\n\n

Configurer SPF, DKIM et DMARC dans Cloudflare

\n

La protection anti-phishing de votre domaine repose sur trois enregistrements TXT complémentaires : SPF, DKIM et DMARC. Ces standards empêchent les attaquants d'envoyer des e-mails au nom de votre domaine et permettent de définir la politique de traitement des messages non conformes.

\n

Le SPF (Sender Policy Framework) liste les serveurs autorisés à envoyer des e-mails pour votre domaine. Il s'ajoute comme enregistrement TXT à la racine : v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 ~all. Le mécanisme ~all (softfail) est conseillé lors de la mise en place initiale ; passez à -all (hardfail) une fois la configuration stabilisée. N'ajoutez que les sources légitimes : trop de include: réduit la fiabilité SPF (limite de 10 lookups DNS).

\n

Le DKIM (DomainKeys Identified Mail) signe cryptographiquement chaque e-mail sortant. Votre fournisseur de messagerie (Google Workspace, Microsoft 365, OVHcloud…) vous fournit un enregistrement TXT CNAME ou TXT à créer dans Cloudflare. Exemple pour Google : google._domainkey.example.fr TXT "v=DKIM1; k=rsa; p=MIIBIjAN...".

\n

Le DMARC (Domain-based Message Authentication) indique aux serveurs destinataires comment traiter les e-mails qui échouent SPF ou DKIM. Commencez en mode monitoring : v=DMARC1; p=none; rua=mailto:dmarc@example.fr. Après analyse des rapports (1-4 semaines), passez à p=quarantine puis p=reject pour un blocage complet des usurpations.

\n

Cloudflare propose également son service Email Routing pour rediriger les e-mails entrants vers une adresse Gmail ou Microsoft sans serveur mail propre. La documentation officielle est sur developers.cloudflare.com/email-routing.

\n

Ces configurations sont directement liées à la conformité DORA pour les entités du secteur financier. Notre page conformité DORA précise les exigences en matière de gestion des risques liés aux tiers numériques.

\n\n

Sous-domaines et zones DNS avancées

\n

Pour les infrastructures complexes, Cloudflare supporte des configurations DNS avancées qui vont au-delà du simple enregistrement A ou CNAME.

\n

Le CNAME Flattening résout le problème du CNAME interdit à la racine du domaine (zone apex). Lorsque vous créez un CNAME sur example.fr (et non www.example.fr), Cloudflare résout automatiquement la chaîne et retourne directement l'adresse IP finale. Cela permet de pointer votre domaine racine vers un service comme Netlify, Vercel ou un load balancer sans violer les RFC DNS.

\n

La délégation de sous-zone permet d'utiliser des nameservers différents pour un sous-domaine. Par exemple, dev.example.fr peut pointer vers des nameservers Route53 pour l'environnement de développement AWS, tandis que example.fr reste géré par Cloudflare. Créez des enregistrements NS pour le sous-domaine délégué.

\n

Les zones multi-niveaux (ou sous-zones) permettent de gérer api.example.fr, cdn.example.fr, mail.example.fr avec des paramètres proxy, TTL et règles de sécurité indépendants. Chaque sous-domaine peut avoir un comportement WAF ou de cache différent selon son usage.

\n

Les Load Balancers Cloudflare (plan Pro et supérieur) permettent de distribuer le trafic entre plusieurs serveurs origin avec health checks automatiques et failover. Ils s'intègrent directement dans la zone DNS et remplacent les enregistrements A multiples (round-robin DNS).

\n

Pour les infrastructures nécessitant un pentest cloud préalable avant migration, consultez notre offre pentest cloud qui inclut l'évaluation des configurations DNS et de l'exposition des services.

\n\n

Surveillance et logs DNS

\n

Une migration DNS réussie doit être suivie d'une supervision active. Cloudflare fournit plusieurs outils de monitoring intégrés.

\n

L'onglet Analytics → DNS affiche le volume de requêtes par enregistrement, les codes de réponse (NOERROR, NXDOMAIN, SERVFAIL) et la répartition géographique. Un pic soudain de NXDOMAIN peut indiquer un enregistrement manquant ou une attaque par énumération DNS.

\n

Les Cloudflare Notifications permettent de créer des alertes par e-mail ou webhook sur des événements DNS : changement de nameservers, activation/désactivation DNSSEC, expiration de certificat. Ces alertes sont configurables depuis "Notifications" dans le tableau de bord principal.

\n

Pour une supervision externe complémentaire, des outils comme UptimeRobot, Pingdom ou Better Uptime peuvent monitorer la résolution DNS et déclencher des alertes si votre domaine devient inaccessible. Combinez avec des vérifications DNSSEC via dnsviz.net ou dnssec-debugger.verisignlabs.com.

\n

Les entreprises soumises à des audits de sécurité doivent conserver les logs DNS dans leur SIEM. Cloudflare Logpush (plan Enterprise) exporte les logs DNS en temps réel vers votre SIEM (Splunk, Elastic, Datadog). Pour les plans inférieurs, l'API Cloudflare permet de récupérer les analytics DNS toutes les heures. Notre guide de gestion des vulnérabilités aborde l'intégration des logs DNS dans un processus de veille sécurité structuré.

\n

Pour une revue complète de votre posture DNS et infrastructure, découvrez notre service d'audit d'infrastructure.

\n\n

FAQ — DNS Cloudflare

\n\n

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

\n

La propagation DNS dépend du TTL de vos enregistrements NS actuels et du cache des résolveurs intermédiaires. Dans la majorité des cas, la propagation complète prend entre 15 minutes et 24 heures. Pour accélérer le processus, abaissez le TTL de vos enregistrements à 300 secondes (5 minutes) au moins 24 heures avant la migration. Les résolveurs publics comme Google (8.8.8.8) ou Cloudflare (1.1.1.1) sont généralement mis à jour en quelques minutes, mais des résolveurs d'entreprise ou d'opérateur peuvent mettre jusqu'à 48 heures à propager les changements. Utilisez l'outil "DNS Checker" (dnschecker.org) pour surveiller la propagation en temps réel depuis plusieurs localisations géographiques.

\n\n

Puis-je utiliser Cloudflare DNS sans activer le proxy (mode DNS only) ?

\n

Oui, tout à fait. Vous pouvez utiliser Cloudflare uniquement comme DNS autoritaire sans activer le proxy. Dans ce cas, les enregistrements restent en mode "gris" (DNS only) et Cloudflare résout simplement les noms vers vos IPs sans faire transiter le trafic par son réseau. Vous bénéficiez quand même de la rapidité du réseau anycast de Cloudflare pour la résolution DNS, du DNSSEC gratuit, de la gestion unifiée des enregistrements et de l'API. La protection DDoS au niveau applicatif, le WAF et le cache ne s'appliquent pas en mode DNS only. C'est une configuration courante pour les services non-HTTP (bases de données, serveurs de messagerie, FTP) ou les sous-domaines gérés par d'autres CDN.

\n\n

Le plan gratuit Cloudflare est-il suffisant pour sécuriser son DNS en entreprise ?

\n

Le plan gratuit inclut le DNS managé avec anycast, le DNSSEC, la protection DDoS L3/L4 automatique, le proxy orange pour masquer les IPs d'origine, et le WAF basique avec quelques règles managées. Pour une PME ou une startup, c'est généralement suffisant pour une sécurité DNS solide. En revanche, pour des entreprises avec des exigences de conformité strictes (NIS 2, ISO 27001), ou nécessitant des SLA contractuels, des logs en temps réel (Logpush), des règles WAF personnalisées avancées, ou du Load Balancing géo-distribué, les plans Pro (20$/mois), Business (200$/mois) ou Enterprise sont recommandés. L'évaluation doit se faire au regard de votre surface d'attaque et de vos obligations réglementaires.

\n\n

Comment éviter les interruptions de messagerie lors d'une migration DNS vers Cloudflare ?

\n

La messagerie est le service le plus sensible lors d'une migration DNS. Avant tout changement, vérifiez que tous vos enregistrements MX sont correctement importés dans Cloudflare. Les enregistrements MX ne doivent jamais être en mode proxy orange — laissez-les toujours en gris (DNS only). Vérifiez également que les enregistrements SPF, DKIM et DMARC sont présents et corrects. Testez l'envoi et la réception d'e-mails depuis des domaines externes avant et après la migration. Conservez les anciens nameservers actifs au minimum 24 à 48 heures après le changement pour permettre aux résolveurs lents de propager. En cas de doute, effectuez la migration un vendredi soir avec une équipe disponible le week-end pour intervenir rapidement.

\n\n

DNSSEC et Cloudflare : que se passe-t-il si je veux changer de DNS plus tard ?

\n

Si vous souhaitez quitter Cloudflare et migrer vers un autre fournisseur DNS, vous devez impérativement désactiver DNSSEC dans Cloudflare avant de changer les nameservers. Désactivez d'abord le DNSSEC dans Cloudflare (ce qui supprime les signatures de zone), puis supprimez l'enregistrement DS chez votre registrar, attendez la propagation (jusqu'à 48h), puis changez les nameservers vers votre nouveau fournisseur DNS. Si vous changez les nameservers sans retirer le DS record, les résolveurs validant DNSSEC recevront des réponses signées avec une clé qui ne correspond plus aux nameservers actifs, rendant votre domaine inaccessible pour une grande partie des internautes. C'est l'erreur la plus fréquente lors d'une migration sortante.

\n\n
\n

À retenir — DNS Cloudflare

\n
    \n
  • Inventaire préalable obligatoire : exportez et vérifiez l'intégralité de vos enregistrements DNS (A, AAAA, CNAME, MX, TXT, SRV) avant de changer les nameservers. Un enregistrement oublié peut couper la messagerie ou des services critiques.
  • \n
  • TTL bas avant migration : abaissez le TTL à 300 secondes au moins 24h avant le changement de nameservers pour accélérer la propagation et réduire le temps d'indisponibilité potentiel en cas de problème.
  • \n
  • Proxy orange vs gris : activez le proxy orange uniquement pour les sous-domaines HTTP/HTTPS. Laissez en gris les enregistrements MX, les sous-domaines FTP, les services incompatibles avec le proxy et tout enregistrement non-web.
  • \n
  • DNSSEC en trois étapes : activez dans Cloudflare, copiez le DS record, collez-le chez le registrar. Ne jamais changer de nameservers sans désactiver DNSSEC d'abord — risque d'inaccessibilité totale du domaine.
  • \n
  • SPF + DKIM + DMARC ensemble : les trois standards sont complémentaires. SPF seul ou DKIM seul ne suffit pas. Commencez avec DMARC en mode p=none pour analyser les flux, puis durcissez progressivement vers p=reject.
  • \n
  • Supervision post-migration : configurez des alertes Cloudflare et un monitoring externe pour détecter immédiatement toute anomalie DNS (NXDOMAIN, SERVFAIL) après la migration.
  • \n
\n