DNS-Spoofing: Wenn der „Wegweiser“ des Internets manipuliert wird

Autor: DerSchneider

Einleitung

Stellen Sie sich vor, Sie tippen in Ihren Browser meinebank.de ein – und landen auf einer perfekt nachgebauten Seite, die Ihre Zugangsdaten abgreift. Nichts an der URL verrät den Betrug. Genau das ist die Wirkung von DNS-Spoofing: Ein Angreifer manipuliert die Namensauflösung des Internets und leitet Nutzer unbemerkt auf falsche Ziele um.

Das Domain Name System (DNS) ist die zentrale Vermittlungsschicht zwischen menschenlesbaren Domainnamen und maschinenlesbaren IP-Adressen. Es wurde in den 1980er Jahren für ein offenes, vertrauensvolles Forschungsnetzwerk entworfen – nicht für ein Umfeld, in dem Kriminalität, Spionage und Sabotage alltäglich sind. Diese historische Altlast ist der Nährboden für DNS-Spoofing.

Dieser Artikel erklärt, wie DNS-Spoofing technisch funktioniert, welche Varianten es gibt, wie man es erkennt und mit welchen Mitteln man sich schützt. Dabei werden auch die Grenzen der Schutzmaßnahmen und offene Kontroversen benannt.

1. Grundlagen: Wie DNS funktioniert – und wo es verwundbar ist

1.1 Die Architektur des DNS

DNS ist ein hierarchisches, verteiltes System. Eine typische Auflösung durchläuft mehrere Stationen:

1. Stub-Resolver auf dem Endgerät (im Betriebssystem oder Browser)
2. Rekursiver Resolver (z. B. der DNS-Server des Providers oder öffentliche Dienste wie 8.8.8.8, 1.1.1.1)
3. Root-Nameserver → TLD-Nameserver → autoritativer Nameserver der Zielzone

Der rekursive Resolver übernimmt die eigentliche Arbeit: Er fragt bei den zuständigen Servern nach, sammelt die Antwort und cacht sie für die Dauer der Time to Live (TTL). Die TTL bestimmt, wie lange ein Datensatz gültig bleibt – ein zentraler Faktor beim Cache-Poisoning.

Die Kommunikation zwischen Stub-Resolver und rekursivem Resolver erfolgt traditionell über UDP auf Port 53 – unverschlüsselt und ohne gegenseitige Authentifizierung. Zwischen den Resolvern wird ebenfalls klassisch UDP verwendet, ergänzt durch TCP für größere Antworten (z. B. bei DNSSEC).

1.2 Die entscheidende Schwachstelle

Ein Resolver muss die Antwort, die er erhält, einem zuvor gestellten Query zuordnen. Klassisches DNS verlässt sich dabei im Wesentlichen auf:

• die Quell-IP-Adresse des antwortenden Servers
• die 16-Bit-Query-ID (Transaktions-ID, 65.536 Möglichkeiten)
• den UDP-Zielport des Resolvers (bei modernen Resolvern randomisiert)

Sind diese Werte erratbar oder abfangbar, kann ein Angreifer eine gefälschte Antwort einschleusen – vorausgesetzt, sie trifft schneller ein als die echte.

2. Begriffe sauber trennen: Spoofing, Cache-Poisoning, Hijacking

Die Begriffe werden häufig synonym verwendet, meinen aber Unterschiedliches:

DNS-Spoofing ist häufig die Methode, Cache-Poisoning das Ergebnis und Hijacking eine mögliche Folge.

3. Angriffsvarianten im Detail

3.1 On-Path (Man-in-the-Middle) Spoofing

Der Angreifer befindet sich im Datenpfad zwischen Client und Resolver – etwa in einem offenen WLAN, in einem kompromittierten Router oder in einem gespiegelten Netzsegment. Er kann:

• die Anfrage abfangen und sofort eine gefälschte Antwort senden
• die echte Antwort verwerfen
• die Query-ID direkt aus der beobachteten Anfrage übernehmen

Diese Variante ist besonders effektiv, weil die Query-ID nicht erraten werden muss.

Praxisbeispiel: In einem lokalen Netzwerk kombiniert ein Angreifer ARP-Spoofing (er gibt sich als Gateway aus) mit DNS-Spoofing. Werkzeuge wie bettercap, ettercap oder dnsspoof automatisieren das. Der Angreifer beantwortet alle DNS-Anfragen mit seiner eigenen IP-Adresse.

3.2 Off-Path Spoofing (Blind Spoofing)

Hier sitzt der Angreifer nicht im Datenpfad. Er muss:

• die Query-ID erraten
• den UDP-Quellport des Resolvers erraten
• die Antwort schneller liefern als der echte Server

Die Erfolgswahrscheinlichkeit steigt mit der Anzahl paralleler Anfragen. Historisch berühmt ist die Kaminsky-Attacke von 2008: Dan Kaminsky entdeckte, dass ein Angreifer durch geschickte Wahl von Subdomains den Resolver dazu bringen kann, viele parallele Anfragen für dieselbe Zone zu stellen – und so die Chancen auf ein erfolgreiches Raten massiv erhöht. Die eigentliche Schwachstelle (Query-ID-Raten) war bereits vor 2008 bekannt; Kaminsky machte sie dramatisch ausnutzbar.

3.3 DNS-Cache-Poisoning

Gelingt es dem Angreifer, eine gefälschte Antwort in den Cache eines Resolvers zu bekommen, wird diese Antwort für alle Clients dieses Resolvers verwendet – bis die TTL abläuft. Die Reichweite ist damit enorm. Ein besonders perfider Effekt: Der Angreifer kann zusätzliche Datensätze (z. B. für Mailserver oder andere Subdomains) einschleusen, die über die ursprüngliche Anfrage hinausgehen.

3.4 Router- und Geräte-Hijacking

Viele Heimrouter erlauben DNS-Einstellungen, die von außen oder durch Malware verändert werden können. Bekannte Beispiele:

• DNSChanger (2007–2011): Malware, die DNS-Einstellungen auf Millionen von Rechnern änderte und Werbeeinnahmen umleitete. 2012 wurden die betroffenen Server abgeschaltet.
• Router-Schwachstellen: Zahlreiche Modelle erlaubten unauthentifizierte Änderungen der DNS-Konfiguration über das WAN-Interface.

3.5 DNS-Rebinding

Beim DNS-Rebinding nutzt der Angreifer die Tatsache, dass Browser und viele Anwendungen DNS-Antworten cachen, aber der Angreifer die TTL kurz halten kann. Er löst eine Domain zunächst auf eine harmlose IP auf, später auf eine interne IP (z. B. 192.168.0.1). So kann eine Webseite auf lokale Ressourcen zugreifen – ein erhebliches Risiko für IoT-Geräte und Heimnetzwerke.

3.6 NXDOMAIN- und Phantom-Domain-Angriffe

• NXDOMAIN-Angriff: Der Angreifer antwortet auf alle Anfragen mit „Domain existiert nicht“. Nutzer werden blockiert, Dienste fallen aus.
• Phantom-Domain-Angriff: Der Angreifer erzeugt massenhaft Anfragen für nicht existierende Subdomains, um Resolver zu überlasten (Denial of Service).

3.7 DoH und DoT: Segen und neue Risiken

DNS over HTTPS (DoH) und DNS over TLS (DoT) verschlüsseln die DNS-Kommunikation und erschweren klassisches On-Path-Spoofing erheblich. Allerdings:

• Der Resolver muss weiterhin vertrauenswürdig sein.
• Unternehmensnetzwerke verlieren teilweise die Sichtbarkeit.
• Es entstehen neue Zensur- und Umgehungsdebatten.
• Die Konzentration auf wenige große DoH-Anbieter schafft neue Abhängigkeiten.

4. Erkennung: Wie erkennt man DNS-Spoofing?

4.1 Technische Indikatoren

4.2 Werkzeuge und Verfahren

• DNSSEC-Validierung: Der stärkste technische Indikator. Scheitert die Validierung, ist etwas faul.
• Passives DNS-Monitoring: Dienste wie Farsight, VirusTotal oder eigene Sensoren erfassen Antworten und erkennen Abweichungen.
• Netzwerk-Monitoring: IDS/IPS-Systeme wie Suricata oder Zeek erkennen verdächtige DNS-Muster.
• Endpunkt-Tools: dig, nslookup, dnscrypt-proxy mit Validierung oder dnssec-trigger.
• Vergleich mehrerer Resolver: Lösen verschiedene Resolver unterschiedlich auf, ist Vorsicht geboten.

4.3 Verhaltensbasierte Erkennung

• Plötzliche Umleitung von Finanz- oder E-Mail-Domains
• Unerwartete Zertifikatswarnungen im Browser
• Login-Seiten, die anders aussehen als gewohnt
• Ungewöhnliche Netzwerkverbindungen zu unbekannten IPs

5. Gegenmaßnahmen

5.1 Auf DNS-Ebene

Erklärung 0x20-Encoding: Der Resolver schreibt den Domainnamen in der Anfrage mit zufälliger Groß-/Kleinschreibung (z. B. bEiSpIeL.dE). Der echte Server muss die Schreibweise exakt übernehmen. Ein Angreifer, der die Anfrage nicht sieht, kann das nicht vorhersagen.

5.2 Auf Netzwerkebene

• Port-Security und DHCP-Snooping in Switches
• Dynamic ARP Inspection (DAI) gegen ARP-Spoofing
• Firewall-Regeln, die DNS nur zu autorisierten Resolvern erlauben
• 802.1X zur Zugangskontrolle
• VLAN-Segmentierung

5.3 Auf Endgeräte-Ebene

• Feste, vertrauenswürdige DNS-Resolver eintragen
• Router-Passwörter ändern, Firmware aktualisieren
• DNSSEC-fähige Resolver nutzen (z. B. Cloudflare 1.1.1.1, Quad9 9.9.9.9)
• Browser mit Secure DNS und HSTS konfigurieren
• Zertifikatswarnungen niemals ignorieren

5.4 Organisatorisch und betrieblich

• Monitoring und Logging von DNS-Antworten
• Threat Intelligence zu bekannten bösartigen Domains
• Notfallpläne für DNS-Kompromittierungen
• Schulung von Mitarbeitern zu Phishing und verdächtigen Weiterleitungen
• Regelmäßige Audits der DNS-Infrastruktur

5.5 DNSSEC: Der wichtigste Baustein – und seine Grenzen

DNSSEC signiert DNS-Datensätze kryptografisch. Ein Resolver kann damit prüfen, ob eine Antwort authentisch ist. Die Vertrauenskette verläuft von der Root-Zone über die TLD bis zur autoritativen Zone.

Grenzen:

• DNSSEC schützt nicht die Vertraulichkeit.
• Es schützt nicht gegen Angriffe auf den autoritativen Server selbst.
• Die Deployment-Rate ist trotz jahrelanger Bemühungen begrenzt.
• Komplexität und Schlüsselverwaltung sind Hürden.
• RFC 7129 (2014) dokumentiert zahlreiche operative Risiken.

6. Fallstudien

6.1 MyEtherWallet (2018)

Angreifer hijackten den DNS-Eintrag von myetherwallet.com über einen kompromittierten DNS-Anbieter. Nutzer, die die Seite aufriefen, wurden auf eine Phishing-Seite umgeleitet, die private Schlüssel abgriff. Innerhalb von etwa zwei Stunden wurden rund 150.000 US-Dollar in Ether gestohlen. Der Fall zeigt: Selbst große Dienste sind verwundbar, wenn ihre DNS-Infrastruktur kompromittiert wird.

6.2 Twitter (2013)

Die Twitter-Domain twitter.com wurde kurzzeitig auf eine Server-Infrastruktur des syrischen Staates umgeleitet. Die Syrian Electronic Army bekannte sich zu dem Angriff. Nutzer sahen gefälschte Inhalte; die eigentliche Gefahr lag in der möglichen Manipulation von Zugangsdaten.

6.3 SeaTurtle (2019)

Die SeaTurtle-Kampagne zielte auf staatliche und private Organisationen im Nahen Osten und Nordafrika. Angreifer kompromittierten DNS-Registrare und änderten NS-Einträge, um den Datenverkehr über eigene Server zu leiten. Der Angriff dauerte Monate und blieb lange unentdeckt.

6.4 DNSChanger (2007–2011)

DNSChanger war eine Malware-Familie, die DNS-Einstellungen auf Millionen von Rechnern änderte. Betroffene Nutzer wurden auf Werbeseiten umgeleitet. 2011 zerschlug das FBI die Infrastruktur; 2012 wurden die Ersatzserver abgeschaltet. Der Fall zeigt die Verbindung von Malware und DNS-Manipulation.

7. Rechtliche Einordnung (Deutschland/EU)

DNS-Spoofing kann je nach Handlung mehrere Straftatbestände erfüllen:

• § 303a StGB (Datenveränderung): Unbefugtes Verändern von Daten.
• § 202b StGB (Abfangen von Daten): Abfangen nichtöffentlicher Datenübertragungen.
• § 263a StGB (Computerbetrug): Vermögensschaden durch Manipulation von Datenverarbeitungsvorgängen.
• § 269 StGB (Fälschung beweiserheblicher Daten): Bei gefälschten Datensätzen.

Auf EU-Ebene relevant: DSGVO (bei personenbezogenen Daten), NIS-2-Richtlinie (für kritische Infrastrukturen) und die Cybercrime-Konvention des Europarats (Budapest-Konvention).

8. Forensik: Nachbereitung eines Vorfalls

• DNS-Logs sichern: Abfragen und Antworten mit Zeitstempeln.
• Cache-Inspektion: Welche Datensätze waren zu welchem Zeitpunkt im Cache?
• Netzwerk-Mitschnitte: PCAP-Dateien für die Analyse der Kommunikation.
• Resolver-Konfiguration prüfen: Wurden Einstellungen verändert?
• Threat-Intelligence-Abgleich: Sind die Ziel-IPs bekannt?
• Zeitliche Korrelation: Wann trat die Abweichung erstmals auf?

9. Historische Entwicklung und aktuelle Kontroversen

• 1983: Erste DNS-Spezifikation (RFC 882/883).
• 1987: RFC 1034/1035 – bis heute gültige Grundlage.
• 1990er: Erste DNS-Spoofing-Angriffe in akademischen Netzwerken.
• 2008: Kaminsky-Attacke – löst weltweite Patch-Welle aus.
• 2010er: DNSChanger, Router-Hijacking, Aufstieg von DoH/DoT.
• 2018: MyEtherWallet-Angriff.
• 2019: SeaTurtle-Kampagne.
• 2020er: Zunahme von DNS-basierten Angriffen auf Lieferketten und Cloud-Infrastrukturen.

Aktuelle Kontroversen:

• DoH vs. Unternehmenskontrolle: Verschlüsselung schützt Nutzer, erschwert aber Netzwerkadministration.
• Zentralisierung: Wenige große DoH-Anbieter könnten zu neuen Abhängigkeiten führen.
• DNSSEC-Pflicht: Einige Regierungen diskutieren verpflichtende Einführung, andere sehen darin Überregulierung.
• DNS als Zensurinstrument: Gleichzeitig Werkzeug für Freiheit und für Kontrolle.
• Kritik an DNSSEC: Zu komplex, zu langsam in der Verbreitung, kein Schutz der Vertraulichkeit.

10. Was kann ein normaler Nutzer realistisch tun?

Ehrliche Einschränkung: Ein normaler Nutzer kann DNS-Spoofing nicht vollständig verhindern. Er kann das Risiko aber deutlich senken – insbesondere durch verschlüsselte DNS-Auflösung und vertrauenswürdige Resolver.

11. Fazit und Ausblick

DNS-Spoofing ist kein Relikt vergangener Tage, sondern eine lebendige Bedrohung. Die Grundursache – fehlende Authentifizierung im DNS – ist bekannt, aber nicht vollständig behoben. DNSSEC, DoH/DoT und bessere Netzwerksicherheit haben die Angriffsfläche verkleinert, aber nicht beseitigt.

Die Zukunft wird von drei Entwicklungen geprägt sein:

1. Verschlüsselung wird zum Standard – aber Vertrauen verlagert sich auf wenige Resolver.
2. Automatisierte Erkennung durch KI und Threat Intelligence wird wichtiger.
3. Regulierung wird versuchen, Sicherheit und Freiheit auszubalancieren.

Wer DNS versteht, versteht einen Großteil der Internet-Sicherheit. Wer DNS schützt, schützt die Grundlage des Vertrauens im Netz.

Glossar

Quellen

• Mockapetris, P. (1987): RFC 1034 – Domain Names: Concepts and Facilities. IETF.
• Mockapetris, P. (1987): RFC 1035 – Domain Names: Implementation and Specification. IETF.
• Kaminsky, D. (2008): Black Ops 2008: It’s the End of the Cache As We Know It. Black Hat USA.
• Arends, R. et al. (2005): RFC 4033 – DNS Security Introduction and Requirements. IETF.
• Hoffman, P., McManus, P. (2018): RFC 8484 – DNS Queries over HTTPS (DoH). IETF.
• Hu, Z. et al. (2016): RFC 7858 – Specification for DNS over Transport Layer Security (TLS). IETF.
• Rose, S., Nakibly, G. (2014): RFC 7129 – Authenticated Denial of Existence in the DNS. IETF.
• NIST (2020): Secure Domain Name System (DNS) Deployment Guide. NIST SP 800-81 Rev. 2.
• ENISA (2019): DNS Security – Threat Landscape. European Union Agency for Cybersecurity.
• Cisco (2023): DNS Security Best Practices. Cisco Systems.
• Cloudflare (2023): What is DNS Spoofing? Cloudflare Learning Center.
• BSI (2022): DNS-Sicherheit – Empfehlungen für Netzbetreiber und Anwender. Bundesamt für Sicherheit in der Informationstechnik.
• US-CERT (2019): SeaTurtle DNS Hijacking Campaign. Alert TA19-004A.
• FBI (2011): DNSChanger Malware – Operation Ghost Click.
• MyEtherWallet (2018): Stellungnahme zum DNS-Angriff.

Hinweis zur Quellenlage: Die genannten RFCs, NIST-, ENISA-, BSI- und US-CERT-Dokumente sind öffentlich auffindbar und verifizierbar. Die Fallstudien zu MyEtherWallet, Twitter, SeaTurtle und DNSChanger wurden in renommierten Medien (u. a. Heise, Bleeping Computer, Wired, The Register) und in offiziellen Stellungnahmen dokumentiert. Wo genaue Seitenzahlen fehlen, liegt das an der Online-Publikation der Quellen.