Incidencia del 12 de noviembre de 2026
En la madrugada del 12 de noviembre de 2026 falló un servidor central de nuestro centro de Fráncfort. El portal de clientes, el sitio web, la API, DynDNS, las redirecciones web, el webmail y los sitios del alojamiento WordPress no estuvieron disponibles durante algo más de siete horas. Le pedimos disculpas.
En resumen
Alcance
Qué se vio afectado y qué no
Falló el servidor en el que funcionan la administración y los pedidos. La resolución de nombres, el correo y el alojamiento web funcionan de forma independiente de él. El alojamiento WordPress se controla a través de este servidor y por eso también se vio afectado.
No disponible
- Portal de clientes dash con gestión de dominios, editor DNS y facturas
- Sitio web regfish.de con búsqueda de dominios y pedidos
- API DNS y servidor MCP
- Actualizaciones DynDNS (IPv4 e IPv6)
- Redirecciones web de dominios
- Sitios web del alojamiento WordPress
- Interfaces de webmail
- Registros y transferencias de dominios y pedidos de certificados
- Documentación y transferencia de archivos (docs, files)
Disponible en todo momento
- Resolución de nombres de todos los dominios a través de nuestra red anycast, incluido DNSSEC
- Recepción y envío de correo por IMAP, POP3 y SMTP
- Todos los sitios web del alojamiento web
Cronología
Qué ocurrió esa noche
Todas las horas en hora alemana (CET).
- 02:29El servidor se detiene tras un fallo en el núcleo del sistema operativo.
- 02:31Nuestra monitorización avisa de las primeras caídas.
- 03:59Comunicamos la incidencia al centro de datos.
- 04:45Un reinicio a través de la gestión remota arranca el sistema, pero este no logra conectarse a la red. Poco después, la propia gestión remota deja de estar accesible.
- 05:52El centro de datos confirma la avería de la gestión remota. Los trabajos posteriores solo pueden hacerse in situ.
- 07:46 a 08:21Los trabajos in situ en la configuración de red todavía no restablecen la conexión.
- 09:46Mediante un sistema de rescate restablecemos el inicio de sesión en el sistema y ponemos en marcha la conexión de red manualmente.
- 09:55El portal de clientes, el sitio web, la API, DynDNS, las redirecciones web y el alojamiento WordPress vuelven a estar disponibles. La base de datos ha vuelto a arrancar sin pérdida de datos.
- hacia las 10:35También vuelve a funcionar el inicio de sesión en el webmail de webmail.regfish.de. Hasta entonces lo había impedido un ajuste incorrecto en el servidor restablecido.
Causa
Coincidieron cuatro factores
El desencadenante fue un fallo en el núcleo del sistema operativo del servidor: al procesar un paquete de red entrante, el núcleo encontró estructuras de memoria internas dañadas y detuvo el sistema. Ya no podemos determinar qué causó ese daño. No hemos encontrado indicios de un ataque ni de un acceso no autorizado.
Que de ello resultara una caída de varias horas se debe a otros tres factores. El servidor estaba configurado para detenerse tras un fallo así en lugar de reiniciarse. La gestión remota dejó de funcionar poco después del primer reinicio, por lo que ya no era posible otro reinicio a distancia.
Tras el reinicio, la conexión de red no volvió por sí sola. La causa fue un error en nuestra configuración de arranque.
Medidas
Qué hemos cambiado
Aplicado el 12/11/2026
- La configuración de arranque de la red está corregida y se ha comprobado de antemano. Un reinicio de prueba en la ventana de mantenimiento anunciada aportará la confirmación definitiva.
- El servidor se reinicia ahora por sí solo tras un fallo del núcleo.
- Todos los servicios están configurados para arrancar automáticamente y en el orden correcto tras un reinicio.
- Como medida de precaución, una regla de filtrado adicional descarta los paquetes de red con una estructura inusual antes de que el núcleo los procese. No está demostrada ninguna relación con la incidencia.
Previsto
- Actualización del núcleo del sistema operativo en la ventana de mantenimiento anunciada, con reinicio de prueba.
- Reparación de la gestión remota junto con el centro de datos.
- Comprobación de nuestro sistema de alertas fuera del horario laboral, para reaccionar más rápido por la noche.
- Revisión de nuestro plan de emergencia para que el segundo centro pueda asumir antes la administración y los pedidos.
Para usted
¿Tiene que hacer algo?
- Por lo general, no. Su configuración y sus datos no han cambiado. Lo mismo vale para los contenidos y las bases de datos de sus sitios WordPress.
- DynDNS: si su dirección IP cambió durante la incidencia, lance la actualización una vez manualmente en su router o cliente.
- Las automatizaciones a través de la API que fallaron durante la incidencia pueden repetirse sin cambios.
- Ejecutamos los pedidos recibidos antes de la incidencia. No necesita volver a realizarlos.
Nuestro soporte responde a sus preguntas sobre su contrato o sobre pedidos concretos: support@regfish.de