I ran across this page in the Heroku docs...

Naked domains, also called bare or apex domains, are configured in DNS via A-records and have serious availability implications when used in highly available environments such as massive on-premise datacenters, cloud infrastructure services, and platforms like Heroku.

For maximum scalability and resiliency applications should avoid naked domains and instead rely solely on subdomain-based hostnames.

Does anyone here speak Enterprise? What are the "availability implications" they're warning about?

(I notice that http://stackoverflow.com works no problem, so evidently there are viable alternate philosophies on this issue.)

  • 28
    I run www.yes-www.org and I approve this question. Commented Jul 16, 2012 at 6:14
  • 3
    There is another concern, too: static assets can't be served without attached cookies (you can't add cookies JUST for the root domain; cookies must be for a subdomain or for .domain.com (wildcard, used if root domain)). You can work around this by serving assets from a different domain (SE uses sstatic.net) to avoid the hideous www subdomain. Commented Jul 16, 2012 at 12:17
  • 2
    @MichaelHampton why can't we leave comments on www.yes-www.org? Why don't you mention ALIAS (or ANAME records) in your page? Commented Feb 27, 2014 at 11:08
  • This question is 6 years old, and mainly about limitations in software. Any updates? Commented Feb 16, 2018 at 0:55

2 Answers 2


What they're talking about is that when you use a CNAME to point to their services (which is only possible on subdomain, not the zone root - it can't coexist with the SOA and NS records that are required on the root of your zone), they can make a change to their own DNS records to work around some kind of availability issue.

With a zone root, you must use an A record to point to a specific IP address for the service. If they have an issue with routing, or some kind of denial of service against that specific address, they're not able to update your zone's A record to point to a different IP on the fly; they can update their own, though, and that's what a CNAME allows them to do.

This doesn't apply to Stack Exchange because they aren't using a third party's platform; they'll be the ones responding to an availability issue, so whether it's a CNAME or an A makes no difference to them.

  • 1
    What about ALIAS (or ANAME) records? Commented Feb 27, 2014 at 11:08
  • 1
    @AugustinRiedinger Those aren't actually a DNS record type - they're a configuration where certain DNS providers will handle the abstraction of dynamically checking the current A record of the target, then serving it back in response to a query for that name. They're essentially designed to solve this exact problem, so they're definitely appropriate to use for this case. Commented Feb 27, 2014 at 17:31
  • 1
    So if we use them, the scalability warning from heroku doesn't remain true anymore, right? Or is there any technical drawback into using them? Commented Feb 27, 2014 at 20:19
  • 2
    @AugustinRiedinger Correct. The technical drawback is in the implementation difficulty, as a "standard" DNS server cannot accomplish that kind of thing without customization. As long as your provider's implementation is stable, it should be just as good as a CNAME setup on a subdomain. Commented Feb 28, 2014 at 2:44

As an addition to @ShaneMadden's answer, one workaround is for the third-party platform to also manage your DNS zone. For example, if you use AWS's Elastic Load Balancer service, and their Route 53 DNS service, you can reliably point the zone apex at an ELB instance using their custom alias records, which allows them to update your DNS zone in response to availability issues.

This is however an argument against the no-www concept, since www.example.com can have a CNAME record.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .