Or simply have a naming convention for hosts. I realize that only makes sense for sufficiently large setups, but once your setup is large enough, it does make things easier.
At $work we maintain setups for customers, and our FQDNs are roughly <function><counter><environment>.<customer>.<ourdomain>.tld. So the second database server in the testing environment for customer "nasa" (hypothetical, of course) would be called db02t.nasa.<ourdomain>.<tld>.
It does make it pretty obvious from the FQDN what the used is being used for.
It looks like there's two types of answers in this thread, and the difference between them is whether their infrastructure is cloud-based or running in a datacenter:
- Cloud: "Who cares? Name them after pokemon or dinosaurs, you can always reprovision and they won't last very long."
- Datacenter: "But what if the name doesn't make sense 16 months from now??"
At $work we maintain setups for customers, and our FQDNs are roughly <function><counter><environment>.<customer>.<ourdomain>.tld. So the second database server in the testing environment for customer "nasa" (hypothetical, of course) would be called db02t.nasa.<ourdomain>.<tld>.
It does make it pretty obvious from the FQDN what the used is being used for.