On déploie un service dans le cloud, les résolutions DNS fonctionnent en UDP, tout roule. Puis un jour, une réponse DNSSEC dépasse la taille d’un paquet UDP, le résolveur bascule sur TCP/53, et le pare-feu cloud bloque silencieusement la connexion. Résultat : des timeouts intermittents, impossibles à reproduire en local. Ce scénario revient souvent dans les environnements AWS, Azure ou GCP, et il illustre un angle mort que beaucoup d’équipes découvrent en production.
Fallback TCP/53 bloqué par les security groups : le piège le plus fréquent
La majorité des configurations de security groups ou de NSG autorisent le DNS sur UDP/53 par défaut. Le port TCP/53, lui, est souvent omis ou explicitement fermé par des règles de durcissement automatisées.
A voir aussi : Les erreurs à éviter lors de la suppression de compte Leboncoin
Le problème survient quand une réponse DNS excède la limite habituelle d’un datagramme UDP. Le serveur DNS envoie alors une réponse tronquée avec le flag TC (Truncated), et le client retente en TCP. Si le port TCP/53 est bloqué, la résolution échoue après un timeout.
Les cas déclencheurs les plus courants :
Lire également : Les 10 erreurs de sécurité informatique à éviter absolument
- Réponses DNSSEC volumineuses, notamment quand le résolveur valide les signatures sur des zones signées avec des clés longues
- Enregistrements TXT surchargés par les politiques SPF, DKIM ou DMARC, fréquents sur les domaines d’envoi d’emails
- Transferts de zone (AXFR/IXFR) entre serveurs DNS primaires et secondaires, qui utilisent exclusivement TCP
- Réponses contenant de nombreux enregistrements (round-robin DNS, géolocalisation, service discovery dans Kubernetes)
La correction est simple sur le papier : autoriser TCP/53 en sortie et en entrée sur les résolveurs. En pratique, on oublie souvent de l’appliquer sur tous les sous-réseaux, ou bien une politique IaC (Terraform, Pulumi) écrase la règle au prochain déploiement.
DNS sur TCP et détection de menaces cloud : faux positifs dans le SOC
Dans les environnements cloud managés, le trafic DNS sur TCP/53 est systématiquement journalisé et corrélé par les services de détection de menaces. Azure Sentinel, AWS GuardDuty ou GCP Security Command Center analysent ce trafic pour identifier des comportements suspects.
Le problème, c’est que le DNS tunneling utilise exactement le même canal que le fallback TCP légitime. Un attaquant qui exfiltre des données encode ses payloads dans des requêtes DNS sur TCP/53. Du point de vue du SOC, un pic soudain de trafic DNS TCP ressemble à une tentative de C2 (command and control).
Ce que ça provoque concrètement
On a des alertes automatisées qui bloquent le trafic ou isolent l’instance. Le service légitime qui avait simplement besoin d’un fallback TCP se retrouve coupé. Les retours varient sur ce point selon les configurations, mais le schéma revient : une alerte de tunneling DNS déclenche un blocage automatisé, et personne ne comprend pourquoi la résolution DNS tombe par intermittence.
Pour éviter ce scénario, il faut créer des exceptions explicites dans les règles de détection pour les résolveurs internes et les plages IP légitimes. Documenter dans la politique de sécurité quels services sont autorisés à générer du trafic DNS TCP, et à quel volume, permet au SOC de distinguer un fallback normal d’une exfiltration.
Configuration DNS et authentification email : SPF, DKIM, DMARC en environnement cloud
Un angle rarement anticipé : les défaillances DNS sur TCP/53 cassent l’authentification des emails. Les enregistrements SPF, DKIM et DMARC reposent sur des requêtes DNS TXT qui peuvent dépasser la taille maximale UDP.
Quand un résolveur cloud ne peut pas compléter la résolution en TCP, la vérification DMARC échoue. Le serveur de réception ne parvient pas à valider l’enregistrement SPF ou la clé publique DKIM. Résultat : des emails légitimes classés en spam ou rejetés à cause d’un port TCP bloqué.
Ce type de problème est documenté depuis 2024 dans les guides de durcissement DNS des plateformes d’email security. Un mauvais comportement des résolveurs DNS (timeouts sur TCP/53, blocage partiel, inspection TLS cassante sur le port) provoque directement des défaillances d’authentification DMARC et des faux positifs antispam.
Points de vérification pour le filtrage DNS lié aux emails
- Vérifier que les règles de pare-feu autorisent le TCP/53 en sortie depuis les serveurs de messagerie et les résolveurs utilisés par le MTA
- Tester la résolution TCP des enregistrements TXT du domaine avec
dig +tcp TXT example.comdepuis une instance cloud - Surveiller les logs DNS pour repérer les réponses tronquées (flag TC) qui ne sont jamais suivies d’une requête TCP
Règles de filtrage DNS dans les architectures cloud hybrides
Dans une architecture hybride (on-premises connecté au cloud via VPN ou interconnexion), le DNS traverse plusieurs périmètres. Chaque périmètre a ses propres règles de filtrage, et le port TCP/53 doit être ouvert sur chaque segment du chemin.
Un cas typique : le résolveur cloud forwarde les requêtes vers un serveur DNS on-premises via un tunnel VPN. Le security group autorise UDP/53, le tunnel laisse passer UDP/53, mais le pare-feu on-premises bloque TCP/53 en entrée. Les requêtes courtes fonctionnent, les requêtes longues échouent.
Segmentation réseau et DNS forwarders
Google Cloud recommande dans ses bonnes pratiques de bien identifier où la résolution DNS est effectuée et de s’assurer que les flux sont autorisés dans les deux sens. Quand on utilise des DNS forwarders conditionnels (pour résoudre des zones privées dans un VPC ou un VNET), chaque maillon de la chaîne de forwarding doit accepter TCP/53.
La segmentation réseau en défense en profondeur complique la situation. Plus on isole les périmètres d’administration (ce qui est souhaitable pour la sécurité), plus on multiplie les points où une règle de filtrage peut bloquer le fallback TCP.
Le réflexe à adopter : tester systématiquement la résolution DNS en TCP après chaque modification de règles réseau, pas seulement en UDP. Un simple dig +tcp sur quelques domaines critiques suffit à valider que le chemin complet fonctionne.
Le DNS sur TCP/53 n’est pas un cas marginal qu’on peut ignorer. Les réponses volumineuses, les enregistrements d’authentification email et les transferts de zone en dépendent. Dans le cloud, où chaque flux traverse des couches de filtrage et de détection, un port TCP/53 fermé ou mal supervisé produit des pannes sournoises, difficiles à diagnostiquer parce qu’intermittentes.
Ajouter TCP/53 aux règles, documenter les exceptions dans le SOC et valider le chemin complet après chaque changement réseau, c’est le minimum pour éviter de perdre des heures sur un problème qui ne devrait pas en être un.
