Plan B si Cloudflare tombe : DNS secondaire et désactivation rapide du proxy

Quand Cloudflare a un incident, vos sites passent d'un coup du statut « protégé » au statut « injoignable », alors que votre serveur d'origine tourne parfaitement. Ce guide décrit ce qu'un administrateur peut préparer à l'avance : un serveur DNS secondaire, une procédure pour désactiver le proxy (le « nuage gris »), et les points qui font échouer le plan B au pire moment.

Comprendre ce qui casse quand Cloudflare tombe

Cloudflare joue souvent trois rôles à la fois pour un domaine : serveur DNS faisant autorité (il répond aux requêtes sur vos enregistrements), reverse proxy (le trafic web transite par son réseau) et tableau de bord/API (l'endroit où vous modifiez tout ça). Une panne peut toucher un seul de ces rôles ou plusieurs. Votre plan B doit donc être pensé par rôle :

• Le proxy est en panne, le DNS répond : les visiteurs reçoivent des erreurs 5xx. Basculer les enregistrements en DNS only suffit, si vous pouvez encore les modifier.
• Le DNS est en panne : le nom de domaine ne se résout plus. Seuls des serveurs DNS secondaires, chez un autre fournisseur ou sur votre propre VPS, peuvent répondre à votre place, à condition d'être déjà configurés.
• Le tableau de bord et l'API sont inaccessibles : vous ne pouvez rien changer. Tout ce qui n'a pas été préparé avant reste hors de portée.

Retenez ce dernier point : un plan B qui commence par « je me connecte à Cloudflare » n'est pas un plan B.

Nuage orange, nuage gris : ce que change le proxy

D'après la documentation Cloudflare sur le statut de proxy, un enregistrement proxifié (nuage orange) répond avec des adresses Cloudflare et fait transiter le trafic HTTP/HTTPS par son réseau. Un enregistrement DNS only (nuage gris) renvoie directement l'IP réelle de votre serveur. Seuls les enregistrements A, AAAA et CNAME peuvent être proxifiés ; MX et TXT sont toujours en DNS only.

Deux détails comptent en situation de crise :

• Le TTL d'un enregistrement proxifié est automatique, 300 secondes d'après la documentation. Il est donc court, mais les caches des résolveurs et des navigateurs peuvent garder l'ancienne réponse plus longtemps.
• Passer en DNS only expose l'IP de l'origine à quiconque interroge le DNS. Vous perdez le cache, les règles WAF et la protection que le proxy apportait.

Désactiver le proxy est donc un mode dégradé assumé : le site revient, mais votre origine doit être capable d'encaisser le trafic et les attaques seule.

Préparer l'origine avant d'en avoir besoin

La plupart des échecs de bascule viennent de l'origine, pas du DNS. Vérifiez ces quatre points dès maintenant.

1. Un certificat valide sans Cloudflare

Beaucoup d'installations utilisent un certificat d'origine émis par Cloudflare (Origin CA). Il n'est pas reconnu par les navigateurs : dès que le proxy est coupé, les visiteurs voient une erreur de certificat. Installez un certificat public sur l'origine, par exemple avec Certbot et Let's Encrypt, puis contrôlez-le avec OpenSSL. Attention : si vous utilisez le challenge HTTP-01, le renouvellement exige que le port 80 soit joignable depuis Internet. Le DNS-01 évite cette contrainte.

2. Un pare-feu qui sait s'ouvrir

Si votre pare-feu n'autorise que les plages IP de Cloudflare sur les ports 80 et 443, la bascule en nuage gris vous coupera du monde entier. Préparez une règle d'ouverture temporaire, testée, et documentée. Avec nftables, voyez le guide pare-feu nftables pour un serveur de jeu. Exemple de jeu de règles à activer en urgence :

# Ouverture temporaire du web à tous (à retirer après l'incident)
nft add rule inet filter input tcp dport { 80, 443 } accept

Adaptez le nom de la table et de la chaîne à votre configuration, et gardez la commande inverse sous la main.

3. Un serveur web qui voit la vraie IP des clients

Derrière le proxy, vos journaux et vos outils de blocage (Fail2ban, CrowdSec) reçoivent l'IP de Cloudflare sauf configuration particulière. Sans proxy, ils reçoivent l'IP réelle. Vérifiez que votre configuration Nginx ne fait pas confiance à un en-tête d'IP client venant de n'importe qui, sinon n'importe quel visiteur direct pourra falsifier son adresse.

4. Une origine qui encaisse seule

Sans le cache, chaque requête atteint votre serveur. Mesurez ce que votre machine supporte, activez un cache local sur les pages statiques et limitez les requêtes abusives. Une protection anti-DDoS au niveau de l'hébergeur reste utile dans ce scénario, c'est un des intérêts d'un VPS Linux ou d'un serveur dédié chez ElypseCloud.

Désactiver le proxy rapidement

Depuis le tableau de bord

Dans la section DNS, ouvrez l'enregistrement concerné et passez le statut de proxy de « Proxied » à « DNS only ». Pour un domaine avec plusieurs sous-domaines, listez à l'avance ceux qui doivent basculer : le site principal, l'API, le panel, mais pas forcément tout.

Par l'API

Le point d'entrée de modification d'un enregistrement DNS est PATCH /zones/{zone_id}/dns_records/{dns_record_id}, avec un jeton portant la permission DNS Write et un champ booléen proxied. Exemple :

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records/${RECORD_ID}" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"proxied": false}'

Rédigez ce script avant la panne : récupérez les identifiants de zone et d'enregistrements, stockez-les dans un fichier de configuration, testez sur un sous-domaine de recette. Utilisez un jeton limité à une zone et à la seule permission nécessaire, stocké hors du dépôt de code. Rappel : si l'API est elle-même touchée, ce script ne fonctionnera pas, d'où l'intérêt d'un DNS secondaire.

Pensez aussi aux enregistrements AAAA, qui pointent vers une adresse IPv6 : si votre origine en possède une, ils doivent suivre le même statut de proxy que l'enregistrement A. Un oubli ici laisse une partie du trafic emprunter un chemin que vous n'avez pas testé.

Vérifier la bascule

Interrogez directement un résolveur public pour voir si l'enregistrement renvoie votre IP et non plus une adresse Cloudflare :

dig +short www.exemple.fr @1.1.1.1
dig +short www.exemple.fr @9.9.9.9
curl -I https://www.exemple.fr

Le guide diagnostiquer la résolution DNS sous Linux détaille ces vérifications et les pièges de cache local.

Le DNS secondaire : ce que Cloudflare permet vraiment

Définitions

• Serveur primaire (DNS primaire) : le serveur où vous éditez le fichier de zone, qui contient les enregistrements de la zone DNS.
• Enregistrement SOA : il décrit la zone (serveur primaire, adresse de contact) et porte un numéro de série, que le serveur secondaire compare pour savoir si sa copie doit être mise à jour.
• Serveur secondaire (DNS secondaire) : un serveur DNS qui reçoit une copie de la zone DNS et répond aux requêtes comme le serveur primaire.
• Transfert de zone : mécanisme de copie. AXFR envoie la zone entière, IXFR seulement les changements, et NOTIFY prévient le secondaire qu'une modification a eu lieu. Un secret partagé TSIG authentifie les échanges.

La limite côté plan

D'après la documentation des transferts de zone, Cloudflare peut fonctionner en primaire (transferts sortants vers d'autres fournisseurs) ou en secondaire (transferts entrants), mais cette fonctionnalité est réservée au plan Enterprise. Jusqu'à 30 pairs peuvent être liés à une zone.

Autre option documentée : la configuration partielle (CNAME). Vous gardez votre fournisseur DNS faisant autorité et Cloudflare ne sert que de proxy pour certains noms. Elle est réservée aux plans Business et Enterprise, et n'inclut pas la protection DDoS de l'infrastructure DNS de Cloudflare.

Tableau comparatif des stratégies

Plan B sans plan Enterprise

Pour la majorité des administrateurs de VPS, voici une approche réaliste :

1. Exportez régulièrement la zone au format BIND (fichier de zone) depuis le tableau de bord ou l'API, et versionnez le fichier (Git privé). Une zone qu'on ne peut pas reconstituer est la vraie cause des heures perdues.
2. Ouvrez un compte chez un second fournisseur DNS et configurez-y la zone DNS, sans y déléguer le domaine tant que tout va bien. Vérifiez que chaque enregistrement existe, y compris MX, TXT (SPF, DKIM, DMARC) et CAA.
3. Testez les réponses du second fournisseur sans toucher à la délégation :

   dig +short A www.exemple.fr @ns1.fournisseur-b.example
   dig +short MX exemple.fr @ns1.fournisseur-b.example

4. Documentez la bascule : où changer les serveurs de noms chez le registrar, qui détient l'accès, quel est le délai attendu.

Prévenez-vous d'une réalité : changer les serveurs de noms chez le registrar n'est pas instantané. La délégation est mise en cache par les résolveurs, souvent plus longtemps que les TTL de vos enregistrements. Ce plan limite la durée d'un incident long, il ne remplace pas une vraie redondance.

Précaution supplémentaire : abaissez le TTL des enregistrements DNS only les plus critiques (par exemple 300 secondes) tant que vous n'êtes pas en incident. Un TTL court ne s'applique qu'aux caches futurs, il faut donc le faire bien avant.

Héberger un serveur DNS secondaire sur votre VPS

Un domaine doit être servi par plusieurs serveurs DNS, idéalement sur des réseaux distincts : si l'un tombe, les autres répondent. Le serveur DNS secondaire joue ce rôle. Sur un VPS Linux, vous pouvez le faire tourner vous-même avec un logiciel de serveur DNS faisant autorité, comme BIND ou NSD, installé sous Debian ou une autre distribution. Il sert une copie de la zone DNS, il ne la modifie pas.

Procédure générale :

1. Partez d'un fichier de zone à jour, celui que vous avez exporté. Il contient l'enregistrement SOA et les enregistrements de la zone.
2. Chargez ce fichier dans la configuration de zone du logiciel, puis vérifiez que le serveur répond pour votre domaine.
3. Ajoutez ce serveur à la liste des serveurs de noms du domaine chez votre registrar, uniquement après avoir vérifié ses réponses.

Pour la vérification, interrogez directement l'adresse IP de votre serveur avec dig. Le @ suivi de l'adresse indique le serveur interrogé :

dig +short A www.exemple.fr @203.0.113.10

L'adresse 203.0.113.10 est une adresse de documentation, à remplacer par celle de votre serveur.

Limite à connaître : une copie figée ne suit pas vos modifications. Chaque changement doit donner lieu à un nouvel export, avec un numéro de série SOA incrémenté, puis à un rechargement de la zone. Sans cela, votre serveur secondaire répond avec des données périmées.

Mail, jeux et services hors web

• Messagerie : les enregistrements MX, qui désignent le serveur de messagerie (serveur mail) qui reçoit les emails, et TXT ne sont jamais proxifiés. Si le DNS est en panne, les emails n'arrivent plus non plus, et l'envoi SMTP vers votre domaine échoue aussi. Un second serveur DNS protège ce flux, à condition que les enregistrements MX et TXT y soient copiés.
• Serveurs de jeu : le proxy de Cloudflare traite le trafic web. Pour un serveur FiveM, Minecraft ou Rust, l'adresse de connexion doit pointer en DNS only, comme décrit dans le guide nom de domaine et enregistrement SRV pour FiveM. Seul le site vitrine, le panel ou l'API HTTP sont concernés par la bascule.
• Applications web auto-hébergées : vérifiez le HTTPS et la redirection comme dans publier un service en HTTPS sur un VPS Linux.

Détecter la panne avant vos utilisateurs

Surveillez le site par deux chemins : l'URL publique (via Cloudflare) et l'IP de l'origine avec l'en-tête Host. Si le premier échoue et le second répond, la panne est côté proxy. Uptime Kuma permet de créer ces deux sondes et d'envoyer une alerte. Hébergez la supervision hors de l'infrastructure surveillée, et pas derrière le même proxy.

# Test direct de l'origine, sans passer par le DNS
curl -I --resolve www.exemple.fr:443:203.0.113.10 https://www.exemple.fr

Checklist du plan B

1. Zone DNS exportée et versionnée, à jour.
2. Second fournisseur DNS chargé et testé, ou transferts de zone si plan Enterprise.
3. Script de bascule en nuage gris testé sur un sous-domaine, jeton d'API restreint.
4. Certificat public valide sur l'origine, renouvellement vérifié.
5. Règle de pare-feu d'ouverture temporaire des ports 80 et 443, testée.
6. Journaux et outils de blocage configurés pour l'IP réelle.
7. Sondes de supervision publique et directe, alertes hors infrastructure.
8. Procédure écrite : qui décide, qui exécute, comment revenir en nuage orange.

Après l'incident, remettez le proxy, fermez la règle de pare-feu temporaire et envisagez de changer l'IP de l'origine si elle a été exposée et que vous craignez des attaques directes. Faites une fois par semestre un exercice de bascule : c'est la seule façon de savoir que le plan fonctionne.