I am looking at setting up a hostname convention for our servers based on the service they provide, such as http, https, smtp, pop, dns, sql, etc. Each service is on its own virtual machines on a Xen host server (dom0), for which there are multiple Xen host servers (10+). I have read both the Datacenter Naming Scheme by Mark Garner of Sun and RFC 1178 as well as a few Google searchs but those seem to focus on having many servers that perform only a few services, such as a larger cluster (10+) of database servers, a large cluster of web servers, a large cluster of mail servers, etc. In my situation we are working with a small cluster (2-4) of virtual servers for a large number of services (12+). In this regard I do not like the idea of having a different hostname theme for each service, such as all mail servers being named after birds, all database servers after trees, and so on, because I think it will become confusing with very few hosts and very many different services. I am wondering if anyone has a good idea for defining hostnames in such an environment. Thank you.

  • 1
    What's wrong with http###, sql###, dns###, etc.?
    – ceejayoz
    May 12, 2009 at 16:50
  • I second @ceejayoz naming. I would follow that naming convention as well.
    – user1797
    May 12, 2009 at 16:57

4 Answers 4


Since you have more than one service per server, I would suggest giving your machines some hostname based off whatever theme you like, then using 'service names'.

For example, host bart might have service names www1, imap1 and ftp1.

Add those service names to DNS and then (depending on your preferences and desire for complexity) either:

  • Create CNAMEs in DNS pointing the service names back to the appropriate hostname
  • Create A records for additional IP addresses and assign those IP addresses to your hosts

Now, make sure you reference services on that machine using the service name (www1), not the hostname.

  • If I understood correctly, @ryanklein wrote that he wanted to setup a "a hostname convention for our servers based on the service they provide, such as http, https, smtp, pop, dns, sql, etc" and that "Each service is on its own virtual machines". I know it is kind of hard to read the big paragraph, I might have incorrectly understood.
    – user1797
    May 12, 2009 at 18:06
  • Yeah, given "In my situation we are working with a small cluster (2-4) of virtual servers for a large number of services (12+)." it was hard to tell if there were 2-4 servers in total or (2..4 * 12+) servers in total. In the case of strictly one service per server, I'd definitely just go with service#{2-4} (mmmm... regexes)
    – MikeyB
    May 12, 2009 at 18:24

here I found a good naming convention:


  • 2
    Welcome to Server Fault! We really do prefer that answers have content, not pointers to content. This ensures that the answer will remain available even if the link goes dead. Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – user9517
    May 25, 2012 at 20:36

What's wrong with http###, sql###, dns###, etc.?

Naming conventions are great when there's no easily described distinction between what the various virtual machines do, but if each one is running an individual service, it's going to be clearest to name them by that service.


The naming scheme where I work today works like this:

|server Role||Domain or Owner||site Code||Serial||Extra Modifier|

This translates to names like this: dnsenet0b1ab

  • Server Role: A documentated server type. In the example, DNS (DNS=DNS, DC=Domain Controller, FNP=File and Print, etc)
  • Domain or Owner: Generally the domain name or owner in the case of Unix boxes. In this example enet = "External Network" domain.
  • Site Code: A three digit code corresponding to a location on our network. In this example, "0b1"
  • Serial: If you rollout 3 servers, the first one is aa, second one ab, third one ac, etc. If a large group of servers is replaced, sometimes they will alternate and use zz, zy, zx, etc to make it easy to spot the new servers
  • Extra Modifier: Used to denote dev/qa/testing environments usually.

The key to naming is consistency. Whatever naming scheme you use, as long is it gets the information that you need across and is ruthlessly enforced, you'll find that consistent, informative naming will speed up projects and make management easier for large install bases.

This system may look intimidating, but it is really great once you get used to it AND is reasonably easy to type and talk about. It's easy to determine the type of server, where it is, etc at a glance. You could easily expand it to include other information that means more to you.

For things that have client exposure, I think that it's a great idea to supplement this with service descriptive CNAME records that aren't tied to a server. Make your mail server mail.example.com, http server intranet.example.com, etc.

You mentioned that servers share roles. If you see an affinity among services, create a "server class". Many places put SMS/SCCM, print queues and AV on file servers... call it a "host management server (hms)" or whatever.

Not the answer you're looking for? Browse other questions tagged or ask your own question.