This document offers rules for choosing host names, so that Netops can better manage the hosts in production. View the rules below through the eyes of Netops. They need to know, from the host name, what the host does and where it fits in the big picture. No matter how familiar a name is to you, if it means nothing to Netops, there may be better choices for your host name.
The Naming Czar has the power to enforce these rules, and is the final authority for host names.
This document sets rules only for host names, that is, the part of a full domain name up to the first dot. For example, for the domain name app01.p001.us-west-1.aws.xyz.com, the rules cover the name app01. This document does not set rules for for anything else, such as network names, DNS subdomain names, or appliance names.
This is a document currently under review. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. Rules
A host's name reflects its primary function, not the manufacturer's name, brand name or the type of software it runs. If a host's primary function changes, we change its name.
A vendor or brand name may be included as part of a host name, if it is important to distinguish hosts of similar function, but it never takes the place of the functional part of the name. Rule 6 covers this case.
- app01 - an app server.
- monitor01 - a monitoring host.
- wiki01 - a wiki media host.
- teamcity - continuous build software built by JetBrains. If we change vendors, or if JetBrains forks or changes the service name, we would have a host with a name having only historical meaning. build-agent01 would be a better choice.
- nagios - a monitoring host running Nagios software. When we change to a different monitoring service, the host name will not reflect the software currently running on the system. monitor01 would be a better choice.
- production-c1-app-1 - a app server running in cluster 1 in the production environment. A hostname should not take the place of subdomains. app01.c01.us-west-1.aws.xyz.com would have been a better choice.
Well-known abbreviations are fine, even preferred, but they must be well-known to Netops, that is, to a community of operators. Here are some examples suitable for host names or parts of them.
app for application
ctl for control
db for database
dm for datamart
fs for file store or file server
fw for firewall
gslb for global server load balancing
gw for gateway
ids for intrusion detection system
mgmt for management
mgr for manager
mon for monitor
ns for name server
ops for operations (Netops, not other kinds of operations)
pip for proxy IP address
rec for recognition
sim for simulator
slb for server load balancing
vip for virtual IP address
vpn for virtual private network
Protocol names, such as smpp, are also fine.
- ns02 a domain name server.
- ops01 a datacenter login host for operations.
- idsmgmt01 a management host for the Intrusion Detection System.
- logs - a logging server, but for what? logs are everywhere, so getting an idea specifically from a hostname is necessary. device-log-agg01 would be a better choice.
- ci - a contiguous integration server. ci is too cryptic to easily understand the purpose of the host without spending time finding it's function. build-agent01 would have been a better choice.
So many of our hosts are web servers that including web in the name adds nothing and takes up space. Use web only for public facing web servers, for example, the servers for www.xyz.com and community.xyz.com.
- content03 - a content (web) server.
- bill01 - a billing information (web) server.
- apiweb01 - a (web) server for static API documentation. apidoc01 or static01 would be a better choice.
- public-site-1 - a (web) server for a Django based app server used to serve dynamic content dynamic01 would make more sense
Except for names representing virtual IP addresses (VIPs), every name should include a two digit number that distinguishes a group of identical hosts. Numbering starts at 01. When the name includes a dash ("-"), put the number at the end.
There are two exceptions where the number goes before the dash:
- The part after the dash modifies the part before, for example, a host with multiple interfaces on the same network, or a single host firewall. i.e. vpn01-a and vpn01-b
- The part after the dash indicates an aliased record value i.e. vpn01-vip references the HA pair.
- app01, app02 - AppServer hosts. The number goes at the end.
- load-sim01, load-sim02 - Load simulators. The number goes at the end.
- db02, db02-vip - names for the real and virtual addresses of the same host, where both addresses are on the same network. The network name will not distinguish them, so -vip takes care of that. The number goes before the dash.
- vpn01standby, vpn02standby - standby virtual addresses for two vpn instances. The number is in the middle of the name. These should be hyphenated, like vpn01-standby and vpn02-standby.
If two hosts serve as an active/backup pair, where the backup host takes over when the active one fails, and a virtual address always points to the active host, their names should include the same number, with "a" and "b" appended.
- vpn01a, vpn01b - a failover pair of vpn appliances.
Hosts with the same function may use different software to achieve that function. If it is important to note this in the name, name the function first, the variation second.
- build-maven01 - a build host for the maven repository specifically. The original build server is build01.
- reporuby01 - a software repository for ruby gems . The original repository server is repo01, so the variation should come after repo, not before. repo-ruby01 or repo-gem01 would be better choices.
Sometimes a name that seems like a good choice becomes something else when you write it down or say it out loud. When you build a name by concatenating two words or abbreviations, your eyes may see a different dividing point than what you intended. Check for this.
- stormon01 - a monitoring host for a storage array. stormon reads as storm-on as well as stor-mon. Reversing the abbreviations, monstor01, may work better.
- nocops01 - a general operations host for the NOC. nocops reads as no-cops as well as noc-ops. Using a dash, noc-ops01, may work better.
- slam01 - a service level agreement (SLA) monitoring host. slam reads as slam more than sla-m. In addition, m is a cryptic abbreviation for monitor, thus also violating Rule 2. sla-mon01 or slawatch01 would be better choices.
There are times when a production host must run code we do not trust. To protect the rest of the network, we put this host behind its own bridging firewall. The name of the firewall should be the name of the host, with -fw appended.
- inventory01-fw - a firewall for the host inventory01, which helps track production inventory but runs Windows.
- pgefw02 - a firewall for the host pge02, which handles some data from a vendor and runs vendor code whose source we have no access to. pge02-fw would be a better choice.
When a group of hosts, each with a different function, and therefore a different name, together provide a service, it helps for their names to share a common part. Depending on how many different hosts there are, and how long the names are, it may make sense to make a DNS subdomain out of the common part, so it is no longer in their names.
Subdomain names are outside the scope of this document, but you should be aware of the option. Talk to the network architects or DNS mavens if you are thinking about a new subdomain.
A client portal
- A client portal includes login, database and web hosts, along with their VIPs. Without a separate subdomain, we would have names such as portal-login01, portal-db01 and portal-web01.
- Creating a portal subdomain changes the names to login01.portal, db01.portal and web01.portal.