DNSSEC con Cloudflare: qué protege, qué no protege y cómo activar sin problemas

La confusión más común sobre DNSSEC es describirlo como “cifrado DNS”. Los equipos que parten de esta premisa equivocada llegan a dos conclusiones igualmente erróneas: o descartan la característica porque "ya tenemos TLS", o la activan sin comprender la dependencia operativa que acaban de introducir. DNSSEC firma las respuestas DNS para demostrar su autenticidad; no cifra nada. El ataque que detiene, la consecuencia de una configuración mal gestionada y lo que simplemente no cubre son tres temas distintos que merecen un tratamiento separado.

Qué hace realmente DNSSEC

Cuando un solucionador recursivo consulta a un servidor autorizado y recibe una respuesta, no existe ningún mecanismo en el DNS tradicional para verificar que esa respuesta sea legítima. El ataque de envenenamiento de caché descrito por Dan Kaminsky en 2008 (y variantes posteriores) explota exactamente esto: un atacante inyecta registros falsos en el caché de un solucionador, redirigiendo el tráfico a IP bajo su control sin que el propietario del dominio lo sepa. Los usuarios consultan al solucionador comprometido, reciben una IP maliciosa con una respuesta aparentemente normal y siguen adelante. TLS no resuelve este problema por sí solo: si el usuario fue llevado a un servidor que tiene un certificado válido para el dominio (obtenido, por ejemplo, a través de DV en otra CA), la cadena HTTPS aparece intacta incluso si el destino es fraudulento.

DNSSEC resuelve el problema en la capa DNS, antes de cualquier conexión TCP. Cada respuesta de DNS lleva registros RRSIG: firmas criptográficas generadas con la clave privada de la zona. El solucionador que admite la validación DNSSEC verifica la firma utilizando la clave pública publicada en la zona (registro DNSKEY) y verifica que esta clave pública sea legítima verificando el registro DS en la zona principal: la cadena de confianza desciende desde la raíz, pasa por la zona TLD (.com, .com.br) y llega a su zona. Un registro con una firma inválida o faltante, en una zona que declara soporte DNSSEC, da como resultado SERVFAIL: el solucionador rechaza la respuesta en lugar de transmitir datos potencialmente manipulados.

Lo que DNSSEC no cubre

DNSSEC no cifra las consultas DNS. Un observador en la red aún puede ver qué dominios está consultando; para esto existen DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT), protocolos separados que cifran el transporte. DNSSEC tampoco protege el contenido de su servicio, no mitiga los DDoS contra sus servidores autorizados y no previene la typosquatting o el phishing en dominios que simplemente se parecen al suyo. La garantía es estrecha y específica: las respuestas DNS para su zona, cuando están firmadas correctamente, llegan al solucionador sin manipulación.

Activando en Cloudflare

El proceso técnico en Cloudflare es simple: un botón en el panel DNS de la zona genera el par de claves, comienza a firmar todos los registros en la zona y comienza a servir registros RRSIG automáticamente. La función está disponible en todos los planes, incluido el gratuito. Lo que haga a continuación es lo que determina si DNSSEC funcionará o interrumpirá la producción.

Después de la activación en el panel, Cloudflare muestra el registro DS que necesita para registrarse con su registrador. Este registro DS, publicado en la zona de TLD por el registrador, es el enlace que conecta la confianza del TLD con su zona; sin él, la cadena de confianza está incompleta y los resolutores validados por DNSSEC tratan su zona como no firmada, no como inválida. El proceso de registro de DS varía según el registrador: algunos tienen una interfaz gráfica en el panel de control, otros requieren que ingrese manualmente los campos: Etiqueta clave, Algoritmo, Tipo de resumen y Resumen. Cloudflare muestra todos estos valores formateados después de habilitar DNSSEC.

El problema de la rotación de claves

El riesgo operativo de DNSSEC no está en la activación, sino en el mantenimiento. Cloudflare rota periódicamente las claves DNSSEC de la zona. Cuando esto sucede, el registro DS registrado con el registrador debe actualizarse para reflejar la nueva clave. Si el registrador admite la actualización automática de DS a través de API, como es el caso de Cloudflare Registrar, Amazon Route 53 en modo de dominio registrado y Namecheap con API habilitada, la rotación se produce sin intervención manual. Si el registrador no lo admite, Cloudflare le envía una alerta y tiene un período de tiempo para actualizar manualmente.

La falta de esta ventana tiene una consecuencia directa: el DS en la caja apunta a una clave que la zona ya no utiliza. Los solucionadores validados por DNSSEC comienzan a recibir RRSIG firmado por una clave diferente a la DS publicada, concluyen que se ha producido una manipulación y devuelven SERVFAIL para cualquier consulta a su dominio. Desde el punto de vista del usuario, el dominio simplemente deja de resolverse. La solución requiere actualizar el DS en el registrador y esperar a que se propague el TTL de la zona de TLD, lo cual suele ser largo, del orden de horas, porque no se controla ese TTL.

Activar de forma segura: qué comprobar antes y después

Antes de habilitar DNSSEC, confirme que su registrador acepte registros DS para el dominio en cuestión. Para .com.br dominios, Registro.br ahora admite DNSSEC, pero el soporte histórico ha sido inconsistente; vale la pena verificar directamente en el panel para ver si la opción DS está disponible para su dominio específico antes de activarla en Cloudflare. Activar Cloudflare sin poder registrar el DS con el registrador deja la zona firmada pero sin la cadena de confianza completa, lo que no ofrece ninguna protección adicional y además crea un estado que puede generar confusión en futuros diagnósticos.

Después de activar y registrar el DS, pruebe la validación con herramientas como dnssec-analyzer.verisignlabs.com o dnsviz.net antes de considerar completo el proceso. Estas herramientas muestran cada eslabón de la cadena de confianza e identifican registros RRSIG no válidos, caducados o faltantes. Configure alertas para la rotación de claves (el panel de Cloudflare ofrece notificaciones por correo electrónico) y documente el proceso de actualización de DS en su runbook de operaciones de DNS. Una rotación mal gestionada a las tres de la mañana, con el dominio principal de la empresa devolviendo SERVFAIL, es el tipo de incidente que debería estar en el runbook antes de que suceda, no después.