DNS Cache Poisoning
Angriffstechnik, bei der ein Angreifer gefälschte DNS-Antworten in den Cache eines Resolvers einschleust, sodass anschließende Nutzer für eine legitime Domain auf eine vom Angreifer kontrollierte IP-Adresse umgeleitet werden.
DNS Cache Poisoning ist eine Angriffstechnik, bei der ein Angreifer gefälschte DNS-Antworten so platziert, dass sie von einem rekursiven Resolver akzeptiert und in dessen Cache aufgenommen werden. Anschließende Anfragen anderer Nutzer für dieselbe Domain werden dann aus dem vergifteten Cache mit der gefälschten IP-Adresse beantwortet — selbst wenn die ursprüngliche Anfrage des Angreifers längst vorbei ist. Die Persistenzwirkung über die TTL eines DNS-Records ist genau das, was Cache Poisoning so gefährlich macht: Ein einziger erfolgreicher Spoofing-Versuch kann hunderte oder tausende Folgenutzer auf eine vom Angreifer kontrollierte Infrastruktur umleiten.
Die historische Schwachstelle: Kaminsky-Attack
Der bekannteste Cache-Poisoning-Angriff wurde 2008 von Dan Kaminsky publik gemacht. Sein Befund: Klassische DNS-Implementierungen prüften eingehende Antworten nur über die 16-Bit-Transaction-ID, die mit der Anfrage gesendet wurde. Ein Angreifer, der Antworten an einen Resolver schicken konnte, musste lediglich die richtige Transaction-ID raten — bei 65.536 Möglichkeiten ein realistisches Szenario, insbesondere wenn der Angreifer den Resolver dazu brachte, viele parallele Anfragen für nicht-existente Subdomains derselben Zone zu stellen. Bei jeder dieser Anfragen war eine korrekte Antwort mit der gefälschten Authority-Section möglich, die den Cache für die gesamte Zone vergiftete.
Die Industrie reagierte mit Source-Port-Randomization: Resolver senden Anfragen seither von zufälligen UDP-Source-Ports statt vom festen Port 53, was den Schlüsselraum von 16 auf effektiv 32 Bit erweitert. Damit ist Kaminsky-Style-Poisoning praktisch nicht mehr realistisch — aber andere Angriffsklassen blieben.
Aktuelle Angriffsflächen
Auch nach Source-Port-Randomization gibt es mehrere Pfade, über die ein Angreifer Cache Poisoning erreichen kann.
| Vektor | Funktionsweise |
|---|---|
| BGP-Hijacking | Angreifer übernimmt das Routing zu einem autoritativen Nameserver oder Resolver und antwortet selbst |
| Off-Path-Side-Channels (z.B. SAD DNS) | Nutzt ICMP-Rate-Limit-Verhalten von Linux-Resolvern, um Source-Ports zu enumerieren |
| Kompromittierte Forwarder | Angreifer übernimmt einen vorgelagerten DNS-Server und manipuliert dort die Antworten |
| Manipulierte DHCP-Resolver-Einstellungen | Angreifer im LAN setzt sich selbst als DNS-Server für andere Clients ein |
| Schwachstellen in Resolver-Software | CVEs in BIND, Unbound, dnsmasq oder Routern führen zu Caching-Anomalien |
Die SAD-DNS-Attacke (Side channel AttackeD DNS, 2020) hat insbesondere gezeigt, dass auch nach Kaminsky neue Off-Path-Vektoren entstehen — die Annahme, das Problem sei vollständig gelöst, ist nicht haltbar.
Warum DNSSEC die strukturelle Antwort ist
DNSSEC löst Cache Poisoning auf einer fundamentaleren Ebene als jede Anti-Spoofing-Maßnahme: Statt Angreifer daran zu hindern, gefälschte Antworten einzuschleusen, macht es ihre Annahme unmöglich. Jede DNS-Antwort wird vom autoritativen Server mit einem privaten Schlüssel signiert; der validierende Resolver prüft die Signatur gegen den öffentlichen Schlüssel der Zone, der seinerseits über die DS-Records von der übergeordneten Zone und letztlich von der Root-Zone als vertrauenswürdig bestätigt wurde. Eine ohne den richtigen Schlüssel erzeugte Antwort wird verworfen — auch wenn ihre Transaction-ID korrekt ist und sie aus dem richtigen Source-Port kommt.
Voraussetzung ist allerdings, dass alle beteiligten Parteien DNSSEC korrekt einsetzen: Die TLD muss signiert sein, die Domain selbst muss signiert sein und einen DS-Record bei der TLD haben, und der Resolver muss Validierung aktiviert haben. Wenn auch nur eine dieser Komponenten fehlt, fällt der Schutz auf das Niveau klassischer DNS-Sicherheit zurück.
DoH und DoT als komplementärer Schutz
Während DNSSEC die Integrität der Antwort sichert, schützen DNS over HTTPS (DoH) und DNS over TLS (DoT) die Vertraulichkeit und Verbindungsintegrität zum Resolver. Ein Angreifer im Pfad zwischen Client und Resolver — etwa in einem öffentlichen WLAN — kann unverschlüsselte DNS-Anfragen mitlesen und mit gefälschten Antworten überholen, was insbesondere für nicht-DNSSEC-signierte Zonen ein Cache-Poisoning-Risiko auf Client-Ebene bleibt. DoH und DoT verhindern dies, indem sie den DNS-Verkehr in eine TLS-Verbindung einkapseln.
In der Praxis ergänzen sich beide Schutzschichten. DNSSEC sichert die kryptografische Authentizität der Antwortdaten; DoH/DoT sichern den Pfad zum Resolver und verhindern, dass Angreifer mitlesen oder manipulieren können. Eine vollständige Härtungsstrategie kombiniert beide.
Auswirkungen für Unternehmen
Drei Maßnahmen reduzieren das Risiko in der Praxis deutlich. Erstens DNSSEC-Aktivierung für alle eigenen Domains — bei modernen Registraren in wenigen Klicks erledigt. Zweitens die Wahl validierender Resolver (alle großen Public-DNS-Anbieter, viele aktuelle ISP-Resolver), idealerweise zusätzlich über DoT oder DoH abgesichert. Drittens regelmäßiges Patchen der eigenen DNS-Infrastruktur, falls intern Resolver oder autoritative Server betrieben werden — Schwachstellen in BIND, Unbound oder dnsmasq werden weiterhin entdeckt und müssen schnell adressiert werden.
Cache Poisoning ist kein theoretisches Risiko. In der Vergangenheit haben gezielte Angriffe auf Banken-Domains, Krypto-Exchange-Hostnamen und Webmail-Dienste reale Schäden verursacht — etwa über Phishing-Weiterleitungen, gefälschte Absender-E-Mails an Mitarbeitende oder Man-in-the-Middle-Angriffe gegen TLS-Verbindungen, deren OCSP-Responder über manipulierte DNS-Antworten erreicht wurden.
Der DNSSEC-Check prüft, ob Ihre Domain technisch korrekt gegen Cache Poisoning abgesichert ist — von den DS-Records über die DNSKEYs bis zu den RRSIG-Signaturen. Der ergänzende DNS-Lookup zeigt die aktuelle Konfiguration aller relevanten Records auf einen Blick.