February 26, 2026

VPN und DNS: Split-DNS und Namensauflösung richtig einrichten

„VPN verbunden, aber interne Systeme sind nicht erreichbar“ oder „es geht nur manchmal“ – in der Praxis steckt hinter diesen Symptomen sehr häufig ein DNS-Thema. VPN und DNS sind untrennbar verbunden, weil fast jede Anwendung zuerst eine Namensauflösung benötigt. Wenn der VPN-Client zwar einen Tunnel aufbaut, aber Split-DNS (auch „Split-Horizon DNS“) falsch umgesetzt ist, landen DNS-Anfragen für interne Hostnamen beim falschen Resolver, interne Domains werden nicht gefunden oder – noch kritischer – interne Namen leaken nach außen. Besonders in modernen Umgebungen mit Hybrid-Cloud, SaaS, Full-Tunnel- oder Split-Tunnel-Setups und mehreren Netzwerken pro Endgerät (WLAN, LAN, Mobilfunk, virtuelle Adapter) ist eine saubere DNS-Strategie der Unterschied zwischen „stabil“ und „Support-Albtraum“. Dieser Artikel erklärt verständlich, wie Namensauflösung im VPN funktioniert, wann Split-DNS sinnvoll ist, wie Sie Split-DNS korrekt einrichten, welche Stolperfallen typisch sind und wie Sie DNS-Leaks vermeiden – inklusive Best Practices für Windows, macOS und Linux sowie für klassische IPsec/TLS-VPNs und SSO-nahe Remote-Access-Lösungen.

Table of Contents

Warum DNS im VPN so oft das eigentliche Problem ist

DNS ist die „Adressbuchfunktion“ des Netzwerks: Aus einem Namen (z. B. intranet.firma.local oder git.firma.tld) wird eine IP-Adresse. Ohne funktionierendes DNS scheitern Verbindungen, obwohl Routing und VPN-Tunnel technisch korrekt sein können. Im VPN-Kontext verschärfen sich DNS-Probleme aus drei Gründen:

Mehrere Wege ins Netz: Ein Endgerät hat parallel lokale Internetverbindung und VPN-Tunnel (vor allem bei Split Tunneling).
Mehrere Resolver: lokale Resolver (Heimrouter, ISP, öffentliche DNS-Server) konkurrieren mit Unternehmens-Resolvern.
DNS-Caching und Prioritäten: Betriebssysteme cachen Antworten und entscheiden nach eigenen Regeln, welcher Resolver „zuerst“ gefragt wird.

Wenn diese Komponenten nicht bewusst gesteuert werden, entstehen scheinbar zufällige Fehler: Heute geht der Zugriff auf ein internes System, morgen nicht – oder nur in einem bestimmten WLAN.

Grundlagen: So funktioniert Namensauflösung

DNS ist standardisiert und basiert im Kern auf rekursiven Resolvern und autoritativen Nameservern. Vereinfacht: Der Client fragt einen Resolver, dieser löst den Namen rekursiv auf und liefert eine Antwort zurück. Technische Grundlagen sind in RFC 1034 und RFC 1035 beschrieben.

Stub Resolver: läuft auf dem Endgerät und stellt DNS-Anfragen (z. B. Windows DNS Client, systemd-resolved).
Rekursiver Resolver: beantwortet Anfragen für den Client (z. B. Unternehmens-DNS, ISP-DNS, öffentlicher Resolver).
Autoritativer Server: ist „Quelle der Wahrheit“ für eine Zone (z. B. interne Zone firma.local oder öffentliche Zone firma.de).

Was ist Split-DNS und wann braucht man es?

Split-DNS bedeutet: Je nach Domain (Zone) wird ein unterschiedlicher DNS-Resolver verwendet. Typischerweise werden interne Zonen (z. B. corp.firma, ad.firma, internal.firma.tld) über interne Unternehmensresolver beantwortet, während öffentliche Namen (z. B. google.de) über lokale oder öffentliche Resolver laufen dürfen. Split-DNS ist besonders wichtig, wenn Split Tunneling aktiv ist oder wenn Sie den Internettraffic nicht komplett über den VPN-Egress führen wollen.

Typischer Use Case: Mitarbeitende im Homeoffice nutzen SaaS direkt (lokal), aber interne Systeme über VPN.
Häufige interne Zonen: Active Directory-Domains, interne Service-Domains, private Cloud-Zonen (z. B. internal.example.com).
Wichtiger Nebeneffekt: Schutz vor DNS-Leaks (interne Namen sollen nicht über öffentliche Resolver gehen).

Split-Horizon vs. Split-DNS: Begriffe sauber trennen

In der Praxis werden zwei Konzepte oft vermischt:

Split-DNS (Client-seitig): Der Client entscheidet, welchen Resolver er für welche Domain nutzt.
Split-Horizon DNS (Server-seitig): Derselbe Name liefert je nach Herkunft der Anfrage unterschiedliche Antworten (z. B. interne IP statt öffentliche IP).

Beides kann zusammen genutzt werden: Client nutzt interne Resolver für interne Zonen (Split-DNS) und erhält dort interne Antworten (Split-Horizon). Fehler entstehen häufig, wenn nur eines von beidem umgesetzt wird.

DNS-Leaks im VPN: Was sie sind und warum sie relevant sind

Ein DNS-Leak liegt vor, wenn DNS-Anfragen – insbesondere zu internen Namen – trotz aktivem VPN bei einem externen Resolver landen (ISP, Heimrouter, öffentlicher DNS). Das kann zwei Folgen haben:

Funktionale Probleme: interne Namen werden nicht aufgelöst, weil externe Resolver die Zone nicht kennen.
Sicherheits- und Datenschutzrisiko: interne Hostnamen, Suchdomänen oder Service-Namen werden nach außen sichtbar.

In sensiblen Umgebungen kann DNS-Leak-Vermeidung Teil von Sicherheitsanforderungen sein. Für VPN-Betrieb im deutschen Kontext ist der BSI IT-Grundschutz-Baustein NET.3.3 VPN eine hilfreiche Orientierung (BSI IT-Grundschutz: NET.3.3 VPN).

Full Tunnel vs. Split Tunnel: DNS-Strategie folgt der Tunnelstrategie

Die DNS-Konfiguration hängt stark davon ab, ob Sie Full Tunnel oder Split Tunnel verwenden:

Full Tunnel: Der gesamte Traffic (inkl. DNS) läuft durch den Tunnel. Hier ist es meist sinnvoll, konsequent Unternehmensresolver zu nutzen, um Logging, Filter und konsistente Policies zu erhalten.
Split Tunnel: Nur interne Ziele laufen durch den Tunnel. Hier ist Split-DNS fast immer erforderlich, damit interne Namen intern und externe Namen effizient extern aufgelöst werden.

Praxisregel: Split Tunnel ohne Split-DNS ist einer der schnellsten Wege zu „VPN verbunden, aber nichts geht“.

Design: So bauen Sie eine saubere Split-DNS-Architektur

Eine robuste Split-DNS-Architektur besteht aus klaren Zonen, klaren Resolvern und klaren Prioritäten.

1) Interne Zonen definieren

Liste aller internen DNS-Zonen (AD-Zonen, interne Subdomains, Cloud-private Zonen).
Liste der Namen, die intern anders auflösen sollen als extern (Split-Horizon-Kandidaten).
Entscheidung: Welche Zonen müssen zwingend über interne Resolver gehen?

2) Resolver-Pfade festlegen

Interne Resolver: hochverfügbar, nah am VPN-Gateway, erreichbar über den Tunnel.
Externe Resolver: lokal/ISP oder definierte öffentliche Resolver – abhängig von Policy (manche Organisationen erlauben nur bestimmte Resolver).
Fallback: Was passiert, wenn interne Resolver nicht erreichbar sind? (Idealerweise: interne Zonen failen klar, statt „heimlich extern“ zu leaken.)

3) Suchdomänen und Suffixe sauber steuern

Viele Probleme entstehen nicht durch A/AAAA-Records, sondern durch Suchdomänen (Search Suffix). Wenn ein Client bei „intranet“ automatisch „intranet.corp.firma“ ausprobiert, müssen diese Suchdomänen konsistent gesetzt sein – und zwar so, dass sie nicht nach außen leaken.

Plattform-Praxis: Split-DNS unter Windows, macOS und Linux

Die Umsetzung hängt stark vom Betriebssystem ab, weil jedes OS eigene Regeln für Resolver-Reihenfolge, Interface-Priorität und Domain-Routing hat.

Windows: NRPT und Interface-Prioritäten

Windows bietet mit der Name Resolution Policy Table (NRPT) sehr mächtige Möglichkeiten, DNS-Anfragen pro Namespace zu steuern. Viele Enterprise-VPNs und Always-On-Setups nutzen NRPT, um interne Zonen immer über bestimmte DNS-Server aufzulösen. Typische Best Practices:

Interne Domains per NRPT an interne Resolver binden (z. B. corp.firma → 10.10.10.10).
Interface-Metriken so konfigurieren, dass der VPN-Adapter bei internen Zielen korrekt priorisiert wird.
DNS-Suffixe gezielt setzen und testen (z. B. per GPO/MDM).

macOS: Resolver pro Domain und „scutil“ als Diagnosehilfe

macOS kann Resolver abhängig von Domains nutzen und hat eine eigene Resolver-Logik pro Interface. In der Praxis ist wichtig, dass der VPN-Client Domain-Specific Resolvers korrekt einträgt. Tests sollten nicht nur über „nslookup“ erfolgen, sondern auch über die Systemresolver-Sicht, weil Tools manchmal eigene Resolverpfade nutzen.

Linux: systemd-resolved, resolv.conf und VPN-Plugins

Unter Linux ist die Landschaft heterogen: systemd-resolved, NetworkManager, klassische resolv.conf, Container-DNS. Häufige Fehlerquellen sind „resolv.conf wird überschrieben“, lokale Stub-Resolver und fehlende Domain-Routing-Regeln. Best Practice ist, ein konsistentes Modell zu wählen und VPN-Integration bewusst zu testen (vor allem bei Split Tunnel).

DNS über VPN: Typische Stolperfallen und wie Sie sie vermeiden

Interne Resolver nicht erreichbar: Route zum DNS-Server fehlt im Tunnel, Firewall blockt UDP/TCP 53. Lösung: DNS-Resolver als explizites Tunnelziel einplanen.
Nur UDP 53 erlaubt: Große DNS-Antworten oder DNSSEC können TCP benötigen. Lösung: UDP und TCP 53 berücksichtigen.
IPv6-Leaks: IPv4 wird über VPN geroutet, IPv6 geht am Tunnel vorbei, DNS nutzt IPv6-Resolver. Lösung: IPv6-Strategie definieren (tunneln oder kontrolliert handhaben).
Split-Horizon ohne Split-DNS: Client fragt extern, bekommt öffentliche IP und scheitert intern (Hairpin/Firewall). Lösung: interne Zonen intern auflösen.
Mehrere VPNs/Adapter: Reihenfolge und Metrik führen zu „zufälligem“ Resolverwechsel. Lösung: klare Prioritäten, eindeutige Policies.
Zu aggressive DNS-Caches: falsche Antworten bleiben cached. Lösung: Cache-Verhalten kennen und Tests nach Cache-Flush wiederholen.

DNSSEC, große Antworten und „es geht nur manchmal“

DNS-Antworten können größer werden (z. B. durch viele Records, DNSSEC, lange TXT-Records). Wenn der Pfad MTU-Probleme hat, kann genau DNS der erste Dienst sein, der „sporadisch“ ausfällt. Achten Sie im VPN-Kontext daher auf:

MTU/MSS: Fragmentierung kann DNS-Antworten treffen, besonders bei UDP.
EDNS0: größere UDP-Antworten sind möglich, aber nicht überall robust.
TCP-Fallback: Resolver und Firewalls müssen TCP 53 erlauben.

Wenn Sie bereits MTU-Probleme vermuten, ist die Kombination „DNS + VPN“ ein typischer Trigger: kleine Queries funktionieren, große Antworten nicht.

DoH/DoT und VPN: Moderne Verschlüsselung vs. Unternehmens-DNS

Immer mehr Betriebssysteme und Browser unterstützen DNS over HTTPS (DoH) oder DNS over TLS (DoT). Das kann ein Vorteil für Privatsphäre sein, kollidiert aber in Unternehmensumgebungen mit Split-DNS und internen Zonen, wenn der Client plötzlich „heimlich“ DoH zu einem öffentlichen Resolver nutzt. Technische Referenzen sind RFC 7858 (DoT) und RFC 8484 (DoH).

Risiko: interne Namen werden nicht aufgelöst oder leaken (wenn Browser/OS DoH nutzt).
Best Practice: klare Richtlinie, ob DoH/DoT erlaubt ist, und wie es mit Split-DNS zusammenwirkt.
Pragmatisch: In vielen Unternehmen wird für interne Zonen konsequent Unternehmens-DNS genutzt; DoH/DoT wird entweder kontrolliert bereitgestellt oder in verwalteten Umgebungen eingeschränkt.

Sicher einrichten: Best Practices für Split-DNS im VPN

Interne Resolver redundant: mindestens zwei Resolver, erreichbar über den Tunnel, mit Monitoring.
Domain-Routing statt „alles intern“: nur interne Zonen über interne Resolver; externe Namen effizient extern (bei Split Tunnel).
DNS-Leak-Tests: prüfen, ob interne Hostnamen oder Suchdomänen extern auftauchen.
TCP 53 berücksichtigen: nicht nur UDP, um große Antworten robust zu handhaben.
IPv6 bewusst behandeln: tunneln oder kontrollieren, aber nicht „ignorieren“.
Klare Suffix-Policies: Suchdomänen sauber setzen, damit Kurzhostnamen funktionieren, ohne zu leaken.
Dokumentation: Zonenliste, Resolverliste, Routing-Regeln, Ausnahmen und Verantwortlichkeiten.

Troubleshooting: Schnelle Checks bei DNS-Problemen im VPN

Wenn Nutzer melden „VPN geht nicht“, können Sie mit einem strukturierten Ablauf schnell eingrenzen, ob DNS die Ursache ist:

Welche Namen scheitern? Nur interne? Nur bestimmte Subdomains? Nur kurze Namen ohne FQDN?
Welcher Resolver wird genutzt? Prüfen Sie OS-seitig, welcher DNS-Server aktiv ist (nicht nur in der VPN-App).
Gibt es unterschiedliche Ergebnisse? Interner Resolver vs. externer Resolver liefert andere IP (Split-Horizon).
Ist der Resolver erreichbar? UDP/TCP 53 über den Tunnel, Routing zum Resolver.
Cache-Effekte ausschließen: Cache leeren und erneut testen.
IPv6 testen: AAAA-Records, IPv6-Routen, Resolver über IPv6.

Ein hilfreicher Grundsatz: Erst DNS sauber machen, dann an Routing oder „VPN-Protokoll“ denken. In sehr vielen Fällen ist DNS der schnellere Fix.

Outbound-Links zur Vertiefung

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.