Slashdot Mirror


Best DNS Naming Scheme For Small/Medium Businesses?

Bandman writes "My business just purchased a couple dozen blades, and with our existing servers, this brings us to around 60 machines. We're geographically dispersed, and most of the users who need to connect to servers are not technical (if that matters). We used to use theme-based naming schemes, but we've been migrating to a more utilitarian system. I think it's clearer and more concise, but I've had some feedback from users who didn't find it understandable. What do you use for your internal DNS schemes? How big is your network, and what do you recommend for future expansion? Does it matter to your users at all?"

6 of 481 comments (clear)

  1. Keep it simple, stupid by realmolo · · Score: 5, Interesting

    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.

    1. Re:Keep it simple, stupid by nine-times · · 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.

  2. Several schemes by silanea · · 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.

    --
    Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
  3. location/purpose naming by socsoc · · Score: 5, Interesting

    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.

  4. Theme based schemes do scale beyond 60 hosts... by bartjan · · 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.

  5. Oh oh I know this one! by willyhill · · 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 for the cities (Portland = pdx, Houston = iah, Ft. Lauderdale = fll, etc) but later we just came up with three-letter codes for some data centers because it was more intuitive (HOU is better than IAH). For the other countries, we used the generic 'ads' subdomain and the two-letter ISO country code.

    The server types were:

    STO - File servers
    APP - Application servers (could also be web servers)
    WEB - Web servers (dedicated)
    SQL - Database (any type)
    PDC - Primary domain controllers
    SDC - Secondary domain controllers
    EXC - Exchange servers
    DNS - Guess
    LIC - Licensing servers
    TSS - Dedicated terminal services boxes
    SRV - Generic servers (to be avoided!)

    There were a couple more but these were the main ones.

    This scheme worked very well because the identifiers and numeric sequences are mnemonic, but most importantly, it scales. Numeric sequences were assigned as servers were imaged and named, pulling the codes from a simple database application someone at the company wrote. The sequences were tasking-specific, meaning that APP servers were sequential and unrelated to the WEB sequences, for example. The only problem I ever saw with that was the situation where we had more than 1,000 server of a single type, but as far as I know that never happened. In any case sequences could be re-used as servers were retired.

    I've seen server naming schemes that used cartoon characters, Star Wars figures, elements, celestial bodies, etc. None of them worked (or would have worked) beyond 100 boxes or so.

    --
    The twitter monologues. Click on my homepage and be amazed.