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:
| Record | Description |
|---|---|
| A | Returns an IPv4 address of the requested domain |
| AAAA | Returns an IPv6 address of the requested domain |
| MX | Returns the responsible mail servers |
| NS | Returns the DNS servers (nameservers) of the domain |
| TXT | Contains various information (e.g., Google Search Console validation, SSL certificate validation, SPF and DMARC entries for mail traffic) |
| PTR | Used for reverse translation of IP addresses into names |
| CNAME | Creates an alias from one domain name to another |
| SOA | Start 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:
- 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.
- 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.
- 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.
- 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.
- 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
anyor 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