[nycbug-talk] Sanity check on new naming scheme

[Matt Juszczak]

Hi folks,

I'm currently in the middle of a systems and network overhaul that's 
pretty large and spans multiple data centers.

I'm working on developing standards, which include all servers being 
maintained by local puppet servers (one at each data center with one fail 
over), centralized authentication/sudo/authorization with LDAP (a few 
slaves at each data center with one primary LDAP server in one data 
center that all writes go to), centralized syslog (one server at each DC), 
and standard DNS (external .net and internal .internal).

I just wanted to sanity check my thoughts on a DNS naming scheme.  It 
seems like putting the description of the box (such as db-blah-01) in the 
name isn't what we're looking to do, and we're also trying to avoid 
generic names (server14, server15, etc.).

What I think we've decided on is something like this:

<server name>.<data center ID>.domain.net	-> public IP
<server name>.<data center ID>.domain.internal	-> Local IP

For example:

bob.nyc01.domain.net
bob.nyc01.domain.internal


Since we probably wouldn't choose to re-use server names, we would do:

bob.domain.net

as a CNAME to the hostname of the box, bob.nyc01.domain.net.

domain.net would only be used for network infrastructure and for nothing 
else, so there won't be collisions.


As for actual functionality of boxes, we were thinking of doing CNAMEs:

blah.db.domain.net -> bob.nyc01.domain.net


In the past, I've had different interfaces on boxes, and have added a 
subdomain to say whether the DNS entry points to the primary IP of the box 
(m for machine), or a service on the box (s for service).  Not sure if 
this is something we should do.


Any opinions?  Can anyone else let me know what kind of flexible scheme 
they use?

Thanks,

Matt