[nycbug-talk] Sanity check on new naming scheme

[Isaac Levy]

Word,

My .02¢,

On Apr 7, 2010, at 1:51 PM, Matt Juszczak wrote:

>> Any reason you don't use functionality as part of the name?
> 
> Security by obscurity :)

Well, yikes- not sure I like that reason, but I can give a different/functional one:

I'd typically rather name the machines uniquely, (sparrow.hostname.com, crow.hostname.com) instead of functionally, (e.g. www2.hostname.com, www3.hostname.com).

That way, when the box which was www2.foo.com gets re-purposed for use as svnbackup.foo.com, the machine name doesn't have to be completely changed- and documentation and other materials related to that server don't have to be changed- IMHO it's a crazy task to always be updating documentation across an organization just to change names around...

!!! Then, for specific services, domain names can be mapped as CNAME aliases (or A records, depending on context/use), to any of the boxes- without much fuss.  Examples, www.publicdomainname.com, svn.domain.internal, wiki.domain.internal, etc...  The stuff people actually use.  When failing-over to a backup for a given service, or whatever, it's less disruptive for (n) number of users- (nothing less disruptive than telling a team of devs they all have to change their source code repo in their IDE's and such).

I'm a big fan of keeping boxen and services separate identities, as far as dns goes.

Last important thing for me: for those names, it's really good to have pre-generated lists of the names to use, because it's often the last thing I want to figure out while unboxing/deploying a server.
Things I've used/inherited in the past: elements from the periodic table, names of birds (from a little book I had in my desk), names of fish, food, island names from around the world, bodies of water, rivers, (stay away from cities and physical locations because eventually every org ends up with some idea of where the boxes physically are).

> 
>> Your naming schemse seems sane/sound.
> 
> Awesome, thanks!


I agree- your scheme is simple and clean, and I've had great results with the sort of naming scheme listed.  I have a few personal things to add, (as I have done similar setups), however it increases the management/overhead of naming so I can't say they're hard-rules I follow:

--
Regarding <server name>
unique name for the machine, not it's function/service

Regarding <data center ID>
I tend to use the name of the physical network zone instead, for example:
<server name>.<core network name>.internalname
e.g.:
servername.computegrid.internalname
servername.utilitynet.internalname
servername.corenetwork.internalname
servername.officetrusted.internalname
servername.officeuntrusted.internalname
servername.dmz.internalname
With this method, I prefer to keep the documentation about the network out of the machine host name.

Regarding .internal
Something SHORT and unique-ish to your org, but not conflicting with TLD's! (make it easy to type, everyone will be typing it a lot!)
--
<server name>.<data center ID>.domain.net	-> public IP

For public use, I really only find value in this naming if it's matched with PTR records, (if we're managing PTR internally)  Otherwise, I don't bother with it at all and focus on the pub. fqdn mappings...

--
<server name>.<data center ID>.domain.internal	-> Local IP
I love this as hostname settings for machines, as well as keeping it resolvable on the internal networks.

However, for the sake of scriptability/manageability, I tend to also make sure the following convenience is in place:
<server name>.internal

This way, users/developers don't need to constantly be aware of which network zone is which, and if a box/service/idea is moved to another network zone, scripts/programs set to reach it still just work.  If the machine is moved to a different network zone, scripts still work and users still can get to it.
It's also far less typing, important to me as things grow.

I tend to set this kind of thing up with internal DNS using Bind Include statements in my zone files, keeping the host mappings in single files- I'd bet this is easy with djbdns too.
This strategy allows for many DNS names to be given for a single host, yet keeping management simple and consolidated to individual zone files.
--

A long .02¢,

Best,
.ike