What the author refers to as a "naked domain" is more generally termed the zone apex.<p>A CNAME does not co-exist with other records (save for RRSIGs if the zone is signed). Quoting RFC 1034:<p><i>If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.</i><p>The rational for CNAME was originally to provide a temporary pointer to a new name. It's in vogue to use it as the author has done as a kludge for find-my-A/AAAA-record-here, and it is mostly a fit for trivial use cases, but it is only a partial solution.<p>Some argue that a standardized ANAME/ALIAS record is needed to suit the needs of the modern DNS. I agree but I also think it's time to consider how we might better allow SaaS providers to maintain records on behalf of users more directly. Doing so would take the burden off of users like the author to understand and correctly maintain DNS records, and allow SaaS providers more nimble and fine-grained control of the customer records for rebalancing load and the like.
Sorry, but redirecting the naked domain seems like the wrong way. The correct way is getting both the naked and www domain set up on the serving host. Then either CNAME or A record the www to the naked... And if needed let the naked domain redirect to the wwww itself.<p>Three simple steps, and should be universally implementable....
Interesting findings! I've had trouble with DNS providers and it is always with the root or "@" domain. As a Bind administrator it drives me mad how they make things complex unnecessarily to save me from myself, often resulting in failed switch-overs, and a 2x wait on DNS updates.
This is a nice unexpected benefit of using Cloudflare to manage our DNS: they automatically flatten your apex/naked domain as well as the www subdomain (if you set them up using CNAMEs in their DNS manager).