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 guys at work seem to enjoy their time with Jenna quite a bit.
Body parts. Easy to remember.
"Where is that file?"
"In the nose."
...therefore all my servers are given a hostname string equal to the Dell "Service Tag", followed by a dash, followed by the Dell "Express Service Code".
I really love my junior admins, and whoever the poor schmuck is that will take my place as senior sysadmin once I'm gone from here.
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).
Your users really shouldn't have to know the name of any server, anyway. That's what shortcuts and mapped drives are for (pushed down via login scripts/GPOs).
Name the servers with logical names based on their function, and maybe an extra number to distinguish servers with the same function. Put all of the REAL info into database. Trying to put lots of config/location details into the DNS name is a waste of time. There no reason to have names like FILESERVER-CHICAGO-02-2003RT when FILESERVER2 would suffice.
We (somewhere between small and medium, branches in Germany, Austria and the US) use two naming schemes:
The primary scheme is [serverclass+#].[branch].domain.com This is what we, the tech staff, use for establishing connections for live systems and what we communicate to our users.
Examples would be mail1.berlin.domain.com, internalweb3.munich.domain.com etc. These names are more logical than physical, ie. one machine that offers several services via one IP is reachable under several names. This allows us to flexibly assign machines to certain roles.
The second naming scheme is what we use to identify the physical (resp. virtual) machines, versus the logical services. And it's simply Shakespeare characters. In my branch we went through the Tempest, the others started off with King Lear, Othello and another one whose name escapes me. We use those names only for reference and for management operations (SSH'ing, file transfers, whole-disk backups, virtual machine management), so our users never get to see those.
Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
There's a whole RFC on this:
http://www.faqs.org/rfcs/rfc1178.html
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.
As fun as it is to give servers clever names, only the tech savvy staff are going to remember the true purpose of that machine (oh it's a reference to the roman goddess of proxy caching... duh, what's wrong with end user!).
It's easier for users to follow the idea if naming conventions follow a logic pattern. My small company has locations in multiple states and use host names like cityFileServer or cityProxy. Once users understand the role of a particular server, it's a trivial task to use one physically located at a different site. This also helps prevent vague help requests like "the server is down" because they are able to articulate exactly what they are talking about.
If it's a network of equipment that will never be used by end users, hell make it clever as you can. Most of the IT staff are going to use the IP addresses rather than the hosts anyway.
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.
What we do is use a series of numbers separated by periods to designate a hierarchy. For example, the servers in the company all share the first number, say 192. Then, each department has its own number, say 168, giving us 192.168. Then, each location in the department has a number, such as 204, taking us to 192.168.204. Then we give each server a unique number, like 10, bringing us up to 192.168.204.10. It's very easy for me to recognize where a machine is by that address. We try to keep the numbers under 255 to make them easier to remember, and it's really not many more digits that a long distance code and phone number.
what goes after Server0003?
Make a Hash MD5 code from the location address of the server + it's Serial number. Use that for the server name. Or use a dictionary. start from a pre-determined random page and use the 3rd word on that page.then every server takes the 3rd word from the next page and so on... or start from 0001 and work up..
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
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.
...
Where I currently work, we manage 550+ AIX (and a few Linux) systems. I'm told there are also about 800 or so Windows images. They all have theme based names. Most AIX systems do have biological names, but a few are named after lakes and chemical elements. Windows I'm told uses car names.
Similar servers do get related names. For example, all chemical elements are Siebel systems, Oracle runs on snakes and TSM on nuts (main site) and monkeys (the backup site). IMHO, this works well, as it makes it easier to remember what server(s) demand your attention, and harder to confuse systems with too similar looking names.
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.
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.
I'm not a developer so I don't get to say all the cool things I do at work often here *grin*
OK, at my current employer there are about 100 or so servers in a single geoloc, so it's really no big deal to name them. My previous job was at a company with a few thousand boxes spread out over three timezones in four cities (in the US), India, Australia, the UK and Brazil.
I was not involved in the naming scheme project, but I thought it worked very well.
Basically, the machines were named as follows:
[three-leter tasking code][3 digit num sequence].[location subnet].[main subnet].[company name abbrev].com
So let's say the company was Mordor Corp. The FQDN for a web server box in the Portland data center would be:
WEB219.pdx.us.mordor.com
An app server in Brazil was:
APP416.ads.br.mordor.com
In the case of the servers in the US, initially they used the airport codes for the cities (Portland = pdx, Houston = iah, Ft. Lauderdale = fll, etc) but later we just came up with three-letter codes for some data centers because it was more intuitive (HOU is better than IAH). For the other countries, we used the generic 'ads' subdomain and the two-letter ISO country code.
The server types were:
STO - File servers
APP - Application servers (could also be web servers)
WEB - Web servers (dedicated)
SQL - Database (any type)
PDC - Primary domain controllers
SDC - Secondary domain controllers
EXC - Exchange servers
DNS - Guess
LIC - Licensing servers
TSS - Dedicated terminal services boxes
SRV - Generic servers (to be avoided!)
There were a couple more but these were the main ones.
This scheme worked very well because the identifiers and numeric sequences are mnemonic, but most importantly, it scales. Numeric sequences were assigned as servers were imaged and named, pulling the codes from a simple database application someone at the company wrote. The sequences were tasking-specific, meaning that APP servers were sequential and unrelated to the WEB sequences, for example. The only problem I ever saw with that was the situation where we had more than 1,000 server of a single type, but as far as I know that never happened. In any case sequences could be re-used as servers were retired.
I've seen server naming schemes that used cartoon characters, Star Wars figures, elements, celestial bodies, etc. None of them worked (or would have worked) beyond 100 boxes or so.
The twitter monologues. Click on my homepage and be amazed.
I agree on keeping it short and pronounceable over the phone.
Users don't really need hostnames. They get mapped drives through login scripts, and that works fine for the 10 to 50 hosts networks which I manage.
For the TLD of your internal domain, you cannot use .local anymore since Apple hijacked it a few years ago for their Rendez-vous thing or whatever. I now mostly use .lan, and also inherited a network which was using .private.
Then comes the company name of course, sometimes in a simplified form.
If distinguishing locations is important to you, you could use location-based sub-domains. But most times, it's not worth the trouble.
To keep various info about hosts (function, configuration, main user, etc.), I had a small database (could also be a spreadsheet). Then I realized I could keep everything in DNS too. So for the last years, I have just used TXT (and sometimes also HINFO) DNS records. Since DNS zone files need to be edited anyway when there are changes, the rest of the info is done at the same time in the same file. And it can be queried from anywhere with plain DNS tools. (In fact I have this very handy alias for searches: alias hostinfo='host -l -a mydomain.lan | grep -i ')
As for non-offensive names, at one place using Greek god names, the boss wanted his notebook named Eros. I don't think anyone would find it offensive, but I'm not sure the boss realized it would be visible in Network Neighborhood. Anyway, probably nobody noticed. As mentioned, users use shortcuts and mapped drives. Nobody cares about names. It's only for network admins.
Good security would mean not showing information that would make lives easier for the bad guys.
Do not show the OS and it would be smart to not show what they are actually doing as well. There may be some scumbag that realises that "za1w2k7dc123" would be a very useful machine to hack into and we now know what weaknesses to try and exploit...
I'll see your Constitution and raise you a Queen.
We had a test server which started off as something bland but since it was a test server people kept crashing it often. It became affectionately known as "Kenny". Now everyone just says "Who Killed Kenny!" when it dies a horrible death.
Using both the service tag and the express service code is a little redundant isn't it?
We use the service tag in all of our workstation names with a dash and room number. If they are in a lab, we use a 2 letter short code for the lab and then the computer number. When we set it up in AD, we add the primary user or primary function in the description.
Using the location in the name give the name a lot more value when looking at logs or reports. When we look at the computer name in say AD, we know we have to correct one just by knowing the room number. Its easy for people to communicate changes to use without having to know the entire name.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
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.
My sources are unreliable, but their information is fascinating. -- Ashleigh Brilliant
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.