lima-city Outage History

Die Störung wurde von der DENIC behoben: https://blog.denic.de/technische-storung-bei-de-domains-behoben/

Im Zeitraum von ca. 09:54 Uhr bis 10:05 Uhr kam es infolge einer Änderung an unseren Core-Switches zu einer Netzwerkstörung zwischen verschiedenen Teilen unserer Infrastruktur. Dadurch waren zeitweise interne Verbindungen zwischen Diensten beeinträchtigt. In diesem Zusammenhang konnte es dazu kommen, dass SSL-Zertifikate für Webseiten vorübergehend nicht vom internen System abgerufen werden konnten. Ebenfalls möglich waren Konnektivitätsprobleme bei vServern, Cloud-Servern, dem Mail-Server sowie Paketverlust und erhöhte Latenzen. Die Ursache wurde identifiziert und die Störung behoben. Wir entschuldigen uns für die Umstände.

Am Freitag, den 3.4.2026 gegen 16:15 haben wir eine Optimierung für das Caching von Wildcard-SSL-Zertifikaten im SSL-Frontend ausgerollt. Nach Berichten einiger Kunden am Samstag hat diese Änderung dazu geführt, dass für kostenlose Subdomains (*.lima-city.de, *.12hp.de/at/ch, *.lima.zone, *.de.cool usw.) teilweise kein Zertifikat ausgeliefert wurde. Der Browser hat daher einen Zertifikatsfehler und eine ungültige SSL-Verbindung angezeigt. Wir haben diese Änderung dann am Sonntag, 5.4.2026 gegen 20:30 zurückgerollt. Nach den Erkenntnissen aus der ersten Analyse und den Berichten waren keine anderen Domains und Subdomain betroffen, sondern nur die kostenlosen Subdomains. Wir werden die Optimierung vor einem erneuten Roll-out noch einmal überprüfen und entschuldigen uns für die Unannehmlichkeiten.

Aufgrund eines Fehlers am Datenbank-Backend für die SSL-Zertifikate lieferten neue SSL-Verbindungen zu den Webhosting-Services, sofern das Zertifikat nicht im lokalen Cache vorhanden war, von 14:34:12 bis 14:36:21 ein ungültiges Zertifikat. Wir entschuldigen uns für die Unannehmlichkeiten.

Wir konnten das Problem auf eine fehlerhafte Seccomp-Policy (Security Policy) zurückführen. Im Zeitraum von 13:23 bis 13:33 haben wir auf dem System erhöhte Fehlerraten für Web-Zugriffe beobachtet, zusätzlich war für einen kurzen Zeitraum kein Datenbank- und FTP-Zugang möglich. Wir bitten um Entschuldigung für die Unannhmlichkeiten.

Auf dem SMTPS-Port (465) des Mail-Service ist auf dem Load Balancer ab 9:05 bis ca. 9:35 ein abgelaufenes Zertifikat ausgeliefert worden. Das ausgelaufene Zertifikat war bereits verlängert, wurde aber nicht nachgeladen. Andere Porte (IMAP, POP3, SMTP, Submission-Port) waren nicht betroffen. Wir untersuchen noch den Prozess und beheben mögliche Schwachstellen. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Grund für die Probleme war starker Bot-Traffic auf dem SMTPS-Port, den wir inzwischen effektiv filtern. Seit ca. 12:15 ist der SMTPS-Port wieder stabil. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Wir haben eine unerwartete Konfigurationsänderung des MySQL-Load-Balancers nach einem Neustart vor ca. 9 Monaten entdeckt, welche heute dazu geführt hat dass nicht ausreichend Verbindungen herstellbar waren um die Last zu bewältigen. Das Problem wurde dauerhaft gelöst und ist seit 9:35 nicht mehr aufgetreten. Der betroffene Zeitraum war zwischen 7:55 und 9:35. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Aufgrund eines hängenden PHP-Containers und eines notwendigen, vollständigen Neustart des Systems waren die Webseiten auf dem Webhosting-Server "nestis" im Zeitraum von 7:50 bis 8:01 nicht erreichbar. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Um Verbindungsprobleme von externen Systemen zu beheben mussten wir den MySQL-Server auf dem Webspace-Server "nestis" kurzfristig neu starten. Der MySQL-Server war daher von ca. 13:15 bis 13:18 nicht verfügbar. Vorher waren externe Verbindungen, u.a. auch von unserem phpMyAdmin, nicht möglich. Mit dem Neustart wurde das Problem gelöst. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Wir haben den kompletten Server gegen ein neues System getauscht, damit wir das defekte Systeme eingehend prüfen können. Die Downtime dauerte von ca. 9:52 bis 11:19. Wir bitte um Entschuldigung für die Unannehmlichkeiten. Allen betroffenen Kunden steht eine Entschädigung nach unserer Verfügbarkeitsgarantie zu. Sofern diese in Anspruch genommen werden soll bitte einfach kurz ein Ticket an uns schreiben, und wir veranlassen die Erstattung.

Wir haben die Situation länger beobachtet und konnten keine Einschränkungen mehr feststellen. Es wurden DNS-Zonen auf unserem DNS-Service angegriffen welche sowohl intern als auch extern verwendet wurden, so dass diverse Dienste bei uns eingeschränkt waren, da die nötigen DNS-Lookups nicht möglich waren. Betroffen waren u.a. die Verwaltung sowie der E-Mail-Service. Nach 13:30 waren die Probleme laut unseren Logs vollständig beseitigt. Wir entschuldigen uns für die Unannehmlichkeiten und bereiten den Vorfall selbstverständlich nach um in Zukunft einen stabileren Service bieten zu können.

Aufgrund eines Crashs des Linux-Kernels war der Webhosting-Server "kratos" im Zeitraum von ca. 6:33 bis 6:50 nicht erreichbar. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Die Situation scheint nun stabilisiert zu sein, vielen Dank für die Geduld.

Im Zeitraum von ca. 15:37 bis 19:00 war auf einem Hypervisor der Cloud-Services ein langsam degradierender Kernel-Absturz festzustellen, der sich erst verzögert äußerte. Wir haben das System gegen 19:00 neu gestartet nachdem kein Management mehr möglich war und die VMs auf dem System betroffen waren. Für wenige Minuten waren durch den Reboot die auf dem System gehosteten VMs nicht erreichbar. Auf dem System war unter anderem ein DKIM-Signer für unseren E-Mail-Service gehostet, wodurch einige wenige E-Mails in diesem Zeitraum nicht signiert wurden und ggf. durch DMARC-Richtlinien abgewiesen wurden. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Im Zeitraum von 3:38 bis 10:15 war der Freespace-Server "bonecrusher" aufgrund des gleichen Fehlerbilds wie der Server "pointblank" am 19.1. nicht verfügbar. Ein Hardware-Defekt konnte im Rechenzentrum nicht festgestellt werden, obwohl auch in diesem Fall Probleme auftraten, den Server automatisiert oder manuell neu zu starten. Eine genaue Analyse dieses Fehlerfalls steht noch aus.

Im Zeitraum von 12:25 bis 12:37 kam es während des routinemäßigen Einspielens eines Software-Updates auf dem Mail-Service zu einem Fehler, bei dem per SMTP eingelieferte E-Mails temporär mit einem "Temporary lookup failure" abgelehnt wurden. Wir entschuldigen uns für die Unannehmlichkeiten.

Im Zeitraum von ca. 17:48 bis 20:20 war der Login in die Verwaltung sowie die Verwaltung zeitweise nicht erreichbar. Die Ursache ist nach einer ersten Einschätzung ein kaskadierendes Problem, das letztendlich dazu führte dass die Anwendung die Login-Seite nicht anzeigen konnte. Bestehende Logins waren nicht betroffen und konnten die Verwaltung regulär nutzen. Wir untersuchen das Problem noch genauer und prüfen, wie es schneller erkennbar gewesen wäre. Wir entschuldigen uns für die Unannehmlichkeiten.

Aufgrund einer Datenbank-Störung war die Verwaltung und unsere Webseite zwischen ca. 2:21 und 3:30 mehrfach für einen kurzen Zeitraum nicht erreichbar. Wir entschuldigen uns für die Unannehmlichkeiten.

Im Zeitraum von 13:31 bis 13:51 war das Webmail mit einem "Fehler 502" nicht erreichbar. Das Problem war auf das Webmail begrenzt, Clients, welche per IMAP/POP3/SMTP auf den E-Mail-Service zugegriffen haben waren nicht betroffen. Wir bitten um Entschuldigung für die Unannehmlichkeiten.

Im Zeitraum vom 14.6., ca. 16:00 bis 15.6., 12:30 kam es zur Problemen bei der Auflösung von Subdomains unter lima-ftp.de, wodurch die FTP-Server nicht über die regulären Hostnamen erreichbar waren. Die FTP-Server selbst liefen ohne Probleme, und die Monitoring-Meldung für die DNS-Domain war nicht eindeutig, daher wurde das Problem leider erst sehr spät korrekt identifiziert. Wir entschuldigen uns für die Unannehmlichkeiten.