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