The basics of domain names

Almost every problem that reaches a committee agenda under the heading of the website turns out, on inspection, to be a domain problem. The site is fine. The hosting is fine. What has happened is that a registration lapsed, or a nameserver was changed by somebody who no longer volunteers, or a record was pointed at a service that was cancelled last spring. Untangling any of that is straightforward once the underlying machinery is clear, and close to impossible while it is not.

The machinery has three moving parts. There is the register itself, a list of names kept by an organisation appointed for each extension. There is the company that puts entries into that register on behalf of people who want them. And there is the name in the register, which does nothing on its own until it is told where to send visitors. Those three things are administered separately, billed separately, and go wrong separately, which is why a single question such as why the address stopped working can have half a dozen unrelated answers.

This section takes them in order. It starts with what a domain actually is, which is a leased entry rather than a purchase, and why that framing explains almost everything that follows. It moves through the act of registration, the roles of the registry, registrar and registrant, and the way names are translated into addresses by the system of nameservers and records. It ends with the renewal cycle, which is the single most common cause of an organisation losing a name it had held without incident for years.

None of it requires technical skill. A treasurer who can read a bank statement can read a domain record. The value of reading it is that the language stops being intimidating, which in turn makes it possible to ask a provider a precise question and recognise a vague answer. Once the basics are in place, the practical work of holding a name properly, covered in the ownership section, becomes a matter of paperwork and habit rather than of trust in one helpful member.