Incident du 12 novembre 2026
Dans la nuit du 11 au 12 novembre 2026, un serveur central de notre site de Francfort est tombé en panne. Le portail client, le site web, l’API, DynDNS, les redirections web, le webmail et les sites de l’hébergement WordPress ont été indisponibles pendant un peu plus de sept heures. Nous vous prions de nous en excuser.
En bref
Impact
Ce qui a été touché et ce qui ne l’a pas été
Le serveur tombé en panne est celui qui fait fonctionner l’administration et les commandes. La résolution de noms, l’e-mail et l’hébergement web en sont séparés. L’hébergement WordPress est piloté par ce serveur et a donc été touché lui aussi.
Indisponible
- Portail client dash avec gestion des domaines, éditeur DNS et factures
- Site regfish.de avec recherche de domaines et commande
- API DNS et serveur MCP
- Mises à jour DynDNS (IPv4 et IPv6)
- Redirections web de domaines
- Sites de l’hébergement WordPress
- Interfaces de webmail
- Enregistrements et transferts de domaines, commandes de certificats
- Documentation et transfert de fichiers (docs, files)
Disponible en continu
- Résolution de noms de tous les domaines via notre réseau anycast, DNSSEC compris
- Réception et envoi d’e-mails via IMAP, POP3 et SMTP
- Tous les sites de l’hébergement web
Chronologie
Ce qui s’est passé cette nuit-là
Toutes les heures sont en heure allemande (CET).
- 02:29Le serveur s’arrête après une erreur dans le noyau du système d’exploitation.
- 02:31Notre supervision signale les premières pannes.
- 03:59Nous signalons l’incident au centre de données.
- 04:45Un redémarrage via la gestion à distance relance le système, mais celui-ci ne parvient pas à se connecter au réseau. Peu après, la gestion à distance elle-même n’est plus accessible.
- 05:52Le centre de données confirme la panne de la gestion à distance. La suite des travaux n’est possible que sur place.
- 07:46 à 08:21Les interventions sur place sur la configuration réseau ne rétablissent pas encore la connexion.
- 09:46Au moyen d’un système de secours, nous rétablissons l’ouverture de session sur le système et mettons la connexion réseau en service manuellement.
- 09:55Le portail client, le site web, l’API, DynDNS, les redirections web et l’hébergement WordPress sont de nouveau accessibles. La base de données a redémarré sans perte de données.
- vers 10:35La connexion au webmail webmail.regfish.de fonctionne de nouveau elle aussi. Jusque-là, un réglage incorrect sur le serveur rétabli l’empêchait.
Cause
Quatre facteurs se sont conjugués
Le déclencheur a été une erreur dans le noyau du système d’exploitation du serveur : en traitant un paquet réseau entrant, le noyau a rencontré des structures mémoire internes corrompues et a arrêté le système. Nous ne pouvons plus établir ce qui a causé cette corruption. Nous n’avons trouvé aucun indice d’attaque ni d’accès non autorisé.
Trois autres facteurs expliquent que cela ait entraîné une panne de plusieurs heures. Le serveur était configuré pour s’arrêter après une telle erreur au lieu de redémarrer. La gestion à distance est tombée en panne peu après le premier redémarrage, si bien qu’un nouveau redémarrage à distance n’était plus possible.
Après le redémarrage, la connexion réseau n’est pas revenue d’elle-même. La cause était une erreur dans notre configuration de démarrage.
Mesures
Ce que nous avons changé
Réalisé le 12/11/2026
- La configuration de démarrage du réseau est corrigée et a été vérifiée au préalable. Un redémarrage d’essai lors de la fenêtre de maintenance annoncée en apportera la preuve définitive.
- Le serveur redémarre désormais de lui-même après une erreur du noyau.
- Tous les services sont configurés pour démarrer automatiquement et dans le bon ordre après un redémarrage.
- Par précaution, une règle de filtrage supplémentaire rejette les paquets réseau de structure inhabituelle avant que le noyau ne les traite. Aucun lien avec l’incident n’est établi.
Prévu
- Mise à jour du noyau du système d’exploitation lors de la fenêtre de maintenance annoncée, avec redémarrage d’essai.
- Réparation de la gestion à distance avec le centre de données.
- Vérification de notre système d’alerte en dehors des heures ouvrées, afin de réagir plus vite la nuit.
- Révision de notre plan d’urgence afin que le second site puisse reprendre plus vite l’administration et les commandes.
Pour vous
Devez-vous faire quelque chose ?
- En général, non. Vos réglages et vos données sont inchangés. Cela vaut aussi pour les contenus et les bases de données de vos sites WordPress.
- DynDNS : si votre adresse IP a changé pendant l’incident, lancez une fois la mise à jour manuellement dans votre routeur ou votre client.
- Les automatisations via l’API qui ont échoué pendant l’incident peuvent être relancées telles quelles.
- Nous exécutons les commandes reçues avant l’incident. Vous n’avez pas besoin de les passer une seconde fois.
Notre support répond à vos questions sur votre contrat ou sur une commande précise : support@regfish.de