Wie DNS-Fehler unsichtbare Downtime verursachen

Observability-Plattformen sind darauf ausgelegt zu verfolgen, was Ihre Systeme tun. Aber was passiert, wenn ein Ausfall auftritt, bevor eine Anfrage überhaupt den Rand Ihrer Infrastruktur erreicht? Ihre Dashboards werden zuversichtlich 100 % Uptime melden, während Ihre Kunden einen anhaltenden Blackout erleben.

Das Split-Horizon-Dilemma

Der Grund, warum Ihre Metriken lügen, liegt in der Split-Horizon-Natur des Cloud-Networking. Ihre internen Kubernetes-Pods auflösen Service-Endpunkte über einen privaten VPC-Resolver. Da das interne Netzwerk makellos ist, sind die Health Checks erfolgreich.

But external customers rely on the public internet's recursive resolution chain to discover your public-facing Ingress.

Wenn das Tor verschwindet

Ein 'unsichtbarer' Ausfall tritt auf, wenn die öffentlichen autoritativen Einträge gestört sind. Ein Beispiel war der Slack-Ausfall 2021: Eine Konfiguration entfernte versehentlich alle A-Einträge für Haupt-APIs.

Intern funktionierten die Server von Slack, verarbeiteten Jobs im Hintergrund. Aber kein neuer Client konnte die Domain 'slack.com' auflösen. Das Internet vergaß einfach, wo Slack gehostet wurde.

Die Lücke isolieren

Um diese Diskrepanz zu beweisen, können Sie ein einfaches Skript schreiben. Erzwingen Sie explizit eine DNS-Abfrage gegen den öffentlichen autoritativen Server:

nslookup -debug ihre-domain.com ns1.ihr-dns-provider.com

Wenn dieser Befehl in einen Timeout läuft, ist Ihre autoritative Schicht fehlerhaft, unabhängig davon, was Ihr internes Tool sagt.

Fazit

Verlassen Sie sich beim Entwurf Ihrer Zuverlässigkeitshaltung niemals auf interne Health Checks, um die externe Erreichbarkeit zu validieren.