À première vue, le DNS semble être un service simple : on saisit un nom de domaine, et Internet retrouve l’adresse IP correspondante. En réalité, ce mécanisme repose sur des choix techniques précis. L’un des plus importants tient à l’usage de deux protocoles de transport, UDP et TCP. Ce duo n’est pas un héritage arbitraire : il répond à des besoins de rapidité, de fiabilité et d’évolution du réseau.
Le DNS, pour Domain Name System, est souvent décrit comme l’annuaire d’Internet. Il traduit des noms lisibles, comme exemple.fr, en adresses IP exploitables par les machines. Sans lui, l’usage quotidien du web, de la messagerie ou de nombreux services en ligne serait bien moins pratique.
Pour fonctionner, le DNS doit échanger des requêtes et des réponses entre plusieurs acteurs : l’ordinateur de l’utilisateur, le résolveur DNS, les serveurs racine, les serveurs de domaine de premier niveau et les serveurs faisant autorité. Ces échanges passent généralement par le port 53, mais ils peuvent emprunter deux protocoles de transport distincts : UDP et TCP.
La règle générale est simple : UDP est utilisé pour la majorité des requêtes DNS courantes, tandis que TCP intervient lorsque la situation exige plus de fiabilité, plus de capacité ou un échange plus structuré. Cette répartition explique pourquoi le DNS est à la fois rapide dans les usages ordinaires et robuste dans les cas plus complexes.
UDP, pour User Datagram Protocol, est un protocole léger. Il n’établit pas de connexion préalable entre le client et le serveur. Le message est envoyé directement, et la réponse revient si tout se passe bien. Cette simplicité réduit le délai de traitement, ce qui convient parfaitement au DNS, où une requête typique ne contient que quelques dizaines d’octets.
Dans la navigation web, chaque milliseconde compte. Avant même de charger une page, le navigateur doit souvent résoudre plusieurs noms de domaine : celui du site principal, mais aussi ceux liés aux images, aux polices, aux scripts ou aux services tiers. Utiliser UDP permet de limiter le coût de ces résolutions. Le système envoie une requête, reçoit une réponse, puis passe à l’étape suivante.
UDP est aussi efficace côté serveur. Les résolveurs DNS publics ou ceux des fournisseurs d’accès traitent des volumes considérables de requêtes. Un protocole sans établissement de connexion consomme moins de ressources. C’est l’une des raisons pour lesquelles UDP reste le mode de transport dominant du DNS classique.
TCP, pour Transmission Control Protocol, fonctionne différemment. Avant d’échanger des données, les deux machines établissent une connexion. Ce processus ajoute un léger délai, mais il offre des garanties importantes : les paquets sont ordonnés, retransmis en cas de perte et contrôlés pendant l’échange.
Cette logique est utile lorsque la réponse DNS est trop volumineuse, lorsqu’un échange ne doit pas être perdu ou lorsqu’un serveur doit transférer des données complètes à un autre serveur. TCP n’est donc pas un plan de secours improvisé, mais une composante prévue du fonctionnement du DNS. Les standards modernes recommandent d’ailleurs aux serveurs DNS de prendre correctement en charge TCP.
Le coût supplémentaire de TCP vient notamment de l’établissement de connexion, souvent résumé par le handshake en trois étapes. Une explication détaillée du mécanisme d’ouverture d’une connexion TCP permet de mieux comprendre pourquoi UDP reste préféré pour les requêtes très courtes, mais pourquoi TCP devient précieux dès que la fiabilité prime.
À l’origine, les réponses DNS sur UDP étaient limitées à 512 octets. Cette contrainte correspondait à un Internet plus simple, où les enregistrements étaient généralement courts. Mais les usages ont évolué. Les réponses DNS peuvent désormais contenir davantage d’informations, notamment avec IPv6, DNSSEC, les enregistrements de messagerie ou certaines configurations de sécurité.
Lorsque la réponse dépasse la taille acceptable pour UDP, le serveur peut indiquer que le message est tronqué. Le client relance alors la requête en TCP afin d’obtenir la réponse complète. Ce comportement est essentiel : sans lui, certaines informations seraient incomplètes, ce qui provoquerait des échecs de résolution ou des erreurs difficiles à diagnostiquer.
L’extension EDNS(0) a permis d’augmenter la taille des messages DNS transportés en UDP. En pratique, cela a réduit le recours automatique à TCP pour de nombreuses réponses plus grandes que les anciens 512 octets. Mais UDP reste exposé à la fragmentation IP, un phénomène qui peut poser des problèmes de filtrage, de perte de paquets ou de sécurité. Dans ces cas, TCP offre un chemin plus fiable.
Le DNS ne sert pas seulement à répondre aux utilisateurs finaux. Il permet aussi aux serveurs DNS de se synchroniser entre eux. Lorsqu’un serveur secondaire récupère les données d’une zone depuis un serveur primaire, on parle de transfert de zone. Ces opérations, appelées AXFR pour un transfert complet et IXFR pour un transfert incrémental, utilisent TCP.
La raison est facile à comprendre : une zone DNS peut contenir des dizaines, des centaines ou des milliers d’enregistrements. Il ne s’agit plus d’une simple question-réponse, mais d’un échange potentiellement long, qui doit être complet et cohérent. TCP garantit que les données arrivent dans le bon ordre et qu’elles peuvent être retransmises si nécessaire.
Ce point est particulièrement important pour les organisations qui gèrent plusieurs serveurs faisant autorité. Une erreur dans une zone DNS peut affecter un site web, des services internes ou la messagerie. Par exemple, les politiques d’authentification des e-mails reposent sur des enregistrements publiés dans le DNS, comme l’explique ce guide sur le rôle d’un enregistrement DMARC dans le DNS.
DNSSEC a introduit des signatures cryptographiques destinées à vérifier l’authenticité des réponses DNS. Cette amélioration de sécurité augmente mécaniquement la taille des réponses, car les enregistrements doivent transporter des informations supplémentaires. Dans certains cas, UDP suffit encore grâce à EDNS(0). Dans d’autres, TCP devient nécessaire.
Les évolutions récentes vont plus loin. Le DNS peut aujourd’hui être transporté dans des canaux chiffrés, notamment avec DNS over TLS et DNS over HTTPS. DNS over TLS utilise TCP, généralement sur le port 853, afin de protéger les requêtes contre l’observation ou la modification sur le réseau. DNS over HTTPS s’appuie sur HTTPS, qui a longtemps reposé sur TCP, même si HTTP/3 introduit aussi QUIC au-dessus d’UDP.
Ces mécanismes s’inscrivent dans une tendance plus large : sécuriser davantage les couches de communication. La manière dont TLS identifie les services hébergés sur une même adresse IP est liée à des notions comme l’extension SNI dans le protocole TLS, tandis que la protection des échanges web s’appuie aussi sur des politiques comme l’en-tête HTTP HSTS. Le DNS n’est donc plus isolé : il fait partie d’un écosystème de sécurité plus vaste.
Dans un environnement idéal, une requête DNS en UDP part, la réponse revient, et l’utilisateur ne remarque rien. Mais les réseaux réels sont plus complexes. Pare-feu, routeurs, systèmes de filtrage, tunnels VPN et équipements d’entreprise peuvent influencer le transport des paquets. Certains bloquent les fragments UDP, d’autres limitent les tailles de messages ou appliquent des règles strictes au port 53.
Lorsqu’une réponse UDP se perd, le client peut tenter à nouveau sa requête. Si le serveur signale une troncature, il doit basculer vers TCP. Cette capacité de repli contribue à la résilience du DNS. Elle explique aussi pourquoi un diagnostic DNS sérieux ne se limite pas à vérifier si un nom répond, mais cherche à savoir comment il répond, avec quelle taille de paquet et par quel protocole.
Les outils réseau comme ping ou traceroute ne testent pas directement le DNS, mais ils aident à comprendre le chemin emprunté par les paquets. Leur fonctionnement repose notamment sur ICMP, un protocole utile pour diagnostiquer les erreurs et la connectivité, comme le montre cette présentation de l’importance d’ICMP dans Internet.
Le DNS utilise UDP parce que la majorité de ses échanges sont courts, fréquents et sensibles à la latence. Pour résoudre rapidement un nom de domaine, UDP offre un excellent compromis : peu de surcharge, pas de connexion préalable et une efficacité adaptée aux volumes massifs de requêtes.
Le DNS utilise aussi TCP parce que certaines situations exigent davantage de garanties. Les réponses volumineuses, les transferts de zone, DNSSEC et les transports chiffrés rendent TCP indispensable. Il apporte la fiabilité nécessaire lorsque les limites d’UDP deviennent visibles.
La coexistence de ces deux protocoles illustre bien la philosophie d’Internet : privilégier la simplicité quand elle suffit, mais prévoir des mécanismes robustes lorsque le contexte l’impose. Le protocole DNS n’a donc pas choisi entre UDP et TCP. Il utilise chacun là où il est le plus pertinent, ce qui contribue à la rapidité, à la stabilité et à l’évolutivité du réseau mondial.
