DNS-Leaks verhindern ist eine der wichtigsten – und am häufigsten unterschätzten – Disziplinen, wenn Sie ein VPN richtig konfigurieren möchten. Viele Teams investieren viel Zeit in starke Verschlüsselung, moderne Protokolle und MFA, übersehen aber, dass bereits eine falsch geführte Namensauflösung sensible Informationen preisgeben kann: interne Hostnamen, genutzte SaaS-Dienste, Zielsysteme, Partnerportale oder schlicht das Browsing-Verhalten. Ein DNS-Leak bedeutet nicht zwingend, dass Daten „im Klartext“ übertragen werden – aber es bedeutet, dass DNS-Anfragen außerhalb des gewünschten Schutzpfads landen, etwa beim DNS-Resolver des Hotel-WLANs, beim ISP oder bei einem öffentlichen Resolver. Besonders kritisch wird das bei Split Tunnel, bei mobilen Geräten, bei IPv6, bei Always-On-/On-Demand-Szenarien und überall dort, wo Browser oder Apps DNS-over-HTTPS (DoH) nutzen und damit systemweite DNS-Policies umgehen können. Dieser Leitfaden erklärt verständlich, was DNS-Leaks sind, warum sie entstehen, wie Sie sie zuverlässig testen und – vor allem – welche Konfigurationsmuster auf VPN-Gateways, Clients und in der Unternehmensinfrastruktur wirklich helfen. Ziel ist eine saubere, auditierbare DNS-Strategie, die Nutzererlebnis und Sicherheit gleichermaßen berücksichtigt.
Was ist ein DNS-Leak – und warum ist das ein Problem?
DNS (Domain Name System) übersetzt Namen wie „intranet.firma.tld“ in IP-Adressen. Die DNS-Grundlagen sind in RFC 1034 und RFC 1035 beschrieben. Ein DNS-Leak liegt vor, wenn DNS-Anfragen nicht über den vorgesehenen sicheren Pfad (z. B. den VPN-Tunnel oder einen Unternehmensresolver) gehen, sondern über ein anderes Netzwerkinterface oder einen fremden Resolver.
Warum ist das kritisch?
- Metadatenabfluss: Schon die Domainnamen verraten viel über Anwendungen, Abteilungen, Partner und Workflows.
- Interne Namen: Wenn interne FQDNs extern angefragt werden, entstehen Spuren bei externen Resolvern – und manchmal Fehlkonfigurationen.
- Manipulationsrisiko: Fremde DNS-Resolver können Antworten beeinflussen (z. B. Captive Portals, Filter, Umleitungen).
- Compliance: In regulierten Umgebungen kann DNS-Weitergabe an Dritte problematisch sein.
Die häufigsten Ursachen für DNS-Leaks in VPN-Setups
DNS-Leaks sind selten „ein Bug“, sondern fast immer ein Design- oder Policy-Problem. Diese Ursachen sehen Sie am häufigsten:
- Split Tunnel ohne Split-DNS: Der Client nutzt weiterhin lokale/öffentliche DNS-Resolver, obwohl interne Namen intern aufgelöst werden sollen.
- Interner DNS wird gepusht, ist aber nicht erreichbar: Dann fällt der Client auf lokale Resolver zurück oder timeouts führen zu alternativen Pfaden.
- IPv6 wird nicht berücksichtigt: IPv4 ist korrekt getunnelt, IPv6-Anfragen gehen lokal raus (oder umgekehrt).
- Browser/Apps nutzen DoH: DNS-over-HTTPS umgeht systemweite DNS-Settings, wenn keine Policy greift.
- Mehrere Interfaces/VPNs: konkurrierende Routen und DNS-Prioritäten (z. B. Always-On + manuelles VPN).
- MDM/Profilfehler: Auf mobilen Geräten oder macOS/Windows-Profilen sind DNS-Settings unvollständig oder inkonsistent.
Split Tunnel vs. Full Tunnel: DNS-Leaks entstehen an der Schnittstelle
Ob Sie DNS-Leaks vermeiden können, hängt stark davon ab, wie Sie Routing und DNS koppeln.
Full Tunnel: einfacher, aber nicht automatisch leak-frei
- Default Route über VPN – DNS-Resolver liegt idealerweise ebenfalls „hinter“ dem Tunnel.
- Leak-Risiko entsteht, wenn der Client trotzdem lokale Resolver nutzt (z. B. durch DoH) oder wenn IPv6 lokal bleibt.
- Vorteil: Sie können DNS zentral erzwingen (Firewall/Proxy/DNS-Policy am Gateway).
Split Tunnel: effizient, aber DNS muss aktiv gestaltet werden
- Nur interne Netze werden geroutet; Internet bleibt lokal.
- Wenn Sie interne DNS-Resolver pushen, müssen Clients diese Resolver über VPN erreichen können.
- Ohne Split-DNS gehen interne Domains schnell „nach außen“ oder lösen gar nicht.
Merksatz: Split Tunnel ohne Split-DNS ist der häufigste Grund für DNS-Leaks.
DNS-Strategien, die in Unternehmen wirklich funktionieren
Es gibt mehrere saubere Muster, um DNS-Leaks zu vermeiden. Welche Strategie passt, hängt davon ab, ob Sie Full Tunnel oder Split Tunnel nutzen, wie Ihr Namensraum aufgebaut ist und wie Ihre Clients gemanagt werden.
Strategie A: Zentraler Unternehmensresolver über VPN (Full Tunnel oder kontrollierter Split)
- Der VPN-Client erhält einen oder mehrere interne DNS-Server (z. B. 10.10.10.10).
- Alle DNS-Anfragen gehen an diesen Resolver (für intern und extern).
- Vorteil: einfache Governance, zentrale Logs und Filterung möglich.
- Risiko: Wenn der Resolver oder der Pfad instabil ist, „stirbt Internet“ gefühlt sofort.
Strategie B: Split-DNS (interne Zonen intern, externe Zonen extern)
- Interne Domains (z. B. *.corp.firma.tld) gehen an interne Resolver.
- Externe Domains gehen an lokale/öffentliche Resolver (oder an einen sicheren Unternehmens-Resolver im Internet).
- Vorteil: weniger Backhaul, stabileres Nutzererlebnis, geringere Last am VPN.
- Risiko: Implementierung ist OS-/MDM-abhängig; DoH kann Split-DNS umgehen.
Strategie C: Per-App VPN + interne DNS nur für Unternehmensapps (Mobile/BYOD)
- Nur Managed Apps nutzen VPN; DNS für diese Apps wird intern aufgelöst.
- Private Apps bleiben außerhalb (Privatsphäre, Performance).
- Vorteil: sehr sauber für BYOD, geringes Leak-Risiko für Unternehmensdaten.
- Risiko: erfordert MDM/Managed App Framework, gute App-Zuordnung.
DNS-over-HTTPS (DoH): Der häufigste „unsichtbare Leak“
DoH verpackt DNS-Anfragen in HTTPS. Dadurch können Browser (oder Apps) DNS komplett am Betriebssystem vorbei abwickeln. Das ist aus Privatsphäre-Sicht oft gut, aber aus Unternehmenssicht kann es Split-DNS und zentrale DNS-Policies unterlaufen.
- Symptom: System-DNS zeigt interne Resolver, trotzdem gehen Anfragen an öffentliche DoH-Endpunkte.
- Risiko: interne Hostnamen können (je nach Browserverhalten) nach außen gelangen; Policy-Kontrollen werden umgangen.
- Fix: DoH per Endpoint-Policy/MDM steuern (Browser-Policies), oder Netzwerkseitig DoH-Endpunkte kontrollieren (SWG/SSE) – immer mit klarer Governance.
Wichtig: DoH ist nicht „böse“, aber es muss in Ihr Security- und DNS-Design passen. Ohne Policy ist DoH ein häufiger Grund für überraschende DNS-Leaks.
IPv6: Wenn Sie es nicht planen, leakt es
Viele VPNs und Netzdesigns sind noch IPv4-zentriert. Moderne Betriebssysteme nutzen IPv6 jedoch bevorzugt, wenn verfügbar. DNS liefert dann AAAA-Records, und Traffic kann über IPv6 einen ganz anderen Pfad nehmen als IPv4.
- Leak-Muster: IPv4-DNS geht über VPN, IPv6-DNS oder IPv6-Traffic geht lokal raus.
- Blackhole-Muster: DNS liefert AAAA, aber IPv6-Pfad ist gebrochen → Webseiten wirken „kaputt“.
- Fix: IPv6 bewusst entscheiden: entweder korrekt über VPN und Policies führen oder kontrolliert behandeln (inkl. DNS-Policy).
Path MTU Discovery ist im IPv6-Kontext besonders relevant (RFC 8201), weil Fragmentierung anders funktioniert als bei IPv4.
Konfiguration am VPN-Gateway: Was Sie serverseitig setzen müssen
DNS-Leak-Vermeidung ist nicht nur Client-Sache. Das Gateway entscheidet, welche DNS-Optionen gepusht werden und ob DNS-Traffic überhaupt erlaubt ist.
- DNS-Server pushen: interne Resolver oder definierte sichere Resolver (je nach Strategie).
- DNS-Suchdomänen: Corporate Suffixes setzen (z. B. corp.firma.tld), damit interne Shortnames funktionieren.
- Firewall-Regeln: DNS (UDP/TCP 53) vom VPN-Clientnetz zu den internen Resolvern erlauben.
- Split-DNS-Regeln: wenn Plattform unterstützt, interne Zonen explizit an interne Resolver binden.
- Block-Regeln gegen Leaks: optional DNS zu „extern“ blocken, wenn Sie Full Tunnel oder strenge Compliance benötigen.
Praxis-Tipp: Wenn Sie DNS-Leaks strikt verhindern wollen, brauchen Sie eine klare Entscheidung: Entweder DNS nur über Unternehmensresolver (dann externes DNS blocken) oder sauberes Split-DNS (dann DoH/DoT-Governance zwingend).
Konfiguration auf Clients: Die wichtigsten Stellschrauben je OS
Die konkreten Settings unterscheiden sich je nach Betriebssystem, aber die Prinzipien sind gleich: Resolver, Priorität und Route zum Resolver müssen zusammenpassen.
Windows
- Prüfen: Welche DNS-Server sind auf dem VPN-Adapter gesetzt (
ipconfig /all)? - Prüfen: Welche Namensauflösung greift (NRPT, Policy-Routing für Namen)?
- Fix: DNS-Suffix/NRPT über GPO/MDM setzen, DoH über Browser-/OS-Policy kontrollieren.
macOS
- Prüfen: Resolver-Reihenfolge und domain-spezifische Resolver (
scutil --dns). - Fix: Konfigurationsprofile (mobileconfig) nutzen, On-Demand/Per-App VPN sauber setzen, Resolver-Prioritäten kontrollieren.
iOS/Android
- Per-App VPN ist oft die sauberste Leak-Vermeidung bei BYOD.
- Fix: MDM-Profile, Managed DNS/Resolver, Compliance-Policies und App-Zuordnung.
Linux
- Prüfen: Systemd-resolved/NetworkManager-Resolver (
resolvectl status). - Fix: Split-DNS über resolver-Policies, VPN-Client-Skripte oder NetworkManager-Profile; DoH-App-Policies berücksichtigen.
Tests: So erkennen Sie DNS-Leaks zuverlässig
Testen Sie DNS-Leaks immer in zwei Dimensionen: „Welche Resolver werden genutzt?“ und „Über welches Interface geht der DNS-Traffic?“
Resolver-Check
- Prüfen Sie, welche DNS-Server aktiv sind (OS-spezifische Tools).
- Testen Sie interne und externe Namen getrennt.
Interface-Check
- Packet Capture am Client oder Gateway: Gehen DNS-Anfragen an externe Resolver, obwohl sie intern sein sollten?
- Auf Gateways: Sehen Sie DNS-Traffic vom VPN-Pool zu internen Resolvern?
Praktische Kommando-Tests
# macOS: Resolver-Details
scutil --dns
Linux: Resolver-Details
resolvectl status
Windows: DNS-Server am Adapter
ipconfig /all
Direkter DNS-Test gegen internen Resolver
dig @10.10.10.10 intranet.corp.firma.tld
nslookup intranet.corp.firma.tld 10.10.10.10
Wenn der interne Name nur über einen externen Resolver angefragt wird oder überhaupt nicht auflöst, ist das ein klarer Indikator für ein DNS-/Split-DNS-Problem.
Typische Fehlerbilder und schnelle Fixes
- Internet geht, Intranet geht nicht: interne DNS-Resolver fehlen oder sind nicht erreichbar → DNS/Firewall-Regeln prüfen, Split-DNS einführen.
- VPN an, Internet „tot“: interner DNS gepusht, aber nicht erreichbar → Route zum Resolver fehlt oder DNS wird geblockt; alternativ Default Route versehentlich im Tunnel.
- Nur Browser betroffen: DoH aktiv → Browser-Policy setzen, DoH-Endpunkte kontrollieren, Unternehmensresolver nutzen.
- Nur „manche“ Seiten gehen: IPv6/AAAA und Pfadprobleme oder MTU → IPv6-Policy und MTU/MSS prüfen.
- Leck nur in bestimmten Netzen: Captive Portals/Hotel-WLAN intercepten DNS → Full Tunnel oder TLS-basierte Kontrolle (SSE/SWG) erwägen.
Hardening: DNS-Leaks aktiv verhindern statt nur „hoffen“
Wenn Sie DNS-Leaks wirklich vermeiden wollen, reichen „korrekte“ DNS-Server-Einstellungen nicht immer. In vielen Umgebungen sind zusätzliche Kontrollen sinnvoll:
- DNS nur zum Unternehmensresolver erlauben: Firewall-Regeln, die DNS zu extern blocken (wenn Strategie A gewählt ist).
- DoH/DoT Governance: Browser-/OS-Policies, ggf. SWG/SSE zur Durchsetzung.
- Logging: DNS-Anfragen zentral sichtbar machen (intern), um Abweichungen zu erkennen.
- MDM/Profilpflicht: kein „manuelles Basteln“ – Profile sind reproduzierbarer.
- IPv6 sauber einplanen: entweder konsequent unterstützen oder bewusst kontrollieren.
Für organisatorische Einbettung in Sicherheitsanforderungen und Betrieb eignet sich als Rahmen u. a. der BSI IT-Grundschutz-Baustein zu VPN: BSI IT-Grundschutz: NET.3.3 VPN.
Praxis-Checkliste: DNS-Leaks verhindern mit sauberer VPN-Konfiguration
- 1) DNS-Strategie festlegen: zentraler Resolver oder Split-DNS oder Per-App VPN.
- 2) VPN pusht passende DNS-Server und Suchdomänen; Dokumentation der Werte.
- 3) Route zum internen DNS-Resolver existiert (Split Tunnel) und DNS ist firewall-seitig erlaubt.
- 4) Externe DNS-Anfragen werden – je nach Strategie – kontrolliert oder geblockt.
- 5) DoH/DoT wird per Policy geregelt (Browser/OS), damit System-DNS nicht umgangen wird.
- 6) IPv6-Policy ist definiert und getestet.
- 7) Tests: interne und externe Namen, Resolver-Check, Interface-Check (PCAP/Logs).
- 8) Monitoring: DNS-Fail-Raten, Anomalien (externe Resolver), Tickets nach Netzen clustern.
Outbound-Links zur Vertiefung
- RFC 1034: DNS Concepts
- RFC 1035: DNS Specification
- RFC 5280: X.509 Certificates and CRL Profile
- RFC 6960: OCSP
- RFC 8201: Path MTU Discovery (IPv6)
- BSI IT-Grundschutz: NET.3.3 VPN
Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte
Cisco Networking • CCNA • Packet Tracer • Network Configuration
Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.
Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.
Leistungsumfang:
-
Netzwerkdesign & Topologie-Planung
-
Router- & Switch-Konfiguration (Cisco IOS)
-
VLAN, Inter-VLAN Routing
-
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
-
NAT, ACL, DHCP, DNS-Konfiguration
-
Troubleshooting & Netzwerkoptimierung
-
Packet Tracer Projektentwicklung & Dokumentation
-
CCNA Lern- & Praxisunterstützung
Lieferumfang:
-
Konfigurationsdateien
-
Packet-Tracer-Dateien (.pkt)
-
Netzwerkdokumentation
-
Schritt-für-Schritt-Erklärungen (auf Wunsch)
Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert
CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

