1. Introduction (Introduction)
La plupart des transactions DNS [RFC1034] ont lieu sur UDP [RFC768]. TCP [RFC793] est toujours utilisé pour les transferts de zone complets (utilisant AXFR) et est souvent utilisé pour les messages dont la taille dépasse la limite originale de 512 octets du protocole DNS. Le déploiement croissant de la sécurité DNS (DNSSEC) et d'IPv6 a augmenté la taille des réponses et donc l'utilisation de TCP. La nécessité d'une utilisation accrue de TCP a également été motivée par la protection qu'il offre contre l'usurpation d'adresse et donc l'exploitation du DNS dans les attaques par réflexion/amplification. Il est maintenant largement utilisé dans la limitation du taux de réponse (Response Rate Limiting) [RRL1] [RRL2]. De plus, les travaux récents sur les solutions de confidentialité DNS telles que [DNS-over-TLS] sont une autre motivation pour revoir les exigences DNS-over-TCP.
La section 6.1.3.2 de la [RFC1123] stipule :
Les résolveurs DNS et les serveurs récursifs DOIVENT (MUST) prendre en charge UDP, et DEVRAIENT (SHOULD) prendre en charge TCP, pour l'envoi de requêtes (hors transfert de zone).
Cependant, certains implémenteurs ont interprété le texte cité ci-dessus comme signifiant que la prise en charge de TCP est une fonctionnalité optionnelle du protocole DNS.
La majorité des opérateurs de serveurs DNS prennent déjà en charge TCP, et la configuration par défaut de la plupart des implémentations logicielles est de prendre en charge TCP. Le public principal de ce document est constitué de ces implémenteurs dont la prise en charge limitée de TCP restreint l'interopérabilité et entrave le déploiement de nouvelles fonctionnalités DNS.
Ce document met donc à jour les spécifications du protocole DNS de base de telle sorte que la prise en charge de TCP est désormais une partie REQUISE (REQUIRED) d'une implémentation complète du protocole DNS.
Il existe plusieurs avantages et inconvénients à l'utilisation accrue de TCP (voir l'annexe A) ainsi que des détails d'implémentation qui doivent être pris en compte. Ce document aborde ces questions et présente TCP comme une alternative de transport valide pour le DNS. Il étend le contenu de la [RFC5966], avec des considérations supplémentaires et des leçons tirées de la recherche, des développements et de l'implémentation de TCP dans le DNS et dans d'autres protocoles Internet.
Bien que ce document n'impose aucune exigence spécifique aux opérateurs de serveurs DNS, il offre quelques suggestions aux opérateurs pour aider à garantir que la prise en charge de TCP sur leurs serveurs et leur réseau est optimale. Il convient de noter que le fait de ne pas prendre en charge TCP (ou le blocage du DNS sur TCP au niveau de la couche réseau) entraînera probablement un échec de la résolution et/ou des délais d'attente au niveau de l'application.