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.
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.
Even Jesus hates listening to Creed.
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.
I've worked in shops with 100 boxes to 10,000 boxes. Having systems with cute names from a movie or theme works for a while, but the system starts to break down once replacement machines start entering the network.
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
Didn't you get the memo?
SideShowMel replaced SideShowBob a while ago.
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.
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.
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.
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.
Yes, I am a smart ass; it's better than the alternative.
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).
...
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.
If you can't name more superhero characters than you have servers then either...
(a) We're going to take your official geek card away.
or (b) You should already know more about naming conventions than anyone reading this.
Seriously, there shouldn't be a problem with a mix and match scheme. For instance, name a typical server ohio-27-002.mycompany.com but use DNS to give the important ones a second name as in wolverine.mycompany.com
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
Must be an enterprise system. They're always a bit slow to upgrade.
rewriting history since 2109
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 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
- 1st letter : S for Solaris, L for Linux, W for Windows, etc.
:
- 2nd letter : P for Production, T for Test, etc.
- After is the shortened name of the service : DNS, FTP, etc.
- And end it with some incremental numbers : 00, 01, etc.
So it might look something like
SPDNS00 or LTFTP01 or WPEXCHANGE01
But its locale is set to de-DE! A system that speaks German can't be a bad system.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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.
One thing we do in our internal network is to have two sets of names. One set is logically named and reflects a specific purpose. For example, "svn.internal.tld", "db.internal.tld", "web.internal.tld". 'svn' is the svn server, 'db' is the db server, and so on. The same machine can potentially be mapped to from many of these names (for example, 'svn' and 'db' may resolve to the same IP).
When we write our internal scripts and configure our software, hostnames are ALWAYS specified using the logical function names.
On top of this, each of the physical machines has a unique name for itself, following whatever arbitrary naming scheme we choose (in our case, it's fruits: lemon, orange, etc.). We use this name when talking about actual machines with problems (e.g. "lemon just went down").
It works well enough for us. When we move services, we don't have to change our internal scripts or configuration at all, just change the dns reference for the given service. The nicknames allow us to talk about each individual machine easily.
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.
Learning HOW to think is more important than learning WHAT to think.
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.
... servers name you?
Why use alphabet soup in the name when you can fully exploit the capabilities of DNS?
What I did on a slightly smaller network than the one you're proposing is this:
As an example: you have two offices (Boston and Miami). In each you have three roles: printserver, fileserver and gateway, and one machine in Miami and two in Boston. The themes would be Maniac Mansion and BOFHs. You end up with:
Boston (domain bos.example.com):
edna IN A 192.168.1.1
bernard IN A 192.168.1.2
hoagie IN A 192.168.1.3
gateway IN CNAME ed
fileserver IN CNAME bernard
printserver IN CNAME hoagieMiami (domain mia.example.com):
printserver IN CNAME pitrsimon IN A 192.168.2.1pitr IN A 192.168.2.2
gateway IN CNAME simon
fileserver IN CNAME pitr
You then give your users only the alias.
Doing things that way, you can easily locate each server. You can make a reference to a particular server easily and you can shuffle tasks around just by changing CNAMEs. The users can access everything with little hassle (fileserver for the local fileserver or full FQDN for the CNAME for a remote one). You can also delegate easily and should you need it, you can add extra levels. You could add country codes after example.com in case you open an office in Vancouver changing your hierarchy your names to:
fileserver.bos.us.example.comprintserver.van.ca.example.com
or even add extra levels under the city names if you need:
fileserver.hq.bos.example.com
fileserver.researchlab.bos.example.com
WTF is happening to slashdot? When I mean plain old text, I should not need to type those stupid html tags! Sorry about the odd spacing in the zone files.
GPG 0x1B479C78
MOD THIS UP
This is some of the best advice in this thread, and it really needs to get some mod points to help counteract the stupid advice of "use comic book character names!" and single-level schema topography.
This guy's advice works because:
1) it scales to any size organization
2) it identifies the actual equipment
3) it identifies the equipment location
4) it identifies what the equipment does/how it fits into the organization
Aside from scaling well and being able to tell you where, what, and how, there's little more than a naming scheme should do.
There are times when you know you can use less without impeding future deployments (such as a geographically-isolated business which would be unable to expand), and that's OK. But for the most part, reducing yourself to a naming convention with a namespace of only a couple hundred variants at best (comic characters, etc.) which tells you -nothing- about what you're looking at is problematic.
Here's a funny one for you which will cause nightmares: systems named after firearm cartridges. So you get things like: 22lr, 223rem, 556x43, 270win, 762x39, 762x59 - and so on and so forth. Then you've got the additional problem of having two different naming conventions for a cartridge, and you start having problems (ie 308win vs. 762NATO vs. 762x51 - all essentially identical cartridges). Just... don't.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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
Brings new meaning to picking through your files....
When I first began my last admin job, the management insisted on using the room name as part of the computer name. Eventually the technicians revolted after having to move rooms full of computers several dozen times per year.
I instituted a new system, made up of a short prefix based upon the device type, followed by the asset tag number. This had the added benefit of making sure that devices were asseted before they could be set up.
SV-100001 (Server)
WS-100002 (Workstation)
LT-100003 (Laptop)
PR-100004 (Printer)
Et cetera
Virtual machines are a bit special since they do not have a physical asset tag. We decided to simply allocate numbers to them sequentially, starting at VM-00001.
For servers, we would often create a friendly name, in the form of a DNS CNAME pointing to the actual name.
$TTL 3600
$ORIGIN internal.domain.com.
tiger IN CNAME SV-12345
Had I took the time, I could have programatically added DNS HINFO records using data from the asset management system, and maybe even a TXT record containing the room, floor, building and site address.
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.
You must agree with your GP that that's certainly short and concise.
On the other hand, It seems to be a genuine innovative idea using Morse for server names.
I was building servers with another guy once. I asked him "what should the naming scheme be?"
Him: I dunno. How about... stars?
Me, looking at a smallish server: Okay, what's a famous dwarf star?
Him: Sneezy.
Assume I was drunk when I posted this.
ah, you will never gat a goot IT guy then.
They usually follow the RFCs, like http://tools.ietf.org/html/rfc1178 "Choosing a Name for Your Computer"
Atari rules... ermm... ruled.
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.
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.