Le DNS n’attend pas d’excuse pour changer de terrain de jeu. Quand la taille d’une réponse explose les 512 octets, ou qu’une opération avancée comme un transfert de zone se profile, le protocole abandonne l’UDP pour basculer en TCP. Ce passage, invisible pour la majorité, a pourtant des conséquences immédiates sur la résolution des noms et la fluidité de la navigation. Un serveur mal configuré ou une transition mal gérée, et ce sont les requêtes qui s’égarent, les sites qui tardent à répondre.
Pourquoi le DNS utilise principalement UDP et dans quels cas le passage en TCP devient essentiel
Le DNS (domain name system) fait d’abord confiance à l’UDP (User Datagram Protocol) pour aller vite, tout simplement. L’UDP ne s’embarrasse pas de formalités : pas de connexion préalable, pas de contrôle d’état, il délivre la requête et file. Pour résoudre un nom de domaine standard, c’est largement suffisant. Les échanges sont compacts, la latence quasi-invisible.
Mais cette légèreté a ses revers. Dès qu’une réponse DNS s’étire et dépasse les fameux 512 octets, un cas fréquent avec DNSSEC ou lors d’un transfert de zone DNS,, la partie se complique. Cette fois, impossible de tout faire passer en UDP : le DNS port TCP prend le relais. TCP, c’est la connexion garantie, la livraison ordonnée, la promesse qu’aucun octet ne sera laissé en chemin. La RFC 1035 l’a gravé dans le marbre : si la réponse ne tient pas en un paquet, si la fragmentation échoue, ou si un serveur primaire doit synchroniser avec un secondaire, TCP s’impose.
Ce passage en TCP s’étend aussi aux contextes où la sécurité est non négociable. Avec DNS over TLS (DoT) ou DNS over HTTPS (DoH), le chiffrement exige une connexion robuste : le protocole TCP devient la norme. Les résolveurs modernes, sous Linux, macOS ou Windows, jonglent entre les deux modes selon la nature de la requête ou le niveau de confidentialité attendu.
Voici les usages typiques des deux protocoles :
- UDP : vitesse, faible charge, résolution quotidienne des noms de domaine.
- TCP : fiabilité, transfert de grandes quantités de données (transferts de zone, DNSSEC), sécurité accrue via DoT/DoH.
Ne pas proposer les deux, c’est s’exposer à des blocages ou ouvrir une brèche de sécurité. Les administrateurs ont tout intérêt à vérifier que leurs serveurs DNS acceptent UDP et TCP, pour garantir la continuité du service.
Problèmes courants lors du basculement UDP/TCP : comment les identifier et les résoudre facilement
Le basculement du DNS entre UDP et TCP n’est pas toujours une promenade de santé, surtout quand le réseau ou la configuration ne suivent pas. Premier indice : des requêtes DNS qui échouent par intermittence, surtout lorsque le domaine visé regorge d’enregistrements ou est protégé par DNSSEC. Une absence de retour, une attente interminable : souvent, le port TCP est en cause.
Dans certains réseaux, le port 53 TCP reste filtré, parfois par peur de menaces extérieures. Résultat, quand la réponse ne rentre plus dans l’enveloppe de l’UDP, le serveur n’arrive plus à transmettre l’information. Les outils de diagnostic comme dig sont sans appel : un « connection timed out » ou un « truncated » met en lumière le souci. Sur les postes équipés de Linux, macOS ou Windows, ces interruptions aléatoires sont accentuées par des politiques de sécurité trop strictes, ou des segmentations réseau mal pensées.
Pour mettre en évidence ces dysfonctionnements, il est utile de tester l’accessibilité des deux modes du DNS port. Une commande dig +tcp permet de vérifier si la connexion TCP passe bien. Côté utilisateur, consulter les logs des navigateurs récents comme Firefox ou Google Chrome aide à repérer les éventuels blocages liés à DoH activé par défaut.
Quelques vérifications simples permettent de rétablir la situation :
- Les pare-feu doivent laisser passer le trafic sur le port 53, aussi bien en UDP qu’en TCP, pour le serveur DNS.
- En cas d’échec des transferts de zone DNS, la configuration des serveurs secondaires mérite une attention particulière.
- Si le problème surgit avec DoT ou DoH, il faut s’assurer que l’infrastructure supporte bien le protocole basé sur connexion.
L’harmonie entre les différentes strates du réseau, clients, serveurs, routeurs, fait toute la différence. Un œil attentif sur les fichiers de logs, une configuration pensée pour le double protocole, et le passage de l’UDP au TCP devient une formalité, sans incident de parcours.
