Best DNS Naming Scheme For Small/Medium Businesses? 481
Bandman writes "My business just purchased a couple dozen blades, and with our existing servers, this brings us to around 60 machines. We're geographically dispersed, and most of the users who need to connect to servers are not technical (if that matters).
We used to use theme-based naming schemes, but we've been migrating to a more utilitarian system. I think it's clearer and more concise, but I've had some feedback from users who didn't find it understandable.
What do you use for your internal DNS schemes? How big is your network, and what do you recommend for future expansion? Does it matter to your users at all?"
RFC1178 (Score:5, Informative)
http://www.faqs.org/rfcs/rfc1178.html [faqs.org]
Interesting read...it specifically says:
'Don't choose a name after a project unique to that machine.'
I agree with the reasoning, but on large scale DNS deployments, I can also see this being a nightmare... I just use arbitrary names, nothing too hard to spell.
Function-based names (Score:4, Informative)
Having worked at two companies now with 8,000+ servers each, unless you're changing server roles all the time, function based names are best. Even in a small environment, I would recommend this scheme. Pad the names to at least two digits, more if your expectations require; i.e. 01, 02, 03. Site names based on local airport codes are also good. If you have multiple sites in one geographical area, suffix the names with 01, 02, 03, ...
Examples:
nagios01.sfo.example.com
nagios02.sfo.example.com
nagios01.phx.example.com
dns01.lga01.example.com
dns01.lga02.example.com
Some would argue against this for purposes of "security". I think this is flawed for several reasons:
1. It's security through obscurity, which is no security.
2. If someone's freely in your network, the jig is already up.
3. It only serves to complicate things when you get bigger, and inevitably go to function based names.
We use : (Score:2, Informative)
- 2nd letter : P for Production, T for Test, etc.
- After is the shortened name of the service : DNS, FTP, etc.
- And end it with some incremental numbers : 00, 01, etc.
So it might look something like
SPDNS00 or LTFTP01 or WPEXCHANGE01
Separate names for function versus physical device (Score:3, Informative)
One thing we do in our internal network is to have two sets of names. One set is logically named and reflects a specific purpose. For example, "svn.internal.tld", "db.internal.tld", "web.internal.tld". 'svn' is the svn server, 'db' is the db server, and so on. The same machine can potentially be mapped to from many of these names (for example, 'svn' and 'db' may resolve to the same IP).
When we write our internal scripts and configure our software, hostnames are ALWAYS specified using the logical function names.
On top of this, each of the physical machines has a unique name for itself, following whatever arbitrary naming scheme we choose (in our case, it's fruits: lemon, orange, etc.). We use this name when talking about actual machines with problems (e.g. "lemon just went down").
It works well enough for us. When we move services, we don't have to change our internal scripts or configuration at all, just change the dns reference for the given service. The nicknames allow us to talk about each individual machine easily.
Re:location/purpose naming (Score:3, Informative)
I agree, although I would make cityFileServer a DNS entry which points to the physical server and use some cryptic name for the physical server... like cityserver01 or something just to differentiate it. That way when you replace cityserver01 with cityserver06, you just need to change the DNS pointer to start using it, as you don't have to reconfigure other systems pointing to it.
Re:An example (Score:3, Informative)
Yes, I have, but the managers in accounting and HR haven't, and could care less. They want their problems fixed, pronto.
Re:No acroynms, use short names/words (Score:5, Informative)
I agree, though I'd tend to suggest names which are more readily applicable to people's work vs. the cartoon names which are popular with most sysadmins.
For instance, a server which serves up a web service for HR might be called hr-web-1, and if a second one is needed, it gets hr-web-2. The record department file server would get records-files, and so on and so forth. The name of a system users need to access should relate to the role or work association of said server so the user knows, without a shadow of a doubt, that they're accessing the correct data.
Names like "daffy" don't do a damn thing for the user but make them feel out of the loop and possibly make them view you as somewhat amateur. That's not good on any level, and even obscure acronyms are preferable.
One place I worked would use names of the format "OperatingSystemDeptAbbrevRole", IE, W2KBUSFD for a w2k business office front desk system, and for servers they'd use the OS, role, and year of purchase (to keep easy track of assets w/o much documentation - IMO, not a good idea if it's the exclusive means, but it was the way things were when I got there, so...)
Naming user workstations in that fashion can be very useful if you need to perform on-site desktop/user support and can't do it all remotely, because you don't need to search an organization chart (or what have you) to determine where a system is before you run off to fix it.
Re:Keep it simple, stupid (Score:5, Informative)
I think it's a bad idea, especially with a small company, to name servers anything but functional names. If you have a single server providing (say) web, file, and print services, make an NS record with the duplicate service name or something.
That way it's much more difficult for someone to do something stupid to "lothar" (HR file/print) when they meant to do it to "legolas" (exchange server) and totally futz things up - say, a visiting contractor, your replacement (should you leave the company), or your boss (in the event that something "needs fixed" and you're out of town/$boss does not ask before touching).
Re:Nice short concise meaningful systematic names. (Score:5, Informative)
Two comments about location-based naming:
1: If you've got multiple geographic locations that require a duplication or replication of services, using the geographic location in the name makes sense.
2: You certainly would NOT want to use room or building location in a name for exactly the reason you cited.
Naming conventions are mainly for humans to understand the relationship of the servers and their duties, locations, configurations, etc. A good naming convention takes many of these elements into account. There isn't a single naming convention that's right for every situation, though being more specific and concise is generally better than not.
For example, a small company I worked for a number of years ago used Greek and Roman mythology. Zeus and Hera were the PDC and BDC, respectively. Apollo was the mail server. For our small environment, that made sense.
A bigger company I recently worked for used something much less creative - a combination of the subnet we assigned for the branch office, the role of the server, and a sequential number:
XXXYYsssnn ...where:
XXX was an abbreviation of the company
YY was the server role
sss was the subnet info
nn was the sequential number
It was difficult to determine exactly where that server was located physically, but it was easy to determine where it was on the network.
Both of those methods offer some advantages and have some drawbacks. If the first method were used in the second example, we'd have run out of names to use and nobody would be able to remember where each server was located physically OR on the network. Conversely, there wasn't any need to apply the second method to the first example as there was only a single location and a small number of servers to keep track of.
The larger your pool of servers, the larger the area in which they're dispersed, and the larger the differences in roles each server has, the more specific you'll need to be with naming.
Re:Keep it simple, stupid (Score:5, Informative)
Except your first rule should be "Do not ever add additional services to operating servers". If you have so much excess server power that you can just randomly decide to make your Exchange server also be a DB server, then you should be using virtualization to partition these servers anyway so that it will be transparent that they are sharing hardware.
Just this weekend, my company had a data center move scheduled, one of the servers was thoroughly documented as only being an MS Project server for one department, and so the outage was arranged. After moving it, another unrelated application broke. It turned out that at some point someone needed a database and so they just went in the DC and found an underloaded server and installed SQL Server on it and configured a critical app from another department to talk to it. The server had to be moved *back* to its original location until an entirely new change management process could be initiated now that a new dependency was discovered.
Also, even if you really *have* to add additional functions to a server, there's no reason you can't create additional A records in DNS with appropriate functional names for the new functions. Then you can still move those services to their own server later if needed.
I don't think the specific standardized naming scheme you use matters that much, as long as you define something sensible for your location and stick with it. My last job our naming convention was along the lines of where LOC was the three-letter airport code of the nearest major airport to that office, DEP was the three letter department code of the department who owned the server, and then FUNCTION and NUM would be something like web01 or db03 or such. That system worked for us but I don't think there was anything magical or perfect about it.
Those were the official system hostnames. We almost always created additional DNS A records if it was a public facing server that needed a more memorable name. But even then we had long since abandoned any "fun" naming scheme. In the earlier years, we had three basic naming schemes. All my internal application servers were named after dog food brands (since we were "eating our own dog food") lab QA machines were named after breweries, and build servers were named after bands.
That last one generated an amusing complaint post-9/11. There was a build server named "anthrax", which had been named that for many years. After the anthrax incidents in the US, we received a complaint that the name was inappropriate.
But that was around the time we were adopting a more formalized naming scheme anyway. I tend to agree with others that fun/funny server names don't really give off a professional vibe. It's probably fine for universities and certainly for personal systems, but for business services these days, even a small starter mom-and-pop, I would keep the hostnames generically location and function based, with location not being any more specific than the general location. It's okay to need to change a hostname if a server is being moved from Chicago to New York (though I would prefer to just set up a new server in New York and migrate the services there) but you shouldn't have to rename a server just because it moved to a new rack or onto another floor.
Re:Oh my god, it's full of themes (Score:2, Informative)
ah, you will never gat a goot IT guy then.
They usually follow the RFCs, like http://tools.ietf.org/html/rfc1178 [ietf.org] "Choosing a Name for Your Computer"
Re:Keep it simple, stupid (Score:3, Informative)
Actually, you should never use NTP in a virtual machine. Virtual machines perceive inconsistent clock ticks from their virtual CPU, which can confuse the holy hell out of NTP as it is constantly trying to predict the clock drift based on ticks.
At least, that's what some VMWare engineers told me at a conference once. But it was consistent with some problems I'd seen with NTP clients in VMs having problems keeping the clock synced.
As for "Where do I stop this virtualization thingie?" You stop it when it makes sense to do so. You probably shouldn't do it for an NTP server, but you should still pick the server you decide to add the NTP service to carefully.