Understanding DNS

Part one - Basic domain name settings

One of the main problems we encounter when taking over an existing domain name or website is the DNS configuration. Most people do not understand DNS, or have lost contact with "the guy that sorted it all out". Even IT professionals are often left in the dark as to how a companies DNS is configured. It may have been setup years ago, or companies are reluctant to interfere with something that works but they dont understand why or how it works. This post is intended to demystify the processes involved.

The domain name service was originally introduced to simplify the Internet, its purpose is to give meaningful names to series of numbers that form Internet addresses (IP addresses), and for web users, it works perfectly. Its much easier to remember "www.google.com" than "173.194.36.104". The tricky bit is saved for website owners, when you buy a shiny new domain name, it needs to be bound somehow to an IP address so that the domain name service (DNS) can fulfil its purpose and serve up your website when someone types in your domain name. It seems straightforward, you type a domain name and some behind the scenes magic fairy goes off to look for where that domain lives. However, since there are no magic fairies were going to have to understand what it is they actually do behind those scenes.

Registration

When you buy a domain name, you are buying a service from a "registrar", for example 123-reg is a registrar. At this point, the domain name is not configured to point at your website, in fact the only job of the registrar is to register your domain and contact details with the Internet authority. In order for your website to function, registrars also need to register the "name service" that will form the first point of call when a request for your page is made. To simplify buying a domain name, registrars simply tag their own name service onto your domain name.

Name Servers

Your domain name is held on a database called a "Name Server". Nameservers are a bit like like websites in some respects, they live at a particular IP address and they already have a domain name bound to that IP address. They are unlike websites in that they do not serve content, pictures or video, but records from a database containing technical information about your website. Although registrars also provide nameservers as part of the domain registration service, by default, these nameservers are configured to point back to the registrars website, some free advertising for them.

Nameservers are the first port of call whenever you request a website via your browser. In most cases and if you havent modified these details, this will be the name server of your registrar. However, if you have an existing website the name server details may have been modified at some point in the past.

Zone records

So what data do name servers actually provide? When a user types your domain name into a browser, the browser must decode the actual IP address of where your website is hosted. It cannot make a request until it knows this information.

To obtain it, the browser queries the nameserver to get the appropriate "zone records" that describe your domains location. Zone records are made up of text files that tell web requests where appropriate aspects of your domain live. In the case of a browser, it probably wants to know the "www" address, and so the name server returns the appropriate "A" record containing the IP address for your website. With email, these require a different type of record known as "MX" (Mail eXchanger) records. This is what makes it possible to host your email at a different location or on a different server to your website.

Website

For the purposes of this discussion, your website simply comprises of files (such as web pages) that reside on a hosted server somewhere on the Internet. As of now, they are "orphaned", that is, although they exist on the Internet, your domain name doesnt yet point to them and so they are unreachable.

To fill in the gaps, take a look at the following diagram. Work left to right starting with the registrar, then following the arrows along the process to discover the actual address of your website. There are two examples here from two different registrars. Notice the zone records for both "@" and "www", dont be confused by the "@" symbol, this does not signify email, but is the 123-reg specific "wildcard" that signifies the non-www address of your website, for example "domain.com" as opposed to "www.domain.com". It is possible then to serve two entirely different websites from "www" and non-www, although this is rarely done and is never advised. For now, ignore the MX (email) records in the diagram, we'll get to them later.

According to the diagram above, if I type in www.lynkit.net into a browser, the magic fairy domain name service will see to it that our website reaches your screen. Which it does otherwise you wouldnt be reading this!

So what could possibly go wrong? As long as the correct IP addresses are entered into the zone records your website should show? Maybe not...

Here we have reconfigured the nameserver records to use a different provider. Although our domain was registered by 123-Reg, they are no longer supplying the required zone records. If you attempt to modify the zone records at 123-Reg, it will have no effect because domainmonster is now supplying these. This is the number one cause of confusion about DNS so its worth remembering. When configuring your website its best to have access to usernames and passwords for all providers in the chain so that fine tuning can take place without breaking any part of your domain. Email is usually the one to suffer in these cases.

So how do we fix the situation above? We could revert to the simple configuration in figure 1, or we could continue to use our third party nameservers by correcting the zone records contained there, as in the configuration illustrated below: