Kurzfassung
Am 29. Oktober 2025 kam ein DNS-Ausfall bei Microsoft auf, der weite Teile von Azure und Microsoft 365 beeinflusste. Kunden konnten administrative Portale nicht erreichen, Dienste in Outlook, Teams oder SharePoint reagierten verzögert oder gar nicht. Die Ursache war eine fehlerhafte DNS-/Routing-Auflösung in internen Microsoft-Infrastrukturen — das Ereignis zeigt erneut, wie sensibel Abhängigkeiten von DNS-Systemen sind.
1. Was geschah?
Microsoft meldete gegen Abend (in mehreren Zeitzonen) umfangreiche Zugriffsprobleme auf zentrale Dienste, darunter Azure-Verwaltungsportale und Microsoft 365-Komponenten. Fehlerhafte DNS-Resolution verhinderte korrekte Routen zu Endpunkten, was Authentifizierungs- und Servicerufe betraf. Internes Routing wurde umgeleitet, um betroffene Pfade zu umgehen.
2. Betroffene Dienste & Reichweite
Die Störung hatte globalen Charakter — Nutzer in Nordamerika, Europa, Asien und weiteren Regionen meldeten Ausfälle oder Verlangsamungen. Betroffen waren u. a.:
- Microsoft 365 Admin Center – nicht erreichbar
- Outlook, Teams, SharePoint – hohe Latenz oder Fehler bei Zugriff
- Azure Virtual Machines & Storage – zeitweise Unterbrechungen bei Zugriffen
- Authentifizierungsdienste, APIs und Portale, die DNS-Namen benötigen
Einige sekundäre Dienste wie OneDrive-Sync waren weniger betroffen, da sie oft eine lokal gecachte Verbindung nutzen konnten.
3. Technische Analyse & Ursache
Microsoft erklärte, dass interne DNS-Routing- und Netzwerkprobleme ursächlich seien. Interne Endpunkt-Resolution scheiterte in Teilen, so dass Anfragen nicht zu den korrekten Hostnamen geleitet wurden. Microsoft leitete Maßnahmen ein, um betroffene Pfade zu umgehen, Dienste auf alternative Routen umzulenken und DNS-Zonen zu rekonvergieren.
Experten wiesen darauf hin, dass selbst bei Cloud-Riesen DNS ein Single Point of Failure sein kann — insbesondere wenn zahlreiche Dienste von zentralen Namensdiensten abhängig sind.
4. Timeline (Kurzüberblick)
- Initialmeldung: Nutzer meldeten Zugriffsprobleme gegen Abend / Nacht je nach Region.
- Ursachenerkennung: Microsoft identifizierte DNS-Probleme in der internen Infrastruktur.
- Notfallmaßnahmen: Umleitung des Traffics, DNS-Zonenrecovery, Aktivierung redundanter Pfade.
- Wiederherstellung: Dienste liefen stufenweise wieder an, vollständige Stabilität folgte in den darauffolgenden Stunden.
5. Konsequenzen für Unternehmen
Unternehmen erlebten Ausfall von Administrationsportalen, Ausfälle von Kollaborations-Tools, API-Fehler und Verzögerungen in Workflows. Für Organisationen, die auf Microsoft-Dienste gesetzt haben, bedeutete der Ausfall potenziell Produktionsunterbrechungen, erhöhten Supportaufwand und Reputationsrisiken.
6. Lehren & Empfehlungen
DNS-Redundanz planen
Nutzen Sie mehrere DNS-Anbieter oder regionale Resolver, um Single-Points-of-Failure zu vermeiden. Interne DNS-Caches mit TTL-Management können die Auswirkung globaler Störungen abmildern.
Fallback-Pfad definieren
Designen Sie Ihre Dienste so, dass sie bei DNS- oder Routing-Ausfällen über alternative Endpunkte (z. B. statische IPs oder sekundäre Domains) erreichbar bleiben.
Chaos-Tests und Simulationen
Führen Sie regelmäßig gezielte Störsimulationen (z. B. DNS-Blackhole-Tests) durch, um zu prüfen, ob Ihre Systeme resilient und Failover-fähig sind.
Transparente Kommunikation
Entwickeln Sie einen Kommunikationsplan für den Ernstfall – informieren Sie Mitarbeitende, Partner und Kunden klar und zeitnah, um sekundäre Schäden zu verhindern.
Monitoring auf DNS-Ebene
Überwachen Sie nicht nur Serviceverfügbarkeit, sondern auch DNS-Auflösung, Latenz und TTL-Verhalten – kleine Anomalien sind oft frühe Indikatoren bevorstehender Ausfälle.
Kosten gegen Risiko abwägen
Investitionen in Redundanz und Disaster-Recovery-Mechanismen lohnen sich langfristig – sie reduzieren Ausfallkosten, Reaktionszeit und Reputationsschäden erheblich.
7. Fazit
Der DNS-Ausfall bei Microsoft am 29. Oktober 2025 zeigt einmal mehr: DNS ist eine kritische Komponente in Cloud-Architekturen. Selbst große Anbieter sind nicht immun gegen interne Infrastrukturprobleme. Wer robuste Fallbacks, DNS-Resilienz und Resilienztests implementiert, bleibt weniger anfällig bei solchen Ereignissen.