Domain Name System explained

What is DNS? Let’s say that you are new to web development, you learned JS, HTML and CSS and once you are looking to deploy your website, comes the DNS issues. In this article I explain how DNS works and give some tips for debugging, all through the lens of a single static website deployment on AWS.

Following the various DM’s I received urging me to make recommendations on what films to see in cinemas, I decided to create a website to respond to requests.

This very complex website would contain a wheel that would indicate whether the film was recommended.

Once it was running locally, the question arose of making it available on the internet for my followers to enjoy. AWS being the leader in this field, I turned to their various services:

• I bought a domain name on route53.

aws route53domains register-domain --cli-input-json ~/register-should-you-watch.json

(A JSON example can be found here)

• I added my files to a publicly accessible S3 bucket named after my domain name.

I typed the URL in my favorite browser and oh dear: no website.

My mental model was not correct. My S3 bucket is stored on a server that is identifiable by an IP address (something like 108.138.217.100). So to contact it and retrieve the files, we need its IP address. But I only provided a domain name (should-you-watch.com). How can I translate it to an IP address?

This is the responsibility of the Domain Name System: to convert human-memorizable domain names into IP addresses.

The DNS servers store the domain address information and return the IP address of domains like should-you-watch.com. The OS and the browser will both cache the result.

Ok but how do they work ?

1. There are actually two types of DNS servers :

   • recursive resolvers don’t contain any domain information. They are responsible of finding the IP addresses. Resolvers are typically managed by internet service providers or by public resolvers like Google and Cloudfare.
   • authoritative nameservers contain DNS records which are instructions that provide information about a domain. These are structured as a tree with 3 main levels:

     • should-you-watch.com nameserver - contains info of all subdomains of should-you-watch.com. Managed by me and AWS.

     • Top Level Domain aka TLD nameservers - contains info of all domains under the last element of the domain name e.g. .com or .gov. Managed by the various organisations that register domain names (Verisign for .com, Afnic for .fr).

     • root nameservers - contains info of TLD servers. Managed by ICANN and by delegation IANA.

       

2. There exists many types of DNS records. Below you have the most well known type of record. An A record returns an IPv4 address.

All types contain 5 parts, type, name (domain or subdomain name), value, class and TTL (time to live: caching time). Others well known types are:

• AAAA record: returns an IPv6 address.

• NS record : indicates which DNS server is authoritative for that domain (the ones we mentioned above).

  

• CNAME record : redirects to another domain (only allowed on subdomains)

  • Example: www.should-you-watch.com CNAME should-you-watch.com

• SOA record : contains admin info about a domain.

• MX record : tells you the email server for a domain.

Ok then. What happens when I type my URL in my browser ?

My browser asks my OS which asks the resolver for the IP address and then, if none had cached a previously response :

1. The resolver makes a DNS request to a root nameserver. It can do that because all resolvers have the 13 IP addresses of the root nameservers hardcoded.
2. This root nameserver will respond with what is called a DNS record with type NS which allows me to contact another nameserver.
3. The contacted nameserver is, if you followed correctly, a TLD.
4. The TLD nameserver will also respond with an NS record and only the AWS nameserver will be able to respond with a DNS record with type A containing the fateful and much desired IP address of my website.

If we focus on my original problem, it seems it was missing some A record. Indeed I have only 4 NS records (4 values = 4 records) and 1 SOA record in my hosted DNS zone.

There are 4 NS records in order to increase reliability. If one of these servers fails or is unavailable, DNS queries can be passed to another server. There is usually one main nameserver and several secondary nameservers, which store exact copies of the DNS records of the main server.

I create an A record that will point to the S3 bucket. Amazon Route 53 provides Alias records to route traffic to selected AWS resources. When Route 53 receives a DNS query for an alias record, it responds with the applicable value for that resource and in my case with the IP address.

Let’s add a CNAME record to redirect subdomain www and voilà.

Now, I can retrieve these info with host, dig and nslookup commands! These 3 commands allow you to perform DNS queries, there are some differences which are detailed here.

+noall hides output while +answer only displays the answer section. You can find more with this complete guide.

That’s it 🎉 Let’s go on should-you-watch.com!

This is not good. What’s going on ?

Is it the cache ? Maybe when I went on the website before buying my domain name, my resolver cached the fact that there was no nameserver associated with this domain name.

Let’s prove it by getting the IP address from my resolver and doing a DNS query on should-you-watch.com. Two things strike me: it’s not the AWS nameserver and it’s an SOA record (remember, the ones containing metadata). My hunch is that it’s the nameserver of a top level domain .com.

Indeed we can find it below.

So if my resolver cached the wrong info, I should be able to ask another resolver, one that did not cached the info.

Above, we can see that the CloudFare resolver found an A record. So my hypothesis was right! The DNS query made by my browser was negative and negative answers always contain SOA records.

On the screenshot above, we can see that the SOA record has a caching TTL of 900s for negative responses (retry part in the response), so for 15min my resolver will cache the “no domain” response.

I can either wait, change my resolver as shown below or clear the DNS cache on my macOS Ventura : sudo killall -HUP mDNSResponder.

That’s it, my website is now available for my followers: https://should-you-watch.com. It is a real relief. Next step : a better SEO.

Fun facts

By digging into the understanding of DNS, one can quickly discover the many existing attacks: Distributed Denial of Service (Dyn in 2016), DNS cache poisoning and spoofing, DNS hijacking (.lk registry in 2021) or even DNS tunneling. I strongly encourage you to find out more.

To conclude

I hope this has helped you understand how DNS works and how to react when confronted with a DNS error.