The www that was not there

A consultancy launched a redesigned site and shared the address on a printed brochure as www.example-consulting.com. The team had tested the bare domain, example-consulting.com, and it worked beautifully.

The DNS zone, however, only contained records for the bare name. There was no record for www at all. Anyone who typed the version printed on the brochure received an error saying the server could not be found. Since people tend to copy what is printed, the people most likely to be sent away were the ones who had been handed a brochure by a prospective client.

The previous host had hidden the problem for years by automatically answering for both names. When DNS moved, the automatic behaviour did not come along. The consultancy is a composite of a few small firms with the same experience, and the numbers are illustrative; the mistake itself is among the commonest launch errors there is.

Two names that look like one

To a person, example-consulting.com and www.example-consulting.com are the same place. To DNS, they are two different names, each of which needs its own answer. The bare name, also called the apex or root of the zone, has records of its own. The www name is a label beneath it, and it exists only if someone has created a record for it.

The habit of putting www in front of a website comes from the early days of the web, when a company would run several services on one domain and name each machine for its function: www for the web server, ftp for the file server, mail for mail. Most people still type it, and printers still print it. Plenty of modern sites use the bare name as their public face. Visitors do not care which; they care that both work.

The consultancy's brochure had gone to print with the www form. The web team had been using the bare form throughout development because it was shorter. Nobody tested the form that had been printed.

What the visitor saw

A browser asked to open the www address first asks DNS for the address behind that name. When the answer is "no such name", the browser never attempts a connection. It displays an error, and the wording depends on the browser: "This site can't be reached", "Server not found", or the code DNS_PROBE_FINISHED_NXDOMAIN. There is no web page, no logo and no contact form, because the failure happens before the web server is involved.

This has a sting in the tail. Because the server never saw the request, the access logs were empty of any trace. The team's analytics reported healthy traffic from people who had used the bare name. The people who had been failing were invisible to every measuring tool the firm owned. The only evidence was a few puzzled messages: "I tried the address on your brochure and it didn't work".

Those messages came from the most interested people. A prospect with a brochure in their hand is far warmer than a stranger finding the site by search. Some wrote to say it was broken; many gave up and said nothing.

Why it used to work

The old host had treated the two names as the same thing without anyone asking it to. Many shared hosting panels create both records automatically when a domain is added, or answer for any name beneath the domain with a catch-all, sometimes called a wildcard record. The site had run there for years with both forms working. Nobody on the team had ever looked at the zone, because there had been nothing to see.

The redesign came with a move to a new platform and new nameservers. The new zone was built by hand, from a list of records the designer had noted down: the address for the bare domain, the mail records and a couple of verification entries. The list did not include www, because the old zone had not listed it either; the old host had made it up on request.

; zone as built
example-consulting.com.      3600  IN  A      203.0.113.10
example-consulting.com.      3600  IN  MX 10  mail.example-consulting.com.
example-consulting.com.      3600  IN  TXT    "v=spf1 mx -all"
; no www record at all

Moving DNS between providers is one of the places where things that "just worked" disappear. Behaviour that came from the provider's software, and not from a record, does not travel in an export.

Finding it

Once the brochure complaint reached a person who knew where to look, the diagnosis was one command:

dig www.example-consulting.com A +noall +comments +answer

The response header said status: NXDOMAIN and the answer section was empty. The same command for the bare name returned status: NOERROR and the address. Comparing the two settled it in under a minute.

A shorter form shows the same thing: dig +short www.example-consulting.com prints nothing, where the bare name prints the address. An empty result does not itself tell you whether the name is missing or the record type is, so the status line is worth reading.

The fix, in three parts

Adding the record is the easy part. The consultancy chose a CNAME for www, pointing at the bare name, so that the two can never drift apart if the address changes:

www.example-consulting.com.  3600  IN  CNAME  example-consulting.com.

Using an A record with the same address would also have worked. The CNAME is tidier for a site hosted at one address; an A record is the better choice if the www name needs to differ in any way, or if the provider offers only a plain apex address.

The second part was deciding which name is canonical. Search engines treat the two forms as separate sites unless told otherwise, and visitors get a muddle of addresses in their bookmarks. The firm picked the www form, because it was already on the brochures, and set up a permanent redirect from the bare name to it. The redirect generator writes the rule for most web servers.

The third part was the certificate, covered below.

The certificate and the plain HTTP versions

A certificate for the bare domain does not automatically cover the www name. If the certificate lists only example-consulting.com, a visitor arriving at the www form gets a warning about a name mismatch, which is a worse experience than a missing page because it looks like a security fault. Request a certificate that lists both names, or a wildcard that covers the www label and the bare name together.

The same applies to the plain HTTP versions. There are four addresses to think about: HTTP and HTTPS, each with and without www. A tidy setup redirects the three non-canonical ones to the fourth in a single hop. A messy one chains them, going from HTTP bare to HTTPS bare to HTTPS www, which works but wastes a round trip and sometimes breaks on certificate mismatches at the intermediate step.

The brochure was still in circulation, so the www form stayed canonical, and the printed address continued to be correct for the life of the print run.

What would have caught it

• Testing both versions of the address, plus the plain HTTP versions, every time DNS or hosting changes.
• Choosing one canonical version and redirecting the other to it.
• Making sure the certificate covers both names.
• Exporting and comparing the old and new DNS zones record by record before changing nameservers.
• Typing every address that appears in print or in an email signature into a browser before it goes out.