Servidor DNS secundario: qué es y cómo funciona

¿Qué es un servidor DNS secundario?

Un servidor DNS secundario es un servidor de nombres autoritativo que mantiene una copia de solo lectura de una zona DNS y responde a las consultas sobre ella con la misma autoridad que el primario. No tiene una versión propia de la zona: la recibe del primario mediante una transferencia de zona y mantiene esa copia sincronizada.

Desde fuera, primario y secundario son indistinguibles. Ambos aparecen en los registros NS del dominio, ambos responden con la bandera AA (respuesta autoritativa) y los resolutores eligen el que responda más rápido. La única diferencia está en dónde se editan los datos: usted cambia los registros en el primario, y el secundario lo sigue.

La documentación antigua y muchos archivos de configuración siguen llamando a los dos roles master y slave (maestro y esclavo). BIND, PowerDNS y la mayoría de los paneles aceptan ambos nombres; el significado es el mismo.

Se espera que todo dominio en producción tenga al menos dos servidores de nombres autoritativos, en redes distintas — el RFC 2182 explica por qué, y la mayoría de los registros rechazan una delegación con menos. Un servidor DNS secundario es la forma en que una instalación de un solo servidor cumple ese requisito sin tener que operar a mano una segunda instalación DNS completa.

DNS primario frente a DNS secundario

Primario (master). Mantiene la copia editable de la zona — en archivos de zona para BIND, en una base de datos para PowerDNS, en el almacenamiento del panel para cPanel, Plesk, DirectAdmin o CyberPanel. Todo cambio en un registro ocurre aquí, y cada cambio debe incrementar el serial del SOA de la zona.

Secundario (slave). Mantiene una copia obtenida por transferencia de zona. Nunca acepta ediciones; cualquier cambio local es sobrescrito por la siguiente transferencia. Responde a las consultas de forma autoritativa, no envía cambios de vuelta y descarta la zona si no consigue comunicarse con el primario durante más tiempo que el expire del SOA.

Lo que esto significa en la práctica:

- Añadir un registro significa editar solo el primario. El secundario recoge el cambio por sí mismo. - Si el primario está caído, el secundario sigue respondiendo — pero no se pueden hacer cambios nuevos hasta que el primario vuelva. - Si el secundario está caído, el primario sigue respondiendo y no se pierde nada; los resolutores simplemente usan el servidor de nombres que queda. - Ambos servidores deben figurar en los registros NS en el registrador, o los resolutores nunca preguntarán nada al secundario.

Cómo obtiene la zona un secundario

El mecanismo es una transferencia de zona, definida por el propio protocolo DNS, de modo que cualquier secundario puede trabajar con cualquier primario sin importar el software.

1. Autorización. El primario debe permitir transferencias hacia la dirección IP del secundario (allow-transfer en BIND, allow-axfr-ips en PowerDNS) o aceptar una clave TSIG compartida. Sin esto, el secundario es rechazado. 2. Primera transferencia. El secundario solicita la zona completa con una petición AXFR por el puerto TCP 53 y almacena el resultado. A partir de ese momento es autoritativo para la zona. 3. Mantenerse sincronizado. El secundario vuelve a comprobar el registro SOA del primario según el intervalo fijado por el valor refresh del SOA de la zona. Si el serial del primario es mayor que el suyo, transfiere de nuevo — la zona completa (AXFR) o solo los cambios (IXFR) cuando ambos lados lo soportan. 4. NOTIFY. En lugar de esperar al temporizador de refresco, un primario puede enviar un mensaje NOTIFY en el momento en que la zona cambia; el secundario comprueba entonces el serial de inmediato. Con NOTIFY configurado, los cambios llegan al secundario en segundos. 5. Expiración. Si el primario permanece inaccesible más allá del valor expire del SOA, el secundario deja de responder por la zona en lugar de servir datos que podrían estar muy desactualizados.

Dos detalles causan la mayoría de las configuraciones fallidas. El serial debe aumentar realmente en cada cambio — un secundario compara números, no contenido. Y AXFR usa TCP, no UDP: un cortafuegos que permite solo UDP 53 deja pasar las consultas normales pero bloquea silenciosamente toda transferencia de zona. El protocolo de transferencia se trata en profundidad en Entender las transferencias de zona AXFR, y los temporizadores en Qué es el registro SOA de DNS y por qué es importante para su dominio.

Por qué necesita un servidor DNS secundario

Disponibilidad. Un único servidor de nombres autoritativo es un punto único de fallo para todos los dominios que aloja. Un reinicio por una actualización del kernel, un fallo de hardware, un DDoS contra el servidor — y los dominios dejan de resolver por completo: sitios web, correo y APIs se detienen a la vez. Con un secundario en una red distinta, los resolutores obtienen sus respuestas de él y los usuarios no notan nada.

Reglas del registrador y del registro. La mayoría de los registros exigen al menos dos servidores de nombres para delegar un dominio, y algunos comprueban que estén en redes distintas. Listar el mismo servidor bajo dos nombres cumple el formulario pero no el propósito: ambos nombres fallan a la vez.

La caché no le salva. Los resolutores cachean los registros solo durante su TTL — de minutos a horas. Un primario caído durante más tiempo que el TTL es un dominio que ha desaparecido de internet, y los servidores de correo que no puedan resolver su MX rechazarán o aplazarán los mensajes.

Distancia. Un secundario en una segunda ubicación responde a los usuarios más cercanos a él, y los dos servidores se reparten la carga de consultas. Es un beneficio adicional, no la razón principal: la razón principal es que un servidor tarde o temprano se cae, y un secundario es lo que mantiene el dominio en línea cuando eso ocurre.

Redundancia DNS: por qué es importante y cómo lograrla profundiza en qué es lo que realmente se rompe y cómo diseñar para evitarlo.

Operar su propio secundario frente a usar uno gestionado

Su propio segundo servidor. Una segunda instalación de BIND o PowerDNS en otra máquina, idealmente en otro centro de datos, configurada como secundario para cada zona. Le da control total y cuesta solo el servidor. El coste es operativo: un segundo equipo que parchear y monitorizar, reglas de cortafuegos en ambos lados y cada zona nueva registrada a mano en el secundario — o automatizada con scripts que usted mantiene. Muchas instalaciones de un solo servidor nunca llegan a hacerlo precisamente por eso.

Un servicio de DNS secundario gestionado. Un proveedor opera los servidores de nombres secundarios; usted permite transferencias de zona desde su IP y apunta sus registros NS a su nombre de host (o a su propio nombre de host con un registro glue — vea Qué son los registros glue de DNS y cuándo los necesita). Su servidor sigue siendo el primario, nada cambia en la forma en que edita el DNS, y el trabajo del proveedor es mantenerse en línea cuando el suyo no lo está. La contrapartida es que depende de un tercero para la mitad de su DNS, así que importan su disponibilidad y la separación de su red respecto a la suya.

Paneles de hosting. En cPanel, Plesk, DirectAdmin y CyberPanel la vía manual es más difícil de lo que parece: el panel regenera la configuración del servidor DNS, de modo que las ediciones a mano se sobrescriben, y cada dominio nuevo debe registrarse en el secundario. Existen integraciones que se enganchan a los eventos de dominio del panel precisamente para esto; las guías de paneles más abajo muestran tanto la vía manual como la automatizada.

Elija lo que elija, la lista de comprobación es la misma: transferencias permitidas desde la dirección del secundario, NOTIFY habilitado, TCP 53 abierto, ambos servidores de nombres en la delegación y el serial incrementado en cada cambio.

Comprobar que un secundario funciona

Pregunte directamente a cada servidor autoritativo por el registro SOA de la zona. Sustituya example.com por su dominio y los dos nombres de host por sus servidores de nombres:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Ambos deben responder, y el número de serial (el tercer campo) debe ser idéntico. Un secundario que responde con un serial más bajo no ha recogido el último cambio; uno que responde SERVFAIL o REFUSED nunca ha cargado la zona o la ha expirado.

Compruebe la delegación tal como la ve el mundo:

dig NS example.com +short

Ambos servidores de nombres deben figurar en la lista. Un secundario perfectamente sincronizado pero ausente de los registros NS no recibe consultas y no protege nada.

Por último, confirme que la propia transferencia de zona es posible desde la red del secundario — desde el equipo secundario, o desde cualquier equipo cuya IP permita el primario:

dig AXFR example.com @ns1.example.com

Un listado completo de la zona significa que las transferencias funcionan; un transfer failed o REFUSED significa que las reglas allow-transfer del primario o un cortafuegos en TCP 53 están bloqueando al secundario.

Errores comunes

- Olvidar incrementar el serial del SOA. El primario responde con datos nuevos, el secundario ve el mismo serial y nunca transfiere. La causa más común de "funciona en ns1, no en ns2". - Abrir UDP 53 pero no TCP 53. Las consultas funcionan, las transferencias no. Todas las zonas del secundario expiran silenciosamente. - No listar el secundario en los registros NS. El secundario se sincroniza perfectamente y nunca se le pregunta nada. - Ambos servidores de nombres en el mismo equipo o la misma red. Cumple el formulario del registrador, no el fallo que se supone que debe sobrevivir. - Un expire del SOA corto. Un día es habitual en los valores por defecto de los paneles; una caída del primario durante un fin de semana se lleva entonces al secundario con él. Dos semanas es el valor habitual. - Editar registros en el secundario. Desaparecen en la siguiente transferencia. - Olvidar el secundario al añadir un dominio nuevo. Cada zona nueva debe registrarse en el secundario, a mano o por automatización; una zona que existe solo en el primario no tiene redundancia alguna.

Guías relacionadas

Configuración y mecanismos subyacentes:

- Cómo configurar un servidor DNS secundario - Entender las transferencias de zona AXFR - Qué es el registro SOA de DNS y por qué es importante para su dominio - Redundancia DNS: por qué es importante y cómo lograrla - Qué son los registros glue de DNS y cuándo los necesita

Paneles de hosting:

- Cómo añadir DNS secundario al panel de hosting cPanel/WHM - Cómo añadir DNS secundario al panel de hosting Plesk - Cómo agregar DNS secundario al panel de hosting DirectAdmin - Cómo agregar DNS secundario al panel de hosting CyberPanel