Slashdot Log In
Best DNS Naming Scheme For Small/Medium Businesses?
Posted by
timothy
on Sun Jul 06, 2008 03:34 PM
from the elephant01-elephant02-elephant03 dept.
from the elephant01-elephant02-elephant03 dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I use porn stars (Score:5, Funny)
The guys at work seem to enjoy their time with Jenna quite a bit.
Re:I use porn stars (Score:5, Funny)
How much of a load can Jenna handle?
Parent
Re:I use porn stars (Score:5, Funny)
Three. Anyone can get in on port 80, 22 if she knows you, and 443 requires a little bit of negotiation.
Parent
Re:I use porn stars (Score:5, Funny)
Three. Anyone can get in on port 80, 22 if she knows you, and 443 requires a little bit of negotiation.
I would think port 79 would be a gimme for Jenna.
Parent
Re:I use porn stars (Score:5, Funny)
Just to warn you, a Jenna server will go down on you often, while still giving you plenty of uptime.
Parent
Re:I use porn stars (Score:5, Funny)
IOW more than a simple handshake.
Parent
Southpark Character (Score:4, Funny)
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.
Parent
Two words. (Score:5, Funny)
Body parts. Easy to remember.
"Where is that file?"
"In the nose."
Re:Two words. (Score:5, Funny)
There are enough anatomical details for the female reproductive system to provide a complete and scalable solution to this problem. Stop acting like you're new here, dammit :)
Parent
Nice short concise meaningful systematic names... (Score:5, Funny)
...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.
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.
Parent
Re:Nice short concise meaningful systematic names. (Score:5, Informative)
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.
Parent
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.
Parent
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).
Re: (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 reme
Re:No acroynms, use short names/words (Score:5, Insightful)
Parent
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.
Parent
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.
Parent
Re:No acroynms, use short names/words (Score:5, Informative)
I agree, though I'd tend to suggest names which are more readily applicable to people's work vs. the cartoon names which are popular with most sysadmins.
For instance, a server which serves up a web service for HR might be called hr-web-1, and if a second one is needed, it gets hr-web-2. The record department file server would get records-files, and so on and so forth. The name of a system users need to access should relate to the role or work association of said server so the user knows, without a shadow of a doubt, that they're accessing the correct data.
Names like "daffy" don't do a damn thing for the user but make them feel out of the loop and possibly make them view you as somewhat amateur. That's not good on any level, and even obscure acronyms are preferable.
One place I worked would use names of the format "OperatingSystemDeptAbbrevRole", IE, W2KBUSFD for a w2k business office front desk system, and for servers they'd use the OS, role, and year of purchase (to keep easy track of assets w/o much documentation - IMO, not a good idea if it's the exclusive means, but it was the way things were when I got there, so...)
Naming user workstations in that fashion can be very useful if you need to perform on-site desktop/user support and can't do it all remotely, because you don't need to search an organization chart (or what have you) to determine where a system is before you run off to fix it.
Parent
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.
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.
Parent
Re:Keep it simple, stupid (Score:5, Informative)
I think it's a bad idea, especially with a small company, to name servers anything but functional names. If you have a single server providing (say) web, file, and print services, make an NS record with the duplicate service name or something.
That way it's much more difficult for someone to do something stupid to "lothar" (HR file/print) when they meant to do it to "legolas" (exchange server) and totally futz things up - say, a visiting contractor, your replacement (should you leave the company), or your boss (in the event that something "needs fixed" and you're out of town/$boss does not ask before touching).
Parent
Re:Keep it simple, stupid (Score:5, Informative)
Except your first rule should be "Do not ever add additional services to operating servers". 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.
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. It turned out that at some point someone needed a database and so they just went in the DC and found an underloaded server and installed SQL Server on it and configured a critical app from another department to talk to it. The server had to be moved *back* to its original location until an entirely new change management process could be initiated now that a new dependency was discovered.
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. Then you can still move those services to their own server later if needed.
I don't think the specific standardized naming scheme you use matters that much, as long as you define something sensible for your location and stick with it. My last job our naming convention was along the lines of where LOC was the three-letter airport code of the nearest major airport to that office, DEP was the three letter department code of the department who owned the server, and then FUNCTION and NUM would be something like web01 or db03 or such. That system worked for us but I don't think there was anything magical or perfect about it.
Those were the official system hostnames. We almost always created additional DNS A records if it was a public facing server that needed a more memorable name. But even then we had long since abandoned any "fun" naming scheme. In the earlier years, we had three basic naming schemes. All my internal application servers were named after dog food brands (since we were "eating our own dog food") lab QA machines were named after breweries, and build servers were named after bands.
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.
But that was around the time we were adopting a more formalized naming scheme anyway. I tend to agree with others that fun/funny server names don't really give off a professional vibe. It's probably fine for universities and certainly for personal systems, but for business services these days, even a small starter mom-and-pop, I would keep the hostnames generically location and function based, with location not being any more specific than the general location. It's okay to need to change a hostname if a server is being moved from Chicago to New York (though I would prefer to just set up a new server in New York and migrate the services there) but you shouldn't have to rename a server just because it moved to a new rack or onto another floor.
Parent
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.
Parent
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.
Parent
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...
Parent
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.
RFC1178 (Score:5, Informative)
http://www.faqs.org/rfcs/rfc1178.html [faqs.org]
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.
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.
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: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.
Parent
We use a series of numbers (Score:5, Funny)
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.
interesting idea (Score:4, Funny)
Re:interesting idea (Score:5, Funny)
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.
Parent
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.
Function-based names (Score:4, Informative)
Having worked at two companies now with 8,000+ servers each, unless you're changing server roles all the time, function based names are best. Even in a small environment, I would recommend this scheme. Pad the names to at least two digits, more if your expectations require; i.e. 01, 02, 03. Site names based on local airport codes are also good. If you have multiple sites in one geographical area, suffix the names with 01, 02, 03, ...
Examples:
nagios01.sfo.example.com
nagios02.sfo.example.com
nagios01.phx.example.com
dns01.lga01.example.com
dns01.lga02.example.com
Some would argue against this for purposes of "security". I think this is flawed for several reasons:
1. It's security through obscurity, which is no security.
2. If someone's freely in your network, the jig is already up.
3. It only serves to complicate things when you get bigger, and inevitably go to function based names.
Cheeses (Score:4, Funny)
The University of Wisconsin CS Dept. used cheeses. Never seemed to have a problem with running out, although they named two machines kraft-slices and velveeta, and the lawyers moved in and made them change.
Incidentally, included among the cheeses were puff, whiz, and head (the latter is also a popular Wisconsin food product, so it's all good).
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.
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.
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.
Screw DNS (Score:4, Funny)
If they can't remember IPs, they shouldn't be allowed on your network.
Power Users must be able to identify machines by MAC as well as IP.
Admins must be able to do both - in hex, decimal, binary AND octal.
Octet delimiters are for pussies.
Dwarf Stars (Score:4, Funny)
Him: I dunno. How about... stars?
Me, looking at a smallish server: Okay, what's a famous dwarf star?
Him: Sneezy.
Re: (Score:3, Funny)
Didn't you get the memo?
SideShowMel replaced SideShowBob a while ago.
Re: (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.
Re:Short and Concise (Score:5, Funny)
what goes after Server0003?
Parent
Re:Short and Concise (Score:5, Funny)
...
Parent
Re:Short and Concise (Score:4, Funny)
On the other hand, It seems to be a genuine innovative idea using Morse for server names.
Parent
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.
Parent