CNAME at Apex/Root of your domain?

This blog provides all possible solutions available as of today for this universal and frustrating problem faced by almost every domain/website owner. 

This is probably the most well know limitation of the DNS system - You cannot create a CNAME at the apex or root of your domain as per RFC 1034. The reason is that CNAMES cannot exist with other records with the same name. Since at a minimum we have the SOA and NS records at the root of the domain already we cannot create a CNAME.

Yet this is a very commonly sought functionality since you may be hosting your site at a managed hosting/service provider who provide an A record and instruct you to point your domain at the A record. Behind the A record there may be 1 or more dynamic IPs and hence it is not possible to simply create A records in your domain to point to those IPs. You need to create CNAME records pointing to that A record. Creating a CNAME record for www pointing to that A record is easy however creating the CNAME at the root or apex is just not possible.

So here are the possible solutions for this problem:

1. Find a DNS hosted zone service provider which has a solution for this problem:

    i) AWS Route53: They provide a special ALIAS record which just acts like a CNAME record. The limitation is that the A record must belong to an AWS service like ALB, Cloudfront, S3. It cannot be from a 3rd party provider.

   ii) Cloudfare: They call is CNAME flattening. There is no limitation like AWS Route53. You can point the CNAME to any A record.

  iii) Other providers like DNSMadeEasy and EasyDNS call it ANAME record. They let you point your root/apex record to any A record.

In the below example I have created an ALIAS record for the root of ultimatenetworkwarrior.com and pointed to the A record I got after creating an AWS Application Load Balancer (ALB) resource. The A record points to some dynamic IPs - I don't need to worry about the changing IPs, the ALIAS record is just going to act like a CNAME record and resolve to the A record and the A record will resolve to the current IPs of the Load Balancer - the ALB service automatically updates the service managed A record with the new IPs whenever the IPs change.

2. Setup an HTTP redirect: In this solution we need to create an A record at the root/apex of the domain and point it to the IP address of a web server which can return an HTTP 301 redirect. Multiple A records should be created ideally to different web servers IPs for redundancy. The web server(s) should be configured to return the redirect to lets say the www version of the domain and the CNAME created for the www record in your domain would eventually take you to the providers A record. This solution has the overhead of managing, maintaining and securing multiple web servers.

Some DNS providers like Godaddy/NameCheap etc. provide a managed redirect service where you don't have to manage your own web servers. They manage and maintain those servers. In this below example I am at my Godaddy console setting up a permanent 301 HTTP redirect to https://www.x7networks.com. (They call this feature Forwarding). Now whenever someone types http://x7networks.com in the browser the Godaddy web servers will send a 301 redirect to https://www.x7networks.com to the browser. The CNAME record for www inside my zone file will then point me to the 3rd party providers A record.

This is how the redirect looks in the browser. When I created that Forwarding setup in Godaddy they created A records at the root of the domain pointing to their managed web servers (one of them is showing in the below output: 15.197.225.128). That server returned a 301 redirect to https://www.x7networks.com thus solving our problem.

3. Use HTTPS/SVCB DNS records: This solution is not fully ready as of today but it is supposed to become like a standard solution for this problem in the future. Here is how it works:

You can create an SVCB record to deliver configuration information for accessing service endpoints. The SVCB is a generic DNS record and can be used to negotiate parameters for a variety of application protocols. An HTTPs record is a type of SVCB record that provides extended configuration information, enabling a client to easily and securely connect to an HTTPS endpoint. This allows a client to make a connection with the server with those specific parameters in 1 shot rather than multiple initial negotiations.

Below is an example of a simple HTTPS record which contains the target - like a CNAME value 

Modern browsers and resolvers have started supporting this DNS record type. A modern browser will make a query for HTTPS record and also A record for the domain you enter in the browser for example lets say ultimatenetworkwarrior.com.

The catch here is that the browser also makes the A record query as well like they have always done in the past. Even if the HTTPS query is successful and the browser receives the endpoint A record and IP from the resolver it still also needs to see the IP in the response to the A record query and since we cannot create CNAME at the root we have to use one of the above 2 solutions. Once browsers start solely depending on the response to the HTTPS record query this can become an elegant solution to this problem in the future.

So in summary the only solutions available as of today are ALIAS/ANAME/CNAME Flattening or some form of HTTP redirects.