Le DNS utilise le port 53 en TCP et en UDP, mais la majorité du trafic quotidien transite en UDP. TCP sur le port 53 reste pourtant un composant non négociable de toute infrastructure DNS correctement dimensionnée. Nous constatons que beaucoup d’architectes réseau traitent encore TCP/53 comme un cas marginal, alors que les évolutions protocolaires récentes et les contraintes opérationnelles réelles en font un canal de transport à part entière.
Troncature DNS et bascule TCP : le mécanisme que les middleboxes cassent
Quand une réponse DNS dépasse la taille maximale négociée en UDP (historiquement 512 octets, étendue par EDNS0), le serveur positionne le bit TC (truncated) dans l’en-tête de la réponse. Le client doit alors rejouer la requête en TCP sur le même port 53.
Ce mécanisme de fallback est défini depuis les origines du protocole. En pratique, il échoue régulièrement dans les environnements où des pare-feu ou des équilibreurs de charge bloquent TCP/53, considérant à tort que le DNS est un protocole exclusivement UDP.
Le problème s’aggrave avec DNSSEC. Les signatures cryptographiques ajoutent plusieurs centaines d’octets aux réponses. Une zone signée avec des enregistrements RRSIG, DNSKEY et DS produit couramment des réponses qui dépassent la limite UDP même avec EDNS0 configuré à 1232 octets. Sans TCP/53 ouvert, DNSSEC est fonctionnellement cassé.
Fragmentation IP : pourquoi UDP ne suffit plus
La RFC 10001 (août 2026) recommande explicitement que le DNS-over-TCP soit disponible en production comme fallback, plutôt que de compter sur des réponses UDP fragmentées. La fragmentation IP pose des problèmes de sécurité (attaques par empoisonnement via fragments forgés) et de fiabilité (perte de fragments sur des chemins réseau asymétriques).
Nous recommandons de configurer la taille de buffer EDNS0 à 1232 octets maximum et de garantir que TCP/53 est autorisé de bout en bout. C’est la combinaison la plus fiable pour éviter à la fois la fragmentation et les échecs silencieux de résolution.
DNS sur TCP dans les transferts de zone et la réplication
Le cas d’usage le plus ancien de TCP/53 reste le transfert de zone (AXFR et IXFR). Un transfert de zone complet peut représenter plusieurs mégaoctets de données pour une zone volumineuse. UDP est structurellement inadapté à ce volume.
- AXFR (transfert complet) : le serveur secondaire télécharge l’intégralité de la zone depuis le primaire via une connexion TCP persistante sur le port 53
- IXFR (transfert incrémental) : seuls les changements depuis le dernier numéro de série SOA sont transmis, toujours en TCP lorsque la taille dépasse la limite UDP
- NOTIFY : le message de notification lui-même passe en UDP, mais le transfert déclenché bascule systématiquement en TCP
Bloquer TCP/53 entre serveurs primaires et secondaires empêche toute synchronisation de zone. C’est une erreur de configuration courante dans les architectures multi-sites où les règles de pare-feu sont gérées par des équipes différentes.
Résolveurs en conteneurs : le piège musl et Alpine Linux
Un cas concret illustre les conséquences d’une implémentation incomplète du fallback TCP. Dans des environnements conteneurisés basés sur Alpine Linux, la bibliothèque musl (le résolveur DNS de la libc Alpine) ne basculait pas correctement vers TCP après réception d’une réponse UDP tronquée.
Le résultat : des échecs silencieux de résolution DNS dans les conteneurs. Aucun message d’erreur explicite, simplement des connexions applicatives qui échouent par timeout. Ce comportement a été corrigé dans Alpine 3.18, mais il reste présent dans les images plus anciennes encore largement déployées.
Ce type de défaut passe inaperçu dans les tests unitaires parce que les réponses DNS courantes (enregistrements A, AAAA simples) tiennent en UDP. Le bug ne se manifeste que lorsque la réponse est volumineuse, typiquement avec DNSSEC activé ou des enregistrements TXT longs comme ceux utilisés pour SPF ou DKIM.
Vérification pratique du support TCP dans un résolveur
Pour tester si un résolveur gère correctement le fallback TCP, nous utilisons une requête forcée en TCP avec dig :
dig +tcp @adresse-resolveur domaine.example A
Si la réponse arrive, TCP/53 fonctionne de bout en bout. Si la requête expire, le problème se situe soit au niveau du résolveur, soit sur un équipement intermédiaire qui filtre TCP/53.
DNS-over-TLS et DNS-over-QUIC : TCP au-delà du port 53
Les protocoles de chiffrement du DNS reposent sur des transports différents du port 53 classique, mais TCP y joue un rôle central.
- DNS-over-TLS (DoT) utilise le port 853 en TCP. La connexion TLS est établie avant toute requête DNS, ce qui élimine le problème de troncature mais ajoute la latence du handshake TLS
- DNS-over-HTTPS (DoH) transite sur le port 443 en TCP, encapsulé dans HTTP/2 ou HTTP/3. Le multiplexage des requêtes sur une seule connexion TCP réduit l’impact du handshake initial
- DNS-over-QUIC (DoQ) utilise UDP sur le port 853 mais intègre nativement le chiffrement et le contrôle de congestion. C’est le seul protocole DNS chiffré qui s’affranchit de TCP
Pour les opérateurs qui déploient un résolveur récursif chiffré, le choix entre DoT et DoH dépend surtout de la politique de filtrage réseau. DoH sur le port 443 est plus difficile à bloquer (il se mélange au trafic HTTPS ordinaire), ce qui peut être un avantage ou un inconvénient selon le contexte de sécurité.
IPv4/IPv6 et transport DNS : les implications TCP en double pile
La RFC 10001 recommande que les serveurs DNS autoritaires et les résolveurs récursifs prennent en charge IPv4 et IPv6. En double pile, le comportement de fallback TCP se complexifie.
Un résolveur qui tente d’abord une requête UDP en IPv6, reçoit une réponse tronquée, puis bascule en TCP sur la même adresse IPv6 peut échouer si le chemin TCP IPv6 est filtré alors que le chemin TCP IPv4 ne l’est pas. Les règles de pare-feu doivent autoriser TCP/53 sur les deux familles d’adresses.
Nous observons fréquemment des configurations où IPv6 est activé sur les interfaces réseau mais où les règles de filtrage n’ont été dupliquées que pour IPv4. Le DNS est souvent le premier service à révéler cette asymétrie, parce que la bascule UDP-TCP amplifie les différences de traitement entre les deux piles.
Le diagnostic passe par des tests séparés : une requête dig en TCP forcé sur l’adresse IPv4 du résolveur, puis sur son adresse IPv6. Toute divergence de comportement signale un problème de filtrage à corriger avant qu’il ne provoque des résolutions intermittentes en production.
