Résumé

  • TCP est une voie normale du service DNS, pas seulement un outil de transfert de zone.
  • EDNS élargit l’enveloppe UDP utilisable sans garantir la livraison sur chaque chemin.
  • La preuve de disponibilité doit suivre une requête de la troncature jusqu’à la réponse TCP et à la réutilisation sûre de la connexion.

L’incident révélateur commence par un tableau de bord au vert. UDP/53 répond vite et les données faisant autorité sont à jour. Une réponse plus volumineuse revient avec TC. Le résolveur ouvre TCP, mais le site dispose d’une file d’acceptation trop courte, d’un délai de pare-feu inadapté ou de processus bloqués derrière un client lent. Les données DNS sont justes ; leur chemin de livraison ne l’est pas.

La RFC 1035 définit UDP et TCP sur le port 53, ainsi que le préfixe de longueur de deux octets pour TCP. Elle demande aussi qu’un serveur ne bloque pas ses autres travaux en attendant des données TCP. EDNS a depuis déplacé la limite UDP initiale, sans supprimer le changement de travail provoqué par une réponse tronquée.

La RFC 6891 permet au demandeur d’annoncer la taille maximale de charge utile UDP qu’il peut réassembler et remettre au DNS. Cette valeur décrit une capacité locale ; elle ne promet rien sur chaque chemin intermédiaire. Un test de laboratoire sans TC ne retire donc pas TCP du contrat de production.

La RFC 7766 impose TCP aux implémentations DNS généralistes et traite la réutilisation comme un moyen d’éviter un établissement par requête. Il faut alors mesurer l’achèvement concurrent, les blocages et les fermetures, et non la seule ouverture du port. La RFC 9210 précise cette frontière opérationnelle : une socket ouverte une fois ne prouve pas un cycle de vie maîtrisé sous charge réelle.