What the author refers to as a "naked domain" is more generally termed the zone apex.
A CNAME does not co-exist with other records (save for RRSIGs if the zone is signed). Quoting RFC 1034:
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.
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.
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.
A CNAME does not co-exist with other records (save for RRSIGs if the zone is signed). Quoting RFC 1034:
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.
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.
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.