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


9

Есть ли способ автоматически синхронизировать все зоны между серверами BIND (9), чтобы мне не нужно было добавлять зоны в ведомое устройство, когда я добавляю их в ведущее устройство?


1
кроме добавления их вручную в named.conf, я не вижу другого пути; если это то, что вы спросили
Quaie

Ответы:


12

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

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

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

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

[да, отвечая на довольно старый пост, но BIND 9.7.2-P2 достаточно крутой, чтобы это оправдать]

Добавляя еще одно обновление (спустя годы после этого, но надеясь, что оно поможет людям, которые сталкиваются с этим в результатах поиска), я бы рекомендовал использовать зоны каталога.

Зоны каталога, представленные в BIND 9.11 (2018), позволяют автоматическое предоставление зон (добавление и удаление) через специальную зону, которая является общей для первичного и вторичного серверов.

Для получения полной информации см .: https://kb.isc.org/docs/aa-01401


При продвижении программного обеспечения, с которым вы связаны, пожалуйста, включите некоторые ссылки на этот факт (даже если программное обеспечение бесплатное). Спасибо и добро пожаловать в Server Fault.
Крис С

Да, я работаю на ISC, ребята, которые поддерживают BIND и ISC DHCP. :)
Knobee

4

Я не знаю никакого способа сделать это изначально для bind9, если вы используете flatfile backend. Существуют различные системы с поддержкой БД, которые могут помочь автоматизировать это. Или вы можете написать это:

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

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


1
+1 - я использую подобную (но, вероятно, менее эффективную) технику самостоятельно, и, похоже, она работает надежно. Чтобы быстро распространять среди ведомых о новых изменениях, им нужно часто опрашивать главный документ (я обнаружил, что каждые десять минут это происходит более чем достаточно часто).
Дэвид Спиллетт

Еще до того, как я получил двойную религию автоматизации и Tinydns, у меня был скрипт, который анализировал список конфигурации зон мастера, чтобы получить список зон, который я открыл через inetd, а затем скрипт на ведомых, которые опрашивали любое количество мастер-IP. адреса (и использовали этот адрес в качестве главного IP-адреса в своих подчиненных конфигурациях). Работал мечтой.
womble

4

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


2

Привязать себя не могу. Более того, было бы нежелательно делать это. Есть много ситуаций, когда только определенные домены должны быть реплицированы с любым данным ведомым устройством.


Теперь, очевидно, BIND может увидеть ответ @ Knobee.
Volker Stolz

@mad_vs - Спасибо, иначе я бы не увидел этот ответ.
Джон Гарденье

1

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

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

В те дни, когда у всех и их мамы были свои собственные домены, меня удивляет, что сейчас нет хорошего решения для такой интеграции с Bind = /


0

Я второй (или третий) вышеупомянутые предложения, чтобы проверить Puppet или 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 очень важны для этой настройки. Я не претендую на исключительные способности написания сценариев, поэтому не стесняйтесь критиковать, но будьте мягкими.


0

Для количества зон, которые у меня есть, синхронизация вручную оказалась проще, чем заставить работать любое другое решение. Если бы у меня было еще много зон, я бы изучал предлагаемые решения.


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

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


@ naught101, вы можете опубликовать сценарии, пожалуйста?

0

Это некоторый 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);
}}

}

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

Затем создайте скрипт 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

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

*/10 * * * * /home/bob/dns_sync.sh
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.