Nandan Desai: Understanding DNS

(The diagrams in this article are created by Nandan Desai except for the ones that are credited to others.)

The Domain Name System was developed to organize and find the IP addresses of computers on a large distributed networks.

Before the domain name system was developed, the computer names and IP addresses were mapped in a simple text file called the hosts file. This file was maintained separately by each user on their own computer. So every computer had it's own version of the hosts file.

As the network size increased, the hosts file approach became impractical. To overcome the limitations of maintaining a hosts file, the Domain Name System (DNS) was developed.

DNS provides a way to organize the computer names and it's called the Domain Namespace or Domain Name Structure.

DNS also provides protocols, services and methods for storing, updating and retrieving the names and IP addresses for computers and it's called the DNS "system" .

From the perspective of the end user, we can consider the DNS as a structured hosts file.

(Point to be noted here: hosts file is still being used on many Operating Systems and the users can define the host names and IP addresses in that file for their own local use.)

The main criteria that were considered while developing the Domain Name System are:

The system needs to be expandable.
It needed to be distributed.
It needed to be resilient. (If one server goes down, there had to be a backup server)
It needed to have delegated authority.( An authority should be able to delegate authority to others in order to manage a massive pool of computer names.)

DNS system acts as a distributed database that resides on multiple servers which are configured to serve DNS requests. The job of these servers is to resolve computer names to IP addresses.

The process of translating user-friendly computer names into IP addresses is called a Resolution.

distributed database

Let's take an example of a PC (DNS client) looking for the IP address of a host name.

DNS clients run something called as a Resolver. This is an application usually built into the Operating System. And it's job is to query the DNS server. The Resolver sends a query to the DNS server to resolve a computer name/host name to an IP address. This is the most common type of DNS request and it's called as a Forward Lookup.

A 'Forward Lookup' resolves a computer name/host name to an IP address.

forward lookup

It's also possible to do a Reverse Lookup. A 'Reverse Lookup' does the exact opposite of the Forward Lookup query. It resolves an IP address to a host name. A DNS Server needs to be configured to allow Reverse Lookups. It is not configured by default.

reverse lookup

Both of these examples of lookup queries are very simplified. Before we take a closer look at how the DNS Resolution works, we need to talk about the Domain Namespace.

Domain Namespace (also known as Domain Name Structure)

The Domain Namespace (or Domain Name Structure) is a naming scheme that is organized into a tree-like hierarchy. Let's take a look at the example cred.club. (https://cred.club). This is called as a Fully Qualified Domain Name (FQDN). A Fully Qualified Domain Name gives the exact location within the tree structure. Each level in the domain tree structure is separated by a period (.). It's very similar to specifying a path to a file in a file system. But the important thing to know here is, the domain names are resolved from right to left.

Let's take a look at the cred.club. domain name again. The full stop(.) after the .club refers to the root domain. Root domain is at the very top of the tree and it is represented by a (.). It is at the highest level of the domain hierarchy. This final full stop(.) isn't something we need to type when we enter a domain name into our web browser. It's being taken care for us but we can type it if we wish and it's perfectly fine.

After the root domain, we have the Top Level Domains. This level in the hierarchy indicates the type of organization the domain name belongs to. For example, .org belongs to an organization, .gov belongs to the government, .mil belongs to the military, .com is commercial and .club belongs to a club. Top Level Domains may also be based on geographical location as well. For example, .in for India, .ca for Canada, .co.uk for the UK etc.

domain name space

After the Top Level Domains, we have the Second Level Domains, which are registered for individuals or various organizations. In our example, .cred belongs to the company called CRED.

After Second Level Domains, we have Sub Domains. For example, blog.cred.club. has blog as the Sub Domain of cred.club..

After the Sub Domains, we can have Hosts. For example, host1.blog.cred.club can be a Fully Qualified Domain Name for a server hosting the blog. Of course, that's not a real domain name but it's possible for CRED to have a server hosting a blog with that host name.

Domain-namespace

It's important to understand how a Fully Qualified Domain Name is structured because this same hierarchy is used by DNS to resolve a Fully Qualified Domain Name.

Domain Name Resolution Process

When a web browser wants to get the IP address of a domain name, it asks the Resolver service of the Operating System.

The resolver service first checks the hosts file on the local file system of the client. All the local hostnames (including the "localhost" to "127.0.0.1" translation) are mentioned in this file.

If the resolver doesn't find the translation in this file, it checks it's local cache. If there are no entries related to the request in the resolver's cache, it goes to the DNS server of the local network (or whichever DNS server is mentioned in the Resolver service's configuration. This can be a local DNS server, Google's 8.8.8.8 server, Cloudflare's 1.1.1.1 etc.). The local DNS server (or the 8.8.8.8 server) checks if it has any entries related to the request in it's cache. If not, then it goes to the Root name servers!

Root name servers keep a record of all Top Level Domain (TLD) nameservers. And they respond to the local DNS server with a list of nameservers who have authority over that Top Level Domain.

Before we move further, we need to be aware of a few definitions here.

Nameserver: A server having a database (not cache, but a database) of DNS records is called a Nameserver. These records are called Resource Records (RRs). Authoritative Nameserver: A nameserver which can respond to the query on it's own from it's own records (not cached records, but DNS database records) is called as an Authoritative Nameserver. If it's able to respond from it's own database records, then that means it has authority over that domain.

After receiving a list of TLD nameservers from the root nameserver, the local DNS server makes a request to the TLD nameserver regarding it's query for the IP address of a domain name.

If the TLD nameservers have the answer, they respond with the IP address. Or else, they will respond with another list of Second Level Domain nameservers. The local DNS server can finally ask these Second Level Domain nameservers for it's request.

If the Second Level Domain nameservers have the authority over the queried domain name, then they will respond with the IP address, or they will again "redirect" the local DNS server to other nameservers who have the authority over the requested domain name.

The diagram below shows how the resolution works if we want to visit cred.club domain name.

dns resolution process

In the above example, the root nameserver responds with the nameservers who have authority over .club Top Level Domain.

The TLD nameservers respond with Authoritative nameservers for cred.club.

The cred.club Authoritative nameservers finally respond with the IP address for the cred.club domain.

The local DNS server responds back the the Operating System's Resolver service with the IP address of cred.club and then the browser can send whatever packets (HTTP requests) it wants to that IP address!

It's as if the local DNS server is traversing a tree data structure from top to bottom (from root nameserver to the cred.club authoritative nameserver).

That's how the DNS resolution works!

In our example, the local DNS server was making DNS requests on behalf of the Resolver service. This type of query is called as a Recursive query of the local DNS server. Here the local DNS server is not making DNS requests for itself but it's doing it for the Resolver service. Hence it's making a Recursive query. The servers making such recursive DNS queries are sometimes referred to as recursive DNS servers. Google's 8.8.8.8 Public DNS server and Cloudflare's 1.1.1.1 Public DNS servers are all recursive DNS servers. When we issue a DNS query to these servers and if they don't know the answer, they query root nameservers, TLD nameservers etc. on our behalf and simply give us the IP address at the end.

There are two switches within the DNS message header called RD (Recursion Desired) and RA (Recursion Available). When we send a DNS message to a DNS server with RD bit set, then we're indicating to the server to just give us the IP address directly by doing a recursive query to other DNS servers as required. If that DNS server supports recursive queries, then it does all the other requests on our behalf and gives us the IP address at the end. And the response packet will have RA bit set, which means, the server is telling us that the recursion feature is available on that server and it just made a few recursive requests to get us the IP address for the domain name we had requested.

If the Resolver service makes the DNS requests to the root nameservers directly and "walks down the tree" on its own, then that will be an Iterative query.

DNS Message Structure

The DNS protocol uses a common message format for all exchanges between client and server or between the servers.

Identification	Control
Question count	Answer count
Authority count	Additional count
Question
...
Answer
...
Authority
...
Additional
...

The Identification field contains a random integer to match up requests and responses.

The Control field contains the aforementioned RD and RA bits amongst other info. It also contains OpCode to indicate what's the purpose of the request. That is, whether this DNS message is for a query, or to check status of the DNS server etc.

The Question, Answer fields contain incomplete Resource Records in the following format: {NAME, TYPE, CLASS}. The Question field contains the domain name that is being requested by the DNS client. Answer field will contain the IP address that the DNS server has found for the requested domain name.

Authority and Additional fields contain the complete Resource Records in the following format: {NAME, TYPE, CLASS, TTL, (RDATA_LENGTH), RDATA}. If the DNS server doesn't know the IP address of the domain name requested by a client but knows who has the authority of the next level down the Domain namespace tree, then that authority name will be included in the Authority field. And if that DNS server also knows the IP address of that authority, then that will be included in the Additional field.

We'll cover more on Resource Records in the following section.

DNS Zones

We know that the Domain Namespace is a hierarchical tree, with the DNS root domain at the top. A DNS zone is a portion of the DNS namespace that is managed by a specific organization or an administrator. A DNS zone starts at a domain within the tree and can also extend down into subdomains so that multiple subdomains can be managed by one entity.

Imagine a hypothetical zone for the cloudflare.com domain and three of its subdomains: support.cloudflare.com, community.cloudflare.com, and blog.cloudflare.com. Suppose the blog is a robust, independent site that needs separate administration, but the support and community pages are more closely associated with cloudflare.com and can be managed in the same zone as the primary domain. In this case, cloudflare.com as well as the support and community sites would all be in one zone, while blog.cloudflare.com would exist in its own zone.

cloudflare

(the above diagram is taken from here).

A DNS zone is defined by a Zone file. It is a plain text file that contains all the information about the zone. This information in the Zone file are called Resource Records (RRs). And this file lives on the Authoritative nameserver and the Authoritative nameserver has the authority over that zone. Authoritative nameserver is considered as the "zone apex", i.e., it lives at the top of the "zone tree".

A sample Zone file for example.com is shown below: (The character ; is for comments)

$ORIGIN example.com.
$TTL 86400
@    SOA    dns1.example.com.    hostmaster.example.com. (
        2001062501 ; serial
        21600      ; refresh after 6 hours
        3600       ; retry after 1 hour
        604800     ; expire after 1 week
        86400 )    ; minimum TTL of 1 day
;
;
    NS    dns1.example.com.
    NS    dns2.example.com.
dns1    A    10.0.1.1
    AAAA    aaaa:bbbb::1
dns2    A    10.0.1.2
    AAAA    aaaa:bbbb::2
;
;
@    MX    10    mail.example.com.
    MX    20    mail2.example.com.
mail    A    10.0.1.5
    AAAA    aaaa:bbbb::5
mail2    A    10.0.1.6
    AAAA    aaaa:bbbb::6
;
;
; This sample zone file illustrates sharing the same IP addresses for multiple services:
;
services    A    10.0.1.10
        AAAA    aaaa:bbbb::10
        A    10.0.1.11
        AAAA    aaaa:bbbb::11

ftp    CNAME    services.example.com.
www    CNAME    services.example.com.
;
;

In the above Zone file, we can see that there are different types of Resource Records, namely, SOA, NS, A, AAAA, MX, and CNAME.

Zone files must always start with a Start of Authority (SOA) record, which contains important information including the primary nameserver, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

We also have Name Service (NS) records which give the names of Nameservers, Address (A for IPv4 and AAAA for IPv6) records (this is the most commonly requested record by most internet users) contains the IP address of a domain name, Mail Exchange (MX) gives the name of the mail server, Canonical Name (CNAME) record returns the alternate name of the requested domain name (the client making this request will have to make a new request with the new name returned in CNAME record).

In the above example, dns1.example.com. is the Authoritative nameserver of this zone (as mentioned in the SOA record) and it has services.example.com, ftp.example.com, www.example.com Sub Domains under it.

ftp.example.com and www.example.com are just aliases for services.example.com (as mentioned in the CNAME record) and services.example.com has an A record with IP address of 10.0.1.10.

So, if a user wants to visit ftp.example.com, then the flow of DNS requests will be as follows: ftp.example.com -> services.example.com -> 10.0.1.10 and the user will get 10.0.1.10 as the IP address for ftp.example.com.

Tip: If you own a domain name on GoDaddy, you can view your Zone file in the GoDaddy UI by going through the following options in the menu: DNS -> Manage Zones -> (search your domain name in the UI and click on it) -> (scroll down to the bottom of the page) -> Export Zone File .

GoDaddy Interface

Zone Transfer

Usually, there are multiple Nameservers for a domain. And amongst them, there is one Primary nameserver and the rest will be Secondary nameservers. In our previous example, dns1.example.com was the Primary nameserver as it was mentioned in the SOA record and dns2.example.com is the Secondary nameserver (it was mentioned in the NS record).

If any changes are made to the Zone file of the Primary nameserver, then that has to be reflected on the Secondary nameserver. So, upon such changes to the Zone file on the Primary nameserver, the Primary notifies this to the Secondary and asks it to initiate something called as a Zone Transfer request. It's basically the Secondary nameserver asking for a copy of the Zone file from the Primary nameserver.

To request for a Zone Transfer, the Secondary nameserver needs to send a special DNS query called AXFR query to the Primary nameserver.

In an AXFR query message, the OpCode field in the DNS message header will be set to 0 and the TYPE field in Question section of DNS message is set to 252 to indicate that it's an AXFR request. Apart from these, the AXFR request must be sent on TCP packets. Normal DNS messages work on UDP (although they can be configured to work on TCP, TLS, HTTPS etc. as well). But AXFR query, which is specially used for Zone Transfers, must be made on reliable protocols like TCP.

Sometimes, the Primary nameservers are misconfigured and respond to any AXFR queries made by any public clients and they just send the whole Zone file to the clients. This is termed as "DNS Zone Transfer Attack". A Zone file of any Nameserver can be very valuable to the attackers as it contains information about the whole network topology of the entire Zone.

AXFR query to get the Zone file of wikipedia.org:

nandan@nandan:~$ dig @ns1.wikimedia.org. -t AXFR wikipedia.org
; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.wikimedia.org. -t AXFR wikipedia.org
; (1 server found)
;; global options: +cmd
; Transfer failed.

Although the above query failed, we can try our luck during a pentest to watch for misconfigured Authoritative nameservers.

Here's how a successful Zone transfer would look like:

> dig @ns2.eppi.com -t AXFR cpsr.org
; <<>> DiG 9.5.0b1 <<>> @ns2.eppi.com -t AXFR cpsr.org

cpsr.org             10800   IN      SOA   ns1.findpage.com. root.cpsr.org.
cpsr.org.            10800   IN      NS    ns.stimpy.net.
cpsr.org.            10800   IN      NS    ns1.findpage.com.
cpsr.org.            10800   IN      NS    ns2.eppi.com.
cpsr.org.            10800   IN      A     208.96.55.202
cpsr.org.            10800   IN      MX    0 smtp.electricembers.net.
diac.cpsr.org.       10800   IN      A     64.147.163.10
groups.cpsr.org.     10800   IN      NS    ns1.electricembers.net.
localhost.cpsr.org.  10800   IN      A     127.0.0.1
mail.cpsr.org.       10800   IN      A     209.209.81.73
peru.cpsr.org.       10800   IN      A     208.96.55.202
www.peru.cpsr.org.   10800   IN      A     208.96.55.202
[...]

The above query doesn't work now, but that example is taken from Nmap book.

Further learning

How are public domain names created and where are they registered?
Why can't 2 people register the same domain name? There has to be a universal domain registry database with all the public domain names stored in it and which ensures that there are no duplicate public domain names. Who owns and manages this universal public registry?
Where can I create a public domain name for myself? For that, I need to visit a Registrar to register my domain name and I will be charged some money for it. But a Domain Registrar is a private company. Who gave this private company the authority to register a public domain name?
How can I become the Registrar myself!?!?!
What is WHOIS protocol?

GoDaddy, a domain registrar, has a YouTube video that answers some of our questions!