Hostnames - A server by any other hostname would offer the same services

Hostnames are one of the most neglected management tools available in the Enterprise.  I have seen several approaches to host naming; Star Wars characters, types of wines and my personal favorite, Pooh Bear characters.

Successful Enterprise IT Management requires the use of structured approaches to spaces; name space, IP space, usernames, etc...  The basic concepts expressed here can and should be applied to others areas of your Enterprise - but I am just going to discuss hostnames.  Cool?  Well then, let’s go -

The goal is to provide you an outline of for a standardized naming convention.  Your goal should be to develop a naming convention that fits your needs and environment. A well-structured, standardized device naming convention will communicate relevant information about a device within the hostname. 

Hostnames can be used to express a lot of information:

• Location of the host
• Applications running on the host
• Environment (production, development, DMZ, etc.)
• Customer (Internal: Human Resources, Accounting, etc. - External: ACME Inc.)
• Equipment Vendor (Cisco, Oracle (miss you Sun) Windows, Redhat, etc.)
• Or whatever you need

We should first start with some base rules.  There is a basic set of requirements that are defined for hostnames; see the Internet Engineering Task Force (IETF) Request for Comments (RFC) 952 - DoD Internet Host Table Specification.  Yes this is an outdated document that has been superseded, well, added to, but the new rules allow for more variation in the hostnames.  The problem is that not all systems take the newer RFC rules into account - but you are free to read other related RFC’s (1123 and 1178).  I recommend that you stick to RFC952.  I also have a couple of additional rules for you.

The breakdown of the RFC 952 rules:

• Maximum length of 24 characters
• Use only alphabetic (a-z), numeric (0-9) and dash (-) for characters
• First character must be alphabetic
• No distinction is made between upper and lower case (upper case bad)
• Last character must not be a dash

Additional rules (not from the RFC)

• Alphabetic characters (a-z) must be lowercase
• Use the minus sign (-) to separate parts (or segments) of the hostname - or - make the segments all fixed length (more explanation in the examples)

So, examples are good, and here are some:

Belso’s Hosting decided to create nice and meaningful hostname convention for all of the hosted servers and services.

First, a breakout of the segments (parts of the hostnames):

• Location - there are three computer rooms, Ashburn VA, Dallas TX, and Los Angles CA
• Customer - Acme Inc, Belso Inc., and Random Company
• Tier - We have several multi-tiered applications - tiers 1, 2 and 3 (you could also say front, middle and back -or- presentation, logic and data)
• Application - Apache, Tomcat and MySQL
• Numeric designator - In case there is more than one type of server

The convention:

We decided to go with a fixed number of characters.  This means that each segment will be fixed.

Location -
We decided the segment should get 3 characters.
Ashburn VA - abv
Dallas TX - dat
Los Angles CA - lac

Customer -
We decided the segment should get 3 characters.
Acme Inc - acm
Belso Inc - bel
Random Co. - ran

Tier -
Just needs 1 character.
Front - 1
Middle - 2
Back - 3

Application -
We decided on 3 characters
Apache - apa
Tomcat - tom
MySQL - msq


So what do we get?

Acme Inc.'s 10th Apache web server in Dallas TX: datacm1apa10
Belso Inc.'s MySQL database in Ashburn VA: asvbel3msq01

Of course this could have used the minus sign to separate segments, so without a lot of detail you could have names like this:

Random's 3rd MySQL database in LA: lac3-random-mysql03

 
I know that adoption of such a change is difficult - and I do not recommend going back and renaming all of your servers, router, and other hostname baring equipment. Define the convention, start applying to your new gear, and modify it as needed.

Think about this - datbel1apa01 is a lot more useful than pooh.