Naming concepts: DNS names will make your life easier
on Jun 28, 2022
The correct naming of systems is the basis for a productive IT operation and also forms the foundation for IT automation. But what does a good naming concept look like in practice? In this article, I will show you some key elements and tips on how to implement these. I will use a VMware environment as a practical example, since the naming concepts are particularly important for monitoring VMware.
However, do not change names in VMware without reading to the end of this article. Ideally, you should follow these criteria when assigning names and thus avoid many potential pitfalls.
- Readability: Simplicity beats complexity! You should know what an abbreviation stands for without needing to check an Excel spreadsheet. Each name should be easy for a human to read and reveal the most important information about a system. This should always include information about the architecture and function of the system. Depending on the size of your organization, it may also be useful to add details such as location.
- Consistency: Your naming concept must be consistent and continuous, without duplications or changes in format. For example, for numbers, consider the number of digits. ‘name-001.lan.domain.net’ will be inadequate when there are more than 1,000 systems.
- Universality: Use DNS names consistently across every tool, even if using DNS names means consistently using lowercase and not using spaces. This ensures that each system on the entire network has only one name and can be uniquely identified by each person and by each tool. This not only saves you the manual administration of IP addresses, but is an important basis for automating processes.
- FQDN: I recommend using fully qualified DNS names (FQDN) including the domain name and not just short names. This has several advantages:
- If you use more than one domain, you can distinguish systems with the same or a similar short name. For example, we at tribe29 host two websites (www.checkmk.com and www.tribe29.com). Thus, under both domains, there could be systems with identical short names.
- Also keep in mind that when using encrypted communication, a certificate is only issued to the full domain name. An access attempt via the short name would therefore fail with a warning about the certificate's validity.
An example using a VM: A few characters is all you need
In practice, you can implement these recommendations using the ‘location-type-function-number.domain’ principle. For example, the DNS name of a VMware vCenter would be ‘muc-vm-vcenter-001.lan.domain.net’. This is the virtual machine on which the vCenter is running.
Location: Where is the system located?
‘muc-vm-vcenter-001.lan.domain.net’
In my environment, I created a virtual data center in vSphere for each physical branch and named it after the city in which the branch is located. ‘muc’ stands for ‘Munich.’ And if you have multiple locations in Munich, you can number each one, for example.
Type: Is it hardware or software?
‘muc-vm-vcenter-001.lan.domain.net’.
In my example ‘vm’ stands for ‘virtual machine’. Alternatively, I could have ‘sr1’ here for ‘server rack 1’ or ‘aws’ if I were running the host on a bare metal server or in AWS, respectively. This information is important because if there is a problem with this system, you can immediately see what your options for action are. For example, you can start a virtual machine remotely, but not necessarily a physical switch.
Function: What does this system do?
‘muc-vm-vcenter-001.lan.domain.net’
‘vcenter’ tells me that my VMware vCenter is running on this VM. If a VM serves as a server, for example for SQL or LDAP, I store this information directly in the DNS name.
Sequential numbering
‘muc-vm-vcenter-001.lan.domain.net’
‘001’ is my sequential number. Currently, I have only one VMware vCenter in use, by using a three-digit number I will have no problems with my format if I add more vCenters. However, keep in mind that with other systems the number may be significantly higher. You can host more than 1,000 SQL servers at a single location in a very large environment, for example.
Best practices: DNS names in VMware vSphere
Based on this principle, I have created the first hosts for the Munich site in the vSphere Client. In addition to two ESXi hosts, only one SQL server is currently running at the Munich site. All display names for the operational systems are easy to understand, resolvable by DNS, are consistent and use a fully-qualified name. I also use a template named ‘TemplateWindowsServer2016’ and have a test server named ‘_muc-vm-001.lan.domain.net’.
I deliberately chose the names for the template and the test server since I am already thinking about monitoring with Checkmk. When monitoring virtualized environments like VMware, it is recommended that Checkmk automatically creates hosts in the monitoring for you. By default, Checkmk adopts VMware's display names as the host names in Checkmk. By assigning prefixes in the display names, you can easily manage your hosts later in monitoring. I therefore recommend agreeing on uniform prefixes with your colleagues.
For my template, for example, I use the prefix ‘template’. This is important because the VMware API does not allow a distinction between templates and real VMs when retrieving monitoring data. Checkmk therefore always initially sees templates as switched off VMs. With the ‘Template’ prefix, I can later use the monitoring rule ‘ESX host and virtual machine states’ to ensure that Checkmk also recognizes all templates as such and, for example, does not send any false alerts.
For my test device ‘_muc-vm-001.lan.domain.net’, I slightly modified the display name. The DNS name would be ‘muc-vm-test-001.lan.domain.net’. The added underscore (‘_’) in front of the name is a character I agreed with the IT team, and here signals that this is a special case. Furthermore, later in Checkmk I can also easily use rules to ensure that this device does not trigger false alarms.
As well as the underscore for systems that are permitted to be offline, I usually also use the hash symbol (‘#’) prefixing the display name. With this, I mark systems that I do not want to have in the monitoring. You can then use the ‘Disabled services’ monitoring rule in Checkmk to remove such systems from monitoring. This helps, for example, if you use virtual desktop infrastructures with VMware Horizon. In this case, VMs are frequently created for the users and then switched off again. Therefore, it does not make sense to include such VMs in Checkmk.
No DNS names used? Customization of the display names in VMware is (not always) advisable
If your systems' display names do not follow a consistent naming concept, you can modify these later. However, you must proceed with caution. If you change a VM's name in VMware, you will only modify the display name. The VM file names or the names of the directories in which the files are located are however not changed and continue to use the original display name.
Small changes, such as adding an underscore or hash, will allow recognition of the old display name. For example, if someone is cleaning up the file system, each team member will recognize which VM the files belong to despite such a change. However, if you have completely replaced the display name, it will appear that the data is no longer needed since there is no longer a VM with the old display name. Deleting the data then renders the VM unusable.
Due to this risk, some organizations have strict requirements for renames or do not allow them at all. Depending on the size of your VMware environment and your IT team's experience, you may want to refrain from renaming. You should also keep in mind that changing the display name may affect backup jobs, for example, and you may need to modify these as well. This will depend on the backup solution you are using, of course.
The only way to get modified display names in the file names and directories in the VMware VMFS is to rewrite them. This only occurs when moving to another storage using Storage-VMotion. To be able to do this online, the corresponding license requirements will need to be met.
With ESXi hosts, a name change is more complex because you need to remove them from the cluster and shut down all VMs. You can find information on this procedure in the VMware manual. However, because of the extensive preparation and the modifications required for the configuration, I only recommend this to experienced users.
The effort required to change the names of VMs and ESXi hosts is not always justifiable. Good host names are particularly important for Checkmk, because it can thus clearly assign monitoring data from different sources to a system. You can translate display names from VMware and other virtualization solutions into host names of your choice with the ‘Piggyback Translation’ monitoring rule. Instructions for the ‘Piggyback mechanism’ can be found in the Checkmk manual. Use this rule wisely, however, and only in exceptional cases. It is better if you use a consistent naming concept throughout.
Conclusion: Good DNS names are definitely worthwhile
This article describes the points you should consider when it comes to naming concepts. The appropriate naming policy saves a lot of time and is the optimal basis for implementing day-to-day IT challenges and automating processes.
The advantages become apparent in practice, for example, in VMware monitoring with Checkmk. Here, naming concepts are particularly important because Checkmk can automatically create hosts for you. In addition, with a suitable naming convention in Checkmk, you can apply monitoring rules flexibly and precisely. This saves you time because you can manage host categories right away instead of needing to manage the individual hosts. For example, if new hosts are added to a site, or new hosts of a particular type are added, Checkmk will automatically apply the appropriate rules.