
A Server Naming Scheme - mstolisov
http://mnx.io/blog/a-proper-server-naming-scheme/
======
siliconc0w
Use something like a mac address and map them logically (i.e use chef
envs/roles/tags). This forces you to stop remembering hostnames and setup
automation to ssh/run commands. If you try to encode information into
hostnames you head into the deep end pretty quickly and it's probably going to
change in six months anyway.

~~~
worklogin
I'm not following. The whole purpose of naming is to make it easy. I don't
want to remember 000a43dbac72.example.com, it's easier to remember "pine" and
"oak" and trust me, after working in the environment a while, everyone knows
what every keyword is.

~~~
siliconc0w
The benefit here is mostly just with larger infrastructures where you're gonna
run out of wood names and where agreeing on and enforcing naming standards is
a futile and painful process.

With logical mappings, you just use chef/puppet/cmdb to do something like
sshnode prod app 1 to connect to the first production app node or sshnode prod
app to connect to all the production app nodes. CNAMES can do this too but
then you run into potential DNS consistency issues. With this you get the
human friendly abstraction and keep the machine friendly determinism.

Of course when your chef server goes down this can be a PITA (I recommend
building in some knife search caching!)

~~~
unethical_ban
This seems reasonable. I think the 'themed' naming works well for up to
perhaps a 100 or so servers/devices managed by a single team, but with tons of
automated provisioning, I suppose unfun naming is a requirement.

------
tambourine_man
Thanks for this link: [http://namingschemes.com](http://namingschemes.com)

It's one of the two hard problems, you know. Help is always appreciated.

[http://martinfowler.com/bliki/TwoHardThings.html](http://martinfowler.com/bliki/TwoHardThings.html)

~~~
chrisweekly
Wait a minute, I always thought the two hard things were cache invalidation,
naming things and off by one errors.

~~~
drivingmenuts
I got burned in a tech interview with off-by-one errors. I had signed into a
shared editor to do some simple practice stuff for the interviewer.

He noted the off-by-one errors as a concern.

I was thinking: this is untested, unreviewed, 2-minute code that shows I can
at least do some sort of problem solving. I'm nervous, don't know you, kinda
worried about the tone of this interview and you're worried about off-by-one
errors.

Kinda glad I didn't get that one. Wish I'd just hung up on the guy.

~~~
wpietri
I feel for both you and him.

The problem with getting praised a lot for being smart is that you then feel
obliged to say smart-sounding things often, and being critical is an easy way
to sound smart. It's even worse if you're hired to be smart. So the guy, if he
wasn't a total tool, was probably thinking: I wish I could just be coding, but
instead I'm supposed to interview a bunch of people in a way that guarantees
it will be awkward. And shit, I just got nervous and said something that
sounds insulting. I wish I could just hang up.

------
kbar13
service discovery via DNS on top of etcd:
[https://github.com/skynetservices/skydns](https://github.com/skynetservices/skydns)

I personally believe that servers should not have names, as naming them just
creates the incentive to try to fix broken infra instead of just killing and
respawning. I've considered using some kind of short UUID for hostnames
instead.

~~~
bryanlarsen
"short UUID" is an oxymoron. If it's short, then it's not universally unique.

Assuming you meant "short ID", how is that any different than the OP's
suggestion of randomly choosing from a list of meaningless names?

~~~
awalton
"Short" is relative. 4 billion IDs is likely Unique within an organization,
even one the size of IBM, Google or Microsoft.

~~~
eldavido
At the risk of pedantry, it depends on whether their allocation is centrally
coordinated. 4 billion IDs with central coordination isn't too bad, but you
need a much, much bigger space to make collision-free, uncoordinated ID
assignment practical.

Corollary: in a room of 23 randomly selected individuals, there's a 1/2 chance
that two individuals share a birthday. 365 days in a year, but only 23 samples
gets you to 1/2 chance of collision. Look up the "birthday paradox" for more
info on this surprising result.

------
eldavido
We used something very similar to this where I work (Crittercism). I designed
most of it.

I used five-part DNS CNAMEs _exactly_ how they're specified in the article (a
bit shocking, actually) except that mine switch the "group name" (prod,
staging, CI, etc.) and the geography, with the rationale that "groups" can
span several geographic areas (example: a multi-regional production
environment), so they're logically the "containers" of geographic regions.

Example: rtr01.us-west-2.prod.crittercism.com, NOT rtr01.prod.us-
west-2.crittercism.com

Great article.

~~~
Asparagirl
I like your way better.

------
15thandwhatever
It all depends on your environment.

Do you manage 12 machines in a closet, 200 EC2 instances, or 1,500 systems in
5 datacenters?

Do you have more than one datacenter in a given city? in a given campus? in a
given building?

Do you build systems that serve a single purpose such as a database, or do you
run multiple daemons on a single system? How do you take
docker/containerization into account?

How often are your sysadmins logging into these systems? Once a week (spell
out "production"), or 20 times a day (abbreviate it as "prod")?

Are your systems all owned and operated by you? Do you manage systems for
multiple clients in the same datacenter?

Does your team consist entirely of your college roommates you started your
company with? Or are you a team of 20 spread out across different time zones
and different countries? Will your funny/memorable names be offensive?

This all seems like an exercise in trying to build the The Server Naming Tower
of Babel Bikeshed.

~~~
romaniv
Yeah, but most of those are good ideas for a moderately large business that's
not managing other people's servers. Especially mnemonic names. Would you
rather reference ruby.web or W1L1Z (which is often the kind of cap that people
come up with by default).

------
thezilch
Presumably you'll need to iterate over hosts anyway, so why not move directly
towards your automation tools' (ansible, chef, puppet, etc) host inventory and
not fuss with DNS...

/etc/ansible/{dev,test,stage,prod}-hosts

    
    
      [nyc-dns]
      10.0.1.1
      10.0.2.1
    
      [nyc-web]
      10.0.1.21
      10.0.2.21
    
      [nyc-db]
      10.0.1.201
      10.0.2.201
    
      [nyc:children]
      nyc-dns
      nyc-web
      nyc-db
    
      [lax-dns]
      10.0.1.1
      10.0.2.1
    
      [lax-web]
      10.0.1.21
      10.0.2.21
    
      [lax-db]
      10.0.1.201
      10.0.2.201
    
      [lax:children]
      lax-dns
      lax-web
      lax-db
    
      [dns:children]
      nyc-dns
      lax-dns
    
      [web:children]
      nyc-web
      lax-web
    
      [db:children]
      nyc-db
      lax-db

~~~
e_proxus
Just started out with Ansible. How do you efficiently SSH into all these hosts
by name instead of IP?

~~~
thezilch
At the low level, Ansible has the ability to execute ad-hoc [0] modules [1]
against any combination of hosts defined. In my host(s) inventory above, you
can execute ad-hoc modules against just nyc-web, lax-web, web(against nyc and
lax), or whatever suites your needs or you've defined a host group for in your
inventory.

Report, using the "command" module, free memory on all "nyc-web" hosts in our
"prod-hosts":

    
    
      ansible -i prod-hosts nyc-web -m command -a 'free -m'
    

More often, we'll want to have Ansible playbooks [2] that take our hosts and
assign roles. Briefly on the topic, we might have a "common" role that deals
with updating our package manager, checking/upgrading packages that every
machine should have (eg. ssh, ntp, etc), and ensuring certain processes are
running. Second, we might have a "web" role that is similar to "common" but
dealing with web-server specific packages, configs, etc. As to keep it brief,
we'll skip how the roles are setup, but here's our "web" playbook (web.yml),
and find that we've defined the hosts [group] to execute against -- all hosts
under our "web" group in the hosts inventory.

    
    
      ---
      - hosts: web
        remote_user: web-user
        roles:
          - common
          - web
    

Which we'll execute with:

    
    
      ansible-playbook -i prod-hosts web.yml
    

Maybe you only want to hit nyc-web and not all web hosts? The following will
take the intersection of the playbook's hosts "web" and the "limit" hosts
"nyc".

    
    
      ansible-playbook -i prod-hosts web.yml --limit nyc
    

Or maybe you know the one IP you want to hit. The ":&" syntax is a logic AND
to find only the nyc 10.0.2.21, because we also have one in LAX. If your IP
layout, then simply a "\--limit 10.0.2.21" would do.

    
    
      ansible-playbook -i prod-hosts web.yml --limit 'nyc:&10.0.2.21'
    

[0]
[http://docs.ansible.com/intro_adhoc.html](http://docs.ansible.com/intro_adhoc.html)

[1]
[http://docs.ansible.com/modules.html](http://docs.ansible.com/modules.html)

[2]
[http://docs.ansible.com/playbooks_intro.html](http://docs.ansible.com/playbooks_intro.html)

~~~
e_proxus
Ah, cool. That clarifies things. I take it there is no way of smoothly
combining Ansible host lists with being able to use pure, old SSH?

~~~
thezilch
Ansible will use the native OpenSSH on your box, which does enable you to use
whatever is in your _.ssh /config_ \-- jump hosts, controlpersist, kerberos,
etc

------
oddevan
OK, I suppose a list of common, easy-to-pronounce words is ok...

I use Pokemon. What do you use?

~~~
pndmnm
To this day, my favorite naming scheme I ever encountered was names of
elements, everything CNAMEd to the elemental abbreviation, with the last octet
of the IP address as the atomic number. It was for a geophysics group, which
probably made it a little more discoverable/easily spellable.

~~~
kijin
That might work for a private network, but what if you have a /24 and need to
use the entire range?

Maybe find molecules with the corresponding molar mass, e.g. glucose = C6H12O6
= 180?

------
ChikkaChiChi
I found that naming my servers after characters legendary badass mexican Danny
Trejo has played to be cathartic and awesome!

Machete, Vega, Jack, Oscar, Angel, Tattoo, Tigre, Carlos, Vic, Reynaldo,
Guerrero, etc...

------
sciurus
There was a good debate about this on the devops-toolchain mailing list.

[https://groups.google.com/d/topic/devops-
toolchain/UZzAcEL7K...](https://groups.google.com/d/topic/devops-
toolchain/UZzAcEL7Kpw/discussion)

------
Zolomon
I guess there is no actual need to use security by obscurity to protect the
servers?

On the other hand, choosing a name for what is running on that server makes it
just one step easier for an attacker?

~~~
mitchellh
Only the web load balancers are likely exposed to the public internet, along
with some sort of bastion host. The rest are probably on your internal network
and can't be accessed/queried anyways, so the names mean nothing to them.

If attackers ARE in your DC already, you're already hosed, and the few minutes
that it would take them to determine that some obscure name like "host-a831f1"
is the DB won't matter.

So in general, I believe optimizing for maintainability here (easier names) is
more worth it than falsely believing that obscuring the names provides some
level of security.

Though, if all your servers are able to be accessed from the public internet,
it might be a different story. But that really isn't recommended.

~~~
awalton
> If attackers ARE in your DC already, you're already hosed,

That's a defeatist attitude, and the reason why security companies get away
with only selling perimeter defense products. "Well if they get in they can do
whatever they want anyways." If servers are properly insulated from one
another, violating a single server won't give them complete access to your
infrastructure.

An example of this: Valve was infiltrated by a hacker that managed to exploit
an ASP server for a random webpage, and was able to get all the way to Valve's
perforce servers and steal a copy of a the tree for Half-Life 2. There's no
reason in hell a random web exposed server should be on the same _network_ as
their Perforce server, but that's what having poor internal network security
does for you.

~~~
scott_karana
I don't think he's advocating that you should have unprotected internal
networks; just that the naming scheme shouldn't be confidential, since it is
one of the first things that will be exposed in a compromise.

Knowing the name "main.prd.example.com" doesn't help if it's got a bastion
host, thorough firewall rules, key-only SSH login, et cetera.

------
rachelbythebay
Even when you pick a naming scheme, it'll eventually cause grief if you get
big enough.

Name your machines XXYYN[N] where XX is the building name, YY is the rack name
and NN is the position in the rack? You'll eventually have more than 676
buildings, 676 racks, or 99 machines in a rack. Multiple people will have
written regexes to split that into building, rack, position and they will
break when you grow one of the fields.

~~~
dredmorbius
That's where the subdomain-based CNAME system comes in handy.

And I'd argue that building numbers probably don't want to be part of your
scheme.

    
    
        purpose###.env.loc##.domain.tld 
    

is about as deep as I'd like to get with my hostnames (though there are other
options for shortening them, with DNS search directives and such).

Encoding:

    
    
        purpose###.rac###.cab###.aisle###.env.loc##.domain.tld 
    

... might keep you from losing boxen. You will hate yourself typing that.
Store the metadata elsewhere, perhaps a txt record for the host.

------
corford
My naming system is pretty similar. Infrastructure consists of a handful of
big beefy machines that then each host anywhere from 4 to 12 single purpose
guest vms.

For the beefy host machines, I just go with core-a, core-b, core-c etc plus a
geo tag. So: 'core-a.de.domain.local', 'core-b.de.domain.local' etc.

For the vms, they get functional names like 'n0-dbc1.de.domain.local' (for
node0, database cluster 1) or 'git.de.domain.local' etc.

Only the last two digits of each guest vms mac address (or addresses if it has
multiple eth interfaces) changes. The rest is tied to the underlying host
machine. So e.g. 00:50:56:01:01:06 means a mac for a guest on 'core-a',
00:50:56:02:02:03 means a mac for a guest on 'core-b' etc.

All internal non-publicly routable IPs use our domain and the '.local' TLD
(with bind serving our internal network). All external, publicly routable IPs
use our domain and the .net TLD. Finally, our frontend website IPs use our
domain and the .com TLD.

The above wont scale well beyond one or two hundred vms per data centre
location but if we ever need more than that, it will be a nice problem to have
:)

~~~
btgeekboy
I'm guessing you don't use live migration of VMs very often?

~~~
corford
Nope, never. If a vm needs permanently moving from one core to another (which
would be unusual for us), we just spin it down and dd the lvm volumes for that
guest via ssh and then change the mac.

It helps that we don't filter on mac. The main reason for tieing the addresses
to the underlying core is to avoid accidentally allocating the same mac to two
different vms (since at the moment vm creation is still a relatively manual
process for us - hoping to improve this in the future though!).

------
TomasEkeli
Why tst instead of test, prd instead of production?

~~~
loudmax
If you're regularly typing the names, it's nicer to type something short like

    
    
      ssh prd01
    

rather than

    
    
      ssh production-01
    

On the other hand if you're managing clusters of servers using something like
ansible, you may not spend as much time typing in individual server names. I
think it may depend on how your workflow is set up.

~~~
gnaritas
Typing test and prod is likely faster than typing tst and prd because you're
not accustomed to leaving out vowels. Short doesn't have to mean no vowels.
Short real words are better than abbreviations.

~~~
res0nat0r
Because 3 letter grouping is visually easier if you use that for every
environment. dev, tst, prd, stg, ppd, bkp. Combines well with geographic
locations by using airport codes also.

~~~
gnaritas
Actual words are better for all environments; abbreviations are ridiculous.
They don't speed anything up, they slow down comprehension and they make
jargon where none is warranted.

The words you speak should be the words you use, not abbreviations of them.
You don't say prd, you say prod, you don't say tst, you say test, so prod and
test are what you should use. One ubiquitous language everyone can share
without the burden of useless jargon. Dropping out vowels isn't saving you
anything.

~~~
res0nat0r
> Dropping out vowels isn't saving you anything.

Except the consistency thing I was talking about. In one of previous job at a
fortune 100 company had to have a consistent naming scheme for everything in
the DC for whatever reason that predated me. 3 letter production environment,
followed by a 4 digit number which described all kinds of things about what
apps / environments ran on the host.

Also having fixed with fields for hosts is very valuable when you are writing
scripts to parse data on hostnames, especially when you are scaling up to tens
/ hundreds of thousands of hosts you begin to appreciate consistency.

~~~
gnaritas
I think the question is about what is good, not what do you do when you're
stuck working with a bad standards, and those are bad standards. Relying on
fixed length host names is as bad as relying on fixed length data or fixed
length file names, i.e. it's absurdly bad practice. These are things
developers learned sucked long ago. Fixed width is not valuable, it's brittle.

~~~
res0nat0r
I wouldn't use fixed values myself, but when I've worked at places with 100k+
hosts using naming schemes with consistent abbreviations of the same lengths,
with other fields describing consistent data is much better than fun names
when you need to fix things quickly.

Different story for small networks, have fun all you want. With hundreds of
thousands of hosts scattered all over the world, this isn't used.

~~~
gnaritas
I haven't said a word about fun names, I think you rather missed my point
entirely.

~~~
res0nat0r
I get it, you like full hostnames such as production-mail-server-and-
occasional-nas-file-server.

I'm just pointing out the fact that billion dollar real world orgs use
abbreviated hostnames more often than not, and they have good reasons to do
so.

~~~
gnaritas
If you got it, you wouldn't be putting up a straw man of long server names
like "production-mail-server-and-occasional-nas-file-server" so no, you really
don't get it because you aren't listening.

You can have short server names that are easy to type AND still use actual
words. Typing prd instead of prod is not saving you anything worth saving nor
making server names easier to type or remember no matter how many there are.

While

    
    
        production-mail-server-and-occasional-nas-file-server
    

is an absurd name, it was your example so I assume part of the scheme in this
big network, but you'd just have well crammed all the same info into...

    
    
        prod-mail-file
    

Without abbreviations and without losing the meaning.

> and they have good reasons to do so.

Yea, inertia.

~~~
res0nat0r
The real world companies I've worked for in the past have good reason to use
abbreviated host names, sorry this is so offensive, but that's...real life?

------
edwhitesell
This article, while interesting to repeat occasionally, was previously
discussed here:
[https://news.ycombinator.com/item?id=6796318](https://news.ycombinator.com/item?id=6796318)
And here:
[https://news.ycombinator.com/item?id=6800935](https://news.ycombinator.com/item?id=6800935)

~~~
teddyh
The subject itself was also discussed here:
[https://news.ycombinator.com/item?id=6540044](https://news.ycombinator.com/item?id=6540044)

I usually suggest that people read RFC 1178, _Choosing a Name for Your
Computer_ :
[http://tools.ietf.org/html/rfc1178](http://tools.ietf.org/html/rfc1178)

At least then they will avoid the usual pitfalls worked out over the many
years in which networked computers has existed.

------
jasonkolb
I kind of like the approach Elasticsearch takes to this, name an instance
after a random Marvel superhero. Keeps things interesting.

~~~
mitchellh
This is cute, but devolves into a maintenance nightmare very quickly. It is
much easier to look at a sever list and see "db001" than it is to see
"spiderman" and remember if that is a DB or not. Extrapolate that out to
hundreds of hosts and you kind of get the picture.

In a modern world where the machines might be homogeneous and VMs/containers
above define the actual role, the machine might just be "host123" whereas the
higher level services have specific names like "db001."

With service cataloging and discovery tools like Consul (disclaimer: I wrote
it), there is an easy way to see a mapping of service name back down to the
host it is on. So even if you're yelling to an ops person "hey db001 is having
problems," the ops person can quickly map db001 down to host 319.

And with slightly more complex (but worth it, imo) naming, you can determine
the rack, datacenter, etc. of a server just by the name.

~~~
Xylakant
> This is cute, but devolves into a maintenance nightmare very quickly.

Especially given that the name changes at every startup. It's absolutely not
recommended to stick with the auto-assigned names, but a rather good idea to
name the node after the machine or the location.

------
Flenser
When this came up before I liked the comment from an ex-dropbox employee on
how dropbox found positional hostnames to be a the best solution:
[https://news.ycombinator.com/item?id=6540044](https://news.ycombinator.com/item?id=6540044)
(top comment by gmjosack)

~~~
robaato
I worked in the field of infrastructure documentation for a while, applying
configuration management principles to it.

Naming is very important and often done poorly. The positional scheme you link
to works very well.

You need to label things, and bear in mind that you might be asking some
outsourced third party "pair of hands" who has no knowleged of your
environment to reboot a box - you want to be sure it's the right one!

Active equipment like servers often have naming conventions around function
etc, but consider what happens if someone remotely renames the server and its
physical label is ot updated...

For passive equipment, e.g. patch panels, we recommended a suffix indicating U
position (being consistent about whether U's coount from the bottom, and which
edge defines the U position). Most places start with U1 as the bottom U
position, and equipment that might take up Us 1&2 is defined as being in U1
(bottom edge). Alternatives OK, but be clear and consistent.

Many organisations are not definitive on location ids, down to city, name of
building within the city, even the names of rooms within a building - multipe
names often used!

Examples might be:

LON-DOCK1-DC1-AA02-PP-U41

LON-DOCK1-DC1-AB02-SW-U23

Sometimes:

SVR-LON-DOCK1-DC1-AB03-U01

(without U suffix is fine for such kit often)

Lots of fun in this area!

------
thiagoharry
I use pokémon names to name computers. I just pick the last 9 bits from the
computer MAC address, add 1, and check which pokémon have this number in the
national pokedex. This scheme can be adapted depending of the network. Perhaps
you could use the names of legendary pokémons to name servers and more
important computers. It's easy to find images, ASCII art and perhaps even toys
to put in the computers to help identification. And even if your network gains
40 new computers each year, the number of existent pokémons grows more than
this and you won't be without names. :-)

------
ttctciyf
I suppose it makes sense to get rigorous and logical about hostnames from an
admin point of view, but I do miss the romance and personal expression of
naming machines after.. well, scifi entities, fairy-tale dwarves, whatever.

One of the many things I like about my ISP is that they apparently feel the
same:

    
    
      traceroute to 192.9.9.100 (192.9.9.100), 30 hops max, 60 byte packets
      1  X.X.X.X (X.X.X.X)  7.057 ms  8.826 ms  8.859 ms
      2  c.gormless.thn.aa.net.uk (90.155.53.53)  26.691 ms  28.136 ms  27.243 ms
      3  c.aimless.thn.aa.net.uk (90.155.53.43)  29.673 ms  30.793 ms  30.273 ms

------
johne20
I used to go the multiple subdomain approach until I discovered some wildcard
SSL certificates do not support more than one level of subdomains. Therefore,
I now do something like staging-nyc.example.com

~~~
flyt
All wildcard SSL certs only support one level of subdomain.

~~~
derefr
You can use a SAN cert to create a multi-level wildcard cert. The cert would
be issued for:

    
    
        example.com, *.example.com, *.*.example.com, *.*.*.example.com [...]

~~~
duskwuff
That's technically possible, but you'll have a very hard time finding a CA
that's willing to issue a crazy cert like that.

~~~
flyt
It's easy to do once you have a good relationship with your CA.

~~~
caw
You can also self-sign for internal machines, and leave your public ones one
wildcard deep.

------
Fizzadar
In what world is `tst` a better part of a hostname than `testing`? All this
article seems discuss is a naming scheme for lazy people who don't want to
type long and descriptive hostnames.

~~~
unfunco
That was my first thought, the author seems to like three-letters, I don't
know why `sql` is better than `db` for database, considering not all databases
are based on the SQL standard, and `mta` for mail server? Really?

~~~
elasticdog
Author here...the important thing isn't the abbreviations, but having a
standard that you can agree upon and use consistently. The listed items are
just an example scheme that tries to keep the length consistent to make
scanning though a list visually a little easier.

~~~
pgl
I think you should make that more clear. It doesn't say anywhere in the
article "for example, you could use something like this".

------
Goladus
Just want to highlight one thing:

 _Essentially, the hostname should not have any indication of the host’s
purpose or function, but instead acts as a permanent, unique identifier to
reference a particular piece of hardware throughout its lifecycle_

It follows that if you are using virtual machines and configuration
management, where the lifecycle of a VM or amazon instance is trivial compared
to an actual piece of hardware, there is less benefit to separating hostname
from functional name.

~~~
molf
Actually, it's still quite nice if the hostname has no relation to the
server's purpose – the functional name can then outlive the hostname if you
throw away and recreate VMs regularly.

------
tallanvor
Our primary server names identify the location (for us), and we try to keep it
very short:

<data center><rack><unit>

So for example: sea1r001u01. Our team in the data centers provide the initial
name based on where they place the server. The unit value starts at 01 at the
top of the rack and increases sequentially.

This means that if we have a hardware issue, the data center teams only need
the hostname to know exactly where the server is located and get to it.

------
KaiserPro
I've been through a number of naming schemes for a few different purposes.

Firstly all VMs are named after their function(AD01, named01 etc) we never re-
purpose VMs

Workstations went through a few conventions dependent on size:

o sysXXX

o french revolutionaries

o generals from WW2

o Fellows of the royal society

o Towns of the UK

My favorite is fellows of the RS, as a lot of them have wiki pages.

The key thing is that you don't recycle names. When a machine dies, so does
the hostname

------
Pxtl
Why do they do this? Why do infrastructure people suffer so much pain learning
the same lessons software developers learned many years ago?

1) Join the vowel generation. If your tools cannot handle unlimited length
names, use different tools.

2) Use descriptive names. Don't name them after your pets.

3) Rigid rules like Hungarian Notation produce cryptic and irrelevant noise.

~~~
jrochkind1
The idea proposed by OP is precisely NOT to use a descriptive name as the base
A record.

Why? Because the functions served by this machine may change over time -- so
any descriptive name you use may become confusingly inaccurate.

But you need a way to refer to the _machine_ itself, whose functions may
change over time. The best way to do this is to pick a _non-descriptive_
unique identifier that will always refer to that machine. As the OP mentions,
that non-descriptive unique identifier "will mostly be useful to operations
engineers, remote hands, and for record keeping."

Then you make a descriptive name as a CNAME. Which, they don't mention, but it
might change over time what that CNAME points to etc.

I have found this general principle to be a very good one even in my much
smaller shop. When we used descriptive names as the 'main' canonical machine
name, this led to huge confusion when roles changed -- you either had
descriptive names that were no longer accurate or confusing, or you changed
them but still had documentation or notes or tickets referring to the old
name, etc.

The rest of the OP goes into a suggested scheme for making the descriptive
names (the CNAME's), in a way that will actually _be_ descriptive of what
developers and ops will need to know. Their scheme seems pretty decent to me,
but definitely depends on the particular context and domain of the shop,
including how many machines you have, if they are geographically dispersed,
etc.

But the basic concept of using a _non-descriptive_ name as the basic machine
name A record, with descriptive names being CNAMES to it -- is I think pretty
widely applicable and wise. (And that mnemonic projet list is pretty useful
for creating non-descriptive unique identifiers that are still easy to
remember and record).

~~~
peterwwillis
He didn't say to use a functional name, he said descriptive. If the machine is
an hp bladecenter 7000 series, reflect that in the name. The functions may
change but the silicon will not. If you're paranoid about security, create
class names that refer to classes of hardware and number identical/similar
ones.

Also it's useful to put the dc and rack number in subnets after the hostname
(hpbl7x0001.r55.la.example.com). The next time you're running around the cage
reading every single 1U's tag name going "AARRRGHFHH WHERE THE FUCK IS
SLIMSHADY.EXAMPLE.COM??", you'll thank me.

(i have no idea why, but it's much easier to get a dns admin to create a new A
record than it is to get a NOC employee to update the network inventory
database)

(also: good luck using your network inventory db to look up a rack location
when the rack/switch that's hosting the network inventory db is down...)

~~~
lmm
Just tell the real server to please stand up.

> (i have no idea why, but it's much easier to get a dns admin to create a new
> A record than it is to get a NOC employee to update the network inventory
> database)

Well yeah, if parts of your organization are dysfunctional then you find ways
to hack their functions into the more functional parts of your organization.
But that doesn't make it the right approach in general.

------
harty65
We decided to be democratic in our office and arrange a vote for the name of
the new server. Unfortunately this resulted in the server being called "Ron's
Electric Love Machine". (Thankfully this abbreviates to RELM which is a bit
easier to deal with)

------
wyc
I name my servers with names fitting ships so that I may have a proper fleet
of boxen.

------
andyhmltn
I actually had this problem a while ago but now I use a script I wrote:

[https://github.com/andyhmltn/frosty-
meadow](https://github.com/andyhmltn/frosty-meadow)

To generate one during the setup of the server automatically

------
kayoone
This list of hostnames comes to mind from an older thread:
[http://seriss.com/people/erco/unixtools/hostnames.html](http://seriss.com/people/erco/unixtools/hostnames.html)

------
mediaserf
I generally use hyphens instead of subdomains for SSL certificate purpose and
go general-to-specific in the order:

datacenter-application-environment-index.domain.com

example:

ord-web-prod-01.domain.com

For clouds I use the cloud and zone/region:

rs-ord-web-prod-01.domain.com aws-east1-app-stg-01.domain.com

~~~
Alupis
I really dislike the suggestion of labeling devices by what they are.

fwl, ups, pdu, rtr, swt, etc... all really give away too much info imho.

Yes, someone may discover what the device is on their own via nmap -O or
something, but telling someone up front this is a PDU and if you mess with it,
it may crash an entire cabinet... is just... silly.

I tend to follow the parent comment's suggestion more, labeling by location
and environment (prod, dev, etc).

~~~
DmitriRavinoff
Assuming you're doing split-horizon DNS, those records should be hidden from
the outside. And the only way to detect the CNAMES other than brute force
scanning of a DNS zone is to do a zone transfer. And you only have zone
transfers allowed from other relevant DNS servers, right? And your monitoring
software will catch a brute-force scan, right?

Remember that the reverse dns always resolves to something like
orange.example.com, which gives away no information at all.

~~~
Alupis
Not if you don't control the DNS, and/or don't notice a crawl in the
background network noise.

------
zx2c4
I've never seen MNX before. I noticed in their pricing and features that they
offer "additional IPs at no extra cost". Has anyone had experience with this?
Are there limits?

~~~
nwilkens
Thanks for checking us out!

We ended up chatting -- but for further clarification for anyone else -- yes,
you can have additional IPs if you can justify them. There are practical
limits, but we haven't come across a situation where we've needed to enforce a
hard limit at this point.

------
ingenter
Another interesting naming scheme:
[http://www.reddit.com/r/nameaserver](http://www.reddit.com/r/nameaserver)

------
andrewchoi
2 hours and no reference to the relevant XKCD?

[http://xkcd.com/910/](http://xkcd.com/910/)

~~~
e12e
Because it's in the top of the page of the story you're commenting on? I'm
sure we can keep hn from turning into /. for a couple of more years yet... ;-)

------
kaonashi
Where do you put the Star Wars references?

------
aashishkoirala
I wish I had this about 5 years ago when I was knee deep in server naming.
Good article anyways!

------
tragomaskhalos
Big choice of names? Memorable? Fun? Just name them all after Muppets.

------
bencollier49
This scheme has no way of denoting if a machine is virtualised or not.

------
akshatpradhan
How would this naming scheme work if you're using heroku?

------
arthursilva
Good post. Does anyone knows this company? To the company: VERY BAD call
requiring users to signup to check custom instances, specially at the
beginning, you should prefer new customers to new signups.

~~~
nwilkens
Thanks for the feedback! We're still optimizing, and this was a mistake not to
put the pricing calculator on the main website.. we're working on that and
will move it to the main page soon.

------
drivingmenuts
Don't forget to encode the physical location if that's a thing. It might be
important to know that web02.prd.nyc.com is in Row D, Cage 4, Slot 5, Front.

------
jjmiv
was the mnx.io article talking about the hosts file? or what you put in your
dns manager....or both?

------
jflowers45
"and yet you settled on Caroline as a name in a few seconds" ... that's a
pretty good cartoon

------
alpb
stg or str is better than sto (storage).

------
antocv
dev,stg,prd... omg, whats so bad about actually spelling it out?! Its not like
you require those precious bytes for your business to suceed.

~~~
ZoFreX
> "The actual purpose abbreviations you use aren’t important, just pick a
> scheme, make sure it’s documented, and stick to it."

Given that in some cases you might be typing them very frequently, some people
would want to shorten them. I assume it's more to do with typing speed than
saving bytes somewhere.

------
mkfifo
Thanks for making it so clear what services your machine provides on the
public internets. I like advertising on the public internets too and sometimes
I even run SSH on port 22 with root access enabled for convenience sake. Also,
since I have so many servers, I make sure to run fingerd and include hints to
what the root password is in my plan (everybody knows what it's like to forget
a pw).

Another good thing to do, I was told that according to RFC1413, always make
sure you are using identd service, it's a very helpful protocol.

I just don't get why people are so paranoid on the internet I've been a sys
admin since the 90's and never once had a virus or been hacked.

I guess with everything now being a "devops" world, we should just focus
entirely on convenience and forget about the old timers annoying speeches on
"SPOF" and "Security/Risk Management" that block me from pushing my awesome
new codes to production as quickly as possible. We use Chef and CI so I don't
ever have to even think about the server itself, other that it is running
Ubuntu, which is super fast and a very secure OS.

I love when new software comes out, I just grab the recipe and ship it! Even
if it is geared to server farms with hundreds of machines, I probably need to
use it for my 5 server cluster.

Anyway, sorry to get off topic.

~~~
xenophonf
I'm an infosec guy, and I think sometimes we can make things so difficult for
attackers that it becomes too difficult for our sysadmins to do their jobs.
Using obscure, pseudorandom server names is a good example of this. If I get
an alert that says, "uxeprdweb05 is down", I know to immediately check the
Mason, OH, production hypervisor cluster/web server rack. If the alert says,
"I-2A51DDBCE621 is down", I have to look up that host in my CMDB before
starting any troubleshooting. Sure, "uxeprdweb05" leaks information to
attackers, but it's nothing they couldn't find out with a port scan. In the
meantime, I and my colleagues don't have to go through a lot of unnecessary
indirection to do our jobs.

As to the security benefits of configuration management tools, again, speaking
as an infosec guy, I love them. I can push a locked-down, default-deny base
config out to all of the computers under my care, and I don't have to worry
about making a mistake or missing a step or forgetting to document something.
I can work with the devops team to set up automated functional and security
testing using a continuous integration tool, so that config changes (including
security updates!) get vetted automatically in a development or test
environment before being pushed to production. I can put the whole config
under revision control, so if there is a service or security incident due to a
config change, we can figure out how our development and testing processes
failed us - and how we can improve them.

And finally, speaking as a ardent FreeBSD user, I wholly agree that Ubuntu is
utter rubbish.

;)

~~~
mkfifo
I am not talking about insane cryptic obfuscation, i am simply stating that
advertising services by publicly naming your server what it runs is flat out
n3wb stupid.

~~~
xenophonf
And my point is that public-facing services already advertise all kinds of
information about themselves. Obscure codenames won't make attacks harder to
run, while they will significantly increase the level of effort on the part of
your sysadmins. Infosec is all about cost-benefit analysis and risk reduction,
right? Well, in my view the administrative overhead costs of a naming
convention like "Star Trek characters" outweigh the supposed security
benefits.

I will grant you that it may come down to differences in our threat models. In
my case attacks are impersonal - it's the malware or botnet /du jour/ that I
have to deal with on a regular basis, versus the kind of APT facing
journalists, civil rights organizations, or militaries. Even then I'm not sure
that naming conventions that leak less information than a basic port scan will
slow APT down. Too, the administrative overhead caused by forcing sysadmins to
constantly go to a CMDB just to do basic troubleshooting might be a cost
targetted organizations would be willing to pay. In my case, we run really,
really lean, so we do what we can to make our I.T. services self-documenting
(naming and numbering conventions that have meaning across multiple network
layers).

