In this concluding article, Geoff Meads delves deeper into the world of the domain name system (DNS) and demystifies some of the more complicated terminology.

In my last article we took a look into how the DNS (or ‘Domain Name System’) powers the devices we use every day by helping them to find the correct IP address for services on the Internet. In this concluding article, we’re going to dig into some of the subtleties of the DNS landscape and, in particular, explore some of the acronyms you might come across.

Domain Registrars

In the last article I noted that control of DNS addresses is undertaken by an organisation called ‘ICANN’ (or the ‘Internet Corporation for Assigned Names and Numbers’). However, ICANN does not sell domain names to individuals or businesses. They use intermediary companies called ‘Registrars’.

When you buy a domain, you will buy it from a Domain Registrar, often a company that also supplies hosting and email services too. When you’re setting up a company, it’s perfectly normal to use the same supplier for all of these things and it certainly helps to keep things simple to do it that way.

To find out who owns a domain you can use a service like ‘WHOIS’ (you can try looking up a domain of your choice at https://lookup.icann.org/lookup). If you try ‘facbook.com’ you’ll see the registrar is a company called ‘RegistrarSafe LLC’. This is the company that is responsible for the billing of that domain name to the owner (Facebook) on a periodic basis and, in turn, paying ICANN for the use of the domain.

When you make a WHOIS look up you will see one of two things, either the actual owner (probably you for the domain you own and use) or possibly the Registrar you purchased it from. In this second case the actual owner has opted for ‘domain privacy’ which hides the end owner from the public record. Whether or not you need this privacy depends on your circumstances.

Now that we know who owns or is the registrar for a domain, where do we find those IP addresses for the domain’s website and email? For that we need an…

NS (Nameserver) Record

ISP records do not contain all the records for every subdomain. They actually only contain single records for each domain. These records have two parts, the domain name itself and the NS (or Nameserver) record. The Nameserver records contain the domain of the entity that holds the detailed records of the domain.

Let’s look at an example…

Looking up the NS record for ‘facebook. com’ reveals the NS records are held at ‘ns.facebook.com’, Actually there are four sub-providers for this in sub-domains called a, b, c and d, probably due to the huge traffic they handle.

While this is helpful information it still didn’t get us the IP address of the Facebook web server to use their service! However, now we know where the detailed DNS records are kept, we need to do another lookup for the IP address of ‘ns.facebook.com’ before we can request them from the Nameserver at that address.

A point of order here, Facebook (and other large services like Amazon, Twitter etc.) have their own Nameservers whereas normal domains (like one belonging to a typical installer) will host their Nameservers with the registrant or company. These Nameservers will be serving NS records for large numbers of domains all at once.

In short, a Nameserver lookup is similar to asking, ‘which phone book is the phone number I want contained in?’. Once we get the right phone book, now we can look up the right number. To find that out we’re going to need an….

‘A’ Record

The ‘A’ Record is the main or primary address for a domain. It holds the IP address of the master domain and is used when no sub-domain is specified in a DNS request. Now, an ‘A’ Record only works with IPv4, for IPv6 you’ll need an ‘AAAA’ record, but we’ll leave IPv6 for another day.

Some websites (including some really big ones like Twitter) don’t use a ‘www’ subdomain for their website. The actual URL for Twitter is ‘https://twitter.com’. This is clearly different from Facebook which uses http://www.facebook.com.

Now, an interesting exercise is to try typing the ‘wrong’ URL into your web browser and see what happens. For example, if you type in ‘www.twitter.com’ it will return the page at twitter.com. Alternatively, if you type in ‘facebook. com’ it will  return ‘www.facebook.com’. So, what on earth is happening there?

To make that happen you’ll need….

CNAME Records

CNAME (or ‘Canonical Name’) records are aliases and take care of situations where people are trying to get to your service but with the wrong URL. We don’t mean a wrong spelling or a typo, we can’t do much about that. But if your website is at ‘www.mywebsite.com’ and a user types ‘mywebsite.com’ we need to catch that and redirect them to the right place or  we might lose their visit and maybe even lose business!

For this purpose, we can add a CNAME Record which will contain two things: the ‘incorrect’ domain and the ‘correct’ one.  An example might be that the CNAME ‘www. mydomain.com’ points to ‘mydomain. com’ (the A Record). Note that a CNAME can only contain domain and sub-domain names, never IP addresses. Once traffic is at the actual IP address specified in the A record the web server can determine if the user’s browser shows the website displayed with or without the ‘www’.

MX Records

These are much easier to explain, put simply they show the IP address that deals with email for the domain. So, if your email client on your phone or laptop needs to send an email to [email protected] it first sends a DNS lookup for ‘mx.theirdomain.com’ so it knows where to send your email.

TXT, SRV and other records

There are yet more DNS record types that we could explore but these are used pretty infrequently. However, it’s worth mentioning TXT and/or SRV records as some services ask you to add these to your DNS records in order to prove you actually own that domain. This is often the case when using external suppliers for your email (like Gmail) or services on your website like Google Analytics or Tag Manager.

As you can see a whole lot of pointing and repointing goes on with even the simplest DNS request. Every time you send or receive your email, look at a webpage or post a Tweet in an app DNS records are being read and traffic redirected, all without the user ever having to know how it works. It’s just another hidden wonder of the Internet world!