¿Cómo migrar un servidor DNS BIND a un nuevo hardware?


9

Conseguí un trabajo para migrar 2x servidores DNS BIND a un nuevo hardware.

Aparentemente están usando servidores prehistóricos 3U que ejecutan el servidor Ubuntu 8.04.
Instalaré servidores 2x 1U con el servidor Ubuntu 9.04.

¿Cómo puedo transferir la configuración de DNS, el caché de DNS? ¿Qué carpetas / archivos de configuración necesito transferir?

¿Lograré algo si uso Webmin> Configuración de copia de seguridad> Servidor DNS BIND o debo evitar usar Webmin?

Respuestas:


16

Yo siempre evitar el uso de Webmin. Si es un servidor Ubuntu BIND configurado regularmente, debería ser suficiente instalar el paquete bind9 en las nuevas máquinas, copiar el contenido de / etc / bind en las nuevas máquinas, luego ajustar la configuración en cada máquina para hablar con la nueva , cambie las delegaciones (o direcciones IP, si corresponde) y continúe con la vida. Para una migración sin interrupciones (tiempo de inactividad cero), haga una máquina a la vez.


+1 Estoy en progreso de migrar un servidor de enlace a uno nuevo, solo copiar la configuración y hacer que los tweeks funcionen.
Mark Davidson el

+1 para evitar Webmin.
John Gardeniers

Probablemente iría uno más y revisaría el contenido de la configuración de BIND para que esté limpio y sin Webmin en la nueva máquina.
Dan Carley el

8

Primero haga una copia de su directorio / etc / bind

sudo tar czvf bind.tgz /etc/bind
Tenga en cuenta que si su Bind se ejecuta en una cárcel, debe construirlo nuevamente creando la cárcel, la jerarquía, los dispositivos ...

Si no, copie su archivo de enlace de forma remota en su nuevo servidor.

scp bind.tgz user@target:~/

Conéctese a su nuevo servidor

ssh user@target

Instalar bind9 a través de apt

sudo apt-get install bind9

También puede obtener la última fuente del sitio web de isc ( https://www.isc.org/downloadables/11 )

Descomprima su archivo en el directorio / etc / bind

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

Realice los cambios que necesita en sus archivos de configuración, pueden estar en sus archivos de zonas ...

y por último, empezar a unir

sudo /etc/init.d/bind9 start


Seguí estas instrucciones al pie de la letra pero terminé con una etccarpeta dentro /etc/bind9. Algo está mal en los tarcomandos. (Ubuntu 14)
frakman1

1

Como estoy justo en el medio de migrar nuestros servidores a un nuevo hardware, me lanzaré al ring por este.

Primero, si es posible, no exponga su servidor maestro (aquel en el que deberían ocurrir todos los cambios) a Internet. Incluso si significa construir una pequeña sesión de VM para alojar un maestro oculto, hace que mover cosas y mantenerlo seguro sea mucho más fácil.

Como ejemplo, aquí está parte de mi diseño de enlace (en / 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 mi configuración básica y luego incluye los otros archivos con:

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

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

Cree sus nuevos servidores y apúntelos al antiguo servidor maestro:

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

Déjalos poblar.

Una vez que el nuevo servidor maestro (con suerte oculto) esté listo, ¡puede entrar y modificar fácilmente el archivo conf particular para señalar al nuevo maestro y viola!


2
poblar un nuevo maestro convirtiéndolo primero en esclavo es una mala idea: pierde el orden de línea original y el formato de los archivos de zona, incluidos todos los comentarios. use rsync o scp o algún otro método para copiar los archivos del antiguo servidor al nuevo (incluso ftp lo hará)
cas

cierto, pero eso solo se aplica al maestro de todos modos, los comentarios nunca se propagarán a los esclavos. Entonces, para registros interesantes, uso un registro TXT y agrego información. al frente del registro: blah.domain.com A 1.2.3.4 info.blah.domain.com TXT "servidor bla principal para Toledo"
Greeblesnort

1

La respuesta de womble es buena.

Además, si es posible, trate de evitar tener que volver a delegar sus servidores de nombres (es decir, trate de terminar con los nuevos servidores que tengan las mismas direcciones IP que los anteriores).

si los nuevos servidores están en la misma subred IP que los anteriores, no hay problema: simplemente configúrelos con direcciones IP temporales y cámbielos por las IP reales cuando estén configurados. cambie la IP en el servidor anterior y cambie la IP en el nuevo servidor (es posible que deba borrar la caché de arp en su enrutador o conmutadores).

Si algo sale mal con la nueva configuración, puede revertir rápida y fácilmente simplemente intercambiando las direcciones IP nuevamente ... por el contrario, revertir después de volver a delegar no es tan fácil ni tan rápido porque no puede cámbielo usted mismo, debe enviar una solicitud a su registrador de DNS (que puede demorar 5 minutos o un día, o incluso semanas, dependiendo de lo informados que estén).

Esto puede sonar demasiado paranoico, pero a lo largo de los años he aprendido que dejar una forma de revertir cualquier cambio siempre es una buena idea ... a menudo, hacer cambios revelará dependencias ocultas / indocumentadas de la forma en que se solían configurar las cosas. antes de cambiarlos. y no importa quién hizo la dependencia indocumentada o cuán equivocado fue: cambiaste la configuración, así que es tu culpa.

Si los nuevos servidores están en una subred diferente, no tiene más remedio que volver a delegar.


0

Asegúrese de que los archivos RR también estén en / etc / bind (Fed / Cent / RH están en / var / some / where /) para el cambio más rápido.

O, una vez que los nuevos sistemas estén activos, conviértalos en secundarios de los sistemas antiguos, haga que transfieran los RR y luego cambie los nuevos a los primarios. Esto también funciona si los primarios están encriptando los archivos de registro RR.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.