February 26, 2026

DNS im VPN: Split DNS, Leaks und Resolver-Ketten sauber designen

DNS im VPN ist einer der häufigsten Gründe, warum „der Tunnel steht, aber nichts funktioniert“ – und gleichzeitig einer der größten Sicherheitshebel in Remote-Access- und Site-to-Site-Designs. Denn DNS entscheidet nicht nur, ob Anwendungen erreichbar sind, sondern auch, welche Namensräume ein Client überhaupt „sieht“, wohin Traffic geroutet wird (z. B. via Split Tunnel), und ob sensible interne Hostnamen oder Suchdomains ungewollt nach außen gelangen. In modernen Umgebungen wird das zusätzlich komplex, weil Endgeräte eigene Resolver-Stacks mitbringen (DoH/DoT, VPN-Profile, MDM-Policies), weil SASE/Proxy-Ketten DNS „umleiten“ können, und weil Cloud- sowie Hybrid-DNS (Private DNS Zonen, Conditional Forwarding, Split Horizon) parallel existieren. Ein sauberes Design muss deshalb drei Ziele gleichzeitig erreichen: erstens zuverlässige Namensauflösung für interne und externe Ressourcen (Verfügbarkeit), zweitens minimale Datenabgabe und Vermeidung von DNS Leaks (Privacy/Security), drittens klare Resolver-Ketten, die operativ messbar und auditierbar sind (Betrieb). Dieser Beitrag zeigt, wie Sie Split DNS robust implementieren, typische Leak-Ursachen eliminieren und Resolver-Ketten so gestalten, dass Remote-Clients, VPN-Gateways, DNS-Forwarder, interne Authoritatives und externe Resolver konsistent zusammenspielen.

Table of Contents

Warum DNS im VPN so oft scheitert

Viele VPN-Probleme wirken zunächst wie Routing- oder Firewallfehler, sind aber DNS-Themen. Der Grund: Anwendungen arbeiten fast immer mit Namen, nicht mit IPs. Wenn DNS falsche Antworten liefert, zu langsam ist oder abreißt, entsteht das gleiche Symptom wie bei Netzwerkstörungen: Timeouts, „Seite lädt nicht“, „SSO hängt“, „RDP findet Host nicht“.

Mehrere Namensräume: Intern (corp.local / internal.example), Cloud Private Zones, Partner-Domains, öffentliches Internet – alles gleichzeitig.
Unklare Priorität: Welcher Resolver ist „zuständig“? Lokaler ISP, Corporate DNS, SASE DNS, Split DNS Resolver?
Client-spezifisches Verhalten: Betriebssysteme und Browser nutzen unterschiedliche Resolverpfade, Caches und teils DoH/DoT.
Split Tunnel Nebenwirkungen: Wenn nur Teile des Traffics durch den Tunnel gehen, muss DNS dazu passen, sonst „zeigt DNS nach innen, Traffic geht nach außen“ oder umgekehrt.

Als technische Basis für DNS eignet sich RFC 1034 und RFC 1035 (DNS Grundlagen).

Begriffe sauber trennen: Split DNS, Split Horizon, Resolver-Kette, Leak

Im Alltag werden DNS-Begriffe oft vermischt. Für ein robustes Design lohnt sich eine klare Terminologie:

Split DNS: Der Client nutzt je nach Domain/Suffix unterschiedliche Resolver (z. B. intern für corp.example, extern für alles andere).
Split Horizon DNS: Der gleiche Domainname liefert unterschiedliche Antworten abhängig vom Client-Standort/Netz (z. B. intern private IP, extern public IP).
Resolver-Kette: Der Pfad der Anfrage: Client Stub Resolver → VPN DNS/Forwarder → Recursive Resolver → Authoritative DNS.
DNS Leak: Eine DNS-Anfrage, die eigentlich über den VPN-/Corporate-Pfad gehen soll, wird an einen externen Resolver gesendet (ISP, Public DNS, DoH-Endpunkt) – oft unbemerkt.

Designziel 1: Verfügbarkeit – Namensauflösung muss deterministisch sein

Ein VPN-DNS-Design sollte deterministisch sein: Für jeden Namensraum ist klar, welcher Resolver zuständig ist, wie Failover funktioniert und wie Caching/TTL wirkt. Das beginnt beim Client.

Client DNS: Welche Informationen ein VPN-Profil liefern muss

DNS-Server: Welche Resolver-IP(s) soll der Client nutzen? Idealerweise redundante Resolver pro Region/PoP.
DNS-Suffix/Search Domains: Welche Suchdomains werden angehängt (z. B. corp.example)? Zu viele Suffixe erhöhen Leak-Risiko und Latenz.
Split DNS Regeln: Welche Domains müssen zwingend über Corporate Resolver laufen (Conditional DNS)?
Routing für Resolver: Sicherstellen, dass der Resolver über den Tunnel erreichbar ist (insbesondere bei Split Tunnel).

Resolver-Redundanz ohne Chaos

Mindestens zwei Resolver: Pro Site/Region zwei unabhängige Resolver, nicht nur zwei IPs auf demselben Host.
Health Checks: Nicht nur „Port 53 offen“, sondern echte DNS-Probes (A/AAAA/NS-Abfrage) und Latenz.
Failover-Policy: Client-Failover kann „sticky“ sein oder aggressiv wechseln; designen Sie so, dass Failover nicht zu Flapping führt.

Designziel 2: Sicherheit & Privacy – DNS Leaks verhindern

DNS ist Metadatenverkehr. Selbst wenn Ihre Anwendungsdaten verschlüsselt sind, verraten DNS-Anfragen, welche Dienste genutzt werden und welche internen Namen existieren. Leaks sind deshalb nicht nur ein Verfügbarkeitsproblem, sondern auch ein Sicherheits- und Datenschutzproblem.

Typische Leak-Ursachen im VPN

Split Tunnel ohne DNS-Routing: Der Client nutzt Corporate DNS, aber die Route zum Resolver geht nicht durch den Tunnel – Ergebnis: Timeout oder Fallback auf ISP DNS.
Search Domains „zu breit“: Der Client hängt interne Suffixe an öffentliche Anfragen an (z. B. printer.corp.example wird nach außen gefragt).
Mehrere aktive Interfaces: WLAN + Ethernet + LTE; OS wählt Resolver nach Metrik, nicht nach Sicherheitsabsicht.
DoH/DoT am Client: Browser/OS nutzt DNS-over-HTTPS/-TLS an einen externen Provider und umgeht Corporate Policies.
Captive Portals/Hotel-WLAN: DNS wird „hijacked“ oder stark gefiltert, sodass der VPN-Stub Fallback-Verhalten zeigt.

DNS-over-HTTPS und DNS-over-TLS im Unternehmenskontext

DoH/DoT erhöhen Privacy im offenen Internet, können aber im Enterprise DNS-Steuerung und Security-Policies umgehen, wenn sie unkontrolliert eingesetzt werden. DoH ist in RFC 8484 beschrieben, DoT in RFC 7858.

Policy-Entscheidung: Entweder DoH/DoT gezielt über Corporate Resolver anbieten oder clientseitig einschränken (MDM/GPO/Browser Policies).
Explizite Ausnahmen: Wenn Entwickler-Tools DoH erzwingen, braucht es definierte Ausnahmen – sonst entstehen Schattenpfade.
Visibility: Wenn Sie DNS als Detection-Signal nutzen (Threat Intel, DGA), dürfen DoH-Leaks die Telemetrie nicht aushebeln.

Designziel 3: Betrieb – Resolver-Ketten müssen beobachtbar und debuggbar sein

Ein gutes DNS/VPN-Design ist operationalisierbar: Sie können messen, ob Auflösung funktioniert, und Sie können schnell unterscheiden, ob das Problem am Client, am VPN, am Forwarder oder am Authoritative liegt.

Korrelierbare Logs: VPN-Session-ID/Client-IP muss mit DNS-Query-Logs korrelierbar sein (mindestens über Quell-IP und Zeitfenster).
Latency-Metriken: p50/p95 DNS-Latenz pro Resolver und pro Namensraum (intern vs extern).
Failure Reasons: NXDOMAIN vs. SERVFAIL vs. Timeout vs. REFUSED – das sind völlig unterschiedliche Ursachen.
Canary Probes: Synthetische Tests aus VPN-Client-Sicht: interne Domain, externe Domain, Cloud Private Zone, Reverse Lookup.

Split DNS Patterns: Bewährte Architekturvarianten

Split DNS ist kein einzelnes Feature, sondern ein Pattern. In Enterprise-Umgebungen haben sich drei Varianten etabliert, abhängig von Client-Fähigkeiten und Governance.

Pattern: Clientseitiges Split DNS (Conditional DNS am Endgerät)

Idee: Der Client entscheidet, welche Domains zu welchen Resolvern gehen.
Vorteil: Geringere Last auf Corporate Resolvern für reines Internet-DNS; bessere Performance für public lookups.
Risiko: Komplexere Client-Policy, OS-/Client-Unterschiede, höheres Leak-Risiko bei Fehlrouting.
Geeignet: Managed Devices mit MDM/GPO und gut kontrollierbarer DNS-Policy.

Pattern: Gatewayseitiges Split DNS (Alles über Corporate Resolver, intern/external via Forwarding)

Idee: Clients nutzen ausschließlich Corporate DNS; dieser forwardet intern/extern abhängig von Domain.
Vorteil: Sehr kontrollierbar, weniger Client-Komplexität, weniger Leaks.
Trade-off: Mehr DNS-Last zentral, potenziell höhere Latenz für public DNS, höherer Skalierungsbedarf.
Geeignet: Große heterogene Clientlandschaften, hohe Compliance-Anforderungen.

Pattern: Hybrid (Corporate DNS für interne Domains, Public DNS für alles andere, aber mit „Leak Guards“)

Idee: Conditional Forwarding/Policies: intern strikt über Corporate Resolver, extern ggf. lokal.
Vorteil: Performance besser, wenn public DNS lokal bleibt; interne Namensräume geschützt.
Wichtig: Harte Sicherungen gegen Fallback/DoH, sonst entstehen unkontrollierte Pfade.

Resolver-Ketten sauber designen: Stub → Forwarder → Recursive → Authoritative

Für Stabilität und Skalierung sollten Sie DNS als Kette betrachten. Typische Enterprise-Kette:

Client Stub Resolver: OS entscheidet Caching, Search Domains, Fallback-Mechanismen.
VPN-provisionierter Forwarder: Corporate DNS-Forwarder, der Policies erzwingt (Split/Conditional Forwarding).
Recursive Resolver: Interner Resolver, der rekursiv auflöst und cached (intern und extern, ggf. getrennt).
Authoritative DNS: Für interne Zonen (AD DNS, BIND, cloud private DNS) und externe Zonen.

Wichtig ist, Loops zu vermeiden: Wenn Forwarder A an B weiterleitet und B an A zurück, entstehen SERVFAILs und „random“ timeouts. Eine saubere Zonenzuständigkeit (Conditional Forwarding) ist Pflicht.

Split Horizon vs. VPN: Wenn gleiche Namen unterschiedliche Antworten liefern

Split Horizon ist praktisch, aber im VPN besonders fehleranfällig, weil Clients je nach Resolver unterschiedliche Antworten bekommen können. Typisches Beispiel: app.example.com zeigt intern auf private IPs, extern auf eine Public VIP. Wenn ein VPN-Client „aus Versehen“ den externen Resolver nutzt, erhält er die falsche IP und läuft in Firewall/Route-Probleme.

Konsequenz: Split Horizon und Split Tunnel müssen abgestimmt sein. Wenn DNS „intern“ antwortet, muss der Datenpfad intern erreichbar sein.
Cloud-Hybrid-Fallen: Private DNS Zonen können unterschiedlich aufgelöst werden, je nachdem ob der Resolver im richtigen Netzwerksegment sitzt.
Debug-Strategie: Immer testen: Auflösung intern/external, dann Connectivity zur gelieferten IP. DNS ohne Connectivity ist ein Anti-Pattern.

DNS Leaks im Detail: Wie sie entstehen und wie man sie nachweist

Ein Leak ist oft kein einzelnes Paket, sondern ein Verhalten: Der Client nutzt in bestimmten Situationen nicht den vorgesehenen Resolver. Um das nachzuweisen, brauchen Sie Tests aus Client-Sicht und Logs aus Resolver-Sicht.

Leak-Nachweise, die in der Praxis funktionieren

Client-Test: Abfragen interner Domains während VPN aktiv ist und prüfen, welcher Resolver antwortet (VPN-DNS vs. ISP/Public).
Resolver-Logs: Sehen Sie Anfragen für interne Suffixe auf externen Resolvern oder im Proxy? Das ist ein Leak-Indikator.
Packet Capture (gezielt): Kurzer Mitschnitt am Client oder Gateway kann zeigen, ob DNS über das richtige Interface geht.
DoH-Erkennung: Ausgehend zu bekannten DoH-Endpunkten über 443, wenn DoH nicht erlaubt sein soll (hier ist Policy und Datenschutz zu beachten).

Search Domains und Suffix-Listen: Kleine Einstellung, große Wirkung

Search Domains sind ein häufiger Leak-Treiber: Ein Client, der „server01“ auflöst, hängt automatisch Suffixe an (z. B. server01.corp.example). Wenn diese Anfrage extern landet, ist das ein Informationsabfluss. Gleichzeitig erzeugen zu viele Suffixe zusätzliche DNS-Latenz, weil mehrere Queries entstehen.

Minimal halten: Nur die wirklich notwendigen Suchdomains provisionieren.
FQDN bevorzugen: In professionellen Umgebungen sollten Anwendungen und Admin-Workflows FQDNs nutzen, nicht Kurzhostnamen.
Policy für interne Namensräume: Interne Zonen eindeutig definieren und nur intern resolven.

DNS und VPN-Security: Threat Blocking ohne Kollateralschäden

Viele Unternehmen nutzen DNS für Security: Blocklisten, Sinkholing, Malware-Domains, DGA-Erkennung. Im VPN-Kontext ist das sinnvoll, aber Sie müssen es so designen, dass es nicht zu „zufälligen“ Ausfällen führt.

Block-Transparenz: Ein blockiertes DNS sollte eindeutig erkennbar sein (z. B. NXDOMAIN/Sinkhole) und nicht als Timeout wirken.
Logging & Privacy: DNS-Logs sind sensibel; Retention und Zugriff müssen klar geregelt sein, insbesondere bei Remote Work.
Whitelist-Prozesse: SaaS und CDNs ändern Domains; ohne schnellen Whitelist-Prozess entstehen Business-Outages.

Site-to-Site VPN: DNS-Design für mehrere Standorte

In Site-to-Site-Topologien ist DNS häufig ein Routing-Thema: Welcher Standort ist „DNS Hub“? Werden Zonen repliziert? Gibt es lokale Resolver, die über den Tunnel forwarden?

Lokale Resolver bevorzugen: Standorte sollten lokale Caches/Forwarder haben, um Latenz zu reduzieren und Tunnel nicht mit DNS-Chatty-Traffic zu belasten.
Conditional Forwarding sauber: Interne Zonen zu den zuständigen Authoritatives, externe Zonen zu definierten Rekursiven.
Failover-Strategie: Wenn der Tunnel ausfällt, darf DNS nicht „in einen falschen Resolverpfad“ kippen, der Split Horizon bricht.

Full Tunnel vs. Split Tunnel: DNS muss die Traffic-Policy spiegeln

DNS und Routing sind untrennbar: Wenn ein Client DNS intern auflöst, muss der Traffic zur gelieferten IP auch intern geroutet werden. Umgekehrt kann Split Tunnel externe Ziele lokal routen, aber dann darf DNS nicht „alles“ durch Corporate Resolver erzwingen, wenn das zu unnötiger Latenz führt.

Full Tunnel: Einfacher zu kontrollieren (DNS und Traffic über VPN), aber höhere zentrale Last und höhere Anforderungen an Egress und NAT.
Split Tunnel: Performancevorteile, aber höheres Leak-Risiko und mehr Komplexität im Client-Policy-Design.
Hybrid: Häufig sinnvoll: interne Domains strikt über Corporate Resolver und Tunnel, extern lokal oder über SASE – aber nur mit klaren Guardrails.

Monitoring & Troubleshooting: Schnelle Ursachenfindung bei DNS-Problemen

DNS-Probleme eskalieren schnell, weil sie „alles“ betreffen. Ein Experten-Setup hat deshalb standardisierte Checks und KPIs.

KPIs und SLIs für DNS im VPN

DNS Success Rate: Anteil erfolgreicher Antworten (NOERROR) pro Namensraum (intern/external).
NXDOMAIN Rate: Plötzliche Peaks können Fehlkonfiguration, Split Horizon Probleme oder Tippfehlerwellen anzeigen.
SERVFAIL/Timeout Rate: Starker Indikator für Resolver-Chain-Probleme, Loops oder Upstream-Ausfälle.
DNS Latency p95: Hohe Latenz wirkt direkt auf App-Start und Login flows.

Runbook-Checks, die immer funktionieren

Auflösung intern/external testen: Dieselbe Domain einmal mit Corporate Resolver, einmal mit Public Resolver.
Connectivity zur Antwort-IP prüfen: DNS ok, aber Traffic blockiert? Dann ist es Routing/Firewall, nicht DNS.
Resolver-Kette verifizieren: Forwarder → recursive → authoritative; Loops ausschließen.
Client-Interface-Reihenfolge: Prüfen, ob der Client den VPN-Resolver wirklich bevorzugt und ob DoH/DoT Policies greifen.

Häufige Anti-Patterns im DNS/VPN-Design

„Ein DNS für alles“ ohne Skalierung: Corporate Resolver wird zum Single Point of Failure und Performance-Bottleneck.
Zu viele Search Domains: Erhöht Leaks und Latenz, erschwert Debugging.
Split Horizon ohne Guardrails: Falscher Resolverpfad liefert falsche IPs, Traffic blackholt.
Unkontrolliertes DoH: Umgeht Corporate DNS, bricht Sichtbarkeit und Policies, erzeugt „mysteriöse“ Abweichungen.
Split Tunnel ohne DNS-Plan: DNS zeigt nach innen, Traffic geht nach außen – oder umgekehrt.
Keine Canary Probes: Probleme werden erst durch Nutzer bemerkt, nicht durch Monitoring.

Checkliste: Split DNS, Leaks und Resolver-Ketten sauber designen

Namensräume definieren: Welche Domains sind intern, welche extern, welche Partner-/Cloud-Zonen existieren?
Resolver-Kette festlegen: Stub → Forwarder → Recursive → Authoritative, inklusive Failover und Loop-Prevention.
Split DNS Regeln: Conditional Forwarding für interne Zonen, klare Policy für externes DNS (lokal vs. corporate vs. SASE).
Leak Guards: Routing zum Resolver sicherstellen, Search Domains minimieren, DoH/DoT bewusst steuern, Interface-Metriken beachten.
Split Horizon prüfen: DNS-Antwort und Traffic-Policy müssen konsistent sein, sonst entstehen Blackholes.
Redundanz: Mindestens zwei Resolver pro Region, echte Health Checks (DNS-Queries), nicht nur Portchecks.
Monitoring: Success/NXDOMAIN/SERVFAIL/Timeout, Latency p95, Canary Probes aus VPN-Client-Sicht.
Troubleshooting-Runbooks: Standardtests für intern/external Resolution, Connectivity zur Antwort-IP, Resolver-Chain-Verifikation.
Privacy & Retention: DNS-Logs als sensitive Daten behandeln, Zugriff und Aufbewahrung zweckgebunden gestalten.

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.