There are few topics as controversial in the world of systems administration as hostname nomenclature. I'm not talking about the merits of using Disney characters versus the names of stars. I'm discussing how to structure a host's name in such a way that it requires a minimal amount of effort to decipher its purpose. I am going to present a naming convention that has worked very well for me in the past in both Windows and *nix environments. This nomenclature should reflect four key pieces of information about our host: location, environment, purpose, and a unique identifier. This hostname will be 15 characters in length with each field consisting of 3 letters or numbers separated by hyphens: loc-env-pur-001.

This is not just an issue for the systems administrator, this is also a matter of department policy. It is easy to follow a naming convention when there are one or two administrators in agreement, but when there are 50 in your organization it gets a little more tricky. Left to their own vices, the installers will adhere to whatever names they find convenient. If a hostname convention isn't actively reviewed by upper management and required to go through an approval process, it will just turn out to be a mess. There needn't be hours of meetings on this topic, but a basic thumbs up or down from a director can make everyone's life easier in the long run.

Location

A hostname should reflect the physical location of a piece of hardware. This element is often omitted altogether in smaller environments that have a single office. It may seem redundant to include this if you only operate one location, but will be a pain to go back and correct when you open another office. Do yourself a favor by adding this from the beginning. You'll be a lot happier when your manager brings you the good news about the new office you are opening in London.

As a rule of thumb, I use the nearest airport's three letter code. This is easy to stick to and minimizes arguing as to how some localities should be abbreviated. Seattle-Tacoma International has a three letter abbreviation of 'SEA', so the first three letters of a machine name located in Seattle would be 'sea'. If we opened another datacenter in Portland, those hostnames would start with 'pdx'.

Environment

We use the environment field to indicate whether this database server is the MySQL server in corporate, development, test, etc. By placing the environment in the hostname we can reduce mistakes where we "thought we were doing that in test." We've all done it and it can turn a normal morning into a firestorm.

Some of the more common environments I have encountered in my tenure have been: corporate, production (also seen it called delivery), development, test, stage, stress, and operations. With that in mind, all of my production hardware in Portland will start with 'pdx-prd'. As the name starts to take shape, you should notice how easy it is to grep a zone file and give your boss a list of all the test machines you have at the satellite development office in Dublin.

Purpose

Whether the machine will be used to host a web server, an e-mail relay, or a corporate database, it needs to be displayed in the hostname. I want to know what the machine is doing when I look at my Remote Desktop toolbar or my *nix prompt. I don't want to have to look at the process list, then search through the service's configuration to figure out what it is doing.

The list of possible purposes or services is too long to list here, but we can take a common service to demonstrate my point. We are getting ready to roll out some web servers at our new production datacenter in Boston. Our closest airport in Logan International and Director Tom says we're using 'prd' and 'web' for production web servers. Our new web servers are all going to start with the same prefix, 'bos-prd-web'. Done deal, there's not too much to argue about here.

Unique identifier

This is self-explanatory, but we need a way to differentiate all of our web servers in Boston. I do this by using a base 10 integer padded with zeros. This works well unless we have more than 999 of a particular host type in one environment at a single location. The easy fix for this would be to substitute a hexadecimal integer in place of the decimal integer. This will allow you to have up to 4095 machines in that particular server class.

A My 40th development SQL server at our main campus in Seattle will be named 'sea-dev-sql-040'.

The pressing questions

So now comes the question: "but we have all that information already broken out by subdomain, why would I put it in the hostname?" The default number of searchable domains on a Linux host is 6. This can be changed to a different value in resolv.h, but is an unacceptable expectation for the casual user. On the flip side, as an administrator I don't want to spend all day typing the fully qualified domain names of my servers. Searching one or a couple domains makes life a lot easier.

As for the 15 character maximum length, this is a limitation of NetBIOS. NetBios usage ceased with the releases of Vista, Server 2008, and all subsequent releases of Windows. While this is becoming less of a limitation with newer operating systems, I still like to provide backward compatibility for those users who may not be using the most current version.

Conclusion

This is by no means the definitive guide to hostname nomenclature. This is merely my personal opinion. There are few things that irritate me more than walking into a new position where someone has named everything from switches to web clusters after Star Wars characters. Don't get me wrong, I like Star Wars as much as the next guy, but please don't name a database server 'Chewie'.

I hope you found this informative and will take some of it to heart while architecting your infrastructure. Future systems administrators will thank you.

Thoughts On Hostname Nomenclature