DNSSEC: qué es, cómo funciona y cómo activarlo sin romper tu dominio

Resumen en 30 segundos (para qué sirve DNSSEC y qué no hace)

DNSSEC añade firmas criptográficas a las respuestas DNS para que los resolvers puedan verificar que no fueron alteradas y que vienen del origen legítimo. Evita ataques como el envenenamiento de caché y permite la “negación autenticada” (demostrar de forma verificable que un nombre no existe).
Lo que NO hace: no cifra el tráfico (para eso está DoH/DoT o TLS a nivel de aplicación), no bloquea DDoS y no arregla un DNS mal configurado.

En mi experiencia con casos de la comunidad, el 90% de los sustos al activar DNSSEC se deben a desajustes del DS en el registrador. La buena noticia: tiene arreglo rápido si sabes dónde mirar.

Así funciona DNSSEC: cadena de confianza explicada

Imagina una cadena que va desde la raíz (.) → TLD (por ejemplo, .com) → tu zona (midominio.com). Cada eslabón “firma” al siguiente, creando una cadena de confianza que los resolvers validadores pueden comprobar.

RRSIG, DNSKEY y el papel del DS

• DNSKEY: publica las claves públicas de tu zona.

• RRSIG: las firmas que acompañan a cada conjunto de registros (A, AAAA, MX, etc.).

• DS (Delegation Signer): vive en la zona padre (el TLD) y contiene un “resumen” de la KSK de tu zona. Es el punte que le dice al validador “confía en las claves de esta zona”.

Cuando probé la activación en entornos reales, el punto crítico fue publicar el DS correcto en el registrador. Si lo pegas con algoritmo o digest equivocado, los validadores ven tu dominio como BOGUS y devuelven SERVFAIL.

KSK vs ZSK: diferencias, tamaños y rotación

• ZSK (Zone Signing Key) firma los registros de la zona.

• KSK (Key Signing Key) firma el DNSKEY set y es la que se refleja en el DS del padre.
  Buenas prácticas: ZSK más “operativa” (rotación más frecuente); KSK más “ceremonial” (rotación menos frecuente y coordinada porque implica tocar el DS).

He visto rollovers donde se rotó la KSK sin actualizar el DS: todo funcionó “localmente” pero los resolvers validadores externos empezaron a fallar minutos después. La moraleja: si cambia KSK, cambia DS en el padre.

NSEC y NSEC3: negación autenticada y (cómo evitar) la enumeración de zona

Para responder “ese nombre no existe” sin abrir la puerta a suplantaciones, DNSSEC usa NSEC (o NSEC3).

• NSEC puede facilitar enumeración de la zona (descubrir nombres).

• NSEC3 usa hashing para dificultar la enumeración.
  Recomendación pragmática: si te preocupa la exposición de nombres internos o previsibles, NSEC3 con opt-out suele ser la elección equilibrada.

Activar DNSSEC paso a paso (registrador + DNS gestionado)

Obtener y publicar el DS (Cloudflare/otros)

1. Activa DNSSEC en tu proveedor de DNS gestionado (Cloudflare, Route 53, Azure DNS, etc.).

2. Copia los parámetros DS que te ofrecen (Key Tag, Algoritmo, Digest Type, Digest).

3. Ve al registrador (donde está el dominio) y pega el DS.

4. Espera propagación (minutos a horas) y valida.

En más de un despliegue comunitario, si el proveedor y el registrador no son la misma empresa, la opción “auto-DNSSEC” no funciona. Hay que pegar el DS manualmente. Suele ser un formulario escondido en “DNSSEC” o “Seguridad” del panel del registrador.

Comprobaciones con dig +dnssec y DNSViz

• dig +dnssec midominio.com A @1.1.1.1 → verifica que llegan RRSIG.

• dig +cdflag midominio.com A @1.1.1.1 → ignora la validación. Si aquí responde pero sin +cdflag da SERVFAIL, tu problema es DNSSEC (normalmente DS o firma).

• dnsviz.net: dibuja la cadena de confianza; detecta DS desincronizado, firmas caducadas o claves ausentes.

Un truco que me ha salvado: cuando DNSViz muestra dos DS y uno es antiguo, pide al registrador eliminar el DS viejo. En cuanto queda uno y coincide con tu KSK vigente, los SERVFAIL desaparecen.

Problemas reales y cómo arreglarlos (servfail, CAA, migraciones)

SERVFAIL por DS desincronizado: diagnóstico rápido

Síntomas: usuarios reportan caídas intermitentes, dig a resolvers validadores devuelve SERVFAIL, pero el authoritative responde bien.
Checklist de 3 pasos:

1. dig +dnssec yourdomain.com DNSKEY y revisa key tags.

2. Compara con el DS publicado en el registrador.

3. Si no coinciden: actualiza DS y depura RRsig caducadas (regenera/forza resign).

Certificados Let’s Encrypt y CAA + DNSSEC

Let’s Encrypt consulta CAA antes de emitir. Si tu zona responde BOGUS por firmas rotas o negaciones mal firmadas, el ACME fallará.
Solución: arregla DNSSEC primero (DS/firma), y si procede, define explícitamente CAA 0 issue "letsencrypt.org".

Lo he visto en foros: todo parecía bien hasta que el bot de ACME no podía validar el CAA; el fix fue regenerar firmas y, por claridad, añadir CAA explícito para evitar interpretaciones dudosas.

Migrar DNS/registrador sin caídas (orden correcto de des/activación)

1. Antes de migrar authoritative DNS, considera desactivar DNSSEC en el padre (eliminando el DS) para evitar que validadores consulten una cadena “mixta”.

2. Cambia los nameservers/zona.

3. Activa DNSSEC en el nuevo proveedor y vuelve a publicar el DS correcto.

4. Valida con DNSViz y dig.

Una anécdota clásica: mover un dominio “con prisas” dejando el DS apuntando a la KSK antigua. Resultado: horas de SERVFAIL global hasta que alguien recordó quitar el DS, propagar y volver a activarlo bien.

Buenas prácticas operativas

Políticas de key rollover y monitorización

• Rollover ZSK: más frecuente (mensual/trimestral).

• Rollover KSK: planificado, con ventana de mantenimiento y comunicación (implica DS).

• Monitorea: caducidad de RRSIG, presencia de CDS/CDNSKEY para rollovers asistidos, alertas cuando DNSViz detecte inconsistencias.

Tamaño de respuestas, EDNS(0) y fallbacks

DNSSEC aumenta el tamaño de respuestas.

• Habilita EDNS(0) y comprueba que tu authoritative soporta UDP fragmentation adecuada o fallback a TCP.

• Evita MTU raras en anycast o middleboxes que corten paquetes grandes.

• Pruebas: dig +dnssec +bufsize=4096 y +tcp para confirmar que no hay truncation destructiva.

FAQs de implementación y seguridad

¿DNSSEC ralentiza el DNS?
Mínimamente. La validación la hace el resolver (no tu web) y el coste extra suele ser imperceptible con buenos caches.

¿Necesito NSEC3 sí o sí?
Si te preocupa la enumeración de nombres, sí; de lo contrario, NSEC puede bastar y simplifica.

¿Puedo automatizar el DS?
Algunos proveedores exponen CDS/CDNSKEY para que el TLD/registrador actualice el DS automáticamente. Aun así, verifica tras cada cambio de KSK.

¿Qué miro cuando “todo cayó” tras activar DNSSEC?

1. ¿El DS en el registrador coincide con tu KSK vigente? 2) ¿Las RRSIG no están caducadas? 3) ¿DNSViz pinta la cadena completa sin huecos?

Conclusión

DNSSEC no es magia, es disciplina operativa: activar, publicar DS correcto, validar y monitorizar. Con un par de comandos (dig +dnssec, +cdflag) y DNSViz en favoritos, puedes desplegarlo con confianza y dormir tranquilo.