I've long thought that the DNS CNAME is one of the most underrated infrastructure technologies considering it has been available for a very long time. Simply put a DNS CNAME is an alias record that points a user-created fully qualified domain name (FQDN) to an existing FQDN. I did a post a few years ago how using the CNAME for a database's ODBC connection is a great way to accommodate a server move without touching the application or server.
Recently, I again had the privilege to be a guest on the Virtumania podcast. On episode 9, we discussed virtualizing SQL servers. The guest of honor was Brent Ozar, a SQL MVP. When it comes to using a DNS CNAME with a SQL database, I was very curious to hear Brent's opinion on the topic. His answer was that infrastructure people are fine and well within their right to manage connections that way, but most database administrators don't have that power in the DNS infrastructure. That is a very valid point for most organizations, as application teams are separate from network infrastructure teams. I had flirted with this very topic in a post earlier this year that dealt with delegating permissions to DNS records for application owners.
There are a lot of factors to determine if these practice points make sense for your environment. While these practices work well for me, Brent brought up the topic of time-to-live (TTL) to maximize the effectiveness of a CNAME record. For Windows Active Directory-integrated DNS engines, the default TTL for a CNAME record is one hour. The TTL simply puts an expiration date on the DNS record that resides in a client resolved. When it is expired, it should resolve the record again from DNS servers that are authoritative to the zone.
When it comes to using the CNAME as a failover or disaster recovery tool, a shorter TTL should be used. I've used them in the 15 minute range, but think that anything more frequent would be excessive on the DNS server. The 15 minute range takes into consideration the reality should a primary system fail; there is a certain level of response time for most systems. Systems such as Web servers may be an easier item to fail over to another server and make sense for a shorter TTL.
When it comes to creating a custom TTL, what values do you use? Share your comments below.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.