For a SaaS we have been working on we wanted to use a Root Record CNAME . A CNAME Record to point to the main domain (apex record) where the application is loaded. At the main domain each incoming CNAME will be filtered and per domain name the projects data will then be loaded.
Advantage of Root Record CNAME
The reason we wanted a Root Record CNAME is that is will be easier to change the main domain ip address later on instead of changing the ip address for all the generated domain names. So when we move the app admin.app.com to xxx.xxx.xx we do not have to change jasperfr.com’s A record to reflect new ip address as the CNAME will point to admin.app.com.
Root Record CNAME Disallowed
Unfortunately we realized most Web hosters do not allow the cnaming of a root record or zone apex. Why no Root Record CNAME? Well according to a comment following here below they do not allow root record CNAMES because they will have at least NS Records and or other records and CNAME records are not allowed to go together with other DNS records:
No, you can’t do that –
CNAME records can only exist as single records and not combined with any other resource record (DNSSEC records excepted).
There are explicit
NS records always present at the top of each domain, so that prevents the use of the
CNAME at the same part of the hierarchy.
CNAMES can basically only be used to redirect subdomains to the main domain or other root domains. So www.jasperfr.com can go to cnn.com with a CNAME. However jasperfr.com cannot go to it..
Allow me to quote Andrew B in this SO thread:
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 (
SOA), which cannot be aliased without breaking the standard at a fundamental level. (particularly in regards to zone cuts)
DNS Hosters Exceptions
There are some DNS hosts that do do it though. They created custom records that allow aliasing a domain using another domain, not just a subdomain:
Some DNS hosts provide a way to get CNAME-like functionality at the zone apex (the root domain level, for the naked domain name) using a custom record type. Such records include, for example:
- ALIAS at DNSimple
- ANAME at DNS Made Easy
- ANAME at easyDNS
- CNAME at CloudFlare
- Amazon Route 53 Alias – See ELB Document
For each provider, the setup is similar: point the ALIAS or ANAME entry for your apex domain to example.domain.com, just as you would with a CNAME record. Depending on the DNS provider, an empty or @ Name value identifies the zone apex.
ALIAS or ANAME or @ example.domain.com.
If your DNS provider does not support such a record-type, and you are unable to switch to one that does, you will need to use subdomain redirection, which is not that hard, depending on the protocol or server software that needs to do it.
Reality and Alternative
Unfortunately there are few of them and most hosters with standard BIND DNS server setups disallow this. So most of us will have to content with an A Records and work with a load balancer. This so you can stick to one ip address AND work with multiple application servers for your SaaS stack.