Our VPN is configured to send the domain-name-server and domain-search parameters from our DHCP server to connected clients.

However, we've been experiencing issues with the domain name resolution - specifically, the domain-search suffix(es) is not being added to the hostname when using software like MSTSC or even nslookup. They are at least looking on the right DNS server, though, and the FQDN is resolved correctly - it's just when I try hostname lookups that it isn't appending the suffix.

What is odd is that a ping for any-hostname will get a response from any-hostname.domain.

I know that ping implements its own resolver separate from nslookup (and other software) - but don't understand how it can know about the DNS suffix when the other software doesn't.

Also, when I check the connection configuration with ipconfig - the correct DNS suffix is listed under the PPP connection - so I know that it's being sent from DHCP over the VPN.

Any suggestions?

2 Answers 2


I believe lan connection of the client has a higher priority/metric than the local one. That is normal. It depends on the name resolution order. Did you check the TCP/IP settings (Advanced settings) in the client? Check the metric of the gateway, DNS settings (DNS tab), and the name resolution order and there are other services too. IP/v6 also provides techniques.

Most importantly, there is a specific setting known as the VPN Binding Order. Imo, this could be the issue.

You could try the solution below. This is copied directly from this Microsoft article.

  1. Click Start, type regedit32 in the Open box, and then click OK.
  2. Click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage
  3. In the right pane, double-click Bind.
  4. In the Value data box, select the "\Device\NdisWanIp" item, press CTRL+X, click the top of the list of devices, and then press CTRL+V.
  5. Click OK, and then quit Registry Editor.
  6. Restart the remote system.

Note: If you use an AD enabled network, you may be able to use a policy.

  • hmm - the VPN connection has no DNS settings tab from the network adapter settings...
    – HorusKol
    May 30, 2016 at 10:31
  • also - it is resolving FQDN via the VPN DNS - just not performing dns search with suffix for hostname lookups
    – HorusKol
    May 30, 2016 at 10:35
  • So, you are saying that, if you search for a hostname in the connected VPN, it does not add suffix? nslookup does not do this? Does it fail or what happens? Of course ping can use NetBIOS. This is how ping works: blogs.msdn.microsoft.com/nitinsingh/2013/06/24/…
    – Epoxy
    May 30, 2016 at 10:59
  • yes, that is what is happening - nslookup is not adding the suffix, it just says "cannot resolve 'hostname'" - but it will resolve 'hostname.domain.on.vpn'
    – HorusKol
    May 30, 2016 at 11:24
  • Yes, this is normal. Nslookup assumes your query is about a local domain in a private network. It does not work like ping. You need to edit the advanced properties of the VPN connection on remote end and add the suffix. Otherwise, it does not know or get confuse. If you want to automate this thing, you may be able to use something such as Windows Connection Manager Administration Kit
    – Epoxy
    May 30, 2016 at 12:28

My problem was similar but slightly different; ping didn't work either. I was able to fix it with a registry setting that I assume would affect non-VPN lookups as well:


For some reason, Active Directory DHCP doesn't support this option (119), so you have to either use Group Policy or the registry.

Related: http://support.microsoft.com/kb/275553

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .