#nsd

Utiliser OpenDNSSEC avec un serveur maître NSD

Gérer proprement #DNSSEC n’est pas trivial : un certain nombre d’opérations de gestion des clés et de renouvellement des signatures doivent se faire dans un ordre précis, à certains moments. Si on le fait à la main, une erreur ou un oubli est vite arrivé. D’où l’intérêt d’utiliser une solution logicielle qui automatise tout cela, en l’occurrence #OpenDNSSEC. Les exemples donnés dans la documentation sont pour un serveur DNS maître utilisant BIND. Et si on se sert de #NSD ?

http://www.bortzmeyer.org/opendnssec-nsd.html

NSD, un autre serveur de noms pour servir ses zones

La plupart des administrateurs système Unix qui installent un serveur #DNS mettent #BIND sans réflechir, non pas qu’ils aient étudié plusieurs serveurs et choisi celui-ci (BIND a des tas de qualités, notamment le record de la richesse fonctionnelle), mais simplement parce que l’idée du choix ne traverse même pas leur cerveau.

Pourquoi envisager #NSD comme alternative ? C’est un logiciel pour serveur faisant autorité, c’est-à-dire le serveur qui distribue directement le contenu des zones (par opposition aux résolveurs qui relaient les requêtes du client final vers les serveurs faisant autorité). Il est utilisé par plusieurs gros TLD comme .FR ou .DE, ainsi que par la racine (à chaque fois, sur une partie seulement des serveurs, pour les raisons indiquées plus haut). NSD a fait le choix de ne pas en faire trop, afin de rester simple et rapide (tous les tests indiquent des performances deux à trois fois meilleures que celles de BIND).

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