In his post on using the network as a place to store config configuration, Udi Dahan suggests that we use separated subnets when we want to have test setups with the same configuration as the production setup. I’ve seen some similar stuff to what Udi suggests.
1) Using cnames that have meaning pushes semantics into the network (i.e., DNS server)
Of course the real server name is something like uk_site002_prod_win98_2 and that has meaning to someone in the netadmins (that is, unless they have settled on one naming convention per machine) but we really like it to have meaning in the context of our application stack. So we get a name like CRM_APPSERVER which is readable and can be used across the organisation. And we stand a chance of using it to swap out to other machines when we really need to, like during a crisis.
2) Using local cname resolution for testing on developer machines
The use of cnames has another thing. When you are testing things locally you can go to your HOSTS file to map the meaningful cname to another machine. In my case that is often localhost. This works really well for me when we are using SQL server linked database servers.
3) Using subnet resolution of cnames for multi-machine test environments (what Udi says)
So. You can take this to the next level and set up a small test subnet that has the cnames adjusted from a local DNS server that means you can keep the same names and they resolve to machines on the test network. Probably at this stage you have the netadmins make you really safe and ensure that you can’t even route the traffic out of the subnet.
4) Using Active directory as a place to look up *everything* not just semantic machine names
I’ve seen this taken one stage further to have Active Directory used as a supergiant, cross-process, cross-machine singleton. Basically, it was used to store the application config for the whole domain. Problems were it became rather cluttered with dozens of settings and the ease of access to the config meant that all levels of the application stack were able to just reach out and get it! That, of course, wasn’t the fault of the config. You could do quite cunning things coupling this with AD permissions, child domains and so on. Meaning you could do things like drop binaries onto the machines from the outside, but the machines inside can never get out even if they try.