DNS-Spoofing und Cache-Poisoning: Ein praktischer Überblick

DNS wurde ursprünglich ohne jede Möglichkeit entworfen zu überprüfen, ob eine Antwort tatsächlich von dem Nameserver stammt, von dem sie angeblich kommt. Diese Lücke ermöglicht Spoofing: Ein Angreifer, der sich so positioniert, dass er eine DNS-Abfrage abfangen oder überholen kann, schickt eine gefälschte Antwort zurück, die das Opfer auf eine Adresse seiner Wahl lenkt – oft, um Traffic auf einen bösartigen Server umzuleiten, der eine legitime Website imitiert.

Cache-Poisoning: dieselbe Idee im großen Maßstab

Cache-Poisoning überträgt die Idee der gefälschten Antwort auf einen gemeinsam genutzten Resolver statt auf ein einzelnes Opfer. Gelingt es einem Angreifer, eine gefälschte Antwort in den Cache eines weit verbreiteten rekursiven Resolvers einzuschleusen, erhält jeder weitere Nutzer dieses Resolvers die vergiftete Antwort, bis sie abläuft – aus einer einzigen erfolgreichen Fälschung wird so ein Angriff auf alle, die sich zufällig denselben Resolver teilen, ohne dass die einzelnen Abfragen abgefangen werden müssten.

Wie sich modernes DNS dagegen schützt

Keine dieser Schutzmaßnahmen ist überall im Einsatz – insbesondere die DNSSEC-Verbreitung bleibt bei den Domains, aus denen das Internet besteht, lückenhaft. Einen gut betriebenen, sicherheitsbewussten öffentlichen Resolver zu nutzen und ein unerwartetes oder verdächtiges Auflösungsergebnis bei einem zweiten, unabhängigen Resolver gegenzuprüfen, bleibt eine vernünftige praktische Vorsichtsmaßnahme, auch wo DNSSEC keine Rolle spielt.

Der Fehler, der den Umgang mit dem Thema veränderte

Cache-Poisoning war kein theoretisches Problem mehr, seit der Sicherheitsforscher Dan Kaminsky 2008 einen grundlegenden Fehler offenlegte, der nahezu jeden damals eingesetzten DNS-Resolver betraf: Der Raum möglicher Transaktions-IDs und Quellports, den ein Angreifer erraten musste, war klein genug, um ihn über eine schnelle Verbindung in Sekunden per Brute Force zu durchsuchen – und so den Cache eines Resolvers für eine ganze Domain zu vergiften, nicht nur für einen einzelnen Record. Die Offenlegung führte zu einer ungewöhnlich koordinierten, gleichzeitigen Patch-Veröffentlichung bei allen großen DNS-Software-Herstellern – die Randomisierung der Quellports wurde fast über Nacht zum Standard – und ist ein wesentlicher Grund dafür, dass die oben aufgeführten Schutzmaßnahmen in ihrer heutigen Form existieren.

Warum DNSSEC trotz zwanzig Jahre alter Lösung hinterherhinkt

DNSSEC löst das zugrunde liegende Vertrauensproblem weit vollständiger als die Port-Randomisierung allein – es ist ein kryptografischer Beweis, nicht bloß ein schwierigeres Ratespiel. Die schleppende Einführung hat mehr mit betrieblicher Komplexität zu tun als mit Zweifeln an seinem Wert: Eine Zone korrekt zu signieren, Schlüssel planmäßig zu rotieren, ohne die Validierung zu brechen, und die gesamte Vertrauenskette von der Root bis zu einer bestimmten Domain intakt zu halten, ist spürbar schwerer richtig zu machen als das Hinzufügen eines unsignierten A-Records. Ein einziger Fehler in diesem Prozess erzeugt genau jenen SERVFAIL-Fehlermodus, der an anderer Stelle dieser Reihe behandelt wird, und das schreckt kleinere Domain-Betreiber ohne eigene DNS-Expertise zusätzlich ab. Die Lücke zwischen „theoretisch gelöst“ und „praktisch überall im Einsatz“ ist in der Sicherheitsinfrastruktur verbreitet, und DNSSEC ist ein deutliches Beispiel dafür.