CNAME at the apex of a zone
  • 19 Apr 2022
  • 8 Minutes to read
  • Contributors
  • Dark
  • PDF

CNAME at the apex of a zone

  • Dark
  • PDF

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

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.

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: and this draft is no longer supported and has been superseded by an alternative proposal:

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

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

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

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