Cómo operar DNS con un primario oculto y secundarios públicos

El servidor donde edita sus zonas DNS no necesita responder a internet, y no debería hacerlo. Un primario oculto guarda la copia autoritativa y recibe los cambios de su gente y de su automatización. Un conjunto de secundarios públicos, que son los únicos servidores listados en sus registros NS, responde todas las consultas. El primario puede parchearse, reiniciarse o ser atacado por nadie, porque nadie de fuera sabe dónde está. Este artículo muestra cómo construir eso con PowerDNS, las dos formas de llevar los datos del primario a los secundarios, y las comprobaciones que demuestran que el primario está oculto de verdad.

La forma del diseño

• Un primario en una red privada, sin dirección pública, nunca nombrado en registros NS ni SOA. Ejecuta la API y la interfaz web que usa su equipo.
• Dos o más secundarios públicos en sedes distintas, idealmente en redes distintas y en proveedores o plataformas distintos, de modo que ningún fallo único los tumbe a todos.
• Una ruta privada del primario a cada secundario, solo para la replicación.
• Los secundarios siguen respondiendo si el primario desaparece. Guardan una copia completa, así que un primario muerto significa «sin cambios durante un tiempo», no «dominio caído».

Hay dos formas de alimentar a los secundarios. Ambas funcionan; convienen a equipos distintos.

Opción uno: transferencias de zona con NOTIFY y TSIG

Esto es DNS estándar y funciona con cualquier mezcla de servidores DNS. El primario envía un NOTIFY cuando una zona cambia; el secundario comprueba el serial del SOA y extrae la zona con AXFR o IXFR.

En el primario, en pdns.conf:

primary=yes
allow-axfr-ips=192.0.2.21/32,198.51.100.31/32
also-notify=192.0.2.21,198.51.100.31
only-notify=

Esas direcciones son las direcciones privadas de los secundarios. Dejar only-notify vacío y listar los destinos en also-notify significa que el NOTIFY va solo a sus secundarios, nunca a lo que resulte estar en los registros NS.

Después firme las transferencias. Una lista de IP permitidas por sí sola confía en la red; una clave TSIG demuestra que la petición viene de su secundario.

# on the primary
pdnsutil generate-tsig-key xfr hmac-sha256
pdnsutil activate-tsig-key example.com xfr primary
pdnsutil list-tsig-keys      # copy the secret

# on each secondary (pdns.conf contains: secondary=yes)
pdnsutil import-tsig-key xfr hmac-sha256 '<secret>'
pdnsutil create-secondary-zone example.com 203.0.113.10
pdnsutil activate-tsig-key example.com xfr secondary

Donde 203.0.113.10 es la dirección privada del primario. Para evitar crear cada zona a mano en cada secundario, PowerDNS puede crearlas automáticamente cuando el primario envía un NOTIFY para una zona nueva. Configure el primario como autoprimary en cada secundario:

pdnsutil add-autoprimary 203.0.113.10 ns1.example.net

y fije autosecondary=yes en los secundarios.

Opción dos: zonas nativas y replicación de base de datos

PowerDNS también puede prescindir por completo de las transferencias DNS. Marque las zonas como NATIVE, guárdelas en un backend MySQL, MariaDB o PostgreSQL, y deje que la base de datos replique los datos del primario a una réplica de solo lectura en cada secundario.

pdnsutil set-kind example.com native

En cada secundario, PowerDNS lee de su base de datos réplica local, configurada como solo lectura. La replicación circula únicamente por la red privada.

Por qué elegir esto:

• Cada cambio llega como una fila, en cuanto la base de datos lo envía. No hay un incremento de serial que olvidar ni un NOTIFY que perder.
• AXFR puede desactivarse en todas partes, así que no hay ninguna interfaz de transferencia que proteger.
• Las zonas nuevas aparecen automáticamente en los secundarios, porque también son filas.
• Las claves DNSSEC se replican junto con los registros, y cada secundario firma las respuestas por sí mismo.

Por qué no: cada secundario debe ejecutar el mismo backend, y ahora está operando replicación de base de datos, que necesita su propia monitorización de retraso y de hilos rotos. Si sus secundarios incluyen el DNS de otro fabricante, las transferencias son la única opción.

Nosotros construimos los nuestros con zonas nativas y replicación de base de datos, porque elimina por completo la superficie de transferencia y convierte la base de datos en la única fuente de verdad, evidente.

DNSSEC con un primario oculto

Ambas opciones admiten la firma:

• Con transferencias, firme en el primario. Los secundarios reciben la zona firmada y la sirven como datos prefirmados; PowerDNS marca la zona como PRESIGNED automáticamente cuando transfiere registros firmados.
• Con replicación de base de datos, las claves viven en la base de datos, así que cada secundario firma en vivo con las mismas claves y responde de forma idéntica.

En cualquier caso, pruebe la validación desde fuera con un resolver validador:

dig +dnssec example.com SOA @1.1.1.1
delv example.com SOA

delv debería informar «fully validated».

Nombre los servidores correctos

El sentido de un primario oculto se pierde si su nombre se filtra a los registros que el mundo lee.

• Los registros NS listan solo los secundarios públicos.
• El campo MNAME del SOA nombra un secundario público, no el primario. En PowerDNS, default-soa-content lo fija para las zonas nuevas; corrija las existentes con pdnsutil edit-zone.
• El glue en el registro apunta solo a las direcciones públicas de los secundarios.

Algunas herramientas ponen por defecto el propio nombre del servidor en el MNAME del SOA. Compruébelo en cada zona, no solo en la primera.

Cierre cada papel

• Ponga un frontal consciente del DNS como dnsdist delante de cada secundario público, para rechazar los tipos de consulta de amplificación, limitar la tasa y descartar consultas de zonas que no sirve.
• En los secundarios, rechace NOTIFY desde cualquier origen salvo el primario, y rechace las peticiones AXFR desde internet.

Compruébelo desde fuera

# NS and SOA name only public secondaries
dig +short NS example.com
dig +short SOA example.com

# Every secondary has the same serial
for ns in $(dig +short NS example.com); do
  printf '%s ' "$ns"; dig +short SOA example.com @"$ns" | awk '{print $3}'
done

# Transfers are refused from the internet
dig AXFR example.com @ns1.example.net

# The primary does not answer from outside (expect a timeout)
dig example.com SOA @<primary-address> +time=2 +tries=1

Ejecute la comparación de seriales de forma continua, no una vez. Un secundario que dejó de recibir actualizaciones sigue respondiendo con confianza con datos antiguos; el único síntoma es un serial que se queda atrás. Alerte sobre ello, y alerte si el nombre o la dirección del primario aparecen alguna vez en un registro NS o SOA.

En resumen

El primario es donde usted edita, los secundarios son donde pregunta el mundo, y los dos se encuentran solo en una red privada. Elija transferencias si mezcla fabricantes de DNS, replicación de base de datos si no quiere ninguna superficie de transferencia. Nombre solo a los secundarios, firme la zona, y vigile los seriales.

Construimos y operamos clústeres PowerDNS de esta forma para clientes que quieren ser dueños de su DNS. Si está planificando uno, con gusto le ayudamos.

CTA

Hable con un ingeniero

Related

Relacionado: DNS autoritativo y recursivo sobre PowerDNS · DNS autoritativo y DNS inverso, operados como infraestructura