Untersuchen des Verhaltens von DNS-Abfragen und der Domänennamenauflösung

Einleitung

In diesem Dokument wird beschrieben, wie Client-Betriebssysteme DNS-Abfragen verarbeiten und welche Auswirkungen dies auf die Auflösung von Domänennamen mit dem Cisco IOS® Secure Client hat.

---

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. In den Beispielen werden Richtlinien für sichere Firewall-ASA/FTD-Gruppen und Cisco Secure Client unter Windows, MacOS, Linux und Apple iOS verwendet.

---

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

---

Split versus Standard-DNS

In diesem Dokument wird erläutert, wie Client-Betriebssysteme DNS-Abfragen verarbeiten und wie sich dies auf die Auflösung von Domänennamen auswirkt, wenn Cisco Secure Client (ehemals Cisco AnyConnect) mit getrenntem oder vollständigem Tunneling verwendet wird. Zu den VPN-Headends, die vorgestellt wurden, gehören Cisco Secure Firewall ASA und FTD (ehemals ASA); Gruppenrichtlinieneinstellungen wie split-dns, dns-server und split-tunnel-all-dns gelten für beide, sofern nicht anders angegeben.

---

Wenn ein Abschnitt explizit auf ältere Client-Versionen verweist, gilt das für Secure Client 4.2 und höher beschriebene Verhalten (einschließlich aktueller Secure Client 5.x-Versionen). Cisco AnyConnect 4.x hat das Ende des Lebenszyklus erreicht; Migration auf Cisco Secure Client für unterstützte DNS- und Tunneling-Funktionen

Das Verhalten der DNS-Auflösung hängt von drei Faktoren ab:

• VPN-DNS-Richtlinie: Konfiguration am Headend (Split-DNS, Tunnel-All-DNS oder Standard-DNS)
• Split-Tunneling-Modus: Tunnel-all, split-include oder split-exclude
• Client-Betriebssystem: DNS-Resolver-Architektur (pro Schnittstelle und global)

---

Wenn Sie den Befehl split-include tunneling ausführen, sind die folgenden drei DNS-Optionen in der Gruppenrichtlinie verfügbar:

---

Modus	Beschreibung
Split-DNS	DNS-Abfragen, die mit den im Headend konfigurierten Domänennamen übereinstimmen (split-dns), werden über den Tunnel an die VPN DNS-Server (dns-server) gesendet. Alle anderen Abfragen verwenden den Client-Betriebssystemauflöser und die DNS-Server des physischen Adapters.
Tunnel-all-DNS	Es ist nur der DNS-Datenverkehr zu den vom Headend definierten DNS-Servern zulässig. Wird mit split-tunnel-all-dns enable in der Gruppenrichtlinie konfiguriert.
Standard-DNS	Alle DNS-Abfragen werden zuerst an die vom Headend definierten VPN-DNS-Server gesendet. Bei einer negativen Antwort (NXDOMAIN oder bei Nichtantwort) kann der Resolver auch DNS-Server auf dem physischen Adapter testen.

---

---

Test von DNS - Wichtig

---

---

True versus Best Effort Split DNS

In AnyConnect 2.4 wurde ein Split DNS-Fallback (bestmöglicher Split DNS) eingeführt, der kein echter Split-DNS ist und auch im Legacy-IPsec-Client gefunden wurde.

---

Best-Effort-Verhalten (Fallback):

• Wenn die Anforderung mit einer geteilten DNS-Domäne übereinstimmt, ermöglicht Secure Client das Tunneling der Anforderung zum Headend.
• Wenn der VPN-DNS-Server den Hostnamen nicht auflösen kann, wird der DNS-Auflöser des Betriebssystems fortgesetzt, und dieselbe Abfrage kann an einen DNS-Server an der physischen Schnittstelle gesendet werden.
• Wenn die Anforderung mit keiner geteilten DNS-Domäne übereinstimmt, tunnelt Secure Client sie nicht. Er kann eine Antwort synthetisieren, sodass der Resolver auf die DNS-Server der physischen Schnittstelle zurückgreift.

---

Aus diesem Grund wird die Legacy-Funktion als DNS-Fallback für Split-Tunneling bezeichnet, was kein echter Split-DNS ist. Secure Client stellt sicher, dass nur Abfragen mit Split-DNS-Domänen in den Tunnel gelangen, verlässt sich aber bei der endgültigen Auflösung auf das Verhalten des OS-Resolvers.

---

Sicherheitsbedenken: Ein privater Domänenname kann an einen öffentlichen DNS-Server weitergeleitet werden, wenn der VPN-DNS-Server NXDOMAIN zurückgibt oder nicht aufgelöst werden kann. und der Resolver versucht es erneut auf dem physischen Adapter.

True-Split-DNS: Cisco Bug-ID CSCtn14578

---

Auflösbar unter Microsoft Windows in AnyConnect 3.0(4235) und beibehalten in Secure Client 4.2+):

• Abfragen für konfigurierte Split-DNS-Domänen sind nur über den VPN-Pfad zulässig (Tunnel-DNS-Server/VPN-Adapter, je nach Plattform und Version).
• Alle anderen Abfragen sind nur über Nicht-VPN-DNS-Server (physischer Adapter) zulässig.

---

Tunnel-all und Tunnel-all DNS

Wenn Split-Tunneling deaktiviert ist (Tunnel-all-Konfiguration), wird DNS-Datenverkehr ausschließlich über den Tunnel zugelassen.

Die tunnel-all-DNS-Konfiguration (split-tunnel-all-dns enable in the group policy) sendet alle DNS-Lookups durch den Tunnel, während auch eine Form von Split-Tunneling konfiguriert ist. Der DNS-Datenverkehr wird ausschließlich über die Tunnelschnittstelle zugelassen.

Dies ist plattformübergreifend konsistent, wobei unter Microsoft Windows nur ein einziger Vorbehalt besteht. Wenn tunnel-all oder tunnel-all-DNS konfiguriert ist, lässt Secure Client den DNS-Datenverkehr ausschließlich zu den DNS-Servern zu, die auf dem sicheren Gateway konfiguriert sind (auf den VPN-Adapter angewendet). Diese Sicherheitserweiterung wurde mit True Split DNS implementiert. Wenn dies problematisch ist (z. B. muss die DNS-Aktualisierung/-Registrierung Nicht-VPN-DNS-Server erreichen), gehen Sie wie folgt vor:

1. Wenn die aktuelle Konfiguration tunnel-all lautet, aktivieren Sie Split-Exclude Tunneling. Jedes Split-Exclude-Netzwerk mit einem Host ist zulässig, z. B. eine Link-Local-Adresse.
2. Stellen Sie sicher, dass tunnel-all-DNS in der Gruppenrichtlinie nicht aktiviert ist (split-tunnel-all-dns disable).

---

Tunnel-all-DNS und Cisco Secure Client Umbrella-Modul

Wenn Split-Tunneling und tunnel-all-DNS aktiviert sind, wird DNS auf Kernel-Ebene abgefangen und blockiert, wenn es nicht die richtige VPN-Schnittstelle erreicht. Das Secure Client Umbrella-Modul (ehemals AnyConnect Roaming Security) kann in Netzwerken beeinträchtigt werden, in denen verschlüsseltes DNS nicht verfügbar ist. Dies liegt daran, dass das Modul über die LAN-Schnittstelle Standard-DNS versuchen kann, während tunnel-all-DNS DNS DNS DNS über das VPN benötigt.

---

Das Umbrella-Modul verwendet standardmäßig verschlüsselten DNS (UDP-Port 443), der im Allgemeinen nicht durch tunnel-all-DNS blockiert wird. Das Problem tritt vor allem dann auf, wenn die Verschlüsselung nicht verfügbar ist und nur DNS verwendet wird.

Empfehlung: Fügen Sie die Cisco Umbrella Resolver-Adressen zur Split-Include-Liste hinzu, wenn Sie tunnel-all-DNS mit dem Umbrella-Modul verwenden. Weitere Informationen finden Sie im Dokument Enable Tunnel All DNS for Secure Client with Umbrella Module (Dokument-ID: 224809).

---

DNS-Leistungsproblem in AnyConnect Version 3.0 behoben (4235)

Dieses Microsoft Windows-Problem tritt am häufigsten unter den folgenden Bedingungen auf:

• Einrichtung des Heimrouters, bei der DNS- und DHCP-Server dieselbe IP-Adresse verwenden (Secure Client erstellt eine erforderliche Route zum DHCP-Server)
• Eine große Anzahl von DNS-Suffixen/Domänen in der Gruppenrichtlinie.
• Eine Tunnel-All-Konfiguration.
• Bei der Namensauflösung wird ein nicht qualifizierter Hostname verwendet, sodass der Resolver mehrere DNS-Suffixe auf allen verfügbaren DNS-Servern ausprobiert.
• Der native DNS-Client versucht, DNS-Abfragen über den physischen Adapter zu senden, den der Secure Client unter tunnel-all blockiert.

---

Dies kann zu erheblichen Verzögerungen bei der Namensauflösung führen, insbesondere dann, wenn das Headend viele DNS-Suffixe weiterleitet. Der Resolver muss Suffixe und Server durchlaufen, bis er eine positive Antwort erhält.

Dieses Problem wurde mit AnyConnect 3.0(4235) und höheren Secure Client-Versionen behoben. Weitere Informationen finden Sie unter der Cisco Bug-ID CSCtq02141 und der Cisco Bug-ID CSCtn14578.

---

---

Workarounds (wenn kein Upgrade möglich ist)

Aktivieren Sie Split-Exclude-Tunneling für eine IP-Adresse, damit der physische Adapter vom lokalen DNS verwendet werden kann. Eine Adresse aus dem link-local-Subnetz 169.254.0.0/16 wird häufig verwendet, da der Datenverkehr zu diesen Adressen das VPN wahrscheinlich nicht durchläuft.

---

Nachdem Sie Split-Exclude-Tunneling aktiviert haben, aktivieren Sie den lokalen LAN-Zugriff auf dem Clientprofil oder Client, und deaktivieren Sie tunnel-all-DNS. Dies ist ein ASA/FTD-Konfigurationsbeispiel:

access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
group-policy gp_access-14 attributes
split-tunnel-policy excludespecified
split-tunnel-network-list value acl_linklocal_169.254.1.1
split-tunnel-all-dns disable
exit

---

Clientprofil-XML:

<LocalLanAccess UserControllable="true">true</LocalLanAccess>

---

Sie können dies auch in der Secure Client-GUI aktivieren: Voreinstellungen → Aktivieren von Allow local (LAN) access when using VPN

1. Verwenden Sie vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDNs) anstelle von unqualifizierten Hostnamen.
2. Verwenden Sie eine andere IP-Adresse für den DNS-Server an der physischen Schnittstelle (separat von DHCP im gleichen Subnetz).

---

DNS mit Split Tunneling auf verschiedenen Client-Betriebssystemen

Verschiedene Client-Betriebssysteme verarbeiten DNS unterschiedlich mit Split-Tunneling (ohne Split-DNS) für Secure Client. In diesem Abschnitt werden diese Unterschiede beschrieben.

---

Microsoft Windows (Windows 10 und Windows 11)

Unter Windows werden die DNS-Einstellungen pro Netzwerkschnittstelle vorgenommen. Mit Split-Tunneling können DNS-Abfragen auf DNS-Server mit physischen Adaptern zurückgreifen, nachdem sie auf dem VPN-Tunneladapter fehlschlagen. Wenn Split-Tunneling ohne Split-DNS verwendet wird, können sowohl die interne als auch die externe Auflösung verwendet werden, da der Resolver auf externe DNS-Server zurückgreifen kann. In Version 4.2 gab es nach der Behebung des Fehlers für die Cisco Bug-ID CSCuf0785 eine wesentliche Änderung beim Secure Client für Windows. Dieses Verhalten ist in Secure Client 5.x unverändert.

---

---

Tunnel-all-Konfiguration (und Split-Tunneling mit aktiviertem Tunnel-all-DNS)

Pre-Secure Client 4.2 (AnyConnect 4.1 und frühere Version):

• Es sind nur DNS-Anfragen an DNS-Server zulässig, die gemäß der Gruppenrichtlinie konfiguriert wurden (Tunnel-DNS-Server).
• Der Secure Client-Treiber antwortet auf alle anderen Anforderungen ohne diesen Namen.
• Die DNS-Auflösung kann nur Tunnel-DNS-Server verwenden.

---

Secure Client 4.2 und höher:

• DNS-Anfragen an DNS-Server sind zulässig, wenn sie vom VPN-Adapter stammen und über den Tunnel gesendet werden.
• Alle anderen Anfragen erhalten keinen solchen Namen; Auflösung nur über den VPN-Tunnel.
• Vor der Cisco Bug-ID CSCuf07885 beschränkte Secure Client Ziel-DNS-Server. Nach diesem Fix wird eingeschränkt, welche Netzwerkadapter DNS-Anfragen initiieren können.

---

Split-include-Konfiguration (Tunnel-all-DNS deaktiviert, kein Split-DNS)

Der Secure Client-Treiber beeinträchtigt den nativen DNS-Resolver nicht. Die Auflösung entspricht der Reihenfolge der Netzwerkadapter. Secure Client ist der bevorzugte Adapter, wenn das VPN verbunden ist.

---

Zunächst wird eine DNS-Abfrage über den Tunnel gesendet. Wenn keine Lösung gefunden wird, kann der Resolver die öffentliche Schnittstelle testen. Die Split-Include-Zugriffsliste muss das Subnetz enthalten, das Tunnel-DNS-Server in Versionen vor 4.2 abdeckt. Ab Secure Client 4.2 werden die Host-Routen für Tunnel-DNS-Server automatisch als Split-Include-Netzwerke (sichere Routen) hinzugefügt, sodass für die Split-Include-ACL keine expliziten Tunnel-DNS-Server-Subnetze mehr erforderlich sind.

---

Split-exclude-Konfiguration (Tunnel-all-DNS Disabled, kein Split-DNS)

Dasselbe Resolververhalten wie bei split-include, tunnel first und dann beim Fallback der öffentlichen Schnittstelle. Die Split-Exclude-Zugriffsliste darf nicht das Subnetz für den/die Tunnel-DNS-Server enthalten. Ab Secure Client 4.2 verhindern die automatischen Hostrouten für Tunnel-DNS-Server häufige Split-Exclude-Fehlkonfigurationen.

---

Split-DNS (Tunnel-all-DNS Disabled, Split-include Configured)

Split-DNS unter Windows erfordert Split-Include-Tunneling (Split-Tunnel-Policy-Tunnel wurde angegeben). Für die Split-DNS-Konfiguration werden nur Split-Exclude-Tunnel-Richtlinien nicht unterstützt.

Vorsicherer Client 4.2:

• Split-DNS-Domänenabfragen: Nur DNS-Server dürfen getunnelt werden. keinen solchen Namen, wenn sie an andere Server gesendet werden.
• Nicht-Split-DNS-Domänenabfragen: Nur für andere DNS-Server zulässig; Kein solcher Name, wenn über Tunnel versucht.

---

Secure Client 4.2 und höher (True-Split-DNS unter Windows):

• Split-DNS-Domänenabfragen: Zugriff auf einen DNS-Server nur, wenn dieser vom VPN-Adapter stammt. Abfragen von der öffentlichen Schnittstelle erhalten keinen solchen Namen, um die Tunnelverwendung zu erzwingen.
• Nicht-Split-DNS-Domänenabfragen: Jeder DNS-Server darf nur verwendet werden, wenn er vom physischen Adapter stammt. Abfragen vom VPN-Adapter erhalten keinen solchen Namen, um die Auflösung der öffentlichen Schnittstelle zu erzwingen.

---

Split-DNS mit Split-exclude Tunneling (Secure Client 5.x)

Die Administratordokumentation für Secure Client 5.x fügt Split-DNS für Split-Exclude-Konfigurationen hinzu. Weitere Informationen zu den Headend- und Richtlinienanforderungen finden Sie im Secure Client 5.x Administrator Guide — Configure Split DNS for Split Exclude Tunneling. Durchsetzungsregeln auf Betriebssystemebene gelten auch dann, wenn Split-DNS aktiviert ist.

---

Verschlüsselter DNS (DoH/DoT) unter Windows

Anwendungen oder Betriebssystemfunktionen, die DNS über HTTPS (DoH) oder DNS über TLS (DoT) verwenden, können den Windows-Stub-Auflösungspfad umgehen, den Secure Client filtert. Wenn Split-DNS für bestimmte Apps fehlerhaft zu sein scheint, aber in einem Browser funktioniert, überprüfen Sie, ob diese Apps verschlüsseltes oder benutzerdefiniertes DNS verwenden. Beim Standard-Split-DNS-Test sollte der OS-Resolver (Browser, Ping) und nicht NSLookup/dig verwendet werden.

---

MacOS

Unter macOS sind die DNS-Einstellungen global (nicht pro Schnittstelle). Wenn Split-Tunneling ohne Split-DNS verwendet wird, können DNS-Abfragen häufig nicht wie erwartet auf DNS-Server außerhalb des Tunnels zugreifen. Sie können nur interne Namen auflösen, nicht jedoch externe Namen über den öffentlichen Pfad. Dies ist dokumentiert in Cisco Bug-ID CSCtf2026 und Cisco Bug-ID CSCtz86314.

---

Problemumgehungen:

• Geben Sie unter der Gruppenrichtlinie eine externe DNS-Server-IP an, und verwenden Sie FQDNs für interne Abfragen.
• Wenn externe Namen durch den Tunnel auflösbar sind, deaktivieren Sie Split-DNS unter Erweitert > Split-Tunneling, indem Sie DNS-Namen aus der Gruppenrichtlinie entfernen, und verwenden Sie FQDNs für interne Abfragen.

---

Split DNS auf macOS wird ab AnyConnect 3.1 unter folgenden Bedingungen unterstützt:

• Split-DNS für beide IP-Protokolle aktiviert (erfordert ASA 9.0+/gleichwertiges FTD) oder
• Split DNS ist für ein IP-Protokoll aktiviert und Client Bypass Protocol ist für das andere aktiviert, ohne Adresspool für das umgeleitete Protokoll (oder ohne IPv6-Pool auf ASA-Versionen vor 9.0).

---

---

Tunnel-all-Konfiguration (und Split-Tunneling mit aktiviertem Tunnel-all-DNS)

Wenn Secure Client verbunden ist, verbleiben nur Tunnel-DNS-Server in der System-DNS-Konfiguration. Anfragen werden nur an Tunnel-DNS-Server weitergeleitet.

---

Split-include/Split-exclude (Tunnel-all-DNS Disabled, no Split-DNS)

Der sichere Client beeinträchtigt den nativen Resolver nicht. Tunnel-DNS-Server werden gegenüber öffentlichen Resolvern bevorzugt, sodass der erste Abfrageversuch über den Tunnel läuft. Da DNS unter macOS global ist, verwenden Abfragen nicht immer zuverlässig öffentliche DNS außerhalb des Tunnels (Cisco Bug-ID: CSCtf2026).

Ab Secure Client 4.2 werden Hostrouten für Tunnel-DNS-Server automatisch als sichere Routen hinzugefügt.

---

Split-DNS (Tunnel-all-DNS Disabled, Split-include Configured)

True Split DNS (vergleichbar mit Windows) gilt in folgenden Fällen:

• Split-DNS ist für IPv4 und IPv6 aktiviert oder
• Split-DNS ist für ein Protokoll aktiviert, und für das andere Protokoll ist kein Client-Adresspool vorhanden.

---

True-Split-DNS bedeutet, dass Split-DNS-Domänen nur über den Tunnel aufgelöst werden und nicht an externe Resolver weitergeleitet werden.

Wenn Split-DNS nur für ein Protokoll aktiviert ist und eine Client-Adresse für das andere Protokoll zugewiesen ist, wird nur der DNS-Fallback für Split-Tunneling erzwungen: Der Secure Client ermöglicht übereinstimmende Abfragen über den Tunnel (andere Abfragen können abgelehnt werden, um Failover zu erzwingen), kann jedoch nicht vollständig verhindern, dass Abfragen von Split-DNS-Domänen über den öffentlichen Adapter in den unverschlüsselten Zustand gesendet werden.

Plattformunterstützung (Administratoranleitung für Secure Client): Full Split DNS wird unter Windows und MacOS unterstützt. Linux bietet nur eingeschränkte Unterstützung (siehe Abschnitt zu Linux).

---

Linux 

Tunnel-all-Konfiguration (und Split-Tunneling mit aktiviertem Tunnel-all-DNS)

Wenn Secure Client verbunden ist, werden nur Tunnel-DNS-Server in der System-DNS-Konfiguration beibehalten.

---

Split-include/Split-exclude (Tunnel-all-DNS Disabled, No Split-DNS)

Der sichere Client beeinträchtigt den nativen Resolver nicht. Tunnel-DNS-Server werden bevorzugt; der erste Lösungsversuch geht über den Tunnel.

---

Split-DNS (Tunnel-all-DNS Disabled, Split-include Configured)

Wenn Split-DNS aktiviert ist, wird nur der DNS-Fallback für Split-Tunneling unter Linux erzwungen:

• Secure Client ermöglicht Split-DNS-Domain-Abfragen über den Tunnel.
• Andere Abfragen können eine Weigerung erhalten, ein Failover auf öffentliche DNS zu fördern.
• Der Secure Client kann Split-DNS-Domänenabfragen nicht vollständig durchsetzen, da sie nie unverschlüsselt über den öffentlichen Adapter gesendet werden.

Der Administratorleitfaden für Secure Client enthält Hinweise zu eingeschränktem Split-DNS unter Linux: Nur getunnelte DNS-Anfragen unterliegen vollständig der Split-DNS-Richtlinie. Einige Abfragen außerhalb des Tunnels können die Split-DNS-Richtlinie nicht erfüllen.

---

Linux VMs und Container

Secure Client unterstützt ein benutzerdefiniertes Tunnel-from-Any-Source-Attribut, sodass Pakete mit jeder Quelladresse im Split-Include- oder Split-Exclude-Modus innerhalb von VM-Instanzen oder Docker-Containern geroutet werden können. Konfigurationsdetails finden Sie im Administratorhandbuch für Secure Client 5.x.

---

Apple iOS (iPhone und iPad)

Das iOS-Verhalten unterscheidet sich von macOS und ist nicht identisch mit Windows. Wenn Split-Tunneling ohne Split-DNS konfiguriert wird, verwenden DNS-Abfragen in der Regel den globalen DNS-Server, der für das Gerät definiert ist, und nicht das gleiche Fallback-Muster wie Windows.

---

Praktische Auswirkungen: Split-DNS-Domäneneinträge sind häufig für eine zuverlässige Auflösung interner Namen erforderlich, wenn Split-Tunneling ohne Split-DNS verwendet wird.

Verlaufskorrigierung: Cisco Bug-ID CSCtq09624 - (AnyConnect für iOS 2.5.4038 und höher) Der aktuelle Secure Client für iOS erfüllt dieselben allgemeinen Anforderungen. Sie können Split-DNS für interne Domänen konfigurieren, wenn Sie Split-Include/Split-and-Exclude verwenden, ohne auf Windows-Fallbacks zurückzugreifen.

Apple behandelt dies als gestaltetes Verhalten. erwarten keine .local Auflösung durch Standard Split DNS unter iOS. Unter iOS unterscheidet sich das Split-DNS-Verhalten von Secure Client auch von anderen Plattformen, wenn Split-Tunneling mit bestimmten Split-DNS-Listenkonfigurationen kombiniert wird. Informationen zu iOS-spezifischen Richtlinienkombinationen (split-dns none, default-domain usw.) finden Sie im Abschnitt "Secure Client Administrator Guide" unter Split DNS Resolution Behavior with Split Tunnel.

---

Dynamic Split Tunneling und DNS (Secure Client 4.5+)

Dynamisches Split-Tunneling löst FQDNs zur Verbindungszeit oder bei Bedarf auf und passt Routing und Filter für den Datenverkehr zu bestimmten Domänen an. Diese wird ohne statische IP-Listen im Tunnel eingeschlossen oder aus diesem ausgeschlossen.

---

Funktion	Beschreibung
Dynamischer Split-Ausschluss	Domänen (example.com) werden zur Laufzeit aus dem Tunnel ausgeschlossen, wenn Anwendungen diese Namen auflösen.
Dynamische Aufteilung:	Domänen werden dynamisch in den Tunnel eingeschlossen.
Verbesserte dynamische Aufteilung	Kombinierte Ein-/Ausschlussdomänenlisten mit Prioritätsregeln (z. B. example.com ausschließen, aber mail.example.com einschließen).

---

Dynamisches Split-Tunneling nutzt die DNS-Auflösung, um Routing-Änderungen vorzunehmen. Die Konfiguration erfolgt über benutzerdefinierte Secure Client-Attribute am Headend (z. B. dynamic-split-exclude-domains, dynamic-split-include-domains).

---

Dynamisches Split-Tunneling gilt für Tunnel-All- und Split-Exclude- (dynamisches Ausschließen) oder Split-Include-Richtlinien (dynamisches Einschließen). Sie ersetzt keine Split-DNS-Richtlinie, ergänzt sie jedoch: DNS-Kontrollelemente aufteilen, deren Abfragen getunnelt werden; Dynamisches Split-Tunneling steuert, welcher IP-Datenverkehr auf der Grundlage aufgelöster Namen getunnelt wird. Weitere Informationen finden Sie in den Konfigurationsdetails: Konfigurieren von dynamischem Split-Tunneling und im Administratorleitfaden für Secure Client 5.x.

---

Split exclude failover (Secure Client 5.x): Optionales benutzerdefiniertes Attribut SplitExcludeFailoverEnabled leitet Datenverkehr über das VPN weiter, wenn der öffentliche Pfad keine Verbindung mit Split-Exclude-Zielen hat. Informationen zur benutzerdefinierten Attributeinrichtung finden Sie im Administratorhandbuch.

---

Verlaufskunden-Versionen (Referenz)

Die nächste Tabelle gilt nur für Legacy-Bereitstellungen, auf denen noch veraltete Clients ausgeführt werden:

---

Version	Relevanz
AnyConnect 2.4	Bestmöglicher Split-DNS-Fallback eingeführt
AnyConnect 2.5 (iOS)	Cisco Bug-ID: CSCtq09624 iOS-DNS-Ausrichtung
AnyConnect 3.0 (4235)	True Split DNS unter Windows DNS Performance Fixes
AnyConnect 3.1 (MacOS)	Split-DNS-Unterstützung unter IPv4/IPv6-Bedingungen
AnyConnect 4.2	Cisco Bug-ID: passerbasierte Durchsetzung von CSCuf0785; Automatische Tunnel-DNS-Host-Routen

---

Stellen Sie Secure Client 5.x auf allen unterstützten Plattformen für aktuelle Fehlerbehebungen und Funktionen bereit.

---

Zugehörige Fehlerinformationen

• Cisco Bug-ID: CSCtn14578 - True Split DNS (kein Fallback) - Windows, 3.0(4235)+
• Cisco Bug-ID: CSCtq02141 - DNS-Verzögerung, wenn sich das ISP-DNS im gleichen Subnetz wie die öffentliche IP befindet
• Cisco Bug-ID: CSCuf0785 - Windows DNS: durch Adapter einschränken, nicht Zielserver - 4.2+
• Cisco Bug-ID: CSCtf2026 - macOS Split Tunnel DNS im Gegensatz zu Windows
• Cisco Bug-ID: CSCtz86314 - macOS-Split-DNS-Abfragen nicht über Tunnel gesendet
• Cisco Bug-ID: CSCtq09624 - iOS-Split-Tunnel-DNS-Verhalten
• Cisco Bug-ID: CSCts89292 - iOS ignoriert .lokale DNS-Domänen
• Cisco Bug-ID: CSCsv34395 - Support für FQDN-Proxy zum DHCP-Server

---

Zugehörige Informationen

• Untersuchen des Verhaltens von DNS-Abfragen und der Domänennamenauflösung (Cisco.com) — Dokument-ID: 116016
• Administratorleitfaden für Cisco Secure Client 5.x - VPN-Zugriff konfigurieren/DNS aufteilen
• ASA/AnyConnect Dynamic Split Tunneling konfigurieren - Dokument-ID 215383
• Tunnel Alle DNS für sicheren Client mit Umbrella-Modul aktivieren — Dokument-ID 224809
• Interop zwischen AnyConnect und dem OpenDNS Roaming-Client — Dokument-ID 200395
• Technischer Support und Downloads von Cisco

---

Revisionsverlauf

Revision	Datum	Kommentare
4.0	28. Juli 2026	Vollständige inhaltliche Aktualisierung: Secure Client-Branding, Plattformaktualisierung, dynamisches Split-Tunneling, Umbrella/tunnel-all-DNS, Tippfehlerkorrekturen und Konfigurationskorrekturen, zugehörige Links
3.0	23. Mai 2024	Rezertifizierung (Cisco.com)
1.0	12. Juni 2014	Erstveröffentlichung

---

Dokument gilt für

• Cisco Secure Client (einschließlich AnyConnect) - Windows, MacOS, Linux, iOS
• Richtlinien für Cisco Secure Firewall ASA und FTD Remote Access VPN Group

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
4.0	10-Aug-2026	Aktualisierte Einführung, Rechtschreibung, Grammatik, feste URLs, eingefügte horizontale Linien in separate Abschnitte zur besseren Lesbarkeit und korrigierte CCW-Fehler.
3.0	23-May-2024	Rezertifizierung
1.0	12-Jun-2014	Erstveröffentlichung