Le 11 octobre, Internet change de clé : votre résolveur DNS est-il prêt ?

Deuxième tour de clé — Ce dimanche 11 octobre, la clé cryptographique qui sert de point de départ à toute la chaîne de confiance DNSSEC va être remplacée, pour la deuxième fois seulement de l'histoire.

C'est grâce à elle que les résolveurs DNS peuvent vérifier que les réponses qu'ils vous renvoient n'ont pas été falsifiées. Ces serveurs qui traduisent les noms de domaine en adresses IP, vous en utilisez un en permanence sans y penser : celui de votre fournisseur d'accès, de votre boîte ou un service comme 1.1.1.1.

Si ce résolveur n'a pas suivi le changement, plus aucun site ne répondra pour ceux qui passent par lui. Les sites, eux, tourneront parfaitement : c'est le résolveur qui refusera de vous indiquer le chemin.

La bonne nouvelle, c'est que la plupart d'entre vous n'auront rien à faire. Gérer un site ne suffit pas à être concerné, et Cloudflare assure que 1.1.1.1 et son DNS font déjà confiance à la nouvelle clé.

Les seuls à devoir mettre le nez dans leur config sont celles et ceux qui font tourner leur propre résolveur avec la validation DNSSEC activée, du BIND de la boîte à l'Unbound du homelab. Pour tous les autres, un simple test en ligne permet de vérifier que le résolveur qu'ils utilisent est prêt.

La clé de voûte

À sa création en 1983, le DNS ne prévoyait aucune vérification. Un résolveur prenait pour argent comptant les réponses qu'il recevait, et un attaquant pouvait lui en glisser une fausse pour envoyer ses utilisateurs sur un faux site. DNSSEC a été ajouté par la suite pour boucher ce trou, et la racine du DNS n'est signée que depuis 2010.

Pour vérifier qu'une réponse est authentique, le résolveur remonte une chaîne de confiance. Avec DNSSEC, les domaines qui l'adoptent signent leurs enregistrements, et chaque parent se porte garant de la clé de ses enfants : la racine du DNS publie l'empreinte de la clé de .com, qui publie à son tour celle de example.com.

Encore faut-il que la chaîne commence quelque part. La racine n'ayant personne au-dessus d'elle pour se porter garant, chaque résolveur qui vérifie les signatures conserve une copie de sa clé et lui fait confiance d'office : c'est son ancre de confiance.

Et c'est précisément cette clé qui change dimanche.

La toute première, KSK-2010, avait cédé sa place en 2018 à KSK-2017. Celle-ci passe à son tour la main à KSK-2024, que les outils désignent par son identifiant (key tag) : 38696.

Un résolveur qui ne connaît pas la nouvelle clé ne pourra plus valider la moindre réponse. C'est le scénario de panne totale de résolution DNS sur lequel alerte l'ICANN, l'organisme qui supervise le système des noms de domaine.

Les résolveurs qui ne vérifient pas les signatures, eux, ne verront aucune différence : pour une fois, c'est le bon élève qui risque la punition.

Les clés cryptographiques, c'est pas automatique

En théorie, tout se fait tout seul. Comme souvent sur Internet, la solution dort dans une RFC, en l'occurrence la 5011 : la racine publie la nouvelle clé en plus de l'ancienne, et le résolveur l'adopte après l'avoir vue pendant au moins 30 jours.

KSK-2024 est publiée depuis le 11 janvier 2025 et, d'après l'ICANN, plus de 95 % des résolveurs qui remontent des données l'ont déjà adoptée.

En pratique, c'est une autre histoire. Le premier changement, prévu pour 2017, avait dû être repoussé d'un an parce que beaucoup d'opérateurs n'étaient pas à jour.

Même Cloudflare s'y était fait prendre : à l'époque, une partie de ses propres résolveurs avaient oublié la clé apprise, à cause d'une vague de mises à jour logicielles et de processus déplacés d'une machine à l'autre. Quelque peu échaudée par cet incident, l'entreprise ne compte plus sur l'apprentissage automatique et a inscrit KSK-2024 en dur dans le logiciel de son résolveur dès juillet 2024.

L'ICANN recommande de ne pas faire aveuglément confiance à l'automatisme et de vérifier que le key tag 38696 figure bien dans le fichier d'ancres du résolveur (bind.keys pour BIND, root.key pour Unbound et PowerDNS Recursor, root.keys pour Knot Resolver).

S'il manque, vérifiez que les mises à jour automatiques sont activées et que le résolveur a le droit d'écrire dans son répertoire de stockage.

Un résolveur en conteneur, recréé à chaque déploiement depuis une vieille image, est un bon candidat à l'amnésie chronique sur le sujet.

Comment vérifier que votre résolveur DNS est prêt pour KSK-2024

Pour en avoir le cœur net sans fouiller dans la config, Cloudflare a mis en ligne un test qui interroge le résolveur utilisé par votre navigateur.

Le principe tient en deux requêtes DNS sur des noms spéciaux : l'une demande au résolveur s'il fait confiance à la clé 38696 (is-ta-38696), l'autre s'il ne lui fait pas confiance (not-ta-38696).

Un résolveur à jour répond normalement à la première et renvoie volontairement une erreur SERVFAIL à la seconde. Pour tester le vôtre, remplacez 1.1.1.1 par son adresse :

dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A

Si les deux répondent normalement, le test ne permet pas de conclure : votre résolveur ne valide pas DNSSEC ou ne gère pas ce mécanisme.

Notez que le test en ligne vérifie le résolveur qu'utilise votre navigateur, qui n'est pas forcément celui que vous pensez tester si vous avez activé le DNS sécurisé du navigateur ou si vous passez par un VPN.

En attendant le post-quantique

Le plan initial de l'ICANN prévoyait une rotation tous les trois ans. Il en aura fallu huit cette fois, la faute à une pandémie qui a forcé les participants aux cérémonies de clés (oui, car c'est assez sérieux) à y assister à distance, puis au passage à de nouveaux boîtiers sécurisés (HSM), qui a obligé à repartir de zéro avec une nouvelle paire.

Mais alors, pourquoi changer une clé qui fonctionne, d'autant que la nouvelle utilise le même algorithme (RSA/SHA-256) ?

D'abord par hygiène : plus une clé sert longtemps, plus elle a de chances de finir compromise. Ensuite, et surtout, pour s'entraîner : le jour où il faudra la remplacer en urgence, mieux vaut que les résolveurs de la planète sachent déjà faire la bascule sans casser Internet.

L'entraînement n'a d'ailleurs rien de superflu : la racine signe toujours en RSA, un algorithme qu'un ordinateur quantique suffisamment puissant pourrait casser, comme l'a démontré Peter Shor dès 1994. Pour que DNSSEC tienne le choc, elle devra un jour passer à une clé post-quantique et rejouer toute la manœuvre à l'échelle de la planète.

Quand on sait que Google a récemment avancé son Q Day à 2029, la date à laquelle la firme veut être prête à affronter ces machines, la bascule de dimanche prend des airs de tour de chauffe.

D'ici là, la seule échéance qui compte reste celle de ce 11 octobre. Vous avez encore quelques jours pour lancer le test, histoire de ne pas découvrir à vos dépens que, cette fois encore, c'était le DNS.