View on GitHub

DNS flag day 2020

English (US) Le Français 日本語 Español 中文（中国）

Merci !

Le DNS Flag Day 2019 a été un succès. La communauté Internet a travaillé de manière concertée, ce qui a permis de résoudre des problèmes qui causaient des délais pour les utilisateurs d’Internet. Nous souhaitons remercier tous les opérateurs qui ont coopéré et ont contribué à un Internet meilleur.

Un résumé des “Flag Days” passés et à venir est disponible ici: https://youtu.be/mH_elg9EUWw?t=649.

Contenu

Quelle est la suite?

Le prochain DNS Flag Day est actuellement en cours de planification. Il se concentrera sur les problèmes opérationnels et de sécurité dans le DNS, causés par la fragmentation des packets IP (Internet Protocol).

Veuillez vous abonner à la mailing list dns-announce ou suivre @dnsflagday sur Twitter pour recevoir une notification quand davantage d’informations seront disponibles.

DNS Flag Day 2020

La communauté DNS a discuté des problèmes persistants d’interoperabilité et de performance du DNS sur les mailing-lists, ainsi qu’à des conférences telles que DNS-OARC 30 (video, slides).

L’approche proposée pour le DNS Flag Day 2020 a été annoncée lors du RIPE78 par Petr Špaček, de CZ.NIC et Ondřej Surý, de l’ISC (video, slides). Cette année, nous allons nous concentrer sur les problèmes de fragmentation IP des paquets DNS.

La fragmentation IP n’est pas fiable sur Internet aujourd’hui, et peut causer des problèmes de transmission quand de larges messages DNS sont envoyés via UDP. Même quand la fragmentation fonctionne, elle pourrait ne pas être sécurisée; il est en théorie possible d’usurper une partie d’un message DNS fragmenté, sans que cela soit facilement détectable par la partie recevant le message.

Ces problèmes peuvent être résolus en a) configurant les serveurs pour qu’ils limitent les messages envoyés en UDP à une taille qui ne déclenchera pas la fragmentation sur les liens réseaux typiques, et b) en s’assurant que les serveurs DNS puissent basculer d’UDP à TCP quand une réponse DNS est trop grande pour rentrer dans cette taille tampon limitée.

Considérations sur la Taille des Messages

La taille optimale d’un message DNS pour éviter la fragmentation IP, tout en minimisant l’utilisation de TCP, dépendra du MTU (Maximum Transmission Unit) du lien réseau physique qui connecte les deux parties. Malheureusement, il n’y a pas encore de mécanisme standard pour les fournisseurs de serveur DNS permettant d’accéder à cette information. D’ici à ce qu’un tel standard existe, nous recommandons que la taille tampon EDNS soit, par défaut, configurée sur une valeur assez petite pour éviter la fragmentation sur la majorité des liens réseaux utilisés aujourd’hui.

Une taille tompon EDNS de 1232 bits évitera une fragmentation sur presque tous les réseaux actuels. Cette valeur se base sur un MTU de 1280, qui est requis par la spécification IPv6, moins 48 bits pour les entêtes IPv6 et UDP.

Veuillez noter que cette recommandation est pour une valeur par défaut, et est donc à utiliser lorsqu’aucune autre meilleure information n’est disponible. Les opérateurs peuvent toujours configurer des valeurs plus grandes si leurs réseaux supportent des trames de données plus grandes et s’ils sont certains qu’il n’y a pas de risque de fragmentation IP. Les fournisseurs de serveurs DNS peuvent utiliser des tailles de paquet plus grandes (ou plus petites) si de meilleures information à propos du MTO sont rendues disponibles par le kernel.

Note: Travail en cours

Ce site web et certains aspects du DNS flag day 2020 sont toujours en cours de finalisation.

Néanmoins, les prérequis techniques sont déjà suffisament clairs et les opérateurs et développeurs peuvent dores et déjà tester et reconfigurer leurs systèmes.

Si vous avez des commentaires ou des suggestions, merci de rejoindre la discussion sur la mailing-list dns-operations.

Action: Opérateurs de serveurs DNS faisant Autorité

Si vous êtes un opérateur de serveur DNS faisant Autorité, ce que vous pouvez faire pour contribuer est de vous assurer que vos serveurs DNS peuvent répondre aux requêtes DNS sur TCP (port 53). Vérifiez aussi vos pare-feux ! car certains bloquent TCP/53.

Vous devriez aussi configurer vos serveurs pour négocier une taille tampon EDNS qui ne causera pas de fragmentation. La recommandation ici est de 1232 bits.

Les serveurs DNS faisant Autorité NE DOIVENT PAS envoyer de réponses plus grandes que la taille du tampon EDNS demandée.

Vous pouvez maintenant tester vos serveurs en rentrant votre domaine dans le formulaire ci-dessous et en pressant “Test!”. Ce testeur utilise l’EDNS Compliance Tester de l’ISC et vérifiera que son test edns512tcp passe avec succès (entre autres tests).

Testez votre domaine


Action: Opérateurs de serveurs DNS Récursifs

En ce qui concerne le DNS Récursif, on retrouve plus ou moins les mêmes prérequis que pour le DNS faisant Autorité: répondre aux requêtes DNS sur TCP (port 53) et utilisation d’une taille de tampon EDNS de 1232 bits qui ne causera pas de fragmentation. N’oubliez pas de vérifier vos pare-feux pour éviter les problèmes de DNS sur TCP !

Enfin, dernière point important, les résolveurs DOIVENT renvoyer les requêtes via TCP s’ils reçoivent une réponse UDP tronquée (avec le bit TC=1 défini) !

NOUVEAU ! Cet outil de vérification testera votre navigateur, votre système et le résolveur DNS de votre FAI, en chargeant une image à partir d’une URL spécifique qui peut uniquement être résolue si le dernier résolveur DNS qui requête le DNS faisant Autorité supporte TCP. Pour plus d’information, consultez la page Check My DNS qui est utilisée par cet outil.

Test your resolver


Action: Fournisseurs de logiciels DNS

Il est important pour les fournisseurs de logiciel DNS de se conformer aux standards et d’utiliser une taille de tampon EDNS par défaut (1232 bits) qui ne causera pas de fragmentation.

Les standards pertinents sont principalement les RFC 7766, RFC 6891 section 6.2.3. et RFC 6891 section 6.2.4..

La motivation pour ce changement est décrite dans les documents IETF draft intarea-frag-fragile section 6.1 et IETF draft iab-protocol-maintenance.

Comment tester?

Si vous êtes le propriétaire d’un domaine ou l’opérateur d’un serveur DNS faisant Autorité, vous pouvez utiliser notre outil de vérification en ligne pour tester votre domaine; vous pouvez le trouver dans la section Action: Opérateurs de serveurs DNS faisant Autorité.

Notre outil de vérification en ligne pour les clients et les opérateurs de résolveurs DNS se trouve dans la section Action: Opérateurs de serveurs DNS Récursifs.

Vous pouvez également tester en utilisant les lignes de commande suivantes:

$ dig +tcp @auth_IP yourdomain.example.
$ dig +tcp @resolver_IP yourdomain.example.
$ dig @resolver_IP test.knot-resolver.cz. TXT

Toutes les requêtes DNS doivent aboutir et les commandes avec ou sans l’option +tcp doivent retourner la même chose.

Si vous êtes un FAI, vous pouvez tester vos serveurs faisant autorité et récursifs en changeant la configuration pour la taille par défaut du tampon EDNS:

La configuration ci-dessus n’aura aucun impact si tout fonctionne correctement, mais certaines requêtes échoueront si TCP n’est pas disponible.

Précédents flag days

Voici une liste des précédents Flag Days:

Qui est derrière DNS Flag Day?

L’initiative DNS flag day est soutenue par les fournisseurs de logiciels DNS et par les fournisseurs de service, et supportée par DNS Operations, Analysis, and Research Center (DNS-OARC), dont la plupart des acteurs de la communité est membre.

Si vous avez des questions techniques à propos du DNS flag day, vous pouvez souscrire à la mailing-liste DNS-operations et les poser sur cette mailing-liste.

Rentrer en contact

Pour les demandes média et presse, envoyez un email à media (at) dns-oarc.net en indiquant “DNS Flag Day” dans le sujet de l’email.

Supporters

FAQ