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

Я получил работу по переносу 2x BIND DNS- серверов на новое оборудование.

Очевидно, они используют доисторические серверы 3U под управлением Ubuntu server 8.04.
Я доберусь до установки 2x 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

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

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, указав новый мастер и альт!

Ответ Уомбла хорош.

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

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

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

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

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

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

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