4

Split DNS ostensibly allows a remote device accessing a LAN using VPN to direct DNS queries for internal domain names to internal DNS servers while queries for public domain names are directed to public DNS servers local to the remote device. For Cisco ASA, the operative command that claims to achieve this is split-dns.

When you establish a remote access VPN connection using a Windows machine, the VPN connection shows itself as a separate network adapter (at least for the Cisco clients I have experience with). The method that Windows uses to decide which network adapter and DNS server to use cannot by itself enforce that all internal DNS queries are sent to the the VPN adapter and that all public DNS queries are sent to the physical adapter. In fact, Windows will attempt the same DNS query on a different adapter if it doesn't receive a response from the first one within one second. Furthermore, it seems that Windows might even choose to send a DNS query for an internal domain to the physical adapter which only has public DNS servers associated with it.

So, if Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers? Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter? If so, how, exactly, does that work?

Improve this question
0

2 Answers 2

Reset to default
7

Experiment

There is a lot of conflicting information about what actually happens on a Windows client when using split-dns. So much that I decided to gather some evidence and see where it points. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. Here is a diagram of the test setup:

enter image description here

With the packet captures running, I initiated DNS resolution on the client. To do so, I pressed enter on srv1.internal.example.com in Google Chrome. Here are the resulting packet captures adjusted to sync their clocks and merged together.

Packets with IDs starting with "C" are from the Windows [C]lient.
Packets starting with "A" are from the [A]SA.

enter image description here

Analysis

In orange, we can see four separate DNS queries that are trying to be made by Windows/Chrome: The destinations of the four DNS queries are as follows:

  • 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C69)
  • 10.10.10.3 - the first DNS Server associated with the VPN Adapter (packet C70)
  • 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C78)
  • 10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet C81)

What is most revealing is that the two DNS queries apparently sent to 8.8.8.8 appear at the ASA in packets A95 and A105 with source and destination IPs translated from external addresses to internal addresses. The responses from the DNS server for those translated queries are in A97 and A106 which are themselves then translated to external addresses again in packets C74 and C84, respectively. These DNS queries ultimately succeed.

Answers to the original questions

If Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers?

Based on the above evidence, the VPN client seems to intercept DNS queries that match the domain configured using the split-dns value command on non-VPN adapters.

Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter?

The fancy part that was missing is that the VPN client performs a sort of network address translation to make it appear to Windows that DNS queries for the internal domain are being serviced by the public DNS server to which Windows sent its request. In fact those requests are serviced by the internal DNS server.

I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS.

Notes on Adapter Binding Order

I tinkered with the oft-cited adapter binding order. Here is what I found. The adapter order seems to have no impact on the efficacy of the VPN Client's ability to intercept and translate DNS queries for internal domains.

Putting the VPN adapter highest in the binding order seems to result in Windows sending DNS requests only to the DNS servers on the VPN adapter initially. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. This creates a noticeable and irritating delay when browsing.

Based on this, it seems that in split DNS configurations the VPN adapter should not be the highest priority.

Improve this answer
2

If you pay close attention to what the VPN software installs, you'll find a shim high up in the network stack that allows the software to intercept DNS lookups long before any routing has taken place.

(In linux it can be done by inserting an additional NSS module. But I've not used the cisco or juniper linux clients in decades.)

Improve this answer
1
  • So I did an experiment to try to confirm the presence of a shim. The results certainly suggest the presence of a shim for all network adapters. I'd appreciate your comments on my analysis of the results if you have a chance to review.
    – alx9r
    Commented Mar 13, 2014 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.