DNS-Flood-Angriff: Wie er abläuft und wie Sie Ihre Abwehr prüfen

Bevor der Browser eines Kunden Ihre Login-Seite laden kann, bevor ein Zahlungspartner Ihre API aufruft, bevor Ihre eigenen Mitarbeitenden ein internes System öffnen, muss aus einem Namen eine Adresse werden. Diese Abfrage steht ausnahmslos am Anfang, und solange die Antwort aussteht, kommt dahinter nichts in Gang.

Damit ist DNS die eine Abhängigkeit, bei der es nichts nützt, wenn alles andere einwandfrei läuft. Ein DNS-Flood-Angriff berührt Ihre Webserver nie. Er richtet sich gegen den Resolver, der Anfragen nach Ihren Domains beantwortet, und fällt dieser Resolver aus, laufen alle Ihre Server weiter, nur erreicht sie niemand mehr. Ihre Dashboards melden, dass alles in Ordnung ist, und damit haben sie sogar recht. Es kommt nur niemand mehr durch, der etwas anderes berichten könnte.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio durchführt, einer je Angriff. Sie setzen an ganz unterschiedlichen Stellen an; ein Testprogramm muss deshalb alle Kategorien abdecken, statt in einer einzigen das Volumen hochzudrehen. Wie sie zusammenspielen, zeigt unser Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was bei einem DNS-Flood-Angriff tatsächlich passiert

Obsidios DNS Flood baut reine DNS-Anfragepakete und schickt sie über TCP an den Ziel-Resolver, formatiert, wie es das Protokoll verlangt: zwei Byte Längenfeld, zwölf Byte DNS-Header, dann die Frage. Dieses Präfix ist keine Designentscheidung. RFC 1035 Abschnitt 4.2.2 legt für TCP fest: «the message is prefixed with a two byte length field which gives the message length, excluding the two byte length field.»

Jede parallele Schleife wiederholt danach pausenlos denselben kurzen Ablauf: Sie öffnet eine neue TCP-Verbindung, schreibt eine Anfrage, wartet auf das erste Byte der Antwort, baut den Socket ab und beginnt von vorn. Die Last landet an zwei Stellen: bei CPU und Speicher des Resolvers, der die Anfrage parst und die Rekursion erledigt, und bei den TCP-Listener-Ressourcen, also Filedeskriptoren und der Tiefe der Accept-Queue.

Stellen Sie sich einen Schwarm von Anrufern vor, die bei der Telefonauskunft eine Nummer erfragen, auflegen und sofort wieder wählen. Jeder Anruf ist eine neue Verbindung, und die Zentrale ist längst voll, bevor der Auskunft die Nummern ausgehen.

Warum TCP und nicht UDP

Die meisten öffentlichen Texte über DNS-Floods gehen von UDP aus, weil echte Angreifer darauf setzen. UDP braucht keinen Handshake, deshalb lässt sich die Absenderadresse fälschen, und genau das macht Reflection und Amplification möglich. Obsidio nutzt keines von beiden, und TCP ist der Grund dafür. Ein abgeschlossener Handshake bedeutet, dass jede Anfrage von einem echten, erreichbaren Gerät kommt, das der Teilnahme zugestimmt hat. Keine Absenderadresse ist gefälscht, und es wird nie Verkehr auf Dritte gelenkt.

TCP bringt zudem etwas, das UDP nicht leisten kann. Weil die Schleife auf das erste Antwortbyte wartet, bevor sie schliesst, liefert jeder Versuch eine Antwort oder das Ausbleiben einer Antwort. Sie messen damit die Auflösungszeit von Ende zu Ende und nicht bloss die Kosten eines Handshakes. Ein Handshake pro Anfrage verteuert jede einzelne, deshalb liegen die erreichbaren Raten niedriger als bei einem UDP-Flood mit gefälschten Absenderadressen. Dafür begrenzt sich die Last von selbst.

Ein Randfall ist TCP damit nicht. RFC 9210 ist deutlich: «All DNS resolvers and servers MUST support and service both UDP and TCP queries». Das Dokument hält zudem fest, dass es zu einer verbreiteten Reaktion auf DNS-Denial-of-Service-Angriffe mit gefälschten Absenderadressen geworden ist, Clients über eine gekürzte UDP-Antwort zu einem erneuten Versuch über TCP zu bewegen («has become a common response to source-address-spoofed, DNS denial-of-service attacks»). Unter Angriffslast schiebt Ihr Rate Limiting legitime Clients also auf den TCP-Pfad, und genau diesen Pfad misst dieser Test.

Welche Ihrer Schutzmassnahmen hätten das abfangen müssen

Gehen Sie die ganze Kette durch, die eine Anfrage passiert, dann lautet die ehrliche Antwort für die erste Zone: Das meiste davon liegt gar nicht im Pfad. Ihre Website steht hinter einer WAF und einem Scrubbing-Dienst. Ihr DNS antwortet auf Port 53 an Ihren Nameservern, häufig bei einer ganz anderen Firma, und Verkehr an diese Nameserver läuft an den Schutzmassnahmen Ihrer Website vollständig vorbei. Diese vordere Zone wird durch die Architektur umgangen, nicht durch eine Technik.

Dass die erste Zone nichts sieht, ist kein Konfigurationsfehler, sondern eine Folge davon, wo DNS in der Architektur steht. Die Frage nach der Abdeckung stellt sich hier deshalb anders: Am eigenen Netzrand lässt sich das nicht beheben, Sie müssen also die Grenzen Ihres Anbieters kennen, und zwar gemessen statt vermutet.

Die Parameter – und wer den Resolver tatsächlich betreibt

Vier Einstellungen prägen einen Durchlauf:

• Parallele Anfragen pro Worker. Standard 20, einstellbar von 1 bis 100. So viele Anfragen hält ein Worker gleichzeitig offen; das entspricht unmittelbar der Zahl offener Sockets zum Resolver.
• Port. Standard 53. Ein abweichender Port erreicht Shims, die woanders lauschen, mit einer Einschränkung: Diese Simulation sendet reines DNS und prüft damit keinen DoH- oder DoT-Endpunkt.
• Zufällige Subdomains. Standardmässig aktiv. Jeder Anfrage wird ein zwölf Zeichen langes zufälliges Label vorangestellt, sodass keine gecachte Antwort existieren kann und der Resolver den vollen Lookup machen muss. Abgeschaltet fangen die Caches nahezu alles ab.
• Query-Typen. Standard sind A, AAAA, MX und ANY, dazu verfügbar sind TXT, CNAME, NS und SOA. Pro Anfrage wird einer zufällig gewählt, weil Record-Typen unterschiedliche Codepfade auslösen und unterschiedlich grosse Antworten erzeugen. Viele Resolver verweigern oder begrenzen ANY; eine Ablehnung ist deshalb ein Ergebnis und kein Fehler.

Die Plattform rechnet mit 20 Anfragen pro Sekunde je paralleler Schleife, unter der Annahme, dass der Resolver innerhalb von 50 ms antwortet. Die Berichte enthalten die Zahl der aktuell offenen Sockets und eine Aufschlüsselung, wie viele Anfragen je Record-Typ hinausgingen.

Bleibt die Frage nach dem Ziel, und an dieser Stelle wird DNS-Testing organisatorisch heikel. Autoritative Server halten Ihre Zonen und beantworten Anfragen von aussen nach Ihren Domains. Rekursive Resolver lösen für Ihre eigenen Clients die Namen aller anderen auf. Fällt die autoritative Seite aus, erreichen Kunden und Partner Sie nicht mehr. Fällt die Rekursion aus, kommen Ihre Mitarbeitenden und Anwendungen nicht mehr nach draussen, Zahlungsnetze und Marktdaten-Feeds eingeschlossen.

In einer typischen Bank betreiben zwei verschiedene Teams diese beiden Dienste. Das autoritative DNS liegt meist bei einem Managed-Provider, aus Redundanzgründen manchmal bei zweien, ausgewählt von denen, die das Domainportfolio verwalten. Die Rekursion läuft in der Regel intern auf der Directory-Plattform und gehört zur Infrastruktur, nicht zur Security. Keines der beiden Teams sieht sich zwangsläufig für eine DDoS-Schutzmassnahme zuständig. Klären Sie vor jeder Festlegung des Prüfumfangs, welchen der beiden Dienste Sie testen, denn davon hängt ab, welche Teams Sie einbeziehen müssen.

Wie Sie sich gegen einen DNS-Flood-Angriff verteidigen

Die Schutzmassnahmen, die hier zählen, sitzen meist nicht am Netzrand vor Ihrer Website.

• Response Rate Limiting, sobald es jemand einschaltet. ISC hält klar fest, dass RRL in BIND 9 standardmässig ausgeschaltet ist («is turned off by default»), und für NSDs rrl-ratelimit gilt dasselbe: «default is off (with a suggested 200 qps)». Verstehen Sie die Funktion, bevor Sie sich darauf verlassen: RRL bremst übermässig viele, fast identische UDP-Antworten, und das Standardverhalten drängt den Client zu einem neuen Versuch über TCP. Gegen UDP-Floods mit gefälschten Absenderadressen ist das eine echte Schutzmassnahme. Gegen Anfragen, die schon über TCP eintreffen und nach durchweg verschiedenen Namen fragen, bewirkt es sehr wenig.
• Kapazität und Anycast. RFC 4786 formuliert es genau: Ein Knoten könne als Senke für Angriffsverkehr aus seinem Einflussbereich dienen und damit verhindern, dass sich Knoten andernorts mit diesem Verkehr befassen müssen («can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic»); die Aufgabe, breit gestreuten Angriffsverkehr zu bewältigen, verteile sich dann ihrerseits auf alle Knoten, die den Dienst erbringen («the task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes that contribute to the service»). Achten Sie auf die Bedingung im zweiten Satz. Anycast verteilt eine breit gestreute Last über mehrere Knoten, das hilft; zugleich bedeutet es, dass ein wirklich globaler Angriff an vielen Knoten gleichzeitig eintrifft, statt von einem aufgefangen zu werden.
• Resolver-Grenzen, die Sie sich angesehen haben. Die Standardwerte sind niedrig angesetzt. NSD dokumentiert tcp-count als maximale Zahl gleichzeitiger aktiver TCP-Verbindungen je Server, standardmässig 100 («the maximum number of concurrent, active TCP connections by each server. Default is 100»), bei einem tcp-timeout von 120 Sekunden. Unbound reserviert 10 incoming-num-tcp-Puffer pro Thread und setzt tcp-idle-timeout standardmässig auf 30 Sekunden. RFC 7766 erlaubt die naheliegende Gegenmassnahme: Server dürfen die Zahl gleichzeitiger TCP-Verbindungen je Client-IP oder Subnetz begrenzen («MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet»). Gegen eine einzelne Quelle funktioniert das, gegen eine verteilte fällt es deutlich schwächer aus.
• Rekursion nur für Ihre eigenen Clients. Ein Resolver, der dem ganzen Internet antwortet, ist ein weit grösseres Ziel, und er lässt sich gegen andere missbrauchen. Unbound macht das von Haus aus richtig: «by default only localhost (the 127.0.0.0/8 IP netblock, not the loopback interface) is implicitly allowed, the rest is refused.» Konfigurationen verändern sich mit der Zeit; prüfen Sie es also nach, statt sich darauf zu verlassen.
• Anbieterseitige Schutzmassnahmen, schriftlich. Wenn jemand anderes Ihr DNS betreibt, steht das meiste davon in seiner Konfigurationsdatei. Fragen Sie nach den Grenzwerten pro Quelle und in der Summe, nach dem Anycast-Footprint und danach, wie Sie im Ernstfall jemanden ans Telefon bekommen. Eines können Sie allein tun: an einen zweiten, unabhängigen Anbieter delegieren.

Was sich als vermeintlich einfache Lösung verbietet: DNS über TCP zu blockieren. RFC 9210 ist eindeutig, dass das Filtern von DNS über TCP im Allgemeinen schädlich ist («the filtering of DNS over TCP is harmful in the general case»); Netze, die TCP-Port 53 blockieren, riskieren, den Zugang zu erheblichen oder wichtigen Teilen des DNS-Namensraums zu verlieren («risk losing access to significant or important pieces of the DNS namespace»).

Was Sie selbst prüfen können und wo die Ergebnisse täuschen

Einiges davon können Sie heute beantworten. Es lohnt sich zu wissen, welche Teile das sind und wo eine billige Prüfung in die Irre führt.

Lesen Sie die Konfiguration, oder fordern Sie sie an. Notieren Sie die Obergrenze für gleichzeitige Verbindungen, die Timeouts, ob die Rekursion eingeschränkt ist, ob Rate Limiting überhaupt aktiv ist. Betreibt ein Anbieter den Dienst, tritt dieses Gespräch an die Stelle der eigenen Prüfung. Damit wissen Sie, wo die Grenzen liegen. Sie wissen aber nicht, was geschieht, wenn Sie sich ihnen nähern, denn die Leistung eines Resolvers bricht nicht linear ein.

Testen Sie die Alarmierungswege für sich. Lösen Sie einen synthetischen Alarm aus und sehen Sie nach, ob er beim richtigen Pikettdienst landet und ob jemand handelt. Das prüft die Kette bis zum Menschen und braucht keinen Angriffsverkehr. Ob ein DNS-Ausfall überhaupt einen Alarm auslösen würde, sagt es nicht, und genau das ist die Lücke in der dritten Zone.

Fragen Sie Ihren eigenen Resolver von einer einzelnen Maschine ab, mit Freigabe und gegen Infrastruktur, die Ihnen gehört. Das ist nützlich für eine Latenz-Baseline und um zu bestätigen, welche Record-Typen beantwortet werden. Und genau hier liegt die Falle.

Eine einzelne Quelle lässt die offenen Fragen nicht nur unbeantwortet; sie beantwortet mehrere davon falsch, und zwar beruhigend falsch. Ein Verbindungslimit pro Quelle greift bei einer einzelnen Adresse sofort. Ihr Anbieter filtert sie vielleicht als offensichtlichen Missbrauch heraus, bevor sie überhaupt als Last registriert wird. Nichts kommt einer Kapazitätsgrenze nahe, der Durchlauf endet ohne Befund, die Latenz bleibt unauffällig, und das Fazit lautet: DNS hält. So sieht ein echter verteilter Angriff nicht aus. Tausende einzelner IP-Adressen aus Privathaushalten öffnen je eine überschaubare Zahl von Verbindungen, keine Quelle überschreitet einen Schwellenwert, und die Summe kommt am Resolver trotzdem an.

Wie Obsidio einen DNS-Flood-Angriff testet

Die Autorisierung steht am Anfang, und diese Simulation hat einen Haken, den die anderen neun nicht haben.

Obsidio weist die Domain-Inhaberschaft über einen DNS-TXT-Eintrag nach, bevor der erste Verkehr fliesst, fährt die Last stufenweise hoch, und jeder Durchlauf lässt sich live abbrechen. Das deckt Infrastruktur ab, die Ihnen gehört. Einen Resolver, den jemand anderes betreibt, deckt es damit noch nicht ab. Ist Ihr autoritatives DNS an einen Anbieter delegiert, sind dessen Nameserver geteilte Infrastruktur, die weitere Kunden bedient, und dass die Domain Ihnen gehört, berechtigt Sie nicht, Last gegen Maschinen zu autorisieren, die Ihnen nicht gehören. Legen Sie den Prüfumfang ausdrücklich mit Ihrem Anbieter fest und holen Sie sein schriftliches Einverständnis ein, bevor der Durchlauf gebucht wird. Manche Anbieter unterstützen autorisierte Tests auf Anfrage, manche führen sie in Ihrem Auftrag selbst durch. Beides ist ein legitimer Weg. Stillschweigend voraussetzen dürfen Sie es nicht. Wo Sie die Rekursion auf eigenen Resolvern betreiben, gilt der übliche Autorisierungsweg, und der Prüfumfang ist rasch bestimmt.

Ist das geklärt, wählen Sie das Ziel, die Parallelität pro Worker, die Record-Typen und ob zufällige Subdomains den Cache aushebeln. Die Last kommt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Instanzen im Rechenzentrum, sodass Verbindungslimits pro Quelle so geprüft werden, wie ein verteilter Angriff sie prüfen würde.

Zwei Grössen sollten Sie während des Durchlaufs beobachten:

• Auflösungszeit und Fehlerrate, in dieser Reihenfolge. Weil jede Anfrage auf eine echte Antwort wartet, messen Sie genau das, was Ihre Kunden erleben. Ein Resolver unter Druck wird langsam, lange bevor er Anfragen ablehnt, und schon in dieser Phase beginnt der Schaden für die Nutzer.
• Offene Verbindungen gegen die dokumentierte Obergrenze. Bleibt die Parallelität bei einer runden Zahl stehen, während die Latenz steigt, haben Sie die Grenze gefunden. Sie kennen sie dann als Messwert und nicht als Standardwert in einem Handbuch.

Klären Sie vorab nüchtern, was der Test zeigen kann und was nicht. Obsidio kann messen, was von aussen sichtbar ist: Auflösungszeit, Fehlerrate, wie viele Verbindungen offen gehalten wurden und wie Ihre Infrastruktur am Netzrand darauf reagiert hat. Ob das Team Ihres Anbieters etwas bemerkt hat, ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, zeigt sich nur in Ihren Konsolen und in denen des Anbieters. Sorgen Sie dafür, dass während des Zeitfensters jemand beide im Blick hat.

Stärke wird bewiesen, nicht versprochen. Bei einem DNS-Flood-Angriff zählt nicht, wie viel Bandbreite Sie eingekauft haben. Entscheidend ist, ob den einen Dienst, von dem alle anderen abhängen, je jemand geprüft hat, die Firma eingeschlossen, die Sie für seinen Betrieb bezahlen.

Wo das in ein Testprogramm gehört

Der DNS Flood ist die protokollspezifische Kategorie. Jede andere Simulation zielt auf Ihren Anwendungs-Stack, ihre Befunde betreffen also Ihre Server, Ihre Timeouts und Ihre Schwellenwerte. Diese zielt auf eine Abhängigkeit, und deshalb ist es meist der Durchlauf, der eine Zuständigkeit sichtbar macht, die vorher niemand benannt hatte. Am nächsten verwandt ist der TCP-Connection-Flood, der ebenfalls über ständig neue Verbindungen ansetzt, dort aber untätige Sockets auf einem Server offen hält, über den Sie selbst verfügen. Hier transportiert jeder Socket eine echte Anfrage an einen Resolver, der Ihnen möglicherweise gar nicht gehört, und gemessen wird die Antwort, auf die er wartet.

Die zehn Simulationstypen führen an ganz unterschiedlichen Stellen zum Ausfall. Slowloris prüft, ob sich je jemand Ihre Verbindungs-Timeouts angesehen hat. Ein HTTP-Flood-Angriff findet das knappste Limit in Ihrem Stack. Ein DNS-Flood-Angriff prüft etwas, das Sie vielleicht nicht im Prüfumfang vermutet hätten. Entscheidend ist die Abdeckung aller Kategorien, nicht das Volumen in einer einzelnen.

Für regulierte Institute muss ein Test auch einen Nachweis hinterlassen. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte mit Zuordnung zu FINMA, DORA und NIS2, generiert in Trusted Execution Environments. Das Ergebnis eines Durchlaufs ist damit ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie sich verbürgen müssen.

Die DNS-Simulation gibt es auf Anfrage und nicht als Standardoption, unter anderem weil das oben beschriebene Gespräch über den Prüfumfang vorher stattfinden muss. Um einen Durchlauf gegen Infrastruktur zu vereinbaren, die Sie testen dürfen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.