Как перенести DNS-сервер BIND на новое оборудование?

У меня есть работа по миграции 2x BIND DNS серверов на новое оборудование.

По-видимому, они используют доисторические серверы 3U под управлением сервера Ubuntu 8.04.
Я установлю 2 сервера 1U с сервером Ubuntu 9.04.

Как перенести настройки DNS, кеш DNS? Какие папки / файлы конфигурации мне нужно перенести?

Я чего-нибудь добьюсь, если воспользуюсь Webmin> Конфигурация резервного копирования> DNS-сервер BIND или мне следует избегать использования Webmin?

мне бы всегда избегайте использования Webmin. Если это регулярно настраиваемый сервер Ubuntu BIND, достаточно установить пакет bind9 на новых машинах, скопировать содержимое / etc / bind на новые машины, а затем настроить параметры на каждой машине, чтобы разговаривать с новой. , измените делегирование (или IP-адреса, если необходимо) и продолжайте жить. Для плавной миграции (без простоев) выполняйте по одной машине за раз.

Сначала сделайте копию вашего каталога / etc / bind

sudo tar czvf bind.tgz /etc/bind

Note that if your Bind run in a jail, you have to build it again by creating jail, the hierarchy, the devices ...

Если нет, скопируйте свой архив привязки удаленно на новый сервер.

scp bind.tgz user@target:~/

Подключитесь к вашему новому серверу

ssh user@target

Установите bind9 через apt

sudo apt-get install bind9

Вы также можете скачать последний исходный код с веб-сайта isc (https://www.isc.org/downloadables/11)

Разархивируйте ваш архив в каталог / etc / bind

sudo tar xzvf bind.tgz -C /etc/bind

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

и, наконец, начать привязку

sudo /etc/init.d/bind9 start

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

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

В качестве примера, вот часть моего макета привязки (в / etc / bind):

-rw-r-----  1 root bind 2.6K 2009-08-07 10:41 named.conf
-rw-r-----  1 root bind 112K 2009-07-24 07:54 named.external.conf
-rw-r-----  1 root bind 112K 2009-07-24 07:53 named.internal.conf
-rw-r-----  1 root bind  792 2009-07-01 10:28 named.logging.conf
-rw-r-----  1 root bind  834 2009-07-01 10:28 named.options.conf
-rw-r-----  1 root bind  373 2009-07-01 10:28 rndc.conf
-rw-r-----  1 root bind  131 2009-07-01 10:28 rndc.key

named.conf содержит мои основные настройки, а затем включает другие файлы с:

include "/etc/bind/named.logging.conf";
include "/etc/bind/named.options.conf";

include "/etc/bind/rndc.key";

Создайте свои новые серверы и направьте их на старый главный сервер:

zone "adnszone.com" {
        type slave;
        masters ( your.master.server.ip; etc.etc.etc.etc; }; 
        file "internal/adnszone.com";
};

Пусть заселяются.

Как только новый главный сервер (надеюсь, скрытый) будет готов, вы можете очень легко войти и изменить конкретный файл conf, чтобы он указывал на новый мастер и альт!

ответ womble хорош.

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

Если новые серверы находятся в той же IP-подсети, что и старые, нет проблем - просто настройте их, используя временные IP-адреса, и замените их реальными IP-адресами, когда они настроены. измените IP-адрес на старом сервере и измените IP-адрес на новом сервере (вам может потребоваться очистить кеш arp на вашем маршрутизаторе или коммутаторах).

если что-то пойдет не так с новой настройкой, вы можете быстро и легко вернуться к ней, просто заменив IP-адреса обратно ... напротив, восстановление после повторного делегирования далеко не так просто и быстро, потому что вы не можете измените это самостоятельно, вы должны отправить запрос своему регистратору DNS (это может занять 5 минут или день или даже недели, в зависимости от того, насколько они осведомлены).

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

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

Убедитесь, что файлы RR также находятся в / etc / bind (Fed / Cent / RH они находятся в / var / some / where /) для наиболее быстрого переключения.

Или, как только новые системы будут запущены, сделайте их вторичными по отношению к старым системам, попросите их перенести RR, а затем поменять новые на первичные. Это также работает, если первичные блоки шифруют файлы записей RR.