Qué hace realmente DNSSEC

DNSSEC (extensiones de seguridad DNS) añade una capa de firmas criptográficas a los registros DNS. En lugar de confiar en que la respuesta a "¿cuál es la IP de example.com?" es auténtica, un resolver compatible con DNSSEC puede verificar que la respuesta fue firmada por el propietario legítimo de example.com — ascendiendo por toda la cadena hasta la zona raíz.

Sin DNSSEC, un atacante que intercepte tráfico DNS (en una WiFi hostil, mediante un secuestro BGP o a través de un resolver comprometido) puede sustituir silenciosamente su propia IP y redirigir a los usuarios a un sitio de phishing o malware. El navegador ve un handshake TLS válido con cualquier sitio que esté en esa IP — sólo tiene que convencer a una CA para que emita un certificado, o confiar en que el usuario no note el dominio incorrecto.

DNSSEC cierra esa brecha. Una respuesta firmada no puede ser falsificada sin la clave privada.

Por qué la mayoría de sitios aún no lo habilita

A fecha de 2026, menos del 5% de los dominios .com tienen DNSSEC habilitado. Los motivos:

  • Las configuraciones incorrectas son catastróficas. Un registro DS erróneo en el registry frente a la clave de firma real en tu proveedor DNS provoca que tu dominio falle en TODOS los resolvers compatibles con DNSSEC — tu sitio queda oscuro para los usuarios de Google Public DNS, Cloudflare 1.1.1.1 y Quad9. La recuperación requiere coordinación con el registry.
  • La superficie de ataque para la amenaza se está reduciendo. HTTPS + HSTS + Certificate Transparency gestionan ahora la mayoría de escenarios de "sitio incorrecto" porque el sitio equivocado no puede obtener fácilmente un certificado válido. DNSSEC añade una capa por encima de eso, pero el beneficio de seguridad marginal es menor que en 2005.
  • Sobrecarga operativa. Migrar de proveedor DNS se convierte en un proceso de varios pasos: desactiva DNSSEC, espera, migra, vuelve a activar. Los errores rompen el dominio durante horas.
  • La mayoría de resolvers no lo aplican. Incluso si habilitas DNSSEC, sólo los resolvers que validan (unos 25–30% de las consultas globales) comprueban la firma. Los demás aceptan los datos sin firmar que el atacante sustituiría.

Cuándo merece la pena DNSSEC

Habilita DNSSEC cuando:

  • Eres una institución financiera, proveedor sanitario o servicio gubernamental. Los reguladores pueden exigirlo; los usuarios lo esperan; el modelo de ataque dirigido justifica el coste operativo.
  • Gestionas credenciales directamente — dominios de autenticación para SSO, gestores de contraseñas, proveedores de identidad.
  • Eres suficientemente valioso para ser objetivo de APTs. Si un adversario a nivel de estado está en tu modelo de amenaza, cada capa importa.
  • Tu DNS está en un proveedor gestionado que se encarga de DNSSEC por ti (Cloudflare, AWS Route 53, Google Cloud DNS). El "coste operativo" es esencialmente cero — activa un interruptor.

Cuándo saltarse DNSSEC

  • Sitio de marketing, blog, SaaS pequeño. Los vectores de ataque que DNSSEC defiende son poco comunes, tu modelo de amenaza probablemente no los incluye, y una mala configuración te cuesta tiempo de actividad.
  • Tienes DNS en un servidor de nombres único autogestionado. Sin redundancia y disciplina en la rotación de claves, DNSSEC añade riesgo sin protección real.
  • Tu proveedor DNS no lo soporta de forma nativa. Algunos proveedores heredados requieren gestión manual de claves — de ahí vienen la mayoría de interrupciones.

Cómo habilitar DNSSEC en los proveedores más comunes

  • Cloudflare — pestaña DNS → DNSSEC → Habilitar. Cloudflare genera las claves automáticamente; copia el registro DS en el panel de tu registrador.
  • AWS Route 53 — Zona alojada → Firma DNSSEC → Habilitar. AWS proporciona el registro DS para el registrador.
  • Google Cloud DNS — Zona → DNSSEC → Habilitar.
  • Registradores habituales — Namecheap, Porkbun y GoDaddy permiten pegar un registro DS en la configuración del dominio. El registro DS viene de tu proveedor DNS; el registrador lo publica en la zona padre.

La regla de UN SOLO SENTIDO: debes publicar el registro DS correcto en el registrador ANTES de activar la firma en el proveedor DNS. Hacerlo en el orden equivocado causa interrupciones.

Configuraciones incorrectas habituales

  • El registro DS en el registrador no coincide con la clave en el proveedor DNS. Después de una rotación de claves, ambos lados necesitan actualizarse. Los resolvers fallarán en la validación hasta que se sincronicen. Resultado: el sitio parece roto para ~25–30% de los usuarios.
  • Migrar de proveedor DNS sin deshabilitar DNSSEC primero. El nuevo proveedor tiene una clave nueva; el registry aún tiene el registro DS antiguo. Falla la validación. Siempre: deshabilita, migra, vuelve a habilitar.
  • Desajuste de algoritmo. Algunos registradores sólo aceptan algoritmos de firma específicos. Mejor práctica moderna: ECDSA Curve P-256 (algoritmo 13). Evita el RSA-SHA1 heredado.
  • Olvidar renovar DNSSEC después de una transferencia de dominio. Muchos registradores eliminan los registros DS en la transferencia. Vuelve a añadirlos inmediatamente o tu dominio se rompe en los resolvers validadores.

Trade-offs

DNSSEC añade:

  • Respuestas DNS ~10–30% más grandes (las firmas ocupan bytes).
  • Resolución DNS ligeramente más lenta (los pasos de validación añaden viajes de ida y vuelta).
  • Complejidad operativa en las migraciones de DNS.
  • Una reducción real de la superficie de ataque por suplantación — para lo que realmente sirve.

La recomendación práctica

  • Si tu DNS está en Cloudflare u otro proveedor gestionado importante: habilita DNSSEC. El coste operativo es un clic y la ventaja, aunque pequeña para la mayoría de sitios, es real.
  • Si autoalojas el DNS o usas un proveedor pequeño: omítelo hasta que entiendas la rotación de claves y tengas monitorización para los fallos de validación.
  • Si estás regulado o manejas credenciales: habilita DNSSEC y documenta el procedimiento de recuperación antes de necesitarlo.

El resumen honesto: DNSSEC es una defensa competente contra una clase de ataque real pero acotada. Es un "debería" para los sitios grandes, un "opcional" para el resto, y un "omítelo" si no puedes soportarlo operativamente.