DNS Essentials: Key Insights for Penetration Testers

Hi! In this article I will cover DNS, DNS records, and how we can enumerate DNS to gain knowledge for penetration testing purposes.
I have tried to keep it short while focusing on the key insights for every penetration tester.

I am making these walkthroughs to keep myself motivated to learn cyber security, and to share my journey  🙂 Join me on learning cyber security. I will try and explain concepts as I go.

Introduction

DNS, which stands for Domain Name System, is a critical component of the internet that translates human-friendly domain names (like www.example.com) into IP addresses (such as 192.0.2.1) that computers use to identify each other on the network. DNS works like a distributed, hierarchical database, and it helps users navigate the internet by ensuring that when you enter a web address, your computer can find the corresponding server’s IP address. It is basicly like a real world address, which coordinates house coordinates to a easily understandable address.

But why are we interested in DNS services from a cyber security perspective?

Enumerating DNS (Domain Name System) is important from a cybersecurity perspective for three mains reasons:

1. Mapping Network Infrastructure:
   DNS enumeration helps cybersecurity professionals map an organization’s network infrastructure. By identifying all the DNS records associated with a domain, including subdomains, it becomes easier to understand the scope of an organization’s digital presence. This information is critical for network security assessments and vulnerability management.
2. Identifying Attack Targets:
   Attackers often perform DNS enumeration to identify potential targets for cyberattacks. By discovering all the publicly available domain names, attackers can find vulnerable systems and services that may be susceptible to attacks like DNS spoofing, phishing, or brute force attacks.
   Please bear in mind that if you participate in bounty hunting you have to make sure these potential targets are a part of the scope!
3. Subdomain Discovery: Subdomains can often be overlooked in security configurations, making them potential entry points for attackers. DNS enumeration helps in finding these subdomains, which may contain vulnerabilities or misconfigurations that can be exploited.

So yes, DNS records can provide a lot of juicy information for pentesters! It allows us to find other hosts to target, some of which may be vulnerable.

DNS Servers

DNS records are distributed over many thousands of name servers. Globally distributed DNS servers translate domain names into IP addresses and thus control which server a user can reach via a particular domain. There are a bunch of different types of DNS servers that are used worldwide, but I will only cover the most important ones for now:

1. Root DNS Servers: These are the highest-level DNS servers in the DNS hierarchy. There are 13 sets of root DNS servers distributed worldwide. They contain information about the top-level domains (TLDs) such as .com, .org, .net, and others, and direct queries to the correct Top-Level Domain server.
2. Top-Level Domain (TLD) DNS Servers: TLD DNS servers are responsible for specific top-level domains like .com, .org, .net, and country-code TLDs like .uk, .fr, and .jp. They maintain information about domain names within their respective TLD.
3. Authoritative DNS Servers: These DNS servers store and provide DNS records for a specific domain. They are responsible for answering DNS queries with information about the domain they are authoritative for. Websites and services often have their own authoritative DNS servers.
4. Recursive DNS Servers: Also known as resolver servers, recursive DNS servers are the ones most people interact with indirectly. They receive DNS queries from clients (e.g., your computer or smartphone), resolve them by querying authoritative DNS servers if necessary, and return the IP address to the client. Internet service providers (ISPs) typically operate recursive DNS servers for their customers.

For us, Authoritative DNS server are actually the most interesting, especially when we start discussing zone transfers. More on this in a bit. For now, let’s discuss the different kind of DNS records that authoritative DNS servers can store about domains.

Types of DNS Records

DNS records contain various types of information, allowing DNS to perform a variety of tasks beyond simple domain-to-IP mapping. Here are some common DNS record types:

1. A (Address) Record: Maps a domain name to an IPv4 address. For example, it links www.example.com to 192.0.2.1.
2. AAAA (IPv6 Address) Record: Similar to the A record but for IPv6 addresses.
3. CNAME (Canonical Name) Record: Points one domain name to another domain name, allowing you to alias one domain to another. For example, you can set up www.example.com as a CNAME for example.com.
4. MX (Mail Exchange) Record: Specifies the mail servers responsible for receiving email for a domain.
5. TXT (Text) Record: Used to store arbitrary text information. It’s often used for domain verification and for specifying SPF (Sender Policy Framework) records for email.
6. NS (Name Server) Record: Identifies the authoritative name servers for a domain.
7. PTR (Pointer) Record: Used in reverse DNS lookup to map an IP address to a domain name. Basicly the reverse of a A record.
8. SRV (Service) Record: Specifies the location of a service, such as a SIP or XMPP server.
9. SOA (Start of Authority) Record: Contains administrative information about the domain, including the primary authoritative name server and contact information.

All of these can be interesting to us.

How to enumerate

This is nice and all, but how do we fetch these records? We got two useful commands on Linux that can help us: nslookup and dig. Let’s start with nslookup, which is a bit more limited in its scope.

Fetching A and AAAA records

In its most basic form, nslookup can be used to “look up” DNS name servers. An example of this is as follows:

nslookup facebook.com

Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
Name: facebook.com
Address: 31.13.92.36
Name: facebook.com
Address: 2a03:2880:f11c:8083:face:b00c:0:25de

This gives you the IP address associated to the hostname. If you thought to yourself that this sounds like a A (and AAAA) record, you are right! 🙂
The server and address mentioned before is the IP address of the DNS server (hinted by the port 53).

Fetching NS records

In most cases a domain has multiple domain name servers. How to find these? Well we simply run the following with dig:

dig ns inlanefreight.htb @10.129.14.128;

<<>> DiG 9.16.1-Ubuntu <<>> ns inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45010
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce4d8681b32abaea0100000061475f73842c401c391690c7 (good)
;; QUESTION SECTION:
;inlanefreight.htb. IN NS

;; ANSWER SECTION:
inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.

;; ADDITIONAL SECTION:
ns.inlanefreight.htb. 604800 IN A 10.129.34.136
;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128);; WHEN: So Sep 19 18:04:03 CEST 2021
;; MSG SIZE rcvd: 107

This finds another DNS server., highlighted in bold. The important thing to note here is that you add the target NS server after the “@”. This will ask the DNS server for any other DNS server it knows.

Fetching MX records

I won’t go into to much detail here but to get MX records you simply run:

dig mx <domain>

This is perfect to find some info on mail servers, which you then can proceed to enumerate through SMTP/POP3/IMAP etc.

Fetching TXT records

As before, you can get TXT records by simply running:

dig txt <domain>

Fetching all records

There is a quick shortcut to find all records on a DNS server:

dig any inlanefreight.htb @10.129.14.128;

<<>> DiG 9.16.1-Ubuntu <<>> any inlanefreight.htb @10.129.14.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7649
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 064b7e1f091b95120100000061476865a6026d01f87d10ca (good)
;; QUESTION SECTION:
;inlanefreight.htb. IN ANY

;; ANSWER SECTION:
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 TXT "atlassian-domain-verification=t1rKCy68JFszSdCKVpw64A1QksWdXuYFUeSXKU"
inlanefreight.htb. 604800 IN TXT "MS=ms97310371"
inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb. 604800 IN NS ns.inlanefreight.htb.

;; ADDITIONAL SECTION:
ns.inlanefreight.htb. 604800 IN A 10.129.34.136

;; Query time: 0 msec
;; SERVER: 10.129.14.128#53(10.129.14.128);; WHEN: So Sep 19 18:42:13 CEST 2021
;; MSG SIZE rcvd: 437

Zone Transfer

Happy so far? You should be. But now comes the concept of zone transfers. This gave me a lot of headaches when I got introduced to this, but after some time it finally made a bit of sense! I hope I can explain it in a clear manner so it makes sense from the get go.

Zone transfer is the process of transferring DNS zones to another server over TCP port 53. It is abbreviated as Asynchronous Full Transfer Zone (AXFR). To make sure that all DNS servers have the same data the zone file (the file that stores all the records) is synchronized between the primary name server to the secondary name servers. This happens automatically, usually once an hour. t is typically used to ensure redundancy and fault tolerance in DNS

But the important thing is that we can manually request a zone transfer from one DNS server to another. If we do this with a tool like dig, we can get all the info from the primary name server sent straight to us!

Note: This requires that the administrator has setup the allow-transfer option in the config in a poor manner, meaning everyone can request the zone file.

An example from HTB is like follows:

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
inlanefreight.htb. 604800 IN SOA inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
;; Query time: 4 msec
;; SERVER: 10.129.14.128#53(10.129.14.128);; WHEN: So Sep 19 18:51:19 CEST 2021
;; XFR size: 9 records (messages 1, bytes 520)

I hope this made a bit of sense. If not, please leave a comment!

DNS Bruteforcing with Gobuster

If zone transfer is not an option, we need to do some bruteforcing.

Gobuster is a tool that we can use to perform subdomain enumeration, althoough there are many alternatives.

It can be used as follows:

Uses DNS subdomain enumeration mode

Usage:
  gobuster dns [flags]

Flags:
  -d, --domain string      The target domain
  -h, --help               help for dns
  -r, --resolver string    Use custom DNS server (format server.com or server.com:port)
  -c, --show-cname         Show CNAME records (cannot be used with '-i' option)
  -i, --show-ips           Show IP addresses
      --timeout duration   DNS resolver timeout (default 1s)
      --wildcard           Force continued operation when wildcard found

Global Flags:
      --delay duration    Time each thread waits between requests (e.g. 1500ms)
      --no-color          Disable color output
      --no-error          Don't display errors
  -z, --no-progress       Don't display progress
  -o, --output string     Output file to write results to (defaults to stdout)
  -p, --pattern string    File containing replacement patterns
  -q, --quiet             Don't print the banner and other noise
  -t, --threads int       Number of concurrent threads (default 10)
  -v, --verbose           Verbose output (errors)
  -w, --wordlist string   Path to the wordlist

An example of running gobuster would be like follows:

gobuster dns -d google.com -w ~/wordlists/subdomains.txt

===============================================================
Gobuster v3.2.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Mode         : dns
[+] Url/Domain   : google.com
[+] Threads      : 10
[+] Wordlist     : /home/oj/wordlists/subdomains.txt
===============================================================
2019/06/21 11:54:20 Starting gobuster
===============================================================
Found: chrome.google.com
Found: ns1.google.com
Found: admin.google.com
Found: www.google.com
Found: m.google.com
Found: support.google.com
Found: translate.google.com
Found: cse.google.com
Found: news.google.com
Found: music.google.com
Found: mail.google.com
Found: store.google.com
Found: mobile.google.com
Found: search.google.com
Found: wap.google.com
Found: directory.google.com
Found: local.google.com
Found: blog.google.com
===============================================================
2019/06/21 11:54:20 Finished

One final note to make is that domain bruteforcing is not the the same as virtual host bruteforcing. Virtual hosts are a way of hosting multiple domain names on the same server, and to the regular visitor will look the same as a subdomain. But if you want to enumerate these you will need to use vhost option instead of dns.

But anyway, we are done for now! I hope you learned a lot about DNS services. It was great fun to write this summary.

Like my articles?

You are welcome to support me by buying me a cup of coffee:

I learned a lot through HackTheBox’s Academy. If you want to sign up, you can get extra cubes, and support me in the process, if you use the following link:

https://referral.hackthebox.com/mzwwXlg