Guide des ports DNS : résolution de nom sur le port 53

Lorsqu'un client doit accéder à un domaine, il demande à un résolveur des enregistrements tels que A, AAAA, CNAME, MX, TXT, NS ou SRV. Le résolveur peut répondre à partir du cache ou parcourir la hiérarchie DNS via les serveurs racine, TLD et faisant autorité jusqu'à ce qu'il trouve l'enregistrement.

La plupart des requêtes client utilisent le port UDP 53 car la requête et la réponse sont petites. DNS peut passer à TCP lorsque les réponses sont trop volumineuses, lorsqu'une troncature se produit, lorsque DNSSEC augmente la taille de la réponse ou lorsque les serveurs effectuent des transferts de zone et d'autres opérations nécessitant un flux fiable.

UDP 53 est le chemin commun pour la résolution DNS quotidienne. Le bloquer interrompt généralement les recherches normales. TCP 53 n'est pas facultatif pour un déploiement DNS complet : il prend en charge les réponses volumineuses, le repli des réponses UDP tronquées, les réponses lourdes en DNSSEC et les transferts de zone entre serveurs autorisés.

Une règle de pare-feu qui autorise UDP 53 mais bloque TCP 53 peut créer des pannes intermittentes difficiles à diagnostiquer. Les petits enregistrements peuvent fonctionner tandis que les réponses DNSSEC, TXT ou liées au courrier plus volumineuses échouent.

Un serveur DNS faisant autorité publie les enregistrements pour les domaines que vous contrôlez. Il doit être accessible via Internet lorsqu'il dessert des zones publiques, mais il ne doit répondre avec autorité que pour ces zones et ne doit pas fournir de récursion ouverte.

Un résolveur récursif effectue des recherches pour les clients. Les résolveurs récursifs publics doivent être conçus et protégés pour ce rôle. Les résolveurs internes ne doivent généralement répondre que pour les réseaux approuvés, les clients VPN ou les environnements d'application spécifiques.

Ouvrez le port 53 vers Internet pour les serveurs DNS faisant autorité qui hébergent des zones publiques. UDP et TCP doivent être pris en compte. Si le serveur est interne uniquement, limitez l'accès aux réseaux nécessitant une résolution de nom.

N'exposez pas un résolveur récursif à l'ensemble d'Internet, sauf si vous exploitez intentionnellement un résolveur public avec limitation de débit, surveillance des abus et planification de capacité. Les résolveurs ouverts sont couramment utilisés pour les attaques par réflexion et par amplification.

Avant d'autoriser le port 53, décidez si le serveur fait autorité, récursif, de transfert, de mise en cache ou à horizon partagé. Confirmez quels clients doivent l'utiliser, quelles zones il dessert, si la récursion est activée et si les transferts de zone sont limités aux serveurs secondaires autorisés.

Un vérificateur de port peut confirmer que le port 53 est accessible, mais l'exactitude du DNS nécessite des tests au niveau du protocole. Utilisez les journaux de fouille, nslookup, d'exploration ou de résolution pour vérifier les réponses enregistrées, la politique de récursivité, le repli TCP, le comportement DNSSEC et les temps de réponse.

Sur Windows Server, le rôle de serveur DNS peut servir les zones intégrées à Active Directory, les enregistrements internes et les règles de transfert. Limitez soigneusement la récursivité et les transferts de zone, surtout si le serveur dispose d'une interface publique.

Sous Linux, les serveurs DNS courants incluent BIND, Unbound, PowerDNS, Knot DNS, CoreDNS et dnsmasq. Configurez les interfaces d'écoute, la politique de récursion, les clients autorisés, les zones faisant autorité, la journalisation et les règles de pare-feu pour UDP et TCP 53.

Sur les plateformes cloud, le DNS géré est souvent plus sûr pour les zones faisant autorité publique, car le fournisseur gère l'anycast, la mise à l'échelle et la résilience DDoS de base. Le DNS auto-hébergé nécessite toujours des instances redondantes, une surveillance et une politique réseau claire.

Commencez par une vérification du port externe pour UDP ou TCP 53, en fonction de ce que vous devez valider. Exécutez ensuite dig @server example.com A, dig @server example.com AAAA ou nslookup sur le résolveur cible pour confirmer les vraies réponses DNS.

Testez explicitement TCP avec dig +tcp @server example.com TXT ou une autre réponse volumineuse. Pour les serveurs faisant autorité, interrogez les enregistrements extérieurs à votre réseau et vérifiez que la récursivité est refusée. Pour les résolveurs récursifs, effectuez une requête à partir des réseaux sources autorisés et non autorisés.

Si le port 53 est fermé, le service DNS peut être arrêté, écoutant sur la mauvaise interface, bloqué par un pare-feu hôte ou restreint par un groupe de sécurité cloud. Si UDP ne semble pas fiable mais que TCP fonctionne, inspectez la MTU, la fragmentation, la taille de la réponse, les paramètres EDNS et le comportement lié à DNSSEC.

Si le port est ouvert mais que les recherches échouent, vérifiez les données de zone, la délégation, les enregistrements de colle, les enregistrements SOA et NS, la politique de récursivité, les redirecteurs, la validation DNSSEC, l'état du cache et les journaux. Les échecs DNS proviennent souvent de la configuration de la stratégie ou de la zone plutôt que de l’accessibilité brute du port.

N'exécutez pas un résolveur récursif ouvert par accident. Limitez la récursivité aux clients de confiance, limitez les transferts de zone aux serveurs secondaires connus, maintenez les logiciels DNS corrigés et surveillez les taux de requêtes, les pics NXDOMAIN, les pics SERVFAIL et les réseaux sources inhabituels.

Pour un DNS public faisant autorité, utilisez des serveurs redondants, DNSSEC le cas échéant, des durées de vie suffisamment courtes pour une flexibilité opérationnelle et une propriété claire des modifications de zone. Pour le DNS interne, protégez les enregistrements à horizon partagé, car ils révèlent souvent les noms d’infrastructure et la topologie privée.