Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Networking Hardware IT

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?"
This discussion has been archived. No new comments can be posted.

Best DNS Naming Scheme For Small/Medium Businesses?

Comments Filter:
  • by Anonymous Coward on Sunday July 06, 2008 @04:39PM (#24077093)

    The guys at work seem to enjoy their time with Jenna quite a bit.

  • Two words. (Score:5, Funny)

    by Anonymous Coward on Sunday July 06, 2008 @04:41PM (#24077109)

    Body parts. Easy to remember.

    "Where is that file?"
    "In the nose."

  • by Anonymous Coward on Sunday July 06, 2008 @04:43PM (#24077125)

    ...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.

    • by KevMar ( 471257 ) on Sunday July 06, 2008 @07:22PM (#24078327) Homepage Journal

      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.

  • by Yvan256 ( 722131 ) on Sunday July 06, 2008 @04:44PM (#24077137) Homepage Journal

    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)

      by kolbe ( 320366 )

      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

      • by Original Replica ( 908688 ) on Sunday July 06, 2008 @07:19PM (#24078293) Journal
        What about animals? The spellings are commonly known, there are hundreds to choose from, and you can group servers easily by animal class.
        • Re: (Score:3, Insightful)

          by ZeissIcon ( 67281 )

          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

    • by rduke15 ( 721841 ) <> on Sunday July 06, 2008 @06:13PM (#24077893)

      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.

      • by EdelFactor19 ( 732765 ) <{adam.edelstein} {at} {}> on Sunday July 06, 2008 @11:45PM (#24080025)

        "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)

      by Workaphobia ( 931620 )

      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.

    • by CAIMLAS ( 41445 ) on Sunday July 06, 2008 @08:21PM (#24078691) Homepage

      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.

  • by realmolo ( 574068 ) on Sunday July 06, 2008 @04:44PM (#24077139)
    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.
    • Z: is a *much* better name for a server eh? :-)
    • by nine-times ( 778537 ) <> on Sunday July 06, 2008 @06:12PM (#24077875) Homepage

      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.

      • by CAIMLAS ( 41445 ) on Sunday July 06, 2008 @08:30PM (#24078735) Homepage

        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)

          by MikeBabcock ( 65886 )

          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, Insightful)

      by afidel ( 530433 )
      I use two letter site code + function + two digit numeric ID, so your example server would be CHFS2, easy for anyone familiar with the system to decode. As far as my users, we use DFS to point them to file resources, short DNS names for web apps, and everything else is published as a Citrix application. They basically have to remember two things, what drive letter to save to and how to get to the Citrix page.
    • Re: (Score:3, Insightful)

      by mckyj57 ( 116386 )

      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.....

  • An example (Score:3, Insightful)

    by fahrvergnugen ( 228539 ) <fahrv&hotmail,com> on Sunday July 06, 2008 @04:45PM (#24077145) Homepage

    A good host name should denote the following:

    -department/cost center
    -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:


    Which would denote san jose office, marketing, fileserver, production, 01.

    Adjust as necessary for your use.

    • Re:An example (Score:5, Insightful)

      by Dr_Harm ( 529148 ) <> on Sunday July 06, 2008 @04:52PM (#24077203) Homepage

      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 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)

      by arth1 ( 260657 ) on Sunday July 06, 2008 @05:13PM (#24077419) Homepage Journal

      A good host name should denote the following:

      -department/cost center
      -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:


      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, 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 from also being known as

      • by Fred_A ( 10934 )

        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)

        by nosfucious ( 157958 )

        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)

          by Gonoff ( 88518 ) on Sunday July 06, 2008 @06:19PM (#24077927)

          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, Insightful)

      by KlomDark ( 6370 )

      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.

  • 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)

      by sohp ( 22984 )


      Why only 2-character codes? Host names can be long.

      Here's what happens when you go with that kind of naming scheme.


      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)

    by silanea ( 1241518 ) on Sunday July 06, 2008 @04:48PM (#24077171)

    We (somewhere between small and medium, branches in Germany, Austria and the US) use two naming schemes:

    The primary scheme is [serverclass+#].[branch] This is what we, the tech staff, use for establishing connections for live systems and what we communicate to our users.
    Examples would be, 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)

    by fmwap ( 686598 ) on Sunday July 06, 2008 @04:52PM (#24077197) Journal
    There's a whole RFC on this: []

    Interesting 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)

      by drinkypoo ( 153816 )
      an rfc is just a story that someone thought might not get laughed at too much. don't take them too seriously until people start targeting them as a specification. The most sensible thing you can do IMO is just use subdomains (it's not that painful honestly) and then name your machines after their function. You can always map multiple names to one machine, and then you can merge or split them later at will, in theory without the users being any wiser.
  • by socsoc ( 1116769 ) on Sunday July 06, 2008 @04:52PM (#24077201)
    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.
    • Re: (Score:3, Informative)

      by sheldon ( 2322 )

      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)

    by RunzWithScissors ( 567704 ) on Sunday July 06, 2008 @04:52PM (#24077209)
    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:

    If that doesn't work, you can also do
    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.

    • Re:Utilitarian (Score:4, Interesting)

      by ptudor ( 22537 ) * on Sunday July 06, 2008 @07:02PM (#24078205) Homepage Journal

      Probably the best naming scheme was first sub-domained by airport code and/or country code:

      If that doesn't work, you can also do

      Thank you for understanding DNS.

      I've worked at crazy places where type of device, location, and all that were crammed into the hostname, just like this post []. I blame people not using subdomains or .local for active directory. Oh, and removing vowels. If a software application was called "Pacific Beach" the machine name would contain it, condensed to PcfcBch with an 01 at the end. Come on people, our language has vowels, use them.

      Also, the world is a better place with tinydns at the top of your hierarchy. It's easy to convert from BIND []. (even though i do use bind9 slaves as v6 listeners.)

      Someone else made a comment about the hostname "" and I'll confess I love it. Better than calling it "" 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 in large organizations. But that's what DNS is for.

  • 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

  • by Anonymous Coward on Sunday July 06, 2008 @04:56PM (#24077255)

    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 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.

  • by s0litaire ( 1205168 ) * on Sunday July 06, 2008 @04:57PM (#24077265)
    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..
    • by Jesus_666 ( 702802 ) on Sunday July 06, 2008 @05:49PM (#24077677)
      How about using an SHA-1 hash of an incrementing counter? The first box is, the second one is etc. The mapping between counter values and machines is stored in an Excel spreadsheet, printed out and stored in the server room.

      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)

    by TheVoice900 ( 467327 ) <> on Sunday July 06, 2008 @04:57PM (#24077269)

    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 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.

  • Road Runner, which is a cable internet provider for Time Warner if you didn't know, uses a perfect system. My e-mail is at and the NEW is northeast wisconsin (even though it covers all of Wisconsin except Milwaukee). I've seen other acronyms for different areas too. Nobody seems to forget 3 simple letters around here. So I dunno much about networking but I think you set up the subdomains and point each one to each server and you're set.
  • Pubs (Score:3, Insightful)

    by ngunton ( 460215 ) on Sunday July 06, 2008 @04:58PM (#24077281) Homepage

    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.

  • You can create subdomains, and maybe be more descriptive with utilitarian names based on what they do or something descriptive enough to be clear, i.e., or even

    Or you can keep the funny names, but use different schemes for different places/functions.
  • Function-based names (Score:4, Informative)

    by bigtangringo ( 800328 ) on Sunday July 06, 2008 @05:00PM (#24077289) Homepage

    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, ...


    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)

    by grizdog ( 1224414 ) on Sunday July 06, 2008 @05:00PM (#24077297) Homepage

    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).

  • 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)

  • 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

    • 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"

  • by KC1P ( 907742 )

    (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.

    • by bartjan ( 197895 ) *

      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...

  • 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 but use DNS to give the important ones a second name as in

  • 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

  • Are you talking about having a user point their web browser to 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

  • Server1
    Server4 ...

    I think you can probably see where this is going.

  • can't stand themes (Score:5, Insightful)

    by v1 ( 525388 ) on Sunday July 06, 2008 @05:15PM (#24077443) Homepage Journal

    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?"


    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.

    • 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",

  • 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.
  • We use : (Score:2, Informative)

    by ratboot ( 721595 )
    - 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 :

    • Stupid idea (Score:5, Insightful)

      by this great guy ( 922511 ) on Sunday July 06, 2008 @09:55PM (#24079319)

      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, then look it up in your network documentation.

  • 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

  • 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.

  • by willyhill ( 965620 ) <> on Sunday July 06, 2008 @05:49PM (#24077675) Homepage Journal

    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:

    An app server in Brazil was:

    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.

    • by CAIMLAS ( 41445 )


      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

  • by Laxitive ( 10360 ) on Sunday July 06, 2008 @06:22PM (#24077935) Journal

    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)

    by chill ( 34294 ) on Sunday July 06, 2008 @06:27PM (#24077967) Journal

    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.

  • by Ernesto Alvarez ( 750678 ) on Sunday July 06, 2008 @07:47PM (#24078501) Homepage Journal

    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:

    1. Assign subdomains to different networks. They should be completely utilitarian.
    2. Assign names to each machine in each network. I follow a theme for each.
    3. When a machine is in two networks, define a "main" network interface. Name it using its main network team (bonus points if you manage to assign a name belonging to both themes).
    4. Assign ALIASES to each machine, one for each function.

    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
    edna IN A
    bernard IN A
    hoagie IN A
    gateway IN CNAME ed

    fileserver IN CNAME bernard

    printserver IN CNAME hoagie

    Miami (domain
    simon IN A IN A
    gateway IN CNAME simon

    printserver IN CNAME pitr

    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 in case you open an office in Vancouver changing your hierarchy your names to:

    or even add extra levels under the city names if you need:

    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)

    by jcuervo ( 715139 ) <> on Monday July 07, 2008 @12:38AM (#24080321) Homepage Journal
    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.

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller