Serveur DNS qui fait autorité et logiciel de contrôle - GuiGui's Show - Liens
vendredi 9 mai 2014 à 00:03 CAFAI, le 09/05/2014 à 00:03
Lorsqu'on est hébergeur DNS, on est souvent amené à ajouter/supprimer une zone et/ou à modifier le contenu desdites zones "automatiquement" via une interface web mise à la disposition du client/membre/...
C'est dans ce cas d'usage qu'un logiciel de contrôle pour le serveur de nom aide en permettant l'ajout, le retrait de zones et la prise en compte des modifications dans un fichier de zone, à la volée, à partir d'une simple ligne de commande.
Parmi les logiciels qui permettent de monter un serveur qui fait autorité les plus connus :
BIND est équipé de rndc
NSD est équipé de nsd-control *à partir de sa version 4*
knot est équipé de knotc ...
Quel serveur de nom choisir ? Voici quelques pistes :
- BIND est un fourre-tout monolithique qui mélange les rôles (serveur récursif-cache et serveur qui fait autorité) ce qui n'est pas sain. Knot est pour l'instant exclusivement un serveur qui fait autorité. Mais ajouter la fonctionnalité récursif-cache est en projet. Donc NSD est à considérer.
- rndc (BIND) est complet : on ajoute une zone, on la supprime, des commandes sont prévues pour tout ça. nsd-control aussi. knotc impose de modifier manuellement le fichier de configuration pour ajouter/supprimer la prise en charge d'une zone puis de faire relire la conf' (knotc reload), ce qui s'avère dommage : l'ajout est facile, la suppression plus difficile (chercher la zone concernée dans un fichier texte et la supprimer quand elle est en plein milieu) ou crade (regénérer tout le fichier de conf' à chaque suppression). BIND et NSD ont un avantage.
NSD et knot sont légers aux niveaux des dépendances à la compilation.
C'est aussi dans ce cas d'usage que l'on regrette qu'il n'y ait pas de protocole normalisé à l'IETF d'échange de la configuration entre serveurs DNS (comme un transfert de zones mais pour la configuration). C'est une plaie de modifier les maîtres puis ensuite les esclaves en utilisant les logiciels de contrôle propre à chaque logiciel ... Cette normalisation est un vieux projet : 2006 - Nameserver Communication Protocol - voir http://www.bortzmeyer.org/ncp-first-draft.html jugé trop prématuré (pas assez discuter des problèmes que l'on cherche à résoudre) donc renvoyé à une design team puis 2011 - RFC 6168 - voir http://www.bortzmeyer.org/6168.html qui pose enfin le cahier des charges ... À voir si ça va aboutir un jour ...
(Permalink)
Lorsqu'on est hébergeur DNS, on est souvent amené à ajouter/supprimer une zone et/ou à modifier le contenu desdites zones "automatiquement" via une interface web mise à la disposition du client/membre/...
C'est dans ce cas d'usage qu'un logiciel de contrôle pour le serveur de nom aide en permettant l'ajout, le retrait de zones et la prise en compte des modifications dans un fichier de zone, à la volée, à partir d'une simple ligne de commande.
Parmi les logiciels qui permettent de monter un serveur qui fait autorité les plus connus :
BIND est équipé de rndc
NSD est équipé de nsd-control *à partir de sa version 4*
knot est équipé de knotc ...
Quel serveur de nom choisir ? Voici quelques pistes :
- BIND est un fourre-tout monolithique qui mélange les rôles (serveur récursif-cache et serveur qui fait autorité) ce qui n'est pas sain. Knot est pour l'instant exclusivement un serveur qui fait autorité. Mais ajouter la fonctionnalité récursif-cache est en projet. Donc NSD est à considérer.
- rndc (BIND) est complet : on ajoute une zone, on la supprime, des commandes sont prévues pour tout ça. nsd-control aussi. knotc impose de modifier manuellement le fichier de configuration pour ajouter/supprimer la prise en charge d'une zone puis de faire relire la conf' (knotc reload), ce qui s'avère dommage : l'ajout est facile, la suppression plus difficile (chercher la zone concernée dans un fichier texte et la supprimer quand elle est en plein milieu) ou crade (regénérer tout le fichier de conf' à chaque suppression). BIND et NSD ont un avantage.
NSD et knot sont légers aux niveaux des dépendances à la compilation.
C'est aussi dans ce cas d'usage que l'on regrette qu'il n'y ait pas de protocole normalisé à l'IETF d'échange de la configuration entre serveurs DNS (comme un transfert de zones mais pour la configuration). C'est une plaie de modifier les maîtres puis ensuite les esclaves en utilisant les logiciels de contrôle propre à chaque logiciel ... Cette normalisation est un vieux projet : 2006 - Nameserver Communication Protocol - voir http://www.bortzmeyer.org/ncp-first-draft.html jugé trop prématuré (pas assez discuter des problèmes que l'on cherche à résoudre) donc renvoyé à une design team puis 2011 - RFC 6168 - voir http://www.bortzmeyer.org/6168.html qui pose enfin le cahier des charges ... À voir si ça va aboutir un jour ...
(Permalink)