Assume an environment with a puppet-managed cluster of different servers - various hardware, software, operating systems, virtual/dedicated, etc.

Would you choose meaningful hostnames (mysqlmaster01..99, mysqlslave001..999, vpnprimary, vpnbackup, etc.) or would you prefer meaningless hostnames such as characters from a book or movie?

The problem I see with meaningful hostnames is that names usually represent a single service and if a server has more than one purpose it gets really messy (especially if server roles change often).

Isn't mapping a service name to an IP address and maintaining that mapping what DNS is supposed to do?

What are the advantages and drawbacks of both approaches and what actual problems have you had to tackle with the approach you chose?

  • 10
    If you control DNS, you can can always do both. – jscott Feb 18 '13 at 14:05
  • 17
    I'll just leave it here: RFC 1178 – gelraen Feb 18 '13 at 14:17
  • Though superficially an opinion-based question, the actual answers are fact-based with empirical polling and based on human cognitive function (how the human brain remembers things). In my opinion this question should be reopened. – dotancohen Apr 7 '15 at 8:46

Once upon a time I had an opportunity to decide on a naming scheme. So I went round and asked my developers, who after all were the people who had to work with these names on a day-to-day basis, whether they preferred functional names (that is, names which represent, in some encoded form, the purpose of the machine) or mnemonic names (that is, names drawn from some pre-existing human naming scheme, which contained no implicit content about the machine's purpose).

Out of 38 developers, 37 preferred mnemonic names; only one preferred functional names. So I named them all after rivers (there's a very large pool of possible names, and many of them are short, easy to remember, and quick to type).

The human brain is pretty well-designed for attaching meaning to names. If you provide names that are memorable, people will pretty quickly remember what those names are used for, and use them. If you use names drawn from some common background (eg rivers, elements, stars, counties, drinks, you get the idea) it helps people to immediately recognise a company hostname when they come across it; otherwise statements like "all the email ended up on betelgeuse" can be a bit confusing).

Conversely, my developers felt that they had in previous jobs had a really hard time remembering exactly what pr1ms001 was.

But I should add that we used CNAMEs in the internal DNS to provide a functional name to mnemonic name mapping, so if you really found it easier to remember that the main mail server at the first cluster at the PR site was pr1ms001, then the DNS would let you know that that was currently orwell. Also, that let us have many functional names per machine, so as long as you always used the functional name relevant to the function you were working on, you could be sure that pr1imap001 would always point to the IMAP server, even if we moved that functionality from orwell to rhine. And when hudson died, we could change the name of the replacement without affecting operational functions, so that we never had the "do you mean new hudson or old hudson?" confusion.

  • 7
    You might think that, but my developers said that the mnemonic scheme was better whether or not anything much else was communicated, because they all built their own internal state tables of what was where, and that sort of memory is easier to build on names that the human brain likes to remember. – MadHatter Feb 18 '13 at 14:25
  • 11
    You should have named them after volcanoes in Iceland. – Chloe Feb 20 '13 at 4:50
  • 1
    +1 for "pool of rivers" ;) – Konerak Feb 20 '13 at 7:18
  • 2
    This is an awesome idea, and I'm stealing it. – SpacemanSpiff Feb 28 '13 at 2:13
  • 1
    I agree that naming servers this way is more work with an autobuild system, but I note that the point of building them is for other people to use them - and the data above are from the people who had to use them. It may be that what they want has changed, but I think our decisions on server admin should be predicated on more than what makes our jobs easy. – MadHatter Jun 11 '15 at 18:06

This largely comes down to whether your servers are pets or livestock.

Pets get individual names. They're distinct from each other, and we care about those differences. When one gets sick, we usually try to nurse it back to health. Traditionally, servers have been pets.

Livestock get numbers. They're mostly identical, and what differences there are, we don't care about and usually try to minimize. When one gets sick, we put it down and get another one. Fully virtualized servers, especially IaaS servers such as AWS, are livestock.

In most complex environments, you have a mix. Your web backends, for instance, are almost certainly livestock. If you need more, you spin up a few more with the standard config; if you don't need as many you turn some off. Your database servers, in some configurations, are pets. There may be a lot of special setup on each; you may even be running them on bare metal instead of virtualization.

Of course, in either environment, you can name SERVICES and address those directly. This is a best practice in any case; your developers shouldn't need to know or care what the actual hostname of a service is. The hostname should be a purely operational detail. Think, then, of encoding information that is useful to your ops staff in the hostnames - for instance, it's often helpful to denote which datacenter a server is in.


This has been covered here before...

My recommendation is a combination of functional names and mnemonic names...

If you're writing an application and it needs to address ccts-logserver1, use that name throughout, but make that a CNAME or an alias. The real hostname can be whatever you want: a fruit or vegetable, greek mythology or Seinfeld character... but it gives you some flexibility when you need to associate real functional names, but keep something that people can remember.

Think of the example where mango, the DB server fails... but is replaced with something else, say peach. Perhaps existing processes and applications need to see cmt-prod-db1. You can swap the systems, build them without naming conflicts and keep the applications (and developers) happy.


Where I work we manage multiple sites, multiple companies, in multiple cities. For us mnemonic names can't work. Instead we use a shorthand form that describes our servers. This works well in our case as we have some clients which may have multiple offices on different domains (or a single office on multiple domains, or multiple offices on the same domain, or all of the above!)

For us, the information contains Company/Domain, city, function, number. So for a domain controller for company, say Cypress in Chicago it would be:

CYPRCHDOM001 (We would refer to this as Cypress main DOM in conversation)

CYPRCHSQL001 would be it's SQL server, CYPRCHMGM001 would be its management (ie, anti-virus, backups, etc), and CYPRCHAPP001 would be a mixed applications server. Easy to remember, easy to sort, easy to teach.

  • 1
    So how do you remember what applications run on CYPRCHAPP001 as opposed to CYPRCHAPP003? I'll admit this is a problem with mnenomic names as well, but if you're going for some kind of functional names, might as well be specific. – user Feb 18 '13 at 19:44
  • 2
    @MichaelKjörling Fine grain specifics of what is on a server don't belong in a name, they belong in some sort of documentation. If someone needs to know what is running on CYPRCHAPP001, they read the documentation. Besides applications move, CYPRCHAPP001_PointofSale_Payroll_HRSoftware-etc will be a misnomer when the company moves their payroll software to a hosted solution. – Wulfhart Feb 19 '13 at 23:17
  • 2
    @Wulfhart I agree with your point, but what's wrong with having CNAMEs for pointofsale, payroll, etc.? That way, nobody but the sysadmins need concern themselves with exactly where the payroll software is running; for everyone else, it just works. Want to move something to another datacenter? No problem at all. Want to move the point of sale system database to its own dedicated server? Just update the pointofsale-database CNAME to point to the new location. And so on. – user Feb 20 '13 at 8:47
  • 1
    Suppose you need to replace a machine: once you've built CYPRCHSQL002 and tested it, do you just retire the name CYPRCHSQL001 (never to be replaced), or do you rename 002 to 001 after you've removed the old 001, or something else? – nickgrim Feb 20 '13 at 11:22
  • @MichaelKjörling That seems like a great idea to me. By "specifics don't belong in a name" I meant not in the machine's hostname. – Wulfhart Feb 20 '13 at 22:39

The only requirement for hostnames is that they should be unique on the network.

The meaning doesn't have to only be to do with the servers function. Location can be very useful if you have to deal with physical devices. Knowing if a device is virtual or physical can also be useful. Being able to tell the difference between a network device, a linux server or a windows box can be very handy when it comes to figuring out what tool to use to login.

The way we handle it is to try and put this information into the device name as follows:

L or T - Live or Test P or V - Physical or Virtual S or N - Server or Network (we don't have any Linux servers) a sequential number to ensure uniqueness An ISO 3166-1 three letter country code indicating where the device is located.

We then use CNAMES in DNS to map various service names through to the hostname.

I have mixed feelings about this. It certainly saves time in having to look up where a certain device is located. On the other hand it is much harder to remember what a given server does when presented with its hostname, when compared to our previous system which used gemstones. The gemstones didn't imply any meaning at all, but they were easy to remember because each person could create their own connections.

I guess the only advice would be to settle on one schema as the greatest confusion arose when we transitioned from one system to the other.

  • I do disagree with this : "Knowing if a device is virtual or physical can also be useful" in the context of a naming discussion. Of course it's useful information, but it's not the first thing you need to know about a server from reading its name. Further, P2V or V2P either breaks your scheme, or requires renaming of the server, which may break other things. – mfinni Feb 19 '13 at 15:38
  • 1
    In my experience P2V or V2P breaks a whole bunch of things and should be avoided where possible - we do, hence it isn't an issue with our naming convention. The naming convention needs to meet the requirements of whoever designed it - in the org I work in it was designed by the team who manage all the servers and network equipment, and they want to be able to tell the above things. It might not be right for you, but then it is all open to debate. The only technical requirement is uniqueness. – dunxd Feb 20 '13 at 12:46

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