5

I've recently been thinking about the TTL of our DNS. We have A records for our servers and then CNAME records for the customer facing names. The www.example.com CNAME points to server-01.example.com for example. In the event of a failure we have the TTL set at 15mins on both the CNAME and A record.

However it dawns on me that this might not be optimal. Surely it should be that A record be 48 hours and the CNAME be 15mins. The CNAME just gets pointed to server-02.example.com in the event of a failure. The A record (in theory should be cached quite happily for a long time, because we use the CNAME as the switcher).

Looking around the Internet I found lots of people having their CNAME long and the A record short: CNAME and A record have different TTLs. Which one will be cached?

This seems contrary to what anybody would want. The question is, does DNS work in the way I hope it works, in that the CNAME request TTL is the important one for if I needed to switch servers in a hurry?

4
  • When you have a moment, please accept one of the answers so that this doesn't show up as an unanswered question. If you need more details on the original topic, let us know.
    – Andrew B
    Dec 21, 2014 at 22:20
  • @AndrewB I don't feel that either of the two answers offer a technical explanation of order of precedence (Why having a short A record verses a long CNAME). Your answer follows the logic that the lower TTL should be used with the one that is changed most often, yet we see Google (who are probably experts in their field) running what is expected to be the opposite configuration. Dec 22, 2014 at 10:03
  • The TTLs in that chain are 7200 (CNAME), 604800 (CNAME), 300 (A). The obscenely huge TTL on the middle record (ghs.google.com) suggests the exact opposite of your assumption: that record is rarely ever touched at all. Why it is modified so infrequently would be pure speculation, but it's fairly obvious that Google is going to modify the A record if they need to modify anything at all.
    – Andrew B
    Dec 22, 2014 at 11:25
  • Rereading your question again, this is an invalid comparison to begin with. I've updated my answer to reflect this.
    – Andrew B
    Dec 22, 2014 at 12:26

2 Answers 2

6

Assuming that the apex A record for example.com. was pointing at a broken IP address, most companies I know would change the A record and skip the www change entirely:

  • Most admins would rather not have their website broken for users who key in the name of the website without the www prefix.
  • This goes double for admins who don't trust their webapp devs to consistently use www.example.com over example.com. (hint: most of us don't)

Moving on to your linked example, you're comparing apples and oranges. Apex DNS records in web hosting scenarios are a massive pain because of the well-known apex CNAME problem. There are only two correct choices in this circumstance: either the apex A record is changed as necessary to point it at a valid IP, or you forgo having an apex record entirely. Anything between the two is half-baked and inconsistent.

All of this is somewhat beside the point though: if you are relying on manual record changes to handle high availability for your service, you are doing something wrong. The IP address the web browser hits should be a load balancer, an anycast address, a CDN, or a webhosting provider who can provide this high availability if your own server farms cannot. Multiple address records can also work if you're confident that the primary applications consuming them follow follow RFC 6724 guidelines (i.e. most popular web browsers), but many applications are lazy and simply use the first address record returned.


For the sake of the argument, let's examine Google's CNAME chain on its own merits without putting it into the context of your original problem. This will look familiar, as it's the text of my original answer:

Record type is inconsequential here. If the record needs to be changed frequently, it should have a very low TTL. If it doesn't need to be changed frequently, it stands to reason that it doesn't need a low TTL and you can use whatever you're comfortable with.

No one (other than Google) can really comment on why Google wants ghs.l.google.com IN A to have a lower TTL than the CNAME records pointing at it. You can't draw any conclusions without understanding their larger design, and the design is what dictates your moving parts.

2
  • 1
    "All of this is somewhat beside the point though: if you are relying on DNS to handle high availability for your website, you are doing something wrong." That statement could not possibly be more incorrect. Without BGP or an expensive third party service DNS is absolutely the best alternative to a highly available site on multiple providers. TONS of people use it, because it works and it works well.
    – Preston
    Mar 16, 2016 at 16:32
  • I was reviewing this Q&A again and amended the answer to be more clear in my intent. I stand by the fact that manual address record changes are not a good HA strategy. Multiple address records may have been what Preston was referring to, and that is a more sensible strategy.
    – Andrew B
    May 2, 2016 at 21:42
1

I agree.

As long as the "real servers" have stable IP addresses the A records should have long TTLs. Keep the TTL on the CNAME records low to enable fast switching to another real server in case of failure or whatever.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .