Автоматически синхронизируйте все зоны между BIND 9

Я не знаю ни о каком способе сделать это исходно к bind9, если Вы используете бэкенд плоского файла. Существуют различные поддержанные DB системы, которые могут помочь автоматизировать его. Или можно написать сценарий его:

Я заполняю текстовый файл со списком зон и основного IP NS для зоны, и прикрепляю его на веб-сайт, к которому я предоставляю свой ведомый доступ. Ведомые устройства периодически выбирают этот файл, и если он изменился, они анализируют его, генерируют named.conf и говорят, связывают для перезагрузки конфигураций. Это "автоматически" в том смысле, что я не имею к вручную ssh к моим вторичным устройствам и обновляю конфигурации, но это является все еще внешним к bind9.

Вы могли также использовать высокоуровневую систему управления конфигурацией, такую как марионетка, для управления всей инфраструктурой DNS. Это немного более сложно все же.

Возможно, Вы ищете систему управления конфигурацией как Марионетка или CFEngine? Существует дополнительная включенная инфраструктура, но они могут обработать распределение большого количества материала конфигурации и могли легко включать это также.

Свяжите себя, не может сделать этого. Главное, это был бы нежелательный, чтобы иметь его, делают так. Существует много ситуаций, где только определенные домены должны копироваться с любым данным ведомым устройством.

Используя rsync на Ваших всех/var/named работах дерева вполне прилично, если Вы пишете свои зоны правильно и удостоверяетесь жизни named.conf в/var/named. Это не будет работать с динамическими обновлениями, хотя, и вид против мелкой частицы для, "как вещи должны быть сделаны".

Я также экспериментировал с наполнением всех доменов для распространения в специальную зону и использовал простой сценарий на ведомых устройствах для восстановления named.conf на основе того, что они видят в основной зоне. В основном то же соглашение как текстовый файл выше, но питание его от DNS для хранения всего внутриполосным. Я должен, вероятно, опубликовать сценарий, прежде чем я закончу тем, что терял его = /

В эпоху всех и их мамы, имеющей их собственные домены, меня удивляет, что нет хорошего решения для интегрированного с, Связывают к настоящему времени = /

Я второй (или треть) вышеупомянутые предложения для проверки Марионетки или CFEngine. Кроме того, Вы могли посмотреть на проверку Ваших файлов в и из CVS/SVN. Если Вы интересуетесь решением для сценариев, вот то, что я использую:

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

ключи ssh довольно важны для этой установки. Я не требую экстраординарных полномочий сценариев-fu, поэтому не стесняйтесь подвергнуть критике, но быть нежными.

1. Создайте сценарий для разрыва, все зональные имена файлов от ведущего устройства (ls-1 сделает большую часть из этого).
2. Создайте сценарий на ведомом устройстве, которое возьмет список зональных файлов, как введено, и создавать named.conf.local из того списка (форматирование довольно просто), и замените существующий named.conf.local (можно использовать другое имя и включать его от named.conf.local, если Вы хотите избежать рискованных действий),
3. создайте единственную команду sudo доступ без пароля для "rndc перезагрузка" на ведомом устройстве.
4. Создайте единственное использование ssh ключ, который позволяет Вам отправлять список зон от ведущего устройства, и передавать его по каналу в ведомый сценарий и затем работать "sudo rndc перезагрузка". Можно теперь продвинуть зоны от ведущего устройства к ведомому устройству.
5. (дополнительно) создайте задание крона для продвижения зон ежедневно, или что когда-либо.

Хороший опыт, разрабатывая это. Я могу отправить свои сценарии, если кто-либо хочет их.

Взгляд на BIND, 9.7.2-P2, в котором Вы имеете "rndc addzone" и "rndc delzone" операторы, которые позволяют Вам "удаленно" добавлять и удалять зоны из рабочего сервера.

У меня есть статья, которая обеспечивает некоторые примеры, которые я дал в NANOG в прошлом месяце.

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

В то время как это не возвратится и очистит любую путаницу, которую Вы в настоящее время имеете, она действительно делает действительно легким синхронизировать машины, что Вы можете справиться с использованием "rndc" продвижение.

[да, ответ на довольно старое сообщение, но 9.7.2-P2 BIND достаточно прохладен для гарантирования его]

Это некоторый код php, который главный сервер может запустить для создания списка. Затем варианты могут заключаться в том, чтобы загрузить его в БД, или другие DNS-серверы могут перетащить его через http / s.

Главный сервер может запускать это:

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

Подчиненный сервер может запускать это:

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

}

Директория "зоны" будет должен быть доступен для записи

Затем создайте сценарий bash следующим образом:

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

Затем создайте задание хронирования с правами root (crontab -e):

*/10 * * * * /home/bob/dns_sync.sh