Blogs de l’ICANN

Lisez les blogs de l’ICANN pour vous tenir au courant des dernières activités d’élaboration de politiques, des événements régionaux et bien plus encore.

Mise à jour sur le projet de roulement de la KSK de la zone racine

26 octobre 2017
Par

En plus des six langues des Nations Unies, ce contenu est aussi disponible en

Cet article est le premier d'une série de mises à jour sur l'avancée du projet de roulement de la KSK de la zone racine. Nous souhaitons tenir la communauté informée de nos activités relatives au roulement.

Le 27 septembre 2017, l'organisation de l'ICANN a annoncé le report du roulement de la KSK de la zone racine. Plus récemment, le 17 octobre, nous avons publié un rapport intitulé Report du roulement de la KSK de la zone racine [PDF, 173 KB] précisant davantage les informations reçues sur la configuration de certains résolveurs qui ont influencé notre analyse, notre raisonnement et la décision dudit report.

Comme le décrit ce rapport [PDF, 173 KB], les versions les plus récentes des résolveurs récursifs BIND et Unbound ont mis en œuvre un protocole défini dans le RFC 8145 [TXT, 27 KB], Signalisation des connaissances de l'ancre de confiance dans le DNSSEC, qui permet à un résolveur de communiquer la configuration de ses ancres de confiance. Un résolveur présentant cette fonctionnalité communique ses ancres de confiance configurées pour la zone racine aux serveurs de noms racine. L'analyse des données d'ancre de confiance communiquées, effectuée dans les semaines précédant la date de roulement initialement prévue (le 11 octobre 2017), a fait craindre qu'il y ait un nombre plus important que prévu de résolveurs non configurés avec la KSK-2017 (notre abréviation pour la prochaine KSK de la zone racine) en tant qu'ancre de confiance. Ces résolveurs ne seront pas en mesure de résoudre les requêtes du DNS lorsque le roulement aura lieu.

Le groupe de recherche du bureau du directeur de la technologie (OCTO) a analysé le trafic des serveurs racine B, D, F et L pour la totalité du mois de septembre 2017 et a trouvé 11 982 adresses IP uniques (8 908 IPv4 et 3 078 IPv6) envoyant des informations relatives à la configuration de l'ancre de confiance. Parmi ces adresses, 620 ont déclaré être configurées uniquement avec la KSK-2010 (l'abréviation pour la KSK de la zone racine actuelle). Après une analyse plus poussée, nous avons pu éliminer certains faux positifs : des adresses IP qui, pour certaines raisons, ne représentaient pas des résolveurs récursifs effectuant une validation DNSSEC. Nous avons réduit la liste à 500 adresses d'éventuels résolveurs récursifs mal configurés dont nous souhaiterions contacter les opérateurs. Nous souhaitons les contacter pour deux principales raisons : afin de comprendre pourquoi leur résolveur déclare être configuré uniquement avec la KSK-2010 et, le cas échéant, afin de les aider à corriger la configuration de sorte à être prêt pour le roulement.

Nous avions initialement prévu de rendre publique cette liste d'adresses afin de solliciter l'aide de la communauté. Après mûre réflexion, nous nous sommes rendu compte qu'une telle liste pourrait être, sortie de son contexte, perçue comme une manière de dénoncer et montrer du doigt les opérateurs dont les systèmes sont mal configurés, ce que nous souhaitons éviter à tout prix. Nous avons décidé de tenter dans un premier temps de contacter directement les administrateurs. En fonction des résultats, nous pourrions être dans l'obligation de publier la liste d'adresses dont nous n'avons pas pu joindre les administrateurs.

Selon les données de septembre susmentionnées, 4,1 % des adresses IP ont déclaré n'avoir que la KSK-2010. (Le pourcentage réel de l'ensemble des résolveurs d'Internet ayant uniquement la KSK-2010 pourrait être supérieur étant donné que seul un faible nombre a indiqué avoir procédé à une configuration d'ancre de confiance.) Via notre enquête et tentative d'atténuation, nous souhaiterions que ce chiffre augmente considérablement. Comme nous ne savons pas combien d'administrateurs nous allons pouvoir contacter, nous ne souhaitons pas, pour l'instant, fixer un objectif chiffré.

Il convient de noter que le chiffre représente un pourcentage de résolveurs et non pas d'utilisateurs finaux, et que c'est l'impact sur les utilisateurs finaux qui importe le plus. Le critère du plan opérationnel publié [PDF, 741 KB] permettant d'envisager de renoncer au roulement en cas de problèmes prend en compte l'impact sur les utilisateurs finaux :

L'ICANN envisagera de suspendre toute activité liée au processus de roulement de clé si le programme d'évaluation révèle qu'une part importante du nombre estimé d'internautes a été touchée par un changement 72 heures après sa mise en œuvre dans la zone racine.

Ce critère découle des recommandations formulées par l'équipe de conception du roulement de la KSK de la zone racine formée par l'ICANN afin de faciliter la planification du roulement, dont le rapport [PDF, 1.2 MB] prévoit la recommandation suivante qui cible également les utilisateurs finaux :

Recommandation 16 : Suspendre toute activité liée au processus de roulement de clé si le programme d'évaluation révèle qu'au moins 0,5 % du nombre estimé d'internautes a été touché par un changement 72 heures après sa mise en œuvre dans la zone racine.

Dans ce processus, nous prendrons davantage en compte l'impact sur les utilisateurs finaux que le pourcentage de résolveurs utilisant encore uniquement la KSK-2010. Après avoir pris contact avec autant d'opérateurs de résolveurs que possible, nous tâcherons de déterminer le nombre d'utilisateurs finaux affectés par les derniers résolveurs qui ne sont pas encore passés à la KSK-2017. Il n'est pas évident de déterminer le nombre d'utilisateurs finaux faisant appel à un résolveur donné mais nous avons différentes idées et sources de données qui nous aideront à mener à bien notre mission.

Dans notre démarche constante de compte rendu à l'égard de la communauté, nous vous informerons davantage sur ces initiatives et autres projets lors de prochains articles de blog.

Authors

Matt Larson

Matt Larson

VP, Research