View on GitHub

DNS flag day 2020

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

Merci !

Le DNS flag day 2019 a été un événément réussi. 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 meilleur Internet.

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 sera focalisé 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 fois, nous allons nous concentrer sur les problèmes de fragmentation IP des paquets DNS.

La fragmentation IP est un problème sur Internet aujourd’hui, en particulier avec les messages DNS larges. Et même si la fragmentation fonctionne, elle pourrait ne pas être assez sécurisée pour le DNS.

Ces problèmes peuvent être résolus en honorant une taille de tampon EDNS qui ne causera pas de fragmentation et en permettant au DNS de basculer d’UDP à TCP lorsque des tailles de tampon larges ne suffisent pas.

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é

En ce qui concerne le “DNS faisant Autorité”, vous pouvez aider à résoudre ce genre de problèmes en répondant aux requêtes DNS sur TCP (port 53), vérifiez aussi vos pare-feux !

Vous devriez aussi utiliser une taille tampon EDNS qui ne causera pas de fragmentation, la recommandation ici est autour de 1220 octets, mais la valeur définitive est toujours en cours de discussion.

Enfin, 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 vérifier votre domaine en le rentrant 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 (d’environ 1220 octets) qui ne causera pas de fragmentation. N’oubliez pas de vérifier vos pare-feux !

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

NEW! This checker will test your browser, system and ISPs resolver by loading an image on a specific URL that can only be looked up if there is support for TCP at the last resolver querying the authority. For more information go to Check My DNS which this checker uses.

Test your resolver


Action: Fournisseurs de logiciels DNS

En tant que fournisseur de logiciel DNS, il est important de se conformer aux standards et d’utiliser une taille de tampon EDNS par défaut (environ 1220 octets) 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?

Vous pouvez utiliser le testeur de l’ISC indiqué dans la section Action: Opérateurs de serveurs DNS faisant Autorité.

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 fournisseur de service, vous pouvez aussi tester vos serveurs faisant autorité et récursifs en autorisant DNS sur TCP et 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