DNS proxy vs DNS uniquement : ce qui change et quand chaque mode a du sens

La plupart des équipes qui migrent vers Cloudflare considèrent le choix entre le cloud orange et le cloud gris comme un détail de configuration. Ils activent le proxy pour tout, supposent qu'une meilleure protection est toujours préférable et découvrent l'erreur des semaines plus tard lorsqu'une base de données commence à renvoyer un délai d'attente sans aucun message d'erreur — ou lorsqu'ils se rendent compte que l'adresse IP source a toujours été exposée dans les enregistrements qui comptent vraiment.

Que fait réellement le mode proxy

Lorsqu'un enregistrement A ou CNAME est en mode proxy, le DNS faisant autorité de Cloudflare ne renvoie pas l'adresse IP de votre serveur d'origine. Il renvoie une adresse IP anycast de Cloudflare lui-même. Le client se connecte à l'un des nœuds périphériques du réseau, qui complète TLS, inspecte la demande et transmet ensuite le trafic à son serveur - éventuellement avec la mise en cache activée, avec les règles WAF appliquées, les Workers interceptant la demande à mi-chemin.

La véritable adresse IP du serveur est cachée au DNS public. Toute requête externe au registre renvoie les adresses IP Cloudflare, pas les vôtres. Cela a des implications concrètes : un attaquant souhaitant contourner WAF devra découvrir l'adresse IP source par un autre moyen : journaux divulgués, certificats TLS historiques dans crt.sh, en-têtes de courrier électronique ou connexions directes à des services auxiliaires exposés sans proxy.

La durée de vie visible de l'extérieur est toujours de 300 secondes, quelle que soit la configuration interne de la zone. Cloudflare contrôle ce que les résolveurs externes reçoivent et mettent en cache : la configuration interne est uniquement destinée à la synchronisation entre les propres serveurs de noms de Cloudflare.

Ce que propose le mode DNS uniquement

Avec l'icône grise, Cloudflare fonctionne exclusivement comme un DNS faisant autorité. La requête de nom renvoie la véritable adresse IP du serveur. Il n'y a pas de terminaison TLS à la périphérie, il n'y a pas de WAF, il n'y a pas de cache, il n'y a pas de Workers dans le chemin. Le client se connecte directement au serveur d'origine et Cloudflare ne voit jamais le trafic.

Pour les enregistrements MX, cette absence de proxy est obligatoire. Le flux de livraison des e-mails nécessite que les serveurs d'envoi se connectent directement au serveur de messagerie indiqué dans l'enregistrement MX. Si l'enregistrement MX tentait de passer par le proxy Cloudflare, le SMTP atteindrait un nœud périphérique qui ne sait pas quoi faire du trafic sur le port 25 — et l'e-mail n'arriverait tout simplement pas. Cloudflare ne vous permet même pas d'activer le proxy sur les enregistrements MX ; La valeur par défaut est DNS uniquement et ne peut pas être modifiée.

Il en va de même pour tout service TCP autre que HTTP ou HTTPS sur les ports pris en charge. Le proxy Cloudflare comprend HTTP/HTTPS sur les ports 80 et 443 et un ensemble restreint de ports alternatifs documentés : 8080, 8443 et quelques autres. Tout ce qui se trouve en dehors de cet ensemble est invisible pour le proxy.

Le piège de la base de données derrière un enregistrement proxy

C’est le scénario qui apparaît le plus silencieusement dans les incidents. Un enregistrement A pointe vers un serveur exécutant MySQL sur le port 3306. L'équipe active le mode proxy car « nous voulons plus de protection ». Le client tente de se connecter au port 3306, mais se connecte désormais au nœud périphérique Cloudflare, qui n'achemine pas le trafic TCP arbitraire. La connexion s'ouvre, attend et se ferme en raison d'un délai d'attente. Il n'y a pas de message d'erreur clair. MySQL ne voit même pas la tentative de connexion.

La même chose se produit avec PostgreSQL sur le port 5432, avec Redis sur le port 6379, avec n'importe quel protocole binaire autre que HTTP. Le proxy rejette simplement le trafic qu’il ne peut pas interpréter. Pour exposer ces services, le registre doit être en mode DNS uniquement – et la conséquence directe est que l'adresse IP du serveur est visible publiquement.

Les enregistrements de sous-domaines pour SSH direct appartiennent également à cette catégorie. Si l'équipe maintient un enregistrement ssh.exemplo.com pointant vers un serveur bastion, il doit s'agir uniquement de DNS. Le proxy rompra la connexion de la même manière.

Auditer ce qui est exposé dans votre région

La question qui mérite d'être posée périodiquement est simple : quels enregistrements de zone sont en mode DNS uniquement et le trafic qui les traverse est-il protégé d'une autre manière ?

Seuls les enregistrements DNS exposent des adresses IP qui peuvent être utilisées pour attaquer directement l'origine, en contournant toutes les règles WAF configurées dans les enregistrements proxy. Si un serveur apparaît à la fois dans un enregistrement proxy et dans un autre enregistrement DNS uniquement – ou si l'adresse IP a été exposée à un moment donné dans le passé et est indexée dans des services comme Shodan – l'effet protecteur du proxy est partiel.

Pour éliminer complètement l'exposition de l'IP source dans les services HTTP, Cloudflare Tunnel résout définitivement le problème. Le serveur d'origine établit une connexion sortante au réseau Cloudflare à l'aide du démon cloudflared. Le trafic utilisateur arrive à la périphérie, passe par des tunnels vers le serveur et le serveur n'a jamais besoin d'accepter les connexions entrantes : il n'y a pas de port ouvert, pas d'adresse IP exposée. Pour le trafic TCP arbitraire en dehors de HTTP, Cloudflare Spectrum couvre ce scénario mais est exclusif au plan Entreprise.

Ce qu'il faut vérifier avant de considérer la configuration fermée

Les zones qui s’agrandissent au fil du temps accumulent des enregistrements créés dans différents contextes, par différentes personnes, avec des intentions parfois non documentées. Un caractère générique *.exemplo.com en mode proxy est légitime et utile pour les sous-domaines créés dynamiquement, mais il peut masquer le fait que des enregistrements spécifiques au sein de ce caractère générique ont été créés manuellement en tant que DNS uniquement pour des raisons dont personne ne se souvient plus.

Les enregistrements TXT et CAA ne font jamais l'objet d'un proxy : il s'agit de données que les clients doivent lire directement, et Cloudflare n'interfère pas. SRV et NS sont également en dehors du proxy. Dans ces cas, l’interface ne présente même pas l’option.