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?"
No acroynms, use short names/words (Score:5, Insightful)
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).
An example (Score:3, Insightful)
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.
Re:An example (Score:5, Insightful)
Depending on your business, you may not need all those things. The original post asks about "small/medium" business... but when you have that many machines, you're clearly a 'medium' business. Small businesses don't need all that.
Also, why are people so hesitant to use multiple levels of DNS domains? Couldn't that server also be named mark-pfs-01.sjc.whatever.com? That way, everyone in SJC knows it just as "marketing production file server 01". Only people off-site need to realize that it's in SJC.
Utilitarian (Score:4, Insightful)
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
Re:We code names by location and function. (Score:3, Insightful)
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.
My scheme.. (Score:5, Insightful)
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.
Pubs (Score:3, Insightful)
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.
Re:An example (Score:5, Insightful)
This is the worst advice I've seen so far, but far too common, alas.
It breaks the rule that the server name should be easy to say over the phone, and that no single typo should cause an issue.
Try playing chinese whispers over the phone with sjcmarkfilep01 a few times, and you'll see why it is stupid. Heck, just try to talk someone through entering the name.
And then someone makes a typo, instructing support to install a new card in sfcmarkfilep01, which also happens to exist, and be vital for San Fransisco operations. An oops that could have been avoided with a smarter and typo-resistant naming system.
Also, why avoid subdomains? What's wrong with marketing.sanjose.internal? That way, you can do "ping dns" and reach dns.marketing.sanjose.internal, and ask someone to take a look at the secondary file server without having to spell out sjcmarkfilep02.
Anyhow, if you want convoluted names like these, make them secondary names. There's nothing that would prevent peter.sgi.com from also being known as b.dns.internal.sgi.com.
can't stand themes (Score:5, Insightful)
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.
Re:An example (Score:3, Insightful)
No, I'd say it's a pretty good scheme.
A naming scheme based on cultural references is bound to fail as soon as you deal with non-english speaking backgrounds. SideShowBob is probably only good for US/Can/Aus/Nz/UK. Telling one of our Russian counterparts to look for SideShowBob01 is not going to work.
- ISO standard Country codes (3 characters)
- Site number within country (1 digit, we only need one)
- O/S NT based, LX based, MC based, A4 for AS/400
- WS Workstation, FS (File)Server, DC Domain Controller.
- Unique number. 3 digits only are needed here for us.
We have a flat DNS space. One domain. Works for us.
But it's probably a good idea to have your DNS managable by the local IT support. Three timezones is best handled with 3 DNS domains (AfEurope, Americas, Asiapac).
People tend to realise which resources they are commonly connecting to. And mostly that should be scripted. Anyone else is going to be careful what they type.
Job's done.
My test domains on the other hand are a much funner place. Bundys, Flintstones, Simpsons and Family Guy are good targets. Keep the group membership based on family and you do have an easy to remember scheme. Bit characters are always good for testing unauthorised access.
Use both - hostnames are NOT service names. (Score:1, Insightful)
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.
Re:An example (Score:3, Insightful)
Fucking horrible idea, but the same thing the company I work for is going to. Just sucks, horribly confusing, obtuse, hard to remember what is what.
I like the subdomain idea much better. Keep it simple. someserver.somelocation.companyname.com.
Re:Keep it simple, stupid (Score:3, Insightful)
Re:No acroynms, use short names/words (Score:5, Insightful)
Go to a utilitarian hierarchy and role naming (Score:3, Insightful)
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.
Re:RFC1178 (Score:3, Insightful)
MOD THIS COMMENT UP (Score:3, Insightful)
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.
Re:Keep it simple, stupid (Score:3, Insightful)
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.....
Re:Nice short concise meaningful systematic names. (Score:3, Insightful)
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.
Stupid idea (Score:5, Insightful)
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.
Re:Keep it simple, stupid (Score:3, Insightful)
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.
Re:No acroynms, use short names/words (Score:3, Insightful)
We actually did this on a network that I ran for a while. Servers were birds of prey (kestrel, hawk, eagle), internal servers were flightless birds (kiwi, ostrich, etc.) Mac workstations were waterfowl (mallard, egret, swan, flamingo), laptops were rodents (rabbit, woodmouse, groundhog), fileservers were large herbivores (rhino, hippo, etc.) Linux workstations were types of deer and related species (ibex, impala, moose) and I reserved the entirety of aquatic invertebrates for naming Windows workstations (cuttlefish, octopus, squid, sponge, sea_cucumber) but that might just be personal prejudice. The other aspect of this that worked nicely, is that I reserved names for various floors in the building or remote locations for different geographical areas, so I knew that hippo was a fileserver on the 2nd floor of the main office (Africa) while bison was a fileserver on the 1st floor (North America). This requires a bit of pre-planning since you are allowed more linux workstations in Africa than in South America, but on the plus-side, almost all of those names are your spellchecker, and a lot of them, people have actually heard of which mean fewer errors and questions. It also gives you a simple way to physically identify the host -- I put little pictures on the cases.
Use DNS fully to make it easier (Score:4, Insightful)
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.
Re:No acroynms, use short names/words (Score:2, Insightful)
No, it's not at all trivial; believe me, I've done it. The machine's canonical hostname tends to find its way into all sorts of places, and you'll be finding random small things have broken for months afterwards.
And if you're just adding a service to the box, it's pretty trivial to point a CNAME record to the same address.
So now your users are using multiple hostnames to access the machine, one of which behaves subtly differently from all the others (e.g. you spend hours looking for hr-ntp-1 in the logs, because you can usually find the right machine that way, until you remember hr-ntp-1 is actually hr-fileserver-3). Which is not a good situation; far better to have all the user-accessible names be CNAMEd, and then you get consistent behaviour from everything.
you do NOT want the possibility for someone with authority over you and a degree of technical prowess to discover your disdain for them or your lack of professionalism.
Or you could just be professional about it. Obviously "pointyhairedboss" is not a good hostname, but there's nothing objectionable in using cartoon characters, star trek ships, greek gods or any of the other common suggestions; if one particular one causes trouble ("Eros"), there's no problem just leaving it out.
And, I should note, I intentionally stated "hr-web-1" and "hr-web-2" in the original post, as this leaves hr-web available in the event that they're doing load balancing or some other shared role task. You're still able to string as many machines on the back as you want, and use a single address for access.
That's fine for the web stuff where you know ahead of time you'll need more than one, but there are many cases where you would think there's no way you're ever going to need more than one machine for a given service and then two years later you do. I suppose you can avoid that by numbering in all cases, but that feels a bit clunky.
If you MUST use a 'nickname' to refer to a machine, make them comply with a naming convention involving purpose/role/location: no proper names, so as to aid in identification (ie, finding "it-w2k8-153" in logs is much more useful than finding "lothar" in logs, when you're not immediately aware of network topography - and it makes it much easier to identify systems on the network which shouldn't be there, or doing specific things they shouldn't be doing.)
Every piece of information you might put in a name could change, and sure, you can put effort into keeping all the names up to date, but it's not the correct place to keep that information. Also, a scheme like that makes it a lot easier for an attacker to set a hostname that fits in, and it won't be as easily noticed because they're all just meaningless letters and numbers to a human taking a quick glance.
The machine's hostname is not a reliable or effective place to keep any piece of information about the machine or its role. All you can aim for is something which will be unique, make it obvious that it's a computer, and human-readable/memorable.