Come migrare un server DNS BIND sul nuovo hardware?


9

Ho ottenuto un lavoro per migrare i server DNS 2x BIND sul nuovo hardware.

Apparentemente stanno usando server preistorici 3U che eseguono Ubuntu server 8.04.
Installerò server 2x 1U con Ubuntu server 9.04.

Come posso trasferire le impostazioni DNS, cache DNS? Quali cartelle / file di configurazione devo trasferire?

Otterrò qualcosa se uso Webmin> Configurazione backup> Server DNS BIND o devo evitare di utilizzare Webmin?

Risposte:


16

Eviterei sempre di usare Webmin. Se si tratta di un server Ubuntu BIND configurato regolarmente, dovrebbe essere sufficiente installare il pacchetto bind9 sui nuovi computer, copiare il contenuto di / etc / bind sui nuovi computer, quindi regolare le impostazioni su ciascun computer per comunicare con quello nuovo , cambia le delegazioni (o gli indirizzi IP, se appropriato) e vai avanti con la vita. Per una migrazione senza interruzioni (zero downtime), esegui una macchina alla volta.


+1 Sono solo in procinto di migrare, bind server su uno nuovo, basta copiare la configurazione e fare in modo che i tweeks facciano il trucco.
Mark Davidson,

+1 per evitare Webmin.
John Gardeniers,

Probabilmente andrei oltre e rivedere il contenuto della configurazione di BIND in modo che sia pulito e privo di Webmin sulla nuova macchina.
Dan Carley,

8

Per prima cosa crea una copia della tua directory / etc / bind

sudo tar czvf bind.tgz /etc/bind
Nota che se il tuo Bind viene eseguito in una prigione, devi ricostruirlo nuovamente creando la prigione, la gerarchia, i dispositivi ...

In caso contrario, copiare l'archivio di bind in remoto sul nuovo server.

scp bind.tgz user@target:~/

Connettiti al tuo nuovo server

ssh user@target

Installa bind9 tramite apt

sudo apt-get install bind9

Puoi anche prendere l'ultima fonte dal sito web isc ( https://www.isc.org/downloadables/11 )

Decomprimi il tuo archivio nella directory / etc / bind

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

Apporta le modifiche necessarie ai tuoi file di configurazione, potrebbe essere nei file delle tue zone ...

e, infine, inizia a legare

sudo /etc/init.d/bind9 start


Ho seguito queste istruzioni alla lettera ma ho finito con una etccartella all'interno /etc/bind9. Qualcosa non va nei tarcomandi. (Ubuntu 14)
frakman1,

1

Dato che sono nel bel mezzo della migrazione dei nostri server su un nuovo hardware, mi lancerò sul ring per questo.

Innanzitutto, se possibile, non esporre il server principale (quello in cui dovrebbero verificarsi tutte le modifiche) a Internet. Anche se significa creare una piccola sessione di macchine virtuali per ospitare un master nascosto, rende più semplice lo spostamento e la sicurezza delle cose.

Ad esempio, ecco parte del mio layout di bind (in / 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 contiene le mie impostazioni di base, quindi include gli altri file con:

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

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

Costruisci i tuoi nuovi server e indicali sul vecchio server principale:

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

Lasciali popolare.

Una volta che il nuovo server principale (si spera nascosto) è pronto, puoi facilmente accedere e modificare il particolare file conf per puntare al nuovo master e viola!


2
compilare un nuovo master rendendolo prima uno slave è una cattiva idea: perde l'ordine di linea originale e la formattazione dei file di zona, inclusi tutti i commenti. usa rsync o scp o qualche altro metodo per copiare effettivamente i file dal vecchio server al nuovo (anche ftp lo farà)
cas

vero, ma questo vale solo per il master, i commenti non si propagheranno mai agli schiavi. Quindi, per i record interessanti, utilizzo un record TXT e aggiungo informazioni. all'inizio della cronaca: blah.domain.com A 1.2.3.4 info.blah.domain.com TXT "server principale blah per Toledo"
Greeblesnort,

1

la risposta di Womble è buona.

inoltre, se possibile, cerca di evitare di dover ridelegare i tuoi server dei nomi (ovvero cerca di finire con i nuovi server che hanno gli stessi indirizzi IP dei vecchi).

se i nuovi server si trovano sulla stessa sottorete IP della precedente, nessun problema: basta configurarli utilizzando indirizzi IP temporanei e scambiarli con gli IP reali quando sono configurati. modificare l'IP sul vecchio server e modificare l'IP sul nuovo server (potrebbe essere necessario cancellare la cache arp sul router o sugli switch).

se qualcosa va storto con la nuova configurazione, è possibile ripristinare rapidamente e facilmente semplicemente scambiando nuovamente gli indirizzi IP .... al contrario, il ripristino dopo aver nuovamente delegato non è affatto facile o veloce perché non è possibile modifica te stesso, devi inviare una richiesta al tuo registrar DNS (che può richiedere 5 minuti o potrebbe richiedere un giorno, o addirittura settimane a seconda di quanto siano informati).

questo può sembrare eccessivamente paranoico, ma nel corso degli anni ho imparato che lasciarsi un modo per annullare qualsiasi cambiamento è sempre una buona idea ... abbastanza spesso, apportare modifiche rivelerà dipendenze nascoste / non documentate sul modo in cui le cose venivano impostate prima di cambiarli. e non importa chi ha reso la dipendenza non documentata o quanto è stato sbagliato - hai cambiato la configurazione, quindi è colpa tua.

se i nuovi server si trovano su una sottorete diversa, non hai altra scelta che delegare nuovamente.


0

Assicurati che anche i file RR siano in / etc / bind (Fed / Cent / RH siano in / var / some / where /) per il passaggio più veloce.

Oppure, una volta che i nuovi sistemi sono attivi, rendili secondari dei vecchi sistemi, fai trasferire loro i RR, quindi scambia quelli nuovi con quelli primari. Questo funziona anche se i primari crittografano i file dei record RR.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.