DNS-DDoS: Wenn der Nameserver zum Engpass wird

Der Webserver antwortet, die Datenbank läuft, das Uptime-Monitoring meldet 200 OK. Trotzdem schreiben Kunden, die Seite sei weg. Wer so einen Nachmittag einmal erlebt hat, prüft beim nächsten Mal zuerst das DNS.

Was ein DNS-DDoS eigentlich trifft

Jeder Seitenaufruf beginnt mit einer Frage an das DNS: Welche IP gehört zu shop.example.de? Der Resolver des Besuchers (beim Provider, bei Google, bei Cloudflare) fragt dafür die autoritativen Nameserver deiner Domain. Genau diese Server sind das Ziel eines DNS-DDoS.

Sind sie nicht erreichbar, bekommt der Resolver keine Antwort. Er versucht es eine Weile, gibt dann auf und meldet dem Browser einen Fehler. Ob dein Webserver gesund ist, spielt keine Rolle mehr. Er wird schlicht nicht gefunden.

Das macht DNS zu einem attraktiven Angriffspunkt: Ein Nameserver bedient oft Tausende Domains, eine Überlastung trifft alle gleichzeitig. Beim Angriff auf den DNS-Anbieter Dyn am 21. Oktober 2016 durch das Mirai-Botnetz waren viele große Websites in Teilen Europas und Nordamerikas stundenweise nicht erreichbar, obwohl ihre eigenen Server liefen.

Drei Muster von DNS-Angriffen

Nicht jeder DNS-Angriff sieht gleich aus. Die Gegenmaßnahmen unterscheiden sich deutlich.

Der Random-Subdomain-Angriff ist der heimtückischste. Weil jede Anfrage einen neuen, nie gesehenen Namen enthält, kann kein Resolver sie aus dem Cache beantworten. Alle landen bei deinen autoritativen Servern. Für den Resolver sieht das aus wie normaler Verkehr, nur sehr viel davon.

Die dritte Variante beschreibt der Artikel über DNS-Amplification genauer. Einen Überblick über alle Angriffsklassen außerhalb des DNS findest du unter DDoS-Arten.

So erkennst du einen Angriff auf dein DNS

Der wichtigste Test: Liefern deine Nameserver noch Antworten, und zwar alle?

dig example.de NS +short

for ns in $(dig example.de NS +short); do
  echo "== $ns"
  dig @"$ns" example.de A +short +time=2 +tries=1
done

Kommt bei einem Server ;; connection timed out; no servers could be reached, ist er aus deiner Sicht nicht erreichbar. Fallen alle aus, ist die Domain tot, egal wie gut der Rest läuft.

Weitere Hinweise:

• Externe Monitoring-Dienste melden „DNS resolution failed“, während Checks per IP funktionieren.
• Dein DNS-Anbieter zeigt in seinen Statistiken einen Anstieg von NXDOMAIN-Antworten. Ein plötzlicher Sprung von wenigen Prozent auf die Mehrheit aller Antworten ist ein klares Signal für Random-Subdomain-Anfragen.
• Betreibst du die Nameserver selbst, steigen CPU-Last und eingehende UDP-Pakete auf Port 53 sprunghaft.

Wie du einen Angriff von einem normalen Ansturm unterscheidest, steht ausführlicher unter DDoS-Attacke erkennen.

TTL als Puffer: eine kleine Rechnung

Resolver speichern Antworten so lange, wie die TTL erlaubt. Solange ein Eintrag im Cache liegt, braucht niemand deine Nameserver. Das ist dein Puffer.

Ein Beispiel: Dein A-Record hat eine TTL von 300 Sekunden. Fällt das DNS aus, sind nach spätestens fünf Minuten die meisten Caches leer, und neue Besucher sehen Fehler. Bei 3.600 Sekunden hast du bis zu einer Stunde, bei 86.400 Sekunden theoretisch einen Tag.

Ganz so sauber ist es in der Praxis nicht: Caches laufen zu unterschiedlichen Zeitpunkten ab, und manche Resolver begrenzen die TTL nach oben. Einige große Resolver liefern nach RFC 8767 („serve-stale“) abgelaufene Einträge weiter aus, wenn die autoritativen Server nicht antworten. Darauf verlassen solltest du dich nicht, es ist ein Bonus.

Zwei Netze statt zwei Server

Viele Registries verlangen mindestens zwei Nameserver. Die meisten Domaininhaber erfüllen das mit ns1 und ns2 beim selben Anbieter, im selben Rechenzentrum, oft im selben Netz. Gegen einen Hardwaredefekt hilft das. Gegen einen DDoS auf diesen Anbieter nicht.

Echte Ausfallsicherheit entsteht durch Diversität:

• Anycast-Nameserver. Dieselbe IP wird an vielen Standorten angekündigt, Angriffsverkehr verteilt sich. Wie das funktioniert und wo die Grenzen liegen, erklärt Anycast-DNS.
• Ein zweiter, unabhängiger DNS-Anbieter. Die Zone liegt bei Anbieter A und wird per Zonentransfer zu Anbieter B gespiegelt. Fällt A aus, beantwortet B weiter. Wie das konkret eingerichtet wird, zeigt Secondary DNS.
• Unterschiedliche Netze und Domains für die Nameserver. Liegen ns1.anbieter-a.net und ns2.anbieter-b.com bei verschiedenen Providern, trifft ein Angriff auf einen nicht automatisch den anderen.

Die Nameserver trägst du beim Registrar ein. Dort sollte die Nameserver-Verwaltung frei konfigurierbar sein, damit du mehrere Anbieter mischen kannst.

Checkliste für deine Domain

• Mindestens zwei Nameserver, die nicht im selben Netz liegen
• Mindestens ein Anbieter mit Anycast
• NS-Einträge beim Registrar und in der Zone stimmen überein
• TTL für stabile Einträge bei 3.600 Sekunden oder mehr
• Monitoring, das DNS-Auflösung separat prüft, nicht nur HTTP per IP
• Eigene Nameserver: Rekursion aus, Response Rate Limiting an
• DNSSEC aktiv und die DS-Einträge beim Registrar korrekt
• Zugang zum Registrar-Konto mit Zwei-Faktor-Anmeldung geschützt

Der letzte Punkt klingt nach einem anderen Thema. Er ist es nicht: Wer im Angriff schnell auf einen anderen DNS-Anbieter umschalten will, braucht sofortigen Zugriff auf die Nameserver-Einstellungen beim Registrar.

Was DNSSEC hier leistet und was nicht

DNSSEC signiert Antworten kryptografisch. Ein Resolver erkennt damit gefälschte Einträge, etwa wenn jemand im Schatten eines Angriffs versucht, Besucher auf eine falsche IP umzuleiten. Gegen Überlastung hilft DNSSEC nicht.

Es gibt sogar einen Nebeneffekt: Signaturen machen Antworten größer. Für Angreifer, die Reflexion nutzen, ist das interessant, weshalb Response Rate Limiting auf signierten Zonen besonders sinnvoll ist. Ein Grund gegen DNSSEC ist das nicht. Wenn du einen Registrar mit DNSSEC-Unterstützung nutzt, kostet dich die Absicherung wenige Klicks.

Wenn der Angriff gerade läuft

1. Prüfe mit den dig-Befehlen oben, welche Nameserver noch antworten.
2. Informiere deinen DNS-Anbieter mit Uhrzeit und betroffener Domain.
3. Hast du einen vorbereiteten Secondary bei einem zweiten Anbieter, aktiviere ihn beim Registrar als zusätzlichen Nameserver.
4. Erhöhe die TTL nicht während des Angriffs, das wirkt erst beim nächsten erfolgreichen Abruf. Plane es für danach.
5. Dokumentiere Zeitpunkte und Fehlermeldungen. Die brauchst du für eine Anzeige und für die eigene Nachbereitung.

Die allgemeinen Sofortmaßnahmen, auch für Angriffe auf den Webserver, stehen unter DDoS-Attacke: was tun.

Am schnellsten gewinnst du Ausfallsicherheit mit einem zweiten Nameserver-Anbieter. Bevor du ihn einrichtest, lohnt ein Blick auf die eigene Domain: Wo liegt sie, wer hat Zugriff, ist DNSSEC aktiv? Wenn du eine neue Domain für ein Projekt brauchst, kannst du bei betadomain den Namen auf Verfügbarkeit prüfen und die Nameserver von Anfang an verteilt anlegen.