When deploying a vCenter Server Appliance (VCSA), customers have two options for setting up a static network address: using either a hostname (Fully Qualified Domain Name) or just a static IP Address (e.g. no DNS). In the first option when using an FQDN, it should be no surprise that you need to also specify a valid DNS Server which the VCSA UI/CLI Installer will automatically validate both the forward and reverse address. This is the most common deployment model for customers in both production as well as for development environments such as a vSphere home lab.
In the second scenario, where a static IP Address is used, a DNS server is not required because we are NOT using an FQDN for the hostname but rather an IP Address. Having said that, if you have ever used the VCSA UI or CLI, you will find that the DNS Server entry is actually a required field and you can not proceed without providing an address.
VCSA UI Installer:
VCSA CLI Installer:
As mentioned earlier, we know that it should not be required but currently the VCSA Installer is a bit overly cautious in its pre-checks and does require a value today. This is something that has already been shared internally and the team will be relaxing this requirement in the future.
With that said, this leads us back to the original question posed in the blog title, do we need a valid DNS server when using a static IP for the VCSA?
The answer is no, you do NOT have to provide a valid DNS server address BUT, you can NOT just use a dummy value that is non-reachable on the network. The reason I am bringing this up is that we recently had several customers who had a requirement to deploy several hundred VCSA's in an isolated environment where DNS would not be available. They found some strange behaviors when they had used a non-reachable address for the DNS server input and this caused large delays during the initial setup as well as when rebooting the VCSA. The reason this was happening was that the VCSA tries to perform a lookup of the static IP Address using the provided DNS server, since it was not a working address, it took awhile before the actual operation timed out.
The workaround is actually quite simple and one that I have personally been using since the inception of the VCSA for environments that does not have DNS. Simply use the default gateway address as the value for the DNS entry. When the VCSA tries to perform a lookup, it will fail and return immediately rather than timing out when an invalid address is used instead. Technically speaking, another more reliable address can just be the loop back address (127.0.0.1) which I believe is also the default entry in /etc/resolv.conf but I do not recall 100% off the top of my head.