13

Ok, so here's the setup. Laptop is connected to our company VPN (Juniper Network Connect 7.2.0). There are two DNS Search suffix's (domain1.com, domain2.local). From that laptop, while connected, nslookup polls the correct DNS server, returns the right IP. Pinging the IP works fine. Pinging the FQDN works fine. Pinging the unqualified domain name appears to be both using the hostname.domain.com suffix (even though that doesn't exist), and appears to be using the results from the local DNS server rather than the VPN DNS server.

More detail:

c:\> nslookup hostname
Server: hostname.domain2.local
Address: 10.0.0.10

Non-authoritative answer:
Name: hostname.domain2.local
Address: 10.0.0.10

c:\> nslookup hostname.domain2.local
Server: hostname.domain2.local
Address: 10.0.0.10

Non-authoritative answer:
Name: hostname.domain2.local
Address: 10.0.0.10

C:\> ping hostname

Pinging hostname.domain1.com [EXTERNAL/WRONG_IP] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for EXTERNAL/WRONG_IP:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\> ping hostname.domain2.local

Pinging hostname.domain2.local [10.0.0.10] with 32 bytes of data:
Reply from 10.0.0.10: bytes=32 time=50ms TTL=128
Reply from 10.0.0.10: bytes=32 time=50ms TTL=128
Reply from 10.0.0.10: bytes=32 time=47ms TTL=128
Reply from 10.0.0.10: bytes=32 time=50ms TTL=128

Ping statistics for 10.0.0.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 50ms, Average = 49ms

So here's what I've tried so far:

  1. ipconfig /flushdns
  2. netsh int ip reset all
  3. Verified that the network adapters are in the right priority order in the advanced settings
  4. Verified that the TCP/IP routes are correct
  5. Verified that the hostname isn't in the hosts file.

So... does anyone know why it still seems to be using the wrong DNS server?

9
  • Have you checked if a static route is configured? What do the A records look like? Take a look at the packets and figure out what server is resolving for the 'ping hostname'. You said VPN DNS, are you on a VPN? Are you split tunneling?
    – rtf
    Jul 23, 2012 at 19:01
  • Please clarify, are you saying that the name hostname.domain1.com doesn't exist? What order do the suffixes appear in the DNS suffix search list (ipconfig /all)? Jul 24, 2012 at 0:22
  • Is the hostname in question special in any way? For example, is it the NetBIOS name of the client, the domain, or perhaps one of the domain controllers? Jul 24, 2012 at 0:24
  • @HarryJohnston, the hostname in question is one of the domain controllers for domain2. hostname.domain1.com doesn't exist, the IP it returns is the IP of the website for domain1.com. In ipconfig /all the DNS suffix search list is domain1, domain2. The laptop in question is a member of domain1, but is VPN'd into domain2, which is a trusted domain.
    – FlyinButrs
    Jul 24, 2012 at 18:49
  • @r.tanner.f - No static routes, and yes, the laptop is connected to the VPN. I believe it's a split tunnel, but I'll check and get back to you. I haven't done a packet analysis yet, I'm trying to diagnose a problem on a user's machine remotely, so getting time to work on it has been tricky.
    – FlyinButrs
    Jul 24, 2012 at 18:51

4 Answers 4

2

There is a difference between name resolution by nslookup and name resolution by Windows networking API used by almost every app.

Standard name resolution process in Windows is in the following order:

  1. Check against local computer's name
  2. HOSTS file
  3. DNS, local cache
  4. DNS, DNS servers in the order of precedence
  5. WINS servers
  6. NetBIOS over TCP/IP (NetBT) broadcast

nslookup, however, is different in that:

  1. It confines itself to registered DNS servers only.
  2. It does not confine itself to full FQDN; it might find partial ones and then tell you that it has done so. Other apps may either assume hostname is a full FQDN or attempt to add Primary DNS Suffix (defined by SystemPropertiesComputerName.exe) and Connection-Specific DNS Suffixes before resolving.

You can use Wireshark (a free third-party diagnostics app) to find out from where ping resolves your hostname.

1

Couple of possible things.

Try a route print and make sure that you don't have any static route in place which could be causing this.

Are you sure that "ping hostname" is being resolved by DNS and not WINS? If you can fully wualify and get a good result, but get a fail on shortname, it may well be a bad WINS record. Check your wins server and remove/correct any wrong records. also run NBTSTAT -RR on your mahcine

Check and adjust your DNS search order (covered in comments already by the looks of it)

Check you dont have a rogue HOSTS / LMHOSTS entry on your machine.

0

You may have a hardcoded address in your hosts file.

nslookup uses a different resolution schema than the rest (including ping but also the gethostbyname() method in the standard library).

Some more information is available e.g. at https://jdebp.eu/FGA/nslookup-results-different-to-ping.htmlarchive.org Wayback Machine memento

0

in case anyone stumbles upon this, the solution is likely very simple the dns is cached to the public ip address. to clear that, simply run "ipconfig /flushdns" this happens if the user tries to connect with the non-vpn ip and then vpn's in before the cache expires. nslookup looks at the dns servers ping does not look at the dns servers unless it needs to figure out the ip address, so if it already has the ip address cached, the dns server is not even checked.

the only other possible issue, although both ping and nslookup would likely be the same incorrect ip if this was the case. because your computer needs to know which network adapter settings should take priority, there is a priority order called interface metric on each network adapter. the VPN's adapter's interface metric should be the highest priority and will be by default, but sometimes other software (multiple vpn softwares installed, etc) could interfer. to set this go into your network adaptor list (Control Panel\Network and Internet\Network Connections) find the VPN's network adaptor (which is created by the VPN software you are using; could be a TAP-Windows adaptor or have the VPN software's name in it) go into the properties and the IPV4 properties under advanced on the general tab, there is a "Automatic metric" which is checked. uncheck it and enter 1 in the Interface metric field. reconnect to the vpn for the changes to take affect. that should be it.

You must log in to answer this question.

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