DNS from Request to Resolution

October 20, 2018

I spent an afternoon configuring a private Burp Collaborator instance and realized that I did not understand DNS as well as I thought.

This post aims to remedy that. I’m going to start with a request to resolve a DNS record and end at the record arriving at the client.

A DNS Record

Let’s break down a random DNS record: blog.smallsec.ca.. We’ll start at the root and work our way back.

Zones vs. Domains

It’s important to understand the difference between zones and domains. A domain contains everything below it in the DNS hierarchy. The blog subdomain is a member of the ca domain, for example.

A zone is one level of the DNS hierarchy. The smallsec zone contains with a .smallsec.ca. attached to it, less any delegations. The ca zone does not contain blog, only a delegation for smallsec.ca..


Delegation is exactly what it sounds like. The DNS server is delegating the work to someone else to deal with. This apparent laziness is the foundation of the DNS name resolution process.

A delegation is a DNS server’s way of saying “I don’t know anything about that, talk to this server”.

Root Servers

DNS is hierarchical, which means there’s a top. At the top of the DNS hierarchy, or root, you can find the root nameservers.

The root zone, ., is often omitted from a DNS record, so you’ll just get blog.smallsec.ca. Some programs will add this if you forget, some require it.

The job of the root nameservers is to delegate control of top-level domains to other name servers.

When the root nameservers receive a request for blog.smallsec.ca. they’ll search their zone. After not finding what they’re looking for, they’ll search for delegations for the ca zone and return the list of nameservers responsible for it:

ca.                     172800  IN      NS      any.ca-servers.ca.
ca.                     172800  IN      NS      j.ca-servers.ca.
ca.                     172800  IN      NS      c.ca-servers.ca.
ca.                     172800  IN      NS      x.ca-servers.ca.

Top-Level Domains

A top-level domain is the bit of a DNS record preceeding the (sometimes implicit) .. There are many top-level domains.

The top-level nameservers are owned by organizations. CIRA owns and maintains the .ca. zone. When smallsec.ca was registered, the registrar, or domain vendor, pays a fee for the domain and an annual maintenance fee to keep the lights on.

When the ca nameserver receives the query for blog.smallsec.ca. it will find the delegation for the smallsec.ca domain and return the nameservers authoritative for the zone:

smallsec.ca.            86400   IN      NS      sam.ns.cloudflare.com.
smallsec.ca.            86400   IN      NS      dora.ns.cloudflare.com.


Now we arrive at the area of DNS most people are familiar with. The domain we’ve registered that we fill with records. This blog lives on the smallsec domain. The fully-qualified domain name is blog.smallsec.ca..

Record Types

At first glance, blog.smallsec.ca seems to be pretty descriptive. It’s telling us to find the host under smallsec.ca that has the record blog. Or is it?

There are many types of DNS records. Here are a few of them:

Seems pretty straightforward, so where’s the nuance? The nuance is that blog could actually define a subdomain of smallsec, rather than just where this blog lives. Then we could have a.blog.smallsec.ca. If this were the case, you’d see an NS record for blog.smallsec.ca pointing to the nameservers authoritative for the subdomain.

Authoritative vs Recursive Nameservers

There are two types of nameserver: authoritative and recursive.

An authoritative nameserver will only return records from its own zone file. If the root-level DNS servers were authoritative, DNS as we know it would cease to work.

When processing a request for which it does not have a record, a recursive server will walk through the process listed above until it’s exhausted all possibilities or found an answer.

Using DIG

We can watch the above process happen using dig +trace blog.smallsec.ca:

# Get list of nameservers responsible for ca.
[email protected]$ dig +trace blog.smallsec.ca.

# Start at the top!
.                       83762   IN      NS      f.root-servers.net.
.                       83762   IN      NS      b.root-servers.net.
.                       83762   IN      NS      a.root-servers.net.
.                       83762   IN      NS      e.root-servers.net.
.                       83762   IN      NS      l.root-servers.net.
.                       83762   IN      NS      d.root-servers.net.
.                       83762   IN      NS      h.root-servers.net.
.                       83762   IN      NS      i.root-servers.net.
.                       83762   IN      NS      k.root-servers.net.
.                       83762   IN      NS      c.root-servers.net.
.                       83762   IN      NS      j.root-servers.net.
.                       83762   IN      NS      m.root-servers.net.
.                       83762   IN      NS      g.root-servers.net.


# Get the servers responsible for ca
ca.                     68536   IN      NS      j.ca-servers.ca.
ca.                     68536   IN      NS      any.ca-servers.ca.
ca.                     68536   IN      NS      x.ca-servers.ca.
ca.                     68536   IN      NS      c.ca-servers.ca.


# Get list of nameservers responsible for smallsec.ca.
smallsec.ca.            86400   IN      NS      dora.ns.cloudflare.com.
smallsec.ca.            86400   IN      NS      sam.ns.cloudflare.com.

# Sam and Dora are authoritative for smallsec.ca, so now we get an answer
blog.smallsec.ca.       300     IN      A
blog.smallsec.ca.       300     IN      A