Verhinderung von DNS-Spoofing und Cache-Poisoning

Jeder Website-Besuch, jede E-Mail-Zustellung und die meisten API-Aufrufe beginnen mit einem DNS-Lookup. Schafft es ein Angreifer, dass dieser Lookup die falsche Adresse liefert, spricht der Nutzer mit dem falschen Server – während die Adressleiste weiterhin den korrekten Domainnamen zeigt. Das ist der Kern von DNS-Spoofing, und seine schädlichste Form, das Cache Poisoning, kann Tausende Nutzer auf einmal treffen. Dieser Leitfaden erklärt auf konzeptioneller Ebene, wie diese Angriffe funktionieren, warum eine Entdeckung im Jahr 2008 die Bauweise von Resolvern veränderte und welche Abwehrmaßnahmen Domaininhaber und Netzbetreiber heute umgesetzt haben sollten. Der Fokus liegt ausschließlich auf der Verteidigung: die Schwachstelle so gut zu verstehen, dass man sie schließen kann.

Was DNS-Spoofing und Cache Poisoning tatsächlich bedeuten

DNS-Spoofing ist ein Sammelbegriff für jede Situation, in der ein Client eine DNS-Antwort erhält, die nicht von der legitimen Quelle stammt. Das kann in einem kompromittierten WLAN passieren, durch Malware, die die lokale hosts-Datei verändert, oder durch einen gefälschten DNS-Server, den ein manipulierter Router verteilt.

Cache Poisoning ist eine spezielle und deutlich ernstere Variante. Rekursive Resolver – betrieben von Internetanbietern, Unternehmen und öffentlichen DNS-Diensten – speichern Antworten zwischen, um Zeit zu sparen. Bringt ein Angreifer einen Resolver dazu, einen gefälschten Record anzunehmen und zu cachen, liefert dieser den falschen Record an jeden Client aus, der nach dem Namen fragt, bis seine Time to Live (TTL) abläuft. Eine einzige erfolgreiche Injektion kann so eine große Zahl von Nutzern umleiten, ohne eines ihrer Geräte anzufassen.

Der Grund ist historisch. Klassisches DNS läuft überwiegend über UDP, ein verbindungsloses Protokoll, und das ursprüngliche Design ging von einem einigermaßen vertrauenswürdigen Netz aus. Ein Resolver akzeptierte die erste plausible Antwort, die zu seiner offenen Frage passte. Einen eingebauten Weg, die Herkunft einer Antwort zu beweisen, gab es nicht.

Wie ein Resolver entscheidet, einer Antwort zu vertrauen

Schickt ein Resolver eine Anfrage an einen autoritativen Server, erhält er später eine Antwort und muss entscheiden, ob sie zu seiner Frage gehört. Traditionell prüft er eine Handvoll Felder:

• Der Question-Abschnitt muss zu Name und Typ der Anfrage passen.
• Die Transaktions-ID, eine 16-Bit-Zahl, muss der ID der Anfrage entsprechen.
• Die Antwort muss von der IP-Adresse und dem Port kommen, an die die Anfrage ging, und am Quellport eintreffen, den der Resolver genutzt hat.

Stimmt all das überein, wird die Antwort akzeptiert. Ein Off-Path-Angreifer, der den echten Verkehr nicht sieht, muss diese Werte erraten. Vor 2008 nutzten viele Resolver einen festen oder vorhersehbaren Quellport, sodass nur die 16-Bit-Transaktions-ID übrig blieb – gerade einmal 65.536 Möglichkeiten. Für einen entschlossenen Angreifer, der schnell viele Pakete senden kann, ist das ein kleiner Suchraum.

Der Kaminsky-Angriff von 2008 und seine Bedeutung

Schwächen bei Transaktions-IDs waren lange vor 2008 bekannt, doch Verteidiger trösteten sich mit dem Caching selbst: Hatte ein Resolver eine gültige Antwort im Cache, musste ein Angreifer bis zum Ablauf der TTL warten, bevor er es erneut versuchen konnte. 2008 zeigte der Sicherheitsforscher Dan Kaminsky, dass dieser Trost trügerisch war.

Seine Erkenntnis, hier nur grob skizziert: Ein Angreifer musste nicht um genau den Namen wetteifern, den er kapern wollte. Indem er Lookups für viele verschiedene nicht existierende Subdomains auslöste, konnte er jedes Mal ein neues Rennen starten, und eine gefälschte Antwort konnte zusätzliche Records enthalten, die die gesamte Domain auf vom Angreifer kontrollierte Nameserver lenkten. Der Schutz durch lange TTLs verschwand, und ein vorhersehbarer Resolver ließ sich in kurzer Zeit vergiften.

Die Veröffentlichung führte im Juli 2008 zu einer ungewöhnlich gut koordinierten Patch-Welle über viele Hersteller hinweg. Die überall ausgelieferte Lösung war kein Neuentwurf von DNS, sondern ein Weg, das Raten drastisch zu erschweren: die Randomisierung des Quellports. Kaminsky und andere betonten, dass dies eine Abmilderung sei und die langfristige Antwort in der kryptografischen Validierung durch DNSSEC liege.

Mehrschichtige Schutzmaßnahmen im Resolver

Moderne Resolver kombinieren mehrere Techniken, die jeweils zusätzliche Unvorhersehbarkeit in eine Anfrage bringen, sodass ein Off-Path-Angreifer deutlich mehr raten muss.

Randomisierung des Quellports

Statt jede Anfrage vom selben UDP-Port zu senden, wählt der Resolver für jede Anfrage einen zufälligen Quellport aus einem großen Bereich. Zusammen mit der zufälligen 16-Bit-Transaktions-ID vervielfacht das die Zahl der zu erratenden Werte um das Zehntausendfache. Aus einem praktikablen Angriff wurde ein sehr viel teurerer – deshalb wurde dies 2008 zur Standardantwort. Beachten Sie, dass manche NAT-Geräte und Firewalls Quellports vorhersehbar umschreiben und diesen Schutz so unbemerkt aushebeln können; das Verhalten am Netzwerkrand zu prüfen lohnt sich.

0x20-Kodierung (Randomisierung der Schreibweise)

DNS-Namen unterscheiden nicht zwischen Groß- und Kleinschreibung, doch die meisten autoritativen Server übernehmen die Frage exakt so in ihre Antwort, wie sie sie erhalten haben. Die sogenannte 0x20-Kodierung – benannt nach dem Bit, in dem sich ASCII-Groß- und Kleinbuchstaben unterscheiden – würfelt die Schreibweise des Anfragenamens zufällig, etwa wWw.ExAmPlE.cOm. Der Resolver prüft dann, ob die Antwort dasselbe Muster beibehält. Jeder Buchstabe fügt etwa ein Bit Entropie hinzu. Bei kurzen Namen ist das weniger wirksam, und Server, die die Schreibweise nicht erhalten, müssen toleriert werden – Resolver setzen die Technik daher meist mit Fallbacks ein.

Weitere Prüfungen im Resolver

• Bailiwick-Prüfung: Records in einer Antwort verwerfen, die außerhalb der Zone liegen, für die der Server autoritativ ist.
• Gehärteter Umgang mit Glue: verhindern, dass Records aus dem Additional-Abschnitt vertrauenswürdige Cache-Daten überschreiben.
• Rate Limiting und Schwellen für unerwünschte Antworten: Fluten nicht passender Antworten erkennen und reagieren, etwa durch einen erneuten Versuch über TCP.
• QNAME-Minimierung (RFC 7816, später RFC 9156): jedem Server nur den nötigen Teil des Namens schicken, was den Datenabfluss reduziert.

Die folgende Tabelle fasst zusammen, was jede Maßnahme schützt und wo ihre Grenzen liegen.

DNSSEC: beweisen, dass eine Antwort echt ist

Alle bisherigen Maßnahmen erschweren Fälschungen, doch keine erlaubt es dem Resolver, die Echtheit eines Records zu beweisen. DNSSEC kann das. Der Zoneninhaber signiert seine Records mit privaten Schlüsseln, veröffentlicht die passenden öffentlichen Schlüssel als DNSKEY-Records, und die Elternzone veröffentlicht einen DS-Record, der für den Schlüssel der Kindzone bürgt. Ein validierender Resolver folgt dieser Vertrauenskette von der Root bis zum empfangenen Record. Lässt sich die Signatur nicht verifizieren, gibt der Resolver einen Fehler (SERVFAIL) zurück statt einer womöglich gefälschten Antwort.

Für Domaininhaber heißt das: Der wirksamste Schritt, den Sie selbst gegen das Vergiften Ihrer eigenen Namen unternehmen können, ist, Ihre Zone zu signieren und sicherzustellen, dass der DS-Record über Ihren Registrar bei der Registry hinterlegt ist. Einrichtung und Fallstricke beschreiben wir ausführlich in Warum DNSSEC für die Domainsicherheit unverzichtbar ist. Zwei praktische Warnungen: Schlüsselwechsel (Rollovers) müssen geplant werden, und wenn Sie den DNS-Anbieter wechseln, müssen Sie den DS-Record aktualisieren oder entfernen – sonst halten validierende Resolver Ihre Domain für defekt.

Verschlüsseltes DNS: DoT und DoH

DNSSEC authentifiziert Daten, verbirgt sie aber nicht, und die Strecke zwischen Laptop oder Smartphone und Resolver ist oft der am stärksten exponierte Teil des Weges, besonders in öffentlichen WLANs. Zwei Standards verschlüsseln diese Strecke:

• DNS over TLS (DoT), definiert in RFC 7858, verpackt DNS in TLS auf einem eigenen Port, 853. Netzbetreiber können es leicht erkennen und verwalten.
• DNS over HTTPS (DoH), definiert in RFC 8484, transportiert DNS-Nachrichten innerhalb von HTTPS auf Port 443, fügt sich damit in normalen Web-Traffic ein und wird von Browsern und Betriebssystemen breit unterstützt.

Beide verhindern, dass ein On-Path-Angreifer Antworten zwischen Client und Resolver liest oder unbemerkt verändert – vorausgesetzt, der Client authentifiziert das Zertifikat des Resolvers. Keines ersetzt DNSSEC: Ist der Resolver selbst vergiftet, liefert auch ein verschlüsselter Kanal die vergiftete Antwort getreu aus. Am stärksten ist die Kombination aus verschlüsseltem Transport und einem validierenden Resolver.

Eigene Resolver härten

Betreiben Sie rekursive Resolver für ein Büro, ein Rechenzentrum oder Kunden, machen einige Konfigurationsentscheidungen einen erheblichen Unterschied:

1. Keinen offenen Resolver betreiben. Beschränken Sie die Rekursion auf Ihre eigenen Netze. Offene Resolver werden für Amplification-Angriffe missbraucht und sind ein leichtes Ziel.
2. Autoritative und rekursive Rolle trennen. Ein Server, der für Ihre Zonen antwortet, sollte nicht zugleich Rekursion für das Internet anbieten.
3. DNSSEC-Validierung aktivieren und den Root-Trust-Anchor automatisch aktuell halten.
4. Software aktuell halten. Resolver-Projekte veröffentlichen regelmäßig Fixes für Cache-bezogene Schwachstellen.
5. Cache-TTLs begrenzen auf sinnvolle Höchstwerte und Schutz gegen unerwünschte Antworten aktivieren.

Ein minimales Beispiel für den Resolver Unbound könnte so aussehen:

server:
    interface: 10.0.0.53
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-referral-path: yes
    use-caps-for-id: yes
    qname-minimisation: yes
    unwanted-reply-threshold: 10000000
    cache-max-ttl: 86400

Das Pendant in BIND beschränkt die Rekursion über eine Access Control List und aktiviert die Validierung:

acl internal { 10.0.0.0/8; 127.0.0.1; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query-cache { internal; };
    dnssec-validation auto;
};

Testen Sie Änderungen immer zuerst in einer Staging-Umgebung, denn strenge Härtungsoptionen können fehlkonfigurierte Zonen Dritter sichtbar machen.

Monitoring und Prüfungen für Domaininhaber

Die meisten Organisationen betreiben keine öffentlichen Resolver, besitzen aber Domains, deren Antworten zum Ziel werden können. Eine praktische Routine umfasst:

• Prüfen, dass sich Nameserver und Registrar-Daten nicht unerwartet geändert haben. Ein kurzer Lookup mit dem WHOIS- und RDAP-Tool von TLDix zeigt die aktuellen Nameserver, Statuscodes und das DNSSEC-Flag einer Domain.
• Signaturen mit dig +dnssec example.com A verifizieren und bestätigen, dass ein validierender Resolver das ad-Flag zurückgibt.
• Registrar-Lock und Zwei-Faktor-Authentifizierung aktivieren, denn wer ein Registrar-Konto kapert, erreicht dasselbe wie per Poisoning – mit weit weniger Aufwand.
• Domains, SSL-Zertifikate und DNS-Hosting nicht auslaufen lassen. Eine abgelaufene Domain kann jemand anderes neu registrieren, was faktisch einem dauerhaften Spoof gleichkommt. Wer Verlängerungstermine in seinem TLDix-Domainpanel verfolgt, beseitigt dieses Risiko.

Alles zusammengeführt

Cache Poisoning nutzt aus, dass klassisches DNS der ersten plausiblen Antwort vertraute. Zufällige Ports, Transaktions-IDs und 0x20-Kodierung machen das Raten teuer; Resolver-Härtung beseitigt bequeme Abkürzungen; verschlüsselte Transporte schützen die Verbindung zum Client; und DNSSEC erlaubt es Resolvern endlich, die Echtheit von Daten zu überprüfen. Keine einzelne Maßnahme reicht aus, doch zusammen machen sie DNS dramatisch sicherer. Für Domaininhaber ist die Kurzliste klar: Zonen signieren, Registrar-Konto schützen, Records überwachen und kritische Namen niemals auslaufen lassen.