Composr Tutorial: How domain names work

Written by Chris Graham (ocProducts)

This tutorial is designed to give a full explanation of domain names, DNS, and the politics surrounding it all. It is written primarily for agencies/consultancies who need to work with previously registered domain names.

Table of contents

Composr Tutorial: How domain names work

localhost

Before we get into explaining domain names, I wanted to quickly talk about host names. Domain names are a form of host names, but you can define your own host names on private networks. Every computer actually automatically has a fully working host name called "localhost" which points back to your own computer. This is useful if you are testing a site on your own computer.

The business relationships of an actual domain name

Domain names are purchased from a domain name registrar (aka "agent"), which is an independent company which uses their prearranged relationship with a high level authority to get a domain name set up. The registrar then provides the commercial services for that domain, and the technical services to be able to set things up against it. The high level authorities differ depending on what kind of domain it is (all these authorities are chosen by the highest level authority, ICANN):

The high level authority for uk domains is Nominet
The high level authority for com, org, etc (usually Verisign)

When dealing with the management of domain names as assets, one typically deals solely with registrars, and never deals with the high level authority. However if a registrar goes out of business or is too poor to provide reasonable service, then one needs to deal with the high level authority. Dealing with the high level authority is not ideal, as the service is more bureaucratic than commercial – one needs to provide identity, send postal letters, and make 'statutory' payments to get anything done.

The very special case of Tucows (ignore if you don't care)

Matters are made complicated in the case of a domain where Tucows is the registrar. This is because Tucows creates an additional level of authority, because they set themselves up as an agent for their own resellers. These resellers don't have to have such a complex infrastructure as full-blown registrars, and thus some companies that sell domain names aren't really registrars, they are just Tucows resellers. Tucows refuse to provide services to domain owners, and insist you always work through one of their resellers. Fortunately, Tucows are set up such that the owner of a domain (on proof of their identity via a scanned passport) can have a different Tucows reseller subsume control over their domain name, without having to make any specific payments or filling in forms or posting anything.

How domain names direct traffic to servers

Note that domains names are not a "web" technology, they are an "Internet" technology. So at the level of domain names we are not considering websites yet, merely how traffic is directed on the Internet. (The web refers to the multimedia experience, while the Internet is the networking technology)

Every domain name has basically one setting involved in the process of directing traffic: the nameserver for that domain name.

The nameserver for the domain then will itself define where different kinds of Internet traffic get routed to. It basically defines against two different traffic kinds:

E-mail (MX records)
All other Internet traffic, including web traffic (A records)

Subdomains

A nameserver may define records for subdomains of any complexity, underneath domain names it handles). So a nameserver for example.com could define records for foo.example.com, bar.example.com, and even foo.bar.example.com.

However, DNS is based on the idea of delegation. nameservers may also choose to delegate control of names such as the above to separate nameservers, instead of handling themselves. So for example, the nameserver for example.com could delegate test.example.com to a separate nameserver. That nameserver could then set all records for test.example.com or anything underneath it, and it could itself make further delegations.

Webhosting

Knowing all the above, we can deduce that there are a number of ways that we could get a domain name to point to some webhosting. These ways are fundamentally quite different, but from the end-users point of view, have the same result.

Transfer a domain (in English, this means "change the ownership of the domain name")
Change the domain tag (in English, this means "move the domain to a different registrar")
Change the reseller (for Tucows-only)
Change the nameserver (in English, this means "set a new nameserver so the controller of that nameserver can configure where traffic will go")
Change the DNS records at the existing nameserver (in English, this means "reconfigure the domain name settings")

Which to use? It typically depends on non-technical reasons that can get quite complex. Basically it depends if you are transferring ownership or just making configuration changes.

Transfer a domain

Every domain name is owned (well, more accurately, rented) by a consumer or business, not by a registrar. This is reflected in the contact details defined for the domain name, but at a more fundamental philosophical level, by the actual person who has rights over the domain.

Transferring a domain is changing the ownership of it to a new person. That new person is then authorised to control it. At the point of transfer, you can also choose a new domain tag (see below).

It is not normally advisable to do a domain transfer unless the domain, as a business asset, is being sold.

Change the domain tag

Changing the domain tag is changing the registrar. Basically you can choose a new registrar company, go to their website and go through to transfer a domain name to them. Typically you are charged a fee equal to their lowest registration fee, and the life of the domain name gets extended.
For the transfer to be finalised, a procedure needs to be undergone that is different, depending on who the high level authority is and who the registrar is. Basically I have experienced three scenarios:

In the simplest case, you go to the old registrar, and you can pull out an authorisation code direct from their control panel. You then paste that code into the website of the new registrar.
In another case, it's as above, except you have to actually go ask the old registrar for the authorisation code.
In the more complex case, the new registrar actually triggers a system whereby the old registrar is informed that the transfer is being planned. The old registrar then contacts the domain owner, via the contact details defined for the domain name. If the old registrar is successful, they send an 'okay' through to the new registrar.

The problem with this mechanism is it depends on:

(For scenario 1) Having access to the domain control panel
(For scenario 2) Having proper proof of identity, reflective of the identity defined for the domain name
(For scenario 3) The domain name contact details being correct (these could be corrected manually before the transfer was initiated, if one has access to the domain control panel)

The advantage of this method is that if the domain tag can be changed to that of the hosting company (assuming they do domain registration), only a single business relationship needs maintaining. The disadvantage is that the existing business relationship is broken, and that we probably then start taking responsibility for things like domain renewal (this is perhaps not a disadvantage if we are providing a full service).

Note that as well as changing the domain tag, one might need to manually change the nameserver (see below). This might be done for you by some domain registrars, but it needs to be checked. It's a simple job to make such a change manually anyway.

Change the reseller

This only applies in cases such as Tucows, where the real registrar is in fact just a reseller to other companies. The only case where we would want to change Tucows reseller, rather than either sticking with the existing reseller, or changing the domain tag, would be the case where the existing reseller is out of business, and we do not want to have to deal with the high level authority by messing around posting things and writing cheques.

Change the nameserver

Changing the nameserver is a simple and effective way of moving a domain to different hosting. One just changes the nameserver so as to point to the nameserver provided by the webhost. The webhosting control panel then allows direct configuration of all hosting-related aspects of that domain name.

The only problem with this method is that it means a commercial relationship has to be maintained with the domain registrar. It's often preferable to do a tag change to a company that provides both webhosting and domain registration – because then only one business relationship needs to be maintained.

Change the DNS records at the existing nameserver

One can change DNS records so as to manually point web traffic towards a new webhost.

Note that this method also has the disadvantages of "changing the nameserver".

Use an HTML solution

Another way to handle things is either to set up an HTML frameset, a simple HTML redirect page, a PHP header redirect, or a header redirect configured in the web server software (e.g. IIS, or .htaccess). This isn't ideal because the domain name cannot be used for making long URLs to the website. However, if there is a second domain name that is 'good enough' then the problem is very small because long URLs can be made against this second domain name.

We'd use an HTML solution in the case where we can leverage no control over any domain settings whatsoever. Two situations for this would be:

the domain is somehow tied up
the client does not want us to make these kinds of changes

Note that for all the methods other than 'Use an HTML solution', it is necessary to set up the webhosting to listen for traffic for the new domain name. Otherwise it has no way of knowing how to associate the files on its web file system with the URL requests it receives.

Finding out domain and DNS settings

I recommend using Software Reviews, Opinions, and Tips - DNSstuff to lookup settings for domain names. Use a "WHOIS Lookup" to find out:

The contact details for a domain
A domain's nameservers
Who the registrar is
When the domain will expire (need renewing)

To find where web traffic is sent, do a DNS lookup of type 'A' against the domain name.
If it doesn't give a result, try adding 'www.' to the start, as sometimes DNS is set up so that URLs need that on there.
To find where mail traffic is sent, do a DNS lookup of type 'MX'.

Feedback

Please rate this tutorial:

Have a suggestion? Report an issue on the tracker.