Configuración de Servidores DNS con Alta Disponibilidad usando BIND9

Implementar servidores DNS en alta disponibilidad garantiza la continuidad del servicio y proporciona redundancia ante fallas. El diseño típico incluye múltiples servidores DNS: uno principal (master) y uno o más secundarios (slaves). Este manual detalla los pasos para configurar BIND9 en este escenario.

1. Preparativos iniciales

Antes de comenzar:

1. Asegúrate de tener dos o más servidores (uno actuará como master y los demás como slaves).
   
2. Todos los servidores deben tener BIND9 instalado:
   
   sudo apt update sudo apt install bind9 bind9utils bind9-doc -y # Ubuntu/Debian sudo yum install bind bind-utils -y # CentOS/RHEL
   
3. Define las IPs de los servidores. Ejemplo:
   • Servidor Master: 192.168.1.10
   • Servidor Slave: 192.168.1.11

2. Configurar el servidor master

2.1 Configurar las zonas en el master

Edita el archivo /etc/bind/named.conf.local:

sudo nano /etc/bind/named.conf.local

Agrega las zonas:

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
    allow-transfer { 192.168.1.11; };  // IP del servidor slave
    also-notify { 192.168.1.11; };     // Notifica cambios al slave
};

zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.1";
    allow-transfer { 192.168.1.11; };
    also-notify { 192.168.1.11; };
};

2.2 Crear los archivos de zona

Sigue el mismo formato descrito en la guía básica:

• Zona directa (/etc/bind/db.example.com):
  
  $TTL 604800
@ IN SOA ns.example.com. admin.example.com. (
2023120301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

; Servidores DNS
@ IN NS ns.example.com.

; Registros A
ns IN A 192.168.1.10
www IN A 192.168.1.20
  
• Zona inversa (/etc/bind/db.192.168.1):
  
  $TTL 604800
@ IN SOA ns.example.com. admin.example.com. (
2023120301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

; Servidores DNS
@ IN NS ns.example.com.

; Registros PTR
10 IN PTR ns.example.com.
20 IN PTR www.example.com.

2.3 Verificar configuración y reiniciar

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/db.example.com
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192.168.1
sudo systemctl restart bind9

3. Configurar el servidor slave

3.1 Definir las zonas como esclavas

Edita /etc/bind/named.conf.local en el servidor slave:

sudo nano /etc/bind/named.conf.local

Agrega las zonas:

zone "example.com" {
    type slave;
    file "/var/cache/bind/db.example.com";
    masters { 192.168.1.10; };  // IP del servidor master
};

zone "1.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/db.192.168.1";
    masters { 192.168.1.10; };
};

3.2 Reiniciar el servicio

Verifica la configuración y reinicia BIND9:

sudo named-checkconf
sudo systemctl restart bind9

4. Configurar sincronización de zonas (transferencia de zona)

El servidor master envía las zonas al slave automáticamente cuando hay cambios. Para que funcione correctamente:

1. Habilitar transferencias de zona en el master:
   • Ya se agregó allow-transfer en la configuración del master.
     
2. Asegúrate de que el puerto 53 esté abierto en ambos servidores:
   
   sudo ufw allow 53
sudo ufw reload
   
3. Prueba la transferencia desde el slave:
   
   sudo rndc retransfer example.com
sudo rndc retransfer 1.168.192.in-addr.arpa

5. Probar la configuración

Desde un cliente, realiza consultas DNS contra ambos servidores:

• Consulta directa al master:
  
  dig @192.168.1.10 www.example.com
  
• Consulta directa al slave:
  
  dig @192.168.1.11 www.example.com
  
• Consulta inversa:
  
  dig -x 192.168.1.20 @192.168.1.11

6. Consideraciones de alta disponibilidad

1. Configurar balanceo de carga DNS:
   • Puedes usar soluciones como Keepalived o HAProxy para balancear peticiones DNS entre los servidores master y slave.
     
2. Configurar TTL en registros:
   • Un TTL bajo (ej. 300 segundos) permite una rápida conmutación si un servidor falla.
     
3. Monitorización:
   • Configura herramientas como Nagios o Prometheus para monitorizar el estado de los servidores DNS.

7. Conclusión

Con este diseño, el servidor master gestiona las actualizaciones de las zonas, y los servidores slave proporcionan redundancia y balanceo de carga. Esto garantiza alta disponibilidad y resiliencia para el servicio DNS.