Hey friend!

I don’t think there is any benefit for you as a DigitalOcean customer. I’ll explain. The meat of it seems to be here:

When using a provider such as Heroku or Akamai to host your web site, the provider wants to be able to update DNS records in case it needs to redirect traffic from a failing server to a healthy server. This is set up using DNS CNAME records, and the naked domain cannot have a CNAME record.

The reason they’re saying this is because Heroku and Akamai provide a managed service in which they may very well have to change the IP of a server or route traffic to a different IP. You are pointing your service to a domain name of theirs, and if you pulled the IP of that domain name and used it instead of a CNAME, your application would break if they changed the IP of that domain name. At DigitalOcean, however, you manage your DNS and IP address. If you need to change IP addresses, this is going to be part of your process rather than ours. At that stage, the only difference using this methodology becomes which DNS A record you end up having to change, not whether or not you have to change one or how much downtime it causes (alias lookups are cached the same).

It would therefore be my opinion that you should then follow the traditional standard of WWW being a CNAME to the root domain, and simply ensure that the website either returns fine with WWW or that it redirects traffic to WWW to the root domain. You could reverse that all the same, if you preferred the reverse. Personally I stopped using WWW everywhere when I started in the industry and someone told me something that was so painfully obvious I had never even taken the moment to make the mental connection: That WWW is a subdomain. It’s three extra letters to no particular end.

Jarland

Thanks for the quick reply @jarland!

My concern is a little more about what I was reading on the yes-www.org site…

Another reason has to do with cookies. One common web site optimization is to serve static content from a subdomain, such as static.example.com. If you are using www, then this is no problem; your site’s cookies won’t be sent to the static subdomain (unless you explicitly set them up to do so). If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly.

I use Discourse as a community, which is a subdomain - community.domain_name.com

I would rather keep my site as domainname.com instead of switching it to www, but I’m concerned that because my naked domain is an LMS in wordpress and has tons of cookies, etc. I’m worried that when folks go to my community which is community.domainname.com that b/c it is a subdomain, all of the cookies from the main site will go with the user and it may slow down or degrade the performance of their Discourse community experience.

Is this correct? Any feedback on that quote above?

Thanks again @jarland !

Currently, I have an A Record for a subdomain “www.mysite.com” that redirects to my naked domain, and I have an A Record for my naked domain “mysite.com”.

So if I wanted to make the switch from using my naked domain to a www subdomain what would the proper steps be, in DO, and in Wordpress? Is this on track or what am I missing?

1. Do I need to change anything in my Domains/DNS settings in my DO account? https://cloud.digitalocean.com/networking/domains/
2. Do I just visit this page in WP: https://mysite.com/wp-admin/options-general.php and change my “Wordpress Address (URL)” and the “Site Address (URL)” from my current naked domain (https://mysite.com) to the www version ➞ https://www.mysite.com

Anything else?