CNAME discussions in this article are specific to their site. In general, you can load balance just as well with A or CNAME, apex or sub-domain. It's only when you get into artificial technical limitations set up by a hosting provider or CDN, that things get messy.

CNAME's guarentee the end users will always do at least 2 DNS lookups. Depending on their resolver config, this will mean they will likely hit 2 or more resolvers. This increases their chances of hitting a bad one and the DNS not resolving.

A records can be load balanced, have full fault tolerance and much more. The modern way to accomplish this is Anycast. Instead of relying on DNS for failover or load balancing, your IP is advertised in different parts of the internet and the traffic is sent to different datacenters, that each may have their own load balancers, caching devices, WAN accelerators, DDoS mitigation and more. In fact, nearly all major DNS providers are doing this today. While you may have 3 or 4 IP's in your zone, those IP's actually route to different places depending on the requestors location.

TL;DR: Summary, just use an A record for Apex or sub-domain, set a really high TTL so a DDoS of your DNS is less relevant and use Anycast to optimize your traffic routing, load balancing, latency to the end user and availability.

How accessible is anycast for most people? AFAIK, if you're ok with a third party seeing all your traffic, you can get behind Cloudflare's anycast or Google cloud load balancer (which does seem to offer TCP, so you don't have to let Google decrypt content); but I haven't seen this from many other providers.

It's not really something you can do yourself either, unless you have assigned IP space and BGP in multiple locations.

For non-commercial folks, there are a couple of VPS providers that provide Anycast support. I personally have not used them, so I can not speak to how easy they have made it to configure.

I agree with your concerns around letting a CDN see traffic. In my workplace, we are not allowed to pass dynamic traffic through CDN's for that very concern that our customers share with you.

[2016], and not really this weekend, just fyi.

The main thing that I dislike with the no-www trend is that it is hierarchically wrong:

. is ICANN root

.com is VeriSign

example.com is Example Company LLC

www.example.com, subdivision.example.com, www2.example.com are all services, subdelegations and individual hosts within example.com

I realize this is a rapidly declining way to view the DNS but it is nevertheless the way it was designed.

its not hierarchically wrong; services never required their own subdomain - example.com is just as valid a host as www.example.com

sure it is helpful for organization, but when was the last time you used ssh.example.com?

Don't get me wrong - it's in no way illegal to use A/AAAA-pointers in your zone root.

RFC 1034[0] however, argues for a tree-based structure and lays emphasis on the value of branching. It being 'wrong' might have been too strong a description, how about it being 'improper'?

When I've seen SSH access being offered as a network service and not as a means to administrate other services on a network it's often been under names such as 'shell.example.com' - not exactly your 'ssh' label but an approximation.

0. https://tools.ietf.org/html/rfc1034

Naturally, Example LLC will serve html on port 80, because that's Hypertext. And while that does not have to redirect to the www homepage, there is hardly any other reasonable alternative I could think of. Likewise, I think I read here, a bare tld domain could resolve, too, I just don't remember what it would or should resolve to.

Cloudflare, among others, has a feature called "CNAME flattening" that resolves the CNAME to an IP and serves it up as an A record. It makes this articles point a non-issue, and in fact probably results in a faster DNS lookup. The only drawback is that it is unclear how often they refresh the value.

Even without MX/TXT records, your apex will always have an SOA, which disqualifies it from using a CNAME(per RFC).

> Because of this we strongly recommend that you always host your main site or app on www or any other subdomain (app.example.com is perfectly fine as well).

There is real, measurable value to no-www. To anyone here who owns a public website, do visitors mainly go to the www or no-www version of your site? (assuming you don't redirect) Are the short or long versions of your URLs shared more?

I would be willing to bet there is a strong inverse correlation between link size and likelihood of being clicked. Anecdotally, on my own site of about ~1k daily active users, the no-www urls were used almost exclusively. Using www to avoid the rare disaster of DoS is unwise.

> There is real, measurable value to no-www.

Citation needed.

> I would be willing to bet there is a strong inverse correlation between link size and likelihood of being clicked.

4 extra characters (www.) is a pretty small fraction of the total link length most of the time, when people link to individual blog posts or what have you. I'd argue that readability of the link is far more important, and www does not harm that.

Citation isn't needed. If you read one sentence later in my comment you can see I asked readers to look at their logs to confirm my statement. The next sentence after is confirming with my own data that visitor of my site preferred the no-www.

The reason to not use www is in your logs.

Just because your users don't use www doesn't mean that there's any value there above if you had a www only site.

    > Anecdotally, on my own site of about ~1k daily
    > active users, the no-www urls were used almost
    > exclusively.

Not sure what this is supposed to prove. You should be redirecting one to the other, so it doesn't matter if people find it more convenient to manually type in one form over the other unless you're telling me you're trying to optimize out the redirect, which seems just as specialized as using www- for TFA's DDoS concerns.

I type in "google.com" every time and don't care that it redirects me to "www.google.co.uk" every time. I don't even notice.

"do visitors mainly go to the www or no-www version of your site?"

Visitors follow links - just checked netlify.com vs www.netlify.com and over the last 3 days around 0.5% of visits went to netlify.com instead of straight to www.netlify.com

It's generally far more important to setup your site to be as performant as possible and get the best uptime than to skip the the www - there are ways to get the best of both worlds however.

Are you sure that isn't because you are redirecting? Where does https://netlify.com/blog/2016/01/12/this-weekends-ddos-attac... point? Google is going to index and show the www version if you always redirect. You have interfered with the results so the 0.5% is biased.

If you don't need load balancing and redirects (i.e. like most people you don't have huge load requirements) just use A records instead of CNAME records.

CNAME-based hosting is really common (SaaS, GitHub Pages, ReadTheDocs, ...).

I'm also dealing with the cname problem. I considered their solution however if the server issuing the redirects from the apex to www happens to go down, people typing the apex domain will not be redirected. The only real solution seems to be to have all customers just use our DNS servers

If you always redirect to www, and always publish links with www, most of your inbound traffic will go to www; so it's not critical if occasionally the apex doesn't work. Some people will not load your page properly, but not too many.

If your site is already heavily linked to at the apex version (or you prefer the no-www hostname for a shorter url or esthetics), then it's likely to take forever for a switch -- in this case, your realistic option is to set the nameserver records for the whole domain to whomever you want to do DNS load balancing for the apex.

I have always used AWS Route53. I didn't even know that ALIAS records were not a standard thing.

What DDoS mitigation service were you using? This is why you need a provider like Incapsula, that protects at the origin server & C-name. Many providers only protect at the level of the A name, so you can get this kind of hit.