Skip to main content
Resources

Roulement de la KSK de la zone racine

Root Zone KSK Rollover

Aperçu
Ressources
Participer
Contexte
Calendrier préliminaire
Plans opérationnels
Plan de communication

Mises à jour techniques

1er février 2018 – Annonce du plan préliminaire pour la poursuite du roulement de la KSK

18 décembre 2017 – État de situation du projet de roulement de la KSK de la zone racine

17 octobre 2017 – Report du roulement de la KSK de la zone racine

27 septembre 2017 – L'ICANN annonce un report du roulement de la KSK

4 septembre 2017 –Vérifier les ancres de confiance actuelles des résolveurs de validation du DNS

4 septembre 2017 – Mise à jour des résolveurs de validation du DNS selon l'ancre de confiance la plus récente

11 juillet 2017 – La KSK-2017 est publiée au sein du DNS

Aperçu

L'ICANN prévoit d'effectuer un roulement KSK des extensions de sécurité du système des noms de domaine (DNSSEC) tel que requis dans la déclaration de pratiques DNSSEC de l'opérateur KSK de la zone racine [TXT, 99 KB].

Rouler la KSK signifie générer une nouvelle paire de clés cryptographiques publiques et privées et distribuer la nouvelle composante publique aux parties qui exploitent les résolveurs de validation, y compris : les fournisseurs de services Internet ; les administrateurs de réseaux d'entreprise et autres opérateurs du résolveur du système des noms de domaine (DNS) ; les développeurs de logiciels de résolveurs du DNS ; les intégrateurs du système ; et les distributeurs de matériel et de logiciels qui installent ou expédient l'« ancre de confiance » de la racine. La KSK est une clé cryptographique servant à signer la clé de signature de zone (ZSK), qui est utilisée par le responsable de la maintenance de la zone racine pour signer avec les DNSSEC la zone racine du DNS de l'Internet.

Tenir à jour la KSK est fondamental pour s'assurer que les résolveurs DSN validant le DNSSEC continuent de fonctionner après le roulement de clé. Ne pas avoir la KSK actuelle de la zone racine aura pour conséquence que les résolveurs validant le DNSSEC seront incapables de résoudre les requêtes du DNS.

Les plans de roulement de la KSK ont été développés par les partenaires de gestion de la zone racine ; l'ICANN, en tant qu'opérateur des fonctions IANA, Verisign, en tant que responsable de la maintenance de la zone racine et l'administration nationale des télécommunications et de l'information du département du commerce des États-Unis (NTIA) en tant qu'administrateur de la zone racine. Le rôle de la NTIA a pris fin le 1er octobre 2016. Les plans de roulement de la KSK ont été publiés en juillet 2016 et tiennent compte des recommandations de l'équipe de conception du roulement de la KSK de la zone racine [PDF, 1.01 MB].

Ressources

Pour mieux connaître les informations pertinentes et les ressources supplémentaires, veuillez consulter la page :

Participer

Poser une question
Envoyez un courrier électronique à globalsupport@icann.org en mettant « roulement de la KSK » dans la ligne objet du message pour poser vos questions.

Assister à un événement
Consulter le calendrier des événements pour trouver les prochaines présentations du roulement de la KSK.

S'engager sur les réseaux sociaux
Utiliser le hashtag #KeyRoll pour participer à la conversation : https://twitter.com/icann

Rejoindre la liste de discussion du roulement de la KSK
Inscrivez-vous à la liste de diffusion pour participer aux débats publics sur des questions connexes : https://mm.icann.org/listinfo/ksk-rollover

Passer le mot
Partagez cette page Web avec d'autres pour les aider à mieux connaître le roulement de la KSK et les effets éventuels.

Contexte

En 2009, les partenaires de la RZM ont collaboré au déploiement de DNSSEC dans la zone racine, qui a abouti à la première publication d'une zone racine signée ayant été validée en juillet 2010.

Les exigences [PDF, 116 KB] pour générer et maintenir la KSK de la zone racine, ainsi que les responsabilités respectives de chacun des partenaires de la RZM, ont été spécifiées par la NTIA. Les procédures par lesquelles ces exigences ont été remplies par le responsable de la maintenance de la zone racine (Verisign) et l'opérateur des fonctions IANA (ICANN) ont été publiées dans des déclarations de politique et pratiques du DNSSEC (DPS). DPS du service de signature de DNSSEC de Verisign [PDF, 138 KB] et DPS de l'opérateur de la KSK de la zone racine [TXT, 99 KB].

Le contrat des fonctions IANA entre la NTIA et l'ICANN a été modifié en juillet 2010 pour y inclure les responsabilités liées à la gestion de la KSK de la zone racine, et ces exigences ont été reportées dans les révisions subséquentes de ce contrat.

L'accord de coopération entre la NTIA et Verisign a été également modifié en juillet 2010 pour refléter les responsabilités de Verisign en tant qu'opérateur de la KSK de la zone racine.

Le contrat des fonctions IANA exige le roulement de la KSK de la zone racine, mais ne spécifie ni les exigences et le calendrier détaillés, ni un plan de mise en œuvre. Le DPS de l'opérateur de la zone racine de la KSK contient la déclaration suivante, établissant les conditions du roulement à l'article 6.5 :

« Chaque RZ KSK devrait être roulée au cours d'une cérémonie de clé selon les besoins, ou après 5 ans d'opération ».

Calendrier

Ces dates peuvent changer en raison de considérations opérationnelles.

  • 27 octobre 2016 : le processus de roulement de la KSK après la génération de la nouvelle KSK.
  • 11 juillet 2017: publication de la nouvelle KSK dans le DNS
  • 19 septembre 2017 : augmentation de la taille de la réponse DNSKEY des serveurs de noms racine
  • 1er février 2018 : période de consultation publique du plan visant à résumer les débuts du roulement KSK - fin le 2 avril 2018.
  • Des dates supplémentaires seront annoncées à mesure que les plans du projet du roulement KSK de la zone racine sont mis à jour

Plans opérationnels

  1. Plan opérationnel de mise en œuvre du roulement de la KSK 2017[PDF, 741 KB] - Décrit en détail les étapes opérationnelles à suivre pour accomplir le projet de roulement de la KSK 2017, y compris la chronologie du processus en huit étapes. - Ce document est actuellement mis à jour afin de refléter le report annoncé le 27 septembre 2017.
  2. Plan de secours pour le roulement de la KSK 2017[PDF, 506 KB] - Décrit les déviations prévues par le plan opérationnel de mise en œuvre sur la base d'anomalies survenant lors de l'exécution du plan opérationnel.- Ce document est actuellement mis à jour afin de refléter le report annoncé le 27 septembre 2017.
  3. Plan d'essai externe du roulement de la KSK 2017[PDF, 516 KB] - Couvre la préparation d'environnements pour le test opérationnel, auxquels le grand public d'Internet peut accéder afin d'évaluer si les systèmes externes sont prêts à participer au roulement de la KSK.
  4. Plan de surveillance du roulement de la KSK 2017[PDF, 480 KB] - Décrit le plan pour surveiller les effets des variations de l'ancre de confiance de la zone de racine dans le trafic vers les serveurs racine.
  5. Plan du test des systèmes en vue du roulement de la KSK 2017[PDF, 519 KB] - Décrit les actions nécessaires pour tester les modifications apportées à l'infrastructure de l'ICANN, impliquées dans le roulement de la KSK.

Plan de communication

L'ICANN mène une vaste campagne de sensibilisation dans le but de s'assurer que ceux qui utilisent actuellement la KSK soient au courant des changements.

Archive des actualités

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."