DNS-Hijacking durch ISPs diagnostizieren, wenn Standard-Resolver versagen

Karthikey Hegde stellte fest, dass sein Podman-Container eine bestimmte Website nicht erreichen konnte, obwohl alle üblichen Fehlerbehebungsschritte durchgeführt wurden. Anfragen an große öffentliche Resolver wie Google und Cloudflare lieferten alle dieselbe IP-Adresse, die seinem Internetdienstanbieter (ISP) gehörte, während verschlüsseltes DNS das korrekte Ziel offenbarte. Dieser Vorfall hebt eine kritische Schwachstelle für Self-Hoster hervor: Das Ändern der DNS-Server-Einstellungen bietet oft keinen Schutz, wenn Ihr ISP den Datenverkehr auf Port 53 abfängt.

Was passiert ist

Hegdes Untersuchung begann, als ein Dienst in seiner lokalen Umgebung einen Domainnamen nicht auflösen konnte. Er testete mehrere öffentliche DNS-Resolver, darunter 1.1.1.1, 8.8.8.8 und 9.9.9.9. Überraschenderweise lieferte jede Klartextabfrage dieselbe IP-Adresse zurück, deren Zugehörigkeit zu seinem ISP durch eine WHOIS-Abfrage bestätigt wurde. Als er den DNS-over-HTTPS-(DoH)-Endpunkt von Cloudflare nutzte, erhielt die Abfrage die legitime IP-Adresse der Zielwebsite. Diese Diskrepanz bewies, dass sein ISP UDP-DNS-Pakete auf Port 53 aktiv abfing und umschrieb, unabhängig von der angegebenen Resolver-Adresse.

Dieses Verhalten macht gängige Ratschläge wirkungslos. Benutzer dazu aufzufordern, zu 1.1.1.1 oder 8.8.8.8 zu wechseln, setzt voraus, dass der ISP diese Pakete zuverlässig weiterleitet. In Wirklichkeit kann unauthentifizierter UDP-Datenverkehr auf Port 53 von jedem Netzwerkgerät entlang des Pfads abgefangen werden. Wie in technischen Diskussionen rund um den Vorfall angemerkt wurde, ist das Abfangen von UDP-DNS für Netzbetreiber trivial. Die Ausrüstung des ISPs erfasst einfach das Paket und antwortet mit einer gefälschten Antwort, sodass es so aussieht, als hätte der angeforderte Resolver falsche Daten geliefert.

Wichtige Details

• Klartext-DNS-Anfragen auf Port 53 fehlen Authentifizierungsmechanismen, was ISPs leichtes Abfangen und Umschreiben von Antworten ermöglicht.
• Wenn mehrere öffentliche Resolver dieselbe falsche IP-Adresse zurückgeben, deutet dies auf einen einzelnen Abfangpunkt hin, nicht auf unabhängige Resolver-Fehler.
• DNS over HTTPS (DoH) und DNS over TLS (DoT) verschlüsseln Anfragen und verhindern so Änderungen während der Übertragung durch Zwischenstationen im Netzwerk.
• Eine Diskrepanz zwischen Ergebnissen von Klartext- und verschlüsseltem DNS erfordert eine Überprüfung über WHOIS, um Manipulationen von CDN-basierten Geolokalisierungen zu unterscheiden.
• Stand November 2026 waren nur etwa 7,1 % der bewerteten Domains DNSSEC-signiert und gültig, was die Erkennungsreichweite einschränkt.
• Selbst gehostete rekursive Resolver wie Unbound sind ebenfalls verwundbar, wenn sie Anfragen über Klartext-UDP auf Port 53 weiterleiten.

Hintergrund

Die DNS-Auflösung verlässt sich traditionell auf UDP-Port 53, ein Protokoll, das auf Geschwindigkeit statt auf Sicherheit ausgelegt ist. Es überprüft weder die Identität des Antwortenden noch die Integrität der Daten. Wenn Sie ein Gerät so konfigurieren, dass es einen bestimmten DNS-Server verwendet, sendet Ihr Betriebssystem eine Anfrage an diese IP-Adresse. Ohne Verschlüsselung kann jedoch jeder Router oder Firewall zwischen Ihrem Gerät und dem beabsichtigten Resolver die Anfrage lesen und eine gefälschte Antwort injizieren. Dies wird als DNS-Hijacking oder Spoofing bezeichnet.

Verschlüsselte DNS-Protokolle wie DoH und DoT kapseln diese Anfragen in TLS, ähnlich wie HTTPS das Browsen im Web absichert. Dies verhindert, dass Netzbetreiber den Inhalt der Anfrage sehen oder verändern können. Die Adoption ist jedoch nicht universell. Viele selbst gehostete Umgebungen verlassen sich weiterhin aus Gründen der Einfachheit oder Kompatibilität auf Klartextweiterleitung. Darüber hinaus fügt DNSSEC eine Schicht kryptografischer Validierung hinzu, um die Datenintegrität sicherzustellen, erfordert aber sowohl, dass der Domaininhaber Datensätze signiert, als auch, dass der Resolver diese validiert. Da nur ein kleiner Bruchteil der Domains DNSSEC unterstützt, bleibt es ein unvollständiger Schutz gegen Hijacking.

Warum es wichtig ist

Für Teams, die selbst gehostete Software betreiben, ist eine zuverlässige DNS-Auflösung grundlegend. Wenn Ihr ISP DNS hijackt, können Ihre internen Dienste möglicherweise keine Verbindungen zu externen APIs, Paket-Repositories oder Update-Servern herstellen. Noch kritischer ist, dass Sie möglicherweise zu bösartigen Servern geleitet werden, die vom Interceptor kontrolliert werden. Während ISPs oft behaupten, dies diene dem Filtern oder Caching, bedeutet die mangelnde Transparenz, dass Sie dem Routing nicht vertrauen können. Standard-Monitoring-Tools melden Dienste möglicherweise als "down", wenn sie lediglich aufgrund falscher DNS-Auflösung unerreichbar sind, was zu verschwendeter Fehlersuche führt.

Darüber hinaus vermittelt das Verlassen auf öffentliche Resolver ohne Verschlüsselung ein falsches Sicherheitsgefühl. Systemadministratoren gehen oft davon aus, dass das Zeigen ihrer Firewall oder ihres Routers auf 1.1.1.1 ihren DNS-Datenverkehr absichert. Dieser Vorfall widerlegt diese Annahme. Wenn Ihr ISP aggressiv genug ist, den Datenverkehr auf Port 53 global abzufangen, ist Ihre Wahl des Upstream-Resolvers irrelevant, es sei denn, Sie erzwingen Verschlüsselung am Rand Ihres Netzwerks. Dies betrifft alles von Container-Orchestrierung bis hin zu einfachen Cron-Jobs, die externe Daten abrufen.

Was Sie tun können

• Testen Sie auf Hijacking, indem Sie dig-Ergebnisse im Klartext mit einem DoH-Endpunkt wie dem von Cloudflare für eine fehlerhafte Domain vergleichen.
• Überprüfen Sie die Zugehörigkeit verdächtiger IP-Adressen mittels WHOIS-Lookups, um festzustellen, ob sie zu Ihrem ISP gehören.
• Implementieren Sie DNS over HTTPS oder DNS over TLS auf Ihrem lokalen Resolver, beispielsweise durch Konfiguration von AdGuard Home mit dnscrypt-proxy.
• Vermeiden Sie die Verwendung von Port 5353 für verschlüsselte DNS-Proxies, um Konflikte mit Multicast-DNS-Diensten wie Avahi zu verhindern.
• Konfigurieren Sie Unbound so, dass es Anfragen über TLS weiterleitet, indem Sie forward-tls-upstream: yes angeben und ein CA-Bundle bereitstellen.
• Nutzen Sie Tools wie OONI, um unabhängige Messungen durchzuführen, wenn Sie breitere Netzwerkinterferenzen jenseits von DNS vermuten.