Sincronizza automaticamente tutte le zone tra BIND 9


9

Esiste un modo per sincronizzare automaticamente tutte le zone tra i server BIND (9) in modo da non dover aggiungere zone allo slave quando le aggiungo al master?


1
oltre ad aggiungerli manualmente a named.conf, non vedo altro; se è quello che hai chiesto
quaie

Risposte:


12

Guarda BIND 9.7.2-P2 in cui hai le istruzioni "rndc addzone" e "rndc delzone" che ti consentono di aggiungere e rimuovere "in remoto" le zone da un server in esecuzione.

Ho un documento che fornisce alcuni esempi che ho dato a NANOG il mese scorso.

ftp://ftp.isc.org/isc/pubs/pres/NANOG/50/DNSSEC-NANOG50.pdf

Anche se questo non tornerà indietro e ripulirà qualsiasi pasticcio che hai attualmente, rende davvero facile sincronizzare le macchine che puoi gestire usando "rndc" in futuro.

[sì, rispondendo a un post piuttosto vecchio, ma BIND 9.7.2-P2 è abbastanza interessante da giustificarlo]

Aggiungendo un altro aggiornamento (anni dopo il fatto, ma sperando che aiuti le persone che si imbattono in questo nei risultati di ricerca), vorrei raccomandare l'uso delle zone del catalogo.

Le zone del catalogo, introdotte in BIND 9.11 (2018), consentono il provisioning automatico delle zone (aggiunta ed eliminazione) attraverso una zona speciale condivisa tra i server primario e secondario.

Per informazioni complete, consultare: https://kb.isc.org/docs/aa-01401


Quando promuovi il software a cui sei associato, includi alcuni riferimenti a tale fatto (anche se il software è gratuito). Grazie e benvenuti a Server Fault.
Chris S,

Sì, lavoro per ISC, i ragazzi che mantengono BIND e ISC DHCP. :)
Knobee

4

Non so come fare in modo nativo per legare9 se stai usando backend flatfile. Esistono vari sistemi supportati da DB che possono aiutare ad automatizzarlo. Oppure puoi copiarlo:

Popolo un file di testo con un elenco di zone e l'IP NS primario per la zona e lo inserisco in un sito Web a cui consento l'accesso ai miei schiavi. Gli slave recuperano periodicamente questo file e, se è cambiato, lo analizzano generano un named.conf e dicono a bind di ricaricare le configurazioni. È "automatico", nel senso che non devo inviare ssh manualmente ai miei secondari e aggiornare le configurazioni, ma è ancora esterno a bind9.

È inoltre possibile utilizzare un sistema di gestione della configurazione di livello superiore come un pupazzo , per gestire l'intera infrastruttura DNS. È un po 'più complicato però.


1
+1 - Uso una tecnica simile (ma probabilmente meno efficiente) e sembra funzionare in modo affidabile. Per ottenere una rapida propagazione agli schiavi di nuove modifiche, è necessario interrogare frequentemente il documento principale (ho riscontrato che ogni dieci minuti è più che abbastanza frequente).
David Spillett,

Prima di ottenere le doppie religioni di automazione e Tinydns, avevo uno script che analizzava la lista di configurazione delle zone del master per ottenere l'elenco delle zone, che ho esposto tramite inetd, e quindi uno script sugli slave che eseguiva il polling di un numero qualsiasi di IP master indirizzi (e hanno usato quell'indirizzo come indirizzo IP principale nelle loro configurazioni slave). Ha funzionato un sogno.
womble

4

Forse stai cercando un sistema di gestione della configurazione come Puppet o CFEngine? Ci sono infrastrutture extra coinvolte, ma possono gestire la distribuzione di molte cose di configurazione e potrebbero facilmente includere anche questo.


2

Il legame stesso non può farlo. Più precisamente, sarebbe indesiderabile farlo. Esistono molte situazioni in cui solo determinati domini devono essere replicati con un dato slave.


Ora pare che BIND possa, vedi la risposta di @ Knobee.
Volker Stolz,

@mad_vs - Grazie, altrimenti non avrei visto quella risposta.
John Gardeniers,

1

L'uso di rsync sull'intero albero / var / named funziona abbastanza bene se scrivi correttamente le tue zone e assicurati che named.conf risieda in / var / named. Tuttavia, non funzionerà con gli aggiornamenti dinamici, ed è in qualche modo contrario a "come dovrebbero essere fatte le cose".

Ho anche sperimentato il riempimento di tutti i domini per propagarli in una zona speciale e ho usato un semplice script sugli slave per ricostruire il nome.conf in base a ciò che vedono nella zona principale. Fondamentalmente lo stesso affare del file di testo sopra, ma alimentandolo dal DNS per mantenere tutto in banda. Probabilmente dovrei pubblicare lo script prima di finire per perderlo = /

Ai giorni in cui tutti e la loro mamma avevano i loro domini, mi sorprende che non ci sia una buona soluzione per questo integrata con Bind ormai = /


0

I secondo (o terzo) i suggerimenti di cui sopra per controllare Puppet o CFEngine. Inoltre, potresti esaminare il controllo dei tuoi file dentro e fuori CVS / SVN. Se sei interessato a una soluzione di scripting, ecco cosa uso:

#!/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

i tasti ssh sono piuttosto essenziali per questa configurazione. Non rivendico straordinari poteri di scripting, quindi sentiti libero di criticare, ma sii gentile.


0

Per la quantità di zone che ho, la sincronizzazione manuale è risultata più semplice che far funzionare qualsiasi altra soluzione. Se avessi molte più zone esaminerei le soluzioni proposte.


0
  1. Crea uno script per estrarre tutti i nomi dei file di zona dal master (ls -1 farà la maggior parte di questo).
  2. Crea uno script sullo slave che prenderà l'elenco dei file di zona come input e crei un nome.conf.local da tale elenco (la formattazione è piuttosto semplice) e sostituisci il nome.conf.local esistente (puoi usarne un altro name e includilo da named.conf.local se vuoi giocare in sicurezza)
  3. creare un accesso sudo senza password a comando singolo per "rndc ricaricare" sullo slave.
  4. Crea una chiave ssh monouso che ti permetta di inviare la lista delle zone dal master e di inoltrarla nello script slave e quindi eseguire "sudo rndc reload". Ora puoi spingere le zone dal master allo slave.
  5. (facoltativo) crea un lavoro cron per inviare quotidianamente le zone o qualsiasi altra cosa.

Buona esperienza, risolvendolo. Posso pubblicare i miei script, se qualcuno li desidera.


@ naught101, puoi pubblicare gli script per favore?

0

Questo è un codice php che il server master può eseguire per creare un elenco. Le opzioni quindi potrebbero essere quelle di caricarlo su un DB o gli altri server DNS possono trasferirlo su http / s.

Il server principale può eseguire questo:

$dir = "/var/lib/bind";
$files = scandir($dir);
foreach($files as $file) {
    $zoneparts = explode(".hosts", $file);
   if(count($zoneparts) > 1){
       echo $zoneparts[0] . "\r\n";
   }
}

Il server slave può eseguire questo:

$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);
}}

}

La directory "zone" dovrà essere scrivibile

Quindi crea uno script bash come questo:

#!/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

Quindi crea un chronjob come root (crontab -e):

*/10 * * * * /home/bob/dns_sync.sh
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.