Skip to main content

Lab 5.2: Advanced DNS Enumeration

Learning Objectives​

By the end of this lab, you will be able to:

  • Understand the role of DNS in network security
  • Perform DNS queries of different types (A, MX, NS, TXT, etc.)
  • Discover hidden subdomains
  • Attempt DNS zone transfers
  • Identify information leaks via DNS
  • Use automated DNS enumeration tools
  • Analyze DNS configuration to identify vulnerabilities
  • Apply DNS security measures

Estimated Duration​

35 minutes

Prerequisites​

  • Windows VM and/or Kali Linux
  • Internet access (for this lab, we will use legal test domains)
  • Understanding of the DNS system (theoretical course)
  • Lab 5.1 (Nmap) completed

Professional Context​

DNS enumeration is a critical step in passive reconnaissance. It allows you to:

  • Discover an organization's infrastructure
  • Identify servers and services unintentionally exposed
  • Find development/test subdomains
  • Collect email addresses for targeted phishing
  • Map network architecture
  • Identify misconfigurations

Used by:

  • Pentesters during reconnaissance
  • Bug bounty hunters to find assets
  • Administrators for auditing their own infrastructure
  • Attackers to identify targets

Excessive or targeted DNS enumeration may be considered malicious reconnaissance.

AUTHORIZED:

  • On your own domains
  • On public test domains (example.com, testphp.vulnweb.com)
  • Within the scope of bug bounty with authorization
  • For security audit with contract

PROHIBITED:

  • Massive enumeration of domains without permission
  • Scanning government or military infrastructures
  • Using to target attacks
  • Aggressive brute force causing denial of service

NOTE: We will only use legal test domains in this lab.

Part 1: Basic DNS Queries​

Step 1.1: nslookup Command​

Simple DNS query:

nslookup example.com

Result:

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    example.com
Address: 93.184.216.34

Information obtained:

  • DNS server used
  • IP address of the domain

Specific type query:

nslookup -type=MX example.com

Common types:

  • A - IPv4 Address
  • AAAA - IPv6 Address
  • MX - Mail servers
  • NS - Name servers
  • TXT - Text records (SPF, DKIM, etc.)
  • CNAME - Canonical name (alias)
  • SOA - Start of Authority

Step 1.2: dig Command (Linux)​

More powerful than nslookup:

dig example.com

Specific type query:

dig example.com MX
dig example.com NS
dig example.com TXT
dig example.com ANY

ANY option: All record types (sometimes limited by DNS servers)

Specific DNS server:

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

Questions:

  1. What are the mail servers (MX) of example.com?
  2. What are the name servers (NS)?

Step 1.3: TXT Records and Information Leaks​

TXT records often contain sensitive information:

dig example.com TXT

Typically found information:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=xxxxxx"

Can reveal:

  • Services used (Google Workspace, Microsoft 365)
  • Security configurations (SPF, DKIM, DMARC)
  • Domain verifications
  • Sometimes: unintentional internal information

Questions: 3. What services does the organization use (based on TXT records)? 4. Are there any sensitive information in the TXT records?

Part 2: DNS Zone Transfer​

Step 2.1: Understanding Zone Transfers​

Zone Transfer (AXFR):

  • Legitimate mechanism to replicate DNS between servers
  • Should be restricted to authorized secondary servers
  • If misconfigured: Allows dumping the ENTIRE DNS zone!

Result of a successful transfer:

  • COMPLETE list of all subdomains
  • All IP addresses
  • Entire DNS configuration

It's like getting the organization's complete directory!

Step 2.2: Attempting a Zone Transfer​

With dig:

dig axfr @ns1.example.com example.com

Result if vulnerable:

example.com.        3600  IN  SOA   ns1.example.com. admin.example.com. ...
example.com.        3600  IN  NS    ns1.example.com.
example.com.        3600  IN  NS    ns2.example.com.
www.example.com.    3600  IN  A     93.184.216.34
mail.example.com.   3600  IN  A     93.184.216.35
ftp.example.com.    3600  IN  A     93.184.216.36
admin.example.com.  3600  IN  A     192.168.1.50
dev.example.com.    3600  IN  A     192.168.1.100
test.example.com.   3600  IN  A     10.0.0.50
...

JACKPOT! All subdomains revealed, including internal ones!

Result if protected:

; Transfer failed.

With nslookup (Windows):

nslookup
server ns1.example.com
ls -d example.com

Step 2.3: Identifying Name Servers​

Before attempting transfer, identify the NS:

dig example.com NS

Result:

example.com.  3600  IN  NS  ns1.example.com.
example.com.  3600  IN  NS  ns2.example.com.

Attempt transfer on each:

dig axfr @ns1.example.com example.com
dig axfr @ns2.example.com example.com

Sometimes one server is misconfigured but not the other!

Questions: 5. Did the zone transfer succeed? 6. How many subdomains did you discover?

Part 3: Subdomain Discovery​

Step 3.1: Subdomain Brute Force​

Common subdomain wordlist:

Create subdomains.txt:

www
mail
ftp
admin
webmail
portal
vpn
remote
dev
test
staging
api

Simple bash script:

#!/bin/bash

DOMAIN=$1
WORDLIST="subdomains.txt"

while read subdomain; do
    result=$(host "$subdomain.$DOMAIN" 2>/dev/null)
    if [[ $result != *"not found"* ]]; then
        echo "[+] Found: $subdomain.$DOMAIN"
        echo "$result"
    fi
done < $WORDLIST

Usage:

chmod +x subdomain_enum.sh
./subdomain_enum.sh example.com

Step 3.2: Automated Tools​

dnsenum (pre-installed on Kali):

dnsenum example.com

Features:

  • Zone transfer attempt
  • Subdomain brute force
  • Reverse resolution (PTR records)
  • Google scraping for subdomains

Example result:

dnsenum VERSION:1.2.6

-----   example.com   -----

Host's addresses:
__________________

example.com.                         93.184.216.34

Name Servers:
______________

ns1.example.com.                     199.43.135.53
ns2.example.com.                     199.43.133.53

Brute forcing with subdomains.txt:
___________________________________

www.example.com.                     93.184.216.34
mail.example.com.                    93.184.216.35
ftp.example.com.                     93.184.216.36

subfinder (modern tool):

# Installation
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# Usage
subfinder -d example.com

Uses multiple sources:

  • Search APIs
  • SSL certificates (crt.sh)
  • Web archives
  • Search engines

Step 3.3: SSL Certificates for Subdomains​

SSL certificates often reveal subdomains!

Manual search on crt.sh:

curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u

Result:

*.example.com
www.example.com
mail.example.com
api.example.com
staging.example.com

Subdomains discovered via SSL certificates!

Questions: 7. How many subdomains did you find with dnsenum? 8. Do any subdomains appear to be for development/testing?

Part 4: Reverse Enumeration (Reverse DNS)​

Step 4.1: Reverse Resolution (PTR Records)​

From an IP, find the domain name:

nslookup 93.184.216.34

OR

dig -x 93.184.216.34

Result:

34.216.184.93.in-addr.arpa name = example.com.

Step 4.2: IP Range Scan for PTR​

Script to scan a range:

#!/bin/bash

NETWORK="93.184.216"

for i in {1..254}; do
    IP="$NETWORK.$i"
    PTR=$(dig -x $IP +short 2>/dev/null)
    if [ ! -z "$PTR" ]; then
        echo "$IP -> $PTR"
    fi
done

Result: List of all domains hosted on this IP range!

Useful for:

  • Identifying all sites of the same organization
  • Discovering unpublicized domains
  • Mapping infrastructure

Questions: 9. How many domains are hosted on the same IP range? 10. Why is reverse resolution useful in reconnaissance?

Part 5: DNS Configuration Analysis​

Step 5.1: Identifying Authoritative DNS Servers​

dig example.com NS +trace

Result shows the complete hierarchy:

.           Root servers
com.        TLD servers
example.com. Authoritative servers

See the complete delegation from the root!

Step 5.2: SPF/DMARC Verification​

SPF (Sender Policy Framework):

dig example.com TXT | grep spf

Analysis:

"v=spf1 include:_spf.google.com ~all"
  • ~all = SoftFail (accepts but marks as suspicious)
  • -all = HardFail (rejects)
  • +all = Accepts all (DANGEROUS!)

DMARC:

dig _dmarc.example.com TXT

If misconfigured: Easier phishing!

Step 5.3: DNS Cache Poisoning (Demonstration)​

On your local VM (not on the Internet!):

Local hosts file:

notepad C:\Windows\System32\drivers\etc\hosts

Add:

192.168.100.50  facebook.com
192.168.100.50  google.com

Save and test:

ping facebook.com

Result: Ping to 192.168.100.50 instead of the real IP!

Application: Local phishing, traffic redirection

Questions: 11. Does the hosts file bypass DNS? 12. How could an attacker exploit this?

Part 6: Advanced Enumeration Tools​

Step 6.1: fierce (DNS Scanner)​

fierce --domain example.com

Features:

  • Zone transfer
  • Subdomain brute force
  • Nearby IP range scan
  • Reverse resolution

Step 6.2: dnsrecon​

dnsrecon -d example.com -t std

Scan options (-t):

  • std - Standard
  • axfr - Zone transfer
  • bing - Bing search
  • zonewalk - DNSSEC zone walking

Full scan:

dnsrecon -d example.com -t std,axfr,bing,zonewalk -n ns1.example.com

Step 6.3: amass (The most comprehensive)​

amass enum -d example.com

Sources used:

  • Multiple APIs
  • Web scraping
  • SSL certificates
  • Archives
  • DNS brute force

Detailed output:

amass enum -d example.com -o subdomains.txt -v

Typical result: 50-500+ subdomains discovered!

Questions: 13. Which tool found the most subdomains? 14. Do any subdomains appear unintentionally exposed?

Part 7: Exploiting DNS Configurations​

Step 7.1: DNS Cache Snooping​

Check if a DNS server has resolved certain domains:

nmap --script dns-cache-snoop --script-args 'dns-cache-snoop.mode=timed,dns-cache-snoop.domains={google.com,facebook.com,internalsite.local}' <DNS_SERVER>

If the server has already resolved these domains: In the cache!

Reveals: Which sites the organization visits

Step 7.2: DNS Zone Walking (DNSSEC)​

If DNSSEC misconfigured:

dnsrecon -d example.com -t zonewalk

Allows enumeration of ALL records even without zone transfer!

Step 7.3: Subdomain Takeover​

Identify subdomains pointing to non-existent services:

dig admin.example.com

If CNAME points to:

admin.example.com CNAME old-service.azurewebsites.net

And old-service.azurewebsites.net no longer exists:

Attacker can:

  1. Create old-service.azurewebsites.net
  2. Control admin.example.com
  3. Phishing, session theft, etc.

Automated detection:

subzy run --target subdomains.txt

Questions: 15. Did you find any subdomains with CNAME to third-party services? 16. How to check if a subdomain is vulnerable to takeover?

Deliverables​

To submit:

  1. DNS Enumeration Report (Word/PDF, 3-4 pages):

    • Answers to the 16 questions
    • Enumeration methodology used
    • Complete list of discovered subdomains
    • DNS configuration analysis
    • Identified vulnerabilities

  2. Screenshots (minimum 6):

    • nslookup/dig queries of different types
    • Zone transfer attempt
    • dnsenum results
    • Output from subfinder or amass
    • TXT records analysis
    • Misconfiguration identification

  3. Result files:

    • List of subdomains (subdomains.txt)
    • Complete dnsenum results
    • amass export

  4. Security Analysis (2 pages):

    • Identified risks
    • Potential impact
    • DNS security recommendations

Evaluation Criteria​

CriterionPoints
Mastery of DNS queries (nslookup, dig)20%
Use of enumeration tools25%
Subdomain discovery20%
Configuration and vulnerability analysis20%
Quality of report and recommendations15%

Quick Reference Commands​

Windows (nslookup)​

nslookup example.com
nslookup -type=MX example.com
nslookup -type=NS example.com
nslookup -type=TXT example.com

Linux (dig)​

dig example.com
dig example.com MX
dig example.com ANY
dig @8.8.8.8 example.com
dig axfr @ns1.example.com example.com

Enumeration​

dnsenum example.com
subfinder -d example.com
amass enum -d example.com
fierce --domain example.com
dnsrecon -d example.com -t std

Conclusion​

This lab taught you:

  • DNS queries of all types
  • Zone transfers and their exploitation
  • Subdomain discovery with multiple techniques
  • Automated enumeration tools
  • DNS configuration analysis
  • Identification of DNS vulnerabilities

Key Lessons:

  1. DNS reveals a lot about infrastructure
  2. Misconfigured zone transfers = complete disclosure
  3. Dev/test subdomains often less secure
  4. TXT records can contain sensitive information
  5. Passive enumeration is hard to detect

Next step: Lab 5.3 ARP Spoofing and Man-in-the-Middle!

Lab developed as part of the Operating Systems course - MODULE 5