HOW DNS WORKS AND WHAT IT DOES.

How DNS works and what it does. In this post I’ll be talking about wha DNS is, what it does, and how it works. Gaining an understanding of this will help you manage your hosting services, sites, and mailboxes in the future.

DNS is the part of managing a website and web services that a lot of people seem to struggle with.

It’s one of those things that appears to look hard, but once you understand it, it’s not really that difficult. The purpose of this guide is to help you understand how DNS works and what it does, so that you can manage it.

I’m going to be writing this based around IPv4, for a simplified explanation.

The basics.

The internet and the web run on servers. Your hosting account, your site and your mailboxes all run on one of these servers. Each and every one of these servers has it’s own address. These addresses are called IP addresses and they look like this:

216.58.212.228

198.143.164.252

It’s not very easy to remember these addresses for humans. We’re much better at remembering addresses like www.google.com and wordpress.org. These are examples of friendly names (or Fully Qualified Domain Names – FQDNs).

What DNS (mostly) does is point friendly names to server (or IP) addresses. What this means is that when you use a friendly name to do something the traffic for whatever you’re doing is routed to a server. How the DNS is “pointed” dictates where the traffic for what you’re doing is sent.

There are other types of DNS records that define something other than where traffic should route as well, these are covered later in this post.

In practice.

DNS works is by pointing friendly names like www.google.com and wordpress.org to server’s IP addresses, DNS controls where traffic is routed.

If you type www.google.com in to your browser’s address bar, then press return a DNS lookup takes place. An IP address is found as a result of the lookup, and your computer then sends the request for www.google.com to this IP address.

A similar lookup takes place when you send an email. The mail server that you’re sending from looks at the email address you’re sending to, then does a DNS lookup on the domain of the to address (the part after the @ sign). Ultimately an IP address is found, and the sending mail server sends your email to the IP address that’s found.

Understanding how DNS works allows you to be able to control how traffic for your domain will route.

Why?

DNS exists so that us humans can use friendly names that are easy to remember and route traffic, emails or website requests to the correct servers. Due to DNS we don’t need to know what these IP addresses are, DNS tells the things that need to know what the IP addresses are. If you know how DNS works, you can control how your friendly names work, or at least the server addresses these point to.

In the early days of the internet DNS didn’t exist. To be able to look at a website you had to know the IP address of the server that holds the site, then you had to edit a file on your computer (hosts) to tell your computer which IP address it should send requests for the site to. DNS was invented so that people didn’t need to do this. The internet was also growing, and keeping track of IP addresses for specific websites was becoming unmanageable using the hosts file.

Due to how DNS works, it also means that things can be moved. A website moves, and it’s DNS is updated so that people get served the site from the server it’s been moved to. Server hardware doesn’t last forever, and software goes end of life, which dictates the need to have to move things and therefore the need to direct traffic to where these things have been moved. DNS allows for the redirection of traffic associated with things being moved to new servers.

Zones and Nameservers.

DNS zones contain all the DNS records for a domain. These are a collection of DNS records for a domain, held in one file. The zonefile.

DNS zonefiles are held on nameservers.

Nameservers are set against a domain (usually at the registry where the domain is held). This defines the nameservers used to obtain DNS information for a domain. Consequently domains and nameservers are integral to how DNS works.

DNS records are defined in a DNS zone, and the DNS zone is held on a nameserver, and the nameserver (or more accurately, nameservers) is set against a domain.

You might think of it like:

Domain defines nameservers > Nameservers hold DNS zone > DNS zone defines DNS records > DNS records control where traffic is routed (where an email would route, or where a request for a website would be sent, for example).

Caching.

When a DNS record is looked up and found it’s remembered for a period of time.

The reason that DNS records are remembered is to speed things up by reducing the number of DNS lookups that would be involved with say, browsing multiple pages on a website.

There are two things that “remember” (or cache) DNS records that have been looked up. These are your computer and the DNS servers your internet connection provider has in place (these are called recursive DNS servers).

The “remembering” is called caching. If a DNS record has been looked up it’s cached (or remembered) for a period of time. The period of time that should be remembered is defined by a DNS record’s TTL (time to live) value, this is a number, usually in seconds. The reason I say “should” is because TTL values are considered to be guidance, rather than something that’s always adhered to.

In practical terms.

You need to know the IP address where your services are held. If you’re using cPanel you can see this by logging in to your cPanel and looking at the information on the right hand side. In amongst this information you’ll see “Shared IP address: 1.2.3.4” it will look like this:

This is the IP address of where your site is, and usually (this can be provider specific) where your mail services will route to.

Most DNS records will ultimately point to the IP address of a server, which is where site traffic will route to, and where emails will route to, so for me, I need to make sure my site points to 185.229.22.190 and that my emails will route to 185.229.22.190 as well.

If you’re using cPanel and have bought your domain and hosting from the same company, and are running your site and mailboxes within cPanel all of this will be in effect by default.

Different Types of DNS records.

There are different types of DNS records that do different things, and work in different ways.

A records:

A records are friendly names (or addresses) that point to an IP address. For example:

someguycalledralph.co.uk > 185.229.22.190

CNAME records:

CNAME records are friendly names that point to other friendly names, such as:

www.someguycalledralph.co.uk > someguycalledralph.co.uk

As someguycalledralph.co.uk is pointed to 185.229.22.190 (as per the A record above) this makes www.someguycalledralph.co.uk also ultimately point to 185.229.22.190 as well:

www.someguycalledralph.co.uk > someguycalledralph.co.uk

someguycalledralph.co.uk > 185.229.22.190

If I changed the A record for someguycalledralph.co.uk it would also change the IP address that www.someguycalledralph.co.uk ultimately points to.

Think of CNAMES like:

CNAME points to A record which then points to IP address.

If I wanted to to I could have one CNAME pointing to another CNAME which points to an A record, like this:

cupoftea.comeguycalledralph.co.uk > www.someguycalledralph.co.uk > someguycalledralph.co.uk > 185.229.22.190

If I then changed the IP address in the A record for someguycalledralph.co.uk to 1.2.3.4 this would also make the cupoftea.comeguycalledralph.co.uk and www.someguycalledralph.co.uk CNAMES also point to 1.2.3.4

CNAME means “canonical name”. Something that refers to something else.

MX records.

MX records dictate where mail routes to.

Like CNAME records MX records are usually a friendly name that points to another friendly name that’s an A record (so ultimately points to an IP address). Like this:

MX = someguycalledralph.co.uk > A someguycalledralph.co.uk = 185.229.22.190

So mail for the someguycalledralph.co.uk domain ultimately routes to 185.229.22.190.

BUT, if for example’s sake, I moved my just my site to another server (but not my mailboxes) and changed the A record for someguycalledralph.co.uk to the IP address of the new server, this would also make my emails route to the server where my site is, because:

MX = someguycalledralph.co.uk > A someguycalledralph.co.uk = 185.229.22.190

So if I change:

A someguycalledralph.co.uk = 185.229.22.190

To:

A someguycalledralph.co.uk = 1.2.3.4

Then:

MX = someguycalledralph.co.uk > A someguycalledralph.co.uk = 1.2.3.4

So:

MX = 1.2.3.4

How I’d fix this (to keep mail routing to 185.229.22.190 but have the site load from 1.2.3.4 would be to:

Create a new A record for mail.someguycalledralph.co.uk that points to 185.229.22.190
Set the MX record for the someguycalledralph.co.uk to mail.someguycalledralph.co.uk
Repoint the A record for someguycalledralph.co.uk to 1.2.3.4

Which would mean I’d end up with my site specific records looking like this:

someguycalledralph.co.uk (A record) = 1.2.3.4

www.someguycalledralph.co.uk (CNAME record) > someguycalledralph.co.uk (A record) = 1.2.3.4

And my mail specific records looking like this:

someguycalledralph.co.uk (MX record) = mail.someguycalledralph.co.uk (A record) = 185.229.22.190

TXT records.

TXT records are basically words advertised by means of DNS.

They are used to store text-based information associated with a domain name. TXT records are used for various purposes, such as providing additional verification or configuration information for a domain.

There are two TXT records who’s “words” are used to validate the server your emails are sent from (as in “I’m definitely not a spammer!”). These are SPF and DKIM records. I’ll cover these in an article about email deliverability.

NS records.

These are authoritative nameservers. They aren’t to be confused with the nameservers set at the central registry.

Authoritative nameservers are defined in the DNS zone of the domain, where as the nameservers set against a domain are defined at the central registry.

Authoritative nameservers, as the name suggests are in charge.

The nameservers held against a domain serve a DNS zone, the authoritative nameservers exist in the DNS zone, they explicitly tell computers and servers doing DNS lookups what DNS records are.

Nameservers against domain provide zone > Authoritative nameservers in zone define where DNS lookups should be directed.

There’s an additional section covering this in a bit more detail at the bottom of this page.

Glue records.

Even nameservers have to have their own IP addresses. As I’ve mentioned above, authoritative nameservers (and the IP address these point to) are defined in a DNS zone.

As a DNS lookup starts by looking at the domain, then querying the nameservers held against the domain (the nameservers defined at the central registry), the nameservers set against the domain at the central registry also have to point to an IP address so that a query for them can be routed to the right server. This is what glue records do.

Glue records are defined at the central registry. They define the IP addresses that the nameservers held against a domain point to. Without these, the DNS query wouldn’t get sent anywhere, and the rest of the DNS lookup would fail.

SRV records.

SRV records are used to define the location of services or servers within a domain. They provide a way to discover and connect to specific services associated with a domain. They usually contain things like a target and a port. They’re really used to help things get set up, for example, say you’re using something like a VOIP phone that automatically works out where to connect to. The automatic working out part uses the serve record to find out where to connect to.

You won’t need to use these much for just making a site, but you might use these if you were running a larger business and wanted to integrate something like skype for business in to your workforce, and the devices using this service to be set up easily (or automatically).

Administration.

There’s no standard interface when it comes to DNS management.

When using cPanel, all the DNS records can be administered in the “Zone Manager”.

In the zone manager in cPanel there will already be a zone set up for you, which usually points all the DNS records to the server on which your cPanel hosting account exists.

You can edit existing records, delete records and edit records using the zone manager. The cPanel documentation covering this can be found here.

This is what the top of the zone for someguycalledralph.co.uk looks like in the cPanel Zone Editor.

And if I click on “edit” on the same line as the top record, I can then… er… edit it:

Tools and utilities.

There are quite a lot of lookup tools that can be used to lookup domains, nameservers and DNS records.

Let’s start as close to the top of the hierarchy as we can.

Whois.

Whois looks up domain registration information. This can be used to see the nameservers held against a domain, plus other domain registration information. You can use these sites to carryout whois lookups:

If you’re using a mac or a linux based computer, whois is built in by default, so you can just open the terminal and type:

whois someguyclledralph.co.uk

Then press return and the whois for someguycalledralph.co.uk will be displayed.

lookups.

The first part of a lookup starts with domain. The domain being the part of your website’s address after the www. or the part of an email address after the @ sign. This is why domains are very important. No active domain = no lookup = nobody can see your website or send you emails.

This section is the bit everyone gets stuck on. What I’m going to do is start with a really basic oversimplified explanation, then work up to what’s actually happening. Going straight in for the full explanation might not be the best way to start!

All of these explanations are specific to browsing to a site, but the same occurs with any DNS lookup. The descriptions are specific to accessing a site hence the “your computer” and “site” being used (instead of something like “outgoing mail server” and “incoming mail server” which is what would be in the descriptions if I was talking about sending and receiving emails).

So here goes…

The very simple version is:

Your computer looks up DNS records for a site.
An IP address is returned as a result of the lookup.
Your computer then sends the request to the IP address for the site.

To summarise:

Computer > Lookup > Lookup gives IP > Computer sends request for site to IP.

But DNS records are cached, remember? So it’s actually:

Your computer checks it’s local cache to see if it has a “remembered” DNS records for the site.
If your computer does have a cached (remembered) DNS record for the site, it sends the request for the site to the IP address in the “remembered” DNS record. If your computer doesn’t have a cached (or “remembered”) DNS record for the site, it then…
Your computer looks up DNS records for a site.
An IP address is returned as a result of the lookup.
Your computer then sends the request to the IP address for the site.

To summarise:

Computer checks it’s cache for DNS record of site, and if there is one, sends request to site, if there’s not one > Lookup > Lookup gives IP > Computer sends request for site to IP

But where does it actually look things up? Step 3 can’t be that simple surely? You’re right, it’s not. Let’s go in to a bit more detail, adding the additional steps in to the above:

Your computer checks it’s local cache to see if it has a “remembered” DNS records for the site.
If your computer does have a cached (remembered) DNS record for the site, it sends the request for the site to the IP address in the “remembered” DNS record. If your computer doesn’t have a cached (or “remembered”) DNS record for the site, it then…
Your computer establishes the nameservers for the domain of the site.
Your computer asks the nameservers for the IP address of the site.
The nameservers reply with the IP address in the DNS record for the site.
Your computer then sends the request to the IP address for the site.

To summarise:

Computer checks it’s cache for DNS record of site, and if there is one, sends request to site, if there’s not one > Lookup > Lookup finds nameservers > Computer asks nameservers for IP of site > Nameservers give IP of site > Computer sends request for site to IP.

There, that wasn’t too bad was it? Now let’s add some steps in covering how your computer does step 3 above (establishes the nameservers for the domain). Here goes:

Your computer checks it’s local cache to see if it has a “remembered” DNS records for the site.
If your computer does have a cached (remembered) DNS record for the site, it sends the request for the site to the IP address in the “remembered” DNS record. If your computer doesn’t have a cached (or “remembered”) DNS record for the site, it then…
Your computer asks the root DNS servers who should be asked for the nameservers of the domain of the site.
The root DNS servers reply stating which top level domain servers (TLD DNS servers) should be asked to find this out.
Your computer asks those top level domain servers (TLD DNS servers) who should be asked for the nameservrs of the domain of the site.
The top level domain servers (TLD DNS servers) reply stating which central domain registry should be asked for the nameservers of the domain of the site.
Your computer asks the central registry for the domain of the site for the nameservers of the domain of the site.
The central registry replies giving the nameservers for domain of the site.
Your computer asks the nameservers for the IP address of the site.
The nameservers reply with the IP address in the DNS record for the site.
Your computer then sends the request to the IP address for the site.

To summarise:

Computer checks it’s cache for DNS record of site, and if there is one, sends request to site, if there’s not one > Lookup > Computer asks root nameservers what TLD DNS servers need to be asked to find out nameservers > Root DNS server states which domain registry should be asked for nameservers > Computer asks TLD DNS what servers need to be asked to find out nameservers > TLD DNS servers reply letting computer know what registry to ask for nameservers > Computer asks registry what nameservers are for the domain of the site > Registry replies with nameservers > Computer asks nameservers for the IP address of the site > Nameservers reply with IP address > Computer sends request for site to IP.

As you can see, there’s a lot of “where do I get this” from your computer and a lot of “ask them” replies back and forth between various servers. Well, I hate to break it to you, but there’s another step like this that I’ve left out (which takes place between steps 2 and steps 3) that involves what are called “recursive DNS servers”. These are DNS servers run by the people that provide your internet connection (your internet service provider, or ISP). These recursive DNS servers also, cache (or “remember”) DNS records.

It’s also the recursive DNS servers that get referred to all the other servers, rather than your computer doing the legwork as well, so they’re quite important.

Let’s add these in:

Your computer checks it’s local cache to see if it has a “remembered” DNS records for the site.
If your computer does have a cached (remembered) DNS record for the site, it sends the request for the site to the IP address in the “remembered” DNS record. If your computer doesn’t have a cached (or “remembered”) DNS record for the site, it then…
Your computer asks your ISP’s recursive DNS servers if they have a cached DNS record for the site. If they do, that give that back to your computer and your computer then requests the site from the IP address in the cached DNS record. If the recursive DNS servers don’t have a cached DNS record for the site, they then…
The recursive DNS servers ask the root DNS servers who should be asked for the nameservers of the domain of the site.
The root DNS servers reply stating which top level domain servers (TLD DNS servers) should be asked to find this out.
The recursive DNS servers ask those top level domain servers (TLD DNS servers) who should be asked for the nameservers of the domain of the site.
The top level domain servers (TLD DNS servers) reply stating which central domain registry should be asked for the nameservers of the domain of the site.
The recursive DNS servers ask the central registry (where the domain of the site is registered) for the nameservers of the domain of the site.
The central registry replies giving the nameservers for domain of the site.
The recursive DNS servers ask the nameservers for the IP address of the site.
The nameservers reply with the IP address in the DNS record for the site.
The recursive DNS servers cache (remember) the IP address of the site, then tell your computer the IP address of the site.
Your computer then also caches (remembers) the IP address of the site, then sends the request to the IP address for the site.

To summarise:

Computer checks it’s cache for DNS record of site, and if there is one, sends request to site, if there’s not one > Lookup > Computer asks ISPs recursive DNS servers if they have a cached record for the IP of the site, if they do, the reply with this and the computer requests the site from the IP, but if they don’t then let the computer know and then > Recursive DNS servers asks root nameservers what TLD DNS servers need to be asked to find out nameservers > Root DNS server states which domain registry should be asked for nameservers > Recursive DNS servers asks TLD DNS what servers need to be asked to find out nameservers > TLD DNS servers reply letting recursive DNS servers know what registry to ask for nameservers > Recursive DNS servers asks registry what nameservers are for the domain of the site > Registry replies with nameservers > Recursive DNS servers asks nameservers for the IP address of the site > Nameservers reply with IP address of the site> Recursive DNS servers lets computer know the IP address of the site > Computer sends request for site to IP.

OK, right. Quite a lot going on there isn’t there? It’s reading things like this that makes people think it’s difficult to understand DNS, so I’ll rephrase all of the above and write it like a conversation, using real life where I can:

You type www.someguycalledralph.co.uk in to your computer’s address bar and press return
Your computer checks it’s local DNS cache to see if it already knows the IP address for the www.someguycalledralph.co.uk site, if it does, it sends the request for the site to the IP address, but if it doesn’t…
Your computer asks your internet connection provider’s DNS servers they know the IP address of the www.someguycalledralph.co.uk site. If they do, it lets the computer know the IP address and your computer then sends the request for the site to this IP address. If your internet connection provider’s DNS servers don’t know the IP address they then ask the root DNS servers who it should ask to find out the IP address of the www.someguycalledralph.co.uk site.
The root DNS servers tell your internet service provider’s DNS servers to ask the DNS servers in charge of .co.uk, which it then does.
The DNS servers in charge of .co.uk tell your internet service provider’s DNS servers the nameservers held against the someguycalledralph.co.uk domain.
Your internet service provider’s DNS servers ask the nameservers what the IP address is for the someguycalledralph.co.uk site, which it tells them.
Your internet service provider’s DNS servers both remember the IP address given for the someguycalledralph.co.uk website, and lets your computer know what this is.
Your computer remembers the IP address and sends the request for the site to the server address.

As complicated as this sounds, all it really is is a referring scheme to find out where a site is:

Computer asks internet connection provider where someguycalledralph.co.uk is, they don’t know so they ask root DNS servers, root DNS servers state which TLD DNS servers should be asked about this, internet connection DNS servers ask the TLD DNS servers, TLD DNS servers give nameservers, internet connection DNS servers ask nameservers, nameservers give IP address, that gets given to your computer, your computer sends the request to the IP address for the someguycalledralph.co.uk site.

Or:

Computer > internet connection DNS servers > root DNS servers > TLD DNS servers > Nameservers > IP address > IP address given to internet connection DNS servers > internet connection DNS servers give IP address to computer.

From your perspective it’s good to know that all this is going on, but the only aspects you have any control over are:

The nameservers set against your domain
The authoritative namesevrers set in your domain’s DNS zone
The records in your DNS zone

Think of it like:

Registry holds domain registration, nameservers are set against domain at central registry
Nameservers give DNS records
Records dictate where requests are sent

I should have just said that, shouldn’t I? Well, maybe, but the reason I’ve gone in to all the detail is so that you know what’s going on, what’s asking what and what does the caching.

Now I’m going to add one last thing in to the mix, which are:

Authoritative nameservers.

Authoritative namesevers are nameservers defined in the DNS zone.

Yes, that’s right, 2 sets of nameservers.

You’ve got the nameservers held against the domain with the central registry, and the nameservers within the DNS zone.

The nameservers held with the central registry provide the DNS zone in which the authoritative nameservers are defined. The authoritative nameservers (which is as the name suggests are in charge) are the ones which gets asked for the DNS records of the site. So they control how DNS works for your domain.

You can see what I mean here:

https://intodns.com/someguycalledralph.co.uk

The nameservers in the “parent” section at the top are the namesevers held with the central registry.

The nameservers in the “NS” section are the authoritative nameservers. These are the ones that actually get asked for the DNS record of the site.

So there’s another step involved with that I’ve mentioned above.

So instead of:

Central registry asked for nameservers > Central registry gives nameservers > Computer asks nameservers for IP of the site > nameservers give IP > Computer looks up site

Its actually:

Central registry asked for nameservers > Central registry gives nameservers > Computer asks nameservers for authoritative nameservers > Nameservers give authoritative nameservers > Computer asks authoritative nameservers for the IP of the site > authoritative nameservers give IP > Computer looks up site

Generally speaking most hosting providers cover this for you automatically and by default. The reason I’m telling you this is because if you have OLD authoritative nameservers in place after moving a site, this can keep the site where you’ve moved from in effect, rather than the site where you’ve moved to.

Authoritative nameservers essentially control how DNS works for your domain.

DNS lookup tools.

These are good to check the DNS of your domain, but do be aware that these can cache DNS records, so if you’re checking for a recent DNS change, they might not show it.

https://intodns.com/ This shows a lot of the DNS zone for a domain, but not all of it. It will display nameservers, authoritative nameservers, MX records and site specific DNS records. This tool caches, be warned.
https://toolbox.googleapps.com/apps/dig/ This tool can be used to see individual DNS records in a zone. Dig is a linux/unix utility which is built in to Mac’s and Linux based systems by default. You can find the Linux dig manual here.
https://dnschecker.org/ This tool actually checks how DNS is propagating by querying lots of DNS servers, so it can be used to check if a recent change you’ve made is propagating, has propagated or is beginning to propagate. It’s very handy to check to see if DNS changes you’ve made are beginning to come in to effect.

How DNS Works and What it Does