HTML Logo by World Wide Web Consortium (www.w3.org). Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS, which is now in beta. ocPortal 9 will be superseded by Composr 10.

Head over to compo.sr for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.


ocPortal 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.


The business relationships of an actual domain name

Domain names are purchased from a domain name registar (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.

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 are mapped to servers

Every domain name has basically one setting that affects how traffic is routed: the name server for that domain name. At the domain name level, there is no such thing as 'web hosting', as domain names are not tied to the web at all.
The name server for the domain itself defines 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 (A records)

Subdomains

A name server 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. Name servers may also choose to delegate control of names such as the above to separate name servers, instead of handling themselves. So for example, the name server for example.com could delegate test.example.com to a separate name server. That name server could then set all records for test.example.com or anything underneath it, and it could itself make further delegations.

Web hosting

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 web hosting. 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 "change to a different registrar")
  • Change the reseller
  • Change the name server
  • Change the DNS records at the existing name server
  • Use an HTML solution
The distinguishing factors are based on typically non-technical reasons, that can get quite complex.

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:
  1. 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.
  2. In another case, it's as above, except you have to actually go ask the old registrar for the authorisation code.
  3. 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 name server (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 name server

Changing the name server is a simple and effective way of moving a domain to different hosting. One just changes the name server so as to point to the name server provided by the web host. The web hosting 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 web hosting and domain registration – because then only one business relationship needs to be maintained.

Change the DNS records at the existing name server

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

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

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 web hosting 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 DNSstuff: On-demand DNS and network tools to analyze, diagnose and monitor a domain or IP address to lookup settings for domain names. Use a "WHOIS Lookup" to find out:
  • The contact details for a domain
  • A domain's name servers
  • 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'.

See Also