Lunes por la mañana en consultas y farmacias alemanas
Desde el lunes 12 de octubre, muchas consultas médicas, farmacias y clínicas de Alemania tienen problemas para acceder a la Telematikinfrastruktur, la red sanitaria nacional, y Gematik informa de interrupciones para los proveedores cuyos conectores son de Secunet o RISE. Fallan del todo o en parte la comprobación de datos del asegurado (VSDM), la mensajería segura (KIM), las recetas electrónicas, la historia clínica electrónica y las bajas médicas electrónicas.
Los conectores de CGM no están afectados, según Gematik, porque CGM no usa la función en cuestión. La causa es el cambio programado de la clave raíz de DNS.
Gematik prevé que todos los conectores Secunet y RISE en el campo se vean afectados durante la semana si no hay una corrección, y los centros sin conector propio pueden verse afectados si se conectan mediante un conector de centro de datos. Gematik aún no puede decir cuántos conectores están afectados.
Un calendario público durante 21 meses
El cambio de clave estuvo en el calendario público durante 21 meses, y el primer día laborable después trajo igualmente una caída.
| Fecha | Hecho |
|---|---|
| 11 de enero de 2025 | La nueva clave raíz KSK-2024 (etiqueta de clave 38696) se publica en el conjunto DNSKEY de la raíz |
| 11 de agosto de 2026 | ICANN publica una guía sobre qué esperar durante el cambio |
| 6 de octubre de 2026 | Cloudflare avisa de que los resolutores validadores deben confiar en la clave nueva |
| 11 de octubre de 2026 | KSK-2024 empieza a firmar el conjunto DNSKEY de la raíz y KSK-2017 (etiqueta 20326) deja de hacerlo |
| 12 de octubre de 2026 | Gematik informa de interrupciones en conectores Secunet y RISE |
| 13 de octubre de 2026 | heise actualiza su información con las respuestas de Gematik |
La guía de ICANN pedía a los operadores de resolutores validadores de DNSSEC, a los fabricantes de software DNS y a quien tuviera anclas de confianza configuradas a mano que confirmaran que sus sistemas estaban listos antes del 11 de octubre. Cloudflare añadió que un resolutor validador que no confíe en la clave nueva puede dejar inaccesibles sitios web sanos, y que la raíz solo había cambiado una vez antes su clave de firma de claves.
Por qué sobreviven los túneles existentes y fallan los nuevos
A los conectores afectados les falta, al parecer, la nueva ancla de confianza raíz de internet, así que no pueden resolver las direcciones de los servicios de acceso VPN de Arvato y T-Systems ni construir un túnel nuevo hacia la red sanitaria.
Los túneles que ya están levantados no necesitan consultas de nombres nuevas, así que siguen funcionando. Los registros DNSKEY de la raíz también permanecen 48 horas en caché, lo que oculta el fallo hasta que un reinicio o una reconexión encuentra la caché vacía o caducada. Por eso heise informa de que los operadores afectados no deben reiniciar sus conectores.
Gematik describe una solución provisional que el proveedor de servicios in situ debe aplicar a mano, y su guía para conectores Secunet recomienda añadir la nueva ancla de confianza incluso a los conectores que aún funcionan. Para RISE no hay todavía una guía propia, y RISE anunció desde el 8 de octubre el firmware 6.2.3 con lo que llamó una corrección importante, aunque se desconoce si arregla este fallo. Sigue sin estar claro por qué los conectores no adoptaron la clave nueva: la especificación exige actualizaciones automáticas RFC 5011 para el ancla propia de la red sanitaria, pero no está claro que el ancla de internet las reciba.
El precedente de mayo de 2020
A finales de mayo de 2020, unas 80.000 de unas 130.000 consultas y clínicas conectadas no pudieron acceder a algunos servicios de la red sanitaria, y los conectores afectados eran de T-Systems, RISE y Secunet.
Gematik culpó primero a una entrada errónea en su lista de estado de servicios de confianza. La revista c't vinculó después la caída con una nueva ancla de confianza raíz DNSSEC fijada en mayo de 2020 combinada con un error de administración. A mediados de junio de 2020 la sincronización de datos maestros seguía alterada en más de 40.000 consultas, y la recuperación exigió actualizaciones in situ de los proveedores de servicios porque el mantenimiento remoto a menudo no estaba autorizado.
Qué preguntar a sus proveedores antes del próximo cambio de raíz
Empiece por todo dispositivo que construya túneles VPN o valide DNS por su cuenta, como pasarelas, conectores médicos y aparatos embebidos. Pida a cada proveedor que confirme por escrito cómo actualiza su ancla de confianza, por RFC 5011 o a mano, y si ya tiene KSK-2024.
Pruebe un reinicio o una reconexión en una ventana de mantenimiento solo después de esa confirmación y tenga lista la solución manual del proveedor. Cloudflare ofrece una prueba de preparación basada en RFC 8509 para el resolutor que usa su navegador, y dice que la mayoría de los operadores web no necesita actuar.
Ponga los cambios de clave raíz y las caducidades de certificados en el mismo calendario de cambios que las versiones de software. Esta caída tenía fecha, una clave pública y una guía publicada, y el fallo solo apareció cuando pasó la fecha.
Leer a continuación: Yandex Cloud aconsejó a los clientes mudarse de sitio | Tres plazos de soporte de Windows en 30 días
