Knowledge Base ISC Main Website Ask a Question/Contact ISC
CNAME at the apex of a zone
Author: Cathy Almond Reference Number: AA-01640 Views: 1471 Created: 2018-08-01 20:41 Last Updated: 2018-08-07 11:02 0 Rating/ Voters

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.

What is the zone apex?

The zone apex is where the SOA and NS (and often MX) records for a DNS zone are placed.  They are DNS records whose name are the same as the zone itself.  For example in in zone you might have:    3600    IN    SOA 2018073001 7200 3600 24796800 3600    3600    IN    NS    3600    IN    NS    3600    IN    MX    10

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:    3600    IN    CNAME

If a recursive resolver receives a client query for, it will look up, receive the CNAME response, understand that it now has to look up too, and return the answer to that query to the client.

The resolver then adds both answers (for and for 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 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, but CNAME cannot be used where the website is addressed simply as because the zone's NS and SOA (and MX if being used) also need to exist at that same name.

Why can't the rules about having a CNAME at the zone apex (or coexisting with other records) be relaxed and reinterpreted?

When "www" served as a "service identifier" prefix for the host that actually serves the content, using CNAME for redirection to a hosting provider was OK.   It worked as required, even though the semantics weren't really correct.  (Mail didn't need a prefix because it always had a special type (i.e. MX) that serves as the service identifier).

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:

  1. Webserver redirection - set up a webserver for that provides a web redirect to
    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. 
    For more information on the ANAME IETF Internet Draft, you can read:
    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:

  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 forwards.
    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.

WARNING: 'Clever' provisioning servers that respond with query-dependent CNAME or MX/NS/SOA records will cause broken DNS resolution

There are some 'engineered' solutions available where the servers authoritative for a zone have been made capable of responding with either a CNAME (when queried for A/AAAA and other record types) or the actual contents of the zone at the apex if queried for MX, NS or SOA records.  This is temptingly attractive as an operational workaround, but it has significant failings.

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 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 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, the resolver will instead follow the cached CNAME redirection and try to look up 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.

© 2001-2018 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

  • There is no feedback for this article
Quick Jump Menu