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?"
Keep it simple, stupid (Score:5, Interesting)
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.
Several schemes (Score:5, Interesting)
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.
location/purpose naming (Score:5, Interesting)
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.
Re:No acroynms, use short names/words (Score:3, Interesting)
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.
Theme based schemes do scale beyond 60 hosts... (Score:5, Interesting)
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.
Mythology or religious characters (Score:2, Interesting)
Oh oh I know this one! (Score:5, Interesting)
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 [airportcodes.us] 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.
Re:No acroynms, use short names/words (Score:3, Interesting)
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" ;-)
Re:Keep it simple, stupid (Score:5, Interesting)
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.
The big companies I've worked for have always used the theme of mythical heroes/beasts (usually greek or roman, sometimes LoTR or something). I assume it's because they want to be able to shuffle the functions these servers are serving while keeping the name.
However, running a network for a small company, I've always chosen to keep it as simple as possible, and expect that I'm going to rename a server if I repurpose it. So, for example, the internal name for the mail server might be as simple as mail.[company name].local. I mean, if it's a small company and you know you're only going to have 1 mail server, then why not? If it's something like a fileserver, where i think I might have several general fileservers on the same site, I might do files01.[company name].local. Yeah, they might have to keep straight which server their documents are on, but they're only forced to remember a number, and they can figure the rest out.
I suppose that if I were dealing with multiple sites, I might try to have it structured something like mail.[location].[company name].local, but I don't know off-hand what the downsides would be of that. i guess really it depends on who's going to need to be finding these servers by name, and what those people need to know from the name. Do they need to know where the server is physically located?
Of course, you can always make aliases, and set up the client computers to search a set domain. One of my goals in naming is to be able to tell users that if they want to access webmail from inside the company, they can go into their browser's address bar and type "webmail". I want things to be that easy. Now that doesn't mean that the webmail is on a server called "webmail", but my DNS will point them to the correct place anyhow.
plain names and TXT records (Score:5, Interesting)
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.
Another error there (Score:5, Interesting)
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...
Re:Utilitarian (Score:4, Interesting)
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 [slashdot.org]. 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 [ptudor.net]. (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.
Re:Nice short concise meaningful systematic names. (Score:5, Interesting)
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.
Re:plain names and TXT records (Score:4, Interesting)
"Users don't really need hostnames"
only for network admins? Who are your "user's"?. I'm a developer, I'm a user and so are my peers. I have to ssh/vnc/remote desktop into multiple machines on a very frequent basis. A poor naming scheme makes my work annoyingly over complicated and forces me to frequently check a database telling me what the machines "are". why do i have to check?
we have a poor naming scheme where the name is a three letter internal designation for our product followed by the network bit. so if the machine's ip is XXX.XXX.XXX.123 its name is XYZ123; This is miserable because this encompasses windows2000,windowsXP, XP64, Vista32,Vista64; rhel3.5 32/64, rhel 4.4-4.6 32/64; rhel 5.1-5.2 32/64; solaris 10.5 (32 and 64) as well as solaris x86-64. Between vlans/virtual machines, multi nics (all have 2+, one for general use and point to point, the other dedicated for multicast..) we fill up several subnets. and with no guarentee that xyz100 is the same type of xyz101 its rather useless. Especially when I need to find a machine on the vlan of X of platform Y. It doesnt help that we only half use nfs and everyone logs in as root on all of these machines. even the windows ones have a user literally named 'root'.
In short: if you have developers names do matter. I'm not talking about naming your mail server or file server or dns server. I agree that no one gives a crap about them; we all are smart enough (or have people smart enough to automate for us the actions) to mount them (through whatever means provided by your workstation). Personally I mount most of those by IP because occasionally a name will go down or get stolen by a nitwit who doesnt realize its reserved. The caveat is also that those machines all have static IP's and the name scheme mentioned above. We recently had a problem where someone used a name already in use which lead to some real hilarity.
the only reason i raise this point is that some moron somewhere is going to (or read this and then going to) make the same profound statement without thinking about what the implications and context are. The result being that his developers suffer while he/she thinks they are "with it". That and lots of people throughout this whole tree of comments seem to be missing the distinction between the two. I wouldn't suggest giving cartoon names to file servers; give them names that are intelligent/useful or whatever.
save the fun and games names for the machines that are "virtually" yours; such that they have a meaningul name to the people who use them. Sorry but I shouldn't need to go to a database period. The machine's MOTD or a readme somewhere should be able to quickly give me whatever info I need that would be in the database that isn't somehow captured in the name.
whatever method you choose, there is one thing that should be universally agreeable: document the naming scheme somewhere accessible.
Re:Keep it simple, stupid (Score:1, Interesting)
"Except your first rule should be "Do not ever add additional services to operating servers"."
Because... why?
"If you have so much excess server power that you can just randomly decide to make your Exchange server also be a DB server, then you should be using virtualization to partition these servers anyway so that it will be transparent that they are sharing hardware."
And that's again... why?
On the other hand, should I use a virtualized server just for a new NTP server, or a DNS or a Wins replica? Where do I exactly stop with the virtualization thingie? Can I deploy a new java app at a server that already holds another? or do I deploy an enterily new server (either physical or virtual) for each and every WAR?
"Just this weekend, my company had a data center move scheduled, one of the servers was thoroughly documented as only being an MS Project server for one department, and so the outage was arranged. After moving it, another unrelated application broke."
So your IT services thoroughly documented a wrong reality and then things broke. Yeah, well, news at eleven.
"Also, even if you really *have* to add additional functions to a server, there's no reason you can't create additional A records in DNS with appropriate functional names for the new functions."
It's only that's what CNAME was invented for, not A. You are aware it exists the CNAME record, do you?
"That last one generated an amusing complaint post-9/11. There was a build server named "anthrax", which had been named that for many years. After the anthrax incidents in the US, we received a complaint that the name was inappropriate."
And we fired all our "Ahmeds" too in order to be politically correct.
This works for a 5000 server environment: (Score:3, Interesting)
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.