Inhalt (4 Abschnitte)
Eindeutige Störungen sind ein Luxus: Alles ist kaputt, alle sehen es, man sucht, man findet. Diese hier war von anderer Art. Unsere Continuous-Integration-Kette scheiterte sporadisch (etwa bei jedem dritten Build) an der Auflösung unserer eigenen Domains. Gleicher Befehl, gleiche Server: mal klappt es, mal no such host. Und um die Spur zu verwischen, tauchte manchmal eine zweite Meldung auf: connect: network is unreachable für eine IPv6-Adresse. Obduktion einer der lehrreichsten Störungen des Jahres, denn bei ihrer Diagnose ist alles wiederverwendbar.
Der falsche Täter: Indizien immer datieren #
Die IPv6-Meldung deutete auf einen offensichtlichen Verdächtigen hin: einen AAAA-Eintrag, der auf eine Adresse zeigte, die unsere Build-Maschinen mit reinem IPv4 nicht erreichen konnten. Fall erledigt? Hier kommt der Reflex ins Spiel, der die Diagnose gerettet hat: das Indiz datieren. Dieser AAAA-Eintrag existierte seit zweieinhalb Monaten, und die CI war in dieser ganzen Zeit ohne Probleme gelaufen. Ein Element, das lange vor den Symptomen vorhanden war, kann nicht ihre Ursache sein; es variierte nur die Fehlermeldungen (Auflösung von A scheitert → „no such host“; nur der AAAA-Eintrag antwortet → IPv6-Versuch → „unreachable“). Erste, allgemeine Lehre: Bei einem sporadischen Symptom zuerst die Chronologie klären (Datum des letzten Erfolgs, Datum jeder Änderung), erst dann Hypothesen bilden.
Die Methode, die Klarheit brachte #
- Fehlschläge pro Domain zählen in den Logs des internen Resolvers: Die SERVFAIL betrafen nur zwei unserer Zonen (Hunderte von Vorkommen) und null externe Domains von zehn getesteten. Die Störung hatte also einen klar umrissenen Bereich, und ein solcher Bereich ist bereits eine Signatur.
- Öffentliche Resolver vergleichen: Dieselbe Anfrage gelang bei dem einen 12 von 12 Mal… und bei einem anderen, bekannt für strikte DNSSEC-Validierung, 3 von 12 Mal. Eine Domain, die nur bei validierenden Resolvern scheitert, ist ein Neonpfeil, der auf die Vertrauenskette zeigt.
- Den DS prüfen:
dig DS <zone>beim Parent. Treffer: ein DS-Eintrag, veröffentlicht für Zonen, die ihrerseits unsignierte Antworten lieferten.
Der Mechanismus: das gebrochene Versprechen #
DNSSEC funktioniert über eine Vertrauenskette: Die übergeordnete Zone (.com) veröffentlicht einen DS-Eintrag (den Fingerabdruck des Schlüssels Ihrer Zone), der den Resolvern verspricht: „Die Antworten dieser Zone sind signiert, und so prüfen Sie sie.“ Ein validierender Resolver, der diesen DS findet, verlangt dann signierte Antworten. Erhält er Unsigniertes (unser Fall, während eines Migrationsfensters der DNS-Server, in dem der alte und der neue Datensatz in den Caches nebeneinander existierten), liefert er die Antwort nicht „trotzdem“ aus: Er antwortet mit SERVFAIL, so ist es vorgesehen. Das ist eine Verweigerung aus Sicherheitsgründen, kein Bug. Daher das perfekt sporadische Muster: Unsere internen Resolver fragten abwechselnd einen nachsichtigen und einen strikt validierenden Resolver ab: Etwa jede siebte Auflösung scheiterte, gerade genug, um ab und zu einen Build zu Fall zu bringen, ohne jemals etwas eindeutig kaputt zu machen.
Goldene Regel für DNSSEC: Aktivieren = Zone signieren, prüfen, dann den DS veröffentlichen. Deaktivieren = DS entfernen, seine TTL abwarten, erst dann die Signierung aufheben. Nie in umgekehrter Reihenfolge, und nie ein DS, der einen Wechsel der autoritativen Server überlebt.
Die Behebung, und die Prüfung, auf die es ankommt #
Die Korrektur bestand aus einem einzigen Schritt: die beim Registrar veröffentlichten DS-Einträge für die betroffenen Zonen entfernen und dann für jede Zone des Portfolios prüfen, dass dig DS nichts mehr zurückgibt und der validierende Resolver 12/12 antwortet. Letzte Falle nebenbei: Die Oberfläche oder die API Ihres Registrars kann einen DNSSEC-Status („deaktiviert“) anzeigen, der nichts beweist über das, was der Parent tatsächlich veröffentlicht. Maßgeblich ist allein eine DS-Anfrage an das DNS. Die CI-Fehlschläge hörten noch am selben Tag auf.
Diese Störung erfüllt alle Kriterien unserer Definition von Zuverlässigkeit: unsichtbar in den Dashboards, sporadisch und durch Methode statt durch Glück gelöst. Das ist der Detailgrad, mit dem eine ernsthaft betreute Infrastruktur geführt werden muss, das DNS eingeschlossen, dieses Stiefkind, auf das man erst schaut, wenn alles brennt. Ein mysteriöses Auflösungsproblem bei Ihnen? Solche Rätsel mögen wir.
