Bonjour à tous, Voici un petit topo sur DNSSEC by me: L'implémentation de DNSSEC permet une sécurisation des différentes zones DNS concernées ainsi que des différents échanges liés au protocol DNS. Cependant, cette implémentation à quelques inconvénients au niveau gestion DNS. L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif. Cette signature du fichier de zone doit être refait à chaque changement dans le fichier de zone originel. Il faut également gérer la durée de vie des clés ZSK et KSK. Il est possible de générer des clés sans durée de vie mais il est préférable d'ajouter une date afin de devoir les renouveller régulièrement (ZSK: tout les 3 mois, KSK: tout les ans). Les deux clés utilisées sont respectivement de 2048 et 4096 bits, donc assez longue à générer. Il est possible de générer les clés avec différents algorithmes en fonction de ce que l'on souhaite: RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256 or ECDSAP384SHA384 Si l'on veut une bonne sécurité: RSASHA512 ou NSEC3RSASHA1 avec une préférence pour le premier. Le choix de cet algorithme dépend aussi d'une donnée: les possibilités offertes au niveau dnssec par le provider. Je suis en train de le remettre en place de mon coté (passage de ovh vers gandi pour le registar). Je vais également voir pour faire un petit script en bash pour gérer les clés. Si vous avez des questions/observations/critiques, feu! Boris
Yop, Je me permets de up la chose, afin de savoir si vous êtes OK et si oui, si je peux commencer le déploiement. Le 9 janvier 2015 12:07, Boris Tassou <boris.tassou@gmail.com> a écrit :
Bonjour à tous,
Voici un petit topo sur DNSSEC by me:
L'implémentation de DNSSEC permet une sécurisation des différentes zones DNS concernées ainsi que des différents échanges liés au protocol DNS. Cependant, cette implémentation à quelques inconvénients au niveau gestion DNS. L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif. Cette signature du fichier de zone doit être refait à chaque changement dans le fichier de zone originel.
Il faut également gérer la durée de vie des clés ZSK et KSK. Il est possible de générer des clés sans durée de vie mais il est préférable d'ajouter une date afin de devoir les renouveller régulièrement (ZSK: tout les 3 mois, KSK: tout les ans).
Les deux clés utilisées sont respectivement de 2048 et 4096 bits, donc assez longue à générer. Il est possible de générer les clés avec différents algorithmes en fonction de ce que l'on souhaite: RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256 or ECDSAP384SHA384
Si l'on veut une bonne sécurité: RSASHA512 ou NSEC3RSASHA1 avec une préférence pour le premier. Le choix de cet algorithme dépend aussi d'une donnée: les possibilités offertes au niveau dnssec par le provider.
Je suis en train de le remettre en place de mon coté (passage de ovh vers gandi pour le registar). Je vais également voir pour faire un petit script en bash pour gérer les clés.
Si vous avez des questions/observations/critiques, feu!
Boris
On Thu Jan 15 15:20:27 2015, Boris TASSOU wrote:
Je me permets de up la chose, afin de savoir si vous êtes OK et si oui, si je peux commencer le déploiement.
Salut, Désolé pour le délai, je n’avais pas réussi à parser une des tes phrases, je m’étais dit que j’allais regarder à tête reposée. Seulement ton mail est passé à la trappe entre temps. La phrase était :
L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif.
(sa longueur n’aide pas) -- alarig
Salut, Pour info, un guide intéressant de l'afnic : http://www.afnic.fr/medias/documents/DNSSEC/afnic-dnssec-howto-fr-v2.pdf Manu Le 15 janv. 2015 à 15:20, Boris TASSOU a écrit :
Yop,
Je me permets de up la chose, afin de savoir si vous êtes OK et si oui, si je peux commencer le déploiement.
Le 9 janvier 2015 12:07, Boris Tassou <boris.tassou@gmail.com> a écrit : Bonjour à tous,
Voici un petit topo sur DNSSEC by me:
L'implémentation de DNSSEC permet une sécurisation des différentes zones DNS concernées ainsi que des différents échanges liés au protocol DNS. Cependant, cette implémentation à quelques inconvénients au niveau gestion DNS. L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif. Cette signature du fichier de zone doit être refait à chaque changement dans le fichier de zone originel.
Il faut également gérer la durée de vie des clés ZSK et KSK. Il est possible de générer des clés sans durée de vie mais il est préférable d'ajouter une date afin de devoir les renouveller régulièrement (ZSK: tout les 3 mois, KSK: tout les ans).
Les deux clés utilisées sont respectivement de 2048 et 4096 bits, donc assez longue à générer. Il est possible de générer les clés avec différents algorithmes en fonction de ce que l'on souhaite: RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256 or ECDSAP384SHA384
Si l'on veut une bonne sécurité: RSASHA512 ou NSEC3RSASHA1 avec une préférence pour le premier. Le choix de cet algorithme dépend aussi d'une donnée: les possibilités offertes au niveau dnssec par le provider.
Je suis en train de le remettre en place de mon coté (passage de ovh vers gandi pour le registar). Je vais également voir pour faire un petit script en bash pour gérer les clés.
Si vous avez des questions/observations/critiques, feu!
Boris
_______________________________________________ Grifon mailing list Grifon@grifon.fr http://lists.grifon.fr/mailman/listinfo/grifon
On Thu Jan 15 16:36:09 2015, Emmanuel Thierry wrote:
Pour info, un guide intéressant de l'afnic : http://www.afnic.fr/medias/documents/DNSSEC/afnic-dnssec-howto-fr-v2.pdf
Il est très intéressant ce howto, merci du lien :) -- alarig
Le 09/01/2015 12:07, Boris Tassou a écrit :
Bonjour à tous,
Voici un petit topo sur DNSSEC by me:
L'implémentation de DNSSEC permet une sécurisation des différentes zones DNS concernées ainsi que des différents échanges liés au protocol DNS. Cependant, cette implémentation à quelques inconvénients au niveau gestion DNS. L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif. Cette signature du fichier de zone doit être refait à chaque changement dans le fichier de zone originel.
Il faut également gérer la durée de vie des clés ZSK et KSK. Il est possible de générer des clés sans durée de vie mais il est préférable d'ajouter une date afin de devoir les renouveller régulièrement (ZSK: tout les 3 mois, KSK: tout les ans).
Le renouvellement me parait fréquent (plus fréquent que ce que j'ai pu voir en exemple en fait). Un quelque chose tout les 3 mois impliquerait, je pense, un "automate" de gestion des clefs (script, daemon, etc) ayant accès à la KSK pour générer de nouvelles ZSK. N'est-il pas préférable de garder un mode de fonctionnement "hors ligne" (d'un point de vue du serveur DNS) de la KSK et donc de renouveller les ZSK de manière moins fréquente. Pour se faire de "pousser" sur le serveur DNS des ZSK générées ailleurs[1] avec la KSK ? [1] Clef sur un repertoire / fichier chiffré, déchiffré par un utilisateur. Ou sur une autre machine, protégée pour cela.
Les deux clés utilisées sont respectivement de 2048 et 4096 bits, donc assez longue à générer. Il est possible de générer les clés avec différents algorithmes en fonction de ce que l'on souhaite: RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256 or ECDSAP384SHA384
Si l'on veut une bonne sécurité: RSASHA512 ou NSEC3RSASHA1 avec une préférence pour le premier. Le choix de cet algorithme dépend aussi d'une donnée: les possibilités offertes au niveau dnssec par le provider.
Dans quelques documentations que j'ai lu, j'ai entendu dire que RDASHA512 était pas supporté par tous les résolveurs et qu'il fallait lui préférer RSASHA256. Peut-être que ce que j'ai lu est périmé depuis ? Qu'est ce qui te fait pencher pour RSASHA512 ?
Je suis en train de le remettre en place de mon coté (passage de ovh vers gandi pour le registar). Je vais également voir pour faire un petit script en bash pour gérer les clés.
Pourquoi pas OpenDNSSEC ? Ou auto-dnssec ? Ou je dis une ânerie ?
Si vous avez des questions/observations/critiques, feu!
Boris _______________________________________________ Grifon mailing list Grifon@grifon.fr http://lists.grifon.fr/mailman/listinfo/grifon
Le 15 janv. 2015 à 19:48, gfa a écrit :
Le 09/01/2015 12:07, Boris Tassou a écrit :
Bonjour à tous,
Voici un petit topo sur DNSSEC by me:
L'implémentation de DNSSEC permet une sécurisation des différentes zones DNS concernées ainsi que des différents échanges liés au protocol DNS. Cependant, cette implémentation à quelques inconvénients au niveau gestion DNS. L'utilisation de DNSSEC passe par la création deux clés: ZSK et KSK. Ces dernière servent au chiffrement des fichiers de zones ainsi qu'à la communication avec le provider du ndd en effet, il est impératif de donner la clef présente dans le fichier de zone signé au registar pour que le dnssec soit effectif. Cette signature du fichier de zone doit être refait à chaque changement dans le fichier de zone originel.
Il faut également gérer la durée de vie des clés ZSK et KSK. Il est possible de générer des clés sans durée de vie mais il est préférable d'ajouter une date afin de devoir les renouveller régulièrement (ZSK: tout les 3 mois, KSK: tout les ans).
Le renouvellement me parait fréquent (plus fréquent que ce que j'ai pu voir en exemple en fait). Un quelque chose tout les 3 mois impliquerait, je pense, un "automate" de gestion des clefs (script, daemon, etc) ayant accès à la KSK pour générer de nouvelles ZSK. N'est-il pas préférable de garder un mode de fonctionnement "hors ligne" (d'un point de vue du serveur DNS) de la KSK et donc de renouveller les ZSK de manière moins fréquente. Pour se faire de "pousser" sur le serveur DNS des ZSK générées ailleurs[1] avec la KSK ?
[1] Clef sur un repertoire / fichier chiffré, déchiffré par un utilisateur. Ou sur une autre machine, protégée pour cela.
Les deux clés utilisées sont respectivement de 2048 et 4096 bits, donc assez longue à générer. Il est possible de générer les clés avec différents algorithmes en fonction de ce que l'on souhaite: RSAMD5, RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, RSASHA256, RSASHA512, ECCGOST, ECDSAP256SHA256 or ECDSAP384SHA384
Si l'on veut une bonne sécurité: RSASHA512 ou NSEC3RSASHA1 avec une préférence pour le premier. Le choix de cet algorithme dépend aussi d'une donnée: les possibilités offertes au niveau dnssec par le provider.
Dans quelques documentations que j'ai lu, j'ai entendu dire que RDASHA512 était pas supporté par tous les résolveurs et qu'il fallait lui préférer RSASHA256. Peut-être que ce que j'ai lu est périmé depuis ?
Qu'est ce qui te fait pencher pour RSASHA512 ?
Je suis en train de le remettre en place de mon coté (passage de ovh vers gandi pour le registar). Je vais également voir pour faire un petit script en bash pour gérer les clés.
Pourquoi pas OpenDNSSEC ? Ou auto-dnssec ? Ou je dis une ânerie ?
OpenDNSSEC ça marche très bien, c'est ce que j'utilise. Il y a juste à uploader les KSK sur l'interface de son registrar un peu avant expiration (et encore je pourrais le scripter), et même la possibilité d'uploader des clés supplémentaires en backup, c'est ultra-flexible. Par contre ça demande de *très* bien connaître les mécanismes de DNSSEC car toutes les opérations sont exposés à l'utilisateur. Je pense qu'auto-dnssec devrait être plus simple sur ce point (même si je ne l'ai pas essayé). Dans tous les cas je vous déconseille vivement de tout scripter vous même, sachant que des logiciels existent et le font très bien. Scripter tout ça, ça reviendrait à coder un wiki statique à base de git et RST alors que plein d'outils efficaces et faciles d'utilisation existent déjà ! ;) Manu
participants (5)
-
alarig -
Boris TASSOU -
Boris Tassou
-
Emmanuel Thierry -
gfa