Zen and the Art of Naming Conventions-hostnames

I spent all weekend with a 6 second long sound bite stuck in my head. It’s from a song I used to love, that I’d played thousands of times, and probably haven’t thought of this century. I knew that the name of the group had something to do with Bangkok, or Tokyo, or some vaguely Asian location, and while I could hear the tune inside my head (at least when the voices gave it a rest) I could NOT come up with the name, or even enough of a lyric to let Google work it’s magic. I needed the name. And that got me thinking. I’ve worked on hundreds of networks, and I’ve seen just about every server naming scheme you could imagine; the good, the bad, and the ugly. Most fall into the cracks between good and bad; let’s call them the indifferent. You can almost classify the techno-geek maturity level of an IT organisation by their naming convention. (You like that? It just happened!) New orgs stick with the classics, like X-Men characters, mythological deities, chemicals, planets, etc. Orgs that are trying to ‘grow up’ err on the other extreme, trying to develop a naming convention that invokes the corporate name, or give as much detail as you would expect to find on the server list on SharePoint.

What’s in a name? That which we call a rose by any other name would smell as sweet.
-Romeo and Juliet, Act II Scene II. William Shakespeare

…see, a guy works a Shakespeare quote into a post, he must know something good.

But that which we call in a UNC path has to be easy to use and remember, and must be resolvable in our DNS. There are some common mistakes that I have encountered over time, and it was one such recent charlie-foxtrot that prompted me to pen this narrative.

Out in the real world, there are two main schools of incorrect thought on the subject of naming systems. I like to call them ‘the Hyphenators’ and ‘the Cryptics.’ In ages past, the forebears of the Hyphenators found out that they could put a hyphen (dash, minus sign, call it whatever you want, it looks like this – ) in computer names, so they did. What followed was years of needlessly breaking names up with countless dashes, and endless “Please check the name and try again” messages from telling users server names, while not saying the “dash” since “everyone should know it’s there” incidents. Actually, I think they eventually devolved into getting kickbacks from the keyboard manufacturing industry, because they put so damn many hyphens in their computer names that you’ll wear out the button on your keyboard!

All of the Cryptics descended from the single forsaken lovechild of a government bureaucrat from the Department of Acronyms, and Rainman. Reproducing asexually, they like to assign a specific, uniform designator to every facet of a machine, and concatenate that together with a location and a number and a department and a distinction between test and production and another between physical and virtual and another for the operating system and another for the version and….you get the point. They used to be called ‘the Run-Ons’ but the Hyphenators got pissed that the name had a hyphen in it. You can imagine what happened next. Well, maybe you can’t. In a fit of Capulet v Montague amour, two of them combined, and the world came to be burdened by hyphenated-cryptics! Many Shuvs and Zuuls knew what it was to be roasted in the depths of the Slor that day, I can tell you!

Before we discuss what makes a good naming convention, let’s discuss the things that govern what we can and cannot do. We’ve got four categories, which are summarised below.
•NetBIOS Names
NetBIOS names (as implemented by Microsoft) are still (even Windows 7 and Server 2008 R2) heavily used by Microsoft. We’ll likely never get away from them entirely. They are exactly 15 bytes in length, which provides for no more than 15 ASCII characters, null padded if necessary, plus a 16th hexadecimal service identifier, or primitive, that indicates the type of name (workstation, server, messenger, domain controller, etc.) While they can contain any letter or number, they cannot contain spaces, cannot consist only of numbers, and the only permitted punctuation characters are underscores and hyphens.
•Host (DNS) Names
Host names can exist alone, or are mapped into a DNS zone as fully qualified domain names. While an FQDN can contain up to 255 characters (plus a . to reference root), a single label can contain no more than 64 characters. Host names can contain any ASCII letter or number, or hyphens only, with periods separating levels of the hierarchical name and terminating the namespace.
Called “Choosing a name for your computer,” this RFC lays out some good guidelines to use when naming hosts. Highlights include favouring shorter names, avoiding words with alternate spellings, and not using digits at the beginning of names.
•(un)Common sense Names
Names should be easy to remember. They should convey useful information. They should not require different treatment based on use (encoding characters in HTTP, escaping characters in LDAP or scripting languages, etc.) They should make sense to the end users and the admins, and err on the side of the end user. Everyone knows where they work…you do not have to include the company’s identity in the server name!

So if we take all that into consideration, we want to shoot for names that are around eight characters long, are easy to remember, and tell users and admins both something useful about the system. We’ll avoid the use of hyphens and underscores completely. So taking all that into account, what do we do?

First, we’ll start the server name with an identifier for the location. Three letters works well here, so you just need to come up with a scheme that identifies all of your locations. The three letters should be easy for end users and IT to remember. Most muggles won’t know airport codes that don’t line up with real city names unless they fly there regularly, so don’t use them. The larger a company is, the more likely you will have cities with similar names, so try to come up with a list of all your locations early on, and vet it with the global team to make sure everyone can live with it. If you are an international team, check to be sure that the city abbreviation doesn’t say something naughty, especially when combined with a server function. I had a naming convention once that would have placed an EX (Exchange) server in BISmarck, ND…therefore Bismarck became BMK.

Next, we will use some standard abbreviations to identify the type of server. Here, understanding is more important than consistency, so some codes may be two letters, while others are three or more. Notice that some apps get full names, while others get abbreviations. The distinction is arbitrary, and you are welcome to modify it to fit your needs. What I have below works for me, and should be a good start for you. You could always leave a comment with more suggestions

server type code
 domain controller DC
 file server FS
 print server PS
 VMware ESX host ESX
 MS Hyper-V host HV
 web server WEB
 MS SQL server SQL
 Oracle server ORC
 generic application server APP
 accounting server ACCT
 human resources server HR
 media server MEDIA
 VPN concentrator VPN
 Internet Security and Acceleration server ISA
 Threat Management Gateway server TMG
 DNS server DNS
 DHCP server DHCP
 SharePoint server SP
 SolarWinds server SW
 Splunk server SPLUNK
 SNA server SNA
 VoIP server VOIP
 Call Manager server CM
 Unity server UNITY
 Cisco Emergency Responder server CER
 Exchange server EX
 Exchange mailbox server MB
 Exchange Client Access server CAS
 generic mail server MX
 Lotus Notes server CRAP

Finally, add a number. Start with 1, and increment up from there. The number is more to allow for redundancy than to indicate ancestry or lineage. Let go of the need to have certain servers always be referenced by the same name. That is what aliases are for, and in an upcoming post, we’ll discuss the common DNS aliases every company should use.

That’s all there is to it. Following the above, you will have server names between seven and eleven characters that are easy to remember, and to spell out to users. From the name you will be able to determine where the server is, and what it’s for. In a name, that is all you really require. If you want to know the operating system, the patch level, how much RAM, Disk, etc. it has, and whether it is physical or virtual, use bginfo to display this on the console, or consult your server list on SharePoint. Your domain controller in Orlando will be ORLDC1, your file server in Jacksonsville will be JAXFS1, the ESX host in your Miami datacenter will be MIAESX1, and your VoIP server in Chicago will be freezing I mean, CHIVOIP1.

Hopefully this will help someone out, and maybe give them the ammunition to convince some hyphenator to STFU and GBTW, and let the real geeks make the important decisions. Hopefully if you have to show this to your boss to convince them that easy is better…they’ll have a similar sense of humour to me! Hopefully, you care enough for my sanity that you wonder if I ever found the song. I did. It just came to me as I was finishing this post. Some bizarre association, or maybe my muse just wouldn’t give it up until I got another post done. Either way, maybe now I can get some sleep! It was Saigon Kick’s “Love is on the Way!”

traceroute response codes

response meaning
!H Host unreachable
!N Network unreachable
!P Protocol unreachable
!S Source route not permitted
!F Fragmentation needed but DF bit is set
!X Communication administratively prohibited

subnet-wildcard values

CIDR SubnetMask     WildcardMask   HexSubNetMas
29 FF.FF.FF.F8
28 FF.FF.FF.F0
27 FF.FF.FF.E0
26 FF.FF.FF.C0
25 FF.FF.FF.80
24 FF.FF.FF.00
23 FF.FF.FE.00
22 FF.FF.FC.00
21 FF.FF.F8.00
20 FF.FF.F0.00
19 FF.FF.E0.00
18 FF.FF.C0.00
17 FF.FF.80.00
16 FF.FF.00.00
15 FF.FE.00.00
14 FF.FC.00.00
13 FF.F8.00.00
12 FF.F0.00.00
11 FF.E0.00.00
10 FF.C0.00.00
9 FF.80.00.00
8 FF.00.00.00
7 FE.00.00.00
6 FC.00.00.00
5 F8.00.00.00
4 F0.00.00.00
3 E0.00.00.00
2 C0.00.00.00


im in ur datastreams, fixup’in’ ur protokols

So the other day, I found myself involved in two different attempts to fix the same problem, which had apparently been an issue for over a year for these guys. They both wanted to use FTP to move files from a host on one segment, to an FTP server on another segment. Sounds simple, right? Well if it was, I wouldn’t be writing this article, would I?


-Two hosts need to communicate with one another using FTP
-across a firewall
-NAT is in place
-the FTP server is using the non-standard port 1959

First, a review of FTP is in order. The current RFC for FTP is 959. Note that FTP commands embed network addressing within the Application layer of the protocol each time a PORT command (amongst others) is issued. The client embeds its IP address in the command, as so.

PORT 010,001,001,024,016,002

Note that the address is represented as padded, comma separated octets. The FTP server uses that information to open a connection back to the client for the data transfer. In this instance, the FTP client is on one network segment, the FTP server is on another, and there is a firewall between them. In the stream, the client’s network traffic is translated by the firewall so that it appears to be at the desired address, even though it is located on another network. This is transparent to both hosts, and to the user. Unfortunately, the FTP server cannot access the FTP client at the real ip.addr ( because the NAT represents the FTP client as having ip.addr

While Network Address Translation is frequently used, there are limitations to what it can do. The normal NAT process can only alter ip.addrs at the Network layer, and port numbers at the Transport layer. For many protocols, this is sufficient to permit the use of NAT, and to do so in a way that is transparent to the user, the hosts, and the application protocol(s) in use. There are however certain protocols that embed the ip.addr and/or port within the Application layer, as FTP does in its port commands. NAT does not inspect the Application layer, so when the destination host receives traffic with one set of addressing at the Network and/or Transport layer, and another set of addressing at the Application layer, problems will occur. This will break RPC traffic completely. For other traffic, there is the fixup command.

PIX firewalls have a feature called fixup which is enabled by default for many protocols on default (IANA assigned) ports. In the firewall configuration, this command is present.

fixup protocol ftp 21

Fixup does several things, but in this case we are most interested in its ability to basically perform NAT functions at the Application layer. Fixup can substitute the NAT address for the real one in the PORT commands transparently, neatly fixing the problem. Of course, if the FTP service had been bound to the default port, this would not have been a problem to begin with. The necessary action on the firewall is to add this command.

fixup protocol ftp 1959

Problem solved.


  1. Whenever possible, stick with default ports.
  2. When using NAT, evaluate the protocols in use for whether or not they play nicely with NAT.
  3. Use the fixup protocol command to inspect the application layer and make relevant corrections.
  4. Remember that not all protocols can be fixed up!

here endeth the lesson 😉