SlightlyLoony
Tera Contributor

find_real_file.pngPlus a question for y'all, at the end of this post...

A few days ago I posted about controlling host names, and this led to another question: How exactly is Discovery finding the names of configuration items (CIs) in the CMDB? Here's the nitty-gritty (and my question!):

The Resolver probe and sensor are responsible for resolving an IP address into a host name.

The first thing the Resolver probe does is query a DNS server configured on the MID server to get the host name. If your MID server has more than one DNS server configured, which DNS server is used depends on the operating system and (perhaps) configuration. Generally speaking, the first DNS server configured is used unless it fails to respond, in which case a secondary server will be used. However, some operating systems allow for load balancing across all configured DNS servers, so your mileage may vary. The DNS query itself is a standard reverse-lookup DNS query, wherein an IP address (like "10.2.54.233") is transformed into an in-addr.arpa name lookup (like "233.54.2.10.in-addr.arpa") and the query asks for a PTR record for that name.

The second thing the Resolver probe does is to query the NetBIOS Name Service (on UDP port 137) on the target computer to see if it will provide a WINS name. Discovery does not need to query a WINS server. Generally only Windows systems will provide the NetBIOS Name Service, though if you have some UNIX or Linux systems running SAMBA, then they may also be configured to provide it as well.

The Resolver probe returns the results of both of these queries to your Service-now instance, where the Resolver sensor figures out what to do with them (according to the rules described here).

Now here's my question for you: does your organization (or any part of it) not have DNS (or at least not a reliable or complete DNS), instead depending on something other than DNS for name resolution? If so, I would really like to know what it is that you use, and why you chose to use it rather than DNS...

1 Comment