ESXi Hostname lookup with DHCP/DNS

Within this article I will share some of the challenges faced while implementing a VMware Auto Deploy environment with DHCP for the  Management Network.

The environment uses an Infoblox DHCP/DNS appliance but contains  some good-to-know things that are not Infoblox specific, so keep on reading.

DHCP is configured to use mac-address reservations to ensure that each ESXi Host receives a static IP address. After starting ESXi from PXE Boot you will get the well-known ESXi Boot Screen:

This boot screen contains the ESXi Hostname, IPv4 and IPv6 address.

In our case we had some challenges regarding to the DNS Hostname which was displayed as http://dhcp-x.x.x.x/. The IP address however was correct to the mac-address reservation within DHCP.

Troubleshooting indicated the following facts:

  • The dhcp-x.x.x.x hostname wasn’t resolvable by DNS;
  • The correct hostname was resolvable by DNS (but wasn’t listed within ESXi);
  • Reversed DNS lookup was also correct.

Use nslookup <ip address> to see if reversed DNS lookup is working correctly. This should give you the hostname if the DNS Pointer (PTR) record is created successfully . The PTR record is mandatory to let ESXi discover it’s Hostname

Whenever the ESXi Host boots or when the Management Network gets restarted the /var/log/dhclient.log clearly shows that, as part of the DHCP process, a Reversed DNS lookup is done to get the systems Hostname. (dns: Resolving PTR for x.x.x.x . . . succeeded)

The outcome of the successful “Resolving PTR for …..”-action is also shown in the /var/log/vmkernel as shown in the next screenshot.

Mind the fact that the Hostname at first was “localhost” (Old value) and has been changed to “textpxe” due to the successful reversed DNS lookup.

So how can it be that our ESXi Hosts within Infoblox were constantly named “dhcp-x.x.x.x” while reversed DNS is working correctly?

Our specific /var/log/dhclient.log revealed something interesting when the ESXi Host gets rebooted (or when the Management Network gets restarted). It’s doesn’t show any entry about resolving a PTR record and instantly sets the hostname to dhcp-x.x.x.x

Further investigation shows that the /etc/dhclient-vmk0.leases (since we are using vmk0 as Management Network) is containing the DHCP option “host-name” as shown in the screenshot below.

Basically the ESXi Host, as part of the DHCP process, isn’t doing a Reversed DNS lookup since it already got the DHCP Option “host-name”. This behavior makes sense: why try to resolve the Hostname when it’s already defined.

It appears that within the Infoblox configuration (as property of the subnet) you can select an option called “Generate Hostname”. This option generates a Hostname if this isn’t sent by the client as shown on the screenshot below.

Since we want Infoblox (DHCP/DNS) to be in charge of the Hostname definition we disabled the “Generate Hostname” option which ensured that the DHCP Option “host-name” isn’t send anymore. Consequently this solved the problem since the ESXi Host is started doing a Reversed DNS lookup again at boot (or when the Management Network restarts)

Leave a comment

1 Comment

  1. Max P

     /  December 29, 2016

    Hi, thank you so much for your post! I had the same exact issue. Even after following your steps it still wasn’t working; after reading the Infoblox IPv4 DDNS config page for my subnet, I noticed the following disclaimer: “Overridden DDNS settings will not take effect unless ‘Enable DDNS’ is also overridden and set at this level.” So, I clicked on Override AND click on the “Enable DDNS Updates” checkbox. Works!

Leave a Reply

%d bloggers like this: