CNAME at the apex of a zone

It is often asked, "why can't I have a CNAME at the zone apex?"

This article explains why you can't do that, and then continues with a discussion of potential alternatives.

The use case for wanting a CNAME at a zone apex is typically one where an organization would like to have their web content hosted and provisioned by a specialist third party. Some third parties, rather than giving you an IP address for the hosting provisioning (in which case, they would most likely be using anycast behind the scenes) will instead give you a new target name to which they ask you to alias your webserver name in your DNS zone.

mydomainname.org.	3600	IN	SOA	dns1.mydomainname.org.	hostmaster.mydomainname.org.	2018073001	7200	3600	24796800	3600
mydomainname.org.	3600	IN	NS	dns1.mydomainname.org.
mydomainname.org.	3600	IN	NS	dns2.mydomainname.org.
mydomainname.org.	3600	IN	MX	10 mail.mydomainname.org.

The DNS record type CNAME (Canonical Name) is used for rewriting one name in a zone to another different name (which could be in the same zone, or somewhere else). It's described in RFC 1034 thus:

The domain system provides such a feature using the canonical name (CNAME) RR.  A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

For example:

www.mydomainname.org.	3600	IN	CNAME	www.mydomainname.hostingcompany.com.

If a recursive resolver receives a client query for www.mydomainname.org/A, it will look up www.mydomainname.org, receive the CNAME response, understand that it now has to look up www.mydomainname.hostingcompany.com too, then return the answers (CNAME plus A record) to the client.

The resolver adds both answers (for www.mydomainname.org and for www.mydomainname.hostingcompany.com) to its cache in case another client comes to ask the same question.

Many people mistakenly believe that the semantics of a CNAME are that the target domain in the RDATA is an alias for the left-hand side (the owner name). In fact this is looking at it the wrong way round. A CNAME says that the owner name is an alias for the target. The original concept was to permit the addition of ' also known as' names to a zone in DNS, which would then be redirected to the 'official' (or 'canonical') name.

Operationally a CNAME record has the effect of rewriting all other DNS records for that owner name (on the left-hand side) - for all record types - to the target canonical name (the RDATA on the right-hand side).

ISC BIND will therefore not allow you to add a CNAME at the zone apex because this would create a broken zone and cause DNS resolution failures. The interpretation of the CNAME record (per the DNS protocol) makes it nonsensical to have a CNAME coexisting with any other records with that same name.

Nevertheless, it has always been functionally OK to use CNAME for redirection to a web hosting provider where the website is addressed as www.mydomainname.org, but CNAME cannot be used where the website is addressed simply as mydomainname.org because the zone's NS and SOA (and MX if being used) also need to exist at that same name.

Having now understood why it is not possible to add a CNAME at the zone apex to 'make this work', what other alternatives are there? Some suggestions follow:

1. Webserver redirection - set up a webserver for mydomainname.org that provides a web redirect to www.mydomainname.org
   Pros: This is a very simple solution, and one which leaves the final provisioning in the hands of the web hosting provider.
   Cons: This solution requires that a webserver be running for the sole purpose of providing redirection; it will also visibly rewrite the website name in the URL of the client web browser, pre-pending the 'www'.
2. Add A and AAAA records to your zone that are the addresses that the target of the CNAME suggested by the web hosting provider will ultimately resolve to.
   Pros: This is a fairly simple workaround to implement.
   Cons: If the provider's hosting solution is dynamic, then those addresses may change, possibly quite frequently.  You will have to monitor and regularly update those records (although this is something that could be scripted).
3. For a simple zone that provides nothing to visitors other than the website, consider asking your parent zone's administrators to add the CNAME for your names to their zone directly instead of delegating it to you to manage.
   Pros: This is a very simple workaround to implement.
   Cons: This will not work for an organization who has many more names in their DNS zone.  It will also not work if the parent zone's administrators don't accept non-delegated records (in other words, hosting your zone records directly instead of delegating them to you).  You also can't implement this as a solution if the domain will be used for email (CNAME cannot coexist with MX).
4. ALIAS or ANAME (non-standard DNS feature). Some DNS hosting providers and DNS server software providers offer 'special' record types such as ALIAS or ANAME for a hosted zone. These records are never returned directly to clients. Instead, when a client queries for a name where an ALIAS or ANAME record would be applicable, the authoritative server will follow the redirection and synthesise the A or AAAA record for the client before responding.
   Pros: This is a simple solution to the problem for administrators.
   Cons: This solution is only available if your DNS hosting provider or DNS server software supports it.  In addition, the need to perform DNS recursion (prior to synthesizing the query response for the client) increases the query response time, as well as adding the potential for authoritative server problems to be introduced if the unavoidable recursive resolution encounters delays or problems.  Authoritative DNS servers, particularly those that are public-facing, do not normally perform any recursive functions. To mitigate the risks of potential delays and problems encountered during recursion, some DNS hosting providers only permit ALIAS/ANAME records where the redirection target name is also hosted by themselves: see the info block about ANAME later.
5. Use the services of a web-hosting provider that allows you to configure IP addresses directly rather than using name redirection.
   Pros: This is a very simple solution that scales well if your web hosting provider is using anycast provisioning.
   Cons: If your chosen web hosting provider does not offer this option, then it will not be available to you without changing to another web hosting provider.
6. Another potential solution currently being discussed would add a new DNS resource record type that browsers would look up, one that could exist at the zone apex. This would be a new application-specific record type for (similar to the way MX works).
   Pros: This would be completely consistent with the DNS protocol going forward.
   Cons: This is not available yet, and would require a browser client update before it can be used. During the transition to a new solution, you would still have to provide other alternative forms of redirection for older resolvers and web browser clients that don't know about the new DNS records.

Note: Another failing of any solution whereby an authoritative server synthesizes (or actively monitors and maintains locally, the resolution of the 'alias' server address - options 2 and 4), is that that any location-dependent A/AAAA records will be provided to the requesting client based on the authoritative server's location, not the end-user's recursive server (resolver) location. It would also be unlikely to handle EDNS Client Subnet (ECS) options as expected either.