Le DNS est traité comme une infrastructure de base : vous signalez les serveurs de noms, configurez un enregistrement A et un enregistrement MX, et oubliez cela. Ce que Cloudflare fait avec un enregistrement proxy rompt ce principe : le protocole existe toujours, mais ce qui se passe lorsque vous activez le mode proxy change la signification du DNS dans votre architecture.
Qu'est-ce qui change lorsque vous proxyez un enregistrement
Lorsque vous créez un enregistrement A dans Cloudflare et activez le proxy (l'icône de nuage orange), l'adresse IP que vos clients reçoivent dans la réponse DNS n'est pas votre adresse IP d'origine. Cloudflare renvoie l'une de ses propres adresses IP, des adresses appartenant au réseau anycast de l'entreprise, réparties sur plus de 300 points de présence dans le monde.
Chaque requête HTTP et HTTPS qui atteint ce domaine entre dans le réseau Cloudflare avant d'atteindre votre serveur. TLS se termine au PoP le plus proche du client. Le WAF inspecte la demande. Des règles de limitation de débit sont appliquées. Le cache est consulté. L’atténuation des attaques DDoS fonctionne en périphérie. Ce n'est qu'alors — si la requête a traversé toutes ces couches — qu'elle est transmise à son origine, via une connexion distincte, via le réseau interne de Cloudflare. La véritable adresse IP de votre serveur reste cachée à tout client externe.
Le DNS, dans ce modèle, est le point d'entrée de toute la chaîne de sécurité et de performances, et non le service qui la précède.
Anycast : Pourquoi 300 PoP sont importants pour la latence
La plupart des réseaux fonctionnent avec un routage unicast : chaque adresse IP est annoncée à partir d'un seul emplacement et le paquet parcourt toute la distance jusqu'à ce centre de données, quel que soit l'endroit où se trouve le client.
Le réseau Cloudflare fonctionne avec anycast : le même bloc d'adresses IP est annoncé simultanément depuis chacun des plus de 300 points de présence, via BGP. Lorsqu'un client reçoit une adresse IP Cloudflare dans la réponse DNS, l'infrastructure BGP d'Internet achemine le paquet vers le PoP géographiquement le plus proche. TLS se termine là, à quelques millisecondes du client. L'itinéraire jusqu'à son origine — qui peut se trouver dans une autre région du monde — s'effectue via le réseau privé de Cloudflare, avec des itinéraires optimisés entre les PoP, invisibles pour l'utilisateur final.
Propagation, TTL et séparation entre faisant autorité et récursif
Deux rôles distincts coexistent dans l'offre DNS de Cloudflare, et les confondre conduit à des attentes erronées lors d'incidents. Le service faisant autorité – lorsque vous déléguez votre domaine aux serveurs de noms de Cloudflare – est ce qui répond avec autorité sur vos enregistrements. 1.1.1.1 est un résolveur récursif public, un service distinct qui interroge les serveurs faisant autorité pour le compte des clients. Vous pouvez utiliser les serveurs de noms Cloudflare pour votre domaine sans jamais utiliser la version 1.1.1.1, et vice versa.
Lorsque vous modifiez un enregistrement dans le tableau de bord Cloudflare, la modification se propage à travers le réseau faisant autorité en 30 secondes environ – un nombre impressionnant pour ceux provenant de fournisseurs qui mettent des heures à mettre à jour les zones. Le problème est que la « propagation », dans le sens où elle affecte les utilisateurs réels, dépend d'une autre couche : les résolveurs récursifs.
Les résolveurs tels que les résolveurs 8.8.8.8 de Google et les résolveurs FAI mettent en cache les réponses par le TTL du registre. Si le TTL était à 3 600 secondes lorsqu'un résolveur a effectué la requête, il continuera à répondre avec l'ancienne valeur pendant une heure maximum, même si Cloudflare a déjà servi le nouvel enregistrement pendant 30 secondes. La « propagation complète » vers tous les clients prend exactement la durée de vie maximale en vigueur au moment du changement.
La durée de vie par défaut pour les enregistrements sans proxy sur Cloudflare est de 300 secondes. Les enregistrements proxy exposent toujours une durée de vie de 300 secondes en externe, quelle que soit la valeur interne : Cloudflare a besoin de cette flexibilité pour gérer ses propres adresses IP anycast. Avant tout changement planifié (migration de source, basculement, rotation IP) la procédure correcte consiste à réduire la durée de vie à 60 ou 300 secondes à l'avance, à attendre que les résolveurs mettent à jour le cache, à exécuter la modification et à augmenter la durée de vie plus tard. Procéder dans l’ordre inverse revient à vivre avec une propagation lente, exactement alors que le coût est plus élevé.
Aplatissement du CNAME et problème de l'apex
La spécification DNS d'origine interdit CNAME au sommet du domaine (exemplo.com lui-même sans sous-domaine) car il entre en conflit avec les enregistrements SOA et NS requis. Pendant des années, cela a obligé les équipes à corriger les adresses IP dans l'enregistrement A du domaine racine, créant des frictions avec les services qui ne garantissent pas les adresses IP statiques : les équilibreurs de charge dans AWS n'exposent que les noms DNS, pas les adresses IP.
Cloudflare résout ce problème avec CNAME Flattening. Lorsque vous configurez un CNAME pour l'apex, Cloudflare résout la cible en temps réel (en interrogeant le A et l'AAAA de la cible au moment de la demande) et renvoie ces adresses IP directement au client. Du point de vue du résolveur externe, il s'agit d'un enregistrement A normal.
Qu'est-ce que cela exige de ceux qui gèrent la production
Les équipes qui traitent le DNS comme une configuration statique rencontrent des problèmes spécifiques lorsqu'elles fonctionnent sur Cloudflare. Le mode proxy de chaque registre (activé ou désactivé) détermine si les systèmes de sécurité et de performances de pointe gênent ou non. Un enregistrement A avec proxy désactivé expose la véritable adresse IP de la source, invalide la protection DDoS et supprime le WAF du flux. Vérifier quels enregistrements sont mandatés et lesquels ne le sont pas n'est pas une tâche de mise en œuvre initiale ; doit faire partie du processus d’examen des changements.
TTL mérite une attention opérationnelle continue. Un TTL élevé réduit la charge faisant autorité et améliore le cache dans les résolveurs, mais augmente le temps de récupération pour les modifications d'itinéraire. La tolérance au temps de propagation est souvent différente entre les enregistrements critiques tels que les sous-domaines MX et les services internes – et cette différence doit être explicite dans les paramètres de zone.
La surveillance active de la propagation lors des modifications du registre évite les surprises. Des outils comme whatsmydns.net montrent ce que les différents résolveurs du monde entier renvoient à ce moment-là. Lorsque la modification a été effectuée mais que les utilisateurs signalent toujours un échec d'accès, la cause probable est un résolveur mis en cache depuis longtemps : la réponse est d'attendre l'expiration de la durée de vie, et non d'empiler une autre modification d'enregistrement par-dessus.
A lire aussi
- Cloudflare Load Balancing et Geo Steering : quand le DNS devient une couche de trafic intelligente -DNSSEC avec Cloudflare : ce qu'il protège, ce qu'il ne protège pas et comment l'activer sans problème
- Cloudflare Email Routing : recevez des e-mails sur votre domaine — et ce qui n'est pas inclus
- Migration DNS vers Cloudflare : la checklist qui évite trois heures de black-out
- DNS proxy vs DNS uniquement : ce qui change et quand chaque mode a du sens -Cloudflare Durable Objects : État cohérent à la périphérie – ce qui change vraiment