Skip to main content

L’histoire derrière la décision de l’ICANN de retarder le roulement KSK

La plupart d'entre vous sont maintenant conscients du fait que l'ICANN a annoncé la décision de retarder la modification de la clé cryptographique qui permet de protéger le système des noms de domaine (DNS). Cette modification ou « roulement » était initialement prévue pour le 11 octobre.

J'aimerais vous fournir quelques détails supplémentaires à propos de notre décision de retarder le roulement. Vous pouvez considérer que c'est l'histoire derrière l'histoire.

Il n'y a eu historiquement aucune possibilité de déterminer quelles ancres de confiance ont été configurées par les validateurs d'extensions de sécurité du DNS (DNSSEC), rendant difficile l'évaluation de l'impact potentiel du roulement KSK de la zone racine. Mais cela a récemment changé et nous avons reçu de nouvelles données que nous ne pouvions tout simplement pas ignorer.

« Signaler la connaissance de l'ancre de confiance dans les extensions de sécurité DNS (DNSSEC) » (définie dans le RFC 8145) est une extension de protocole récente qui permet à un validateur de signaler aux serveurs du nom d'une zone les ancres de confiance qu'il a configurées dans cette zone.

Le protocole a seulement été finalisé en avril 2017, bien qu'il ne soit uniquement pris en charge que par les versions les plus récentes de certains logiciels de programme de résolution largement utilisés (BIND 9.10.5b1 et 9.11.0b3 ou ultérieur et Unbound 1.6.4 et ultérieur). Initialement, ce protocole ne devait pas être suffisamment déployé pour fournir des informations utiles pour le premier roulement KSK de la racine.

Toutefois, certaines recherches à leur stade très initial (par Verisign et plus tard l'ICANN) ont constaté un nombre croissant de validateurs signalant la configuration des ancres de confiance aux serveurs racines. Les données de six adresses de serveur racine indiquent que, pour le mois de septembre 2017, environ 12 000 adresses IP source uniques ont envoyé les rapports de configuration des ancres de confiance. Le nombre de réponses est en pleine croissance et se rapproche maintenant de 1400 adresses uniques par jour.

Ces rapports qui nous parviennent indiquent qu'environ 5 % du total des validateurs et environ 6 %-8 % sur un jour donné indiquent qu'ils utilisent KSK-2010, qui est la KSK de la zone racine qui signe actuellement la DNSKEY RRset de la racine. Fait important, ces validateurs ne se résoudraient plus correctement après le roulement KSK de la racine prévu.

Sur la base de ces nouvelles informations, nous avons décidé de reporter le roulement KSK de la racine pendant au moins un trimestre.

Tout au long du projet, nous avons souligné que le KSK de la racine est en cours de déploiement dans des conditions normales de fonctionnement et avons procédé avec prudence et sans précipitation. La décision de report a été prise dans cet esprit de prudence parce que nous n'avons pas de pression opérationnelle de procéder compte tenu notre confiance continue dans la sécurité de la clé actuelle, KSK-2010.

Il y a diverses raisons à ce qu'un validateur ne puisse fonctionner qu'avec KSK-2010 : une ancienne configuration avec une ancre de confiance statiquement configurée (p. ex. la déclaration de « clé de confiance » de BIND) ou un manquement de mise à jour automatique de l'ancre de confiance en utilisant le protocole de mise à jour automatique RFC 5011 en raison d'un défaut du logiciel, d'une erreur de l'opérateur ou d'autres raisons.

Compte tenu de la proportion relativement élevée de validateurs avec juste KSK-2010, l'ICANN croit qu'il est important d'en comprendre les motifs avant de continuer avec le roulement KSK de la racine. Nous allons bientôt publier la liste des validateurs ne fonctionnant qu'avec KSK-2010 et demander l'aide de la communauté opérationnelle pour nous aider à identifier, diagnostiquer et corriger ces systèmes.

Nous apprécions la compréhension de la communauté et nous nous réjouissons de votre aide à rassembler les informations nécessaires pour passer au roulement KSK de la 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."