67

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

Agvorth
  • 2,429
  • 4
  • 28
  • 29
  • 28
    I run [www.yes-www.org](http://www.yes-www.org/) and I approve this question. – Michael Hampton Jul 16 '12 at 06: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](http://sstatic.net)) to avoid the hideous www subdomain. – Tom Marthenal Jul 16 '12 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? – Augustin Riedinger Feb 27 '14 at 11:08
  • This question is 6 years old, and mainly about limitations in software. Any updates? – Michael Cole Feb 16 '18 at 00:55

2 Answers2

58

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.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 1
    What about `ALIAS` (or `ANAME`) records? – Augustin Riedinger Feb 27 '14 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. – Shane Madden Feb 27 '14 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? – Augustin Riedinger Feb 27 '14 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. – Shane Madden Feb 28 '14 at 02:44
13

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.

mgorven
  • 30,036
  • 7
  • 76
  • 121