Host Naming




The Basic Idea, in Verse

Jay R. Ashworth's advice in anapestic tetrameter, with apologies to T.S. Eliot: 

    The Naming of Hosts is a difficult matter,
        It isn't just one of your holiday games;
    You may think at first I'm as mad as a hatter
        When I tell you, a host must have THREE DIFFERENT NAMES.

    First of all, there's the name that the users use daily,
        Such as venus, athena, and cisco, and ames,
    Such as titan or sirius, hobbes or europa--
        All of them sensible everyday names.

    There are fancier names if you think they sound sweeter,
        Some for the web pages, some for the flames:
    Such as mercury, phoenix, orion, and charon--
        But all of them sensible everyday names.

    But I tell you, a host needs a name that's particular,
        A name that's peculiar, and more dignified,
    Else how can it keep its home page perpendicular,
        And spread out its data, send pages world wide?

    Of names of this kind, I can give you a quorum,
        Like lothlorien, pothole, or kobyashi-maru,
    Such as pearly-gates.vatican, or else diplomatic-
        Names that never belong to more than one host.

    But above and beyond there's still one name left over,
        And that is the name that you never will guess;
    The name that no human research can discover--
        But THE NAMESERVER KNOWS, and will us'ually confess.

    When you notice a client in rapt meditation,
        The reason, I tell you, is always the same:
    The code is engaged in a deep consultation
        On the address, the address, the address of its name:

                It's ineffable,
                effable,
                Effanineffable,
                Deep and inscrutable,
                singular
                Name.



The Details

Machine names are often expected to meet one or more of these criteria:

Encoding information into the name is in general a bad idea because when something changes you will have to rename the host (or live with a misleading name). Such data are better put into some other database, e.g., LDAP, or at least implemented with DNS CNAME aliases and such, leaving the base machine names alone.

Rapid rollout is a more-compelling argument, e.g., sparc50...sparc151 at least don't require much wasted time — and at least a machine isn't going to change from being a SPARC to something else. However, you can avert this situation by having an inventory of names in advance.

Human-readable / memorable tends to work best. The biggest obstacle tends to be political, i.e., the attraction of bad ideas (see near bottom) and the inability of bossess to comprehend machines having multiple names with the "role" names being movable as machine functions and other non-essential characteristics change.

The other obstacle is running out of inspiration. Here are some categories you may wish to mine for ideas. Some sites will elect to use multiple categories, e.g., reserve disease names for MS-Windows servers.

Expect turf wars and violent objections where you least expect it. Be prepared for exceptions and vetos. Establish a loose pattern within reasonable limits (e.g., 4-16 letters, no usernames, no punctuation other than hyphen, in particular no underscores, nothing obscene), save your ammo if someone just doesn't want to cooperate.


Bad, Bad Ideas: Hall of Shame

It also pains me as a Scandinavian to feel obliged to caution against stepping outside the 26-letter Latin alphabet for, or include accents in, host names, tempting as it might be to name host for the Norns (urðr, verðandi, skuld) or for Icelandic volcanoes (e.g., eyjafjallajökull, öræfajökull, katla, hekla, grimsvötn, askja, hengill, snæfellsjökull, torfajökull).

These bad ideas are institutionalised and management-dictated at many institutions and large companies (e.g. clueless bad advice from Pierre Dumoulin) — instead of implementing them via alias names, if at all.

Other don't-do-this warnings are included in RFC1178 (1990): "Choosing a Name for Your Computer", by Don Libes.