BIND9 - режим MASTER/SLAVE

В этой статье я хочу рассказать вам о том, как настроить BIND9 Named сервер на Linux машинах и сделать из них связку основного и резервного ДНС сервера.

Если у вас возникли вопросы по установке пакета BIND из репозиториев или из исходников. Отпишите об этом в комментариях и я постараюсь помочь вам в решении вашего вопроса.

Итак, допустим, BIND установлен и что же дальше?

Давайте проверим работает ли он в данный момент времени или нет?

Примечание: такую проверку сделать нужно, потому что при установке пакета BIND, в некоторых дистрибутивах Linux, установщик сразу же его может запустить. Этого нам пока не нужно.

Итак, если BIND запущен - остановите его.

давайте заглянем в основной конфигурационный файл BIND (обычно он располагается по пути /etc/named.conf или /etc/bind/named):

### КОД по-умолчанию ###

options {
     directory "/var/named";
};

zone "." IN {
     type hint;
     file "caching-example/named.root";
};

zone "localhost" IN {
     type master;
     file "caching-example/localhost.zone";
     allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
     type master;
     file "caching-example/named.local";
     allow-update { none; };
};

теперь давайте из этого конфига сделаем конфиг для MASTER зон:

### КОД для MASTER ###

options {
     directory "/var/named";
     allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу - ставим "any", т.е. любой.
     version "No info"; // Прячем реальную версию ДНС сервера за надписью "No info". Тут можно всякое написать, в т.ч. и "заборное".
     listen-on { 192.168.1.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту.
     allow-recursion { none; }; // отключаем рекурсию
     allow-transfer { 192.168.2.100; }; // Говорим MASTER серверу куда можно передавать зоны (обычно тут указывается адрес IP Slave сервера).
};

zone "." IN {
     type hint;
     file "caching-example/named.root";
};

zone "localhost" IN {
     type master;
     file "caching-example/localhost.zone";
     allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
     type master;
     file "caching-example/named.local";
     allow-update { none; };
};

zone "domain1.ru" IN { // Вот собственно и первая наша внешняя зона, которую будет обслуживать наш сервер
     type master; // поскольку мы хотим чтобы для этой зоны наш сервер был первичным (MASTER), то и пишем тут "type master"
     file "caching-example/domain1.conf"; // А это место расположения файла с описанием зоны. Название файла "domain1.conf" может быть произвольным.
     notify yes; // Говорим зоне MASTER сервера предупреждать SLAVE сервер о том что зона обновилась (если в нее вносили какие-то изменения).
};

zone "domain2.ru" IN { // А это вторая зона. Таких зон может быть ооочень много.
     type master; // По аналогии.
     file "caching-example/domain2.conf"; // По аналогии.
     notify yes; // По аналогии.
};

Вот и все.

А теперь давайте посмотрим на другую машину. Также поставим там Bind как и для MASTER. Смотрим конфиг:

### КОД для SLAVE ###

options {
     directory "/var/named";
     allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу - ставим "any", т.е. любой.
     version "No info"; // Прячем реальную версию ДНС сервера за надписью "No info". Тут можно всякое написать, в т.ч. и "заборное".
     listen-on { 192.168.2.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту.
     allow-recursion { none; }; // отключаем рекурсию
};

zone "." IN {
     type hint;
     file "caching-example/named.root";
};

zone "localhost" IN {
     type master;
     file "caching-example/localhost.zone";
     allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
     type master;
     file "caching-example/named.local";
     allow-update { none; };
};

zone "domain1.ru" IN { // Вот собственно и первая наша внешняя Slave зона, которую будет обслуживать наш сервер
     type slave; // поскольку мы хотим чтобы для этой зоны наш сервер был вторичным (SLAVE), то и пишем тут "type slave"
     file "caching-example/domain1-slave.conf"; // А это место расположения файла с описанием зоны. Название файла "domain1-slave.conf" может быть произвольным. Но лучше, для удобства помечать файлик маркером, так как сделал это я "-slave".
     masters { 192.168.1.100; }; // А вот Этой переменной мы указываем SLAVE серверу адрес MASTER сервера, откуда, собственно, мы и будем забирать описание и детали зоны "domain1.ru"
};

zone "domain2.ru" IN { // А это вторая Slave зона. Таких зон может быть ооочень много.
     type slave; // По аналогии
     file "caching-example/domain2-slave.conf"; // По аналогии.
     masters { 192.168.1.100; }; // По аналогии.
};

Обратите внимание, что в listen-on { 192.168.2.100; 127.0.0.1; }; стоит IP адрес отличный от адреса сервера MASTER, более того он находится в другой подсети. Это сделано для того чтобы, если вдруг подсеть #1 192.168.1.xxx "упадет" и перестанет отвечать на запросы... то резервный сервер в подсети #2 192.168.2.xxx - наш SLAVE останется доступным для общекорпоративной сети 192.168.xxx.xxx и он сможет продолжать обрабатывать ДНС запросы пользователей так, что они ничего не почувствуют. Как только MASTER сервер встанет в строй, работа продолжится в штатном режиме.
Примечание: Если MASTER сервер выходит из строя очень важно понимать, что добавление новых записей на SLAVE сервер лучше не производить.. иначе база данных зон на MASTER сервере потеряет свою актуальность и хоть перебросить новые зоны на мастер сервер не составит труда, надо понимать, что в масштабах обновления записей к примеру 1000 и более, это будет очень тяжело.
Потому, если аварийное состояние MASTER сервера затянется надолго.. то лучше объявить клиентам о технических работах и приостановить также работу и SLAVE сервера до момента полного восстановление работоспособности MASTER узла.
Так же обратите внимание, что мы убрали allow-transfer { 192.168.2.100; }; - Для SLAVE сервера нет нужны передавать зону куда либо еще (за редким исключением), потому мы убрали эту опцию.

Вот и все со SLAVE.

Теперь можно добавлять на сервере MASTER файлы описания/содержания зоны и выкладывать их в соответствующие (указанные в файле конфигурации) директории. На сервер SLAVE эти файлы добавлять не нужно, SLAVE сервер сам их заберет с базы MASTER сервера.

Пример такого файла:

$ORIGIN .
$TTL 1800      ; 30 minutes
domain1.ru     IN SOA ns1.domain1.ru. info.domain1.ru. (
       201108083 ; serial
       1800   ; refresh (30 minutes)
       900   ; retry (15 minutes)
       604800   ; expire (1 week)
       86400   ; minimum (1 day)
       )
       NS ns1.domain1.ru.
       NS ns2.domain1.ru.
       A 192.168.1.100
       MX 10 mail.domain1.ru.
$ORIGIN domain1.ru.
*     A 192.168.1.100
mail      A 192.168.1.100
ns1     A 192.168.1.100
ns2     A 192.168.2.100
www     A 192.168.1.100

О синтаксисе этого файла в интернете написано очень много, но если вопросы возникнут тут, я готов она них ответить и добавить в этот материал информацию о синтаксисе написания конфигурации зон.

Теперь запустим поочередно Bind (named) демоны на MASTER и на SLAVE серверах и посмотрим как оно все работает.

На сим все..
Надеюсь у вас все получится.

С Уважением,
Savaog

И такой еще вопрос. Мастер и

И такой еще вопрос. Мастер и Слейв на одном сервере можно подымать?

Можно, но не нужно... вредно

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

Не увлекайтесь таким эмулированием... помните, ничто не бывает более постоянным, как временное!

Ваш, Savaog

"Давайте проверим работает ли

"Давайте проверим работает ли он в данный момент времени или нет?"
А как это сделать?

В случае использования только

В случае использования только авторитетного сервера, как в приведённой статье, лучше использовать nsd. Он и меньше, и секьюрнее.

Все отлично, но это

Все отлично, но это называется не master-slave а primary и secondary. Пожалуйста, используйте корретную терминологию.

Терминология вполне

Терминология вполне корректна. Primary/Secondary - эти термины использовались для идентификации серверов со службой Bind версий 4.xx. В свежих версиях используются термины Master/Slave. Учитывая тот момент, что для домена можно указать 2х и более ДНС серверов, обслуживающих данную зону, то терминология master/slave подходит больше, если мы возьмем во внимание тот момент, что может быть даже 2 master сервера и, допустим, 3 дублирующих слейва. Но на самом деле это слова почти что синонимы. Для того чтобы раскрыть более полно содержание этой статьи терминология Master/Slave выбрана не случайно и является более оптимальной.

Тем болеe, для простого пользователя терминология Primary/Secondary является больше перечисляющей серверы, нежели отражающий их статусы. Как-то так.

С Уважением,
Savaog

А если я например создам сайт

А если я например создам сайт sait11.ru то мне не надо платить за домен и не надо его не где регистрировать?
и есть что-то на подобе бинда для винды?

Платить надо регистратору

Платить надо регистратору доменных имен. А вот поддержкой доменного имени вы будете заниматься сами.