Synchronisez automatiquement toutes les zones entre BIND 9
9
Existe-t-il un moyen de synchroniser automatiquement toutes les zones entre les serveurs BIND (9) afin de ne pas avoir à ajouter de zones à l'esclave lorsque je les ajoute au maître?
à part les ajouter manuellement à named.conf, je ne vois pas d'autre moyen; si c'est ce que vous avez demandé
quaie
Réponses:
12
Regardez BIND 9.7.2-P2 dans lequel vous avez les instructions "rndc addzone" et "rndc delzone" qui vous permettent d'ajouter et de supprimer "à distance" des zones d'un serveur en cours d'exécution.
J'ai un article qui donne quelques exemples que j'ai donnés au NANOG le mois dernier.
Bien que cela ne revienne pas en arrière et ne nettoie aucun désordre que vous avez actuellement, cela facilite vraiment la synchronisation des machines que vous pouvez gérer à l'aide de "rndc" à l'avenir.
[oui, répondant à un message plutôt ancien, mais BIND 9.7.2-P2 est assez cool pour le justifier]
Ajoutant encore une autre mise à jour (des années après le fait, mais en espérant que cela aide les gens qui traversent cela dans les résultats de recherche), je voudrais recommander l'utilisation des zones de catalogue.
Les zones de catalogue, introduites dans BIND 9.11 (2018) permettent le provisionnement automatique des zones (ajout et suppression) via une zone spéciale partagée entre les serveurs principal et secondaire.
Lors de la promotion d'un logiciel auquel vous êtes associé, veuillez inclure une référence à ce fait (même si le logiciel est gratuit). Merci et bienvenue sur Server Fault.
Chris S
Oui, je travaille pour ISC, les gars qui maintiennent BIND et ISC DHCP. :)
Knobee
4
Je ne connais aucun moyen de le faire nativement pour bind9 si vous utilisez un backend de fichier plat. Il existe différents systèmes basés sur DB qui peuvent aider à l'automatiser. Ou vous pouvez l'écrire:
Je remplis un fichier texte avec une liste de zones et l'IP NS principal de la zone, et je le colle sur un site Web auquel j'autorise mes esclaves à accéder. Les esclaves récupèrent ce fichier périodiquement, et s'il a changé, ils l'analysent génèrent un nommé.conf, et disent à bind de recharger les configurations. C'est "automatique" dans le sens où je n'ai pas besoin de ssh manuellement pour mes secondaires et de mettre à jour les configurations, mais c'est toujours externe pour bind9.
Vous pouvez également utiliser un système de gestion de configuration de niveau supérieur tel que marionnette , pour gérer l'intégralité de votre infrastructure DNS. C'est un peu plus compliqué cependant.
+1 - J'utilise moi-même une technique similaire (mais probablement moins efficace) et elle semble fonctionner de manière fiable. Pour obtenir une propagation rapide vers les esclaves des nouveaux changements dont ils ont besoin pour interroger fréquemment le document maître (j'ai trouvé que toutes les dix minutes étaient plus que suffisamment fréquentes).
David Spillett
Avant d'avoir les deux religions d'Automation et de Tinydns, j'avais un script qui analysait la liste de configuration des zones du maître pour obtenir la liste des zones, que j'exposais via inetd, puis un script sur les esclaves qui interrogeait n'importe quel nombre d'IP maître adresses (et utilisé cette adresse comme adresse IP maître dans leurs configurations esclaves). A travaillé un rêve.
womble
4
Vous cherchez peut-être un système de gestion de configuration comme Puppet ou CFEngine? Il y a une infrastructure supplémentaire impliquée, mais ils peuvent gérer la distribution de beaucoup de choses de configuration et pourraient facilement l'inclure également.
Lier lui-même ne peut pas le faire. Plus précisément, il ne serait pas souhaitable de le faire. Il existe de nombreuses situations où seuls certains domaines doivent être répliqués avec un esclave donné.
Maintenant, BIND peut apparemment, voir la réponse de @ Knobee.
Volker Stolz
@mad_vs - Merci, je n'aurais pas vu cette réponse autrement.
John Gardeniers
1
L'utilisation de rsync sur l'ensemble de votre arborescence / var / named fonctionne plutôt bien si vous écrivez correctement vos zones et assurez-vous que named.conf vit dans / var / named. Cela ne fonctionnera pas avec les mises à jour dynamiques cependant, et est en quelque sorte à contre-courant pour "comment les choses devraient être faites".
J'ai également expérimenté le bourrage de tous les domaines pour les propager dans une zone spéciale, et j'ai utilisé un simple script sur les esclaves pour reconstruire le named.conf en fonction de ce qu'ils voient dans la zone principale. Fondamentalement, le même accord que le fichier texte ci-dessus, mais en le nourrissant à partir du DNS pour garder tout dans la bande. Je devrais probablement publier le script avant de le perdre = /
À l'époque où tout le monde et sa maman avaient leurs propres domaines, cela me surprend qu'il n'y a pas de bonne solution pour cela intégré à Bind maintenant = /
J'appuie (ou troisième) les suggestions ci-dessus pour vérifier Puppet ou CFEngine. En outre, vous pouvez envisager de vérifier vos fichiers dans et hors de CVS / SVN. Si vous êtes intéressé par une solution de script, voici ce que j'utilise:
#!/bin/bash
DATE=`date +%Y-%m-%d`
archive='/root/dns'
cd $archive
[ $1 ] && DEBUG=$1
if [ "$DEBUG" == "-debug" ]; then
echo "Debugging activated..."
else
unset DEBUG
fi
for server in dnsm02 dnsm03 dnsm51 dnsm52; do
for file in named.conf named.cfx.conf named.external.conf named.internal.conf named.logging.conf named.options.conf; do
PATCHDIR="$archive/$server/$DATE/patch" && [ $DEBUG ] && echo "PATCHDIR = $PATCHDIR"
SRVDIR="$archive/$server/$DATE" && [ $DEBUG ] && echo "SRVDIR = $SRVDIR"
## Fetch bind config files from $server, put them in date stamped $archive/$server
[ ! -d $PATCHDIR ] && mkdir -p $PATCHDIR && [ $DEBUG ] && echo "Created archive directory"
scp -q user@$server:/etc/bind/$file $archive/$server/$DATE/$file && [ $DEBUG ] && echo "Copied remote $file from $server..."
## diff fetched file against template file and create a patch
[ $DEBUG ] && echo "Creating patch file..."
diff -u $SRVDIR/$file $archive/$server/$file > $PATCHDIR/patch.$file
[ ! -s $PATCHDIR/patch.$file ] && rm -f $PATCHDIR/patch.$file && [ $DEBUG ] && echo "no differences , no patch created for $server $file"
[ -s $PATCHDIR/patch.$file ] && patch $SRVDIR/$file $PATCHDIR/patch.$file && ssh user@$server "sudo scp user@dnsm01:$SRVDIR/$file /etc/bind/$file" && [ $DEBUG ] && echo "$file patched and uploaded"
done
[ $DEBUG ] && echo "Checking whether patch directory is empty..."
[ $(ls -1A $PATCHDIR | wc -l) -eq 0 ] && rmdir $PATCHDIR && [ $DEBUG ] && echo "$PATCHDIR empty, removing..."
ssh user@$server "sudo rndc reload"
done
Les clés ssh sont assez essentielles pour cette configuration. Je ne revendique pas de pouvoirs extraordinaires de scripting-fu, alors n'hésitez pas à critiquer, mais soyez doux.
Pour la quantité de zones dont je dispose, la synchronisation manuelle s'est avérée plus facile que de faire fonctionner une autre solution. Si j'avais plus de zones, j'examinerais les solutions proposées.
Créez un script pour extraire tous les noms de fichiers de zone du maître (ls -1 fera la plupart de cela).
Créez un script sur l'esclave qui prendra la liste des fichiers de zone en entrée, et créez un named.conf.local à partir de cette liste (le formatage est assez simple), et remplacez le named.conf.local existant (vous pouvez utiliser un autre nom, et incluez-le depuis named.conf.local si vous voulez jouer en toute sécurité)
créer un accès sudo sans mot de passe à commande unique pour "rndc reload" sur l'esclave.
Créez une clé ssh à usage unique qui vous permet d'envoyer la liste des zones à partir du maître, de la diriger vers le script esclave, puis d'exécuter "sudo rndc reload". Vous pouvez maintenant pousser les zones du maître vers l'esclave.
(facultatif) créez un travail cron pour pousser les zones quotidiennement ou quoi que ce soit.
Bonne expérience, cela fonctionne. Je peux poster mes scripts, si quelqu'un le veut.
@ naught101, pouvez-vous publier les scripts s'il vous plait?
0
Il s'agit d'un code php que le serveur maître peut exécuter pour créer une liste. Les options pourraient alors être de le télécharger sur une base de données ou les autres serveurs DNS peuvent le tirer sur http / s.
$zones = file(URL TO MASTER SERVER);
if($zones != ""){
$header = "// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
";
file_put_contents("/var/www/html/zone/zones.txt", $header);
foreach($zones as $zone){
if($zone != "") {
$zone = preg_replace('~[[:cntrl:]]~', '', $zone);
$config = 'zone "' . $zone.'" {
type slave;
masters {lemming; };
allow-transfer {none; };
file "/var/lib/bind/db.'.$zone.'";
};
';
file_put_contents('/var/www/html/zone/zones.txt', $config, FILE_APPEND);
}}
}
Le répertoire "zone" devra être accessible en écriture
Créez ensuite un script bash comme celui-ci:
#!/bin/bash
php /var/www/html/index.php
cp /var/www/html/zone/zones.txt /etc/bind/named.conf
service bind9 restart
logger DNS Zones pulled from master and bind restarted /home/bob/dns_sync.sh
Créez ensuite un chronjob en tant que root (crontab -e):
Réponses:
Regardez BIND 9.7.2-P2 dans lequel vous avez les instructions "rndc addzone" et "rndc delzone" qui vous permettent d'ajouter et de supprimer "à distance" des zones d'un serveur en cours d'exécution.
J'ai un article qui donne quelques exemples que j'ai donnés au NANOG le mois dernier.
ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf
Bien que cela ne revienne pas en arrière et ne nettoie aucun désordre que vous avez actuellement, cela facilite vraiment la synchronisation des machines que vous pouvez gérer à l'aide de "rndc" à l'avenir.
[oui, répondant à un message plutôt ancien, mais BIND 9.7.2-P2 est assez cool pour le justifier]
Ajoutant encore une autre mise à jour (des années après le fait, mais en espérant que cela aide les gens qui traversent cela dans les résultats de recherche), je voudrais recommander l'utilisation des zones de catalogue.
Les zones de catalogue, introduites dans BIND 9.11 (2018) permettent le provisionnement automatique des zones (ajout et suppression) via une zone spéciale partagée entre les serveurs principal et secondaire.
Pour des informations complètes, voir: https://kb.isc.org/docs/aa-01401
la source
Je ne connais aucun moyen de le faire nativement pour bind9 si vous utilisez un backend de fichier plat. Il existe différents systèmes basés sur DB qui peuvent aider à l'automatiser. Ou vous pouvez l'écrire:
Je remplis un fichier texte avec une liste de zones et l'IP NS principal de la zone, et je le colle sur un site Web auquel j'autorise mes esclaves à accéder. Les esclaves récupèrent ce fichier périodiquement, et s'il a changé, ils l'analysent génèrent un nommé.conf, et disent à bind de recharger les configurations. C'est "automatique" dans le sens où je n'ai pas besoin de ssh manuellement pour mes secondaires et de mettre à jour les configurations, mais c'est toujours externe pour bind9.
Vous pouvez également utiliser un système de gestion de configuration de niveau supérieur tel que marionnette , pour gérer l'intégralité de votre infrastructure DNS. C'est un peu plus compliqué cependant.
la source
Vous cherchez peut-être un système de gestion de configuration comme Puppet ou CFEngine? Il y a une infrastructure supplémentaire impliquée, mais ils peuvent gérer la distribution de beaucoup de choses de configuration et pourraient facilement l'inclure également.
la source
Lier lui-même ne peut pas le faire. Plus précisément, il ne serait pas souhaitable de le faire. Il existe de nombreuses situations où seuls certains domaines doivent être répliqués avec un esclave donné.
la source
L'utilisation de rsync sur l'ensemble de votre arborescence / var / named fonctionne plutôt bien si vous écrivez correctement vos zones et assurez-vous que named.conf vit dans / var / named. Cela ne fonctionnera pas avec les mises à jour dynamiques cependant, et est en quelque sorte à contre-courant pour "comment les choses devraient être faites".
J'ai également expérimenté le bourrage de tous les domaines pour les propager dans une zone spéciale, et j'ai utilisé un simple script sur les esclaves pour reconstruire le named.conf en fonction de ce qu'ils voient dans la zone principale. Fondamentalement, le même accord que le fichier texte ci-dessus, mais en le nourrissant à partir du DNS pour garder tout dans la bande. Je devrais probablement publier le script avant de le perdre = /
À l'époque où tout le monde et sa maman avaient leurs propres domaines, cela me surprend qu'il n'y a pas de bonne solution pour cela intégré à Bind maintenant = /
la source
J'appuie (ou troisième) les suggestions ci-dessus pour vérifier Puppet ou CFEngine. En outre, vous pouvez envisager de vérifier vos fichiers dans et hors de CVS / SVN. Si vous êtes intéressé par une solution de script, voici ce que j'utilise:
Les clés ssh sont assez essentielles pour cette configuration. Je ne revendique pas de pouvoirs extraordinaires de scripting-fu, alors n'hésitez pas à critiquer, mais soyez doux.
la source
Pour la quantité de zones dont je dispose, la synchronisation manuelle s'est avérée plus facile que de faire fonctionner une autre solution. Si j'avais plus de zones, j'examinerais les solutions proposées.
la source
Bonne expérience, cela fonctionne. Je peux poster mes scripts, si quelqu'un le veut.
la source
Il s'agit d'un code php que le serveur maître peut exécuter pour créer une liste. Les options pourraient alors être de le télécharger sur une base de données ou les autres serveurs DNS peuvent le tirer sur http / s.
Le serveur maître peut exécuter ceci:
Le serveur esclave peut exécuter ceci:
Le répertoire "zone" devra être accessible en écriture
Créez ensuite un script bash comme celui-ci:
Créez ensuite un chronjob en tant que root (crontab -e):
la source