Discovery and DNS Reverse Lookup

[Ronald Lucas]

Using Istanbul...

I created a report starting from "Discovery Log" showing failed authentications.   In my report I've included the column "Device.DNS Name" to help in my troubleshooting.   Turns out, if my MID server host cannot perform a reverse lookup for an IP, the "Device.DNS Name" field in the report is empty.   But if the MID server host can perform a reverse lookup for an IP, the "Device.DNS Name" field has a value.

So in some cases, it seems a probe or sensor is relying on a MID server host's ability to perform reverse lookup to populate "Device.DNS Name".   Can someone confirm?

How important is reverse lookup for discovery to be complete and accurate?

Thanks,

Ron

[Dave Ainsworth]

Hi Ron,

I have come across something fairly similar recently where we could see discovery was attempting to connect (in the MID server logs) but there was nothing in the event logs on the server we were discovering to show that an attempt to authenticate was being made. After a few more tests, it was found that it wasn't just discovery where this was happening - they tried different credentials and running other commands on the MID server against the target device and saw similar behaviour. So this ruled out issues specifically with discovery.

It turned out there was an incorrect DNS entry which was returning the wrong name. They temporarily fixed this by adding an entry to the hosts file on the MID server. After this, both their test scripts and discovery were successful.

I am still trying to find out more information of why the incorrect DNS entry caused this issue but am wondering if for one of the servers where you are having issues, you might be able to add an entry into the hosts file on the MID server and then try again and see if you are still having issues?

Regards,

Dave

[KristyS]

Dave,

Did you figure out why discovery requires the reverse DNS lookup to authenticate to a device?  We have the same issue and trying to understand how to get around this without having to delete the old DNS record. 

[Dave Ainsworth]

Hi Kristy,

Apologies for the late reply. 

I don't think this was figured out (while I was around on the engagement) but as I mentioned, we saw that there were issues even when discovery was not used, i.e. a Powershell script was created to run WMI on the MID server and this also could not connect so it looked like the protocols used by discovery (WMI etc.) had problems when there were incorrect records and the issue did not appear to be with discovery itself.

Regards,

Dave

[robertgeen]

So just some background information on this based upon my experience. WMI seems to require a fully formed host name in order top work. It will get this either through a reverse lookup or through WINS name resolution. I've seen issues in Cloud environments where WINS and reverse lookup aren't setup and it causes WMI queries to fail completely (and thus discovery of servers to fail). RMI based discovery is supposed to fix this but I never actually saw it working so if you are having issues with WMI try to force discovery to use RMI as it's supported out of the box (and I believe in future releases including London they are actually going to start using RMI for everything due to port issues with WMI).

I hope this information helps and if so feel free to mark as the correct answer (also if you try to look up this information about WMI it's really hard to find and took me months of looking and working with Support at one of my engagements to semi figure it out). Thanks.