NIS2 y DNS — Lo que los operadores regulados en la UE deben saber

La Directiva NIS2 (Directiva (UE) 2022/2555) es la regulación insignia de ciberseguridad de la UE. Amplía y endurece la Directiva NIS original, eleva los requisitos mínimos de ciberseguridad en toda la Unión y trae a decenas de miles de nuevas entidades al ámbito. Para cualquiera que opere DNS en o para la UE, NIS2 ya no es opcional — es el suelo legal.

Esta guía cubre lo que NIS2 significa específicamente para DNS: qué entidades están en el ámbito, cómo se ven las medidas de gestión de riesgos del Artículo 21 en operaciones DNS, los plazos de notificación de incidentes que un proveedor DNS debe cumplir, y una lista de comprobación lado comprador para evaluar si su proveedor DNS está listo para NIS2.

Qué es NIS2 y por qué existe

NIS2 fue adoptada en diciembre de 2022 y los estados miembros tenían hasta el 17 de octubre de 2024 para transponerla a derecho nacional. Reemplaza la Directiva NIS de 2016 (NIS1), ampliamente criticada por aplicación inconsistente, cobertura sectorial estrecha y poderes de supervisión débiles.

El objetivo declarado de la directiva es establecer un alto nivel común de ciberseguridad en toda la Unión. Lo hace mediante:

1. Ampliar la lista de sectores cubiertos, incluyendo infraestructura digital, administración pública, producción de alimentos y gestión de residuos.
2. Bajar los umbrales de tamaño — la mayoría de organizaciones medianas (>=50 empleados o >=10 M EUR) están ahora en el ámbito.
3. Imponer dos niveles de supervisión: entidades esenciales (supervisión proactiva, obligaciones más altas) y entidades importantes (supervisión reactiva, ligeramente menos exigente).
4. Elevar las multas: hasta 10 M EUR o el 2 % de la facturación anual global para entidades esenciales, 7 M EUR o el 1,4 % para entidades importantes.
5. Introducir responsabilidad personal de los órganos de dirección que no cumplan obligaciones de ciberseguridad.
6. Armonizar los plazos y contenido de notificación de incidentes en toda la UE.

Si su organización está en el ámbito, NIS2 no es un régimen blando. Los reguladores nacionales (BSI en Alemania, ANSSI en Francia, NCSC-NL en Países Bajos, INCIBE en España, ACN en Italia, etc.) tienen ahora poderes explícitos para inspeccionar, auditar y multar.

Dónde encaja DNS en NIS2

El Anexo I de NIS2 lista los sectores de alta criticidad. Bajo el epígrafe "infraestructura digital", se nombran explícitamente como entidades esenciales:

• Operadores de puntos de intercambio de Internet
• Proveedores de servicios DNS (excluidos los operadores de servidores raíz)
• Registros de nombres de TLD
• Proveedores de servicios de computación en la nube
• Proveedores de servicios de centros de datos
• Proveedores de redes de distribución de contenidos
• Prestadores de servicios de confianza (eIDAS)
• Proveedores de redes públicas de comunicaciones electrónicas
• Proveedores de servicios de comunicaciones electrónicas disponibles públicamente

La frase "proveedores de servicios DNS" es amplia. Capta a los proveedores DNS autoritativos (entidades que responden consultas sobre una zona — DNScale, Cloudflare DNS, Route 53, ClouDNS, DNS Made Easy, Dyn, etc.), operadores de resolutores recursivos públicos (Quad9, OpenDNS, Cloudflare 1.1.1.1, Google Public DNS) y proveedores de servicios DNS empresarial / gestionado. El DNS interno / privado usado solo por una organización generalmente no está en el ámbito como servicio, aunque puede serlo como parte de la infraestructura más amplia de esa organización.

Los estados miembros pueden ampliar la lista — el borrador alemán NIS2UmsuCG, por ejemplo, trata a algunos proveedores de hosting de manera más amplia que el mínimo de la UE.

Artículo 21 — Las medidas de gestión de riesgos

El Artículo 21 es el corazón operativo de NIS2. Obliga a entidades esenciales e importantes a tomar "medidas técnicas, operativas y organizativas adecuadas y proporcionadas" para gestionar los riesgos de ciberseguridad. La directiva lista 10 categorías de medidas:

1. Análisis de riesgos y políticas de seguridad de los sistemas de información
2. Gestión de incidentes
3. Continuidad del negocio, incluyendo gestión de copias de seguridad y recuperación
4. Seguridad de la cadena de suministro, incluyendo seguridad de las relaciones con proveedores y prestadores de servicios directos
5. Seguridad en la adquisición, desarrollo y mantenimiento de sistemas de redes e información, incluyendo gestión y divulgación de vulnerabilidades
6. Procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad
7. Prácticas básicas de ciberhigiene y formación en ciberseguridad
8. Políticas y procedimientos sobre el uso de criptografía y, cuando proceda, cifrado
9. Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos
10. Uso de autenticación multifactor o de soluciones de autenticación continua, comunicaciones de voz/vídeo/texto seguras y sistemas de comunicaciones de emergencia seguros

Para DNS específicamente, esto se traduce en requisitos operativos concretos:

1. Gestión de incidentes para caídas y compromisos DNS

Un proveedor DNS debe tener procedimientos escritos para responder a:

• Caídas autoritativas en un PoP, región o globalmente
• Ataques DDoS contra la red anycast
• Compromiso de datos de zona (modificación no autorizada de registros de cliente)
• Compromiso de claves DNSSEC (exposición de claves privadas KSK o ZSK)
• Compromiso de cuentas de operador que pueda llevar a cambios de registros

Los procedimientos deben incluir detección, contención, erradicación, recuperación y análisis post-incidente. Deben probarse. Los clientes deben esperar un contacto de seguridad, un runbook de respuesta a incidentes y un RTO/RPO publicado para el servicio DNS.

2. Criptografía cuando proceda

DNSSEC es el control criptográfico más directamente relevante para DNS. Bajo el Artículo 21(2)(h), un proveedor DNS que no ofrezca DNSSEC en absoluto corre el riesgo de ser juzgado no conforme para clientes de alta criticidad. Funcionalidades DNSSEC esperadas en 2026:

• Soporte de algoritmos: ECDSA P-256 (algoritmo 13) o Ed25519 (algoritmo 15) — RSA-SHA256 (algoritmo 8) es aceptable pero considerado legado.
• Rotación automatizada de claves (KSK y ZSK) sin tiempo de inactividad para el cliente.
• Almacenamiento seguro de claves — respaldado por HSM o equivalente.
• Reporte público del DS vía API para automatización con el registrador.

Para datos en tránsito entre interfaces de operador y clientes, TLS 1.2+ con suites de cifrado modernas es el mínimo.

3. Seguridad de la cadena de suministro — Artículo 21(2)(d)

Esta disposición es donde NIS2 alcanza a los clientes de proveedores DNS. El Artículo 21(2)(d) obliga a cada entidad en el ámbito a gestionar la seguridad de las relaciones con proveedores directos. Si su proveedor DNS tiene un incidente de seguridad que le afecta, los reguladores esperan que haya hecho la diligencia debida con anterioridad.

En la práctica, esto significa:

• Documentar los proveedores en su cadena DNS (registrador, host DNS primario, host DNS secundario, resolutor recursivo gestionado si aplica).
• Obtener evidencia de su postura de seguridad (certificaciones, informes de auditoría, política de seguridad pública).
• Establecer SLAs contractuales para notificación de incidentes y recuperación.
• Reevaluar con cadencia documentada (anualmente como mínimo).

4. Autenticación multifactor

El Artículo 21(2)(j) exige MFA para interfaces de gestión. Para DNS eso significa:

• MFA en el panel del cliente del proveedor DNS.
• MFA en el registrador donde se gestionan los registros NS (seguridad de delegación).
• Gestión de claves de API con permisos restringidos y política de rotación.
• Sin credenciales compartidas de larga duración; las cuentas de servicio deben ser auditables.

5. Continuidad del negocio y copias de seguridad

Continuidad específica de DNS:

• Anycast multi-región para que un fallo regional aislado no deje una zona fuera de línea.
• DNS multi-proveedor para zonas del nivel más alto — ver /learning/multi-provider-dns-deployment.
• Copias de seguridad de datos de zona que se puedan restaurar rápidamente en otro proveedor.
• Procedimientos de recuperación probados con RTO/RPO documentados.

Artículo 23 — Plazos de notificación de incidentes

El Artículo 23 establece los plazos de notificación que los proveedores DNS deben cumplir. Un "incidente significativo" es uno que:

• Ha causado o puede causar interrupción operativa sustancial de los servicios o pérdida financiera
• Ha afectado o puede afectar a otras personas físicas o jurídicas causando un daño material o inmaterial considerable

Para DNS, esto incluye caídas autoritativas prolongadas, fallos de validación DNSSEC causados por error del proveedor, cambios no autorizados a datos de zona del cliente o compromiso de claves privadas DNSSEC.

Cadencia de notificación:

Estos plazos se aplican al proveedor DNS como entidad en el ámbito. Los clientes pueden tener obligaciones de notificación separadas ante sus propios reguladores si el incidente DNS causa impacto aguas abajo en su propio sector.

Las 24 horas de alerta temprana son ajustadas. Un proveedor DNS debe tener monitorización, paginación y un notificador designado listos para presentar al CSIRT nacional o autoridad competente. No es un ejercicio trimestral.

Qué significa esto para los clientes DNS — una lista de comprobación práctica

Si su organización está en el ámbito de NIS2 (o es proveedor de una entidad cubierta), aquí tiene una lista práctica para evaluar su proveedor DNS:

Diligencia del proveedor

• El proveedor está nombrado / dispuesto a confirmar por escrito si está en el ámbito como proveedor de servicios DNS bajo NIS2.
• Jurisdicción primaria del proveedor y autoridad competente que lo supervisa.
• Postura de seguridad pública: security.txt, política de divulgación de vulnerabilidades y estado publicado para reportes de seguridad cifrados.
• Informes post-incidente públicos para incidentes significativos previos (si los hay).
• Procedimiento documentado de respuesta a incidentes y SLA de notificación en su contrato.

Controles técnicos

• Soporte DNSSEC con algoritmos modernos (ECDSA P-256 o Ed25519).
• Almacenamiento seguro de claves respaldado por HSM o equivalente.
• MFA en el panel de cliente.
• Claves de API granulares (limitadas a la zona, con vencimiento, rotables) — ver /learning/multi-user-accounts.
• Anycast multi-región — ver /learning/anycast-dns-network.
• Registro de auditoría de todas las acciones del panel y la API, retenido según su política de retención.

Resiliencia

• RTO/RPO documentados para el servicio autoritativo.
• Mecanismo para exportar datos de zona bajo demanda para portabilidad.
• Disposición multi-proveedor (soporte Terraform / DNSControl) — ver /learning/multi-provider-dns-deployment.

Consideraciones específicas UE

• El proveedor opera infraestructura bajo jurisdicción UE si su sector requiere residencia de datos.
• El tráfico de consultas DNS puede confinarse a PoPs UE (por ejemplo, el set de servidores de nombres UE de DNScale — ver /learning/dns-delegation-by-region).
• Contratos bajo derecho de la UE y resolución de disputas UE.

Dónde encaja DNScale

DNScale opera como proveedor DNS bajo jurisdicción UE con un modelo operativo consciente de NIS2:

• Operaciones UE: infraestructura y operaciones dentro de la UE; el tráfico de consultas puede confinarse a PoPs UE vía el set de servidores de nombres UE.
• DNSSEC: ECDSA P-256 por defecto; rotación automatizada de claves; almacenamiento de claves respaldado por HSM.
• MFA + claves API restringidas: MFA en el panel, claves limitadas a la zona, registro de auditoría completo — ver /learning/multi-factor-authentication-guide y la documentación de claves API DNScale.
• Anycast multi-región vía /learning/anycast-dns-network y /learning/global-dns-resolution-balancing para resiliencia.
• Disposición multi-proveedor: los providers Terraform y DNSControl ya están disponibles — ver /learning/terraform-provider-guide y /learning/dnscontrol-guide.
• Artefactos de seguridad públicos: security.txt y política de divulgación de vulnerabilidades en ubicaciones estándar; informes post-incidente publicados cuando proceda.

Para sectores donde la aplicación de NIS2 es más activa — financiero, energía, administración pública, sanidad — mover el suministro DNS a un proveedor bajo jurisdicción UE con controles alineados con NIS2 reduce tanto el riesgo regulatorio como la carga documental de la cadena de suministro bajo el Artículo 21(2)(d).

Referencias

• Directiva (UE) 2022/2555 — la Directiva NIS2
• Guía ENISA sobre la implementación de NIS2 — recursos prácticos para entidades cubiertas
• Borrador BSI NIS2UmsuCG — transposición alemana
• Guía ANSSI NIS 2 — transposición francesa
• RFC 8945 — TSIG (autenticación de transferencias de zona, relevante para medidas de criptografía)
• RFC 4034/4035 — protocolo núcleo DNSSEC
• RFC 8901 — DNSSEC multi-firmante (relevante para despliegues multi-proveedor)

Lecturas relacionadas

• Mejores prácticas de seguridad DNS — endurecimiento operativo
• Gestión de claves DNSSEC — criptografía en la práctica
• Despliegue DNS multi-proveedor — resiliencia de la cadena de suministro
• DNScale vs Cloudflare — comparación bajo jurisdicción UE
• Mejores proveedores DNS UE — marco de evaluación
• Proveedores DNS conformes con RGPD — marco regulatorio adyacente