Le 18 septembre l’ICANN publiait une décision de son Board. Elle met un terme à plus de 2 ans de tergiversations sur le remplacement de la clé KSK (Key Signing Key) de la zone racine. Ce remplacement aura lieu le 11 octobre 2018.
En effet, depuis la mise en œuvre de DNSSEC en 2010 au niveau de la zone racine, c’est la même clé cryptographique (dite KSK-2010*) qui est utilisée pour signer la ZSK (Zone Signing Key), laquelle ZSK étant utilisée pour signer à son tour la zone racine. Cette KSK-2010 représente le point d’entrée qui, par le jeu des délégations, permet de créer une chaîne de confiance validant l’intégrité d’une réponse sur un enregistrement DNS d’une zone signée. Ceci explique pourquoi elle est stratégique.
Cette décision vous concerne plus particulièrement si vous exploitez, pour vous-même ou pour vos clients, un service de résolution DNS et que celui-ci est configuré pour réaliser de la validation DNSSEC. Dans ce cas, il est encore temps de vous mettre en conformité, si jamais vous n’aviez pas encore dans votre trousseau de clés la KSK-2017.
Pourquoi diable, en 2018, nommer cette clé KSK-2017 ?
Eh bien tout simplement parce qu’initialement, cette clé, créée en 2016, devait entrer en service en 2017. Or, l’ICANN a été dans l’obligation de repousser cette opération, suite à plusieurs alertes de la communauté qui s’inquiétait de l’impact que cela pourrait avoir sur les utilisateurs. Cela a conduit à la réalisation d’études d’impact qui concluent toutes qu’il y aurait effectivement une incidence visible. Par exemple, la mise en œuvre du RFC-8145 qui permet, entre autres, aux résolveurs validants d’indiquer quelles clés de confiance sont utilisées pour la racine, a permis de collecter des données à analyser. Il ressort de ces données que même si une majorité des résolveurs « participant » à cette collecte connaissent bien les 2 clés (la KSK-2010 et la KSK-2017), les 100% ne sont pas atteints.
Cependant, avec la garantie que les plus importants acteurs du secteur sont aujourd’hui prêts pour ce changement et avec la conviction que ces quelques pourcentages de résolveurs non conformes ne représentent en réalité qu’une « petite » fraction (à l’échelle d’internet, cela pourrait quand même vite représenter quelques millions d’utilisateurs), l’ICANN a décidé de franchir le Rubicon ce 11 octobre. Plus que quelques jours à attendre pour constater l’impact réel de ce changement.
Aussi, si vous êtes directement concerné, et que votre résolveur DNS validant ne contient pas ces 2 clés, il est nécessaire d’ajouter rapidement la KSK-2017 à votre trousseau de clés afin d’anticiper des problèmes de validation. La consultation des 2 liens fournis à la fin de ce billet devrait vous permettre de réaliser cette opération.
(*) Dans les faits, les clés ne sont pas identifiées avec ces 2 labels (KSK-2010/KSK-2017) mais par des entiers appelés « Key Tag ». Les clés KSK-2010 et KSK-2017 ont respectivement pour « Key Tags » 19036 et 20326.
Comment vérifier que votre résolveur connaît bien la KSK-2017 ?
En toute logique, sur une version récente de Bind, Unbound… la mise en œuvre du RFC-5011 assure la présence des 2 clés (KSK-2010 et KSK-2017). Voici, de manière non exhaustive quelques tests à réaliser pour valider que c’est bien le cas.
Si vous utilisez :
- Unbound : consultez le fichier « /var/lib/unbound/root.key » (Attention, il est peut-être ailleurs si la configuration a été personnalisée).
- Bind : sur les versions récentes (> 9.11), utilisez la commande « rndc managed-keys status », sur les autres, il faut chercher un des fichiers bind.keys, managed-keys.bind ou *.mkeys (cela dépend de votre configuration).
- Knot Resolver : tapez la commande « trust_anchors.keysets » dans la console.
- PowerDNS Recursor : tapez la commande « rec_control get-tas ».
Pour une information plus détaillée, nous vous recommandons les 2 liens suivants :
Autres liens Afnic utiles sur DNSSEC :
(*) Dans les faits, les clés ne sont pas identifiées avec ces 2 labels (KSK-2010/KSK-2017) mais par des entiers appelés « Key Tag ». Les clés KSK-2010 et KSK-2017 ont respectivement pour « Key Tags » 19036 et 20326.
À la une
07/11/24
Tous les ans, le Conseil Scientifique de l’Afnic organise ...
En savoir plus
Les méthodes d’authentification SPF, DKIM et DMARC forment ...
En savoir plus