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?"
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.
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.
Although I have done away with using names due to the size of the company I now "host". I used to use Cartoon Characters for all of my servers:
Sun Servers: Dilbert Names, Transformers, and Go bots
Linux Servers: Hanna Barbera, Disney, and Universal Pictures Cartoon Characters (Woody, Chilly, etc.)
Windows Servers: Scooby Doo and Misc names.
Find a schema that works for you though. If your line of work is in a specific industry, perhaps you should use that as a guideline when choosing as it may help others remember the servers better.
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.
I tend to pick a religion or set of mythos and just go with the varied names therein. I have a domain with Hades, Ares, Zeus, Athena, etc. I also did a Hindu one with Shiva, Kali, Lakshmi, Ganesh, Vishnu, etc. Hard to get them mixed up that way, and you can generally tell which are related by their names.
People are like slinkies; useless but fun to watch when you push them down the stairs
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.
Don't use themes that are hard for illiterate slobs or new-to-English folks to spell properly. I remember at one company I worked, the art director decided that all the art machines would be named after famous artists, especially her favorite: impressionism masters. Yeah, right, let's connect up to matisse, gaugin, renoir, manet, monet, delecroix, macchiaioli, or seurat, there's a file on there I need.
Actually, there is some wisdom in using names that are hard to spell.
At the college I attended, there was a convention to name shell servers after minerals. (My memory is a bit hazy here, so consider this as "based on my vague recollection of a true story").
The first shell server was called "safir" (sapphire in Sweden). Nice and easy. There was a CNAME called "shell" too that you were supposed to actually use, but nobody really cared, or realised it could be a problem.
Then they got a new server, rubin (ruby), instead. Lots of scripts broke, as well as hardwired reflexes to type the hostname "safir".
Next time it was time to install a new server, they called it quetzalcoatlite. :-)
Since that day everybody has just learnt to type "ssh shell" ;-)
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.
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
Thank you for understanding DNS.
I've worked at crazy places where type of device, location, and all that were crammed into the hostname, just like this post. I blame people not using subdomains or .local for active directory. Oh, and removing vowels. If a software application was called "Pacific Beach" the machine name would contain it, condensed to PcfcBch with an 01 at the end. Come on people, our language has vowels, use them.
Also, the world is a better place with tinydns at the top of your hierarchy. It's easy to convert from BIND. (even though i do use bind9 slaves as v6 listeners.)
Someone else made a comment about the hostname "fileserver01.servers.production.marketing.sjc.somecompany.com" and I'll confess I love it. Better than calling it "hitchcock.somecompany.com" and leaving it for someone else to figure out in five years.
IPv6 is another consideration; people do make a valid point that it is inconvenient to type 2620:0:c0:f010:218:e7ff:fe17:cad8/64 but at the same time I find it ridiculous that people will just read off IP addresses like 172.18.19.20 in large organizations. But that's what DNS is for.
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.
My team supports around 2000 Unix servers, we have about 3000 Windows servers admin'd by my counterpart's team, and the naming schemes we're using seem to mostly work. Each server has (at least) 2 names. The system gets a hardware name like t2k123, and then a logical name, like clarify-web-prd-01. This way, I know it's a Sun T2000 (t2k), it has a number (123), and it's used for clarify, it's a webserver, it's production, and it's #1 in the (in this case) cluster. There's probably also a clarify-web-prd-02 which will be on hardware that isn't t2k123. And somewhere I bet there's a clarify-web-stg-01, a clarify-web-dev-01, and maybe even a clarify-app-prd-01 and so on.
This answers the important questions: Whose program is it for? What does it do? What's the criticality, and which one is it?
I suppose you could work location into the hardware name, but a simple spreadsheet or a file on the box saying where it is (building, room, rack) is just as effective.