Résumé

  • La nouvelle KSK est publiée avant son activation et coexiste avec l’ancienne afin que les résolveurs validants puissent mettre à jour leur ancre de confiance.
  • Analyse BTW : la continuité dépend de l’observation de cette adoption ; l’opération centralisée de rotation ne met pas à jour les logiciels distribués.

Sources : explication de la rotation KSK et méthode de mesure DNSSEC de LACNIC.

La validation DNSSEC part de la KSK de la zone racine, utilisée comme ancre de confiance, puis descend la chaîne de signatures. Un résolveur qui ne connaît pas la nouvelle ancre peut rejeter une réponse pourtant valide. L’explication des services IANA republiée par LACNIC décrit donc une publication anticipée et une période où les deux clés restent admises.

Cette période transforme le temps en surface de contrôle. Les opérateurs doivent vérifier les mises à jour automatiques et repérer les logiciels ou configurations restés obsolètes. Quelques résolveurs peuvent toucher beaucoup d’utilisateurs s’ils servent un grand réseau.

L’étude DNSSEC de LACNIC apporte un test observable. Ses sondes Atlas interrogent un domaine aux signatures volontairement invalides : SERVFAIL indique que le résolveur rejette la réponse, tandis que NOERROR révèle l’absence de validation. Des captures anonymisées repèrent aussi les requêtes de types DNSSEC.

La méthode a des limites. Les auteurs préviennent que les sondes Atlas se trouvent souvent dans des réseaux plus avancés ; l’échantillon peut représenter une borne haute plutôt qu’un recensement. Le contrôle décisif consiste donc à savoir quelles populations n’ont pas encore accepté la nouvelle ancre avant le retrait de l’ancienne.