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.
Assuming you meant "short ID", how is that any different than the OP's suggestion of randomly choosing from a list of meaningless names?
a1, a2, ... aN for serves 2 cores 8GB ram
b1, b2, ... bN for serves 4 cores 8GB ram
c1, c2, ... bN for serves 4 cores 16GB ram
...
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.
For a 50% chance of collision you need Math.pow(2,32/2) calls to your ID generating function which is 65536 calls.
And that's just a 50% chance. Even a 1% chance is too much (for which you would need much less than 65536 calls).
I doubt "IBM, Google or Microsoft" are using 32bit UUIDs.
"4 billion IDs is likely Unique within an organization"
I don't think it's unique within any organization.
"Sure Frank. What's its host tag name?"
"AF84n3Dd2PM."
If the hostname is randomized, then the logical thing would be to copy and paste the hostname and send it off over the wire, which would theoretically cut down on human error.
It's annoying enough to try to find "snowwhite" amongst 40 servers in each of 40 racks; trying to scan the list of names for "ABC123XYZ987" when none of the name correlates with any useful information would be absolutely maddening. Jesus christ, I can just imagine for every sever looking at the name on a sticky note, looking at a tag name, and then looking again at the sticky note and back to the tag name, possibly a third time, just to make sure it wasn't off by one number or letter or something. Repeat for thousands of servers? Euuggh!
Besides the poor cage monkey having to deal with that crap, when you're fighting fires in the ops room you need to be able to refer to a handful of server names quickly. You can't be copying-and-pasting names to people, looking information up every 2 seconds because you can't possibly memorize it. We are human beings and so we need human interfaces to information.
dig +short 4test.shephard.org
4.2.2.2I've done this, and it works very, very well with third parties. You simply give them their work-order, and it consists of working on particular physical devices.
I.E.
Row 10, Rack 11, RU-15 - Serial Number 103527382 - Replace Hard Drive.
Row 13, Rack 9, RU 6 - Serial Number 103528942 - Replace Power Supply.
etc...
The work orders are generated from your CMDB, which tracks things like serial numbers and physical locations.
As organizations grow, this is eventually where they all end up (after multiple iterations of other less scalable systems)
In the above case, the question was how to direct technicians to gear - and, specifying a physical location and a faceplate label (Serial Number or what have you) does the job.
In the case of Humans - they usually have cnames for the function they are interested in anyways.
I do work on about 4500 servers - and I couldn't tell you the name of a single one of them (though, I note they have some long convoluted DNS PTR, even harder to understand than a serial number) - But, I have a ton of cnames when I want to login to a particular customers server (based on customer, production/test/dev/fste, function).
Teams that need to do maintenance on servers have tools that group them based on role, location, data center, etc... They never actually "ssh" into a server the way I might.
A lot depends on whether you are talking about scales of 100+, 1000+, or 10,000+ servers (or network devices for that matter) At each stage you start to lose more and more of human naming convention, and move everything into a Configuration Management Database (CMDB)
The human interface problem is solved by physical directions, not type of data provided.
That was part of the reason for that curated list of words that they were recommending in the article.
> If the hostname is randomized, then the logical thing would be to copy and paste the hostname and send it off over the wire
Eventually that chain of communication will need to end in an action. Not all actions are just "copy-paste it into a box." What if I know that the server is a "Rack #3", but now I need to look at labels on the actual servers to find server 'SDFssdfa4324tdfgfg"? It's a lot easier to grok server "crimson".
Bob: "Frank? Which server did you say was on fire?" Frank: "It's the email server. The name is ..." Bob: "Frank - you know the rule. Send it, don't say it." Frank: "Uh ... I can ... maybe text it to you?" Bob: "Insecure." Frank: "Uh ... pigeon?" Bob: "The intern ate the last one." Frank: "Uh, carve it on the intern's back?" Bob: "Tattoo it. Safer that way." Frank: "OK, give me an hour." Bob: "Hey, server's burning, you know. Ain't gonna last forever ..."
Keeping your hostnames secret, like dropping ICMP, is useless.
However, I personally question the wisdom of giving a network intruder a roadmap to your internal network via easily predicted DNS names, but that's probably just me being paranoid.