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
TOO SHORT
Why only 2-character codes? Host names can be long.
Here's what happens when you go with that kind of naming scheme.
LOCIPDD1
LOCIPDQ1
LOCIPDP1
LOCIPDP2
LOCDDQD1
LOCDDAP1
LOCAPCP1
LOCAPDP1
It goes on and on. Now try saying PDD and PDP over the phone and see how well that works.
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.
When I was at the University of Edinburgh back in the 1980's, I seem to remember the CS workstations being named after pubs in the city. That worked since there are so many pubs in Edinburgh - practically one on every street corner. It worked pretty well because the names were distinctive and recognizable, and it was at least a little humorous. I think it's better to use a set names that people already recognize, since the brain is really good at recognition. Abstract names are not so great, since they require conscious effort to memorize.
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.
Why do people seem to almost always associate a hostname with the service/application that the host provides? (Don't get me started on applications that bake in the hostname into their configurations and can not be configured to bound to certain IPs.)
For hostnames, we use some type of theme. For example, our e-mail gateways use the messaging gods (hermes, mercury, etc). For our file service cluster we used Matrix characters (neo and trinity). Then we overlay service names that the application and clients use like smtp.example.com, mx.example.com, imap.example.com or ifs.example.com. These service names AND applications are then bound to virtual IPs.
We also try to not reuse hostnames. That way when we talk about "medusa", we know what physical box we are talking about and don't get in to the "which box/generation of medusa are we talking about" issue. On the other hand, service names just move from box to box as upgrades take place all unknown to our users.
To us the hostname should not be known by anyone outside of the sysadmins group. Our users just care about the services that our servers provide and as long as they can connect to imap.example.com, they are happy.
I use two letter site code + function + two digit numeric ID, so your example server would be CHFS2, easy for anyone familiar with the system to decode. As far as my users, we use DFS to point them to file resources, short DNS names for web apps, and everything else is published as a Citrix application. They basically have to remember two things, what drive letter to save to and how to get to the Citrix page.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Why use alphabet soup in the name when you can fully exploit the capabilities of DNS?
What I did on a slightly smaller network than the one you're proposing is this:
As an example: you have two offices (Boston and Miami). In each you have three roles: printserver, fileserver and gateway, and one machine in Miami and two in Boston. The themes would be Maniac Mansion and BOFHs. You end up with:
Boston (domain bos.example.com):
edna IN A 192.168.1.1
bernard IN A 192.168.1.2
hoagie IN A 192.168.1.3
gateway IN CNAME ed
fileserver IN CNAME bernard
printserver IN CNAME hoagieMiami (domain mia.example.com):
printserver IN CNAME pitrsimon IN A 192.168.2.1pitr IN A 192.168.2.2
gateway IN CNAME simon
fileserver IN CNAME pitr
You then give your users only the alias.
Doing things that way, you can easily locate each server. You can make a reference to a particular server easily and you can shuffle tasks around just by changing CNAMEs. The users can access everything with little hassle (fileserver for the local fileserver or full FQDN for the CNAME for a remote one). You can also delegate easily and should you need it, you can add extra levels. You could add country codes after example.com in case you open an office in Vancouver changing your hierarchy your names to:
fileserver.bos.us.example.comprintserver.van.ca.example.com
or even add extra levels under the city names if you need:
fileserver.hq.bos.example.com
fileserver.researchlab.bos.example.com
WTF is happening to slashdot? When I mean plain old text, I should not need to type those stupid html tags! Sorry about the odd spacing in the zone files.
GPG 0x1B479C78
an rfc is just a story that someone thought might not get laughed at too much. don't take them too seriously until people start targeting them as a specification. The most sensible thing you can do IMO is just use subdomains (it's not that painful honestly) and then name your machines after their function. You can always map multiple names to one machine, and then you can merge or split them later at will, in theory without the users being any wiser.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
MOD THIS UP
This is some of the best advice in this thread, and it really needs to get some mod points to help counteract the stupid advice of "use comic book character names!" and single-level schema topography.
This guy's advice works because:
1) it scales to any size organization
2) it identifies the actual equipment
3) it identifies the equipment location
4) it identifies what the equipment does/how it fits into the organization
Aside from scaling well and being able to tell you where, what, and how, there's little more than a naming scheme should do.
There are times when you know you can use less without impeding future deployments (such as a geographically-isolated business which would be unable to expand), and that's OK. But for the most part, reducing yourself to a naming convention with a namespace of only a couple hundred variants at best (comic characters, etc.) which tells you -nothing- about what you're looking at is problematic.
Here's a funny one for you which will cause nightmares: systems named after firearm cartridges. So you get things like: 22lr, 223rem, 556x43, 270win, 762x39, 762x59 - and so on and so forth. Then you've got the additional problem of having two different naming conventions for a cartridge, and you start having problems (ie 308win vs. 762NATO vs. 762x51 - all essentially identical cartridges). Just... don't.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
I absolutely disagree with this. You may have a vision of the function of a server in the beginning, but those functions morph. You can make DNS aliases that go with the function, but don't name the *machine* those functions.
When you do that you end up, as I have seen people do, with a web server named mail and a mail server named db1. And don't tell me you should just rename the server, either.....
When I first began my last admin job, the management insisted on using the room name as part of the computer name. Eventually the technicians revolted after having to move rooms full of computers several dozen times per year.
I instituted a new system, made up of a short prefix based upon the device type, followed by the asset tag number. This had the added benefit of making sure that devices were asseted before they could be set up.
SV-100001 (Server)
WS-100002 (Workstation)
LT-100003 (Laptop)
PR-100004 (Printer)
Et cetera
Virtual machines are a bit special since they do not have a physical asset tag. We decided to simply allocate numbers to them sequentially, starting at VM-00001.
For servers, we would often create a friendly name, in the form of a DNS CNAME pointing to the actual name.
$TTL 3600
$ORIGIN internal.domain.com.
tiger IN CNAME SV-12345
Had I took the time, I could have programatically added DNS HINFO records using data from the asset management system, and maybe even a TXT record containing the room, floor, building and site address.
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.
Being a user of Xen myself on small server sites, I prefer to name servers somewhat randomly and give them additional A records for their functionality.
That is, Legalas.test.local and Intranet.test.local may both resolve to the same IP, but I can move Intranet to another server and still know what the name is of the specific box that was previously the fileserver.
My way, regular clients connect to the common names, whereas technical staff connect to hardware names. CNAMEs are also appropriate under some circumstances.
- Michael T. Babcock (Yes, I blog)
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.