Zusammenfassung

  • Laut öffentlicher ZARC-Auswertung waren kommerzielle Second-Level-Domains unter .ZA zwischen dem 6. und 14. März 2025 von DNS-Ausfall und -Beeinträchtigung betroffen [1].
  • ZADNA beschrieb eine Störung des .za-Namensraums, insbesondere bei co.za-Namen, und nannte ZARC als Betreiber von co.za, org.za, net.za und web.za [2][3].
  • ZADNA berichtete von unerwartetem Verkehr zu Nameservern, automatisierten Sicherheitsmaßnahmen, Meldungen mit Bezug zu Google Public DNS, Mitigation sowie Kapazitäts- und Resilienzarbeit [2][3].
  • IANAs Root-Datenbank und RFC 1034 verorten den Mechanismus in DNS, Register und Delegation, belegen aber nicht den Vorfall selbst [4][5].
  • Rechenschaft verlangt eine klare Grenze des Ausfalls, eine Erklärung der Mitigation, sichtbare Unsicherheit und Nachweise darüber, welche Kontrollen geändert wurden.

Was geschah

ZARC veröffentlichte später eine Auswertung des DNS-Ausfalls und der Degradation im März 2025, die kommerzielle Second-Level-Domains unter .ZA betraf. ZARC erklärte, operative Telemetrie analysiert und Verbesserungen an Infrastruktur, Betrieb, DNS-Architektur, Verfahren und Resilienz umgesetzt zu haben [1].

Die ZADNA-Erklärung vom 14. März liefert die Sicht der öffentlichen Aufsicht. Sie sprach von einer Dienststörung des .za-Namensraums, konkret bei co.za-Namen, und identifizierte ZARC als Betreiber der kommerziellen Second-Level-Domains co.za, org.za, net.za und web.za [2][3].

ZADNA beschrieb außerdem die betriebliche Form: unerwarteter Verkehr zu Nameservern, automatisierte Sicherheitsmaßnahmen, Mitigation und Berichte mit Bezug zu Google Public DNS, die die Namensauflösung beeinflusst haben könnten [2][3]. Das reicht für die Einordnung als DNS- und Registerkontinuitätsproblem. Es reicht nicht für die Behauptung, Google habe den Vorfall verursacht, alle .za-Namen seien ausgefallen oder die vollständige Root Cause sei öffentlich.

Die engere Sprache ist wichtig. Ein DNS-Vorfall des Registers ist kein totaler nationaler Internetausfall. Betroffen ist die Nachschlageinfrastruktur, mit der Nutzer und Software einen Dienst finden. Für Inhaber abhängiger Domains ist die Wirkung dennoch direkt: Der Name wird unzuverlässig aufgelöst und ein gesunder Dienst erscheint offline.

Warum das wichtig ist

Ein Register führt Einträge, betreibt aber zugleich laufende Infrastruktur. Nutzer erreichen eine Domain nicht durch das Lesen einer Richtlinie, sondern durch DNS-Abfragen. Wenn der autoritative Antwortpfad beeinträchtigt ist, werden die Kontinuitätskontrollen des Registers zur öffentlichen Abhängigkeit.

Das ist die Heng.lu-Fläche dieses Beitrags: DNS, Register und Delegation. Korrekte Registerdaten genügen nicht, wenn der laufende Auflösungsdienst unter Verkehrsdruck, während Mitigationsentscheidungen oder bei resolver-sichtbaren Effekten nicht stabil bleibt. Die Frage ist nicht, ob das Register souverän ist. Sie lautet, ob laufender Code, Daten, Nameserver, Monitoring und Wiederherstellung abhängige Nutzer erreichbar halten.

Der Vorfall zeigt auch, weshalb Transparenz Beobachtung und Schlussfolgerung trennen muss. ZARC kann Telemetrieanalyse und Verbesserungen melden [1]. ZADNA kann unerwarteten Verkehr, automatisierte Maßnahmen und Nachbereitung beschreiben [2][3]. Leser müssen weiterhin erkennen können, was autoritatives DNS-Verhalten, resolver-sichtbares Symptom, Kapazitätsgrenze, defensive Reaktion oder unbekannte Tatsache war.

Die technische Ebene

DNS löst Namen in einer delegierten Hierarchie auf. IANA führt .za in der Root-Zonendatenbank und macht damit die Delegationsfläche sichtbar [4]. RFC 1034 beschreibt ein verteiltes Namenssystem, in dem Server Fragen beantworten und Autorität zwischen Zonen delegieren [5]. Diese Quellen erklären den Mechanismus, nicht die Ereignisse im März.

Vereinfacht sucht ein Resolver nach autoritativen Informationen, um eine Antwort zu erhalten. Register-Nameserver sind Teil dieser Kette. Wenn Verkehrsbehandlung, Mitigationsregeln oder DNS-Architektur beeinträchtigt sind, kann dies als Auflösungsfehler erscheinen, obwohl das Hosting weiter funktioniert.

Die ZARC- und ZADNA-Unterlagen zeigen dieselbe betriebliche Familie: Ausfall oder Degradation kommerzieller Second-Level-Domains, unerwarteter Nameserver-Verkehr, automatisierte Maßnahmen, Mitigation und Resilienzarbeit [1][2][3]. Nicht veröffentlicht sind alle Logs, Schwellenwerte, Regeln oder Resolverpfade. Dort endet die Beweisgrenze.

Wer betroffen war

Am sichersten belegt sind Nutzer, Registranten und Organisationen, die von den betroffenen kommerziellen Second-Level-Domains abhängig waren. ZADNA nannte co.za ausdrücklich und beschrieb die von ZARC betriebene kommerzielle Gruppe [2][3].

Betroffen waren auch Betreiber, deren Dienst wegen der gestörten Namensauflösung unerreichbar wirkte. Die Anwendung, der Hoster oder das Zugangsnetz können gesund sein, während das Register-DNS das sichtbare Kundensymptom erzeugt.

Die Quellen tragen keine Nutzerzahl, keine Schadenssumme und keine Behauptung, alle .za-Namen hätten gleich reagiert. Sie tragen die engere Feststellung, dass die Register-DNS-Ebene als Kontinuitätsabhängigkeit sichtbar wurde.

Die Nachweispflicht des Registers

Erstens braucht es eine präzise Dienstgrenze: betroffene Zonen, Labels, Nameservergruppen oder kommerzielle Second-Level-Domains. Eine pauschale Aussage wie «.za war down» verwischt die reale Betriebsebene.

Zweitens braucht es eine Zeitlinie von erstem Nutzersymptom, internem Alarm, automatisierter Sicherheitsaktion, manueller Mitigation, resolver-sichtbarer Erholung und stabilem Endzustand. ZARC nennt ein Zeitfenster und Verbesserungskategorien [1], aber nicht jeden internen Zeitpunkt. Diese Lücke darf nicht erfunden werden.

Drittens muss Telemetrie klassifiziert werden. «Unerwarteter Verkehr» kann eine Abfragespitze, ungewöhnliche Query-Muster, Retries, Bots oder eine ungünstige Interaktion von Schutzschwellen und legitimer Last bedeuten. ZADNA belegt die allgemeine Beschreibung [2][3], nicht ein endgültiges DDoS-Label oder eine Regel-für-Regel-Diagnose.

Viertens ist die Resolverperspektive nötig. ZADNAs Hinweis auf Google Public DNS bezeichnet einen möglichen Symptompfad, keine Ursache [2][3]. Ein guter Abschluss trennt autoritative Antworten, Cacheverhalten, negative Antworten und Unterschiede zwischen Resolvern.

Fünftens muss Mitigation einer Kontrollklasse zugeordnet werden: Kapazität, Nameserververteilung, Filter, Schwellenwerte, Eskalation, Monitoring oder Architektur. «Dienst wiederhergestellt» beweist noch nicht, dass das nächste Ereignis kürzer bleibt.

Was zu beobachten ist

Künftige Berichte sollten Nameserver-Verkehr, autoritatives Verhalten, Resolver-Symptome und Kundenerreichbarkeit getrennt darstellen. Zu beobachten sind außerdem Serverdiversität, Kapazitätsreserve, Sicherheit automatisierter Regeln, Telemetrieaufbewahrung und öffentliche Validierung nach der Reparatur.

Die Bewertung wird ernster bei Wiederholung, längerer resolver-sichtbarer Störung, blockierten legitimen Abfragen oder fehlendem begrenzten Abschlussbericht. Sie wird weniger ernst bei klarer Reichweite, belastbarer Zeitlinie, einer mit dem Kontrollelement verknüpften Mitigation und nachweisbaren Architektur- oder Kapazitätsverbesserungen.

Quellen

  1. https://zarc.web.za/public-incident-review-march-2025-dns-outage-and-degradation/
  2. https://www.zadna.org.za/za-namespace-experiences
  3. https://www.zadna.org.za/images/za_namespace_disruption.pdf
  4. https://www.iana.org/domains/root/db/za.html
  5. https://www.rfc-editor.org/rfc/rfc1034.txt