CNAME at the apex of a zone
- Updated on 17 Sep 2018
- 9 minutes to read
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.
www.mydomainname.org. 3600 IN CNAME www.mydomainname.hostingcompany.com
If a recursive resolver receives a client query for www.mydomainname.org, it will look up www.mydomainname.org, receive the CNAME response, understand that it now has to look up www.mydomainname.hostingcompany.com too, and return the answer to that query to the client.
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 this 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 will 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 for 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.
In more recent times, along with an increase in web server provisioning, it has also become popular for organizations to expect to have their website accessible simply by their apex DNS domain name - without the 'www' prefix.
We cannot change how the special CNAME record is used without changing all of the DNS server implementations in the world at the same time. This is because its meaning and interpretation was strictly defined in the DNS protocol; all current DNS client and server implementations adhere to this specification. Attempting to 'relax' how CNAME is used in authoritative servers without simultaneously changing all DNS resolvers currently in operation will cause name resolution to break (and web and email services to become intermittently unavailable for those organizations implementing 'relaxed' authoritative server solutions.)
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:
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'.
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).
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).
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.
There has been extensive discussion about this draft and about other ways to resolve web hosting DNS redirection for the apex on the IETF DNSOP WG mailing list:
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.
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 handleEDNS Client Subnet (ECS) options as expected either.
It is not a good solution because resolvers (following the DNS protocol correctly) cache what they have learned.
If a client's local DNS resolver does not have anything in cache yet and the client queries for www.mydomainname.org MX, the 'engineered' server will provide the expected MX record to the resolver (which will then cache it and return it to the client. So far so good - this time DNS resolution was successful.)
But, if earlier, another client had asked for www.mydomainname.org A, the 'engineered' server would have then provided the CNAME record. If this was still in cache, then instead of looking up the MX record for the client at www.mydomainname.org, the resolver will instead follow the cached CNAME redirection and try to look up www.mydomainname.hostingcompany.com MX.
This is most likely to fail and will result in intermittent problems for mail delivery. Other services that are dependent on reliable DNS resolution will also experience intermittent failures.