Flashback: DNS names for internal hosts
March 2, 2010
This is a short bit that I wrote when I was considering overhauling the internal naming scheme at my company. We used to use an odd mismash of names, and we used to have multiple invented internal DNS names, that referred to the physical location. And I don’t mean things like “location.example.com” (that might make sense!). I mean it would be as if General Motors had “boston.gm” and “tijuana.gm” and “tokyo.gm”. Nonesensical in a lot of ways (particularly now that the TLD’s can be bought for a song (well, an expensive song)).
Anyway, I was curious how other people did it, so I asked. As it turns out, this post originally aired in July of 2008. I would guess that I had a couple of hundred readers. That’s a good range of experience to draw from, but I wanted a more broad view, so I submitted it to slashdot. And it got on the front page.
Thanks to Slashdot, this entry originally received 43 comments, which is right around 30 more than the next most popular story at that point. I’ve had a lot of people tell me that they found me because of that front page article. I didn’t submit it to drive people to the blog; I really did want to hear what people were doing with their own networks. Driving people to the blog was a completely satisfactory side effect, though 
Before you leave this page, make sure to check out the original and read the comments. There’s a lot of funny (and interesting) ideas!
Enjoy!
Bob Plankers, over at The Lone Sysadmin wrote a couple days ago about getting busted while reading the wiki page on X-Men. He tried to cover it up by claiming to be researching future host names. Quick thinking, Bob. Good job!
It does bring up a good point, though. Internal naming schemes are something that everyone has an opinion on, and a load of suggestions.
At various places, I’ve used greek/roman gods, Simpsons characters, beer companies, wine labels, and fish.
At my current company, we used the beer and wine names. We absorbed another company that used fish. It worked fine for a while, but we grew in terms of servers and locations until it got unwieldy to remember A) all the names, and B) what each name did. You’d also start to get very similar names after a while. We’ve now got 4 physical locations, soon to be 5, and something like 50-60 servers (not counting network devices), no one would be able to keep them all straight (including the admin).
To improve the situation, we’re in the process of changing to location-based hostnames with a flat internal domain structure. For example, the 2ndary application server in Ohio is oh-app2, with the fake internal domain name trailing. The alpha site’s primary fileserver is a-fs1.
It’s no where near as fun as “wolverine.internal.com” but it certainly does tell you where you’re connecting to and what the machine does. What makes it interesting is when you go changing things like CVS repositories on people’s machines, mail servers, etc. The policy we’ve taken is to alias the old information to the new, and slowly phase out the old method.
What do you use as internal naming systems? What do you think would make an excellent scheme? Make sure to check the list to make sure it hasn’t been done before!
Posted in General
Email me
content rss
March 3rd, 2010 at 3:15 am
That’s fine as long as each server only has (and will only ever have) one task and maybe once you get to the point where clever names are hard to remember, this is always the case. But of course the obvious problem with calling a server oh-app2 is that if you move your data centre somewhere else or decide to add a second service to the machine, the names pretty quickly become nonsensical again.
I’ve always tried for a primary name for each machine that simply indicates identity (zeus, fender, mahi-mahi, whatever) but tried to instill in the IT staff that these names should never be used directly in any any configuration file. Service-oriented CNAMEs (ftp, dns1, etc) should be created that can be re-aliased to another machine when needed. Network devices were named by type and location, mind you.
I’ve never got quite as high as 50-60 devices but even before then, the “theme” names do start to break down as it is harder to think of names at all, let alone one that conveys a hint of meaning.
March 3rd, 2010 at 10:05 am
Interesting topic. I wonder if people’s opinions have changed between when you originally wrote this and now.
Most companies I’ve worked for have had ‘fun’ names for their servers, brands of scotch, currencies, and the like. Mostly it works out well enough if the names aren’t important – peoples desktops in a small company for example.
However the company I’m working for now has hundreds of different systems serving a ridiculous number of purposes and there is no one person who knows what everything is for. In fact I’m pretty sure that there are servers out there that nobody knows what they are doing.
At some point as this company grew they got smart though. All user desktops are now named “city-username-OS-##” – yes.. it can get long, but there is no mistaking who/what/where the system is. Servers generally have a similar scheme – at least the windows ones do. city-function-## mostly. Unix servers don’t always have a standard naming scheme, but the hostname usually identifies it in some way.
They’ve never used ‘fake’ domain names to identify things – always just the hostname.
Fun names can be fun, and using CNAMES for things makes it easy to separate the purpose of the system from the hostname so that you can migrate services between systems, however when you have thousands of servers that you have to manage on a very occasional basis – it’s a lot easier to figure out what “ny-linux-cluster-##” does than trying to figure out what “titanic” is for.
March 3rd, 2010 at 10:51 am
Julian,
If I were in that position, I’d probably change the hostname to the hardware identifier (for example, right now, my laptop machine names are all identical to the built-in ethernet address). For Dell machines, it would probably be the service tag. That name would also be the A record. I’d then CNAME the others to it, and I’d have one CNAME per service, so that if (when) services got migrated, the name could follow without issue. Pretty much what you said, it sounds like.
Anthony,
I’m not sure. I would guess most people probably feel the same, or at least, the same percentage of people feel the same. I think as people (and infrastructures) mature, they move toward a more rigidly defined scheme. And new networks are starting all the time, and someone somewhere will always have their PDC named Zeus.
March 3rd, 2010 at 1:21 pm
Work designates all systems by “SiteRoleXXX”.
On my home network, I allow the family to name their computers whatever they want, but have a strict policy for my servers, and test network.
My convention is this:
FOO-WIDGET-XXX
“FOO” is the network; “WIDGET” is the Role the server/appliance uses; “XXX” is the number for the device. If the device is a single unit, it is “001″. My VM Server has a numerical designation of “100″, so that I can create 99 VM’s for testing. If I version upgrade the VM Server, it will go to “200″, and so forth.
I document all of this, so that I can look up the system, and view its history, software installed, etc. My Wiki contains notes that make regarding software testing and special configurations that I used.
March 3rd, 2010 at 1:46 pm
The company I work for has a the following standard naming scheme:
So things look something like MI12db01
That would be Michigan location 12 database 01
It works ok, but it leaves much to be desired. In fact its exceedingly difficult to describe what a server is by hostname. If done properly and you have a good managment system hostnames shouldnt matter. For small sites and infrastructrue fun names are fine and are easier to remember but as sites grow name collisions become more common. Of course there is the reverse way to organize systems heirachy using dns
maybe db01.12.mi.domain.com, makes perfect sense to me
March 3rd, 2010 at 4:18 pm
I have been of the school that names didn’t matter if you documented the systems or had a asset tracking system that could document it for you.
An asset tracking/management system makes the whole issue of “What is on this server?” moot.
March 4th, 2010 at 12:11 pm
@John M – That works if you can keep it up-to-date. I’m a firm believer that it is possible to do as well.
However I’ve also seen many really bad asset tracking packages that are so cumbersome to use that people don’t bother keeping them up to date. I’ve also seen tons of good ones go unused because people ‘cant be bothered’. It’s like documentation – you spend all this time getting it working and say ” ok.. finally – i’ll document it later” – but later never comes.
We have an asset tracking database here but I’d say 20% of the servers aren’t even in it and maybe 50% of what IS in it is not up to date
March 4th, 2010 at 1:54 pm
@Anthony
I work in an environment that requires us to keep the assets up to date, due to SOP’s, and validation issues. One step in our build process requires us to install the tracking agent the asset, so it can be managed.
We also manage the documentation as we build, so we have a baseline system that has to signed off before it can go into production.
That being said, I have worked in businesses that have poor or non-existent asset tracking and documentation.
I have yet to find anyone that likes processing and updating documentation.