We are hosting many web applications for our customers. As is obvious they want to use their own domains to refer to those applications, usually they want that any user that either type http://www.customer1.example
or http://customer1.example
goes to their web application.
The situation we are facing is that we need to have the flexibility to change IP addresses in the near future. And we don't want to rely on the customer doing the A record change on their domains. So we thought that using CNAME
records will work, but as we find out CNAME
records will not work for the root domain.
Basically:
customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work
We want to be able to change the IP address of customer1.mycompanydomain.example
or the A
record and our customers will follow this record which we have control over.
in our DNS it will look like:
customer1.mycompanydomain.example IN A 192.0.2.1
Any ideas?
Best Answer
The reason this question still often arises is because, as you mentioned, somewhere somehow someone presumed as important wrote that the RFC states domain names without subdomain in front of them are not valid. If you read the RFC carefully, however, you'll find that this is not exactly what it says. In fact, RFC 1912 states:
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:
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.
I strongly disagree with the statement that it's done only by "amateur admins" or such ideas. It's a simple "What does the name and its service need to do?" deal, and then to adapt your DNS config to serve those wishes; If your main services are web and e-mail, I don' t see any VALID reason why dropping the CNAMEs for-good would be problematic. After all, who would prefer @subdomain.domain.org over @domain.org ? Who needs "www" if you're already set with the protocol itself? It's illogical to assume that use of a root-domainname would be invalid.