DNS from Request to Resolution
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.
.- The root zone.
ca- The ca top-level zone.
smallsec- The smallsec zone in the ca zone.
blog- The blog subdomain of the smallsec zone.
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
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".
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:
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.
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:
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
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:
- NS - Define the name servers for a domain.
- A and AAAA - Define hosts in a domain
- CNAME - An alias that points to a host record.
- MX - Define a mail server for the domain.
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.
We can watch the above process happen using
dig +trace blog.smallsec.ca: