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?
...
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.
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.
How about using an SHA-1 hash of an incrementing counter? The first box is 356a192b7913b04c54574d18c28d46e6395428ab.company.internal, the second one is da4b9237bacccdf19c0760cab7aec4a8359010b0.company.internal etc. The mapping between counter values and machines is stored in an Excel spreadsheet, printed out and stored in the server room.
That way you get a unique naming scheme that's both logical, understandable (you can convert the host name into its counter value through a simple rainbow table) and reasonably safe from hash collisions.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)