Quand un navigateur tape une adresse web, la requête DNS part par défaut en UDP sur le port 53. Rapide, léger, efficace pour la majorité des résolutions.
Le problème commence quand la réponse dépasse la taille d’un datagramme UDP ou quand un transfert de zone doit transiter entre deux serveurs. Le protocole bascule alors sur TCP port 53, et c’est précisément ce flux que beaucoup d’entreprises négligent dans leurs règles de pare-feu. Mal configuré, ce port devient un angle mort exploitable pour l’exfiltration de données ou le contournement de politiques de sécurité.
A lire aussi : Cybersécurité en entreprise, l'expertise d'un cabinet change tout
Pourquoi le DNS utilise TCP sur le port 53 en entreprise
UDP gère les requêtes courtes. Mais plusieurs scénarios courants en environnement professionnel forcent le passage en TCP.
Les transferts de zone entre un serveur DNS primaire et ses secondaires utilisent TCP. C’est le mécanisme par lequel un serveur réplique l’intégralité de ses enregistrements vers un autre. Sans TCP 53 ouvert entre ces deux machines, la synchronisation échoue silencieusement.
A lire en complément : Auditeur système : rôle et missions dans une entreprise tech
Les réponses volumineuses dépassant la limite classique de 512 octets provoquent aussi une bascule vers TCP. C’est fréquent avec les enregistrements DNSSEC, qui ajoutent des signatures cryptographiques à chaque réponse. Un réseau d’entreprise qui déploie DNSSEC sans autoriser TCP 53 verra des résolutions échouer de manière intermittente, un type de panne difficile à diagnostiquer.
Dernier cas : certaines extensions DNS modernes, comme EDNS0, augmentent la taille maximale des datagrammes UDP. Quand la négociation EDNS0 échoue (pare-feu intermédiaire qui tronque les paquets, par exemple), le client DNS retombe sur TCP comme mécanisme de secours.
Tunneling DNS sur TCP : le risque que les pare-feu ignorent
Les attaques par tunneling DNS exploitent un fait simple : le trafic DNS sortant est presque toujours autorisé. Un attaquant encode des données dans des requêtes DNS apparemment légitimes, puis les fait transiter vers un serveur externe qu’il contrôle.
Le flux TCP 53 aggrave ce risque. Contrairement à UDP, une connexion TCP permet de maintenir un canal persistant, avec un débit plus élevé et une fiabilité de transmission qui facilite l’exfiltration de fichiers entiers.
Beaucoup de pare-feu d’entreprise traitent le port 53 comme un flux d’infrastructure anodin. Traiter TCP 53 comme un flux applicatif à risque change la donne. Cela signifie activer l’inspection applicative sur ce port, pas simplement autoriser ou bloquer au niveau transport.
Signaux d’alerte à surveiller sur le port 53 TCP
- Des sessions TCP 53 de longue durée vers des serveurs externes inconnus, alors qu’une résolution DNS normale se termine en quelques millisecondes
- Un volume de trafic DNS sortant anormalement élevé depuis un poste de travail ou un serveur qui n’a pas de rôle DNS
- Des requêtes portant sur des sous-domaines très longs ou encodés en base64, signe caractéristique d’un tunnel DNS actif
Règles de pare-feu pour le DNS port TCP en entreprise
La première erreur fréquente consiste à ouvrir TCP 53 en sortie vers n’importe quelle destination. En réalité, seuls vos serveurs DNS récursifs internes ont besoin de communiquer en TCP 53 avec les serveurs racine et les serveurs faisant autorité sur Internet.
Les postes de travail ne doivent jamais résoudre directement vers l’extérieur. Toute requête DNS d’un poste client passe par le résolveur interne. Le pare-feu bloque TCP et UDP 53 en sortie pour toutes les machines sauf les serveurs DNS désignés.
Pour les transferts de zone, la règle est encore plus stricte. TCP 53 n’est autorisé qu’entre le serveur primaire et ses secondaires identifiés, avec des adresses IP sources et destinations explicites. Aucune raison de laisser ce flux ouvert plus largement.
Configuration type en trois niveaux
- Niveau poste de travail : UDP et TCP 53 autorisés uniquement vers les résolveurs DNS internes, tout le reste bloqué
- Niveau serveur DNS récursif : TCP et UDP 53 autorisés en sortie vers les serveurs racine et les forwarders configurés, avec inspection applicative activée
- Niveau transfert de zone : TCP 53 autorisé exclusivement entre les adresses IP des serveurs DNS primaire et secondaires, dans les deux sens
DNS chiffré et migration progressive depuis le port 53 TCP
L’arrivée de DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) change la trajectoire du port 53 en entreprise. Ces protocoles encapsulent les requêtes DNS dans du TLS, respectivement sur les ports 443 et 853.
Windows Server 2025 prend en charge nativement DoH côté serveur. Le port 53 en clair reste actif en parallèle pour permettre une migration sans coupure. Cette coexistence impose de maintenir les règles de filtrage sur TCP 53 pendant toute la phase de transition, qui peut durer plusieurs mois dans un parc hétérogène.
Le piège serait de croire que DoH rend le filtrage du port 53 inutile. Tant que des clients ou des services internes utilisent le DNS classique, le port 53 TCP reste un vecteur d’attaque actif. La bonne approche consiste à migrer progressivement les résolveurs vers DoH ou DoT, puis à restreindre TCP 53 aux seuls flux de transfert de zone une fois la migration complète.
Obligations réglementaires NIS2 et supervision du service DNS
La directive NIS2 (UE 2022/2555) classe les fournisseurs de services DNS comme entités essentielles, indépendamment de leur taille. Pour une entreprise qui opère ses propres serveurs DNS, cela implique des obligations de supervision, de journalisation et de réponse aux incidents sur l’ensemble du service de résolution.
Journaliser les connexions TCP 53 entrantes et sortantes devient une mesure de conformité, pas simplement une bonne pratique. Les logs doivent inclure l’adresse source, la destination, la durée de la session et le volume échangé. Ces données alimentent la détection d’anomalies, notamment les tunnels DNS évoqués plus haut.
La supervision active du port 53 TCP, combinée à des alertes sur les comportements atypiques, répond directement aux exigences NIS2 en matière de gestion des risques liés à la sécurité des réseaux.
Le port 53 TCP n’est pas un détail de configuration réseau. C’est un flux qui mérite ses propres règles de filtrage, sa propre supervision et sa propre stratégie de migration vers les protocoles chiffrés. Les entreprises qui le traitent avec le même sérieux que leurs autres flux applicatifs réduisent considérablement leur surface d’attaque sur la couche DNS.
