Skip to main content

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

L'Organisation de l'ICANN annonce aujourd'hui qu'elle ne procédera pas au roulement de la KSK de la zone racine lors du premier trimestre 2018.

Nous avons décidé que nous ne disposions pas d'informations suffisantes afin de fixer une date précise pour le roulement. Toutefois, nous tenons à préciser que l'Organisation de l'ICANN s'engage à procéder au roulement de la KSK de la zone racine et nous poursuivrons nos discussions avec la communauté sur cet important processus, nous rassemblerons ses retours et nous préviendrons toutes les parties intéressées de la date fixée pour le roulement au moins un trimestre civil à l'avance.

De plus, nous souhaitons avoir l'avis de la communauté afin d'aider à déterminer, si possible, des critères objectifs adéquats permettant de mesurer l'éventuel impact négatif du roulement de la KSK de la zone racine sur les internautes, et des valeurs acceptables pour ces critères avant un roulement. Le tout conformément au modèle ascendant multipartite qui a largement contribué à l'élaboration de politiques de l'ICANN.

Le 27 septembre 2017, l'Organisation de l'ICANN a annoncé qu'elle repoussait le roulement de la KSK de la zone racine d'au moins un trimestre, tout en laissant la possibilité de procéder au roulement de la KSK de la zone racine au cours du premier trimestre 2018. Depuis, nous nous sommes rendu compte que notre analyse et notre préparation nécessiteront davantage de temps.

Dans une publication précédente, nous avons décrit notre analyse des informations de configuration de l'ancre de confiance d'un résolveur récursif à l'aide d'un protocole défini dans le RFC 8145Signalisation des connaissances de l'ancre de confiance dans les extensions de sécurité du système des noms de domaine (DNSSEC). Notre analyse a révélé qu'environ 4 % des quelque 12 000 résolveurs de validation des DNSSEC interrogés en septembre 2017 étaient uniquement configurés avec la KSK-2010 (l'abréviation pour la KSK de la zone racine actuelle) et auraient été incapables de résoudre des requêtes du DNS après le roulement.

La décision de l'Organisation de l'ICANN de repousser le roulement est fondée sur le fait que nous n'avions pas compris pourquoi ces résolveurs n'ont pas été correctement configurés et que nous avions besoin de plus de temps pour mener des recherches.

Depuis lors, nous avons tâché de contacter les opérateurs de 500 adresses qui avaient fait part d'une configuration de résolveur uniquement avec la KSK-2010 et non d'une configuration correcte avec la KSK-2010 et la nouvelle KSK, la KSK-2017. Nous espérions que ces recherches révéleraient un ensemble clair de causes expliquant le défaut de configuration, qui aurait permis d'adopter des communications et des actions ciblées susceptibles de répondre à ces problèmes spécifiques. Mais en fin de compte, l'analyse n'a pas été aussi concluante que nous l'espérions.

Au début de nos recherches, nous avons reçu des réponses des opérateurs d'environ 20 % des 500 adresses. Parmi les opérateurs de ces adresses que nous avons contactés, 60 % étaient des groupes d'adresses connus pour héberger des dispositifs dotés d'adresses dynamiques tels que des routeurs d'utilisateurs de haut débit à domicile et des machines virtuelles éphémères, ce qui rend ces résolveurs extrêmement difficiles (voire impossible) à localiser. Environ 25 % des adresses correspondaient à un résolveur transmettant pour le compte d'un autre résolveur ayant déclaré utilisé uniquement la KSK-2010. Dans la mesure où l'adresse du dispositif faisant part d'une mauvaise configuration n'était pas le véritable résolveur source, il est extrêmement difficile (voire impossible) d'identifier la véritable adresse source du résolveur ayant déclaré utiliser uniquement la KSK-2010.

Afin de procéder au roulement de la KSK de la zone racine, l'Organisation de l'ICANN doit avoir la certitude que le roulement n'aura pas un impact négatif inacceptable sur les internautes. Le problème auquel nous avons été confronté depuis que nous avons commencé à analyser les rapports de configuration de l'ancre de confiance des résolveurs découlant du RFC 8145 concerne l'évaluation de l'impact sur les utilisateurs.

Nous pouvons formuler un certain nombre d'hypothèses. Par exemple, il est peu probable qu'un résolveur récursif gérant une adresse dynamique puisse prendre en charge un grand nombre d'utilisateurs étant donné qu'il ne propose pas d'adresse stable permettant d'envoyer des requêtes à des dispositifs à des fins de résolution. Enfin, déterminer l'éventuel impact sur les utilisateurs sur la base des données mises à notre disposition est difficile et nous souhaitons donc obtenir des retours de la communauté.

Les consultations et discussions sur les critères acceptables pour le roulement de la KSK se tiendront via une liste de diffusion existante déjà utilisée afin de discuter du roulement de la KSK de la zone racine. Nous encourageons quiconque souhaiterait apporter sa contribution à rejoindre la liste de diffusion en se rendant sur la page web ici.

L'Organisation de l'ICANN assurera un suivi de cette liste de diffusion et, à compter du 15 janvier 2018, nous élaborerons un projet de plan pour le roulement de la KSK de la zone racine sur la base des retours reçus et des échanges de la liste de diffusion. Le plan sera publié au plus tard le 31 janvier 2018 et sera soumis à un processus de consultation publique formel de l'ICANN qui permettra de recueillir de nouveaux commentaires. Nous organiserons une séance lors de l'ICANN61 à San Juan, Porto Rico, afin de débattre du plan et de permettre à la communauté de s'exprimer directement. Notre objectif est de disposer d'un plan révisé pouvant être soumis à un examen communautaire et à une consultation publique avant l'ICANN62 à Panama City, Panama, et de publier peu de temps après un plan final.

Tout au long du processus, nous continuerons à maintenir la communauté informée de l'avancée du projet de roulement de la KSK de la zone racine.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."