Jak migrować serwer BIND DNS na nowy sprzęt?

Dostałem zadanie migracji 2 serwerów BIND DNS na nowy sprzęt.

Najwyraźniej używają 3U prehistorycznych serwerów z systemem Ubuntu Server 8.04.
Zainstaluję 2x serwery 1U z serwerem Ubuntu 9.04.

Jak mogę przenieść ustawienia DNS, pamięć podręczną DNS? Jakie foldery / pliki konfiguracyjne muszę przenieść?

Czy coś osiągnę, jeśli użyję Webmin> Konfiguracja kopii zapasowej> Serwer DNS BIND, czy powinienem unikać używania Webmin?

Chciałbym zawsze unikać Webmin. Jeśli jest to regularnie konfigurowany serwer Ubuntu BIND, wystarczy zainstalować pakiet bind9 na nowych komputerach, skopiować zawartość pliku / etc / bind na nowe komputery, a następnie dostosować ustawienia na każdym komputerze, aby porozmawiać z nowym , zmień delegacje (lub adresy IP, jeśli to właściwe) i zacznij żyć. Aby zapewnić bezproblemową migrację (zero przestojów), wykonuj po jednym komputerze na raz.

Najpierw wykonaj kopię katalogu / etc / bind

sudo tar czvf bind.tgz /etc/bind

Jeśli nie, skopiuj archiwum powiązań zdalnie na nowy serwer.

scp bind.tgz user@target:~/

Połącz się ze swoim nowym serwerem

ssh user@target

Zainstaluj bind9 przez apt

sudo apt-get install bind9

Możesz również pobrać najnowsze źródło ze strony internetowej isc ( https://www.isc.org/downloadables/11 )

Rozpakuj swoje archiwum w katalogu / etc / bind

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

Dokonaj potrzebnych zmian w plikach konfiguracyjnych, może być w plikach stref ...

i na koniec zacznij wiązać

sudo /etc/init.d/bind9 start

Ponieważ jestem właśnie w trakcie migracji naszych serwerów na nowy sprzęt, rzucę się na ten pierścień.

Po pierwsze, jeśli to w ogóle możliwe, nie wystawiaj swojego serwera głównego (tego, na którym powinny nastąpić wszystkie zmiany) do Internetu. Nawet jeśli oznacza to zbudowanie małej sesji maszyny wirtualnej do obsługi ukrytego wzorca, znacznie ułatwia przenoszenie i zabezpieczanie.

Jako przykład, oto część mojego układu powiązań (w / 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 zawiera moje podstawowe ustawienia, a następnie zawiera inne pliki z:

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

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

Zbuduj nowe serwery i skieruj je na stary serwer główny:

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

Pozwól im się zaludnić.

Gdy nowy serwer główny (mam nadzieję, że jest ukryty) jest gotowy, możesz bardzo łatwo wejść i zmodyfikować konkretny plik conf, aby wskazywał na nowy serwer główny i altówkę!

odpowiedź womble jest dobra.

także, jeśli to w ogóle możliwe, staraj się unikać ponownego umieszczania swoich serwerów nazw (tj. spróbuj skończyć z nowymi serwerami mającymi takie same adresy IP jak stare).

jeśli nowe serwery znajdują się w tej samej podsieci IP co stara, nie ma problemu - po prostu skonfiguruj je przy użyciu tymczasowych adresów IP i zamień je na prawdziwe adresy IP po ich skonfigurowaniu. zmień adres IP na starym serwerze i zmień adres IP na nowym serwerze (może być konieczne wyczyszczenie pamięci podręcznej arp na routerze lub przełącznikach).

jeśli coś pójdzie nie tak z nową konfiguracją, możesz szybko i łatwo przywrócić, po prostu ponownie zamieniając adresy IP ... z drugiej strony, cofanie po ponownej delegacji nie jest tak łatwe lub szybkie, ponieważ nie możesz zmień to sam, musisz przesłać prośbę do swojego rejestratora DNS (co może potrwać 5 minut lub może potrwać dzień, a nawet tygodnie, w zależności od tego, jak są zamaskowani).

może to zabrzmieć zbyt paranoicznie, ale nauczyłem się przez lata, że ​​pozostawienie sobie sposobu na cofnięcie każdej zmiany jest zawsze dobrym pomysłem ... dość często wprowadzanie zmian ujawni ukryte / nieudokumentowane zależności od tego, jak to było ustawione zanim je zmieniłeś. i nie ma znaczenia, kto sprawił, że nieudokumentowana zależność, lub jak się myliła - zmieniłeś konfigurację, więc to twoja wina.

jeśli nowe serwery znajdują się w innej podsieci, nie masz innego wyboru, jak dokonać ponownej delegacji.

Upewnij się, że pliki RR znajdują się również w / etc / bind (Fed / Cent / RH znajdują się w / var / some / where /) w celu najszybszego przełączenia.

Lub, gdy nowe systemy będą gotowe, uczyń je drugorzędnymi w stosunku do starych systemów, poproś o przeniesienie RR, a następnie zamień nowe na pierwotne. Działa to również, jeśli podstawowe szyfrują pliki rekordów RR.