Aujourd'hui, plusieurs grands services DNS et fabricants de serveurs DNS organiseront un événement conjoint , destiné à mettre l'accent sur sur la fragmentation IP lors du traitement de messages DNS de grande taille. C'est le deuxième événement de ce type, après le « DNS flag day » de l'année dernière sur le traitement correct des requêtes EDNS.
Les participants de l'initiative DNS flag day 2020 appellent à fixer les tailles de tampon recommandées pour EDNS à des valeurs de 1232 octets (taille MTU de 1280 moins 48 octets pour les en-têtes), ainsi qu'à traiter les requêtes par TCP comme une fonction nécessaire sur les serveurs. Dans il est uniquement stipulé que le support du traitement des requêtes par UDP est obligatoire, tandis que le TCP est mentionné comme souhaitable mais pas obligatoire au fonctionnement. Les nouvelles et classifient clairement le TCP parmi les capacités obligatoires nécessaires pour le bon fonctionnement de DNS. Dans le cadre de cette initiative, il est proposé de forcer le passage de l'envoi de requêtes par UDP à l'utilisation de TCP dans les cas où la taille du tampon EDNS n'est pas suffisante.
Les changements proposés élimineront la confusion liée au choix de la taille du tampon EDNS et résoudront le problème de la fragmentation des grands messages UDP, dont le traitement entraîne souvent une perte de paquets et des délais d'attente du côté du client. Du côté client, la taille du tampon EDNS sera constante, et les grandes réponses seront immédiatement envoyées au client par TCP. L'exception de l'envoi de grands messages par UDP résoudra également les problèmes de rejet de gros paquets sur certains pare-feux et permettra de bloquer les attaques par empoisonnement du cache DNS, basées sur la manipulation de paquets UDP fragmentés (dans la fragmentation, le deuxième fragment n'inclut pas l'en-tête avec l'identifiant, ce qui permet de falsifier suffisament pour que la somme de contrôle soit valide).
À partir d'aujourd'hui, les fournisseurs DNS participant à l'initiative, dont CloudFlare, Quad 9, Cisco (OpenDNS) et Google, la taille du tampon EDNS de 4096 à 1232 octets sur leurs serveurs DNS (le changement EDNS sera étalé sur 4 à 6 semaines et finira par couvrir de plus en plus de requêtes). Les réponses aux requêtes UDP ne respectant pas la nouvelle limite seront envoyées par TCP. Les fabricants de serveurs DNS, y compris BIND, Unbound, Knot, NSD et PowerDNS publieront des mises à jour ajustant la taille du tampon EDNS par défaut de 4096 à 1232 octets.
En fin de compte, les modifications apportées peuvent entraîner des problèmes de résolution lors de l'accès aux serveurs DNS, dont les réponses DNS par UDP dépassent 1232 octets et qui ne peuvent pas envoyer de réponse par TCP. Une expérience menée par Google a montré que le changement de la taille du tampon EDNS n'influera pratiquement pas sur le niveau des échecs : avec un tampon de 4096 octets, le nombre de requêtes UDP tronquées est de 0,345 %, tandis que le nombre de réponses TCP non accessibles est de 0,115 %. Avec un tampon de 1232 octets, ces chiffres sont respectivement de 0,367 % et 0,116 %. Rendre le support de TCP obligatoire pour les fonctionnalités DNS entraînera des problèmes d'interaction avec environ 0,1 % des serveurs DNS. Il est constaté qu'en conditions modernes, même sans TCP, le fonctionnement de ces serveurs reste instable.
Les administrateurs des serveurs DNS autoritatifs doivent s'assurer que leur serveur répond par TCP sur le port réseau 53 et que ce port TCP n'est pas bloqué par un pare-feu. Le serveur DNS autoritatif ne doit pas non plus envoyer de réponses UDP dont la taille dépasse
la taille du tampon EDNS demandée. Sur le serveur lui-même, la taille du tampon EDNS doit être fixée à 1232 octets. Les résolveurs sont soumis à des exigences à peu près similaires : possibilité obligatoire de répondre par TCP, support obligatoire de l'envoi de requêtes répétées par TCP en cas de réponse UDP tronquée et définition du tampon EDNS à 1232 octets.
La configuration de la taille du tampon EDNS sur différents serveurs DNS est assurée par les paramètres suivants :
options {
edns-udp-size 1232;
max-udp-size 1232;
};
max-udp-payload: 1232
net.bufsize(1232)
udp-truncation-threshold=1232
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232
edns-buffer-size: 1232
ipv4-edns-size: 1232
ipv6-edns-size: 1232
Source : opennet.ru
