DNS Explained - How Your Browser Finds Websites

So, for those of us who work, play, and communicate over the Internet, we all hear the term "DNS" at least occasionally, if not often. DNS is an acronym that stands for "Domain Name System". DNS is the cornerstone of the Internet - it is how we navigate from site to site.

So, when I type www.example.com into my browser window (I happen to use Chrome) and hit enter, it magically loads a website, right? No? OK. So it turns out that the process of acquiring the IP address that we need in order to actually load a website is a long and somewhat convoluted one. Let's take a look.

So first, how does one even locate a computer or server on the Internet? A hosting server, just like any other computer that's connected to the Internet, has what is called an "IP Address". An IP address (using the current addressing system, called "IPv4") is a sequence of four sets of numbers separated by dots such as 111.222.333.444. The address is completely unique to that computer - none other on the Internet should have the same address. Unlike our home Internet connections, which sometimes change to new IP addresses when our equipment is restarted, or after a certain length of time, IP addresses of web servers are usually "static" - they never change. In short, the IP address is a unique set of numbers that allow the computer to be found among all of the other devices connected to the Internet.

Awesome, back to our attempt to retrieve and load a website. The first thing that happens when we type in the domain name that you wish to visit into your browser window is a check of your browser's local cache. If your browser has already been to this website recently, it may already know what the IP address for the website in question is, and have that value cached. Browser caches don't usually last long, so it would've been a recent visit. If it doesn't have the information in its cache, it will then also check our computer's DNS cache. This operates in much the same way - if the computer has been used to visit the website recently, it saves the IP address for as long as it has been instructed to do so - this is the "Time to Live" setting, which we'll come back to later.

If either of our local caches, the one in our browser or the one the computer retains, already had the IP address of our website stored, then we've already reached the end of the first part of the process of loading our website - we've acquired the IP address. Part two, of course, is then sending a request to that IP address in order to actually load the website in question! This all happens in milliseconds, unbeknownst to us, the users, and we continue browsing. End of story!

If, though, our browser can't find the IP address that it is looking for locally, it has to reach out and contact its recursive DNS server.

"Recursive DNS servers" is a mouthful; what does that mean? These are most often one or more DNS servers which are located at our Internet Service Provider, or ISP (the company that is selling us Internet service). Our ISP automatically assigns us their default DNS servers while we are on our Internet connection. We never even have to know or care about it! Some users change these settings, which we'll talk more about in the details section later in the article.

When our system is not capable of finding the DNS records for the domain that it seeks in its local cache, it next checks with the recursive DNS servers. If those servers already have the IP address we're looking for in their cache (which would mean that someone else - another customer, probably - using these DNS servers has visited this site recently, and the information got saved there for later use, which is handy for us right now) then we're done! The information is returned to our operating system and then our browser, and we send our request to that IP address to load the website, and off we go.

If the recursive servers didn't have have the records we are looking for in their cache, then what is next? Our request is about to get bounced around a variety of computers (servers) so that it can get to a server that can tell it what we want to know. So, hang on.

First, our request now travels to what are called the "root name servers". The root name servers serve as a type of gatekeeper, controlling access to the next layer of DNS servers. All they do is locate an appropriate server for our request to go to next. The root name servers are dispersed around the world, and controlled by several separate organizations. The reason for this is to ensure that they won't all be taken out of commission by a single disaster or failure!

The root name servers redirect our request to the name servers for our requested top-level domain (TLD).

Each domain ending like .com or .org has its own name servers that can help us out. We'll have been passed off to one of those by the root DNS servers, and they can help us out because they know the location of the "golden ticket" - they know where the server is that is holding the information we seek! They will pass our request on to the next, final step in line - the Authoritative DNS Servers for our domain.

There used to be only a handful of top-level domains (TLD) like .com and .org and .net but now there are many, many more like .online and .rocks and .careers. Every TLD has its own name servers that can help us out. That is why we needed the Root DNS Servers above - there are so many domain extensions, with more being added all the time, our poor computer would have no idea how to find out about them. So the Root DNS server can tell us where our extension's servers are, and then we head here to find out where to go next. In our case, if we are trying to find www.example.com, the .com name servers will be the ones we need to direct us to the next step. The .com name servers will now tell us where to find the authoritative name servers for our specific domain.

The domain name's authoritative name servers are the place responsible for delivering information about our domain to the rest of the Internet. The chase ends here.

When you first register your domain, your registrar often provides this service for you automatically. They've got a set of servers which will be responsible for keeping track of your DNS records, and providing those records to any requests that come their way - like the one we are making right now. If you set up hosting for your website, the host may ask you to instead switch over and use their name servers for this task, which you will then continue to do as long as you're hosting your site with them. Most often, this is the only time you would change your authoritative DNS servers - when selecting, or switching, hosting providers or domain registrars.

In any case, now we are here, at the authoritative DNS servers, and we ask them for the A Record for the domain that we typed in. It delivers us the record, which consists of an IP address for the server our website is hosted on. This is what we've been looking for! This information, in most cases, is then cached (stored for later use) by our recursive DNS service that we talked about earlier, and then also cached by our own computer. These caching steps will make a return trip to this website a bit shorter - sometimes imperceptibly, but sometimes a noticeable amount.

OK! We're done, and our website is now loading (unless the website itself has errors, or the hosting service, but let's leave that for another day, shall we?). So, let's do a quick overview of what the process was:

  • We type in a domain name (www.example.com) into our browser.
  • The browser checks its cache and the computer's cache for the DNS records for that match the domain name we entered. If it succeeds, it requests the page from the website's host.
  • If we haven't found our record yet, our request goes to our Recursive DNS Servers that we have set for our computer or network (probably our ISP). If they have the record cached, we take the results from them and try to load the page (and we also cache it locally for later use).
  • If we still haven't found it, we go to the Root DNS Servers, and ask them where to find the correct Top Level DNS Servers for the .com TLD.
  • We arrive at the .com Top Level DNS Servers, who have one nugget of information for us - they are kept up to date on which Authoritative Name Servers are responsible for example.com and they share that information with us.
  • Then, we head over to the Authoritative Name Servers, who give us the record we're looking for.
  • Finally, the result is cached by the recursive DNS servers, and by our local system - and we load our page!

So now that we know how the DNS request process works, what about setting up DNS records for your own domains? DNS Records are a set of information, primarily IP addresses. These records indicate various things about our domain - where to go when we type in the domain name (example.com), or www.example.com, where to go when other subdomains (employees.example.com) are used, and how to handle email for our domain, among other things.

We edit these records, usually, on our domain registrar or our website host's control panels. The records themselves live on the above mentioned "Authoritative Name Servers", and are primarily made up of locations (IP addresses and domain names) and time to live numbers (discussed more below). Some direct people to our website, some direct them to subdomains, or different areas of the site, or different related sites. Some exist for the direction of email, and some for other purposes altogether. Let's dig in a bit and take a look at a few.

There are two big components we see in DNS records - hostnames and time to live numbers.

Hostnames, in this context, are really just referring to the specific place you're wanting to go. With our illustration, if there was a site called example.com, being entered without any www. or anything else in front of it, we would use the symbol @, when editing a domain record, to indicate that we're referring to the "naked domain" - without anything prefixed ot it. We can also enter a record for the hostname www.example.com as well as employees.example.com, if we are editing the records for Example.com. These are all separate hostnames, and, with their own DNS records, can point to different hosting servers or computers, if we wish them to, or even to other websites entirely.

DNS records have a "TTL" or time to live setting. This is simply an amount of time that the name servers will allow records to be cached by any of the computers who might store the information about that specific domain and hostname before that cached data must be discarded and reacquired. A low TTL means that your visitors will need to reacquire the DNS information more often, resulting in slower loads, possibly, but with always current DNS information. Longer times mean that changes to DNS may not be reflected to visitors right away, but their average load times will be a little faster.

So why is this important to us? Say that we want to move our site example.com from one host to another, but we'd like it if the change happened immediately for all users. The problem is, of course, that we've spent this whole article referring to people's browsers, computers, internet providers, and all sorts of other computers caching records about where to find a particular website. If we move our website to a new server, and update our DNS records to reflect that move - how long will it be before our visitors' computers need to check for the records again and find the new site? What if we have visitors viewing the old site? Or what if we had to take the old site down?

Enter Time to Live (TTL) settings. Before making a DNS change, if we know ahead of time, we can change our TTL to something very small - measuring in minutes instead of hours. Then, give it some time to propogate around to all of our visitors, and when we make our change, they'll be checking back very often to grab the newest dns records, and shortly after we change them, people will have that change. Then, we can raise the TTL back up, to avoid people having to send those requests down the chain so often!

Let's now dive into the specific kinds of DNS records that you may encounter, or have to change for your own websites.

A records are the heart of DNS. An A Record is (more often than not) the type of record that tells an incoming request where to find the website they are looking for. One component An A Record for a domain stores an IP address for a specific hostname, such as:

  • @ (no hostname, just the domain example.com
  • www (www.example.com)
  • employees (employees.example.com) Note that sometimes, people redirect either their naked domain (@) or their www hostname to the other, using a CNAME record (discussed below). Sometimes, they leave both as A records and deal with the redirecting on their web server. In any case, you should definitely have both records, it's just a question of what you do with them.

A CNAME record (Canonical Name Record) is pretty straightforward, as well. You provide another domain name as the value of this record, and the domain name lookup process will simply continue with the new domain name. An example: If we used employees.example.com as our employee site address, and decided to alter its address, we might use a CNAME record to redirect it, and so the CNAME would have host: employees.example.com and its value would be example.com to redirect to example.com.

Why would we want to use CNAME records to redirect a hostname to another? Some people use them to redirect www. traffic to a "naked domain". Others use it to redirect the "naked domain" (@) to a www. hostname. There are also situations where we've been using a URL like employees.example.com - but now we want it to go somewhere else, without setting up a redirect on our hosting server (because we don't want to, or can't). We can easily do that with a CNAME.

MX records help mail requests to a domain find the correct mail transfer agents that are available for it. Registrars that provide free mail forwarding set this process up for you, and likewise if you buy email from your registrar, it should be set up for you. If you self host your email, or use an external service (Like Google Apps or Office 365), you may have to set up your own MX records. MX records identify the servers (mail servers) that you will use to process your mail. Sometimes there are multiple servers listed. The trick with email is that sometimes, you only get one chance to receive an email. A visitor to your webpage who has a minor connection issue can, if they choose, refresh the page or come back again later. Email might bounce and never return if a server has an issue - so there can be more than one.

Email servers can exist on the same hosting service that you have for your website, or they can be through a whole other company, as stated above. If you were to switch to Google Apps, for instance, you might end up with MX records that look like this:

Priority    Mail Server

There are other types of DNS records, but these are the ones that seem to be encountered most often in the wild. There is a relatively complete listing at this Wikipedia page on Top Level Domains.

Due to a want for greater speed or more reliability, some people change the DNS servers (meaning the recursive DNS servers discussed above) that are assigned to their computer (remember, by default, this is usually our ISP's DNS servers, as discussed above), or to their router if they have one (which sets DNS servers for all of the computers on the router's network). We could then choose a third party such as Google Public DNS or OpenDNS instead of using our ISP's DNS servers.

Once we make that change, now, when our browser and our computer cannot find a record, instead of reaching out to the recursive DNS servers owner by our Internet provider, they will instead reach out to Google's Public DNS servers (which are the exact same type of "recursive DNS server" - just owned and operated by Google rather than by our ISP). Making this happen is a matter of logging into our router and swapping the numbers around. But most of the time, people just stick with their Internet provider, for simplicity's sake - or because they don't know there are sometimes faster or better options out there.

And that's our overview of the process and of DNS records themselves. Of course, the Internet and DNS resolution is a very muddled thing, and sure to change with the onset of IPv6, which is slowly going to be replacing IPv4 - or even with the onset of new, HTTP replacing ideas like IPFS.

But for now, this is the process, and this was a summarized explanation of how DNS really works.


What did you think of the article? Let us know!
(these comments are powered by GitHub issues and use 0 trackers)