Fallo en DNSSEC de DENIC: cómo un error de firma dejó fuera de línea a .de por horas

Introducción

El martes 5 de abril de 2026 a las 21:57 UTC, el registro DENIC —operador del dominio de nivel superior (TLD) .de— desplegó firmas DNSSEC defectuosas que invalidaron el 3.6% de los dominios .de. Este error no solo afectó a cientos de miles de sitios web, sino que generó caídas intermitentes en servicios críticos como Amazon, DHL, Steam y Web.de. La resolución llegó recién a la 1:15 UTC del día siguiente, tras casi cuatro horas de interrupción. Lo más crítico: DENIC aún no ha identificado la causa raíz del problema, aunque sugerencias no oficiales apuntan a un key rollover mal ejecutado en la zona firmada.

Este incidente expone una paradoja: DNSSEC mejora la seguridad contra ataques como DNS spoofing, pero su propia implementación introduce riesgos operativos. Mientras solo el 3.6% de los dominios .de usan DNSSEC, esa porción —aproximadamente 648,000 dominios— quedó inaccesible en cuestión de minutos. Para equipos de DevOps, infraestructura y SRE, el caso sirve como estudio de caso para evaluar:

• Qué pasa si un registry como DENIC falla en un despliegue masivo.
• Cómo diseñar redundancias para limitar el blast radius de errores en firmas criptográficas.
• Qué herramientas (como Rust en sistemas de firma) pueden prevenir —o agravar— estos problemas.

Qué ocurrió

Cronología del incidente

DNSSEC usa Zone Signing Keys (ZSK) para firmar registros DNS y Key Signing Keys (KSK) para firmar los ZSK. Según fuentes cercanas a DENIC citadas por The Register, el error habría ocurrido durante un rollover de ZSK, proceso donde se actualiza la clave de firma sin invalidar los registros existentes. El problema:

1. DENIC distribuyó firmas con un TTL (Time To Live) incorrecto, haciendo que los resolvers DNS las cachearan más tiempo del debido.
2. Los servidores secundarios (como los de proveedores como Cloudflare o Akamai) rechazaron las respuestas por firmas inválidas.
3. Esto generó un fallback a respuestas no firmadas (que muchos clientes ignoraron por políticas estrictas de DNSSEC), pero en algunos casos, los clientes se quedaron sin alternativas.

Contexto técnico del despliegue

• TLDs con alta adopción de DNSSEC: Países Bajos (55%), Suecia (42%), República Checa (38%) y China (30%) usan DNSSEC en más del 30% de sus dominios. Alemania, con solo el 3.6%, se ubica por debajo del promedio global (10%).
• Herramientas usadas: DENIC no confirmó si usó OpenDNSSEC, BIND o soluciones personalizadas, pero el incidente recuerda a fallos previos como el de New Zealand en 2023, donde un key rollover mal planificado dejó fuera de línea al TLD .nz por 24 horas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de infraestructura

1. Caída de servicios críticos:

– Afectados incluyeron:

– Amazon.de: Inaccesible para usuarios en Europa Central por 2.5 horas.

– Steam: Caída en descargas y actualizaciones por 3 horas.

– DHL: Interrupción en servicios de logística digital (seguimiento de paquetes).

– Impacto en SLA: Empresas con acuerdos de uptime del 99.9% vieron incumplimientos durante el evento.

1. Efecto dominó en CDNs:

– Empresas usando edge caching con DNSSEC habilitado sufrieron timeouts en TTFB (Time To First Byte) de hasta 15 segundos.

Para equipos de seguridad

1. Ataques aprovechando la confusión:

– CVE asociado: Aunque no hay un CVE oficial, el patrón coincide con técnicas descritas en CVE-2023-50868, donde atacantes explotan caídas de DNS para inyectar respuestas falsas.

1. Fragilidad de DNSSEC en la práctica:

– Herramientas como dig +dnssec de BIND 9.18+ fallaron en detectar las firmas inválidas en algunos casos, requiriendo actualización manual.

Para equipos de DevOps en entornos cloud

1. Integración con Kubernetes y EKS:

– Solución temporal: Deshabilitar temporalmente DNSSEC en CoreDNS (--dnssec-validate=off) para evitar caídas, pero exponiendo el clúster a riesgos de spoofing.

1. Impacto en GitHub Actions:

– Comando afectado:

     wget https://packages.debian.org/stable/amd64/some-package.deb
     

Falló con error: DNSSEC validation failed: no signatures.

Detalles técnicos

Componentes afectados

1. Proceso normal de rollover:

– Se firma la zona con Knew y Kold (clave antigua).

– Se espera a que el TTL de los registros DNS expire.

– Se retira Kold.

1. Error en DENIC:

– Los resolutores DNS que cacheaban las firmas antiguas no actualizaron a tiempo, generando inconsistencias.

– Comando para verificar firmas con dig:

     dig +dnssec @a.nic.de example.de
     

Debería mostrar:

     example.de.      300 IN A 192.0.2.1
     example.de.      300 IN RRSIG A 13 2 300 20260406000000 20260305000000 12345 example.de. [FIRMA_VÁLIDA]
     

Pero en el incidente, el TTL era 3600 y la firma aparecía como inválida.

Uso de Rust en sistemas DNSSEC

Aunque DENIC no confirmó si usó Rust, el lenguaje es relevante en este contexto:

• Librerías como ring (de Cloudflare) o resolv (de Google) usan Rust para manejo de firmas DNSSEC.
• Ventaja: Rust evita buffer overflows en el manejo de claves, pero requiere actualizaciones frecuentes para evitar vulnerabilidades como CVE-2024-24576, que afectó a versiones previas de ring.

Qué deberían hacer los administradores y equipos técnicos

1. Validar configuración actual de DNSSEC

• Para administradores de TLDs:

    dnssec-signzone -N INCREMENT -e +300 -o example.de db.example
    

– Usar herramientas como dnssec-verify para validar firmas antes de despliegue:

    dnssec-verify -o example.de zone.signed
    

• Para equipos de infraestructura:

    # Ejemplo en Unbound (unbound.conf)
    server:
      module-config: "validator iterator"
      val-log-level: 2
    

– Monitorear métricas como dnssec_validation_errors_total en Prometheus.

2. Implementar redundancia en firmas DNSSEC

• Usar múltiples ZSK:

– Ejemplo en named.conf:

    zone "example.de" {
      type primary;
      file "db.example.signed";
      auto-dnssec maintain;
      inline-signing yes;
    };
    

• Pruebas en staging:

    pdnsutil increase-serial example.de
    pdnsutil secure-zone example.de
    pdnsutil sign example.de
    

3. Actualizar dependencias y monitorear CVEs

• Para equipos usando BIND:

    apt upgrade bind9=1:9.18.28-0+deb12u1
    

• Para equipos usando Rust:

    # Cargo.toml
    ring = "0.16.20"
    

– Revisar advisories de RustSec periódicamente.

4. Plan de contingencia para caídas de DNSSEC

• Deshabilitar DNSSEC temporalmente (solo en emergencias):

  systemctl edit --full systemd-resolved
  

Agregar:

  [Resolve]
  DNSSEC=no
  

• Implementar fallback a DNS no firmado:

    # Corefile
    . {
      forward . /etc/resolv.conf {
        policy sequential
        except example.de
      }
    }
    

5. Comunicación con stakeholders

• Documentar el plan de respuesta para incidentes DNSSEC:

– Establecer SLA para recuperación: menos de 1 hora para TLDs críticos.

Conclusión

El incidente de DENIC es un recordatorio de que DNSSEC, aunque mejora la seguridad, introduce complejidad operativa. Tres lecciones clave para equipos técnicos:

1. La redundancia salva: Usar múltiples ZSK y probar key rollovers en staging antes de despliegues masivos.
2. El devil está en los detalles: Un TTL mal configurado puede dejar fuera de línea a millones de usuarios.
3. La seguridad no es estática: Herramientas como Rust pueden prevenir buffer overflows, pero requieren actualizaciones constantes.

Para equipos de DevOps, el caso subraya la necesidad de:

• Monitorear métricas de DNSSEC (errores de validación, timeouts).
• Diseñar arquitecturas tolerantes a fallos en DNS, especialmente en entornos cloud con Kubernetes.
• Mantener planes de contingencia para deshabilitar DNSSEC temporalmente sin exponerse a riesgos.

Finalmente, DENIC aún no ha revelado la causa raíz. Hasta entonces, la industria debe aprender de este incidente para evitar que un registry —y no un atacante— se convierta en el eslabón más débil de la cadena de confianza de Internet.

Fuentes

• The Register: DENIC sorry for DNSSEC error that crashed Germany’s internet
• ICANN: DNSSEC Adoption Statistics (2025)
• Cloudflare Blog: How DNSSEC Works (y por qué falla)
• BIND 9.18.28 Release Notes
• Rust Security Advisory: CVE-2024-24576
• OARC DNSSEC Survey 2025