La résolution de noms de domaine et le contrôle des ports TCP constituent deux piliers de la politique de sécurité réseau. Depuis l’entrée en application du règlement d’exécution européen 2024/2690 le 1er juillet 2025, les fournisseurs DNS, les registres de domaines de premier niveau et les services cloud sont soumis à des exigences techniques précises. Ce cadre réglementaire modifie concrètement la manière dont les équipes réseau doivent aborder le filtrage DNS et la gouvernance des flux TCP.
DNS chiffré et perte de visibilité réseau : un angle mort sous-estimé
DNS over HTTPS (DoH), DNS over TLS (DoT) et DNS over QUIC protègent la confidentialité des requêtes entre le poste client et le résolveur. Cette protection a un revers : lorsqu’un navigateur ou un système d’exploitation utilise un résolveur externe non contrôlé par l’organisation, les politiques de filtrage internes deviennent inopérantes.
Le problème ne se limite pas au contournement de listes de blocage. Un résolveur externe peut aussi empêcher la détection d’exfiltration de données par tunneling DNS, une technique qui encode des informations dans les requêtes elles-mêmes. Sans visibilité sur ces flux, les équipes de sécurité perdent une capacité de détection qui reposait sur l’analyse du trafic DNS en clair sur le port 53.
Pour conserver cette visibilité, il faut centraliser la résolution chiffrée vers un résolveur interne compatible DoH ou DoT. Les ressources de sécurité sur Open Syd détaillent les mécanismes de durcissement associés. Le filtrage au niveau du pare-feu doit alors bloquer les requêtes DNS sortantes vers des résolveurs tiers non autorisés, y compris sur le port 443 utilisé par DoH.
Ports TCP et filtrage DNS : construire une politique de contrôle cohérente
Le DNS utilise principalement le port UDP 53 pour les requêtes standard. Lorsque la réponse dépasse la taille maximale d’un datagramme UDP (512 octets par défaut), le serveur signale une troncature et le client bascule sur le port TCP 53 pour obtenir la réponse complète. Les transferts de zone entre serveurs DNS utilisent aussi TCP 53.
Cette dualité UDP/TCP crée une surface d’attaque spécifique. Bloquer TCP 53 en sortie sans discernement peut casser la résolution de certains enregistrements volumineux (DNSSEC, enregistrements TXT longs). En revanche, laisser TCP 53 ouvert sans restriction facilite le tunneling DNS et les transferts de zone non autorisés.
Critères pour un filtrage réseau adapté
- Autoriser TCP 53 uniquement entre les serveurs DNS internes et les résolveurs amont identifiés, jamais depuis les postes de travail directement
- Restreindre les ports sources éphémères (plage 49152-65535 selon les recommandations IANA) aux seuls processus de résolution DNS légitimes via des règles de pare-feu applicatif
- Surveiller les volumes anormaux de requêtes DNS sortantes, un indicateur classique de tunneling ou de communication avec un serveur de commande et contrôle (C2)
- Journaliser les requêtes DNS sur le résolveur interne pour alimenter le SIEM, ce qui compense la perte de visibilité liée au chiffrement bout en bout
Le filtrage par port seul ne suffit pas. La combinaison du contrôle de port et de l’analyse du contenu DNS (inspection des noms de domaine résolus, détection d’entropie élevée dans les sous-domaines) offre une couverture plus robuste contre les techniques d’évasion.
Obligations NIS2 : ce que la directive change pour la gestion DNS
La directive NIS2 (directive (UE) 2022/2555) et son règlement d’exécution 2024/2690 introduisent des obligations opérationnelles qui touchent directement l’infrastructure DNS des entités concernées.
En cas d’incident affectant la disponibilité ou l’intégrité du service DNS, le dispositif de notification impose une alerte initiale sous 24 heures, suivie d’une notification détaillée sous 72 heures, puis d’un rapport final dans un délai d’un mois. Ces délais supposent une capacité de détection et de qualification rapide des incidents DNS.
Le règlement couvre aussi la sécurité de la chaîne d’approvisionnement, la cryptographie et le contrôle d’accès. Pour un administrateur réseau, cela signifie que le choix d’un résolveur DNS externe (service cloud, résolveur public) doit intégrer une évaluation du fournisseur au regard de ces critères. Les retours terrain divergent sur ce point : certaines organisations considèrent que les grands résolveurs publics offrent une résilience supérieure, d’autres estiment que la dépendance à un tiers augmente le risque réglementaire.
Segmentation réseau et DNS : réduire la surface d’exposition par le routage
La segmentation réseau limite la propagation d’une compromission, mais son interaction avec le DNS est rarement traitée en détail. Un réseau segmenté en VLAN avec un résolveur DNS unique pour tous les segments offre un point de pivot à un attaquant qui compromet ce résolveur.
Déployer des résolveurs DNS dédiés par segment réseau réduit ce risque. Chaque résolveur ne résout que les noms nécessaires au segment qu’il dessert, et les règles de pare-feu interdisent les requêtes DNS inter-segments non autorisées. Cette approche alourdit l’administration, mais elle compartimente efficacement les mouvements latéraux.
Points de vérification pour un audit DNS
- Vérifier que chaque segment réseau dispose de règles explicites autorisant ou refusant le trafic DNS vers des destinations précises
- S’assurer que les enregistrements DNS internes (zones privées) ne sont pas accessibles depuis des segments exposés à internet
- Contrôler que les transferts de zone (AXFR/IXFR) sont restreints aux seuls serveurs secondaires autorisés, avec authentification TSIG
L’articulation entre DNS, ports TCP et segmentation réseau forme un ensemble cohérent dont chaque composant compense les limites des autres. Un filtrage de port sans gouvernance DNS reste perméable, tout comme un DNS sécurisé perd son efficacité si le routage réseau permet des contournements. La directive NIS2 pousse les organisations à formaliser cette articulation, mais les données disponibles ne permettent pas encore de mesurer le niveau réel de conformité atteint par les entités concernées.
