nsd + dnssec
#1

Bonsoir :-)

Je viens de configurer DNSSEC pour mon serveur nsd. La clef publique KSK a été copiée chez mon Registrar qui en a calculé une empreinte. (Et après calcul, j'ai la même chez moi ce qui est rassurant !)

Pour ce faire, j'ai changé

Code :
zone:
        name: "chezmoi.tld"
        zonefile: "chezmoi.tld/zone.db"

par

Code :
zone:
        name: "chezmoi.tld"
        zonefile: "chezmoi.tld/zone.db.signed"

du fichier /var/nsd/etc/nsd.conf.

À aucun moment je n'ai édité le fichier de zone qui est situé dans /var/nsd/chezmoi.tld/zone.db avec désormais à ces côtés le fichier /var/nsd/chezmoi.tld/zone.db.signed.

Deux questions :

- Vu le principe de la mise en place de DNSSEC avec nsd (et ce n'est pas le même principe avec bind), je n'ai pas édité le fichier de zone.db pour incrémenté de 1 le numéro de série. Je n'en vois pas l'intérêt puisque je n'ai justement pas édité ce fichier. Pouvez-vous confirmer ?

- Sinon une question très certainement idiote la signature de mon fichier de zone a une durée de vie de 2 mois. Je l'ai décidé ainsi. Mais que dois-je faire des anciennes clefs ZSK au delà de cette limite ? Puis-je les écraser dans deux mois après les avoir remplacé par de nouvelles ou ai-je des obligations légales (voire techniques ce que je ne pense pas) qui me contraignent de les conserver sur une certaine durée ? Votre point de vue ?

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#2

Permets moi de te dire vertement le fond de ma pensée.

T'as déconné royalement.

DNSSEC faut le tester pendant un certain temps avant de charger les clés. (dans l'ideal, je dirais qu'il faut faire un cycle complet ksk, quitte à faire un premier cycle court). Et faut tout automatiser. Dès le depart.

Sinon, réponse à tes questions :

- L'incrementation de ton fichier de zone se fait maintenant à la signature. Par contre, faut bien s'assurer que la signature se fasse lorsque tu édite la zone !

- à mon avis tu n'as pas tout compris à dnssec, en particulier les durées de vies des clés et signatures. Pas le temps d'expliquer ca maintenant.

Peux-tu expliquer de manière bien détaillée ton installation et tout ce que tu as (ou vas) mettre en place. Notamment tous les scripts.
Répondre
#3

Bon j'explique comment les clés doivent être gérées.

Les signatures de zones ont une durée de vie définie (disons DdVSig : Durée de Vie Signature) et durant tout ce temps, les clés les ayant signées doivent être disponibles.

Ce qui signifie que la durée de validité des clés et leur durée d'utilisation ne sont pas la même ! Une clé est valide si elle est publiée dans la zone et signée par la clé maître KSK (y compris cette même clé KSK) et par elle-même. Mais elle une clé ZSK ne doit être utilisée pour signer que lorsque tous les résolveurs qui connaissent la zone l'ont en mémoire. Idem, elle ne doit plus être utilisée à la fin de sa durée de vie, mais elle doit rester valide (dispo dans la zone et signée) tant que ses signatures elles-mêmes n'ont pas expiré.

Donc les ZSK ne doivent être supprimées qu'au bout de leur durée de vie + DdVSig !

Ça marche ?
Répondre
#4

Que c'est bien compliqué ! pffff....

GPG:Fingerprint ed25519 : 072A 4DA2 8AFD 868D 74CF  9EA2 B85E 9ADA C377 5E8E
GPG:Fingerprint rsa4096 : 4E0D 4AF7 77F5 0FAE A35D  5B62 D0FF 7361 59BF 1733
Répondre
#5

C est la, qu on comprend. Pourquoi, il y a autant de monde sur windows ???.
Répondre
#6

@22decembre:

Citation :Permets moi de te dire vertement le fond de ma pensée.
T'as déconné royalement.

Salut 22decembre ;-)

Je vais essayer de t'expliquer ce que j'ai fais et ce que j'ai compris des manipulations sur DNSSEC avec un fichier de zone. Ainsi, tu pourras m'indiquer où "je déconne royalement" et cela me permettra ainsi de mieux comprendre mes erreurs le cas échéant et de progresser. Je tiens à noter qu'entre la date de mon premier post et ce que je vais expliquer ci-dessous, j'ai eu le temps de "mûrir".

Attention, cela va être long ! :-)

(1) J'utilise ldns sur un système Debian. En effet, dans un premier temps, même si j'ai bien compris ton message au niveau de l'automatisation du processus, je ne désire pas effectuer les manipulations liées à DNSSEC de façon automatique (notamment sur le serveur). Autre raison : Comme tu le sais, le logiciel teirs zkt fourni par le projet OpenBSD est "obsolète" et je ne désire pas compiler la version de zkt directement sur mon serveur.

(2) J'utilise donc un système Debian avec le logiciel ldns (après avoir lancé la commande "apt install ldnsutils").

URL : https://www.nlnetlabs.nl/projects/ldns/

Préalable : Sur mon système FreeBSD, si j'ai modifié mon fichier de zone qui se nomme "zone.db", alors je change son numéro de série. (En ce moment, je le modifie souvent pusique je fais des tests et j'apprends.) J'effectue une copie de ce nouveau fichier de zone sur une clef USB puis je le copie dans un répertoire "tmp" d'un compte simple utilisateur d'un système Debian (virtuel ou réel).

Sur Debian, je lance la construction de DFLinux avec livebuild pour aider à la construction des deux couples de clefs.

Puis :

(a) Je crée un répertoire "zsk" dans le répertoire "tmp".
(b) Je crée un répertoire "ksk" dans le répertoire "tmp".
© Je lance la commande :

$ ldns-keygen -a RSASHA256 -b 2048 chezmoi.tld

qui me permet de créer le couple de clefs zsk pour signer les différents éléments de mon fichiers de zone.

Mon choix : La durée de vie de ce couple de clefs sera de deux mois. Par conséquent, dans deux mois, je recommencerai cette manipulation.

(d) Le couple de clef zsk créés, je lance la commande :

$ ldns-keygen -a RSASHA256 -b 4096 -k chezmoi.tld

qui me permet de créer le couple de clefs ksk pour signer les différents éléments de mon fichiers de zone.

Mon choix : La durée de vie de ce couple de clefs sera d'une année. Par conséquent, dans un an, je recommencerai cette manipulation. Comme tu l'as précisé, je conserve donc ce couple de clefs précieusement. Dans mon cas : DvdSig = 1 année.

(e) Le couple de clef ksk créés, je lance la commande :

$ ldns-signzone -e 20171013 zone.db ksk/DEBUT_NOM_DES_CLEFS_KSK_SANS_EXTENSION zsk/DEBUT_NOM_DES_CLEFS_ZSK_SANS_EXTENSION -f zone.db.signed

qui me permet de créer le fichier de zone signé pour chacun de ces éléments. Les enregistrements signés du fichier de zone (RRSIG) sont donc créés. À partir de cette construction, ce fichier de zone zigné qui se nomme "zone.db.signed" sera valide durant deux mois. Par conséquennt, dans deux moix, un couple de clefs zsk sera recréé comme à l'étape ©. C'est notamment à ce niveau là de ma "chaîne de fabrication" que je me demande si je peux librement écraser les anciennes clefs zsk qui ne sont devenues obsolètes ou si je dois les conserver pour une demande "officielle" ultérieure (de la part de mon Registrar, de "l'État", ... que sais-je ?!!).

(f) La version signée du fichier de zone créé (nommé "zone.db.signed"), je lance la commande :

$ ldns-key2ds -n -2 zone.db.signed > zone.db.signed.txt

qui me permet de créer une empreinte du fichier de zone signé ("-2" pour choisir l'algorithme de hachage SHA256).

(3)

(a) L'empreinte du fichier de zone signé créé, je crée une archive compressée en tar.gz du répertoire "tmp" que je copie sur la clef USB. Ensuite, je copie le tout sur le compte root de mon serveur. (Mon choix : Je n'utilise ssh.)

(b) Je décompresse l'archive. Je l'ouvre et j'accède donc à aux données créés sur le système Debian :

- le répertoire "ksk"
- le répertoire "zsk"
- le nouveau fichier de zone non signé "zone.db". (Rappel : le numéro de série a été modifié ci-dessus sur mon système FreeBSD).
- le nouevau fichier de zone signé "zone.db.signed" dans lequel, notamment, le numéro de série modifié a été chiffré avec la ligne "SOA" concernant le domaine chezmoi.tld.

© Je change les droits de tout ce nouveau petit monde avec un "chown -R root:wheel". J'écrase tous les ancienns données concernant la zone chezmoi.tld avec un "rm -rf /var/nsd/chezmoi.tld/*"**. (Rappel : "zone.db.signed" apparaît bel et bien au niveau du fichier "/var/nsd/etc/nsd.conf" à la place de "zone.db".)

** Là je fais bien attention à ce que je valide !!!

(d) Avec un "#ls -lh /var/nsd/chezmoi.tld/*", je vérifie que tout est bien comme il se doit : droits (600 sur les clefs ksk/zsk) privées, le fait que dans chaque répertoire (zsk, ksk) apparaissent deux clefs uniquement (une privée avec l'extension ".private" et une publique avec l'extenson ".key"), j'efface les données inutiles sur le serveur comme le fichier "zone.dn.signed.txt" créé à l'étape (2f), ...

Lorsque je suis certain de tous les changements opérés, je lance la commande :

# rcctl restart nsd

puis je quitte le compte root du système OpenBSD qui exploite mon serveur après avoir débranché proprement ma clef USB.

(4) Je retourne sur mon système FreeBSD. Je lance mon navigateur Mozilla Firefox. L'URL choisie : Celui de mon Registrar ! J'ouvre donc une session sur mon compte chez mon Registrar. Je copie la clef publique ksk là où il faut. Je vérifie que l'empreinte générée chez mon Registrar correspond bien avec celle générée sur le système Debian. (Rappel : Dans le fichier "zone.db.signed.txt" de l'étape (f)).

Je garde une copie de toutes ces données grâce à l'archive compressée en faisant une référence claire à leur date de création du style "tmp-20170813.tar.gz".

(5) Dans deux mois (quelques jours avant), mis à part les étapes (2b) et (2c) de le création du couple de clefs ksk, je devrai donc reprendre toutes les étapes précédentes à partir de l'étape (2).

Par conséquent :

- J'irai dans le répertoire "tmp".
- J'effacerai tout ce qui se trouve dans le répertoire "zsk" et les fichiers zone.db.signed et zone.db.signed.txt. Quant au fichier de zone "zone.db", tout dépendra si je l'ai modifié par une version plus récente !
- Je lancerai la construction de DFLinux.
- Je lancerai la génération des nouvelles clefs zsk.
- Je signerai le fichier de zone en utilisant les nouvelles clefs zsk (valabales pour les deux mois à venir) et les anciennes clefs ksk (encore valables pour les 10 mois à venir).
- Sur mon serveur OpenBSD, j'irai copier les nouvelles données : le nouveau répertoire "zsk" et le nouveau fichier "zone.db.signed" (le cas échéant le nouveau fichier "zone.db" pour assurer la cohérence de l'ensemble).

Et là dans un an, je me demande aussi si d'un point de vue "institutionnelle", je dois conserver l'ancien couple ksk (clef privée/clef publique). Tu me confirmes que, d'un point de vue strictement technique, nous pouvons les supprimer. Ok, j'avais bien compris. Mais comme je l'ai déjà mentionné à deux reprises ci-dessus, y a-t-il des raisons non techniques ("institutionnelles", ...) qui nous obligeraient à les conserver ?

Voilà. Désolé pour ce roman.

Alors @22decembre, qu'en penses-tu ? Bien évidemment, tu mets de côté l'aspect non automatique de la méthode décrite ci-dessus (et voulue de ma part) !

Sinon, merci pour tes explications. Ce passage notamment

Citation :Mais elle une clé ZSK ne doit être utilisée pour signer que lorsque tous les résolveurs qui connaissent la zone l'ont en mémoire. Idem, elle ne doit plus être utilisée à la fin de sa durée de vie, mais elle doit rester valide (dispo dans la zone et signée) tant que ses signatures elles-mêmes n'ont pas expiré.

qu'il va falloir que je médite avec mes outils actuels ! ;-)

@PengouinBSD : Je confirme que ce "roulement" des clefs ZSK en lien avec une authentification avec un clef KSK sur une année (pour moi du moins) n'est pas trivial à comprendre et à mettre en oeuvre avec les outils natifs du projet OpenBSD (ce que je ne fais pas d'ailleurs).

@Kokol: Hors de question. Ce ne serait pas aussi amusant. Lis ma prose ci-dessus ! ;-) D'ailleurs, comment ces maniupluations sont effectuées sur un serveur Windows hébergeant un serveur DNS primaire ? Est-ce possible ? Probablement !

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#7

kuniyoshi a écrit :Je tiens à noter qu'entre la date de mon premier post et ce que je vais expliquer ci-dessous, j'ai eu le temps de "mûrir".

Ok. Bon, t'as (un tout petit peu) moins déconné que ce que j'ai pensé. Mais quand même!

Déjà premiere déconne : Tu as mis tes clés dnssec dans le registre sans avoir tout solutionné auparavant.

kuniyoshi a écrit :je ne désire pas effectuer les manipulations liées à DNSSEC de façon automatique (notamment sur le serveur).

Je comprends pourquoi : tu veux voir comment ça marche avant de pouvoir automatiser. Mais commence dès maintenant à concevoir tes scripts, sinon tu seras mort ! (juste l'idée qu'un renouvellement de clés tombe un jour où tu n'as aucune minute de libre…)

Deuxième déconne : T'as pas compris que les durées de vie des signatures de zones (DdVSig) sont normalement plus courtes que les durées de vie des ZSK.

Chez moi les signatures sont valables 5 jours (de mémoire), les ZSK 1 mois et les KSK 1 an.

Il faut que tu cherches quelle est ta vraie DdVSig.

Sinon bonne idée de générer tes clés sur un autre pc… Mais je pense que les signatures doivent se dérouler sur le serveur lui-même.
Répondre
#8

Tiens, je viens de voir que ldns est dispo dans les ports d'OpenBSD ! On va pouvoir avoir des trucs plus récents.
Répondre
#9

À lire pour s'en inspirer (et probablement ameliorer) :

https://www.digitalocean.com/community/t...untu-14-04
Répondre
#10

@22decembre: Ok. Je commence à comprendre que la partie durée de vie m'échappe complètement actuellement. Pourtant j'avais bien lu tes écrits sur ce point dans l'ouvrage de thuban. Je viens de le re-parcourir rapidement et effectivement j'en avais déjà pris connaissance il y a quelques semaines... puis, notamment, accaparé par le fait de vouloir trouver une alternative à zkt, j'ai complètement oublié ce passage ?!

Alors effectivement, comme l'a souligné PengouinBSD ci-dessus, cela me semble désormais nettement plus compliqué de gérer le roulement.

Citation :Chez moi les signatures sont valables 5 jours (de mémoire), les ZSK 1 mois et les KSK 1 an.
Il faut que tu cherches quelle est ta vraie DdVSig.

Soyons très clair :

- Le fait que tes clefs ZSK soient valables 1 mois et KSK 1 année, c'est bien toi qu'il l'a décidé ? Ou alors je n'ai vraiment rien compris ! :-(
- Par contre, effectivement, cette donnée m'échappe : DvDSig. Je vais voir tout de suite où cette information se trouve ensuite j'avise.

Sinon, vu que je viens de modifier mon fichier zone il y a environ 2 heures sans respecter les durées de vie des signatures de zones, dans les faits, il se passe quoi ? Cela fait bien une semaine que je procède ainsi et je n'ai jamais rien remarqué. Au bout d'un certain laps de temps, tout re-fonctionne... de mon point de vue du moins. Où se situe le vrai problème si on re-crée un couple de clefs ZSK comme bon nous semble (en avance ou en retard par rapport au DvDSig) ? Exemple concret : Aujourd'hui, j'ai modifié mon fichier de zone sur la partie SPF, DKIM et DMARC. J'ai donc naturellement ré-créé un couple de clefs ZSK pour signer ce nouveau fichier de zone. Peut-être aurais-je dû garder l'ancien couple de clefs ZSK pour signer le nouveau fichier de zone ? Après tout ce semble tout aussi cohérent puisque cet ancien couple de clef était encore valide ! Quant à la DdVSig... aucune idée. Oui, ce n'est plus aussi clair qu'avant. Je vais y réfléchir.

Citation :Sinon bonne idée de générer tes clés sur un autre pc…

Bah j'ai bien dû trouver une alternative pour générer mes clefs ailleurs que sur OpenBSD.

Citation :Mais je pense que les signatures doivent se dérouler sur le serveur lui-même.

Pourquoi ? Pour la facilité de la mise en oeuvre de l'automatisationdu "roulement" des clefs je suppose. Si c'est le cas je suis d'accord mais il faut bien voir que cela prend des ressources sur la machine. J'avoue que j'ai du mal à accepter le fait que les clefs seront générées sur mon (petit) serveur... en production.

Citation :Tiens, je viens de voir que ldns est dispo dans les ports d'OpenBSD ! On va pouvoir avoir des trucs plus récents.

Ok. Merci. Quelle version ? A priori, la version installée sur Debian est la plus récente (2008 il me semble). Donc cela devrait aussi être la dernière version sur OpenBSD. À vérifier !

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#11

kuniyoshi a écrit :@22decembre: Ok. Je commence à comprendre que la partie durée de vie m'échappe complètement actuellement.

Non, tu crois ? je te rassure, tous ces trucs ca a pris enormement de temps pour moi à le comprendre.

Citation :Pourtant j'avais bien lu tes écrits sur ce point dans l'ouvrage de thuban. Je viens de le re-parcourir rapidement et effectivement j'en avais déjà pris connaissance il y a quelques semaines... puis, notamment, accaparé par le fait de vouloir trouver une alternative à zkt, j'ai complètement oublié ce passage ?!

Alors effectivement, comme l'a souligné PengouinBSD ci-dessus, cela me semble désormais nettement plus compliqué de gérer le roulement.

Citation :Chez moi les signatures sont valables 5 jours (de mémoire), les ZSK 1 mois et les KSK 1 an.
Il faut que tu cherches quelle est ta vraie DdVSig.

Soyons très clair :

- Le fait que tes clefs ZSK soient valables 1 mois et KSK 1 année, c'est bien toi qu'il l'a décidé ? Ou alors je n'ai vraiment rien compris ! :-(

Oui. Et aussi la durée de validité des Sig. Tout ca ca se module. Ta DdVSig doit etre suffisamment longue pour pas trop charger le serveur et la bande passante, mais pas trop longue pour te permettre de faire des changements rapides.

Citation :- Par contre, effectivement, cette donnée m'échappe : DvDSig. Je vais voir tout de suite où cette information se trouve ensuite j'avise.

Sinon, vu que je viens de modifier mon fichier zone il y a environ 2 heures sans respecter les durées de vie des signatures de zones, dans les faits, il se passe quoi ?

Il se passe que tu dois ressigner, puis recharger ta zone. Mais il se passe aussi que la version précédente de ta zone est encore valide (jusqu'à la fin de la période DdVSig). Donc ca veut dire qu'il faut que tu planifie tout à l'avance. Entre autre les changement d'ip doivent être écrits et signés au moins une DdVSig à l'avance (voir plus) !

Citation : Cela fait bien une semaine que je procède ainsi et je n'ai jamais rien remarqué. Au bout d'un certain laps de temps, tout re-fonctionne... de mon point de vue du moins.

Ca doit être que la signature de ta zone a expiré. La zone n'est plus valide.

Citation :Où se situe le vrai problème si on re-crée un couple de clefs ZSK comme bon nous semble (en avance ou en retard par rapport au DvDSig) ?

J'ai une clé ZSK crée chaque mois. Elle est mise en zone et donc je suis sûr que quand on commence à l'utiliser (un mois plus tard), la zone sera valide. Dans le même temps la clé précédente reste dans la zone et est effacée au bout de la période DdVSig.

Citation :Exemple concret : Aujourd'hui, j'ai modifié mon fichier de zone sur la partie SPF, DKIM et DMARC. J'ai donc naturellement ré-créé un couple de clefs ZSK pour signer ce nouveau fichier de zone. Peut-être aurais-je dû garder l'ancien couple de clefs ZSK pour signer le nouveau fichier de zone ? Après tout ce semble tout aussi cohérent puisque cet ancien couple de clef était encore valide ! Quant à la DdVSig... aucune idée. Oui, ce n'est plus aussi clair qu'avant. Je vais y réfléchir.

C'est effectivement là que ca peche. T'as pas besoin de recréer une clé ZSK à chaque signature.

Citation :
Citation :Sinon bonne idée de générer tes clés sur un autre pc…

Bah j'ai bien dû trouver une alternative pour générer mes clefs ailleurs que sur OpenBSD.

Citation :Mais je pense que les signatures doivent se dérouler sur le serveur lui-même.

Pourquoi ? Pour la facilité de la mise en oeuvre de l'automatisationdu "roulement" des clefs je suppose. Si c'est le cas je suis d'accord mais il faut bien voir que cela prend des ressources sur la machine. J'avoue que j'ai du mal à accepter le fait que les clefs seront générées sur mon (petit) serveur... en production.

En fait, la génération des clés est assez légère. Tu as aussi des clés bien trop grosses. Durant ma première année j'ai eu des clés KSK de 4096. C'est beaucoup trop ! (songe que c'est aussi autant de temps de travail pour les validateurs !) Tes KSK peuvent être à 2048 et ZSK à 1024.

Citation :
Citation :Tiens, je viens de voir que ldns est dispo dans les ports d'OpenBSD ! On va pouvoir avoir des trucs plus récents.

Ok. Merci. Quelle version ? A priori, la version installée sur Debian est la plus récente (2008 il me semble). Donc cela devrait aussi être la dernière version sur OpenBSD. À vérifier !

Openbsd 6.1 stable, c'est la version 1.6.7. Current a la version 1.7.
Répondre
#12

Mettons que la signature des zones puisse se faire de manière hebdomadaire (en dehors des fois où tu édites la zone). La creation des ZSK pourrait etre mensuelle.

Tout ca pourrait être cronable. Resterait les KSK, que tu génerais à la main tous les ans ou tous les deux ans.
Répondre
#13

Ah je crois qu'il faut quand même que tu mettes à jour le numero de serie de la zone, contrairement à ce que je disais (parce qu'avec zkt t'as pas besoin, mais apparement ldns fait pas cette partie du job).
Répondre
#14

Ya ca aussi qui contient des scripts dont on peut s'inspirer (je dis on car je regarde moi meme depuis un moment à changer de système).

https://wiki.wsartori.com/wiki/The_Perfe...er_scripts
Répondre
#15

Citation : (je dis on car je regarde moi meme depuis un moment à changer de système)

Oui j'ai bien compris que tu étais aussi intéressé par une alternative à zkt. Je te sens motiver pour m'expliquer mais aussi pour trouver cette fameuse alternative. On sent bien que tu vis la "chose" depuis plus longtemps que moi. ;-) Je n'ai pas ton expérience dans le domaine mais les outils fournis par ldns me semblent corrects. Je corrige aussi une erreur ci-dessus : la dernière version de ldns date de décembre 2016 (version : 1.7) Je n'ai encore testé celle d'OpenBSD mais 'elle ne emble pas trop vieille

La je ressens le souci temporel lié à la rotation de deux clefs ZSK au niveau des caches de résolveurs mais c'est encore confus. Il me faut encore du temps. Il faut que je relise ce que tu as écrit mais il faut aussi que je lise d'autres écrits. Je fonctionne ainsi. A priori, à un moment donné, je vais avoir le déclic (j'espère). Là je sens un lien clair entre ta DdVSig et l'indicateur TTL du fichier de zone. Mais cela reste encore du ressenti. Il faut que je parvienne à visualiser tout cet enchaînement. (Je suis un visuel.)

Ressources :

http://www.bortzmeyer.org/7583.html

-> Y'a mieux comme schéma mais cet homme connait bien son sujet ! :-)

http://projets-ima.plil.net/mediawiki/in...formatique

-> franglais :-(... mais semble intéressant

http://www.guiguishow.info/2013/01/10/

-> le début de l'article

Wait, je lis, je réfléchis sur tout ce que je viens d'apprendre.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#16

Effectivement, la DdVSig se rapproche dans son fonctionnement du ttl. Les deux sont complémentaires disons (tu peux avoir des tt différents sur ta zone mais tu n'as qu'une seule DdVSig).
Répondre
#17

Allez un début d'automatisation : (testé sur FreeBSD)

gen-ksk.sh :

Code :
#!/bin/sh
DOMAIN=$1d &&
ZONE=zone.db
rm -rf ksk/ &&
mkdir ksk &&
ldns-keygen -a RSASHA256 -b 2048 -k $DOMAIN > ksk.txt &&
mv K* ksk/

gen-zsk.sh :

Code :
#!/bin/sh
DOMAIN=$1 &&
ZONE=zone.db &&
mkdir zsk &&
ldns-keygen -a RSASHA256 -b 1024 $DOMAIN > zsk.txt &&
mv K* zsk/

sign-zone.sh : (Remarque : changement du série de série à la main pour l'instant.)

Code :
#!/bin/sh
DOMAIN=$1 &&
ZONE=zone.db &&
EXPIR=20170819 && # 5 jours après le 14/08/2017 dans ton cas de figure : il s'agit d'un exemple
KSK=$(cat ksk.txt) &&
ZSK=$(cat zsk.txt) &&
ldns-signzone -e $EXPIR $ZONE ksk/$KSK zsk/$ZSK &&
ldns-key2ds -n -2 $ZONE.signed > $ZONE.hash

Je testerai sur mon système OpenBSD/Desktop.

Sinon, je cogite encore sur ce que j'ai appris hier. Question : Coment est géré le moment où deux clefs ZSK coexistent dans la zone (l'ancienne, la nouvelle) ? J'avoue ne pas comprendre comment d'un point de vue pratique cela est possible notamment avec le fichier de zone ? Le cas échéant, y a-t-il un "flags" particulier dans le fichier de zone signé pour faire apparaîter de façon distincte l'ancienne clef ZSK de la nouvelle ? A priori, je ne vois rien là dessus sur le Web.

Dès que l'on désire faire cette manipulation de rollover à la main (ou le scripter par soi-même), sur le Web, les documents (souvent anciens) et exhaustif sur le sujet parlent beaucoup "théorie" mais peu d'exemples pratiques sont présentés.

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#18

Tu dois pas encore supprimer les clés !
Répondre
#19

En fait, les rollover (KSK ou ZSK) impliquent d'avoir forcement les deux clés dans la zone à un moment ou un autre. Je vais expliquer ca :

Au jour zero, on crée une clé Y de durée de validité 2T+DdVSig, puis la zone est signée (avec la clé X).

Au bout du temps T, la clé X est dépreciée. La clé Y commence alors à signer la zone. Dans le même temps, on génère une nouvelle clé Z.
Au bout de T+DdVSig, on peut effacer la clé X, puisque ses signatures ont toutes expirées.
Au bout du temps 2T, la clé Y est dépréciée, la clé Z commence à être utilisée, une nouvelle cĺé est crée...

C'est la methode la plus simple. L'autre méthode est de générer les clés une période de DdVSig avant la fin de validité des clés précédentes. C'est un poil hasardeux.
Répondre
#20

Pour ceux que ça intéresse, j'ai ouvert un fil de discussion sur @misc : https://marc.info/?l=openbsd-misc&m=150278063319066&w=2
Répondre
#21

Merci thuban :-)

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#22

Donc, qu'en est-il de tes reflexions ?
Répondre
#23

Salut 22decembre :-)

Encore merci pour tes commentaires. :-)

Voici où j'en suis dans mes réflexions pour 1 cycle de rollover ZSK :

Sur une année : Définition d'une suite r (rollover) liée au choix du Time To Live (TTL ZSK = t = entier naturel compris entre 1 et 3 ?!) d'une clef ZSK :

r : |N --> |N
n |-> r(n)=nt

Définitions : n étant un entier naturel strictement supérieur à 1

z(n) = clef ZSK numéro n
f(n) = numéro de série n du fichier de zone (incrémentation de 1 !)

Mes choix :

t = "TTL" ZSK = 2 mois
d = DdVSig = 5 j (comme toi !)

Remarques :
- d permet de "translater" la durée de vie d'une clef pendant que la nouvelle clef est mise en place.
- Au bout de t (mois) + d (jours) :
(a) un résolveur sait que la clef est désormais obsolète. Pourquoi ? Parce que cette information est contenue dans la signature de cette clef ! Le cas échéant, le résolveur va formuler une nouvelle demande. Et la réponse à sa question sera signée par la nouvelle clef mise en production d jours auparavant !
(b) l'ancienne clef = poubelle !

Autrement dit, voici le cas général

r(0)=0 ; r(1)=t ; r(2)=2t ; r(3)=3t ; r(4)=4t ; r(5)=5t ; r(6)=6t ; r(7)=7t ; ...

et avec mes choix (t=2) sur une année

r(0)=0 ; r(1)=2 ; r(2)=4 ; r(3)=6 ; r(4)=8 ; r(5)=10 ; r(6)=12

Remarque : r(6)=12 -> gestion supplémentaire du rollover de la clef KSK (à anticiper comme le ZSK je suppose)


d d
<---> <---> etc...
|-----------------------------------|-----[-----------------------------|-----[-----------------------------|
r(n) r(n+1) r(n+2)

Au début (cas général) :
d d
<---> <---> etc...
|-----------------------------------|-----[-----------------------------|-----[-----------------------------|
r(0)=0 r(1)=t r(2)=2t

et avec mes choix :

5j 5j
<---> <---> etc...
|-----------------------------------|-----[-----------------------------|-----[-----------------------------|
r(0)=0 r(1)=2 r(2)=4
(mois) (mois)

Voici la chronologie avec mes choix :

r(0) : (étape n°1 du rollover : initialisation)

- f(1) créé
- z(1) créée et mise en production :
-> Durée de vie = t+d
-> z(1) signe le fichier de zone f(1)
- z(2) créée et mise en attente
-> Durée de vie = 2t+d (= Durée de vie de z(1) + t)

r(1) : (étape n°2 du rollover : changement de clef)

- z(1) rendue obsolète
- f(2) créé (numéro de série incrémenté de 1 avec des modifications éventuelles des enregistrements contenus dans le fichier de zone)
- z(2) mise en production :
-> Durée de vie = t+d
-> z(2) signe le fichier de zone f(2)
- z(3) créée et mis en attente
-> Durée de vie = 2t+d (= Durée de vie de z(2) + t)

r(1) + d : (étape n°3 du rollover : rappel d=5 j)

-z(1) mise hors service (traduction : poubelle !)

r(2) : (étape n°4 du rollover : voir l'étape n°2)

- z(2) rendue obsolète
- f(3) créé (numéro de série incrémenté de 1 avec des modifications éventuelles des enregistrements contenus dans le fichier de zone)
- z(3) mise en production :
-> Durée de vie = t+d
-> z(3) signe le fichier de zone f(3)
- z(4) créée et mise en attente
-> Durée de vie = 2t+d (= Durée de vie de z(3) + t)

etc...

Cas "général" d'un cycle d'un rollover en 3 étapes (sauf initialisation) :

r(n) : (étape n°1 du rollover)

- z(n) rendue obsolète
- f(n+1) créé (numéro de série incrémenté de 1 avec des modifications éventuelles des enregistrements contenus dans le fichier de zone)
- z(n+1) mise en production :
-> Durée de vie = t+d
-> z(n+1) signe le fichier de zone f(n+1)
- z(n+2) créée et mise en attente
-> Durée de vie = 2t+d (= Durée de vie de z(n+1) + t)

r(n) + d : (étape n°2 du rollover)

-z(n) mise hors service (traduction : poubelle !)

r(n+1) : (étape n°3 du rollover)

- z(n+1) rendue obsolète
- f(n+2) créé (numéro de série incrémenté de 1 avec des modifications éventuelles des enregistrements contenus dans le fichier de zone)
- z(n+2) mise en production :
-> Durée de vie = t+d
-> z(n+2) signe le fichier de zone f(n+2)
- z(n+3) créée et mise en attente
-> Durée de vie = 2t+d (= Durée de vie de z(n+2) + t)


Es-tu d'accord ?

Là il faut que je réfléchisse sur le rollover KSK/ZSK au bout d'une année !

NB : Le déclic : En lisant tes dernières explications*, j'ai compris qu'un résolveur connaissait la date d'expiration d'une signature d'une clef. C'est ce passage qui me bloquait. Il y a encore quelques minutes, je n'avais pas saisi le mécanisme qui faisait que tous les résolveurs allaient en même temps mettre à jour leur cache. Là je pense avoir compris !

*Voici la phrase CLEF (;-)) dans tes explications qui m'a débloquée : "Au bout de T+DdVSig, on peut effacer la clé X, puisque ses signatures ont toutes expirées."

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#24

Bon si on veut encore être plus concis sur le cycle, ce serait plutôt (en excluant les étapes "exceptionnelles" d'initialisation du processus et du cumul avec le rollover des clefs KSK dans un an) :

d d d
... <---> <---> <---> etc...
----|-----[-----------------------------|-----[-----------------------------|-----[-----------------------------|
r(n-1) r(n) r(n+1)

r(n) : (étape n°1 du rollover)

- z(n) rendue obsolète
- f(n+1) créé (numéro de série incrémenté de 1 avec des modifications éventuelles des enregistrements contenus dans le fichier de zone)
- z(n+1) mise en production (créée en r(n-1)) :
-> Durée de vie = t+d
-> z(n+1) signe le fichier de zone f(n+1)
- z(n+2) créée et mise en attente
-> Durée de vie = 2t+d (= Durée de vie de z(n+1) + t)

r(n) + d : (étape n°2 du rollover)

-z(n) mise hors service (traduction : poubelle !)

Questions :

(1) Pourquoi ne pas effacer la clef z(n) à l'étape n°1 ? En effet, puisque la clef z(n+1) est désormais en service (et donc z(n) de fait HS) et que la clef z(n) expire d jours plus tard, il n'y pas de "risques" d'avoir une "collision" ! Nous nous sommes "protégés" avec la translation des d jours. Non ?
(2) Mais finalement le TTL initial du fichier de zone ne sert plus à rien si TTL > t+d ?!

Un OS pour les gouverner tous (FreeBSD), un jail pour les trouver (Unbound)
Un filesystem pour les amener tous et dans les ténèbres les lier (ZFS) ;)
Répondre
#25

La mise à jour du cache ne va pas se faire massivement d'un coup d'un seul.

Mais tu as grosso modo compris. Tu as surtout compris l'importance du facteur temps et de faire les choses sans se gourrer ni rien oublier (j'espère).

Pense pas trop au rollover KSK...
Répondre


Sujets apparemment similaires…
Sujet / Auteur Réponses Affichages Dernier message

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)