On configure un serveur DNS, on ouvre le port 53 dans le pare-feu, et la question tombe : faut-il autoriser UDP seul, TCP seul, ou les deux ? Sur le terrain, la réponse dépend moins d’un choix théorique que du type de trafic DNS qui transite réellement sur le réseau.
Pourquoi le DNS utilise le port 53 en UDP et en TCP
Le port 53 est le port standard du DNS depuis la publication des RFC 1034 et 1035. À l’origine, UDP était le transport par défaut : une requête DNS classique tient dans un seul paquet, et UDP évite le coût d’établissement d’une connexion. Le client envoie sa question, le serveur répond, terminé.
A lire également : Quel processeur choisir pour tirer le meilleur de la RTX 4090
TCP entre en jeu dès que la réponse dépasse la taille maximale d’un datagramme UDP (historiquement 512 octets, étendu ensuite par EDNS). Quand un serveur DNS détecte qu’il ne peut pas faire tenir sa réponse dans un paquet UDP, il renvoie une réponse tronquée avec un flag « TC » (truncated). Le client relance alors la même requête en TCP.
On retrouve aussi TCP dans les transferts de zone (AXFR/IXFR) entre serveurs primaires et secondaires. Ces échanges portent sur des volumes de données bien plus importants qu’une simple résolution de nom, ce qui rend UDP inadapté.
Lire également : Écrans protégeant les yeux : choisir le type le moins fatigant
RFC 7766 : TCP n’est pas un fallback optionnel pour le DNS
Beaucoup d’administrateurs considèrent encore TCP comme un mécanisme de secours. La RFC 7766, publiée en mars 2016 avec le statut Standards Track, corrige cette idée. Elle formalise l’obligation de prise en charge de TCP pour tout service DNS et demande des performances comparables à celles d’UDP.
En pratique, bloquer TCP/53 dans un pare-feu peut provoquer des échecs de résolution silencieux. Les réponses DNSSEC, par exemple, incluent des signatures cryptographiques qui alourdissent les paquets. Si le serveur tronque la réponse et que le client ne peut pas basculer en TCP, la validation DNSSEC échoue.
DNS port TCP ou UDP : critères de choix en production
Le choix ne se pose pas comme une alternative binaire. On garde les deux protocoles ouverts sur le port 53, mais on ajuste la configuration selon le contexte.
Requêtes de résolution standard
Pour la résolution quotidienne (navigation web, requêtes applicatives), UDP reste le transport principal. La latence est minimale : pas de handshake en trois étapes, pas de maintien de connexion. Sur un résolveur qui traite des milliers de requêtes par seconde, cette économie compte.
Transferts de zone et réponses volumineuses
Les transferts de zone entre serveurs DNS autoritaires passent systématiquement par TCP. C’est aussi le cas pour les réponses qui dépassent la taille négociée via EDNS, ou pour les enregistrements DNSSEC volumineux. Fermer TCP/53 casse les transferts de zone et la validation DNSSEC.
Environnements soumis à des contraintes de sécurité
Sur des réseaux où l’on filtre agressivement le trafic, certaines équipes limitent UDP/53 pour réduire la surface d’attaque (amplification DNS, par exemple). Dans ce cas, forcer le DNS en TCP atténue le risque d’amplification, puisque TCP exige un handshake avant tout échange de données. Les retours varient sur ce point : le gain en sécurité se paie en charge serveur et en latence.
Vulnérabilités TCP sur le port DNS : ce que montre CVE-2024-0760
Ouvrir TCP/53 ne va pas sans précaution. L’avis de sécurité CVE-2024-0760, publié par ISC le 23 juillet 2024 pour BIND, décrit un scénario où un flux massif de messages DNS sur TCP peut rendre le serveur instable. Un attaquant qui ouvre de nombreuses connexions TCP simultanées vers le port 53 peut saturer les ressources du processus DNS.
Ce type de vulnérabilité rappelle que TCP, sur un service aussi exposé que le DNS, demande des mesures d’accompagnement :
- Limiter le nombre de connexions TCP simultanées par adresse source (rate limiting au niveau du pare-feu ou du serveur DNS lui-même)
- Configurer des timeouts courts sur les connexions TCP inactives pour libérer les ressources
- Appliquer les correctifs de sécurité du serveur DNS dès leur publication, en particulier pour BIND, Unbound ou PowerDNS
Bloquer TCP/53 pour se protéger de ces attaques n’est pas la bonne approche : on casse la conformité RFC et on empêche DNSSEC de fonctionner.
Au-delà du port 53 : DoT et DoH déplacent la question du protocole DNS
La question « TCP ou UDP sur le port 53 » ne couvre plus la totalité du paysage DNS en production. Deux protocoles chiffrés changent la donne :
- DNS over TLS (DoT) utilise TCP sur le port 853. Le trafic est chiffré, ce qui empêche l’inspection du contenu des requêtes par les équipements réseau intermédiaires
- DNS over HTTPS (DoH) encapsule le DNS dans du HTTPS sur le port 443. Le trafic DNS devient indiscernable du trafic web classique, ce qui complique le filtrage
- Certains navigateurs activent DoH par défaut, ce qui contourne les résolveurs DNS configurés au niveau du système ou du réseau local
Pour les équipes réseau, le travail ne se limite plus à gérer 53/udp et 53/tcp. Il faut aussi décider si on autorise, force ou bloque DoT et DoH selon la politique de sécurité. Des guides d’exploitation récents montrent que forcer le DNS local et bloquer les tentatives de contournement via DoH devient une pratique courante sur les pare-feu d’entreprise.
Sur un réseau correctement administré, le port 53 reste ouvert en UDP et en TCP. UDP porte l’essentiel du trafic de résolution, TCP prend le relais pour les réponses tronquées, les transferts de zone et DNSSEC. La vraie décision opérationnelle porte désormais sur la gestion des flux chiffrés (DoT, DoH) et sur le durcissement des connexions TCP face aux attaques par saturation. Garder un protocole et fermer l’autre sur le port 53 crée plus de problèmes qu’il n’en résout.
