4

On a windows 7 client, when I ping a LAN host MYSTERY, it gives me the correct IP. However, when I do nslookup MYSTERY, it says non-existent domain. I checked both the DNS listed in ipconfig and find that the hostname MYSTERY is indeed not listed. The DHCP server also does not have the entry. The same behaviour occurs after I do ipconfig /flushdns. There in no entry in the local windows host file as well.

How can I find out where the client is getting the resolved IP?

Note: MYSTERY is a Synology Rackstation configured to join the network domain.

Improve this question
3
  • 1
    It seems like the GetAddrInfoEx function in Windows 7/8 could indicate what namespace provider is resolving a hostname. However, I don't actually know of any tool that uses this call and identifies the providers of any results. msdn.microsoft.com/en-us/library/windows/desktop/…
    – rakslice
    Mar 4, 2015 at 8:25
  • Have you checked /windows/sistem32/dirvers/etc/hosts?
    – madalinivascu
    Mar 4, 2015 at 12:32
  • @madalinivascu host file checked.
    – Jake
    Mar 5, 2015 at 3:05

3 Answers 3

Reset to default
9

Your Windows machine must have some sort of mDNS resolver (Bonjour), let it be from iTunes, Skype, or other software that installs a mDNS resolver. ping will resolve correctly if a resolver is installed because LLMNR is now used in Windows Vista and above. LLMNR utilizes the mDNS resolver to return the record.

Synology uses a daemon called avahi, this is a Multicast DNS/mDNS/DNS-SD server. From the factory, Synology comes out of the box with it configured as "RackStation" or hostname from what I have experienced.

If you have a Mac, dns-sd -B will show you multicasted services. You will see _http._tcp.local. service listed for RackStation.

dns-sd -G v4 RackStation.local should give you the proper IP address for your RackStation

dns-sd -L RackStation _http._tcp. should return all the information of the service, this includes port numbers, serial, model, etc

This also applies to DiskStation as well. I did my testing on a DiskStation. RackStation should be the same.

Improve this answer
4
  • This is a bit of a non-sequitur as things stand, since ping doesn't resolve mDNS. If you're trying to answer a different question than the one that is being asked, can you preface this with the question that you are answering?
    – Andrew B
    Mar 4, 2015 at 5:51
  • 1
    superuser.com/a/624760
    – xeon
    Mar 4, 2015 at 5:55
  • Well, I'll be damned. It's a little non-intuitive that this detail isn't easy to find in the documentation for getaddrinfo and associated headers. Thank you.
    – Andrew B
    Mar 4, 2015 at 5:59
  • I edited the answer to add the information from that link. No problem, glad to help.
    – xeon
    Mar 4, 2015 at 6:05
3

(This answer is probably wrong. @xeon seems to be on the right track and I've learned something here.)

The reason a DNS lookup fails is because ping isn't using DNS to resolve that name.

nslookup is a command for DNS lookups. ping on the other hand will also attempt to use NetBIOS/WINS and the hosts file for name resolution. The most likely scenario is that this name was obtained via the former.

You can use nbtstat -c to list the NetBIOS names and IP addresses that have recently been seen, or nbtstat -a <device> if you want to actively search for a name. Keep in mind that -a will take longer as it has to attempt this once per interface. (you can't tell it to skip broadcast/only use WINS)

The -r option will let you compare what was resolved via broadcast with what was resolved via WINS, but that's getting a little more advanced.

Improve this answer
5
  • How about accessing with http://MYSTERY through the web browser? Is it DNS?
    – Jake
    Mar 4, 2015 at 3:31
  • nslookup the FQDN. See if that works.
    – Citizen
    Mar 4, 2015 at 3:49
  • It will work for the browser because the standard getaddrinfo call on the Windows platform includes results from WINS. (search that page for "netbios") There is no special coding required inside the web browser to support these names. nslookup on the other hand implements its own DNS lookup routines and is purely a tool for DNS resolution.
    – Andrew B
    Mar 4, 2015 at 3:52
  • FQDN is the same behaviour. Ok, then why only that particular Windows client can ping and the other clients in the LAN cannot? Can I have some search keywords to find out how to check WINS/NETBIOS records in the Windows Server environment, please?
    – Jake
    Mar 4, 2015 at 4:03
  • nslookup was designed as a DNS diagnostics tool. It never advertised itself as a tool that will perform other kinds of name resolution. :) Regarding the rest, I've edited the answer.
    – Andrew B
    Mar 4, 2015 at 4:30
0

Check your windows hosts file to make sure you do not have an entry hard coded there. This will force name resolution even if it is not resolvable there.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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