If you’re not familiar with CNAMES, they’re a type of record used in DNS. And they’re very useful when you’re building a SaaS.
Let’s take the following scenario:
- A customer purchases a new site and is assigned a temporary subdomain (e.g: tempdomain01.yourdomain.com)
- The customer then changes the domain to their real domain
To get the their real domain to point to the site, they need to update their DNS records.
But that means giving them the IP address for the server where the site resides. This presents a problem for two reasons:
- You’re usually hiding the IP for security reasons – usually behind a proxy such as CloudFlare.
- If you have to move the site around, then the customer will lose access until they update their DNS to the new IP
CNAMES allow for an alternative solution that resolves this issue.
When the customer changes their domain to their real domain (eg: realdomain.com), the original temporary domain remains in your DNS records and continues to point to the server where the site resides.
The customer will delete any “A” records for their domain and create a CNAME record instead. This CNAME record will point to the temporary domain (tempdomain1.yourdomain.com).
When a browser requests the customer domain, the request follows the path of the CNAME which points to tempdomain1.yourdomain.com. This ultimately resolves to the IP address of the server where realdomain.com is located. If you’re using CloudFlare, it will return a CLOUDFLARE address which keeps your real server IP hidden.
A common misconception on CNAMES is that the CNAME value will replace the original URL request. In other words, users might think that the server will attempt to load tempdomain1.yourdomain.com instead of realdomain.com. This is, of course, not correct – the CNAME value is only used to figure out an IP address – the browser will still send a request for realdomain.com.
When the browser sends the request to the IP address, the request ultimately ends up on your server (maybe proxied by something such as CloudFlare) where realdomain.com resides. Since the browser still sends the request for realdomain.com, that is the site that the server will render.
Simple & Effective!
If you need to move the site to a new server where the IP changes, all you have to do is change the IP for tempdomain01.yourdomain.com which you control. The customer does not have to update any DNS records.
You can learn more about CNAMES on the CloudFlare site.
Alternatives
There are some alternatives you can use – obviously with advantages and disadvantages.
One alternative is to setup a single DNS entry for each server. For example, you can setup DNS entries for server01.yourdomain.com and server02.yourdomain.com. You can give your customer these names for their CNAME record.
The advantage to doing this is that you can move all sites on a server to a new server and only have to update a single DNS record.
The disadvantage is that, if you have to move a single site to a new server, the customer will have to update their DNS CNAME record.
We prefer to use the temporary domain method so that we have fine-grained control of each domain. This is because, in our experience, moving all sites from one server to another is a rare event but moving individual sites occur much more often.
Caveats
Not all DNS providers support creating CNAME records at the apex (custdomain.com). In these instances you might have no choice but to ask the customer to move their name server records to a DNS service that supports this (eg: CloudFlare).
Was This Article Useful? Or do you have questions or comments about it (or our products & services)? We'd love to hear from you!
Automatic Notification Of New Articles
Sign up to get automatic notifications of new articles. This is a different list than our standard list - you only get new articles once a week (usually on Mondays). No other emails will be sent unless you sign up for our general list as well.
Follow us on Twitter! We post a lot of cool things there first. To keep up, click the "X" below!