Suppose you have a small windows domain configured as follows:
- domain name is
ad.example.com
(as per these guidelines) DC1
is at 10.10.10.3DC2
is at 10.10.10.4DC1
andDC2
are running the AD-integrated DNS and DHCP Server roles- AD DHCP is configured with an address pool from 10.10.10.50-99
- AD DHCP is issuing client leases with the
006 DNS Servers
option set to the addresses ofDC
's running AD-integrated DNS (i.e. 10.10.10.3 and 10.10.10.4) - AD-integrated DNS servers have google's 8.8.8.8 configured as a forwarder
- the 10.10.10.0/24 subnet is connected to the internet via a Cisco ASA with internal address 10.10.10.1
- the ASA is the gateway for the 10.10.10.0/24 network
vpn.example.com
is a public DNS entry that resolves to the external IP address of the ASA- Remote Windows computers connect to the 10.10.10.0/24 network through the ASA using the Cisco IPSec VPN Client pointed at
vpn.example.com
- the Remote Windows computers are issued IP addresses from 10.10.10.200-10.10.10.254
- split-tunneling is enabled such that only 10.10.10.0/24 traffic is tunneled (the highest available upstream bandwidth at this site is only 2Mbps)
For Windows laptops that sometimes connect via VPN, how should their DNS be configured?
If a mobile Windows laptop just accepts a random public DNS server address, it will send DNS queries for _ldap._tcp.site._sites.ad.example.com
to the random public DNS server when the tunnel is not active. Is this standard practice? Somehow that seems like a bad idea.
On the other hand, if a Windows laptop is configured with only the internal DNS servers 10.10.10.3 and 10.10.10.4 (as sternly recommended here) then the VPN Client cannot resolve vpn.example.com
to make the VPN connection -- it's a chicken-and-egg problem.
Is there something fancier that ought to be going on with DNS on the Windows laptops connecting by VPN?
How much control does a VPN client have over Windows DNS lookups? Should DNS split tunneling be enabled?
Enabling DNS split-tunneling seems to mean we're relying on the VPN Client to intercept DNS queries like _ldap._tcp.site._sites.ad.example.com
to prevent them from being sent to the public DNS server. Is the DNS split-tunneling in VPN clients strict and reliable? For that matter, it seems like some applications might just ignore the VPN adapter altogether and attempt to resolve Windows domain addresses using the public DNS server on the physical adapter. Is this something I should be concerned with?
The other option -- sending all DNS lookups through the tunnel to the AD-integrated DNS servers -- seems like a bad idea for two reasons: 1) The tunnel is likely to be much higher latency than a public DNS server when the user is many hops from the ASA. 2) It seems like names will resolve to IP addresses that correspond to servers in close proximity to the ASA rather than the remote computer. If I understand this correctly, that means problems accessing media on CDNs. (Edit: Here's an example of someone experiencing just this problem.)
For Windows laptops that sometimes connect via VPN, how should their DNS be configured?
The Network Adapter should be configured with DNS local to itself, either ISP or Home Router DNS. The VPN Adapter should receive the AD DNS servers via DHCP you have listed when connecting to the VPN. In addition, DHCP should be handing out the default domain name (domain.local) to support the answer to your next question:
How much control does a VPN client have over Windows DNS lookups? Should split tunneling be enabled?
Using fully qualified dns names (FQDN) from the remote laptop will ensure the request is associated with the VPN adapter and sent to the DNS servers on that adapter. If you rely on just hostnames then your laptop will want to use the Network Adapters DNS servers.
Using split-tunneling is a matter of security preference. With it enabled, it is possible for the laptop to access both their local network and the VPN simultaneously where there are endless possibilities for compromise. With split tunneling turned off, the laptop cannot access TCP/IP on the physical adapter and so will lose access to network printers and shares while maintaining a 'tunnel' just to the VPN endpoint.