What does the TTL on a CNAME record mean

CNAME records were originally created to allow multiple names that provide the same resource to be aliased to a single "canonical name" for the resource. With the advent of name based virtual hosting, it has instead become commonplace to use them as a generic form of IP address aliasing. Unfortunately, most people who come from a web hosting background expect CNAME records to indicate equivalence in the DNS, which has never been the intent. The apex contains record types which are clearly not used in the identification of a canonical host resource (NS, SOA), which cannot be aliased without breaking the standard at a fundamental level. (particularly in regards to zone cuts)

Unfortunately, the original DNS standard was written before the standards governing bodies realized that explicit verbiage was necessary to define consistent behavior (RFC 2119). It was necessary to create RFC 2181 to clarify several corner cases due to vague wording, and the updated verbiage makes it clearer that a CNAME cannot be used to achieve apex aliasing without breaking the standard.

6.1. Zone authority

The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone.

This establishes that SOA and NS records are mandatory, but it says nothing about A or other types appearing here. It may seem superfluous that I quote this then, but it will become more relevant in a moment.

RFC 1034 was somewhat vague about the problems that can arise when a CNAME exists alongside other record types. RFC 2181 removes the ambiguity and explicitly states the record types that are allowed to exist alongside them:

10.1. CNAME resource records

The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS. An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. That is, for any label in the DNS (any domain name) exactly one of the following is true:

• one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
• one or more records exist, none being CNAME records,
• the name exists, but has no associated RRs of any type,
• the name does not exist at all.

"alias name" in this context is referring to the left hand side of the CNAME record. The bulleted list makes it explicitly clear that a SOA, NS, and A records cannot be seen at a node where a CNAME also appears. When we combine this with section 6.1, it is impossible for a CNAME to exist at the apex as it would have to live alongside mandatory SOA and NS records.

(This seems to do the job, but if someone has a shorter path to proof please give a crack at it.)

Update:

It seems that the more recent confusion is coming from Cloudflare's recent decision to allow an illegal CNAME record to be defined at the apex of domains, for which they will synthesize A records. "RFC compliant" as described by the linked article refers to the fact that the records synthesized by Cloudflare will play nicely with DNS. This does not change the fact that it is a completely custom behavior.

In my opinion this is a disservice to the larger DNS community: it is not in fact a CNAME record, and it misleads people into believing that other software is deficient for not allowing it. (as my question demonstrates)

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.