Résumé

  • Le bit TC signale que le canal n’a pas pu transporter tout le message. RFC 2181 précisa qu’il concerne un RRset requis qui ne tient pas en entier ; le client doit ignorer la réponse tronquée et non transformer les enregistrements visibles en ensemble complet.
  • TCP fournit un chemin plus vaste, puis devint un transport DNS ordinaire : RFC 7766 exigea le support d’UDP et de TCP et autorisa TCP d’emblée, tandis que RFC 9210 attribua clairement la capacité, le filtrage et l’observation aux opérateurs.

Une enveloppe rapide avait une limite franche

En novembre 1987, RFC 1035 décrivit le DNS sur le port 53, par UDP comme par TCP. UDP convenait aux questions ordinaires : aucun établissement de connexion et peu d’état à conserver. Le format imposait cependant une limite de 512 octets aux messages UDP, hors en-têtes IP et UDP.

Une réponse plus longue devait être tronquée et porter TC=1. Ce bit ne disait ni « nom absent », ni « trois adresses seulement », ni « réponse douteuse ». Il attestait que la longueur permise par le canal avait été dépassée.

Sans cet aveu, la pénurie de place aurait acquis un pouvoir qu’elle ne devait pas avoir. Les enregistrements tombés hors du datagramme auraient pu paraître inexistants. Le transport aurait ainsi réécrit, par accident, le contenu du DNS.

La vérité se groupait en RRset

RFC 2181 donna en 1997 une règle plus fine. Les enregistrements ayant même propriétaire, même classe et même type forment un RRset. Pour une requête visant ces données, l’ensemble entier constitue l’unité de réponse.

TC ne doit être levé que si un RRset nécessaire ne peut être inclus intégralement. Si seule une information complémentaire manque de place, le serveur peut omettre tout le RRset auxiliaire et conserver TC à zéro. Le demandeur formulera une autre question s’il en a besoin.

Avec TC à un, la réponse change de statut. Le client doit l’ignorer et recommencer par un mécanisme autorisant une réponse plus grande, par exemple TCP. Un RRset partiel peut subsister matériellement dans le paquet ; il n’est pas pour autant une preuve exploitable.

La règle interdit deux raccourcis : choisir les valeurs qui semblent utiles et compléter le reste avec un cache ancien. Ce qui est incomplet ne devient pas vrai parce que ses premiers octets sont plausibles.

Le signal ne gouvernait pas le choix suivant

Le serveur expose une insuffisance du transport courant. Le résolveur garde la décision : réinterroger le même serveur sur TCP, en essayer un autre, réutiliser une connexion ou appliquer une politique locale.

TCP peut porter un message dépassant un datagramme et encadre chaque message DNS par une longueur de deux octets. En échange, il consomme un établissement de connexion, de la mémoire, des entrées d’état et du temps d’inactivité. Ces coûts ne donnent aucun droit sur les données. Ils appartiennent aux nœuds qui ouvrent et servent la connexion.

Cette répartition est sobre. Le canal bon marché peut reconnaître sa limite ; le consommateur de l’information doit chercher la version complète. L’intermédiaire n’a jamais reçu le mandat de deviner ce qui manquait.

EDNS annonça un budget, pas une livraison

Avec RFC 6891, le demandeur put annoncer la taille de charge UDP qu’il acceptait. EDNS(0) permit donc à de nombreuses réponses de dépasser l’ancien plafond sans quitter UDP.

Mais une taille annoncée au serveur ne certifie ni le MTU de chaque lien, ni le comportement des tunnels, pare-feu et équipements intermédiaires. Les fragments IP peuvent disparaître ou être filtrés. DNSSEC ajouta signatures et preuves ; IPv6 et des types de données plus riches augmentèrent encore la pression sur la taille.

EDNS et TC ne sont donc pas concurrents. Le premier offre une capacité ; le second constate que la réponse requise ne tient pas dans la capacité réellement utilisable. Un grand nombre dans une requête n’est pas un reçu de bout en bout.

TCP sortit du rôle de porte de secours

La formule « UDP pour les requêtes, TCP pour les transferts de zone et les réponses trop grandes » devint une mauvaise habitude opérationnelle. Certains réseaux laissèrent TC annoncer un recours tout en bloquant TCP/53.

RFC 7766 corrigea cette asymétrie en 2016. Toute mise en œuvre DNS d’usage général doit prendre en charge UDP et TCP : serveurs faisant autorité, récursifs, relais et résolveurs locaux. Le texte relâcha aussi l’ancienne obligation de commencer par UDP. Un résolveur peut choisir TCP pour une raison locale et doit réutiliser une connexion déjà ouverte.

Ainsi, TC mène souvent à TCP sans définir à lui seul toute la politique de transport. TCP est une option normale, et des transports DNS ultérieurs élargissent encore le choix. La règle durable porte sur l’intégrité de la réponse, non sur un rituel immuable en deux paquets.

Une connexion fiable exigeait une économie d’état

Ouvrir une connexion pour une seule question répète le coût de l’aller-retour. RFC 7766 recommande la réutilisation et le pipeline : plusieurs requêtes peuvent partir sans attendre chaque réponse, le serveur les traite en parallèle et peut répondre dans un ordre différent.

Le client doit alors associer explicitement chaque réponse à sa requête. Le serveur et les outils de capture doivent reconstituer le flux ; un segment TCP n’est pas nécessairement un message DNS complet.

Les limites restent légitimes. Clients et serveurs réduisent les connexions concurrentes, fixent des seuils d’admission et ferment les sessions inactives. Un délai doit protéger les ressources sans récompenser une arrivée volontairement lente de fragments de flux.

L’exploitation dut observer les deux transports

RFC 9210 transforma le support en devoir d’exploitation. Résolveurs et serveurs doivent servir UDP et TCP ; les opérateurs réseau doivent généralement autoriser les deux. Interdire TCP détruit une partie attendue du DNS.

Le serveur conserve le droit de limiter les ressources, mais pas de refuser une requête au seul motif qu’un autre transport aurait pu suffire. Le pouvoir porte sur le coût mesurable, pas sur la valeur de la réponse.

La supervision doit également reconstituer les flux, suivre la réutilisation, le pipeline et les réponses hors ordre. Ignorer TCP parce qu’il serait « rare » rend invisibles aussi bien la récupération normale que certaines attaques.

La fragmentation rendit l’aveu encore plus utile

RFC 9715 recommande en 2025 d’éviter la fragmentation IP pour DNS sur UDP et propose 1400 octets comme maximum recommandé lorsqu’aucune contrainte plus faible ne s’applique. La fragmentation fragilise la livraison et ouvre des risques de pollution de cache.

Le texte ne change pas la causalité de TC. Un répondant qui constate une taille excessive peut produire une réponse adaptée ou tronquée ; un demandeur qui perd des fragments doit finir par essayer un autre transport.

TCP peut, lui aussi, échouer. Le port peut être filtré, le service saturé, le chemin cassé. La promesse du mécanisme est plus modeste et plus solide : si l’évidence n’est pas complète, le protocole le dit et conserve une voie pour la redemander.

Ce que TC ne certifia jamais

TC ne prouve ni une erreur DNSSEC, ni la censure, ni l’inexistence d’un nom, ni une attaque. L’omission de données additionnelles non requises ne suffit pas toujours à le déclencher. Et le bit n’ordonne pas exclusivement TCP parmi tous les transports apparus depuis.

Sa portée étroite fait sa force : ce message n’a pas livré tout ce qui était requis sur ce canal. Le DNS pouvait tolérer une première enveloppe trop petite ; il refusait qu’elle mente sur ce qu’elle avait perdu.

Sources et limites

Le bit et la limite initiale viennent de RFC 1035, l’intégrité des RRsets de RFC 2181, l’offre EDNS de RFC 6891, les responsabilités TCP de RFC 7766 et RFC 9210, et l’évitement de fragmentation de RFC 9715. Ces normes ne mesurent ni le taux mondial de TC, ni le filtrage actuel, ni les réglages par défaut des produits.