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

Aperçu

L'ICANN a l'intention d'effectuer le roulement de la clé de signature de clé (KSK) des extensions de sécurité du système des noms de domaine (DNSSEC) dans la zone racine tel que requis par la déclaration de pratiques de DNSSEC de l'opérateur de la KSKde 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 la distribution de la nouvelle composante publique aux parties qui opèrent les résolveurs de validation, y compris : les fournisseurs de services Internet ; les administrateurs de réseaux d'entreprise et d'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 utilisée pour signer cryptographiquement la clé de signature de zone (ZSK) qui est utilisée par le responsable de la maintenance de la zone racine afin que la zone racine du DNS de l'Internet soit validée par le DNSSEC.

Il est essentiel d'obtenir la nouvelle clé afin de veiller à ce que les noms de domaine à valider par le DNSSEC continuent à valider après le roulement. Le défaut d'avoir la KSK de la zone racine actuelle voudra dire que les résolveurs validant DNSSEC seront incapables de vérifier que les réponses du DNS n'aient pas été faussées et retourneront donc une réponse d'erreur pour toutes les requêtes validées par le DNSSEC.

Les plans de roulement de la KSK ont été développés par les partenaires de gestion de la zone racine ; l'ICANN, dans le cadre de son rôle d'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. Les plans intégreront les recommandations de l'équipe communautaire de conception [PDF, 1,01 MB], en ajustant ces recommandations pour répondre aux exigences et aux contraintes opérationnelles. Maintenant que les plans ont été élaborés en collaboration, les futurs roulements de la KSK seront effectués par l'ICANN conformément aux dits plans.

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
Voir le calendrier des événements pour trouver les prochaines présentations du roulement de la KSK.

S'engager sur les réseaux sociaux
Utilisez 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 des 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 comment ils peuvent être affectés.

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 KSKde la zone racine [TXT, 99KO].

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 à l'ICANN d'effectuer un roulement de la KSK de la zone racine, mais ne spécifie ni un calendrier détaillé ni un plan de mise en œuvre. Le DPS de l'opérateur de la KSK de la zone racine contient cette déclaration, et précise une exigence pour un roulement dans l'article 6.5 :

« Chaque clé de signature de clé de la zone racine (RZ KSK) est programmée pour être reportée à travers une cérémonie de clé selon les besoins, ou après 5 ans d'opération ».

Calendrier préliminaire

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
  • 11 octobre 2017 : la nouvelle KSK commence à signer l'ensemble de clés de la zone racine (l'événement de roulement réel).
  • 11 janvier 2018 : révocation de l'ancienne KSK
  • 22 mars 2018 : dernier jour où l'ancienne KSK apparaît dans la zone racine.
  • Août 2018 : l'ancienne clé est supprimée des équipements dans les deux locaux de gestion de clés de l'ICANN.

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 pour accomplir le projet de roulement de la KSK 2017, y compris la chronologie du processus en huit étapes.
  2. Plan de marche arrière du 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 des anomalies survenant lors de l'exécution du plan opérationnel.
  3. Plan d'essai externe du roulement de la KSK 2017 [PDF, 516 KB] - Couvre la préparation des environnements du test opérationnel, auxquels le grand public d'Internet peut accéder, pour é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, 437 KB] - Décrit le plan pour surveiller les effets des variations de l'ancre de confiance pour la zone de racine dans le trafic vers les serveurs racine.
  5. Plan de test des systèmes de 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.
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."