Should you use www or not in your domain? (2017)
bjornjohansen.no
bjornjohansen.no
" One of the reasons why you need www or some other subdomain has to do with a quirk of DNS and the CNAME record.
Suppose for the purposes of this example that you are running a big site and contract out hosting to a CDN (Content Distribution Network) such as Akamai. What you typically do is set up the DNS record for your site as a CNAME to some akamai.com address. This gives the CDN the opportunity to supply an IP address that is close to the browser (in geographic or network terms). If you used an A record on your site, then you would not be able to offer this flexibility.
The quirk of the DNS is that if you have a CNAME record for a host name, you cannot have any other records for that same host. However, your top level domain example.com usually must have an NS and SOA record. Therefore, you cannot also add a CNAME record for example.com.
The use of www.example.com gives you the opportunity to use a CNAME for www that points to your CDN, while leaving the required NS and SOA records on example.com. The example.com record will usually also have an A record to point to a host that will redirect to www.example.com using an HTTP redirect."
Source: had to navigate the shitty position of trying to CNAME to a CDN and have that CDN's DNS infra replicate our e.g. MX records.
[0] https://blog.cloudflare.com/introducing-cname-flattening-rfc...
[1] similar discussion, 2014: https://news.ycombinator.com/item?id=7293512
Fine if all you are doing is 302 to the www. Variant, but otherwise no.
With an extra caching key, this can even be cached.
Anycast addresses this issue, right?[1] Cloudflare uses Anycast for their IP addresses.[2]
[1] https://en.wikipedia.org/wiki/Anycast
[2] https://www.cloudflare.com/learning/cdn/glossary/anycast-net...
I discovered this when using a CNAME for a root-level domain and then wondering why I had spotty mail delivery. Turns out, quite a few mail systems and/or DNS resolvers handle this fine - but there are still quite a lot that don't.
- do I own the IP address(es), and BGP-route them to the machines in question?
- can I use any provider (who is willing to do the required configuration)? As a specific example, could I run anycast between two boxes purchased through Hetzner auction? (Translation: considering that I'm going fishing around in the auctions as opposed to other options, would I even be listened to? heh)
- who am I actually paying, and for what? (besides power, bandwidth, and possibly the server itself)
- ...how does anycast actually work _within the context of using it for hosting_? :/ https://en.wikipedia.org/wiki/Anycast is... distinctly not contextually-scoped to my intentions.
As far as cookies are concerned, keeping them on the origin ensures they get passed to all subdomains, which is usually a benefit, as opposed to a problem -- which you'll discover when you need to restrict API requests on a subdomain only to logged-in users, for example. And as long as you're keeping your cookie payload small, like a session ID or two, there's zero worry about a performance hit.
And as far as a CNAME needing to point to another domain instead of an IP, has that ever been an issue for anyone? Genuinely curious. I'd never even heard of that until now.
Honestly, simpler is better and "www." is an unnecessary vestige from another era. I dropped it from my sites starting a couple years ago. (Obviously with a redirect in case anyone ever types it.)
Disclaimer I work on App Engine.
Search in that same document for "naked domain".
> I'd like to map my app to a naked domain (such as http://example.com).
vs.
> App Engine does not currently provide a way to map static IP addresses to an application
the latter is that you own an IP and want to map it against your appengine.
the former is example.com -> appengine site.
(not related to google)
So you traded an intermittent problem (only relevant when an IP change occurs) for 24/7 guaranteed service outages for a (probably very) low percentage of your intended demographic.
Because I'm pretty sure we all know what I meant when I pointed out using Cloudflare means gaining a convenience at the expense of being at the mercy of third party outages.
"as far as a CNAME needing to point to another domain instead of an IP"
So, it's unclear to me who you're arguing with. I thought a post explaining why using a CNAME on an "apex domain" is potentially problematic might be helpful. Guess not.
Of course, this isn't something that has a concrete right and wrong answer. It's more a question of how much you trust your subdomains. Personally, I think sharing that information should be a conscious choice when setting the cookies and not something that you let happen by default.
I'm a bit scale focused though. If your site is never going to need a CDN, you can of course pick aesthetics over serviceability. But if this is something you hope to one day get big, you might as well make an easy decision to prepare for it at the start. You will want to support any inbound links you get for as long of forever as possible, so it's nice if they are to the right hostname to start with.
In some cases a single edge case can be the reason to make a decision.
If your attitude is “working in 99% of cases is good enough”, that means over a long enough period of use, 100% of your users will encounter an edge failure.
The way to even have a shot at 99% of your users a good experience is to constantly let edge cases force your hand.
https://www.alexa.com/topsites
Google: www
Youtube: www
Facebook: www
Baidu: www
Wikipedia: www
Would be interesting to go through the whole list and get a broader statistic.
Let's look at some of the newer/hipper sites on the list:
Reddit: www
Instagram: www
Netflix: www
Twitch: www
Spotify: www
edit: I guess both of mine have some plugin doing this?
$ curl -v https://google.com
[...]
< HTTP/2 301
< location: https://www.google.com/ $ curl -i https://google.com
HTTP/1.1 301 Moved Permanently
Location: https://www.google.com/
...
Chrome is moving towards the opposite though, hiding the www subdomain in the browser bar.
If I served my site through the apex domain, I'd redirect www to the apex — standard practice. With that in mind, if a browser kept forcing me to go to www when it hit the apex, and my site kept forcing the apex when it saw a hit to the www, you'd have an endless loop and the user would never be able to see the site.
YouTube: no major subdomains as far as I know. Facebook: aside from developer resources (which require you to log on with Facebook), none really.
Baidu: not familiar with it, so no idea.
Wikipedia: one for every language. Furthermore, the Wikipedia of each language seems to be completely separate, both in content and accounts.
Reddit: a lot. Aside from the obvious api.reddit.com, users may use <whatever>.reddit.com and the subreddit's CSS may use this info to change the looks of the subreddit.
Instagram: no idea, but I believe the main interface is simply on instagram.com.
Netflix: just netflix.com.
Twitch: as far as I know just the main domain, no subdomains.
Spotify: a few services, like open.spotify.com and play.spotify.com, but they all require you log on separately.
It's pretty mixed, with some websites having a lot of subdomains, but not all of them requiring or using shared cookies.
YouTube has:
- gaming
- tv
- music
- kids
- artists
Maybe more, but those are the ones linked on YouTube proper.
Your list in years old:
Netflix 21; Google 20; Baidu 18; Wikipedia 17; Facebook 14; Reddit: 13; YouTube 13; Spotify 12.
Only Twitch and Instagram are less than a decade old (barely).
Netflix isn't new or hip, they have all-gray hair and are at heightened risk of breaking a hip in Web age terms.
Some popular sites without www:
Twitter, DuckDuckGo, Stripe, Imgur, TechCrunch, Bandcamp, Medium, Stackoverflow, Square, Github, OfferUp, Poshmark, Giphy, Lifehacker, Gfycat, 22 Words, Go.com, Discord, 24/7 Sports, Nextdoor, Mental Floss, Vimeo, thechive, Comicbook.com, Patch, Mega.nz, Food52, HBO Go, Phys.org, Gizmodo, Pitchfork, Padlet, Definition.org, Shmoop
This is just further shows how it's a weird cultural issue for some people.
A lot.
If your site is 15 or 20 years old, you're from an era where consumers universally expected www to preface a domain. 20 years ago consumer ignorance was extremely high as it pertained to how the Web worked and how addresses worked, any variations from what was normal would be a poor choice. It was also technically more annoying 20 years ago to try to get by without www, companies like Cloudflare have helped make that far more trivial as an issue. Once you've become very successful such that tens or hundreds of millions of people are using your service and you've firmly established your address (eg as www.facebook.com), the downside risk is greater than the upside potential to bother switching from www to non-www at that point. If you're Facebook and you've acquired a sweet 2 billion person social monopoly, there's zero potential value in messing with switching from www.fb.com to fb.com.
Further, if you've built up an elaborate service over many years using www and attaching cookies and subdomains to countless services, there can be a plethora of super annoying problems (and or very serious security risks) to deal with in switching to non-www for your core. So once again, for someone like Facebook or Google, the value proposition to switching a gigantic service over, is more of a nightmare. If you're just starting out with none of that legacy, such things are not a problem, you build from the ground up for non-www.
If you're Twitter, Imgur, Github or Stripe and you want the identity benefit of having no www in the front - it produces a better url for advertising, a shorter url for function (valuable historically for eg Twitter and Imgur), and stronger visual branding (less cruft around your name) - then you avoid www from the early days.
Gitlab goes one better and redirects the root domain to about.gitlab.com.
How about Bird scooters, founded 2017? Yup, redirects to www.
Lets look at some recent Ycombinator grads [1]. It's about half and half whether they redirect to www.
[1] https://techcrunch.com/2018/08/22/the-top-10-startups-from-y...
Whatever factor you think age plays in the www subdomain decision, it doesn't seem to be reflected by real companies.
I still think the best argument for keeping www is from Heroku:
"Root domains are aesthetically pleasing, but the nature of DNS prevents them from being a robust solution for web apps. Root domains don't allow CNAMEs, which requires hardcoding IP addresses, which in turn prevents flexibility on updates to IPs which may need to change over time to handle new load or divert denial-of-service attacks.""
See: https://web.archive.org/web/20110628072339/http://status.her...
Like most things in technology, if Amazon, Facebook and Google are all doing it, it's probably for good reason...
"www" is all about conforming to expectations
That statement couldn't be more wrong. It's absolutely possible to programmatically update DNS records. Set the TTL low (which you would be anyway for the CNAME records) and change them as you see fit.
- Cookies are passed down to subdomains / unnecessary cookies hurt performance / cookies may be read by third parties
- DNS origin can’t be a CNAME (must be an A-type record, that points to a static IP address)
He is using the non-www like everyone else, of course. We always list out the practical reasons that www is better, just before we choose non-www.
Now, if your website is hosted at the origin (“example.com”), you can’t do that. But there is no issue with the “www” hostname being a CNAME record. So if you want any scaling flexibility, now or in the future, you should go with the www hostname from the beginning.
Granted, his blog was knocked offline by HN. But would a CNAME have saved their Wordpress site?
FWIW, https://ycombinator.com/ redirects to https://www.ycommbiator.com, as does Reddit.
In the past I've heard of non-technical users adding ".com" to the end of one of these gTLDs, which obviously takes them to a completely different website. I wonder whether anybody has used this as a form of pseudo-typosquatting or phishing?
Sorry but such a blanket statement is naive and arrogant—you've got to look at individual use cases before making a call on this.
When putting your domain in print, you should omit the www if you can. Just catch the root domain request and redirect to www if you want it.
For SEO purposes, if traffic is just clicking from one site to another, like from a search engine, the url doesn’t matter. But it does pay to be consistent, though. The main issue can be duplicate content isssues, so you should choose one version. Same goes for all 4 versions, though, if you add http vs https into the mix. Choose one.
I can see www not being needed to tell the non-techies that a not-com is a domain name or web address as they get more used to not-coms. I senior taking another 5 years until we get there.
All their public services default to subdomains, including www.
Although technically Google Search should probably load at search.google.com if it were going to be consistent with the URL convention of all their other services.
My point is web developers will do whatever they want. Technically you should use www for your website. But if your domain is known for being a website the www is implied and you could make an argument for leaving it out. But no one cares. This isn't linux where you can force users to follow obscure rules to get your software to work. You simply just won't get that traffic. And that, is justice!
So we all know the answer already. Redirect https:// to https://www or vice versa depending upon on your inclination.
When dozens of 3,000 lb death boxes are travelling at high speeds in close proximity to each other, and in close proximity to slow moving, talking creatures made out of meat, it's best to communicate as clearly and possible.
Am I missing something or is OP using a non-www domain? I'm using Chrome fyi (mentioned because I know safari messes with the address bar)
Guess he is Stallmam-serious about practicing what he preaches.
Also this is a stupid clickbait non-issue.
That said, I agree. The author does jump to conclusions, but that's pretty much why I posted it. It's was first search result and I decided an HN debate would help me find a better answer.
And Safari defaults to not even showing 90% of the URL, from what I can find.
Of course you can get a similar effect by using the "X-Frame-Options" header but if you are doing something like allowing user-defined content it is best to have layers and do different subdomains AND X-Frame-Options.
Basically if you have an application that allows users to host Javascript, either use a completely different domain or make sure your root domain doesn't host any meaningful content or have cookies that are used for security or privacy.
However, Cloudflare already offers something called CNAME flattening for apex domains and there's already an AAAA record type that works like a CNAME but without all the problems they cause.
Granted, not all DNS providers support this, but if they do, is there else anything wrong with using the apex domain? Isn't the cookie problem a solved problem?
My vote is for just letting CNAMEs work at the root, apparently a lot of DNS software already lets you get away with it: https://mailarchive.ietf.org/arch/msg/dnsop/awmoLxtbQtQhSt9K...
Interesting.
The technical reasons really make me lean towards using www.
1. users see example.com in the address bar
2. hosting on www.example.com
However you can get the best of both worlds. If you go to amazon.com, you will see amazon.com in the address bar. Yet your browser makes requests only to www.amazon.com; the content is hosted on www.amazon.com.
Does anyone know how they pulled that off?
For me, the "www" shows up in Chrome 70 and Firefox. Chrome 72 hides the www again.
See this post on Super User: https://superuser.com/questions/1356867/chrome-69-hiding-www...
So please leave this decision to the admins and the way they established it. With WWW!
Is that really weird at all? "you take the pain so your customers have things more pleasant" is a common idea.
None of your customers care if you are doing "the right theoretical approach to the usage of www" if your competitor isn't. They'll simply go to your competitor, who does the thing they want.
e.g. "CNAMES at the root of DNS" which is mentioned in this post; you can find any number of greybeards lecturing you on how wrong it is, but when you face your customers and they say "Amazon Route 53 DNS lets us do it", what does it matter how wrong it is? Explaining to them how Amazon has built something custom and non-standard, won't make them happier. They'll just use Amazon.
The problem is that Let's Encrypt doesn't support wildcard certs, so having a single cert for the origin and allowing connections on "www." is not possible. This is a problem because a request on "https://www." will be rejected completely rather than redirected to the origin (or vice versa). In other words, I have to choose one, and the other one won't work at all and can't be redirected (for https, but I'm auto-redirecting from http to https as well, so for everything). Obviously, the marketing gains from not having a "www" outweigh any other considerations at this point, so no "www".
As I understand it, anyway. I could be wrong. I hope I'm wrong, and have just misunderstood how this all hangs together.
They do support wildcard certs now.
unless I'm missing something :)
I imagine you have to setup your stuff to respond to the DNS + web based challenge/response.
Here is how I do it using acme.sh:
acme.sh --issue --dns --force --yes-I-know-dns-manual-mode-enough-go-ahead-please -d "${domain}" -d "*.${domain}" > /dev/shm/.le."${domain}".txt certbot -d example.com www.example.com [other flags here]
Here is an example certbot command:
certbot certonly -n --agree-tos -m example@example.com --webroot -w /var/www/example.com -d 'example.com,www.example.com'
https://github.com/sumdog/bee2/blob/master/dockerfiles/CertB...
They do. Since March 2018.
The truth is: 1. No one cares 2. Choose one of two and stick to it 3. Care to maintain a redirect from the second option to the chosen one.
Cheers!
There is an RFC for using www
But the site hosting the article does not use www...
Everything it mentions in prefer for WWW can be solved by a combination of static IP and CDN. My site's domain, for example, has a domain with a static IP and the site is served by HTTPS. Certificate resolution for the HTTPS goes to CloudFlare which also serves as a CDN for everything retrieved from the domain. CloudFlare provides firewall and security options as a feature of its CDN capabilities.
Because I am already solving for all the DNS and application concerns mentioned by the article I choose to use the more sane approach and simply drop use of a default subdomain.
EDIT:
I also detest cookies. They can store virtually nothing at 4kb per domain and the cookie API is horrible. Instead I use localStorage for all storage concerns and share explicitly anything that needs to be shared via XHR, which currently is nothing.
What don't you like about it?
https://developer.mozilla.org/en-US/docs/Web/API/Document/co...
Compare all that madness to the localStorage API:
localStorage.myName = "string up to 5mb";
delete localStorage.myName;You should only be using server-side APIs for cookie management. Many good ones exist.
Reference: https://www.owasp.org/index.php/HttpOnly
No. I will use any string I want of any size I want. Cookies are a relic of an archaic age for the web.
Cookies only continue to be used because many server based web applications haven't figured out a modern way for managing sessions.
Don't let your API elegance preferences be the only factor in your architecture design choices. Please consider security too as you may be putting your users at risk. Design choices in this area are more nuanced than you seem to be aware of.
And regarding Cloudflare: Terminating your TLS session on a third party provider's server also has it's downsides.