En temps normal, le roulement d'une KSK se passe bien et en douceur avec OpenDNSSEC. Ici, on va s'attarder sur le cas spécial (et inutile) où un roulement de KSK approche et que l'on souhaite quitter un modèle arborescence pour les données + arborescence séparée pour les délégations signées (DLV) pour le modèle normal et classique de DNSSEC : une seule arborescence unifiée.
Si vous débutez avec DNSSEC, je vous recommande les lectures suivantes :
- DNS : Attaques et sécurisation pour la théorie.
- DNSSEC pour 2013 pour l'aspect pratique avec OpenDNSSEC.
Rappel : DLV permet de séparer l'arborescence qui contient les données (enregistrements NS/A/AAAA/MX/SRV/DNSKEY/RRSIG/...) de celle qui contient les délégations signées. Cela permet de créer une chaîne de confiance avec des ilôts sécurisés (zone signée dont la zone parente n'est pas signée/n'accepte pas l'ajout de délégations signées, ...) tant que l'intégralité de l'arborescence pour arriver à ces ilôts n'est pas signée et/ou n'accepte pas l'ajout de délégations signées. DLV est très peu utilisé. Il existe plusieurs dépôts DLV, le plus important étant celui de l'ISC (dlv.isc.org). Un (ou plusieurs) dépôt doit être configuré sur un récursif-cache sinon DLV n'est pas utilisé par ledit récursif-cache. Quand DLV est configuré, le récursif-cache cherche d'abord une délégation signée valide via l'arborescence classique (racine, TLD, ...). Si le résultat est négatif, il utilise les dépôts DLV configurés pour tenter de trouver une délégation signée.
Historique : au moment où j'ai voulu signer mes zones (dont guiguishow.info.), info. n'acceptait pas encore la soumission de délégations signées (enregistrements de type DS qui pointent sur la KSK de la zone) ou, en tout cas, mon bureau d'enregistrement ne me permettait pas d'effecter une demande d'ajout. Juste pour découvrir et m'amuser, j'ai alors décidé d'utiliser le registre DLV de l'ISC.
Or, depuis quelques mois, je peux enfin soumettre un enregistrement DS via l'interface de mon bureau d'enregistrement. Donc, en tout logique, je souhaite arrêter d'utiliser DLV. La première idée qui vient à l'esprit est de profiter du roulement de la KSK qui approche pour effectuer cette transition.
Pour les plus perspicaces : oui, j'ai signé mes zones (sauf une) en janvier 2013 donc le roulement de la KSK aurait du avoir lieu en janvier 2014. Sauf que le passage de Squeeze à Wheezy ne s'est pas fait en douceur : OpenDNSSEC a supprimé les clés utilisées du HSM logiciel, me forçant à un roulement de clés d'urgence.
Réfléchissons à cette idée (profiter du roulement de KSK approchant pour ne plus utiliser DLV) en regardant le schéma des états que peuvent avoir les clés dans OpenDNSSEC ainsi qu'en révisant le schéma de pré-publication qui est utilisé.
Voilà ce qui se passerait si j'abandonnais DLV durant le roulement de la KSK (j'ai pris en compte uniquement les états visibles dans les outils OpenDNSSEC ce qui exclut les états « Générated » et « Dead ») :
État « Publish » :
- Récursifs-cache utilisant le dépôt DLV de l'ISC : aucun impact car le seul changement est que le RRset DNSKEY comporte un RR supplémentaire (la partie publique de la nouvelle clé).
- Récursifs-cache qui n'utilisent pas DLV : aucun impact pour la même raison.
État « Ready » :
- Récursifs-cache utilisant le dépôt DLV de l'ISC : aucun impact. OpenDNSSEC considère simplement que la nouvelle clé est présente dans suffisamment de récursifs-cache et peut donc être utilisée.
- Récursifs-cache qui n'utilisent pas DLV : aucun impact pour la même raison.
Je demande l'ajout d'un RR DS dans la zone info. À partir du moment où il est publié :
- Récursifs-cache utilisant le dépôt DLV de l'ISC :
- Récursifs-cache qui ont encore des données en cache : aucun impact. L'ancienne clé est toujours présente dans la zone et elle signe toujours ladite zone et les anciennes signatures ainsi que la délégation signée sont en cache.
- Récursifs-cache qui n'ont plus rien en cache : ils feront une nouvelle résolution sans utiliser DLV et trouveront le DS pointant sur la nouvelle clé ... qui ne signe rien alors qu'il y a des signatures dans la zone : échec. Théoriquement, ils continueront à utiliser DLV et remettront donc les données en cache.
- Récursifs-cache qui n'utilisent pas DLV : le DS pointe sur la nouvelle clé ... qui ne signe rien alors qu'il y a des signatures dans la zone : échec. A priori aucun impact pour les récursifs-cache qui ont encore des données en cache.
État « Active » (j'indique à DNSSEC que le DS est publié) :
- Récursifs-cache utilisant le dépôt DLV de l'ISC :
- Récursifs-cache qui n'ont plus rien en cache : ils referont une résolution sans utiliser DLV et trouveront le DS qui pointe sur la nouvelle clé qui signe la ZSK qui signe la zone : tout va bien.
- Récursifs-cache qui ont obtenus des données entre la publication du DS et le passage à l'état « active » : ils ont toujours le bon DS et les anciennes signatures en cache : échec. Ils peuvent utiliser DLV tant qu'un élément de la chaîne de confiance n'est pas brisée dans leur cache (l'enregistrement DLV pointe désormais sur l'ancienne KSK qui ne signe plus rien).
- Récursifs-cache qui n'utilisent pas DLV :
- Récursifs-cache qui ont obtenus des données entre la publication du DS et le passage à l'état « active » : ils ont toujours le bon DS qui pointent sur la nouvelle KSK qui ne signe rien (ancienne signature du RRset DNSKEY) : échec.
- Récursifs-cache qui n'ont plus rien en cache : le DS pointe sur la nouvelle clé qui signe la ZSK qui signe la zone : tout va bien.
Bien sûr, la période de temps entre le moment où la délégation signée est publiée dans la zone parente et le moment où on indique cette publication à OpenDNSSEC est plus ou moins grande en fonction de ma réactivité/disponibilité. Ce qui implique que le trouble que je décris durera plus ou moins longtemps.
Pour que l'analyse soit complète, il faudrait tenir compte du fait que le cache d'un récursif n'est pas tout vide ou tout plein pour un même domaine : toutes les données (délégation dans la zone parente, signatures, ...) n'expirent pas en même temps (TTL différents). Ça augmente les combinaisons possibles.
Néanmoins, la documentation d'OpenDNSSEC (ainsi que le man ods-ksmutil) nous conseille de ne pas changer les paramètres d'une politique de signature notamment les délais de "propagation" (terme pas vraiment correct car il induit en erreur sur la réalité du processus) pendant qu'un roulement de clés est en cours. Ce qui est logique. Je ne souhaite pas changer les délais de propagation mais je vais changer les TTL (DS/SOA de la zone parente) car ils sont utilisés par OpenDNSSEC pour affiner ses calculs.
En conséquence, soit je fais ce changement de politique pour ma zone avant le roulement ou après. Avant, ça ne convient pas si je laisse une délégation dans le registre DLV car la politique ne sera donc plus adaptée à la zone parente. Après, ça me semble un peu tard notamment car les calculs pour le roulement seront légèrement "faussés".
Une méthode beaucoup plus simple est d'ajouter une délégation signée dans la zone parente (info) qui pointe sur la KSK actuelle, avant le roulement. Les récursifs-cache qui utilisent DLV et ont des données en cache continueront à valider puis, à expiration des TTL, n'utiliseront plus DLV mais pourrons toujours valider les signatures. Les récursifs-caches qui n'utilisent pas DLV et qui ont des données en cache, continueront à ne pas valider, puis, à expiration des TTL, valideront les signatures. De plus, le roulement de la KSK tombera dans le cas général qui est très bien pris en charge par OpenDNSSEC.
Les étapes sont donc de se débarrasser de DLV puis de modifier la politique de signature utilisée par OpenDNSSEC pour la zone. J'ai fait ça le week-end du 10 mai pour un roulement de clé planifié pour le 19-20 mai 2014.
Pour la première étape, il suffit de demander la publication d'un enregistrement DS dans info. La prise en compte au plus tard par les récursifs sera : maintenant + temps de publication (moins de 15 minutes dans mon cas) + 3600 secondes (1h). Cela correspond au cache négatif dans info. (ça concerne tous les récursifs-cache, qu'ils utilisent DLV ou non) et au TTL des enregistrements DLV dans le dépôt DLV de l'ISC (ça concerne les récursifs-cache qui utilisent ce dépôt).
Après quelques temps (au bout d'une heure ça devrait être plié mais j'ai attendu 2 jours, sans raison), on pourra supprimer notre délégation du dépôt de l'ISC.
Pour la deuxième étape, il faut d'abord ajouter une politique dans le fichier de configuration « kasp.xml » d'OpenDNSSEC. J'ai simplement copié/collé la politique qui s'applique à toutes mes zones qui ont une délégation signée dans le dépôt DLV de l'ISC et j'ai changé les paramètres relatifs à la zone parente.
On synchronise le contenu de ce fichier avec la base de données d'OpenDNSSEC :
ods-ksmutil update kasp zonelist filename set to /etc/opendnssec/zonelist.xml. kasp filename set to /etc/opendnssec/kasp.xml. Policy guiguishow found Info: converting P1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days |
On modifie ensuite le fichier zonelist.xml pour changer la politique associée à la zone par la nouvelle politique.
On synchronise le contenu de ce fichier avec la base de données d'OpenDNSSEC :
ods-ksmutil update zonelist zonelist filename set to /etc/opendnssec/zonelist.xml. kasp filename set to /etc/opendnssec/kasp.xml. Zone guiguishow.info found Policy set to guiguishow. |
On vérifie que le changement a bien été pris en compte.
Avant :
ods-ksmutil zone list zonelist filename set to /etc/opendnssec/zonelist.xml. Found Zone: guiguishow.info; on policy dlv |
Après :
ods-ksmutil zone list zonelist filename set to /etc/opendnssec/zonelist.xml. Found Zone: guiguishow.info; on policy guiguishow |
On utilise aussi la commande « ods-ksmutil key list » pour vérifier qu'on n'a pas fait d'erreur et que nos clés sont toujours là (même si la doc indique que la commande « update » ne touche pas aux clés).
Au moment venu du roulement de la KSK, on est tranquille, on laisse OpenDNSSEC faire le taff, on demande la publication d'un nouveau DS dans la zone parente quand il nous le demande (état « ready ») et c'est tout.