Ce jeudi 11 octobre, à 1600 UTC, , la clé DNSSEC de la racine ICANN
change. Normalement, il n'y aura rien à faire, et aucun impact, mais
on ne sait jamais, l'informatique, des fois, ça fait des histoires,
donc voici quelques rappels.
La plupart des résolveurs DNS validants utilisent la technique décrite
dans le RFC 5011 <http://www.bortzmeyer.org/5011.html> et tout sera
donc automagique.
Votre résolveur DNS validant devrait déjà avoir la clé 19036
(l'actuelle, surnommée KSK-2010) et la 20326 (celle qui rentre en
service le 11 octobre, surnommée KSK-2017 car cela fait déjà un an
qu'elle a été générée). Pour vérifier :
Avec Unbound, on affiche le fichier des clés (son emplacement dépend
de votre configuration) :
% cat /var/lib/unbound/root.key
...
. 172800 IN DNSKEY 257 3 8 ... {id = 20326 (ksk), size = 2048b}
;;state=2 [ VALID ] ;;count=0 ;;lastchange=1502474052 ;;Fri Aug 11 19:54:12
2017
. 172800 IN DNSKEY 257 3 8 ... {id = 19036 (ksk), size = 2048b}
;;state=2 [ VALID ] ;;count=0 ;;lastchange=1404118431 ;;Mon Jun 30 10:53:51
2014
Ici, c'est bon, il y a les deux clés, en état VALID, et avec les
bonnes dates.
Avec Knot Resolver :
trust_anchors.keysets
dans la console devrait vous montrer un tableau avec les deux clés.
Avec PowerDNS Recursor, ça se fait avec rec_control:
# rec_control get-tas
Avec BIND 9.11 ou supérieur :
% rndc secroots -
Affiche les clés configurées, ou bien obtenues automatiquement. Si on
utilise la méthode automatique du RFC 5011 :
% rndc managed-keys status
...
name: .
keyid: 19036
algorithm: RSASHA256
flags: SEP
next refresh: Tue, 28 Aug 2018 17:18:31 GMT
trusted since: Mon, 24 Jul 2017 20:23:49 GMT
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Tue, 28 Aug 2018 17:18:31 GMT
trusted since: Mon, 24 Jul 2017 20:23:49 GMT
Parfait ici, il y a les deux clés.
Avec les versions de BIND plus anciennes, il faut regarder le fichier
managed-keys.bind. Si on utilise les vues, c'est le fichier
d'extension .mkeys dans chaque vue.
Les détails pour BIND sont documentés à l'ISC
<https://kb.isc.org/docs/aa-01529>
Avec un routeur Ubiquiti et dnsmasq :
xxxx@ubnt# show service dns forwarding options
options dnssec
options
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
options
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
options dnssec-check-unsigned
L'ICANN a une page Web indiquant comment tester les différents
résolveurs <https://www.icann.org/dns-resolvers-checking-current-trust-anchors>
Deux sites Web qui permettent (plus ou moins bien) de voir ce qui
arrivera le 11 octobre : <http://www.ksk-test.net/>
<http://test.kskroll.dnssec.lab.nic.cl/>
Question en apprendre plus, Adiel Akplogan a fait un bon article en
anglais
<http://www.circleid.com/posts/20180924_the_root_ksk_rollover_what_does_it_mean_for_me/>
et l'ICANN a la page Web officielle <https://www.icann.org/kskroll>.
Plusieurs articles dans les médias en anglais mais je n'ai rien trouvé
en français :
<https://www.networkworld.com/article/3305070/internet/icann-sets-plan-to-reinforce-internet-dns-security.html>
<https://hub.packtpub.com/redhat-shares-what-to-expect-from-next-weeks-first-ever-dnssec-root-key-rollover/>
<https://mybroadband.co.za/news/internet/277299-how-the-dns-key-change-will-affect-south-africans.html>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
