Skip to content

Ivan Li

Domain Name System

6 min read

The Domain Name System is a distributed database that stores IP addresses and other related data to enable queries over the internet to be resolved to the appropriate destinations. A common analogy is that the DNS is an indexed directory (like a phonebook) of human readable & memorable names which can be used in place of web server IP addresses. The DNS directories are distributed/updated all over the world so that anyone connected to the internet can have domain names properly resolve to their respective IP addresses.

Let’s take a simple journey through tracing what occurs when we type www.google.com into our browser for a better understanding of the DNS.

In order to save time on network calls and to speed up the DNS resolution overall, there is usually caching implemented on multiple levels of the system.

When we type in www.google.com, the first place our browser might look is in the built-in browser or operating system DNS cache to check if you have recently accessed google.com. If you have, it will immediately resolve it to 172.217.6.206 and attempt to reach that server with a request. But for the sake of this adventure, we will pretend all caches are empty.

What should happen next is your browser will send out a query to the default DNS recursive resolver to recursively retrieve the IP address for the request. You can think of the DNS resolver as an assistant that takes your request and goes door to door (in an efficient manner) to search for the matching IP address.

Your loyal DNS resolver usually defaults to the one that is provided by your ISP. It works quite well but there are public alternatives provided by big tech companies like Google and Cloudflare such as 1.1.1.1 and 8.8.8.8. We’ll revisit this option at the end.

Before diving into more detail; take a moment to check out this very high level diagram of the ordered steps that the DNS resolver generally takes (trace the flow of the numbers):

DNS Diagram

In step 1 we don’t see the home network router or modem being accessed before getting to the ISP resolver but some local network devices are also places where a DNS response can potentially be cached. There is also caching done server side at each layer of the DNS; that is related to the ability to set a TTL on the DNS records (to be explored in another post)

From steps 2 to 7, the resolver goes to each name server starting from the top “root” level and retrieves a piece of information from each in order to get to the next level down. Instead of housing all the information in one giant server, each piece of the domain name is broken down into sections that are stored on separate layers. This is partially why the DNS is called a distributed database. There also isn’t actually just one Root server or one TLD server but hundreds/thousands of replication servers spanning the globe serving the same information per level for low latency and high redundancy.

You can also think of the DNS servers as an N-ary tree that has each level representing a piece of the domain name starting from Right to Left: { www.google } { .com } { . }. Note that there is actually a . representing the “root” sitting at the end of every domain name which is hidden in most client browsers and user interfaces.

I like to imagine that each server “level” represents an index similar to that of a science textbook but each index page actually references another book that becomes more and more specific to our request until the final book returns to us the exact IP address that our domain translates to.

The Root Name Server is the literal root of the “tree” when resolving a domain name. It stores all the locations for the TLD (Top Level Domain servers) and directs you to one based on the letters provided at the end of a name (in our example it is obviously .com).

The TLD server that we end up hitting would then be responsible for directing us to an authoritative name server that houses our requested domain name: www.google.com. Since this is a Google owned and operated domain, the TLD server will respond with Google’s own authoritative name servers: ns1.google.com., ns2…, ns3…, ns4….

Authoritative name servers are the last place that a resolver looks before finding the desired IP address. These servers are generally packaged together with domain name registrars. If you register a domain name using GoDaddy or Namecheap for instance, the name servers will be different than Google's. You can of course also opt out of your domain name registrars included name server and use an alternative or even create/host your own if you want total control: How To Configure an Authoritative-Only DNS Server.

A useful tool to look into how a DNS resolver travels from the root all the way down to the authoritative name servers is with the “dig” utility found in most UNIX systems: dig +trace www.google.com. Try querying another domain name with dig such as www.microsoft.com to find authoritative name servers that differ from Google’s.

Finally, with step 8, the DNS resolver returns the result to our browser, the full “DNS lookup” cycle is complete. Steps 9 and 10 are technically not part of the DNS resolution. Those steps are when the client actually begins to connect to the requested server and start the SSL/TLS security handshake along with the fetching of application data (to be explored in a future post).

It might have seemed like a lot went on from step 1 all the way to step 8 but it all usually happens in less than 100 milliseconds for fast connections (and even faster if cached at any intermediate point). The global DNS is a truly robust and resilient system that we owe the collaborative efforts of many developers, regulators and maintainers for having it properly put together and running on such a grand scale.


How do we use a different DNS resolver than the one our ISP provides?

If you are on a Mac, simply open up your Network settings panel and click ‘Advanced’ on the bottom right. Next, click on the DNS tab and on the left hand side that says ‘DNS Servers’, press the + button on the bottom left to add your desired alternative resolver address (you can use for example 1.1.1.1 by Cloudflare). Return to the previous screen and hit Apply to have the changes saved.

Your device should now be using the Cloudflare DNS resolver system wide for every external network lookup. To verify that this is indeed working, you can use this tool: DNS leak test. Click on ‘Standard Test’ and the results should say that your ISP is now ‘Cloudflare’ … go back into your Network settings and delete the DNS resolver entry that we added before and re-run this test to see what it says. An alternative to using that website tool is to run the dig command in terminal (with no args) and observing a line near the end to say which server is being used for the lookup:

1dig
2
3;; Query time: 12 msec
4;; SERVER: 1.1.1.1#53(1.1.1.1)
5;; WHEN: Wed Apr 10 13:21:22 EDT 2020
6;; MSG SIZE rcvd: 239

Why would someone bother using an alternative DNS resolver?

Usually there isn’t really ever a need to tinker with this as well, obviously you have been using the internet just fine your entire life without touching this. Google / Cloudflare claims in their documentation that their particular public DNS service offerings will allow your cat picture consuming sessions to be both Faster and more Secure. By faster, they generally mean that they have better caching mechanisms and more machines in place than your average ISP DNS setup does and that will result in faster domain name resolutions.

By more secure, these companies claim that they have implemented defenses against hackers that attempt to mess with your DNS by overloading it, or by modifying the resolved domain of your cat pictures to point to an IP address that has dog pictures instead. Read more about DNS attacks here: The Most Popular Types of DNS Attacks. Your average ISP resolver is probably not as well designed or strictly audited than the ones offered by Google / Cloudflare / Whatever Big Tech Company.

In relation to security, Cloudflare also claims to enable users to enjoy more privacy if you use their DNS resolver because they promise to never log, track or sell your personal data … while your ISP might.

Another application of using (or forcing the use of) another DNS is to block/filter certain IPs out from being accessible from a client device. Some strictly theoretical examples:

  1. I am an evil corporate overlord and I don’t want people to browse reddit.com - I can block reddit’s addresses from being resolvable by forcing a custom DNS to be deployed on all company devices.
  2. I am an evil authoritarian government and want to block my citizens from accessing “sensitive” data, so I take control of all available resolvers at the ISP level to censor things at will.
  3. I want to block all known phishing/scam/dangerous/advertisement sources - Pi-hole or How to set up AdGuard DNS
  4. I am using a modified Nintendo Switch to load home-brew applications but I would also like to go online on my console without Nintendo detecting my modified software and banning my account. The solution? We use a custom DNS that blocks resolution of all known Nintendo server IP addresses. Ave / 90dns · GitLab

Resources:

A better DNS overview: What Is DNS? | How DNS Works | Cloudflare

Common DNS Attacks: The Most Popular Types of DNS Attacks

Good overall article describing DNS over HTTPS: A cartoon intro to DNS over HTTPS - Mozilla Hacks - the Web developer blog

Fire up your own authoritative name server: Configure-bind-as-an-authoritative-only-dns-server

Diagram tool: Excalidraw | Hand-drawn look & feel • Collaborative • Secure