BIND9 - режим MASTER/SLAVE

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

---

В этой статье я хочу рассказать вам о том, как настроить 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 зон:

 

 

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[/b]" 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 [ l2x2l team ]