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?"
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?
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.
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.
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.
Re:I use porn stars (Score:5, Funny)
IOW more than a simple handshake.
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.
Re: (Score:3, Funny)
Just a warning, this is not an ideal naming scheme as we found out the hard way after we had a customer call and demand to know why we had a server named after him. (John Holmes)
Two words. (Score:5, Funny)
Body parts. Easy to remember.
"Where is that file?"
"In the nose."
In the nose (Score:3, Funny)
Brings new meaning to picking through your files....
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 :)
Re: (Score:3, Funny)
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.
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.
Re: (Score:3, Insightful)
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 (Printe
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.
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)
Re: (Score:3, Insightful)
We actually did this on a network that I ran for a while. Servers were birds of prey (kestrel, hawk, eagle), internal servers were flightless birds (kiwi, ostrich, etc.) Mac workstations were waterfowl (mallard, egret, swan, flamingo), laptops were rodents (rabbit, woodmouse, groundhog), fileservers were large herbivores (rhino, hippo, etc.) Linux workstations were types of deer and related species (ibex, impala, moose) and I reserved the entirety of aquatic invertebrates for naming Windows workstations (cu
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.
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: (Score:3, Funny)
Ah, that's a fun system. I use Starcraft hostnames in my house:
Old Desktop: Goliath
Server: Overmind
Router: Nexus
Wii: Pylon
New Desktop: Tassadar
I was thinking if I ever got a small, low power 24/7 mini box, I'd call it Zergling.
I know the tech people at RPI name internal domain names after pokemon - I get the feeling there are more of those available now than network addresses that can fit in the IPv4 space.
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.
Re: (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
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: (Score:2)
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.
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).
Re: (Score:3, Insightful)
Being a user of Xen myself on small server sites, I prefer to name servers somewhat randomly and give them additional A records for their functionality.
That is, Legalas.test.local and Intranet.test.local may both resolve to the same IP, but I can move Intranet to another server and still know what the name is of the specific box that was previously the fileserver.
My way, regular clients connect to the common names, whereas technical staff connect to hardware names. CNAMEs are also appropriate under some ci
Re: (Score:3)
Hey, look, Mike posted exactly the right answer and nobody with points noticed. Bummer.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
I absolutely disagree with this. You may have a vision of the function of a server in the beginning, but those functions morph. You can make DNS aliases that go with the function, but don't name the *machine* those functions.
When you do that you end up, as I have seen people do, with a web server named mail and a mail server named db1. And don't tell me you should just rename the server, either.....
Re: (Score:2)
br.
Re: (Score:3, Funny)
Our mac solution was simple.
We say sorry, we don't support macs.
If they win the political battle to get a mac in (or bring in a personal mac), they still have the standard issue desktop in the office to access everything.
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.
Re: (Score:3, Informative)
Actually, you should never use NTP in a virtual machine. Virtual machines perceive inconsistent clock ticks from their virtual CPU, which can confuse the holy hell out of NTP as it is constantly trying to predict the clock drift based on ticks.
At least, that's what some VMWare engineers told me at a conference once. But it was consistent with some problems I'd seen with NTP clients in VMs having problems keeping the clock synced.
As for "Where do I stop this virtualization thingie?" You stop it when it ma
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.
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.
Re: (Score:2)
Not to mention all the renaming that would have to be done when the machine moves...
Alphabet soup for host name doesn't strike me as being very bright either... (and it *might* be offensive to your Slovenian client "My mother was a what ??").
Re: (Score:3, Insightful)
No, I'd say it's a pretty good scheme.
A naming scheme based on cultural references is bound to fail as soon as you deal with non-english speaking backgrounds. SideShowBob is probably only good for US/Can/Aus/Nz/UK. Telling one of our Russian counterparts to look for SideShowBob01 is not going to work.
- ISO standard Country codes (3 characters)
- Site number within country (1 digit, we only need one)
- O/S NT based, LX based, MC based, A4 for AS/400
- WS Workstation, FS (File)Server, DC Domain Controller.
- Uniq
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: (Score:3, Informative)
Yes, I have, but the managers in accounting and HR haven't, and could care less. They want their problems fixed, pronto.
Re: (Score:3, Insightful)
Fucking horrible idea, but the same thing the company I work for is going to. Just sucks, horribly confusing, obtuse, hard to remember what is what.
I like the subdomain idea much better. Keep it simple. someserver.somelocation.companyname.com.
We code names by location and function. (Score:2)
Something along the lines of XXyyy01, XXyyy02, where XX is a two-character code for the computer center in which the box physically resides, yyy is the basic function of the box, and 01, 02 are numbers to describe each unique server in each location/category. Zones on Solaris servers are indicated with -Zn where n is the zone number.
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.
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.
Re: (Score:3, Insightful)
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: (Score:3, Informative)
I agree, although I would make cityFileServer a DNS entry which points to the physical server and use some cryptic name for the physical server... like cityserver01 or something just to differentiate it. That way when you replace cityserver01 with cityserver06, you just need to change the DNS pointer to start using it, as you don't have to reconfigure other systems pointing to it.
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.
Big flat spaces (Score:2)
With cryptic names. Well, not cryptic, they just have nothing to do with the function. The users shouldn't have to know anything about the names of the servers. They should just tell you what they're trying to do, and you should go forth and fix it, or tell them why they're stupid as nicely as possible (unless you work in an all-Unix shop and you're the only one who knows how to work sh.)
If it's really big and complicated, use subdomains, that's what they're for. It's most convenient if you can map them to
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.
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.
subdomains (Score:2)
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.
Uses and subdomains (Score:2)
Or you can keep the funny names, but use different schemes for different places/functions.
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).
Elements (Score:2)
I use the names of Elements for my machine naming scheme. They are short, recognizable, and if you want to be really anal, they are already in groups and you can apply those groups to type of servers.
(Halogens are the mail servers, Lanthanides are the web servers, actinides are the databases, etc)
depends what they're for (Score:2)
We use different naming schemes for different subsets of servers depending on what they're used for.
For general-use clusters that people are going to ssh in to do work on, need to remember the names of, and are actually different (i.e. we don't have five servers just for load-balancing, but for five different things), we tend to use theme-based names that are short and hard to misspell. E.g. the old standby of computer scientists: turing, knuth, etc.
For servers that are going to be used as part of a cluster
err, a caveat to the above (Score:2)
Again in the "depends what they're for" vein, we do have a set of general-purpose servers with identical mounted filesystems/home-dirs that do have different, non-numerical names (still the short, hard-to-misspell variety). These are mainly compute servers for people who leave long-running jobs in screen, because it's easier to remember "I set some stuff up on knuth" than "I set some stuff up on foo32". The load-balancing can be sub-optimal in this approach (people tend to pick a machine they use as "their"
STDs (Score:2)
(Credit: Gordon Greene)
If you want an endlessly expandable name space, you can't beat STDs. The catch is that no one can spell half of them.
Dead celebrities are good too. You can use the cause of death as a subdomain, to keep things a bit less chaotic. People *can* spell those.
Re: (Score:2)
We toyed with using that theme for the next group of servers. Hepatitis would do great for a cluster ;)
No doubt management would veto it...
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.
You have a problem here... (Score:2, Funny)
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
don't waste your time on it (Score:2)
In a small/medium business, there are not enough systems that you need to worry having structured naming conventions. In those situations, I just make sure they are,
* 8 chars or less (for compatibility with everything)
* no special characters (punctuation, etc.)
* easy to spell and to pronounce
* hard to confuse with users/functions/places -- who knows what this server will be used for in the future. Save yourself the effort of renaming it.
Sometimes I pick a theme, but it's most
Applications or network drives? (Score:2)
Are you talking about having a user point their web browser to CRM-server.XYZ.com? or are you having them connect to a network drive? -filer/share....
I wouldn't tie the name to the hardware since you should be architecting your environment to be able to migrate the application/share to new hardware in the next few years, so doing something like DL380-row1-rack2-A isn't a wise idea.
If you're naming storage devices (arrays) than -- is a good solution. EMC-1234-14AA
Coming up with "cutesy" naming schemes lik
Madness, I know, but.. (Score:2)
Server1 ...
Server2
Server3
Server4
I think you can probably see where this is going.
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.
Re: (Score:2)
Interesting ... I've used Trek names internally for over 12 years with a simple nomenclature.
My own servers, desktops, laptops, phones, PDAs, etc get Federation starship names (e.g. "enterprise", "intrepid", "saratoga", etc).
Any kit belonging to my employer gets a Klingon starship name ("bortas", "amar", etc).
Routers, access points etc get named after ways they use to get around ("wormhole", "subspace", "graviton", "conduit", etc).
Games consoles use recreational names ("kadis-kot", "holodeck", "dabotable",
Mythology or religious characters (Score:2, Interesting)
We use : (Score:2, Informative)
- 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
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.
Use multiple names (Score:2)
Names serve at least two purposes. First, they designate a particular machine and should be kept the same over its lifetime (barring the occasional re-christening) to avoid confusion if someone reads old documentation (e.g. trouble tickets about failed hardware). Second, names designate the purpose to which that hardware is being used (e.g. "mailserv" should always be the current mail server). Over time as hardware gets reassigned, these two purposes will inevitably drift apart.
The solution to this qu
Oh my god, it's full of themes (Score:2)
The comments on this article make me stabby.
If/when I run a company where I need to hire IT folk, this will be one of my interview questions. If someone says a good naming scheme would be planets, elements, or some other theme based nonsense, (s)he's getting the boot.
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.
MOD THIS COMMENT UP (Score:3, Insightful)
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 l
Separate names for function versus physical device (Score:3, Informative)
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.
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.
Go to a utilitarian hierarchy and role naming (Score:3, Insightful)
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.
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:2)
Re: (Score:3, Funny)
Didn't you get the memo?
SideShowMel replaced SideShowBob a while ago.
Re: (Score:2, Funny)
Must be an enterprise system. They're always a bit slow to upgrade.
Re: (Score:2)
I wouldn't trust my files to your sideshowbob server.
Re: (Score:3, Funny)
Re: (Score:2)
Re:Short and Concise (Score:5, Funny)
what goes after Server0003?
Re:Short and Concise (Score:5, Funny)
...
Re:Short and Concise (Score:4, Funny)
On the other hand, It seems to be a genuine innovative idea using Morse for server names.
Re: (Score:2)
...Damn it!
This works for a 5000 server environment: (Score:3, Interesting)
Re: (Score:2)
Why, exactly (except copyright issues)?
It's by far easier to take a support call for bilbo.company.com than it is to take a support call for pcdtddo01l.company.com, and if unsure what bilbo.company.com does and who to contact, have the internal DNS return HINFO, RP and TXT information that tells you.
(And make a weekly printout for the major SPFs and internal DNS servers themselves)
Even big corporations will