Slashdot Mirror
Best DNS Naming Scheme For Small/Medium Businesses?
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?"
The best suggestion I can think of right now is to use short names or words and NOT use acronyms, because you'll end up with lots of people either not remembering the acronyms (typing them with typos) and/or not remembering which acronyms are associated with what.
Using something that should be familiar to most employes and not offensive to anyone would also help, especially when they call for tech support.
As a reference, on my network at home all the computers, servers and even devices have names from the Metroid games (Zebes, Samus, SR388, etc).
A good host name should denote the following:
-location
-department/cost center
-purpose
-prod/stage
-some sort of serial # to make it easy
Depending on how your sites are named (I like using airport codes but it might not scale right for your org), you could wind up with:
sjcmarkfilep01
Which would denote san jose office, marketing, fileserver, production, 01.
Adjust as necessary for your use.
Even Jesus hates listening to Creed.
I've worked in shops with 100 boxes to 10,000 boxes. Having systems with cute names from a movie or theme works for a while, but the system starts to break down once replacement machines start entering the network.
Probably the best naming scheme was first sub-domained by airport code and/or country code:
jfk.us.domain.com
lgw.uk.domain.com
If that doesn't work, you can also do city.country.domain.com
Once you've got your subdomains worked out, the machine host name ends up being the function, or a code you've designed to indicate function (since you don't want to tell everyone what your boxes do). You probably also want to include a numeric component as well. ie NS3, NI2 (Network Infrastructure ie DNS, DHCP, routing, firewall, etc). Make sure you document what each designation machine does, that way people don't start running around naming things incorrectly.
I like this system because it allows for growth, replacement, and tells you something useful about the machines if their name shows up in a log somewhere.
I would argue that many of your users don't need to touch the machines, especially those in production. If there are some that users need to access, you can always create a CNAME to give them that gets them to a box that already has a name in your organized naming scheme.
Hope that's useful.
-Runz
It doesn't really matter what you name the machines, so long as they are unique names. At my company we use the names of sugars for all our Linux machines, and alcohols for all our macs.
Now, the important part is just to use aliases for all services. So for example, if SMTP runs on a machine called dextrose, then create a DNS alias smtp.department.company.com that points to that server. If there is more than one server providing the service, you can either use round-robin DNS (if it doesn't matter which one is used), or just provide a numerical suffix to the alias.
If you have a compute cluster, I strongly recommend numbering the machines sequentially, then you can use a tool like PDSH or bash {} expansion to address groups of machines.
We used to use theme-based naming schemes
oh god please no.
Our machines were named based on themes, and that's the WORST idea on the planet. If you are going to give things names, things that need to be immediately recognized for what they are. If you have too many to give them logical names, then name them as radically different as possible so you can tell them apart in a heartbeat. The whole point of naming them is to avoid confusion, or we'd just number them wouldn't we?
Name them Orange, Peanut, Chrysler, Diamond, and Dolphin. Pick names that are not easily confused. Stay away from names that identify people or places, to avoid other communications issues. "Tom has that" should not leave you wondering if Tom is a server you don't usually work with, or is someone named Tom. Same for "Where's that database? Detroit?"
I have to deal with one group of servers that are all named by Star Trek (TNG) ship names. And at another location they are all weather phenomena. BAD IDEA. I don't deal with the trek machines much and they just can't understand why I can't remember the difference between Enterprise and Intrepid. Sure if you deal with them daily you'll get the hang of it, but picking similar names is a nightmare for anyone unfamiliar with the system. If we only had one space ship for a server I could associate that uniqueness with its purpose. But no, I'm thinking "OK the firewall runs on the spaceship... oh ya that's right we have SEVEN of those... was it DS9 because it's a station? Maybe Defiant because it's defying the hackers? OK where'd that list go?"
NO THEMES
And if you're tempted to use a different theme for each location, just DON'T. What's more important to you, being able to tell what a machine does, or knowing where it's at? If you do theme by location, all you're going to clarify is where it's at.
I work for the Department of Redundancy Department.
As others explained these strict naming schemes are a stupid idea. First of all they indicate you have no documentation and rely on hostnames to document your network. They are painful to read/type. Hard to spell over the phone. Confusing when you add an ftp service to spdns000. Typos are easily made (ltftp01 is rebooted instead of lsftp01). Naming errors are bound to happen (what do you do when you notice an error a few weeks after a server has been set up but only discovers it now when the hostname is already in dozen of config files, do you waste time fixing something that, in the end, is completely irrelevant ?). The naming convention also totally breaks when you merge or collaborate closely with another company with not the same naming convention. Etc. I could go on and on.
Here is what works: a naming convention with no specific rules. Just use unique names, not too exceedingly hard to type or remember. Use CNAMEs to represent functionnality. Encode the location in subdomains. Example: {shrek,moon,highway}.{losangeles,newyork}.company.local, with 'webmail' pointing to the right servers in the 2 locations. If you are afraid to not remember what is the OS/purpose of highway.newyork.company.local, then look it up in your network documentation.
What do you do when a server moves?
How often do servers move anyways? They're not notebook PCs, they are big heavy iron boxes, often bolted into a chassis in a room visited by no-one but sys-admins. If a server is physically relocated it is generally regarded as a significant event. Might as well give it a new hostname as well. If you think that is a hassle to users, well that is what CNAME records are for. Nobody said the hostname of a server has to be the only name that can be used to find a server.
General guidelines say you shouldn't put the computers location in the name.
What general guidelines are these? I've not seen anything forbidding the practice, and in fact it has been requested by some outfits I've worked with that hosts be named based at least partly upon location, especially when the site is large and in separate buildings. It is really a pain to have to get out a network architecture drawing to figure out where an errant server is because it is named solely for its function, and it is impractical to go searching for it because it could be down the hall or it could be in a building on the other side of a site that is 3 km long.
How 'bout making full use of DNS capabilities and subscribing to one system of naming hosts and use CNAME records to provide preferred names for users to use?
If a server is named after building/room/rack it can be easy to track down problems and you need physical access to the server to resolve them. CNAME entries like WWW, FTP, MAIL and so on can be used to give them functional names.
Cutesy theme names might be confusing to some, but there can also be issues with badly chosen functional hostnames of any type that make them about as useless as IP addresses for remembering what hosts are what. To get around various Windows networking shortcomings hostnames sometimes have to be short, and too much info gets crammed into them to the point they become meaningless. What the hell is VAN01AP5B anyways, besides hard to type or remember? That is where properly using DNS subdomains could be better used too. AcctPay-5B.Admin.Vancouver.example.com is much more descriptive and the hostname is easier to type and remember (AcctPay-5B). Computers local to the server in question (the most likely users) could type only the hostname and not the FQDN, and of course CNAMEs can be used to assign more concise names.