Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🏠 Back to Blog

DNS

Domain Name System (DNS) is an integral part of the Internet that resolves computer names into IP addresses. DNS is a distributed system without a central database, functioning like a library with many different phone books. The information is distributed over many thousands of name servers globally. DNS servers translate domain names into IP addresses and control which server a user can reach via a particular domain. DNS also stores additional information about services associated with a domain, such as mail servers and name servers.

DNS Server Types

  • DNS Root Server: Responsible for top-level domains (TLD). There are 13 root servers globally, coordinated by ICANN. They serve as the central interface between users and content on the Internet.
  • Authoritative Nameserver: Holds authority for a particular zone and only answers queries from their area of responsibility. Their information is binding.
  • Non-authoritative Nameserver: Not responsible for a particular DNS zone. They collect information on specific DNS zones using recursive or iterative DNS querying.
  • Caching DNS Server: Caches information from other name servers for a specified period determined by the authoritative name server.
  • Forwarding Server: Performs only one function: forwards DNS queries to another DNS server.
  • Resolver: Not an authoritative DNS server but performs name resolution locally in the computer or router.

DNS Encryption

DNS is mainly unencrypted, which means devices on the local WLAN and Internet providers can intercept and spy on DNS queries. This poses a privacy risk. Solutions for DNS encryption include:

  • DNS over TLS (DoT): Encrypts DNS traffic using TLS
  • DNS over HTTPS (DoH): Encrypts DNS traffic using HTTPS
  • DNSCrypt: A network protocol that encrypts traffic between the computer and the name server

DNS Records

Different DNS records are used for DNS queries, each serving various tasks:

RecordDescription
AReturns an IPv4 address of the requested domain
AAAAReturns an IPv6 address of the requested domain
MXReturns the responsible mail servers
NSReturns the DNS servers (nameservers) of the domain
TXTContains various information (e.g., Google Search Console validation, SSL certificate validation, SPF and DMARC entries for mail traffic)
PTRUsed for reverse translation of IP addresses into names
CNAMECreates an alias from one domain name to another
SOAStart of Authority record containing administrative information about the zone

Domain Hierarchy

The DNS hierarchy consists of:

  • Root: The top level of the DNS hierarchy
  • Top Level Domains (TLD): Examples include .net, .org, .com, .dev, .io
  • Second Level Domain: Example: inlanefreight.com
  • Sub-Domains: Examples: dev.inlanefreight.com, www.inlanefreight.com, mail.inlanefreight.com
  • Host: Example: WS01.dev.inlanefreight.com

Zone Files

Zone files contain forward records in BIND format, allowing the DNS server to identify which domain, hostname, and role IP addresses belong to. This is essentially the phone book where the DNS server looks up addresses for domains.

Example forward zone file:

root@bind9:~# cat /etc/bind/db.domain.com

;
; 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

Reverse Name Resolution

For Fully Qualified Domain Name (FQDN) to be resolved from an IP address, the DNS server must have a reverse lookup file. PTR records are responsible for the reverse translation of IP addresses into names. In this file, the computer name (FQDN) is assigned to the last octet of an IP address using a PTR record.

Example reverse zone file:

root@bind9:~# cat /etc/bind/db.10.129.14

;
; BIND reverse data file for local loopback interface
;
$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.

5    IN     PTR    server1.domain.com.
7    IN     MX     mx.domain.com.

Zone Transfers

A DNS zone transfer is essentially a wholesale copy of all DNS records within a zone (a domain and its subdomains) from one name server to another. This process is essential for maintaining consistency and redundancy across DNS servers. However, if not adequately secured, unauthorised parties can download the entire zone file, revealing a complete list of subdomains, their associated IP addresses, and other sensitive DNS data.

In practice, additional servers called secondary name servers are installed for redundancy. For some Top-Level Domains (TLDs), making zone files accessible on at least two servers is mandatory. DNS entries are generally only created, modified, or deleted on the primary server. A DNS server that serves as a direct source for synchronizing a zone file is called a master. A DNS server that obtains zone data from a master is called a slave. The slave fetches the SOA record of the relevant zone from the master at certain intervals (refresh time, usually one hour) and compares serial numbers.

How it works:

  1. Zone Transfer Request (AXFR): The secondary DNS server initiates the process by sending a zone transfer request to the primary server. This request typically uses the AXFR (Full Zone Transfer) type.
  2. SOA Record Transfer: Upon receiving the request (and potentially authenticating the secondary server), the primary server responds by sending its Start of Authority (SOA) record. The SOA record contains vital information about the zone, including its serial number, which helps the secondary server determine if its zone data is current.
  3. DNS Records Transmission: The primary server then transfers all the DNS records in the zone to the secondary server, one by one. This includes records like A, AAAA, MX, CNAME, NS, and others that define the domain’s subdomains, mail servers, name servers, and other configurations.
  4. Zone Transfer Complete: Once all records have been transmitted, the primary server signals the end of the zone transfer. This notification informs the secondary server that it has received a complete copy of the zone data.
  5. Acknowledgement (ACK): The secondary server sends an acknowledgement message to the primary server, confirming the successful receipt and processing of the zone data. This completes the zone transfer process.

Attempting a zone transfer

rtn@xerxes[/]$ dig axfr @nsztm1.digi.ninja zonetransfer.me

zonetransfer.me is a special service designed to demonstrate zone transfers

Dangerous Settings

DNS servers can be vulnerable to attacks. Some dangerous settings that can lead to vulnerabilities include:

  • 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. If set to any or a broad subnet, anyone can query the entire zone file, potentially exposing internal IP addresses and hostnames
  • zone-statistics: Collects statistical data of zones

Footprinting DNS Services

Querying Name Servers

DNS servers can be queried to discover which other name servers are known using the NS record:

rnemeth@htb[/htb]$ dig ns inlanefreight.htb @10.129.14.128

Zone Transfer (AXFR)

Zone transfers can reveal all DNS records for a domain. If allow-transfer is misconfigured, an attacker can retrieve the entire zone file:

rnemeth@htb[/htb]$ dig axfr inlanefreight.htb @10.129.14.128

; <<>> DiG 9.16.1-Ubuntu <<>> axfr inlanefreight.htb @10.129.14.128
;; global options: +cmd
inlanefreight.htb.      604800  IN      SOA     inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb.      604800  IN      TXT     "MS=ms97310371"
inlanefreight.htb.      604800  IN      TXT     "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb.      604800  IN      TXT     "v=spf1 include:mailgun.org include:_spf.google.com include:spf.protection.outlook.com include:_spf.atlassian.net ip4:10.129.124.8 ip4:10.129.127.2 ip4:10.129.42.106 ~all"
inlanefreight.htb.      604800  IN      NS      ns.inlanefreight.htb.
app.inlanefreight.htb.  604800  IN      A       10.129.18.15
internal.inlanefreight.htb. 604800 IN   A       10.129.1.6
mail1.inlanefreight.htb. 604800 IN      A       10.129.18.201
ns.inlanefreight.htb.   604800  IN      A       10.129.34.136

Subdomain Brute Forcing

Individual A records with hostnames can be discovered through brute-force attacks using wordlists (such as those from SecLists):

rnemeth@htb[/htb]$ for sub in $(cat /opt/useful/seclists/Discovery/DNS/subdomains-top1million-110000.txt);do dig $sub.inlanefreight.htb @10.129.14.128 | grep -v ';\|SOA' | sed -r '/^\s*$/d' | grep $sub | tee -a subdomains.txt;done

ns.inlanefreight.htb.   604800  IN      A       10.129.34.136
mail1.inlanefreight.htb. 604800 IN      A       10.129.18.201
app.inlanefreight.htb.  604800  IN      A       10.129.18.15

Tools like dnsenum can automate this process:

rnemeth@htb[/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