This document describes how different Operating Systems (OSs) handle Domain Name System (DNS) queries and the affects on domain name resolution with Cisco AnyConnect and split or full tunneling.
When you use split-include tunneling, you have three options for DNS:
In all cases, the DNS queries that are defined to move through the tunnel go to any DNS servers that are defined on the ASA. If there are no DNS servers defined on the ASA, then the DNS settings are blank for the tunnel. If you do not have split DNS defined, then all of the DNS queries are sent to the DNS servers that are defined by the ASA. However, the behaviors that are described in this document can be different, dependent upon the Operating System (OS).
AnyConnect Release 2.4 supports split DNS Fallback (best effort split DNS), which is not the true split DNS found in the legacy IPsec client. If the request matches a split DNS domain, AnyConnect allows the request to be tunneled in to the ASA. If the server cannot resolve the host name, the DNS resolver continues and sends the same query to the DNS server that is mapped to the physical interface.
On the other hand, if the request does not match any of the split DNS domains, AnyConnect does not tunnel it in to the ASA. Instead, it builds a DNS response so that the DNS resolver falls back and sends the query to the DNS server that is mapped to the physical interface. That is why this feature is not called split DNS, but DNS fallback for split tunneling. Not only does AnyConnect assure that only requests that target split DNS domains are tunneled in, it also relies on the client OS DNS resolver behavior for host name resolution.
This raises security concerns due to a potential private domain name leak. For example, the native DNS client can send a query for a private domain name to a public DNS server specifically when the VPN DNS name server could not resolve the DNS query.
Refer to Cisco bug ID CSCtn14578, currently resolved on Microsoft Windows only, as of Version 3.0(4235). The solution implements true split DNS: it strictly queries the configured domain names that match and are allowed to the VPN DNS servers. All other queries are only allowed to other DNS servers, such as those configured on the physical adapter(s).
When split tunneling is disabled (the tunnel all configuration), DNS traffic is allowed strictly via the tunnel. The tunnel all DNS configuration (configured in the group policy) sends all of the DNS lookups through the tunnel, along with some type of split tunneling, and DNS traffic is allowed strictly via the tunnel.
This is consistent across platforms with one caveat on Microsoft Windows: when any tunnel all or tunnel all DNS is configured, AnyConnect allows DNS traffic strictly to the DNS servers that are configured on the secure gateway (applied to the VPN adapter). This is a security enhancement implemented along with the previously mentioned true split DNS solution.
If this proves problematic in certain scenarios (for example, DNS update/registration requests must be sent to non-VPN DNS servers), then complete these steps:
This Microsoft Windows issue is mostly prevalent under these conditions:
This issue is due to the native DNS client that attempts to send DNS queries via the physical adapter, which AnyConnect blocks (given the tunnel-all configuration). This leads to a name resolution delay that can be significant, especially if a large number of DNS suffixes are pushed by the headend. The DNS client must walk through all of the queries and available DNS servers until it receives a positive response.
This problem is resolved in AnyConnect Version 3.0(4235). Reference Cisco bug IDs CSCtq02141 and CSCtn14578, along with the introduction to the previously-mentioned true split DNS solution, for more information.
If an upgrade cannot be implemented, then here are the possible workarounds:
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
<LocalLanAccess UserControllable="true">true</LocalLanAccess>
Different OSs handle DNS searches in different ways when used with split tunneling (without split DNS) for AnyConnect. This section describes those differences.
On Microsoft Windows systems, DNS settings are per-interface. If split tunneling is used, DNS queries can fall back to the physical adaptor DNS servers after they fail on the VPN tunnel adaptor. If split tunneling without split DNS is defined, then both internal and external DNS resolution works because it falls back to the external DNS servers.
On Macintosh systems, the DNS settings are global. If split tunneling is used, but split DNS is not used, it is not possible for the DNS queries to reach DNS servers outside of the tunnel. You can only resolve internally, not externally.
This is documented in Cisco bug IDs CSCtf20226 and CSCtz86314. In both cases, this workaround should resolve the issue:
The split DNS case has been resolved in AnyConnect Version 3.1. However, you must ensure that one of these conditions is met:
The iPhone is the complete opposite of the Macintosh system and is not similar to Microsoft Windows. If split tunneling is defined but split DNS is not defined, then DNS queries exit through the global DNS server that is defined. For example, split DNS domain entries are mandatory for internal resolution. This behavior is documented in Cisco bug ID CSCtq09624 and is fixed in Version 2.5.4038 for the Apple iOS AnyConnect client.