DNS

Intro

Domain Name Servers contain information necessary to map domains to their corresponding IP addresses.

Types of DNS Query

1. Recursive

In this type of DNS query, the server to which a client is making the query, provides the IP address corresponding to the domain name. This might involve sending further more DNS queries on the queried server side to other different servers.

2. Iterative

In this type of DNS query, the server to which a client is making the query, provides pointer to another DNS server containing the information that we require.

Types of DNS Servers

1. DNS Root Server

Root Servers are responsible for iterative DNS query where they provide pointers for top-level domain(.com , .net , etc.) nameservers(TLD server) . There are a total of 13 root servers distributed across globe. They are managed by non-profit ICANN organization.

2. TLD(Top Level Domain) Name Server

Similar to how root servers are responsible for providing pointers to TLD servers, TLD servers are responsible for providing pointers to authoritative name servers.

3. Authoritative Name Server

They are last stop in the name resolution journey. It holds up-to-date information regarding the IP address for the hostname/domain.

When a domain is registered, domain owner specifies the authoritative DNS servers responsible for managing the domain’s DNS records. Authoritative servers have the original files of domain zone. Authoritative name servers hold authority for a particular zone. They only answer queries from their area of responsibility i.e. if they do not have the domain zone files for any particular domain, they will not query other servers recursively to provide the proper response.

4. Caching/Non-authoritative DNS Server

They query the authoritative nameserver and cache the information for a specified period. The time period for which caching server should store the information, is defined in the domain zone file managed by the authoritative name server. After that time period, caching DNS server sends the request to authoritative server again and updates its cache. Unlike authoritative servers, they recursively query other required DNS servers to provide a proper response. They are also distributed widely across the globe to reduce latency and provide high-availability. If we are sending request to caching server, we might get old information if the hostname-to-IP mapping has been changed recently. That’s why many domain registrar provides the disclaimer that it might take around 24 hours for the correct DNS resolution to reflect across the world when the mapping is changed.

5. Resolver

Resolvers are non authoritative DNS servers but perform name resolution locally in the computer or router. They are pre-configured with a list of IP addresses for the root DNS servers.

Types of DNS Records

DNS Record	Description
A	Returns an IPv4 address of the requested domain as a result.
AAAA	Returns an IPv6 address of the requested domain.
MX	Returns the responsible mail servers as a result.
NS	Returns the DNS servers (nameservers) of the domain.
TXT	This record can contain various information. The all-rounder can be used, e.g., to validate the Google Search Console or validate SSL certificates. In addition, SPF and DMARC entries are set to validate mail traffic and protect it from spam.
CNAME	This record serves as an alias. If the domain www.hackthebox.eu should point to the same IP, and we create an A record for one and a CNAME record for the other.
PTR	The PTR record works the other way around (reverse lookup). It converts IP addresses into valid domain names.
SOA	Provides information about the corresponding DNS zone and email address of the administrative contact.

Note: All these types of records can be stored by the a non-authoritative/caching DNS server.

DNS Record sample in Zone file

A record

domain(Under other TL domains)	class	record	IP
server2	IN	A	10.129.14.7

NS record

example.com	record type:	value:	TTL
@	NS	ns1.exampleserver.com	21600

Note: @ refers to “this domain” i.e. domain of the zone file.

SOA record

name	example.com
record type	SOA
MNAME(primary server for this zone)	ns.primaryserver.com
RNAME(administrator’s email address)	admin.example.com (admin@example.com)
SERIAL	1111111111
REFRESH	86400
RETRY	7200
EXPIRE	4000000
TTL	11200

TXT

example.com	record type:	value:	TTL
@	TXT	Put values for verification here!	32600

CNAME

blog.example.com	record type:	value:	TTL
@	CNAME	example.com	32600
blog	CNAME	example.com	32600

CNAME records can be used to alias one name to another. CNAME stands for Canonical Name.

A common example is when we have both example.com and www.example.com pointing to the same application and hosted by the same server. To avoid maintaining two different records, it’s common to create:

• An A record for example.com pointing to the server IP address
• A CNAME record for www.example.com pointing to example.com

As a result, example.com points to the server IP address, and www.example.com points to the same address via example.com. If the IP address changes, we only need to update it in one place: just edit the A record for example.com, and www.example.com automatically inherits the changes.

PTR record

last IP digit	class	type	FQDN
7	IN	PTR	server2.domain.com.

dig command

dig is a command-line tool that can be used to get any of these records for a particular domain:

dig [record_type] [@DNS_Server] {hostname}

@DNS_Server we can specify which DNS server to use when getting these records.

+trace option can be used to find the DNS path taken while resolving the domain

record_type By default, the record_type returned by dig command(if not specified) is A record. ANY can be sent in the record_type if one needs all the records associated with the domain.

-x option can be used for reverse DNS lookup

+short option can be used to just view the ANSWER section

How to read the output of dig command?

There is dig version, HEADER, ANSWER, footer sections in the output.

“ANSWER SECTION” is the main one that contains the DNS record. Depending upon the type of record that has been queried, they are returned in one of the previously mentioned formats.

In the footer(statistics) section, we can find the latency time(in milliseconds) in addition to which DNS server was used to solve the request.

How does a domain gets resolved in a device

Through a combination of recursive and iterative DNS queries.

1. Checks /etc/hosts file for DNS resolution and returns IP address
2. If not found, checks the mapping in local resolver cache and returns IP address(dns flush will clear this cache)

3. If not found, sends DNS query to the DNS server configured in the device. For example, google public DNS server 8.8.8.8. In a linux machine, DNS server can be specified in the /etc/resolv.conf file so that all the DNS calls are made to that server.

    nameserver 8.8.8.8
   

   Sample /etc/resolv.conf

   Generally, DNS server configured is a caching server which stores the recently/frequently used mappings, making DNS resolution faster.

   They can also benefit in cases where there is internal DNS server in the network for internal DNS resolution.

4. If the DNS caching server already has the record, then simply returns the IP address.
5. Otherwise, finds the IP address through recursive approach(Root Server, TLD server, Authoritative domain).
6. If DNS server is not explicitly configured, routers(default gateway) makes all the DNS calls for the network. The router is configured by the ISPs with certain DNS resolvers.

How to configure our own DNS server?

In linux, Bind9 is often used to spin up DNS servers. All DNS servers work with three different types of configuration files:

1. local DNS configuration files

• named.conf.local
• named.conf.options
• named.conf.log

These files are located at /etc/bind/. In the configuration file, settings can be configured globally or zone-wise. Global settings apply to all the zones. If the same setting is applied on global level and zone level, then zone setting takes precedence.

zone "domain.com" {
    type master;
    file "**/etc/bind/db.domain.com**";
    allow-update { key rndc-key; };
};

/etc/bind/named.conf.local

2. zone files

DNS system is handled in a hierarchy with the root servers in the top hierarchy — which delegates the DNS query to respective secondary servers — and name servers at the bottom which contain actual DNS records.

A zone can be defined as the region of the authority of domains. Each DNS server/zone contains a mapping table which is either the delegation mapping or a DNS mapping. This table/file is called a zone file. A zone file describes a zone completely. It should contain precisely one SOA record(generally at top) and at least one NS record. If there is syntax error in zone file, all the records in it are unusable and results in SERVFAIL error message to DNS queries.

This zone file can be copied across multiple servers. The server containing the original copy is the master/primary zone and the server that contains the copied version of zone file is called slave/secondary zone. The secondary server is not caching/non-authoritative server described above. They are replicas of the authoritative servers maintained to handle fail-overs and increase reliability.

The process of copying the zone file across other zones(dns name server) is called DNS zone transfer.

DNS zone transfer is done so that the secondary zones can also serve the DNS query requests. In case of master zone failure as well, slave zone can back up and serve the request. System administrator only makes changes in the primary zone file and those changes are copied to any secondary zones associated with the primary zone. Using a secret key rndc-key, which we have seen initially in the default configuration, the servers make sure that they communicate with their own master or slave. The slave fetches the SOA record of the relevant zone from the master at certain intervals, the so-called refresh time, and compares the serial numbers. If the serial number of the SOA record of the master is greater than that of the slave, the data sets no longer match.

;
; BIND reverse data file for local loopback interface
;
$ORIGIN domain.com
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     ns1.domain.com.
      IN     NS     ns2.domain.com.

      IN     MX     10     mx.domain.com.
      IN     MX     20     mx2.domain.com.

             IN     A       10.129.14.5

server1      IN     A       10.129.14.5
**server2      IN     A       10.129.14.7**
ns1          IN     A       10.129.14.2
ns2          IN     A       10.129.14.3

ftp          IN     CNAME   server1
mx           IN     CNAME   server1
mx2          IN     CNAME   server2
www          IN     CNAME   server2

/etc/bind/db.domain.com (Sample zone file)

DIG for DNS zone transfer

---

DIG can be used to perform DNS zone transfer. If we want to initiate a zone transfer for a domain zonetransfer.me , we first need to get the list of DNS name servers for the domain.

dig +short ns zonetransfer.me

After we get the list of DNS servers, we can initiate AXFR(Asynchronous Full Transfer Zone) request to get a copy of the zone file from DNS server.

dig axfr zonetransfer.me @dns_server

AXFR is a protocol for “zone transfers” for replication of DNS data across multiple DNS servers

Sub-domain enumeration

It can also be used to find the sub-domains of a domain. When performing axfr request, it returns the zone file which might contain sub-domain A records. Not all name servers allow zone transfer. If the server has not allowed zone transfer, we get “Transfer failed” error.

In such case, we would have to resort to brute-forcing using various tools and wordlists:

gobuster dns -d horizontall.htb -w /usr/share/SecLists/Discovery/DNS/namelist.txt -r dns_server.htb

dnsenum --dnsserver 10.129.14.128 --enum -p 0 -s 0 -o subdomains.txt -f /opt/useful/SecLists/Discovery/DNS/subdomains-top1million-110000.txt inlanefreight.htb

dnsenum is a better choice as it also finds the records associated with the sub-domains if possible, unlike gobuster which only shows the matched sub-domains. When using gobuster, we would have to perform one more step using tools such as dig to find the DNS records of the discovered sub-domains.

3. Reverse name resolution files

For the IP address to be resolved from Fully Qualified Domain Name(FQDN), the DNS server must have a reverse lookup file. FQDN of a domain consists of three labels including hostname, second-level domain and top-level domain, each separated by a period, ending with a trailing period. e.g. www.mywebsite.com. . Trailing periods indicate the end of the address. FQDN is also necessary for installing SSL certificates.

Reverse name resolution happens with the help of PTR DNS records present in the zone file. The reverse name resolution file looks similar to zone file except its origin would be 3 octets of reversed IP address with .in-addr.arpa added. “in-addr.arpa” has to be added because PTR records are stored within the .arpa top-level domain in the DNS. in-addr.arpa is the namespace within .arpa for reverse DNS lookups in IPv4. The reverse name resolution file containing PTR record for server2.domain.com looks like:

$ORIGIN 14.129.10.in-addr.arpa
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     ns1.domain.com.
      IN     NS     ns2.domain.com.

7     IN     PTR    server2.domain.com.
;<last-IP-digit>      IN     PTR    <FQDN-of-system>

/etc/bind/db.10.129.14 (Sample PTR record)

The local DNS config file for this would look like:

zone "14.129.10.in-addr.arpa" {
    type master;
    file "/etc/bind/db.10.129.14";
    allow-update { key rndc-key; };
};

/etc/bind/named.conf.local

Dangerous configurations

Option	Description
allow-query	Defines which hosts are allowed to send requests to the DNS server.
allow-recursion	Defines which hosts are allowed to send recursive requests to the DNS server.
allow-transfer	Defines which hosts are allowed to receive zone transfers from the DNS server.
zone-statistics	Collects statistical data of zones.

# class CH(CHAOS), generally IN(Internet) class is used
dig **CH TXT** mydomain.com @{dns_server_hostname_or_IP}

Command to find the DNS server version (doesn’t work on all)