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 smallsec.ca.
.
Delegations
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:
|
|
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:
|
|
Domain
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:
- 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.
Using DIG
We can watch the above process happen using dig +trace blog.smallsec.ca
:
|
|