{"id":7677,"date":"2026-10-11T12:06:29","date_gmt":"2026-10-11T12:06:29","guid":{"rendered":"https:\/\/technodidact.de\/?p=7677"},"modified":"2026-10-11T12:06:29","modified_gmt":"2026-10-11T12:06:29","slug":"dns-spoofing-wenn-der-wegweiser-des-internets-manipuliert-wird","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/dns-spoofing-wenn-der-wegweiser-des-internets-manipuliert-wird\/","title":{"rendered":"DNS-Spoofing: Wenn der \u201eWegweiser“ des Internets manipuliert wird"},"content":{"rendered":"

Autor: DerSchneider<\/strong><\/p>\n\n\n\n

\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Stellen Sie sich vor, Sie tippen in Ihren Browser meinebank.de<\/code> ein \u2013 und landen auf einer perfekt nachgebauten Seite, die Ihre Zugangsdaten abgreift. Nichts an der URL verr\u00e4t den Betrug. Genau das ist die Wirkung von DNS-Spoofing: Ein Angreifer manipuliert die Namensaufl\u00f6sung des Internets und leitet Nutzer unbemerkt auf falsche Ziele um.<\/p>\n\n\n\n

Das Domain Name System (DNS) ist die zentrale Vermittlungsschicht zwischen menschenlesbaren Domainnamen und maschinenlesbaren IP-Adressen. Es wurde in den 1980er Jahren f\u00fcr ein offenes, vertrauensvolles Forschungsnetzwerk entworfen \u2013 nicht f\u00fcr ein Umfeld, in dem Kriminalit\u00e4t, Spionage und Sabotage allt\u00e4glich sind. Diese historische Altlast ist der N\u00e4hrboden f\u00fcr DNS-Spoofing.<\/p>\n\n\n\n

Dieser Artikel erkl\u00e4rt, wie DNS-Spoofing technisch funktioniert, welche Varianten es gibt, wie man es erkennt und mit welchen Mitteln man sich sch\u00fctzt. Dabei werden auch die Grenzen der Schutzma\u00dfnahmen und offene Kontroversen benannt.<\/p>\n\n\n\n

\n\n\n\n

1. Grundlagen: Wie DNS funktioniert \u2013 und wo es verwundbar ist<\/h2>\n\n\n\n

1.1 Die Architektur des DNS<\/h3>\n\n\n\n

DNS ist ein hierarchisches, verteiltes System. Eine typische Aufl\u00f6sung durchl\u00e4uft mehrere Stationen:<\/p>\n\n\n\n

    \n
  1. Stub-Resolver<\/strong> auf dem Endger\u00e4t (im Betriebssystem oder Browser)<\/li>\n\n\n\n
  2. Rekursiver Resolver<\/strong> (z. B. der DNS-Server des Providers oder \u00f6ffentliche Dienste wie 8.8.8.8, 1.1.1.1)<\/li>\n\n\n\n
  3. Root-Nameserver<\/strong> \u2192 TLD-Nameserver<\/strong> \u2192 autoritativer Nameserver<\/strong> der Zielzone<\/li>\n<\/ol>\n\n\n\n

    Der rekursive Resolver \u00fcbernimmt die eigentliche Arbeit: Er fragt bei den zust\u00e4ndigen Servern nach, sammelt die Antwort und cacht<\/strong> sie f\u00fcr die Dauer der Time to Live (TTL)<\/strong>. Die TTL bestimmt, wie lange ein Datensatz g\u00fcltig bleibt \u2013 ein zentraler Faktor beim Cache-Poisoning.<\/p>\n\n\n\n

    Die Kommunikation zwischen Stub-Resolver und rekursivem Resolver erfolgt traditionell \u00fcber UDP auf Port 53<\/strong> \u2013 unverschl\u00fcsselt und ohne gegenseitige Authentifizierung. Zwischen den Resolvern wird ebenfalls klassisch UDP verwendet, erg\u00e4nzt durch TCP f\u00fcr gr\u00f6\u00dfere Antworten (z. B. bei DNSSEC).<\/p>\n\n\n\n

    1.2 Die entscheidende Schwachstelle<\/h3>\n\n\n\n

    Ein Resolver muss die Antwort, die er erh\u00e4lt, einem zuvor gestellten Query zuordnen. Klassisches DNS verl\u00e4sst sich dabei im Wesentlichen auf:<\/p>\n\n\n\n

      \n
    • die Quell-IP-Adresse<\/strong> des antwortenden Servers<\/li>\n\n\n\n
    • die 16-Bit-Query-ID<\/strong> (Transaktions-ID, 65.536 M\u00f6glichkeiten)<\/li>\n\n\n\n
    • den UDP-Zielport<\/strong> des Resolvers (bei modernen Resolvern randomisiert)<\/li>\n<\/ul>\n\n\n\n

      Sind diese Werte erratbar oder abfangbar, kann ein Angreifer eine gef\u00e4lschte Antwort einschleusen \u2013 vorausgesetzt, sie trifft schneller<\/strong> ein als die echte.<\/p>\n\n\n\n

      \n\n\n\n

      2. Begriffe sauber trennen: Spoofing, Cache-Poisoning, Hijacking<\/h2>\n\n\n\n

      Die Begriffe werden h\u00e4ufig synonym verwendet, meinen aber Unterschiedliches:<\/p>\n\n\n\n

      Begriff<\/th>Angriffspunkt<\/th>Methode<\/th>Typische Dauer<\/th><\/tr><\/thead>
      DNS-Spoofing<\/strong><\/td>Netzwerkebene \/ Transaktion<\/td>Gef\u00e4lschte Antworten, Race Condition<\/td>Kurzzeitig, pro Query<\/td><\/tr>
      DNS-Cache-Poisoning<\/strong><\/td>Cache des Resolvers<\/td>Einschleusen falscher Datens\u00e4tze<\/td>Bis zum Ablauf der TTL<\/td><\/tr>
      DNS-Hijacking<\/strong><\/td>Autoritative Daten \/ Konfiguration<\/td>Kompromittierung von Registrar, Router oder Hosts<\/td>Langanhaltend<\/td><\/tr>
      DNS-Rebinding<\/strong><\/td>Browser \/ lokales Netz<\/td>Wechsel der Antwort-IP w\u00e4hrend einer Session<\/td>W\u00e4hrend der Session<\/td><\/tr>
      DNS-Tunneling<\/strong><\/td>Datenkanal<\/td>Ausnutzung von DNS als Transportweg<\/td>Dauerhaft, oft unentdeckt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      DNS-Spoofing ist h\u00e4ufig die Methode<\/strong>, Cache-Poisoning das Ergebnis<\/strong> und Hijacking eine m\u00f6gliche Folge<\/strong>.<\/p>\n\n\n\n

      \n\n\n\n

      3. Angriffsvarianten im Detail<\/h2>\n\n\n\n

      3.1 On-Path (Man-in-the-Middle) Spoofing<\/h3>\n\n\n\n

      Der Angreifer befindet sich im Datenpfad zwischen Client und Resolver \u2013 etwa in einem offenen WLAN, in einem kompromittierten Router oder in einem gespiegelten Netzsegment. Er kann:<\/p>\n\n\n\n

        \n
      • die Anfrage abfangen und sofort<\/strong> eine gef\u00e4lschte Antwort senden<\/li>\n\n\n\n
      • die echte Antwort verwerfen<\/li>\n\n\n\n
      • die Query-ID direkt aus der beobachteten Anfrage \u00fcbernehmen<\/li>\n<\/ul>\n\n\n\n

        Diese Variante ist besonders effektiv, weil die Query-ID nicht erraten werden muss.<\/p>\n\n\n\n

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

        3.2 Off-Path Spoofing (Blind Spoofing)<\/h3>\n\n\n\n

        Hier sitzt der Angreifer nicht im Datenpfad. Er muss:<\/p>\n\n\n\n

          \n
        • die Query-ID<\/strong> erraten<\/li>\n\n\n\n
        • den UDP-Quellport<\/strong> des Resolvers erraten<\/li>\n\n\n\n
        • die Antwort schneller<\/strong> liefern als der echte Server<\/li>\n<\/ul>\n\n\n\n

          Die Erfolgswahrscheinlichkeit steigt mit der Anzahl paralleler Anfragen. Historisch ber\u00fchmt ist die Kaminsky-Attacke von 2008<\/strong>: Dan Kaminsky entdeckte, dass ein Angreifer durch geschickte Wahl von Subdomains den Resolver dazu bringen kann, viele parallele Anfragen f\u00fcr dieselbe Zone zu stellen \u2013 und so die Chancen auf ein erfolgreiches Raten massiv erh\u00f6ht. Die eigentliche Schwachstelle (Query-ID-Raten) war bereits vor 2008 bekannt; Kaminsky machte sie dramatisch ausnutzbar.<\/p>\n\n\n\n

          3.3 DNS-Cache-Poisoning<\/h3>\n\n\n\n

          Gelingt es dem Angreifer, eine gef\u00e4lschte Antwort in den Cache eines Resolvers zu bekommen, wird diese Antwort f\u00fcr alle<\/strong> Clients dieses Resolvers verwendet \u2013 bis die TTL abl\u00e4uft. Die Reichweite ist damit enorm. Ein besonders perfider Effekt: Der Angreifer kann zus\u00e4tzliche Datens\u00e4tze (z. B. f\u00fcr Mailserver oder andere Subdomains) einschleusen, die \u00fcber die urspr\u00fcngliche Anfrage hinausgehen.<\/p>\n\n\n\n

          3.4 Router- und Ger\u00e4te-Hijacking<\/h3>\n\n\n\n

          Viele Heimrouter erlauben DNS-Einstellungen, die von au\u00dfen oder durch Malware ver\u00e4ndert werden k\u00f6nnen. Bekannte Beispiele:<\/p>\n\n\n\n

            \n
          • DNSChanger<\/strong> (2007\u20132011): Malware, die DNS-Einstellungen auf Millionen von Rechnern \u00e4nderte und Werbeeinnahmen umleitete. 2012 wurden die betroffenen Server abgeschaltet.<\/li>\n\n\n\n
          • Router-Schwachstellen<\/strong>: Zahlreiche Modelle erlaubten unauthentifizierte \u00c4nderungen der DNS-Konfiguration \u00fcber das WAN-Interface.<\/li>\n<\/ul>\n\n\n\n

            3.5 DNS-Rebinding<\/h3>\n\n\n\n

            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\u00f6st eine Domain zun\u00e4chst auf eine harmlose IP auf, sp\u00e4ter auf eine interne IP (z. B. 192.168.0.1<\/code>). So kann eine Webseite auf lokale Ressourcen zugreifen \u2013 ein erhebliches Risiko f\u00fcr IoT-Ger\u00e4te und Heimnetzwerke.<\/p>\n\n\n\n

            3.6 NXDOMAIN- und Phantom-Domain-Angriffe<\/h3>\n\n\n\n
              \n
            • NXDOMAIN-Angriff:<\/strong> Der Angreifer antwortet auf alle Anfragen mit \u201eDomain existiert nicht“. Nutzer werden blockiert, Dienste fallen aus.<\/li>\n\n\n\n
            • Phantom-Domain-Angriff:<\/strong> Der Angreifer erzeugt massenhaft Anfragen f\u00fcr nicht existierende Subdomains, um Resolver zu \u00fcberlasten (Denial of Service).<\/li>\n<\/ul>\n\n\n\n

              3.7 DoH und DoT: Segen und neue Risiken<\/h3>\n\n\n\n

              DNS over HTTPS (DoH) und DNS over TLS (DoT) verschl\u00fcsseln die DNS-Kommunikation und erschweren klassisches On-Path-Spoofing erheblich. Allerdings:<\/p>\n\n\n\n

                \n
              • Der Resolver<\/strong> muss weiterhin vertrauensw\u00fcrdig sein.<\/li>\n\n\n\n
              • Unternehmensnetzwerke verlieren teilweise die Sichtbarkeit.<\/li>\n\n\n\n
              • Es entstehen neue Zensur- und Umgehungsdebatten<\/strong>.<\/li>\n\n\n\n
              • Die Konzentration auf wenige gro\u00dfe DoH-Anbieter schafft neue Abh\u00e4ngigkeiten.<\/li>\n<\/ul>\n\n\n\n
                \n\n\n\n

                4. Erkennung: Wie erkennt man DNS-Spoofing?<\/h2>\n\n\n\n

                4.1 Technische Indikatoren<\/h3>\n\n\n\n
                Indikator<\/th>Beschreibung<\/th>Erkennungsmethode<\/th><\/tr><\/thead>
                Ungew\u00f6hnliche IP-Adressen<\/strong><\/td>Bekannte Domain l\u00f6st pl\u00f6tzlich auf fremde IP auf<\/td>Vergleich mit Baseline, Threat Intelligence<\/td><\/tr>
                Geografische Anomalien<\/strong><\/td>Antwort-IP liegt in unerwartetem Land<\/td>GeoIP-Abgleich<\/td><\/tr>
                TTL-Anomalien<\/strong><\/td>Extrem niedrige oder hohe TTL-Werte<\/td>TTL-Monitoring<\/td><\/tr>
                Mehrfach unterschiedliche Antworten<\/strong><\/td>Gleiche Domain, verschiedene IPs in kurzer Zeit<\/td>Antwort-Historie<\/td><\/tr>
                DNSSEC-Validierungsfehler<\/strong><\/td>Signaturpr\u00fcfung schl\u00e4gt fehl<\/td>DNSSEC-Validator<\/td><\/tr>
                Asymmetrische Antwortwege<\/strong><\/td>Antwort kommt von anderer IP als erwartet<\/td>Pfadanalyse<\/td><\/tr>
                Unerwartete NXDOMAIN-Antworten<\/strong><\/td>Bekannte Domain pl\u00f6tzlich \u201enicht vorhanden“<\/td>Monitoring<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                4.2 Werkzeuge und Verfahren<\/h3>\n\n\n\n
                  \n
                • DNSSEC-Validierung:<\/strong> Der st\u00e4rkste technische Indikator. Scheitert die Validierung, ist etwas faul.<\/li>\n\n\n\n
                • Passives DNS-Monitoring:<\/strong> Dienste wie Farsight, VirusTotal oder eigene Sensoren erfassen Antworten und erkennen Abweichungen.<\/li>\n\n\n\n
                • Netzwerk-Monitoring:<\/strong> IDS\/IPS-Systeme wie Suricata oder Zeek erkennen verd\u00e4chtige DNS-Muster.<\/li>\n\n\n\n
                • Endpunkt-Tools:<\/strong> dig<\/code>, nslookup<\/code>, dnscrypt-proxy<\/code> mit Validierung oder dnssec-trigger<\/code>.<\/li>\n\n\n\n
                • Vergleich mehrerer Resolver:<\/strong> L\u00f6sen verschiedene Resolver unterschiedlich auf, ist Vorsicht geboten.<\/li>\n<\/ul>\n\n\n\n

                  4.3 Verhaltensbasierte Erkennung<\/h3>\n\n\n\n
                    \n
                  • Pl\u00f6tzliche Umleitung von Finanz- oder E-Mail-Domains<\/li>\n\n\n\n
                  • Unerwartete Zertifikatswarnungen im Browser<\/li>\n\n\n\n
                  • Login-Seiten, die anders aussehen als gewohnt<\/li>\n\n\n\n
                  • Ungew\u00f6hnliche Netzwerkverbindungen zu unbekannten IPs<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n

                    5. Gegenma\u00dfnahmen<\/h2>\n\n\n\n

                    5.1 Auf DNS-Ebene<\/h3>\n\n\n\n
                    Ma\u00dfnahme<\/th>Wirkung<\/th>Einschr\u00e4nkung<\/th><\/tr><\/thead>
                    DNSSEC<\/strong><\/td>Kryptografische Signatur der DNS-Daten<\/td>Nicht fl\u00e4chendeckend deployed, komplex<\/td><\/tr>
                    Query-ID-Randomisierung<\/strong><\/td>Erschwert Blind Spoofing<\/td>Kein Schutz gegen On-Path<\/td><\/tr>
                    Quellport-Randomisierung<\/strong><\/td>Erh\u00f6ht Entropie<\/td>Kein Schutz gegen On-Path<\/td><\/tr>
                    0x20-Encoding<\/strong><\/td>Zuf\u00e4llige Gro\u00df-\/Kleinschreibung in Query<\/td>Nur bei manchen Resolvern<\/td><\/tr>
                    DNS-over-TLS (DoT)<\/strong><\/td>Verschl\u00fcsselung zum Resolver<\/td>Resolver muss vertrauensw\u00fcrdig sein<\/td><\/tr>
                    DNS-over-HTTPS (DoH)<\/strong><\/td>Verschl\u00fcsselung, Umgehung von Port-53-Blockaden<\/td>Zentralisierung, Datenschutzfragen<\/td><\/tr>
                    DNSCrypt<\/strong><\/td>Verschl\u00fcsselung und Authentifizierung<\/td>Geringe Verbreitung<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                    Erkl\u00e4rung 0x20-Encoding:<\/strong> Der Resolver schreibt den Domainnamen in der Anfrage mit zuf\u00e4lliger Gro\u00df-\/Kleinschreibung (z. B. bEiSpIeL.dE<\/code>). Der echte Server muss die Schreibweise exakt \u00fcbernehmen. Ein Angreifer, der die Anfrage nicht sieht, kann das nicht vorhersagen.<\/p>\n\n\n\n

                    5.2 Auf Netzwerkebene<\/h3>\n\n\n\n
                      \n
                    • Port-Security und DHCP-Snooping<\/strong> in Switches<\/li>\n\n\n\n
                    • Dynamic ARP Inspection (DAI)<\/strong> gegen ARP-Spoofing<\/li>\n\n\n\n
                    • Firewall-Regeln<\/strong>, die DNS nur zu autorisierten Resolvern erlauben<\/li>\n\n\n\n
                    • 802.1X<\/strong> zur Zugangskontrolle<\/li>\n\n\n\n
                    • VLAN-Segmentierung<\/strong><\/li>\n<\/ul>\n\n\n\n

                      5.3 Auf Endger\u00e4te-Ebene<\/h3>\n\n\n\n
                        \n
                      • Feste, vertrauensw\u00fcrdige DNS-Resolver eintragen<\/li>\n\n\n\n
                      • Router-Passw\u00f6rter \u00e4ndern, Firmware aktualisieren<\/li>\n\n\n\n
                      • DNSSEC-f\u00e4hige Resolver nutzen (z. B. Cloudflare 1.1.1.1, Quad9 9.9.9.9)<\/li>\n\n\n\n
                      • Browser mit Secure DNS<\/strong> und HSTS<\/strong> konfigurieren<\/li>\n\n\n\n
                      • Zertifikatswarnungen niemals ignorieren<\/li>\n<\/ul>\n\n\n\n

                        5.4 Organisatorisch und betrieblich<\/h3>\n\n\n\n
                          \n
                        • Monitoring und Logging<\/strong> von DNS-Antworten<\/li>\n\n\n\n
                        • Threat Intelligence<\/strong> zu bekannten b\u00f6sartigen Domains<\/li>\n\n\n\n
                        • Notfallpl\u00e4ne<\/strong> f\u00fcr DNS-Kompromittierungen<\/li>\n\n\n\n
                        • Schulung<\/strong> von Mitarbeitern zu Phishing und verd\u00e4chtigen Weiterleitungen<\/li>\n\n\n\n
                        • Regelm\u00e4\u00dfige Audits<\/strong> der DNS-Infrastruktur<\/li>\n<\/ul>\n\n\n\n

                          5.5 DNSSEC: Der wichtigste Baustein \u2013 und seine Grenzen<\/h3>\n\n\n\n

                          DNSSEC signiert DNS-Datens\u00e4tze kryptografisch. Ein Resolver kann damit pr\u00fcfen, ob eine Antwort authentisch ist. Die Vertrauenskette verl\u00e4uft von der Root-Zone \u00fcber die TLD bis zur autoritativen Zone.<\/p>\n\n\n\n

                          Grenzen:<\/strong><\/p>\n\n\n\n

                            \n
                          • DNSSEC sch\u00fctzt nicht<\/strong> die Vertraulichkeit.<\/li>\n\n\n\n
                          • Es sch\u00fctzt nicht<\/strong> gegen Angriffe auf den autoritativen Server selbst.<\/li>\n\n\n\n
                          • Die Deployment-Rate<\/strong> ist trotz jahrelanger Bem\u00fchungen begrenzt.<\/li>\n\n\n\n
                          • Komplexit\u00e4t<\/strong> und Schl\u00fcsselverwaltung<\/strong> sind H\u00fcrden.<\/li>\n\n\n\n
                          • RFC 7129<\/strong> (2014) dokumentiert zahlreiche operative Risiken.<\/li>\n<\/ul>\n\n\n\n
                            \n\n\n\n

                            6. Fallstudien<\/h2>\n\n\n\n

                            6.1 MyEtherWallet (2018)<\/h3>\n\n\n\n

                            Angreifer hijackten den DNS-Eintrag von myetherwallet.com<\/code> \u00fcber einen kompromittierten DNS-Anbieter. Nutzer, die die Seite aufriefen, wurden auf eine Phishing-Seite umgeleitet, die private Schl\u00fcssel abgriff. Innerhalb von etwa zwei Stunden wurden rund 150.000 US-Dollar in Ether gestohlen. Der Fall zeigt: Selbst gro\u00dfe Dienste sind verwundbar, wenn ihre DNS-Infrastruktur kompromittiert wird.<\/p>\n\n\n\n

                            6.2 Twitter (2013)<\/h3>\n\n\n\n

                            Die Twitter-Domain twitter.com<\/code> wurde kurzzeitig auf eine Server-Infrastruktur des syrischen Staates umgeleitet. Die Syrian Electronic Army bekannte sich zu dem Angriff. Nutzer sahen gef\u00e4lschte Inhalte; die eigentliche Gefahr lag in der m\u00f6glichen Manipulation von Zugangsdaten.<\/p>\n\n\n\n

                            6.3 SeaTurtle (2019)<\/h3>\n\n\n\n

                            Die SeaTurtle-Kampagne zielte auf staatliche und private Organisationen im Nahen Osten und Nordafrika. Angreifer kompromittierten DNS-Registrare und \u00e4nderten NS-Eintr\u00e4ge, um den Datenverkehr \u00fcber eigene Server zu leiten. Der Angriff dauerte Monate und blieb lange unentdeckt.<\/p>\n\n\n\n

                            6.4 DNSChanger (2007\u20132011)<\/h3>\n\n\n\n

                            DNSChanger war eine Malware-Familie, die DNS-Einstellungen auf Millionen von Rechnern \u00e4nderte. 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.<\/p>\n\n\n\n

                            \n\n\n\n

                            7. Rechtliche Einordnung (Deutschland\/EU)<\/h2>\n\n\n\n

                            DNS-Spoofing kann je nach Handlung mehrere Straftatbest\u00e4nde erf\u00fcllen:<\/p>\n\n\n\n

                              \n
                            • \u00a7 303a StGB (Datenver\u00e4nderung):<\/strong> Unbefugtes Ver\u00e4ndern von Daten.<\/li>\n\n\n\n
                            • \u00a7 202b StGB (Abfangen von Daten):<\/strong> Abfangen nicht\u00f6ffentlicher Daten\u00fcbertragungen.<\/li>\n\n\n\n
                            • \u00a7 263a StGB (Computerbetrug):<\/strong> Verm\u00f6gensschaden durch Manipulation von Datenverarbeitungsvorg\u00e4ngen.<\/li>\n\n\n\n
                            • \u00a7 269 StGB (F\u00e4lschung beweiserheblicher Daten):<\/strong> Bei gef\u00e4lschten Datens\u00e4tzen.<\/li>\n<\/ul>\n\n\n\n

                              Auf EU-Ebene relevant: DSGVO<\/strong> (bei personenbezogenen Daten), NIS-2-Richtlinie<\/strong> (f\u00fcr kritische Infrastrukturen) und die Cybercrime-Konvention des Europarats<\/strong> (Budapest-Konvention).<\/p>\n\n\n\n

                              \n\n\n\n

                              8. Forensik: Nachbereitung eines Vorfalls<\/h2>\n\n\n\n
                                \n
                              • DNS-Logs sichern:<\/strong> Abfragen und Antworten mit Zeitstempeln.<\/li>\n\n\n\n
                              • Cache-Inspektion:<\/strong> Welche Datens\u00e4tze waren zu welchem Zeitpunkt im Cache?<\/li>\n\n\n\n
                              • Netzwerk-Mitschnitte:<\/strong> PCAP-Dateien f\u00fcr die Analyse der Kommunikation.<\/li>\n\n\n\n
                              • Resolver-Konfiguration pr\u00fcfen:<\/strong> Wurden Einstellungen ver\u00e4ndert?<\/li>\n\n\n\n
                              • Threat-Intelligence-Abgleich:<\/strong> Sind die Ziel-IPs bekannt?<\/li>\n\n\n\n
                              • Zeitliche Korrelation:<\/strong> Wann trat die Abweichung erstmals auf?<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n

                                9. Historische Entwicklung und aktuelle Kontroversen<\/h2>\n\n\n\n
                                  \n
                                • 1983:<\/strong> Erste DNS-Spezifikation (RFC 882\/883).<\/li>\n\n\n\n
                                • 1987:<\/strong> RFC 1034\/1035 \u2013 bis heute g\u00fcltige Grundlage.<\/li>\n\n\n\n
                                • 1990er:<\/strong> Erste DNS-Spoofing-Angriffe in akademischen Netzwerken.<\/li>\n\n\n\n
                                • 2008:<\/strong> Kaminsky-Attacke \u2013 l\u00f6st weltweite Patch-Welle aus.<\/li>\n\n\n\n
                                • 2010er:<\/strong> DNSChanger, Router-Hijacking, Aufstieg von DoH\/DoT.<\/li>\n\n\n\n
                                • 2018:<\/strong> MyEtherWallet-Angriff.<\/li>\n\n\n\n
                                • 2019:<\/strong> SeaTurtle-Kampagne.<\/li>\n\n\n\n
                                • 2020er:<\/strong> Zunahme von DNS-basierten Angriffen auf Lieferketten und Cloud-Infrastrukturen.<\/li>\n<\/ul>\n\n\n\n

                                  Aktuelle Kontroversen:<\/strong><\/p>\n\n\n\n

                                    \n
                                  • DoH vs. Unternehmenskontrolle:<\/strong> Verschl\u00fcsselung sch\u00fctzt Nutzer, erschwert aber Netzwerkadministration.<\/li>\n\n\n\n
                                  • Zentralisierung:<\/strong> Wenige gro\u00dfe DoH-Anbieter k\u00f6nnten zu neuen Abh\u00e4ngigkeiten f\u00fchren.<\/li>\n\n\n\n
                                  • DNSSEC-Pflicht:<\/strong> Einige Regierungen diskutieren verpflichtende Einf\u00fchrung, andere sehen darin \u00dcberregulierung.<\/li>\n\n\n\n
                                  • DNS als Zensurinstrument:<\/strong> Gleichzeitig Werkzeug f\u00fcr Freiheit und f\u00fcr Kontrolle.<\/li>\n\n\n\n
                                  • Kritik an DNSSEC:<\/strong> Zu komplex, zu langsam in der Verbreitung, kein Schutz der Vertraulichkeit.<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n

                                    10. Was kann ein normaler Nutzer realistisch tun?<\/h2>\n\n\n\n
                                    Ma\u00dfnahme<\/th>Aufwand<\/th>Wirkung<\/th><\/tr><\/thead>
                                    Vertrauensw\u00fcrdigen DNS-Resolver eintragen<\/td>Gering<\/td>Hoch<\/td><\/tr>
                                    Router-Passwort \u00e4ndern, Firmware aktualisieren<\/td>Gering<\/td>Hoch<\/td><\/tr>
                                    DoH\/DoT im Browser aktivieren<\/td>Gering<\/td>Mittel bis hoch<\/td><\/tr>
                                    DNSSEC-f\u00e4higen Resolver nutzen<\/td>Gering<\/td>Mittel<\/td><\/tr>
                                    Zertifikatswarnungen ernst nehmen<\/td>Gering<\/td>Hoch<\/td><\/tr>
                                    \u00d6ffentliche WLANs meiden oder VPN nutzen<\/td>Mittel<\/td>Hoch<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

                                    Ehrliche Einschr\u00e4nkung:<\/strong> Ein normaler Nutzer kann DNS-Spoofing nicht vollst\u00e4ndig verhindern. Er kann das Risiko aber deutlich senken \u2013 insbesondere durch verschl\u00fcsselte DNS-Aufl\u00f6sung und vertrauensw\u00fcrdige Resolver.<\/p>\n\n\n\n

                                    \n\n\n\n

                                    11. Fazit und Ausblick<\/h2>\n\n\n\n

                                    DNS-Spoofing ist kein Relikt vergangener Tage, sondern eine lebendige Bedrohung. Die Grundursache \u2013 fehlende Authentifizierung im DNS \u2013 ist bekannt, aber nicht vollst\u00e4ndig behoben. DNSSEC, DoH\/DoT und bessere Netzwerksicherheit haben die Angriffsfl\u00e4che verkleinert, aber nicht beseitigt.<\/p>\n\n\n\n

                                    Die Zukunft wird von drei Entwicklungen gepr\u00e4gt sein:<\/p>\n\n\n\n

                                      \n
                                    1. Verschl\u00fcsselung<\/strong> wird zum Standard \u2013 aber Vertrauen verlagert sich auf wenige Resolver.<\/li>\n\n\n\n
                                    2. Automatisierte Erkennung<\/strong> durch KI und Threat Intelligence wird wichtiger.<\/li>\n\n\n\n
                                    3. Regulierung<\/strong> wird versuchen, Sicherheit und Freiheit auszubalancieren.<\/li>\n<\/ol>\n\n\n\n

                                      Wer DNS versteht, versteht einen Gro\u00dfteil der Internet-Sicherheit. Wer DNS sch\u00fctzt, sch\u00fctzt die Grundlage des Vertrauens im Netz.<\/p>\n\n\n\n

                                      \n\n\n\n

                                      Glossar<\/h2>\n\n\n\n
                                      Begriff<\/th>Erkl\u00e4rung<\/th><\/tr><\/thead>
                                      Stub-Resolver<\/strong><\/td>DNS-Client auf dem Endger\u00e4t<\/td><\/tr>
                                      Rekursiver Resolver<\/strong><\/td>Server, der DNS-Anfragen stellvertretend aufl\u00f6st<\/td><\/tr>
                                      Autoritativer Nameserver<\/strong><\/td>Server, der die offiziellen Daten einer Zone h\u00e4lt<\/td><\/tr>
                                      TTL<\/strong><\/td>Time to Live \u2013 G\u00fcltigkeitsdauer eines DNS-Datensatzes<\/td><\/tr>
                                      Query-ID<\/strong><\/td>16-Bit-Kennung zur Zuordnung von Anfrage und Antwort<\/td><\/tr>
                                      NXDOMAIN<\/strong><\/td>DNS-Antwort \u201eDomain existiert nicht“<\/td><\/tr>
                                      DoH\/DoT<\/strong><\/td>DNS over HTTPS \/ DNS over TLS<\/td><\/tr>
                                      DNSSEC<\/strong><\/td>Kryptografische Absicherung von DNS-Daten<\/td><\/tr>
                                      ARP-Spoofing<\/strong><\/td>Manipulation der ARP-Tabelle im lokalen Netz<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                      \n\n\n\n

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

                                        Hinweis zur Quellenlage:<\/strong> Die genannten RFCs, NIST-, ENISA-, BSI- und US-CERT-Dokumente sind \u00f6ffentlich 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.<\/p>","protected":false},"excerpt":{"rendered":"

                                        Autor: DerSchneider Einleitung Stellen Sie sich vor, Sie tippen in Ihren Browser meinebank.de ein \u2013 und landen auf einer perfekt nachgebauten Seite, die Ihre Zugangsdaten abgreift. Nichts an der URL verr\u00e4t den Betrug. Genau das ist die Wirkung von DNS-Spoofing: Ein Angreifer manipuliert die Namensaufl\u00f6sung des Internets und leitet Nutzer unbemerkt auf falsche Ziele um. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41,44,17],"tags":[8877,11291,11293,11294,11292,3468,4872],"class_list":["post-7677","post","type-post","status-publish","format-standard","hentry","category-digitalkultur","category-ethik-gewissen","category-im-herz","tag-cache-poisoning","tag-dns-hijacking","tag-dns-spoofing","tag-dnssec","tag-doh","tag-it-sicherheit","tag-netzwerksicherheit"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/7677","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=7677"}],"version-history":[{"count":1,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/7677\/revisions"}],"predecessor-version":[{"id":7678,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/7677\/revisions\/7678"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=7677"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=7677"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=7677"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}