Wie der Spamhaus-DDoS von 2013 offene DNS-Rekursion zum Test der

Zusammenfassung

Cloudflare meldete zunächst etwa 10 Gbit/s, später 75–90 Gbit/s, eine Eskalation in Richtung 120 Gbit/s und schließlich eine providerseitige Beobachtung von etwa 300 Gbit/s. Diese Werte gehören zu den jeweiligen Messpunkten von Cloudflare und sind keine universelle Vermessung des Internets. [1][2]
Die ausführbare Angriffskette verband gefälschte IP-Quelladressen, offen erreichbare rekursive Resolver, vergrößerte DNS-Antworten und gemeinsam genutzte Routing-, Peering-, Transit- oder Mitigationspfade. Rekursive und autoritative DNS-Dienste müssen dabei klar unterschieden werden. [4][10]
Nach Angaben von Cloudflare beteiligten sich mehr als 30.000 Resolver; auch diese Zahl und der beschriebene Verstärkungsfaktor von annähernd hundert sind an den Beobachtungskontext des Unternehmens gebunden und keine vollständige Bestandsaufnahme aller beteiligten Netze. [1][2]
RFC 5358 empfahl bereits vor dem Vorfall, Rekursion auf berechtigte Clients zu begrenzen. BCP 38 und BCP 84 ordneten die Validierung von Quelladressen den Zugangs-, Kunden- und Multihoming-Grenzen zu. [4][5][6]
Eine Unterbrechung der Website oder unterstützender Netzwerkpfade beweist nicht, dass die verteilten DNSBL-Daten von Spamhaus weltweit ausgefallen waren; Spamhaus erklärte, diese Daten seien weiter verfügbar geblieben. [3]
Anycast verteilte Last, beseitigte aber nicht die Abhängigkeit von BGP-Auswahl, Standortkapazität, Peering und Transit. Ein Engpass auf einem einzelnen Pfad belegt weder einen Ausfall eines gesamten Internetknotens noch eine gleichmäßige Beeinträchtigung aller Netze.
Spätere RFCs sowie Material von RIPE, MANRS, DNS-OARC und der Forschung liefern Vergleichsmaßstäbe und heutige Prüfmethoden. Sie dürfen nicht rückwirkend als im März 2013 identisch verfügbare oder tatsächlich eingesetzte Kontrollen behandelt werden. [7][8][9][14][15][16][17][18][19]
Der praktische Verantwortlichkeitstest lautet: unbeabsichtigte Rekursion schließen, gefälschte Quelladressen am geeigneten Netzrand abweisen, Routing- und Mitigationsänderungen dokumentieren, Dienstebenen getrennt messen und jede Reparatur von einem unabhängigen Beobachtungspunkt aus verifizieren.

Der Vorfall als Infrastruktur- und Verantwortlichkeitstest

Der Angriff auf Spamhaus im März 2013 wird häufig auf eine spektakuläre Bandbreitenzahl reduziert. Für eine belastbare Analyse ist jedoch nicht die größte zitierte Zahl der beste Ausgangspunkt, sondern der tatsächlich ausführbare Paketpfad. Zwischen dem 18. und 27. März verband dieser Pfad mehrere unabhängig betriebene Komponenten: Ein System erzeugte kleine DNS-Anfragen mit einer gefälschten Quelladresse, ein offen erreichbarer rekursiver Resolver akzeptierte die Anfragen, größere Antworten wurden an die vorgetäuschte Adresse geschickt, und Routing- sowie Interconnection-Pfade transportierten die zusammenlaufende Last.

Zunächst war die Erreichbarkeit von Spamhaus betroffen; später verlagerte sich der Druck nach Darstellung von Cloudflare auf providerseitige und peeringnahe Infrastruktur. [1][2]

Diese Kette ist zugleich eine Karte praktischer Kontrolle. Der Betreiber eines rekursiven Resolvers entscheidet, für welche Clients dieser Dienst erreichbar ist. Ein Zugangs- oder Kundennetz entscheidet an seinen kontrollierbaren Rändern, ob Pakete mit dort unmöglichen Quelladressen austreten dürfen. Ein Mitigationsanbieter entscheidet über Anycast-Ankündigungen, Filterung, Scrubbing, Kapazitätsverteilung und Routenänderungen. Peering- und Transitanbieter kontrollieren ihre eigenen Schnittstellen, Richtlinien und Reaktionen auf Überlastung.

Der Betreiber des angegriffenen Dienstes kontrolliert Architektur, Abhängigkeiten und Kommunikation über die Verfügbarkeit, nicht jedoch fremde Resolver oder entfernte Netze, aus denen gefälschte Pakete austreten.

Verantwortung kann deshalb nicht allein aus dem Namen, der Größe oder der gesellschaftlichen Rolle einer Organisation abgeleitet werden. Entscheidend ist, welcher Betreiber eine konkrete Bedingung im laufenden System ändern konnte. Ebenso entscheidend ist der Nachweis, dass er dies getan hat. Eine Richtlinie ohne überprüfte Umsetzung, eine Reparatur ohne externen Wiederholungstest oder eine Kapazitätsangabe ohne benannten Messpunkt bleibt unvollständig.

Diese Betrachtung bewertet weder die politische noch die operative Legitimität der Blocklisten von Spamhaus. Sie trennt die Debatte über solche Listen von der engeren technischen Frage, wie eine reflektierte DNS-Last entstehen, anwachsen und durch gemeinsam genutzte Netzinfrastruktur wandern konnte. Damit bleibt der Untersuchungsgegenstand dort, wo sich belastbare Belege finden lassen: in Konfigurationen, Paketmerkmalen, Messpunkten, Routingentscheidungen und überprüfbaren Reparaturen.

Die zeitliche und sachliche Grenze des Ereignisses

Der hier betrachtete Vorfall ist auf den Zeitraum vom 18. bis 27. März 2013 begrenzt. Cloudflare berichtete, Spamhaus habe nach Schutz gesucht, nachdem ein Angriff die Verbindung des Dienstes ausgelastet und die Website unerreichbar gemacht hatte. In der ersten Darstellung nannte Cloudflare ungefähr 10 Gbit/s und später Angriffswellen von etwa 75 bis 90 Gbit/s, die zu einem erheblichen Teil über offen zugängliche rekursive DNS-Resolver reflektiert worden seien. [1]

In einer weiteren Darstellung beschrieb Cloudflare eine Eskalation in Richtung 120 Gbit/s. Der Angriffsdruck habe sich dabei vom ursprünglichen Kundenziel in Richtung der Provider und Verbindungsflächen verlagert, über die das Schutznetz erreichbar war. Dieselbe providerseitige Darstellung ist auch die Quelle für den vielfach wiederholten Wert von etwa 300 Gbit/s. [2] Diese Werte gehören nicht zwangsläufig zu demselben Ort, demselben Zeitpunkt oder derselben Definition von empfangenem, verworfenem und weitergeleitetem Verkehr.

Eine Messung an der Kundenschnittstelle beschreibt einen anderen Ausschnitt als eine Messung innerhalb eines Anycast-Netzes oder auf einem vorgelagerten Link. Auch der Angriff auf die ursprüngliche Zieladresse ist nicht ohne Weiteres mit späterem Verkehr gegen unterstützende Infrastruktur gleichzusetzen. Die Berichte bilden eine zeitliche Entwicklung ab, aber keinen lückenlosen, synchronisierten Datensatz über sämtliche beteiligten Netze. Deshalb dürfen die Werte nicht zu einer einzigen, über den gesamten Zeitraum konstanten Angriffskurve verschmolzen werden.

Ebenso wichtig ist die Abgrenzung der betroffenen Dienste. Die Unerreichbarkeit einer Website belegt einen realen Ausfall dieses Endpunkts oder seines Pfades. Sie belegt jedoch nicht, dass jede andere von derselben Organisation betriebene oder verteilte Funktion ebenfalls ausgefallen war. Spamhaus erklärte später, dass seine verteilten Blocklist-Daten verfügbar geblieben seien, obwohl Website, Hosts, DNS-Partner und unterstützende Dienste angegriffen worden seien. [3] Daraus folgt weder eine Garantie unterbrechungsfreier Erreichbarkeit für jeden Nutzer noch ein weltweiter Ausfall der E-Mail-Filterung.

Die Formulierung, der Angriff habe das Internet „fast zum Zusammenbruch gebracht“, gehört in diesem Rahmen zur damaligen öffentlichen Zuspitzung und zur Überschrift einer providerseitigen Darstellung. Sie ist kein festgestellter globaler Ausfallbefund. [2] Der eingefrorene Quellenbestand belegt weder den Ausfall eines bestimmten Internetknotens als Ganzes noch eine universelle Störung sämtlicher Netze. Auch eine abschließende juristische Zurechnung aller Handlungen oder die Identität aller beteiligten Akteure lässt sich daraus nicht ableiten.

Was Cloudflare tatsächlich beobachtete

Bandbreitenangaben erhalten ihren Aussagewert erst durch den Messkontext. Cloudflare ordnete die anfänglichen ungefähr 10 Gbit/s und die späteren Wellen von 75 bis 90 Gbit/s seiner Kunden- und Mitigationssicht zu. [1] Die Eskalation in Richtung 120 Gbit/s sowie der Wert von etwa 300 Gbit/s stammen aus der späteren Beschreibung der providerseitigen Belastung. [2] Diese Zahlen können die erhebliche Größe des beobachteten Verkehrs belegen, sind aber keine Messung des gesamten öffentlichen Internets.

Ein providerseitiger Spitzenwert kann beispielsweise Daten umfassen, die an mehreren Standorten eintreffen, an einer bestimmten Systemgrenze gezählt oder vor der Zustellung an den geschützten Kunden verworfen werden. Ohne identische Zählerdefinitionen, Zeitfenster und Entduplizierungsregeln lässt er sich nicht direkt mit dem Wert an einer Kundenschnittstelle vergleichen. Eine belastbare Darstellung benennt deshalb Beobachter, Ort, Zeitraum, Messmethode und den Zustand des Verkehrs: empfangen, gefiltert, weitergeleitet oder am Engpass verloren.

Cloudflare erklärte außerdem, mehr als 30.000 rekursive Resolver beobachtet zu haben, und beschrieb für die verwendete Anfrage-Antwort-Form einen Verstärkungsfaktor von annähernd hundert. In den Berichten wurden Anfragen nach Daten zu ripe.net genannt. [1][2] Diese Aussagen stützen den beschriebenen Reflexionsmechanismus und die große Zahl sichtbarer Antwortquellen. Sie sind jedoch weder eine vollständige Zählung jedes beteiligten Resolvers noch eine Rekonstruktion aller ursprünglichen Quellnetze.

Die IP-Adressen reflektierender Resolver verraten nicht automatisch, von welchem Bot, Kundenanschluss oder autonomen System die gefälschten Anfragen ausgingen. Da die Quelladresse manipuliert wurde, sieht der Resolver gerade die Adresse des vermeintlichen Opfers. Für eine Herkunftsanalyse wären zusätzliche Daten an den tatsächlichen Austrittsrändern, zeitlich abgestimmte Flussdaten oder andere unabhängige Beobachtungen erforderlich. Eine vollständige Verteilung über Quell-AS lässt sich aus den Resolverantworten allein nicht ableiten.

Auch Auswirkungen auf unbeteiligte Netze bleiben nur teilweise sichtbar. Ein überlasteter Transit- oder Peeringpfad kann Verkehr Dritter beeinträchtigen. Der Quellenbestand liefert jedoch keine vollständige Messung aller solchen Nebenwirkungen. Es wäre deshalb unzulässig, aus einer großen Rate automatisch auf eine flächendeckende Störung oder einen bestimmten Schaden bei jedem Netz auf dem möglichen Pfad zu schließen. Das Fehlen einer universellen Messung verkleinert den nachgewiesenen Angriff nicht; es begrenzt lediglich die Reichweite der Schlussfolgerungen.

Der ausführbare Pfad einer DNS-Reflexion

Die Angriffskette begann mit einer falschen Angabe im IP-Header. Ein System versandte eine kleine UDP-basierte DNS-Anfrage, setzte aber als Quelladresse die Adresse des beabsichtigten Empfängers ein. UDP baut vor der Antwort keine verbindungsorientierte Sitzung auf. Der angesprochene DNS-Dienst schickte seine Antwort deshalb an die angegebene, tatsächlich jedoch gefälschte Adresse.

Der verwendete Vermittler war ein rekursiver Resolver, der Anfragen von beliebigen externen Adressen akzeptierte. Er nahm die Frage entgegen, beschaffte oder ermittelte die verlangten DNS-Daten und sandte die Antwort an den vermeintlichen Client zurück. War die Antwort deutlich größer als die Anfrage, erhielt der Angreifer eine Verstärkungswirkung: Er musste nur den kleineren ausgehenden Datenstrom erzeugen, während die Resolver den größeren Datenstrom zum Opfer sendeten. RFC 5358 hatte dieses Reflexions- und Verstärkungsmuster bereits 2008 beschrieben. [4]

Der Angriffserfolg hing nicht von einem einzelnen außergewöhnlichen Resolver ab. Viele Server konnten jeweils einen vergleichsweise kleinen Beitrag leisten. Wiederholte Anfragen an Tausende offen erreichbare Resolver ließen die Antworten jedoch an einer Zieladresse oder auf einem tragenden Link zusammenlaufen. Der von Cloudflare genannte Bestand von mehr als 30.000 beobachteten Resolvern veranschaulicht diese Aggregation, ohne eine universelle oder vollständige Zählung zu sein. [1]

Das Ziel einer reflektierten Antwort musste in späteren Phasen nicht ausschließlich ein Server von Spamhaus sein. Wenn ein Mitigationsanbieter die geschützte Adresse per Anycast ankündigte oder der Verkehr auf vorgelagerte Infrastruktur zielte, konnten Pakete an Schutzstandorten, Transitverbindungen, Peering-Schnittstellen oder providerseitigen Engpässen eintreffen. [2] Ein Paket auf einem solchen Pfad belegt jedoch nicht automatisch, welches physische Segment der bindende Engpass war.

Die Kette benötigt mehrere voneinander unabhängige Bedingungen. Das Ursprungsnetz muss die gefälschte Quelladresse passieren lassen. Ein rekursiver Resolver muss die Anfrage eines nicht berechtigten externen Clients annehmen. Die Antwort muss größer oder in großer Zahl erzeugbar sein. Routing und Interconnection müssen die Antwort zum angegebenen Ziel tragen. Die Gesamtwirkung entsteht aus dem Zusammenspiel dieser Bedingungen, nicht aus einem abstrakten Etikett wie „DNS-Angriff“.

Gerade deshalb lässt sich Verantwortung entlang des Paketpfads aufteilen. Der Resolverbetreiber kontrolliert nicht den fernen Anschluss, an dem die Quelladresse gefälscht wurde. Das Zugangsnetz dieses Anschlusses kontrolliert nicht die Zugriffslisten eines fremden Resolvers. Ein Mitigationsanbieter kann eingehenden Verkehr filtern oder verteilen, aber nicht rückwirkend die Erzeugung aller reflektierten Antworten verhindern. Jeder Betreiber ist zunächst für den Kontrollpunkt verantwortlich, den er tatsächlich konfigurieren und prüfen kann.

Rekursive und autoritative DNS-Dienste sind verschiedene Rollen

Eine autoritative DNS-Instanz veröffentlicht Antworten für Zonen, für die sie zuständig ist. Ein rekursiver Resolver beantwortet dagegen Fragen von Clients, indem er bei Bedarf die DNS-Hierarchie durchläuft, Ergebnisse zwischenspeichert und dem Client eine aufgelöste Antwort liefert. Diese Rollen sind im DNS-Modell funktional verschieden. [10]

Ein einzelner Server kann technisch beide Rollen übernehmen. Dadurch verschwinden die Unterschiede jedoch nicht. Ist die Autoritativfunktion öffentlich erreichbar, kann das für die Veröffentlichung einer Zone erforderlich sein. Eine Rekursivfunktion für beliebige externe Clients ist eine andere Berechtigung. Das Schließen offener Rekursion bedeutet deshalb nicht, öffentliches autoritatives DNS abzuschalten. Es bedeutet, den rekursiven Dienst auf die vorgesehenen Nutzer und Netze zu begrenzen.

Für den Spamhaus-Vorfall ist diese Trennung zentral. Der beschriebene Pfad nutzte offen erreichbare rekursive Resolver, die Fragen externer Absender bearbeiteten und Antworten an gefälschte Zieladressen schickten. [1][4] Die bloße Existenz eines DNS-Servers macht dessen Betreiber nicht zu einem Betreiber offener Rekursion. Auch die Möglichkeit anderer Verstärkungsformen über autoritative Dienste darf nicht dazu führen, die hier belegte Rolle ungenau auf sämtliche DNS-Infrastruktur zu übertragen.

EDNS(0) erweitert die Transport- und Nachrichtenmöglichkeiten des DNS und ist für das Verständnis größerer DNS-Antworten relevant. [11] Daraus folgt jedoch nicht, dass EDNS(0) allein den Angriff verursachte. Verstärkung entstand in dem hier betrachteten Pfad aus der Kombination von Anfrageform, Antwortgröße, offenem rekursivem Zugriff und gefälschter Quelladresse. Ein Merkmal des DNS-Protokolls ersetzt nicht die Analyse der Zugriffskontrolle und des Quellnetzes.

Auch NAT-Verhalten kann bei UDP-Kommunikation betriebliche Randbedingungen beeinflussen. RFC 4787 beschreibt Anforderungen an UDP-NAT-Verhalten, ist aber kein Beleg dafür, dass ein bestimmtes NAT im Vorfall eine bestimmte Rolle spielte. [12] Für eine konkrete Zurechnung wären Geräte-, Pfad- und Zeitdaten erforderlich. Der allgemeine Standard kann eine Prüfung strukturieren, aber keine nicht beobachtete Komponente in die Ereignisgeschichte einfügen.

Die klare Rollentrennung verbessert auch Reparaturnachweise. Ein Betreiber kann dokumentieren, welche Instanzen autoritativ antworten, welche rekursiv arbeiten, welche Clientpräfixe zugelassen sind und über welche Interfaces die Dienste erreichbar sind. Ein externer Test aus einem nicht berechtigten Netz sollte keine Rekursion erhalten, während die notwendigen autoritativen Antworten weiterhin verfügbar bleiben. Nur eine solche rollenbezogene Prüfung zeigt, dass die beabsichtigte Funktion erhalten und die unbeabsichtigte Exposition beseitigt wurde.

Offene Rekursion als kontrollierbare Betreiberentscheidung

RFC 5358 hatte die Gefahr öffentlich zugänglicher rekursiver Nameserver fünf Jahre vor dem Vorfall beschrieben. Der operative Kern war bereits vorhanden: Rekursion sollte nur den vorgesehenen Clients angeboten werden, und Netze sollten verhindern, dass Pakete mit gefälschten Quelladressen austreten. [4] Die Empfehlung zur Begrenzung der Rekursion ist deshalb kein nachträglich erfundener Maßstab.

Der Resolverbetreiber wählt Software, Rollen, Interfaces, Zugriffslisten, zugelassene Clientbereiche, Cacheverhalten und häufig auch Begrenzungen für Antworten. Diese Entscheidungen bestimmen, ob ein externer, nicht authentisierter Absender den Dienst als Reflektor verwenden kann. Ein versehentlich kombinierter autoritativer und rekursiver Betrieb entbindet den Betreiber nicht von dieser Kontrolle. Vielmehr muss er beide Rollen ausdrücklich erfassen.

Fehlender Vorsatz hebt die technische Wirkung nicht auf. Ein Betreiber muss das Angriffsziel nicht kennen oder auswählen, damit sein offen erreichbarer Resolver eine Antwort an eine gefälschte Adresse sendet. Ebenso wenig macht ein kleiner individueller Datenstrom die Exposition bedeutungslos. Die Verantwortlichkeitsfrage lautet nicht, ob ein einzelner Resolver den gesamten Angriff verursacht hat, sondern ob er eine vermeidbare, wiederholbare Fähigkeit für beliebige externe Anfragende bereitstellte.

Ein belastbarer Nachweis beginnt mit einem vollständigen Inventar. Er sollte jede rekursive Instanz, deren IPv4- und IPv6-Adressen, Interfaces, Software, Besitzer, vorgesehene Nutzergruppen und Konfigurationsquelle erfassen. Externe Tests aus nicht zugelassenen Netzen sollten zeigen, dass keine Rekursion angeboten wird. Interne Tests müssen zugleich nachweisen, dass berechtigte Clients den Dienst weiterhin verwenden können.

Reparaturen müssen Neustarts, Failover und Konfigurationsverteilung überstehen. Ein einmaliger Scan unmittelbar nach einer Änderung reicht deshalb nicht aus. Sinnvoll sind wiederholte Prüfungen von mehreren externen Beobachtungspunkten, gespeicherte Konfigurationsstände, Änderungszeitpunkte und ein Abgleich mit dem tatsächlichen Bestand. Antwortbegrenzungen und Rate Limits können den Schaden reduzieren, ersetzen aber keine klare Rekursionsgrenze.

Spätere Verfahren wie DNS Cookies können in unterstützten Kommunikationsbeziehungen zusätzliche Widerstandsfähigkeit gegen bestimmte Spoofing-Szenarien schaffen. [7] Spätere Empfehlungen zur Minimierung von ANY-Antworten können eine attraktive Antwortform verkleinern. [8] Beide sind Verteidigungsebenen für heutige Systeme. Sie dürfen weder als Beleg für einen identischen Einsatz 2013 noch als Ersatz für die bereits damals dokumentierte Begrenzung rekursiver Dienste dargestellt werden.

Gefälschte Quelladressen und die Kontrolle am Netzrand

Die andere Seite des Pfades liegt näher am tatsächlichen Absender der gefälschten Anfrage. BCP 38, veröffentlicht als RFC 2827, beschreibt die Filterung an Kunden- und Zugangsgrenzen. Ein Provider soll Verkehr zurückweisen, dessen angegebene Quelladresse nicht zu den Präfixen gehört, die von der betreffenden Kundenschnittstelle legitimerweise stammen können. [5]

Aus Sicht des Providers wird dies häufig als Ingress-Filterung bezeichnet, weil die Pakete vom Kunden in das Provider-Netz eintreten. Für den übrigen Internetverkehr wirkt die Kontrolle als Egress-Schutz: Die gefälschten Pakete verlassen den kontrollierten Rand nicht. Gerade dort kennt der Betreiber normalerweise die Beziehung zwischen Schnittstelle, Kunde und zugewiesenen Quellpräfixen am besten.

Multihoming und asymmetrisches Routing machen eine naive Prüfung schwieriger, aber nicht bedeutungslos. BCP 84 behandelt diese Situationen und beschreibt verschiedene Verfahren, darunter interfacebezogene Zugriffslisten und Reverse-Path-Methoden mit unterschiedlichen Akzeptanzeigenschaften. [6] Ein strenger Rückpfadtest kann in asymmetrischen Topologien legitime Pakete ablehnen. Daraus folgt die Notwendigkeit einer topologiegerechten Kontrolle, nicht die Aufgabe jeglicher Quelladressvalidierung.

Ein multihomed Netz muss seine zulässigen Quellpräfixe korrekt dokumentieren. Seine Provider müssen Richtlinien wählen, die legitime asymmetrische Pfade erhalten und dennoch unmögliche Quelladressen abweisen. Änderungen an Routing, Kundenanbindungen oder Präfixen erfordern erneute Tests. Eine einmal richtig konfigurierte Regel kann nach einem Umbau entweder zu durchlässig oder zu restriktiv werden.

Ein beliebiger Transitprovider ist nicht automatisch für jedes gefälschte Paket verantwortlich, das irgendwo über sein Netz läuft. Die stärkste Kontrollmöglichkeit liegt an Schnittstellen, an denen die zulässigen Kundenquellen bekannt sind. Weiter entfernt kann ein Netz die Beziehung zwischen Paketquelle und ursprünglichem Anschluss häufig nicht mehr zuverlässig bestimmen. Eine faire Zuordnung muss deshalb die konkrete Schnittstelle, die verfügbare Präfixkenntnis und die tatsächlich eingesetzte Richtlinie benennen.

Prüfbare Belege umfassen freigegebene Quellpräfixe, ACL- oder Validierungsmodi, dokumentierte Ausnahmen, Zähler für verworfene Pakete, kontrollierte Spoofing-Tests und Änderungsverläufe. Eine allgemeine Erklärung, BCP 38 sei „aktiviert“, ist unzureichend, wenn offenbleibt, welche Kundenränder getestet wurden und wo Ausnahmen bestehen. Die anhaltenden Schwierigkeiten bei der Einführung von Quelladressvalidierung machen gemessene Abdeckung wichtiger als bloße Absichtserklärungen. [15]

Geschlossene Rekursion und Quelladressvalidierung bearbeiten unterschiedliche Kontrollpunkte. Die erste Maßnahme entfernt einen Reflektor aus der Reichweite beliebiger Anfragender. Die zweite verhindert, dass die gefälschte Anfrage das Ursprungsnetz verlässt. [4][5][6] Keine Seite kann ihre Pflicht auf die andere übertragen. Erst das gemeinsame Versagen ermöglicht die beobachtete Kette in ihrer beschriebenen Form.

Verstärkung, lokale Beiträge und die gemeinsame Externalität

Ein offen erreichbarer Resolver kann aus lokaler Sicht wie ein kleiner Konfigurationsfehler erscheinen. Ein einzelnes Zugangsnetz kann nur wenige gefälschte Anfragen pro Kunde und Zeitfenster sehen. Reflexion verändert jedoch die relevante Größenordnung. Kleine Anfragen werden über viele unabhängige Systeme verteilt, größere Antworten laufen dagegen auf ein Ziel oder einen begrenzten Satz von Verbindungswegen zu.

Nach den Angaben von Cloudflare waren mehr als 30.000 Resolver sichtbar. Für die beobachtete Anfrage-Antwort-Form beschrieb das Unternehmen eine Verstärkung von annähernd hundert. [1][2] Diese Angaben sind keine universellen Konstanten. Sie zeigen aber, wie viele lokal unscheinbare Beiträge gemeinsam eine Last erzeugen können, die einen Link oder eine Mitigationsumgebung unter erheblichen Druck setzt.

Der Betreiber eines offenen Resolvers trägt möglicherweise nur geringe eigene Kosten. Der Datenverkehr bleibt unter lokalen Alarmgrenzen, und der eigene Dienst scheint zu funktionieren. Die größeren Kosten entstehen an anderer Stelle: beim Ziel, beim Schutzanbieter, auf Transitverbindungen, an Peering-Schnittstellen oder bei Dritten, deren Verkehr einen belasteten Pfad teilt. Das ist eine Netzwerkexternalität, weil die Folgen einer lokalen Konfigurationsentscheidung außerhalb der eigenen administrativen Domäne anfallen.

Dasselbe gilt für unzureichende Quelladressvalidierung. Ein Zugangsnetz sieht möglicherweise nur kleine ausgehende UDP-Anfragen. Die Verstärkung findet erst bei entfernten Resolvern statt. Aus dem geringen lokalen Volumen darf deshalb nicht geschlossen werden, der eigene Kontrollpunkt sei unwesentlich. Die gefälschte Quelladresse ist eine notwendige Bedingung dafür, dass die Antworten zum Opfer statt zum tatsächlichen Anfragenden gelangen.

Verantwortlichkeit allein nach individuellem Verkehrsanteil würde diese Struktur verfehlen. Kein einzelner Resolver muss unverzichtbar sein, und kein einzelnes Quellnetz muss einen großen Anteil erzeugen. Relevant ist, ob ein Betreiber eine wiederholbare Bedingung kontrollierte, die in großer Zahl den Angriff ermöglichte. Der Maßstab ist somit nicht institutionelles Gewicht, sondern praktische Änderbarkeit und überprüfbare Umsetzung.

Eine belastbare Nachbereitung sollte deshalb Nenner erfassen. Nicht nur die Zahl geschlossener Resolver ist wichtig, sondern der Anteil des gesamten autorisierten Bestands, der geprüft wurde. Nicht nur die Zahl verworfener Spoofing-Pakete zählt, sondern die Abdeckung der Kundenränder und dokumentierte Ausnahmen. Erst solche Bezugsgrößen zeigen, ob eine Reparatur punktuell oder systematisch war.

Anycast, BGP, Peering und Transit

Mit der Aufnahme der Mitigation verlagerte sich der Schutz von einer einzelnen Kundenverbindung in eine verteilte Netzarchitektur. Anycast erlaubt, dieselbe Dienstadresse von mehreren Standorten anzukündigen. BGP wählt anhand der sichtbaren Routen, Richtlinien und Beziehungen, zu welchem Standort Verkehr gelangt. So kann Angriffslast verteilt werden, anstatt hinter einem einzigen Zugangslink zusammenzulaufen.

Anycast schafft jedoch keine abstrakte Gesamtkapazität, die unabhängig von Pfaden überall verfügbar wäre. Jeder Standort besitzt konkrete Links, Filterressourcen und erreichbare Peering- oder Transitwege. Wenn BGP einen großen Verkehrsanteil zu einem Standort mit geringerer freier Kapazität lenkt, kann dort ein Engpass entstehen, obwohl andere Standorte noch Reserven haben. Ebenso kann eine vorgelagerte Verbindung schmaler sein als die interne Mitigationskapazität.

Cloudflare beschrieb, dass sich der Angriff von Spamhaus auf providerseitige und peeringnahe Infrastruktur verlagerte und in dieser Phase höhere Raten beobachtet wurden. [2] Damit änderte sich die Ausfalldomäne. Nicht nur die Verbindung des ursprünglichen Kunden, sondern auch Pfade zum Schutznetz, Provider und gemeinsame Interconnection-Flächen konnten unter Druck geraten.

„Peeringnah“ oder „exchange-facing“ ist dabei keine Aussage, ein bestimmter Internetknoten sei vollständig ausgefallen. Verkehr kann einen Mitigationsstandort über privates Peering, einen Exchange-Port, Transit oder eine Kombination dieser Wege erreichen. Die Überlastung eines Ports oder vorgelagerten Links ist nicht mit dem Ausfall der gesamten Vermittlungsplattform gleichzusetzen. Der eingefrorene Quellenbestand erlaubt keine erfundene Zuordnung eines bestimmten Austauschknotens oder einer bestimmten flächendeckenden Störung.

Für eine genaue Rekonstruktion wären BGP-Ankündigungen und -Rücknahmen, Communities, Standortlasten, Schnittstellenzähler, Flussdaten sowie Zeitpunkte der Koordination mit Peers und Transitprovidern erforderlich. Diese Daten könnten zeigen, wann sich Verkehr verschob, welcher Pfad an Kapazitätsgrenzen geriet und welche Änderung Entlastung brachte. Eine aggregierte Spitzenrate allein kann diese Sequenz nicht ersetzen.

Cloudflare kontrollierte sein Anycast-Design, die Annahme und Filterung von Verkehr, Scrubbing-Entscheidungen, Routenänderungen und die Genauigkeit öffentlicher Messangaben. Peering- und Transitpartner kontrollierten ihre eigenen Schnittstellen, Richtlinien und Überlastungsreaktionen. Betreiber von Internetknoten kontrollierten ihre Vermittlungsinfrastruktur und operative Koordination. Eine Schuld- oder Volumenzuweisung an einen dieser Akteure setzt jedoch konkrete Pfadbelege voraus.

Spätere Architekturhinweise für große autoritative DNS-Dienste können heutige Resilienzprüfungen unterstützen. [9] Sie sind kein Nachweis, dass dieselben Mechanismen 2013 identisch verfügbar oder in der betrachteten Infrastruktur eingesetzt waren. Die historische Aussage bleibt enger: Anycast und Interconnection waren Bestandteil des laufenden Mitigationspfades, und ihre Wirksamkeit hing von realen Routen, Kapazitäten und betrieblichen Entscheidungen ab.

Website, unterstützende Netze und verteilte DNSBL-Daten

Der erste beschriebene sichtbare Ausfall betraf die Website von Spamhaus. Nach Darstellung von Cloudflare wurde die Verbindung ausgelastet und die Website unerreichbar. [1] Spätere Angriffswellen trafen providerseitige Umgebungen und unterstützende Pfade. [2] Spamhaus berichtete zudem über Angriffe gegen Hosts, DNS-Partner und weitere unterstützende Dienste, erklärte aber, dass die verteilten Blocklist-Daten weiterhin verfügbar gewesen seien. [3]

Diese Aussagen beschreiben mehrere Dienstebenen. Eine Website liefert Seiten, Kontaktmöglichkeiten, Erläuterungen und öffentliche Statusinformationen. Eine DNS-basierte Blockliste verteilt Daten über andere Endpunkte, Replikate, Resolverpfade und Nutzerabhängigkeiten. Der Ausfall der Weboberfläche kann Kommunikation und Support erheblich beeinträchtigen, ohne jede DNSBL-Abfrage weltweit zu unterbrechen.

Umgekehrt macht die fortgesetzte Verfügbarkeit verteilter Daten den Angriff auf Website und unterstützende Netze nicht belanglos. Ein Dienst kann auf einer Ebene weiterarbeiten und auf einer anderen stark eingeschränkt sein. Auch kann eine allgemein verfügbare Datenebene für einzelne Regionen oder Netzpfade schlechter erreichbar sein. Die Quellen belegen nicht, dass jeder Nutzer zu jeder Zeit einen fehlerfreien Zugriff hatte.

Deshalb muss eine Verfügbarkeitsaussage immer Endpunkt, Pfad und Zeitfenster nennen. Für die Website wären HTTP-Erreichbarkeit, Antwortzeiten und Fehlerquoten relevant. Für autoritatives DNS müssten die zuständigen Nameserver und mehrere Beobachtungsorte geprüft werden. Für eine DNSBL wären Abfrageerfolg, Aktualität, Latenz und Konsistenz der verteilten Daten getrennt zu messen.

RFC 8767 behandelt die Nutzung veralteter DNS-Antworten zur Verbesserung der Resilienz unter bestimmten Bedingungen. [13] Dieser spätere Mechanismus kann heute Teil einer Kontinuitätsanalyse sein. Er beweist jedoch weder, dass er 2013 identisch verfügbar war, noch dass er die fortgesetzte Verfügbarkeit der Spamhaus-Daten erklärte. Eine solche konkrete Kausalbehauptung wäre ohne Betriebsdaten unzulässig.

Spamhaus kontrollierte Architektur, Dienstabhängigkeiten und Präzision seiner Statuskommunikation. Das Unternehmen kontrollierte nicht die entfernten offenen Resolver oder die Netze, die gefälschte Pakete passieren ließen. Cloudflare kontrollierte die Mitigation der angenommenen Routen, aber nicht jeden ursprünglichen Sendepunkt. Diese Grenzen verhindern sowohl eine Übertreibung zum weltweiten DNSBL-Ausfall als auch eine Verharmlosung der realen Störung unterstützender Infrastruktur.

Welche Belege zu welchem Betreiber gehören

Ein Resolverbetreiber sollte ein datiertes Verzeichnis sämtlicher rekursiver Instanzen vorlegen können. Dazu gehören Besitzer, Interface, Adressfamilie, zugelassene Clientpräfixe, Softwarestand, Konfigurationsquelle und Änderungsnachweis. Externe Tests müssen aus nicht berechtigten Netzen erfolgen. Ein negativer Test ist nur aussagekräftig, wenn der geprüfte Bestand und der Beobachtungsort dokumentiert sind.

Zusätzlich sind Stichproben zu Anfrage- und Antwortverhalten sinnvoll: Nachrichtentyp, Antwortgröße, Trunkierung, Rate-Limit-Aktion und Zeitfenster. Dabei sollten nur die für den Sicherheitsnachweis erforderlichen Daten aufbewahrt werden. Eine Begrenzung großer Antworten kann Schäden reduzieren, beweist aber nicht, dass offene Rekursion geschlossen wurde. Zugriffskontrolle und Antwortbegrenzung benötigen getrennte Nachweise.

Ein Zugangsnetz sollte je Kunden- oder Mandantenschnittstelle festhalten, welche Quellpräfixe zulässig sind und welches Verfahren sie validiert. Kontrollierte Tests mit absichtlich unzulässigen Quellen können zeigen, ob Pakete den Rand verlassen. Ausnahmen brauchen einen verantwortlichen Besitzer, eine technische Begründung, eine Laufzeit und einen Termin für die erneute Prüfung.

Bei multihomed Kunden muss der Nachweis die tatsächliche Routingtopologie berücksichtigen. Ein strenger Reverse-Path-Test kann bei legitimer Asymmetrie ungeeignet sein; eine zu lockere Regel kann gefälschte Quellen durchlassen. [6] Der Betreiber sollte deshalb dokumentieren, warum die gewählte Methode zur Topologie passt, welche Pfade als möglich gelten und wie Änderungen den Prüfzustand beeinflussen.

Transit- und Peeringanbieter sollten Schnittstellenauslastung, Stichprobenflüsse, Routenänderungen, Alarme und Koordinationszeitpunkte aufbewahren. Diese Daten helfen zu bestimmen, wo reflektierter Verkehr eintrat und welche Maßnahme eine beobachtete Entlastung bewirkte. Sie belegen nicht automatisch, dass ein entfernter Resolverbetreiber von seiner Exposition wusste oder dass ein Internetknoten als Ganzes ausfiel.

Ein Mitigationsanbieter benötigt klar definierte Messpunkte, Zeitfenster, Samplingmethoden und Regeln zur Entduplizierung. Site-spezifische Anycast-Last, Scrubbing-Entscheidungen, Routenänderungen und Upstream-Anfragen sollten miteinander verknüpft werden. Öffentliche Raten müssen zwischen empfangenem, verworfenem und zum Kunden weitergeleitetem Verkehr unterscheiden. Der Wert von etwa 300 Gbit/s bleibt ohne solche zusätzlichen Grenzen eine Cloudflare zugeschriebene providerseitige Beobachtung. [2]

Spamhaus wiederum sollte Website-Erreichbarkeit, DNS-Zustand, unterstützende Provider und DNSBL-Datenverfügbarkeit getrennt dokumentieren. Abhängigkeitskarten und Zeitreihen verhindern, dass ein grüner Gesamtstatus mehrere technisch verschiedene Dienste verdeckt. Der Reparaturnachweis ist vollständig, wenn er kontrollierte Komponente, Beobachtung, Änderung und unabhängigen Wiederholungstest miteinander verbindet.

Vor dem Vorfall dokumentierte Kontrollen

Die zentrale historische Fairnessfrage lautet, welche Kontrollkategorien im März 2013 bereits öffentlich beschrieben waren. RFC 5358 stammte aus dem Jahr 2008 und behandelte DNS-Reflexion über öffentlich zugängliche rekursive Server. Er empfahl, Rekursion auf die vorgesehenen Clients zu begrenzen, und verwies zugleich auf die Notwendigkeit, gefälschte Quelladressen zu verhindern. [4]

BCP 38 war als RFC 2827 bereits im Jahr 2000 veröffentlicht worden. Es ordnete die Filterung unmöglicher Quelladressen den geeigneten Kunden- und Zugangsgrenzen zu. [5] BCP 84 beziehungsweise RFC 3704 erweiterte das Modell für multihomed Netze und asymmetrische Pfade. [6] Diese Dokumente zeigen, dass beide grundlegenden Kontrollarten vor der Spamhaus-Kampagne bekannt waren.

Daraus folgt nicht, dass jeder beteiligte Betreiber die Empfehlungen tatsächlich implementiert hatte. Ebenso wenig beweist das Veröffentlichungsdatum, wer von welchem konkreten Resolver wusste oder welches Netz eine bestimmte gefälschte Anfrage weiterleitete. Ein Standard beschreibt eine Kontrollmöglichkeit und deren Zuordnung; die konkrete Verantwortlichkeit erfordert weiterhin Betriebs- und Pfadbelege.

Der sachgerechte Maßstab für 2013 besteht daher aus zwei Fragen. Erstens: War unbeabsichtigt offene Rekursion auf den betreffenden Resolvern begrenzbar und wurde sie begrenzt? Zweitens: Konnte das jeweilige Zugangs- oder Kundennetz unmögliche Quelladressen an seinem kontrollierbaren Rand erkennen und abweisen? Wo technische Ausnahmen bestanden, müssten sie dokumentiert und durch andere Maßnahmen abgesichert worden sein.

Diese historischen Kontrollen sind keine Garantie vollständiger Abwehr. Geschlossene Rekursion auf einem Server beseitigt nicht alle anderen Reflektoren. Quelladressvalidierung in einem Netz repariert keine fremden offenen Resolver. Ihre Bedeutung entsteht durch breite, überprüfte Anwendung. Der Angriff machte sichtbar, wie verbleibende Lücken über administrative Grenzen hinweg zusammenwirken können.

Spätere Standards als Vergleich, nicht als rückwirkender Maßstab

Nach 2013 wurden zusätzliche Mechanismen und betriebliche Leitlinien veröffentlicht. RFC 7873 beschreibt DNS Cookies, die bei unterstützenden Endpunkten bestimmte gefälschte oder unerwünschte Austauschformen erschweren können. [7] RFC 8482 empfiehlt minimale Antworten auf ANY-Anfragen und verringert damit eine historisch attraktive Antwortform. [8] RFC 9199 behandelt Architekturfragen großer autoritativer DNS-Dienste. [9]

Diese Dokumente verbessern heutige Prüfungen, dürfen aber nicht als Beleg dienen, dass dieselben Mechanismen im März 2013 identisch verfügbar, einheitlich implementierbar oder tatsächlich eingesetzt waren. Sie ersetzen außerdem nicht die älteren Kernkontrollen. DNS Cookies schließen keine unbeabsichtigt offene Rekursion in jeder Konstellation. Kleinere ANY-Antworten verhindern nicht jede Verstärkung. Eine resiliente autoritative Architektur beseitigt keine gefälschten Quellen in einem Zugangsnetz.

Neuere RIPE-Leitlinien können die Inventarisierung, Rollenabgrenzung und den Betrieb von DNS-Infrastruktur strukturieren. [14] MANRS-Material verdeutlicht, dass die praktische Verbreitung von Quelladressvalidierung weiterhin Schwierigkeiten bereitet. [15] Präsentationen bei RIPE und DNS-OARC dokumentieren betriebliche Belastungen durch DNS-Amplifikation sowie Verfahren zur Beobachtung und Eindämmung. [16][17]

Messforschung kann helfen, Exposition, Reflexionsverhalten und Auswirkungen über beobachtbare Populationen zu untersuchen. [18] Neuere RIPE-Labs-Analysen zu DNS-Abwehrmaßnahmen bieten ebenfalls Vergleichspunkte für heutige Verteidigung und Verifikation. [19] Solche Quellen erweitern den Werkzeugkasten, füllen aber keine historischen Datenlücken zu einem bestimmten Betreiber oder Pfad.

Der faire Vergleich fragt somit nicht, ob ein Betreiber von 2013 jede spätere RFC vorweggenommen hat. Er fragt, ob die damals verfügbaren Kontrollen genutzt, ihre Grenzen dokumentiert und Reparaturen überprüft wurden. Für heutige Betreiber kommt eine zweite Frage hinzu: ob spätere Verfahren angemessen als zusätzliche Verteidigungsschichten eingesetzt und unter ihren realen Voraussetzungen getestet werden.

Ein reproduzierbares Prüfprogramm

Ein verantwortlicher Resolverbetrieb beginnt mit einer Bestandsaufnahme, die reproduzierbar ist. Jede rekursive Instanz sollte einem Betreiber, einer Adresse, einem Interface, einer Rolle und einer Gruppe berechtigter Clients zugeordnet sein. IPv4 und IPv6, UDP und TCP sowie sekundäre oder nur zeitweise aktive Interfaces müssen einbezogen werden. Der Prüfbestand darf nicht lediglich aus den Systemen bestehen, die bereits als korrekt bekannt sind.

Externe Proben aus nicht berechtigten Netzen sollten keine rekursive Auflösung erhalten. Gleichzeitig müssen interne oder ausdrücklich berechtigte Clients weiterhin funktionieren. Autoritative Antworten sind separat zu testen, damit eine Reparatur nicht versehentlich die öffentliche Zonenauskunft unterbricht. Konfigurationsstände, Zeitpunkte, Beobachtungsorte und Testergebnisse sollten aufbewahrt werden.

Nach einer Änderung sind Wiederholungstests erforderlich. Neustart, Failover, Ersatzsysteme oder eine spätere Konfigurationsverteilung können eine Exposition erneut öffnen. Ein Prüfprogramm sollte daher sowohl regelmäßige Intervalle als auch ereignisbezogene Tests nach Upgrades, Übernahmen, Netzumbauten oder Rollenänderungen vorsehen.

Die Quelladressvalidierung verlangt eine parallele Bestandsaufnahme an den Netzrändern. Für jede relevante Kundenschnittstelle müssen zulässige Präfixe, Validierungsmethode, Ausnahmen und verantwortliche Personen bekannt sein. Autorisierte Spoofing-Tests sollten von repräsentativen Ausgangspunkten aus durchgeführt werden. Nach Routingänderungen muss geprüft werden, ob asymmetrische oder multihomed Pfade weiterhin korrekt behandelt werden.

Resolver- und Randtelemetrie sollten sich zeitlich verbinden lassen. Der Betreiber muss beantworten können, ob ein Resolver extern erreichbar war, welche Antwort er erzeugte, ob die scheinbare Quelle plausibel war, über welchen Link die Last eintrat und welche Kontrolle geändert wurde. Das verlangt keine unbegrenzte Speicherung personenbezogener Daten, wohl aber ausreichend präzise, zweckgebundene Betriebsbelege.

Missbrauchsmeldungen sollten mehr enthalten als eine Liste von IP-Adressen. Ein brauchbarer Hinweis nennt Zeitfenster in UTC, Protokoll, Ziel, scheinbare Quelle, Messmethode, repräsentative Paketmerkmale und eine erreichbare Fallkennung. Empfänger sollten Bearbeitung, verantwortliche Stelle, Änderung und Wiederholungstest dokumentieren. Bei Meldungen an autonome Systeme ist klarzustellen, ob die Adresse einen reflektierenden Resolver oder einen vermuteten Ursprung bezeichnet.

Anycast- und Mitigationsübungen müssen reale Pfade einbeziehen. Ein Anbieter sollte prüfen, welche Standorte die Route ankündigen, wie BGP den Verkehr verteilt, wo Kapazitätsgrenzen liegen und wie sich der Verlust eines Peering- oder Transitpfades auswirkt. Standortbezogene Zähler sind aussagekräftiger als eine einzige globale Kapazitätszahl.

Dienstbetreiber sollten Website, autoritatives DNS, DNSBL-Abfragen, Datenaktualität und Kommunikationskanäle getrennt testen. Ein Gesamtstatus darf diese Unterschiede nicht verdecken. Wiederherstellungsübungen müssen zeigen, dass der Dienst nach einer Routing- oder Provideränderung nicht nur intern als verfügbar gilt, sondern von mehreren externen Netzen tatsächlich erreichbar ist.

Schließlich benötigt jeder fehlgeschlagene Test eine eindeutige Zuordnung. Die Stelle mit praktischer Kontrolle erhält eine Frist, dokumentiert die Reparatur und lässt sie unabhängig erneut prüfen. Abschluss bedeutet nicht, dass eine Konfigurationsdatei geändert wurde. Abschluss bedeutet, dass sich das unerwünschte Verhalten am relevanten Kontrollpunkt nicht mehr reproduzieren lässt und die beabsichtigte Dienstfunktion erhalten bleibt.

Grenzen des öffentlichen Quellenbestands

Der Mechanismus der DNS-Reflexion ist in diesem Fall besser belegt als die universelle Größe des Ereignisses. Cloudflare beschrieb die gefälschten Anfragen, die offenen rekursiven Resolver, die größeren Antworten und den Angriff auf Spamhaus sowie später auf providerseitige Pfade. [1][2] RFC 5358 liefert den vorbestehenden technischen Rahmen für genau diese Art von Missbrauch. [4]

Weniger vollständig ist die räumliche und administrative Verteilung. Der Quellenbestand enthält keine vollständige Liste aller autonomen Systeme, aus denen die ursprünglichen gefälschten Anfragen austraten. Die beobachteten Resolveradressen sind nicht mit diesen Ursprungsnetzen gleichzusetzen. Auch interne Kenntnisstände einzelner Resolver-, Zugangs-, Transit-, Exchange-, Mitigations- oder Dienstbetreiber bleiben unbekannt.

Ebenso fehlt eine universelle Spitzenmessung. Die Werte 10, 75–90, 120 und 300 Gbit/s müssen Cloudflare zugeschrieben und in ihren jeweiligen Beobachtungskontext eingeordnet werden. [1][2] Sie dürfen nicht zu einer Aussage umgeformt werden, das gesamte Internet habe zu einem bestimmten Zeitpunkt genau diesen Angriffsdatenstrom erlebt.

Die Auswirkungen auf unbeteiligte Dienste und Netze sind nicht vollständig erfasst. Gemeinsame Links können Nebenwirkungen erzeugen, doch der vorliegende Bestand misst nicht jeden betroffenen Pfad. Aus der plausiblen Möglichkeit einer Mitbetroffenheit darf keine konkrete Störung für einen nicht dokumentierten Betreiber erfunden werden. Insbesondere gibt es keine Grundlage, einen vollständigen Ausfall eines bestimmten Internetknotens zu behaupten.

Auch die Frage nach den handelnden Personen bleibt begrenzt. Der spätere Hinweis von Spamhaus auf eine Festnahme ist Kontext, aber keine vollständige technische und juristische Zuordnung jeder Handlung, jedes Pakets oder jedes Schadens. [3] Ohne entsprechende Entscheidung darf keine Person als abschließend rechtlich verantwortlich bezeichnet werden.

Schließlich lässt sich der kausale Anteil der einzelnen Betreiber nicht exakt quantifizieren. Tausende Resolver, mehrere Quellnetze, verschiedene Routen und wechselnde Engpässe können zusammenwirken. Ein einzelner Konfigurationsfehler mag austauschbar sein, während die Klasse solcher Fehler wesentlich bleibt. Verantwortlichkeit kann daher einem kontrollierbaren Versäumnis folgen, ohne eine mathematische Aufteilung des Gesamtschadens zu behaupten.

Diese Unbekannten sind kein Anlass, die gesicherten Aussagen abzuwerten. Sie markieren vielmehr die Grenze zwischen Beobachtung und Spekulation. Eine verantwortliche Analyse hält diese Grenze offen sichtbar und verlangt dort zusätzliche Belege, wo weitergehende Zurechnungen vorgenommen werden sollen.

Der abschließende Verantwortlichkeitstest

Der erste Teil des Tests betrifft die Fähigkeit zur Kontrolle. Ein Resolverbetreiber kann festlegen, wer rekursive Dienste nutzen darf, und rekursive von autoritativen Rollen trennen. Ein Zugangsnetz kann an bekannten Kundenrändern unmögliche Quelladressen abweisen. Ein Mitigationsanbieter kann Anycast, Filterung, Routen und Kapazitäten steuern. Ein Dienstbetreiber kann Abhängigkeiten und Verfügbarkeitsaussagen präzise strukturieren.

Der zweite Teil betrifft den Nachweis. Eine Behauptung über geschlossene Rekursion benötigt ein Inventar und externe Negativtests. Eine Behauptung über Quelladressvalidierung benötigt abgedeckte Schnittstellen, zulässige Präfixe, Testresultate und dokumentierte Ausnahmen. Eine Behauptung über Mitigationskapazität benötigt Messpunkte, Site-Daten und Routenverläufe. Eine Behauptung über Dienstkontinuität benötigt getrennte Messungen der betroffenen Endpunkte.

Der dritte Teil betrifft die Reparatur. Ein Betreiber besteht den Test nicht allein durch den Verweis auf eine Richtlinie oder einen späteren Konfigurationswechsel. Er muss zeigen, dass die relevante Änderung im laufenden System wirkte, Neustart und Failover überstand und von außerhalb des betroffenen Pfades bestätigt wurde. Die Reparatur muss außerdem die beabsichtigte Funktion erhalten: autoritatives DNS darf nicht mit offener Rekursion verwechselt, legitimes multihomed Routing nicht durch ungeeignete Filter beschädigt und fortgesetzte DNSBL-Verfügbarkeit nicht aus einer bloßen Website-Messung abgeleitet werden.

Der vierte Teil betrifft die Reichweite der Aussage. Cloudflare kann präzise über seine Beobachtungen berichten, aber nicht ohne zusätzliche Daten einen universellen Internetzustand feststellen. Ein Exchange-Betreiber kann über seine Ports und Fabric sprechen, aber nicht über jeden möglichen End-to-End-Pfad. Spamhaus kann seine Dienstarchitektur und Kommunikation belegen, kontrolliert aber keine entfernten Resolver. Jede Schlussfolgerung muss innerhalb der Sicht und Zuständigkeit ihres Belegs bleiben.

Die Spamhaus-Kampagne ist deshalb mehr als eine historische Erzählung über eine große Datenrate. Sie zeigt, wie verteilte technische Nachlässigkeit zu einer gemeinsamen externen Belastung werden kann. Der Angriffspfad verlief durch reale Software, reale Schnittstellen und reale Routingentscheidungen. Genau dort liegt auch die Möglichkeit der Verbesserung.

Die tragfähige Schlussfolgerung lautet nicht, eine einzelne Institution habe das gesamte Ereignis verursacht oder das Internet sei global ausgefallen. Sie lautet: Offene Rekursion, fehlende Quelladressvalidierung und unzureichend belegte Pfadkontrolle können sich über Tausende Systeme hinweg zu einer erheblichen Last verbinden. Wer einen dieser Kontrollpunkte betreibt, muss dessen Zustand kennen, Änderungen dokumentieren und die Wirkung seiner Reparatur beweisen.

Verantwortlichkeit folgt damit der praktischen Kontrolle. Wo der öffentliche Bestand keine Antwort liefert, bleibt das Ergebnis unbekannt. Wo ein Betreiber eine konkrete Bedingung ändern konnte, genügt weder Rhetorik noch rückblickende Gewissheit. Erforderlich sind nachvollziehbare Betriebsdaten, ein klarer Reparaturschritt und ein unabhängiger Nachweis, dass der unerwünschte Pfad tatsächlich geschlossen wurde.

Wie der Spamhaus-DDoS von 2013 offene DNS-Rekursion zum Test der Netzwerkverantwortung machte