How to handle CNAME flattening problem for APEX Domains
You might have heard many DNS providers don’t support CNAME flattening for root (APEX) domains. Now, there are many questions:
- What’s the problem? It’s good.
- What’s the CNAME flattening?
- Do we (really?) care about that?
- How would I handle the scenario?
First, it’s not a problem until you don’t explicitly require it. Do you know that all communication is made with IP addresses on the internet? The internet doesn’t know anything except for an IP address. The domain names are all about your phone book; if you call to My Mother
from your phone, it will call a phone number; the telephone provider doesn’t know about your My Mother
. So, similar to that, when you surf a website like www.google.com
, the internet doesn’t know who is www.google.com
. Your browser will connect an IP with meta info with www.google.com
. Hey, I don’t want to extend this topic here; if you need to, please ping me, and I will create a separate blog for it.
So, every domain should have at least one IP address. Yes, you read correctly: at least one, and it can have more than one as a fallback option. Now, the question is, where will your browser get the IP address for the domain you are surfing? Have you saved it somewhere, like your phonebook? No, your computer is smart enough to get the IP address for this domain. Sorry, the internet design is smart enough to handle it. The DNS Server handles it.
The next question is, from where does the DNS server get the IP record for your intended domain? It’s a long, long story. This post is not the right place to elaborate. In short, the domain owner sets the IP address through a DNS provider, and it’s propagated all over the internet network. Your DNS server also responds with the correct IP address.
Now, suppose you own a domain and want to set the IP address for it so that you can define from which IP address ( read here the hosting server) your request will be provided. For a typical hosting provider, the IP address is fine and as intended. Your domain needs to point to an IP address, you already assigned an IP address, that’s it, very good.
Now, coming to a large application which is connected with many services, your customer base is worldwide, you want minimum distance from your end-user to your server so that your web content can be transferred instantly, data usage and latency will be reduced, etc., etc., etc., you will choose the cloud platform, correct? Now, your server cannot reside in one region or place; it will be distributed worldwide. How can you set a single IP address for all of your servers? Not possible, correct? ( NOTHING IS IMPOSSIBLE; but it’s not so easy, and not easy from the financial side as well; I am going with the simplest solution ). From here, we need the CNAME record. When you set the IP address, it’s an A
record. The CNAME
record is the middleware. Your domain can have a CNAME record, and based on your location, or server load, or availability, your DNS server can of this CNAME record can answer different IP addresses (a A
record ), ultimately what your end-user’s browser needs to connect your domain.
The DNS servers allow CNAME records for all of your subdomains but not for the root domain, which is similar to the APEX domain. Why? Many reasons. Please ignore this, but your DNS provider can restrict the assigning of a CNAME for your root/APEX domain.
We faced a similar situation. In Azure Front Door (AFD), they provide a CANME record to point to your domain/subdomain. One of our clients’ DNS providers doesn’t allow adding a CNAME record for the APEX domain. (It’s also called CNAME flattening on the APEX domain.)
Then, we created a tiny Virtual Machine (VM) in the Azure platform, which was responsible for redirecting traffic from the root/APEX domain to the www.
subdomain. The www.
subdomain is allowed to assign a CNAME record to our AFD.
Now, why a virtual machine? Not an Azure Function or Service or a serverless process?
The serverless functions need an SSL certificate, which your client needs to buy unnecessarily. We can use the Let’s Encrypt SSL certificate for this redirection purpose. We created a virtual machine to receive the request for the root/apex domains and redirected the traffic to www.
subdomain, then our Azure Front Door was smart enough to handle the request. We have implemented the auto renewal of the SSL certificate for all our client’s domains, for which required. That’s it.
Do you need the process for the VM creation in Azure or need the process to create a redirection service with HTTP and HTTPS protocol? I will create a separate post.