Should your website address have a www (e.g. or not (e.g. This question came up again recently, prompting me to look into it a bit more, and write down my thoughts. Some people feel fairly strongly about this; there is even a campaign against "www". The alternative, called bare domains, zone apex domains or root domains, is not without issues.

Some arguments against:

  • The www just looks "old"
  • www is unpleasant to spell. In conversation the short form "web" has taken over the "world wide web" phrase, so "www" is just weird and ugly
  • New exciting startups use bare domains: Twitter, Stack Overflow, lots of others
  • Typing www takes more effort, which on some mobile platforms can be inconvenient
  • Separate www used to be needed because you had separate machines serving as web servers; Layer 4 content switches make that a non-issue
  • In URLs the www is superfluous visually, because the "http://" in the URL indicates that it is a web site

Some arguments in favour:

  • the www looks familiar
  • Most popular websites use www: Facebook, Google, Zynga, most others
  • Typing www is hardly ever needed: browsers can prepend it for you, and you don't often need to type URLs anyway, because you usually reach sites through existing links on other pages, bookmarks, history suggestions etc.
  • Separate www makes management more flexible because you can have separate addresses with different A records
  • The www makes a hostname visually self-identify as a web address, without needing an ugly "http://". This is especially appealing in printed marketing materials such as business cards, TV ads etc. This may be even more important for uncommon top-level domain names (those other than .com/.org/.net), especially newly created ones and country TLDS that are used for vanity domains, which non-expert users may not recognise. Note also that some browser (e.g. Google Chrome) hide the "http://", so it may fall further out of use.
  • bare domains are not allowed to have CNAMEs in the DNS, but CNAMEs are strongly recommended in some network configurations
  • bare domains can confuse email configurations
  • some DNS control panels at DNS providers don't allow you to use bare domains
  • SSL configuration is easier with "www", because that gets matched by "*" wildcard certificates.

Ultimately people seem to decide based on entrenched taste rather than actual usability or technical arguments. But I'm interested in considering the technical implications. Having the "www" has no technical drawbacks, but bare domains have two: the CNAME problem and the mail problem, which I would like to explore in some more detail.

The CNAME problem stems from the RFC1034 DNS specification rule which states that:

"If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types."

A bare domain must have SOA and NS records (these are the basis of authority delegation in DNS), so if it also had a CNAME, that would violate the above rule.

So, what problems are caused by this restriction that you cannot use CNAMEs for your web server address? Surely you can simply not use CNAMEs, but use A records to locate your web server? Actually, that depends. Some CDNs use CNAMEs (RackSpace, Amazon CloudFront). Likewise, load balancers from cloud hosting providers like Amazon EC2 typically require CNAMEs. Amazon has relatively recently announced a solution: Amazon Route 53 alias resource record sets. Heroku documents DNS configuration for custom domains (duly requiring A addresses for root domains), but after a recent DDoS they recommend against root domains because they don't allow their system administrators to update IP addresses.

Next, the email issue. To deliver internet email, a message sender consults the DNS for the MX record of the destination, then looks up the resulting DNS name, which results in an A record, listing the IP address of the mail server (MTA) to connect to. If there is no MX record on the destination, the sender does a lookup of A records on the name itself. With bare domains you can have A records pointing to the web server, and the MX record to a different server that runs the mail server (MTA). The problem comes when the MX lookup fails (or is not done), and the sender falls back to the A record -- it now talks to the wrong address and fails to deliver the email. Now, wether this message sender behaviour is advisable is debatable, and not all mail sending software will work in the same way. I think that it is likely that this is less of a problem now than it was years ago. But if you weren't using bare domains then you'd have no A records on your domain, and this wouldn't be a problem at all.

So neither issues are show-stoppers, but it seems that having "www" is more straightforward all round.

This topic would not be complete without the obvious recommendations that you should only have one canonical URL for a resource. So if you use bare domains, you should also support www and redirect it to the bare domain, in case people type it out of habit. Or if you use "www", you could redirect your bare domain to it.

As an aside: in the early days of the web the "web" hostname was sometimes used, and I used it myself for before the "www" became the norm. I still prefer it visually, and in transcription. But, the principle of least surprise directs me to continue using "www" for my own websites.