Slow DNS resolving through AC and multiple domains

[Johan Leuyckx]

Hi

Using AC for "tunnel all" ipsec vpn. DNS resolving is slow when host is not in default domain. We have 3 domains. In case we need to resolve a name in domain3. This is what happens.

E.g. ping hostA (hostA resides in domain3, so hostA.domain3 is the fqdn)

dns query for hostA through vpn results in "no such name"

then silence for 14 seconds (in fact following DNS rules, it waits 2s tries again, waits another 2s, then tries with another interface which is not the vpn interface and due to tunnel all, there is no reply and then dns resolver waits 6 seconds.... bla bla bla)

dns query for hostA.domain1 results in "no such name"

silence for 14 seconds

dns query for hostA.domain2 results in "no such name"

silence for 14 seconds

dns query for hostA.domain3 results in "x.x.x.x"

FINALLY, reply from my host after 45 seconds !!!

Is anyone else seeing this behavior? According TAC, this is "normal behavior". The workaround is Split Tunnel with Local LAN access. Then in stead of waiting for a timeout on the 2nd and 3rd queries, we get a "no such name" from the dns server configured on the local interface and the DNS resolver service moves on to the next suffix for the search domain.

Can you see our problem?

We tried with Windows native l2tp ipsec and there we don't have the issue!

Regards,

Johan

[Tommy Alexander]

Hi,

The problem you mention should only happen in the case that the DHCP server is also the DNS server.

Due to the requirement for DHCP server ip address to be routed through the physical adapter, thus the DNS queries over physical adapter is attempted, but we block those DNS queries thus the timeout of ~ 14 seconds each time we switch to a new suffix.

There is a enhancement request to support full split DNS support instead of DNS fallback that we currently support.

The bug id for that is: CSCtn14578

You can look it using the bug toolkit on CCO:

http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl

Tom

[Christopher83]

Hey Johan,

We're having the same issue, but unfortunately don't have access to the bug tracking tool.  Did you ever get anywhere with this or find any workarounds?

Chris

[uwkleinh]

The defect mentioned by Tom above is a feature enhancement, which we implemented with 3.0.4235 that may not be visible externally to Cisco.

However one of the issues with delayed name resolution is that if the DNS server IP assigned to the physical adapter via DHCP (or statically configured) is the same as the DHCP server IP, then the OS may be delaying the subsequent DNS queries by 15 seconds.

This can be verified by capturing traffic on the AnyConnect adapter of the PC.

With the fix of CSCtn14578 we are now able to force the dns resolution quicker through the tunnel instead of relying on the underlying OS to send subsequent queries. As said, with newer clients you would not run into this issue but check out CSCtq02141 which describes the problem more.

Hope this helps,

Uwe