Computer name naming convention for security
You have identified only one risk, that of an attacker identifying machine roles on the network by using predictable host names.
I think you missed the competing risk, that of increased operator error by not using predictable and descriptive host names.
This is how I would assess those conflicting measures:
Use unpredictable host names
Benefit(s)
An attacker will need to spend (significant) more effort in determining the layout of your network and to identify the most profitable targets for a penetration attempt.
Risks
Operator error. Users and administrators may have difficulty identifying systems and their correct roles e.g. confusing test and production systems.
- Probability: high
- Impact: high
Rationale: Most humans have terrible memories where "random" data is concerned --> high probability.
Also there are usually very few barriers that prevent trusted users and administrators from making high impact mistakes --> high impact.
Use predictable host names
Benefit(s)
Reduced operator error rates, ease of management and automation.
Risks
Attackers will also have an easier time determining the layout of your network and to identify the most profitable targets for a penetration attempt.
- Probability: medium
- Impact: low
Rationale: Not every naming convention is immediately intuitive to a black-hat attacker --> medium probability.
Also using hostnames to predict a network layout is only a shortcut, but doesn't provide information that an attacker wouldn't be able to learn through other means. And knowledge of the role of a server as disclosed by a hostname does not automatically make it more vulnerable (only more or less valuable). --> low impact.
The fact that there is no readily available information to support your conclusion, should give you some idea about its validity.
The point is, that if your attacker is already in, he will need to do some additional foot-printing anyway. Your host name may be database.xyz.intranet, but if the nmap gives you 1521 (oracle), 1433 (sql server) or 5432(Postgress), that gives some information about possible vulnerabilities.. Sure, it will save some time knowing that www.companyname.com is probably not the back end database server, but that is minimal.
On the other hand: are your developers really happy to do SQL-queries on linux20195681.intranet? What is they fire-up a second database in your on-premises cloud? Giving some meaningful names simplifies their life too. And of course it easier for the stand-by that is called at 2 a.m.
Also, your real servers may be hidden behind a load-balancer. The VIP would then typically get the functional name and the hosts behind it some sequence number.
If you are in a small organization, you could consider giving your hosts themed names (e.g. my Pi's at home are called pi, rho, sigma, phi, etc.), but even then, I struggle to remember that sigma is my home-automation, psi my DNS server etc. And yes, you might theme Zeus as the production database, Jupiter as test and Odin as develop, but at some point, any form of polytheism will put a limit on the number of servers.
So it really is better to give them functional names.
On the other hand: don't be to specific or alluring. Calling a host privatekeybackup.intranet will surely attract a bit more attention.
There have been some ideas of randomizing host names (rfc8117) but that seems more an issue for clients.
What you're advocating for is called "security though obscurity". While in theory obscurity does provide some extra protection while not making things worse, it usually does make things worse in practice. It (1) adds complexity to the system which leads to errors, (2) dilutes the understanding of what information is secret and what isn't, and (3) may have a non-trivial maintenance cost.
An example of (1) would be an admin applying low security settings to a highly sensitive server because the fact it was sensitive wasn't obvious from the name.
An example of (2) would be a user which is asked by IT to disclose the server name which they think is secret. Later, when they are asked by an attacker pretending to be IT to disclose their password, they will be less surprised and less suspicious.
An example of (3) would be the fact that in order to maintain obscure server names, IT will have to change them every time they suspect their network was compromised.