Le port 53 est le point de passage obligé de toute résolution DNS. Quand un navigateur, un script ou un service tente de traduire un nom de domaine en adresse IP, la requête transite par ce port sur le serveur DNS cible.
Bloquer ou mal configurer le port 53 en TCP revient à couper silencieusement une partie du trafic DNS, parfois sans message d’erreur explicite. Vérifier son ouverture ne prend que quelques minutes, mais la méthode varie selon le système et le contexte réseau.
A voir aussi : Sécurité des IS : les critères clés à ne pas négliger
Écoute locale ou écoute réseau : le piège classique du port 53
Un serveur DNS peut tourner et répondre parfaitement en local sans jamais accepter de connexion distante. C’est le cas le plus fréquent quand on installe BIND ou un autre résolveur sans toucher à sa configuration d’écoute.
La commande netstat -lp --inet (ou ss -tlnp sur les distributions récentes) affiche les sockets en écoute. Si la colonne adresse locale indique 127.0.0.1:53 ou localhost:domain, le service DNS n’écoute que sur la boucle locale. Un telnet mon_ip 53 depuis une autre machine ne recevra aucune réponse, alors que telnet 127.0.0.1 53 fonctionnera sans problème depuis le serveur lui-même.
A lire également : L'authentification renforcée : un standard devenu incontournable
Pour corriger ce comportement sur BIND, il faut modifier la directive listen-on dans named.conf.options afin d’y inclure l’adresse IP publique ou privée du serveur, puis redémarrer le service. Ce détail de configuration est la cause de la majorité des « port 53 fermé » signalés sur les forums d’administration système.
Tester l’ouverture du port 53 TCP sous Linux et Windows
La vérification repose sur deux niveaux : confirmer que le service écoute, puis confirmer que le pare-feu laisse passer le trafic.
Depuis le serveur lui-même
Sur Linux, ss -tlnp | grep :53 liste les processus écoutant en TCP sur le port 53. La présence d’une ligne avec l’adresse 0.0.0.0:53 ou l’IP du serveur signifie que le service accepte les connexions entrantes. Sur Windows Server, la commande équivalente est netstat -an | findstr :53.
Depuis une machine distante
Telnet reste l’outil le plus direct pour un test rapide :
telnet adresse_du_serveur 53– si la connexion s’établit (écran vide ou curseur clignotant), le port TCP est ouvert et le service répond- Si le message « connexion refusée » apparait, le port est accessible mais aucun service n’écoute
- Un timeout sans réponse indique un filtrage par un pare-feu ou un équipement réseau intermédiaire
Sur les systèmes où telnet n’est pas installé, Test-NetConnection -ComputerName adresse -Port 53 sous PowerShell donne un résultat explicite avec un champ TcpTestSucceeded à True ou False.
Règles de pare-feu : iptables, firewalld et Windows Defender
Même quand le service DNS écoute correctement, un pare-feu mal configuré bloque le port 53 sans avertissement. Le diagnostic doit couvrir les deux protocoles, car le DNS utilise UDP pour la majorité des requêtes courtes et TCP pour les transferts de zone, les réponses volumineuses et DNSSEC.
Linux avec iptables
Ouvrir le port 53 en entrée sur les deux protocoles nécessite deux règles distinctes :
iptables -A INPUT -p tcp --dport 53 -j ACCEPTiptables -A INPUT -p udp --dport 53 -j ACCEPT- Penser à sauvegarder les règles avec
iptables-saveou via le mécanisme de persistance de la distribution (netfilter-persistent, iptables-services)
Avec firewalld, la commande firewall-cmd --permanent --add-service=dns ouvre automatiquement le port 53 en TCP et UDP. Un firewall-cmd --reload applique la modification.
Windows Server
Le service DNS de Windows crée normalement sa propre règle dans le pare-feu Windows Defender. Si ce n’est pas le cas, une règle entrante autorisant le port 53 en TCP et UDP doit être ajoutée manuellement dans les paramètres avancés du pare-feu. Vérifier que le profil réseau actif (domaine, privé ou public) correspond au profil de la règle évite un blocage discret que les journaux système ne signalent pas toujours clairement.
DNS sur TCP : les cas où le port 53 TCP devient indispensable
Beaucoup d’administrateurs configurent le port 53 uniquement en UDP, partant du principe que les requêtes DNS classiques n’utilisent pas TCP. Cette approche tronque le fonctionnement normal du DNS dans plusieurs situations concrètes.
Les transferts de zone (AXFR, IXFR) entre serveur DNS primaire et secondaires passent exclusivement par TCP. Un port 53 TCP fermé empêche toute synchronisation de zone, ce qui peut provoquer des réponses obsolètes ou des échecs de résolution sur les serveurs secondaires.
Les réponses DNS dépassant la taille standard d’un paquet UDP (historiquement limitée) déclenchent un mécanisme de repli vers TCP. Avec l’adoption de DNSSEC, qui ajoute des signatures cryptographiques aux enregistrements, la taille des réponses DNS augmente et le recours à TCP devient plus fréquent. Bloquer TCP sur le port 53 peut donc provoquer des échecs de validation DNSSEC chez les clients.
Le mécanisme EDNS (Extension Mechanisms for DNS) permet d’augmenter la taille des paquets UDP, mais tous les équipements réseau intermédiaires ne le gèrent pas correctement. En cas de fragmentation ou de troncature, TCP reste le filet de secours.
Diagnostic complet : checklist de vérification du port 53
Quand une résolution DNS échoue et que le port 53 est suspecté, la vérification gagne à suivre un ordre logique, du plus proche au plus éloigné.
Commencer par confirmer que le service DNS tourne (systemctl status named ou Get-Service DNS sous Windows). Vérifier ensuite l’adresse d’écoute avec ss ou netstat. Puis tester la connectivité TCP depuis une machine distante avec telnet ou PowerShell. Enfin, examiner les règles de pare-feu locales et, si un pare-feu matériel ou un groupe de sécurité cloud (type AWS Security Group ou NSG Azure) se trouve en amont, vérifier que le port 53 y est aussi autorisé en TCP et UDP.
Sur les box internet grand public, la redirection du port 53 peut poser des contraintes spécifiques. Certains modèles interceptent les requêtes DNS sortantes sur le port 53 pour les rediriger vers leurs propres résolveurs, ce qui complique l’hébergement d’un serveur DNS domestique.
Un port 53 TCP correctement ouvert, du service jusqu’au dernier pare-feu traversé, garantit que le DNS fonctionne dans tous ses modes de transport. Négliger la partie TCP revient à parier que les réponses DNS resteront toujours petites, un pari de moins en moins tenable avec la généralisation de DNSSEC et des enregistrements volumineux.
