The DNS CNAME record is probably the greatest tool as an administrator that we can use to facilitate moves and changes in the backend when using Active-Directory integraded DNS. Using the CNAME record for database connectivity is a new strategy I have started to use to facilitate server moves simply with the DNS change. Take the following example:
FQDN Server Name: DATASERVER1.AMCS.TLD
Associated CNAME: CORPDB.AMCS.TLD
Now, DATASERVER1 is a Windows cluster for Microsoft SQL Server with a disaster recovery site with the databases mirrored. If that is needed to be used, the CORPDB record points to DATASERVER2 to redirect client traffic to that database server. But, the management does not stop there. This accomodates for a single change in DNS to point the server in question to the remote data center (RDC) database engine as a different FQDN name. But, I've been taking this a step further with CNAME use. For each database, I have been creating a CNAME record that points to the relevant server or DNS CNAME that the database is currently housed upon. Further, I make these CNAME records self-documenting in their nomenclature so that looking at the DNS records tells you everything needed. Here is an example:
Associated CNAME: DB-DATABASENAME-STATE.AMCS.TLD
FQDN server name of target host: CORPDB.AMCS.TLD
In this example, DB indicates a database, DATABASENAME would be the application name and STATE would refer to the implemenation level (Live, Test, etc.). All of these relevant records starting with DB- helps in alphabetical sorting in the DNS console. By using CNAME records in this fashion, all client connectivity is pointed to the DNS record instead of the server name. This permits a move of the server and a move of the individual database to be transparent of any configuration outside of DNS record management. By pointing all client connectivity to the CNAME record, configuration changes are not required (other than clearing a DNS cache) on the clients accessing the databases.