Le 10 mai 2018 à 15:14, Gabriel Detraz <detraz(a)crans.org&gt; a écrit : Ploc à tous, Pour gérer dnssec avec re2o, on a fait des tests avec 5-1, globalement re2o marche avec knot ou bind pour gérer des zones dns. En ce qui concerne DNSEC, il apparait que utiliser knot est beaucoup plus simple, je vous explique pourquoi. Evidemment peut-être que des éléments plus subtils m’ont échappé. Avec bind, il faut générer les clefs avec une commande pour chaque zone, puis ensuite lancer une commande sur le fichier de zone à chaque fois qu’on le modifie pour le signer, cf https://www.skyminds.net/serveur-dedie-mettre-en-place-dnssec-pour-securi... <https://www.skyminds.net/serveur-dedie-mettre-en-place-dnssec-pour-securi... . Du coup il est nécessaire d’avoir un bout de re2o-tools qui s’occupe de lancer la commande à chaque fois qu’on regen la zone. Avec knot, c’est beaucoup plus simple, cf https://www.swordarmor.fr/gestion-automatique-de-dnssec-avec-knot.html <https://www.swordarmor.fr/gestion-automatique-de-dnssec-avec-knot.html> . Il suffit d’ajouter dnssec-signing: on et dnssec-policy: default dans la zone, knot s’occupe alors de générer la clef. Il reste juste à récup la DNSKEY et la publier chez gandi/ovh/whatever. A mon avis, knot simplifie grandement le process et ne nécessite pas d’avoir un script re2o (ou autres) pour resigner la zone à chaque fois. Qu’en pensez-vous ? — Chirac

Depuis bind 9.7 bind signe la zone tout seul et depuis 9.9 (cette version est dans jessie) le processus est complètement transparent vis a vis du fichier de zone. Tu modifie le fichier de zone comme si la zone n'etait pas signée et bind s'occupe tout seul de publier ou retirer les clefs et de signer ou re-signer la zone quand il y en à besoin. Il faut juste effectivement générer les clefs a intervalle regulier (ou en avance) pour assurer la rotation des ksk ou des zsk. https://github.com/nitmir/bind-dnssec s'occupe de generer les clefs automatiquement par exemple. le lien que tu donnes pour bind est complètement outdated, sauf si tu veux garder les clefs hors ligne, auquel cas, bind ne peut pas signer la zone tout seul vu qu'il n'a pas accès aux clefs. C'est dommage que ton lien sur knot ne parle pas de la rotation des ksk, c'est la seule opération apres la configuration initiale encore non automatisable dans la gestion de dnssec... Le 10 mai 2018 15:14:37 GMT+02:00, Gabriel Detraz <detraz(a)crans.org&gt; a écrit : > > Ploc à tous, > > Pour gérer dnssec avec re2o, on a fait des tests avec 5-1, globalement > re2o marche avec knot ou bind pour gérer des zones dns. > > En ce qui concerne DNSEC, il apparait que utiliser knot est beaucoup plus > simple, je vous explique pourquoi. Evidemment peut-être que des éléments > plus subtils m’ont échappé. > > Avec bind, il faut générer les clefs avec une commande pour chaque zone, > puis ensuite lancer une commande sur le fichier de zone à chaque fois qu’on > le modifie pour le signer, cf https://www.skyminds.net/ > serveur-dedie-mettre-en-place-dnssec-pour-securiser-les-dns-du-domaine/ . > Du coup il est nécessaire d’avoir un bout de re2o-tools qui s’occupe de > lancer la commande à chaque fois qu’on regen la zone. > > > Avec knot, c’est beaucoup plus simple, cf https://www.swordarmor.fr/ > gestion-automatique-de-dnssec-avec-knot.html . Il suffit d’ajouter dnssec-signing: > on et dnssec-policy: default dans la zone, knot s’occupe alors de > générer la clef. Il reste juste à récup la DNSKEY et la publier chez > gandi/ovh/whatever. > > > A mon avis, knot simplifie grandement le process et ne nécessite pas > d’avoir un script re2o (ou autres) pour resigner la zone à chaque fois. > Qu’en pensez-vous ? > > > — > Chirac > > > -- Valentin Samir _______________________________________________ Re2o mailing list Re2o(a)federez.net https://lists.federez.net/listinfo/re2o