The End of Hostname Standards? Hostnames in the Dynamic Infrastructure World

The fastest way to start a fight in IT is to get engineers together with the goal of creating a hostname standard.  If there is one thing that seems to get blood pressure altitudes at new heights it is the topic of hostname standards.  This was the case at Gap and boy did it go on for months.  At one point people that were friends actually stopped talking to each other because arguments got so heated.  In retrospect, the entire exercise was one in futility.

Individual server hostnames are increasingly becoming irrelevant today.  Hostnames, historically, provide IT people with a sense of control over the chaos of IT operations.  However, this “control” is just one of many legacy thought patterns that equate to an old way of doing business.  In truth, the hostname should essentially be viewed as a variable that is disposable.  How you might ask?  This is because the servers themselves should be viewed as disposable.  In fact, with modern configuration management software like OpsCode Chef or PuppetLabs Puppet, and dynamic cloud computing host instantiation, hostnames truly do become irrelevant.  What is still relevant is the virtual ip or “VIP” in networking parlance.  The VIP is a (usually) friendly DNS name that end users use to locate an application or  service behind a load balancer.  The  servers themselves are the dynamically named piece of this design discussion that I am talking about.

Think about it, if a server vm can be spawned, destroyed, and rebuilt in minutes, can you really rely on a static hostname?  The answer is probably no.  Increasingly, the server instance name needs to be as dynamic and flexible as the infrastructure.  Finding a server is often done when something is wrong, and with static hostnames, you would have had to either:  consult a monitoring system that told you the name because something was wrong, someone else came to you and said ” I need help with the yoda123 server”, or think for a minute to try and derive it from a hostname standard.  With modern configuration management, if you need to locate any server, or more likely a group of servers, you can do so easily and programmatically.  You dont really need a hostname standard.  Let’s examine some examples of why.

With OpsCode Chef, you can search your entire infrastructure for any combination of server roles, attributes, or functions.  It is super easy and straightforward.  Here is an example of how to search for all servers you have that are web servers:

knife search node "role:webserver"

You can also do boolean searches for multiple roles.  Here we search for all nodes with apache and memcached roles:

knife search node "role:apache AND role:memcached"

You can also do some fun things like search all your nodes for things like a variation of a hostname!

knife search node "id:yodaweb*"

Finding hosts by role or function like this is as easy or easier than relying on a static traditional hostname standard.  It also is dynamic.  When the host is terminated, the CM clients are told to remove them from the node list.  So, the next time you do a search, you will not get a result set without that server.  This type model means that the server hostname can be something like aabbccddeeffgg1234 and it can be easier to find machines using intelligent search rather than trying to map aabbcc to some kind of master hostname schema, where aabb means it is a web server.  Plus, is it always accurate as of the way the server was built.  Meaning, you don’t have situations where Mr. Joe DevOps built a memcached server but did not name it yodamemd, but instead named it r2d2mem.  In this type scenario you would not be able to locate the server, but with the modern CM system you could find it.

Still, after many arguments, folks still say there are use cases for hostname standards.  I think that argument can have some relevance when you break down the type of machine and the specific use case in question.  For example, hypervisor hosts often don’t need to have an end user friendly hostname because they never access these servers directly.  However, a VIP for a well known app probably would be nice if it were friendly and iterative.  Perhaps, the case can be made that servers that end users access directly (with no VIP) is convenient to have “easy” names to remember.  However, this is most likely a set of use cases that are small.  Anything, that needs to scale most likely won’t benefit from a predictable hostname standard.

I did a quick breakdown of how hostnames can be viewed by use case:

CLOUD

Dynamic Host Names that do not adhere to any hostname standard.

Ex) This GUID name can be formed from well known UUID sources like the host mac address.  Here is a quick and dirty example.

     MAC address of NIC1 
eg) 04:0c:ce:d0:7a:b6

    – The following steps are performed to arrive at the dynamic Hypervisor host name:
1) Query to system to get the mac address of NIC1 the RAW name.
2) Any dashes (-), underscores (_), colons (:), or dots (.) are removed from the RAW name.
3) The CLEANED mac name is then prefixed in lowercase with anything you chose to ensure alphabetical characters.

HAV

See my previous post of HAV versus Cloud for what HAV means.  Persistent hosts that end users may access directly without VIPs can benefit from some sane hostname standard.

Here is an example of a hostname standard that might work for some common infrastructure use cases.

  • Hostnames are accessed using friendly 13 character CNAME.
  • 15 Characters are the full characters allotted for the hostname standard.
    • 14-15th characters only used for mgmt and ethernet interfaces identification.
    • CNAME should automatically be created for any of the e0 and e7 interfaces to the hostname ending at Server Instance ID.

Env ID (1)      Location ID (3)   App ID (3)   App Function (3)   Instance ID (3)   Mgmt ID (2)

  • The 15 character format is the full name.
  • Most physical hosts will have at least 3 interfaces:  2 ethernet interfaces, and 1 mgmt interfaces.
  • Most virtual guest hosts will have at least 1 or 2 virtual ethernet interfaces.

Note:  You can go higher than 15 characters for the name, but Windows machines will not like them and unattended installs will in fact fail.  Yes, this still happens in 2012.  Stupid, but there it is.

While I did this work, I compiled what I think are the relevant standards information to guide hostname making decisions.  I have added my notes below for your reading pleasure.

DNS Naming Rules:

FORMAT:  HOST-LABEL.SUBDOMAIN-LABEL.TLD

http://tools.ietf.org/html/rfc1035

  • There cannot be more than 127 levels of LABEL
  • Each LABEL has a max of 63 ASCII subset characters.
  • The total number of characters in a FQDN cannot exceed 253 ASCII subset characters including decimal dots.
  • The hierarchy of domains descends from right to left.
  • DNS names may use any ASCII subset of characters:  A – Z, 0 – 9, and a – hyphen. (The LDH rule for letters, digits, and hyphen)
  • DNS names may NOT start with the hyphen.
  • DNS names are NOT case sensitive and not interpreted as such either (case insensitive)

LINUX LIMITS

The Single UNIX Specification version 2 (SuSv2) guarantees ‘Host names are limited to 255 bytes’. POSIX 1003.1-2001 guarantees ‘Host names (not including the terminating NULL) are limited to HOST_NAME_MAX bytes’.  These values in Linux are set to 64 bytes.

(libc defaults to 64.)

DNS

Minimum name length

2 characters.

Maximum name length

63 characters.

MICROSOFT LIMITS

http://support.microsoft.com/kb/909264

DNS

Minimum name length

2 characters.

Maximum name length

24 characters.

NETBIOS (LEGACY)

Minimum name length

1 character.

Maximum name length

15 characters.

The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.