DNS Deep Dive for Pentesters

TL;DR: DNS translates domain names to IP addresses. For pentesters, it’s a goldmine of reconnaissance data and a frequent attack target. Master DNS enumeration, zone transfers, and DNS-based attacks.

Table of Contents

Quick Reference

Essential DNS Commands

Common DNS Record Types

Common DNS Ports

Why DNS Matters for Pentesters

The First Step in Every Engagement

DNS is typically the first thing you query during reconnaissance. It reveals:

1. Subdomains - Hidden applications, staging servers, admin panels
2. Mail servers - Phishing targets, email security configuration
3. Name servers - Potential zone transfer targets
4. IP addresses - Infrastructure mapping
5. TXT records - Sometimes contain secrets, API keys, or misconfigurations
6. Cloud providers - CNAMEs often reveal AWS, Azure, GCP usage

Real-World Breaches Involving DNS

How DNS Works

TL;DR: DNS is like a phone book for the internet - it translates human-readable names (google.com) to machine-readable IP addresses (142.250.80.46).

The DNS Hierarchy

                    ┌─────────────────┐
                    │   Root Servers  │  (.)
                    │   (13 clusters) │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
        ┌─────▼─────┐  ┌─────▼─────┐  ┌─────▼─────┐
        │   .com    │  │   .org    │  │   .net    │  TLD Servers
        └─────┬─────┘  └───────────┘  └───────────┘
              │
        ┌─────▼─────────────┐
        │   example.com     │  Authoritative NS
        │   (Name Server)   │
        └─────┬─────────────┘
              │
    ┌─────────┼─────────┐
    │         │         │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│  www  │ │  mail │ │  api  │  Individual Records
└───────┘ └───────┘ └───────┘

Components of DNS

DNS Record Types

A Record (Address)

Maps hostname to IPv4 address.

example.com.    IN    A    93.184.216.34

Pentester Use: Find target IP addresses, identify hosting providers.

# Using dig
dig example.com A

# Using nslookup
nslookup example.com

# Using host
host example.com

example.com.    300    IN    A    93.184.216.34

AAAA Record (IPv6 Address)

Maps hostname to IPv6 address.

example.com.    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Pentester Use: IPv6 addresses may have different firewall rules, additional attack surface.

# Using dig
dig example.com AAAA

# Check if IPv6 is configured
dig +short example.com AAAA

MX Record (Mail Exchanger)

Specifies mail servers for a domain.

example.com.    IN    MX    10    mail.example.com.
example.com.    IN    MX    20    backup-mail.example.com.

Pentester Use:

• Identify mail infrastructure
• Phishing target selection
• Check for email security (SPF, DMARC, DKIM)

# Get MX records
dig example.com MX

# Using host
host -t mx example.com

# Check mail server IPs
dig +short $(dig +short example.com MX | head -1 | awk '{print $2}')

example.com.    300    IN    MX    10 mail.example.com.
example.com.    300    IN    MX    20 mail2.example.com.

NS Record (Name Server)

Specifies authoritative name servers.

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

Pentester Use:

• Zone transfer targets
• DNS infrastructure mapping
• Potential subdomain enumeration

# Get name servers
dig example.com NS

# Get name server IPs
dig +short ns1.example.com

TXT Record (Text)

Holds arbitrary text data, often used for verification and email security.

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

Pentester Use:

• SPF records reveal authorized mail senders
• Domain verification tokens (sometimes sensitive)
• Occasionally contain secrets or internal info

# Get all TXT records
dig example.com TXT

# Look for SPF
dig +short example.com TXT | grep spf

# Look for DMARC
dig +short _dmarc.example.com TXT

# Look for DKIM (need selector)
dig +short selector1._domainkey.example.com TXT

# Leaked internal info
"internal-api-key=sk_live_abc123..."

# Cloud verification
"aws-verification=abc123"
"MS=ms12345678"

CNAME Record (Canonical Name)

Alias that points to another domain.

www.example.com.    IN    CNAME    example.com.
blog.example.com.   IN    CNAME    example.ghost.io.

Pentester Use:

• Subdomain Takeover - If CNAME points to unclaimed resource
• Identify third-party services (CDNs, SaaS)
• Understand infrastructure relationships

# Check for CNAME
dig www.example.com CNAME

# Subdomain takeover check
dig blog.example.com CNAME
# If returns: blog.example.com.  CNAME  something.s3.amazonaws.com.
# And the S3 bucket doesn't exist - TAKEOVER POSSIBLE!

SOA Record (Start of Authority)

Contains zone administrative information.

example.com.    IN    SOA    ns1.example.com. admin.example.com. (
                            2023010101 ; Serial
                            3600       ; Refresh
                            1800       ; Retry
                            604800     ; Expire
                            86400 )    ; Minimum TTL

Pentester Use:

• Admin email (admin.example.com = admin@example.com)
• Zone serial number (change tracking)
• DNS infrastructure details

# Get SOA record
dig example.com SOA

# Extract admin email
dig +short example.com SOA | awk '{print $2}' | sed 's/\./@/' | sed 's/@$//'

PTR Record (Pointer)

Reverse DNS - maps IP to hostname.

34.216.184.93.in-addr.arpa.    IN    PTR    example.com.

Pentester Use:

• Discover hostnames from IPs
• Validate target ownership
• Find related infrastructure

# Reverse lookup
dig -x 93.184.216.34

# Using host
host 93.184.216.34

# Bulk reverse lookups
for ip in $(cat ips.txt); do host $ip 2>/dev/null | grep "pointer"; done

SRV Record (Service)

Specifies service locations.

_ldap._tcp.example.com.    IN    SRV    0 100 389 dc1.example.com.
_kerberos._tcp.example.com. IN   SRV    0 100 88  dc1.example.com.

Pentester Use:

• Discover Active Directory domain controllers
• Find internal services
• Service enumeration

# Find AD Domain Controllers
dig _ldap._tcp.dc._msdcs.domain.local SRV

# Find Kerberos servers
dig _kerberos._tcp.domain.local SRV

# Find SIP services
dig _sip._tcp.example.com SRV

DNS Query Process

TL;DR: When you type a URL, your computer asks a series of DNS servers until it finds the IP address.

Step-by-Step Resolution

┌────────┐
│  You   │ 1. "What's the IP for www.example.com?"
│ (Client)│─────────────────────────────────────────────┐
└────────┘                                              │
                                                        ▼
                                                ┌───────────────┐
                                                │   Recursive   │
                                                │   Resolver    │
                                                │  (8.8.8.8)    │
                                                └───────┬───────┘
                    2. Check cache - not found          │
                                                        │
        3. "Who handles .com?"    ┌─────────────────────▼─────────────────┐
           ┌──────────────────────│         Root Server (.)               │
           │                      └───────────────────────────────────────┘
           │
           │  4. "Ask .com TLD servers"
           ▼
    ┌──────────────────┐
    │   .com TLD       │
    │   Server         │
    └────────┬─────────┘
             │
             │  5. "example.com uses ns1.example.com"
             ▼
    ┌──────────────────┐
    │  ns1.example.com │
    │  (Authoritative) │
    └────────┬─────────┘
             │
             │  6. "www.example.com = 93.184.216.34"
             ▼
    ┌───────────────┐
    │   Recursive   │  7. Cache result, return to client
    │   Resolver    │──────────────────────────────────────────┐
    └───────────────┘                                          │
                                                               ▼
                                                        ┌────────┐
                                              8. Got IP │  You   │
                                                        │(Client)│
                                                        └────────┘

DNS Caching Layers

Pentester Note: Cached responses can hide recent changes. Use +nocache or query authoritative directly.

# Query authoritative directly
dig @ns1.example.com www.example.com

# Request no caching
dig +nocache example.com

# Trace the full resolution
dig +trace example.com

# Flush local DNS cache
# Linux (systemd)
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

DNS Enumeration Techniques

TL;DR: DNS enumeration reveals subdomains, infrastructure, and potential attack vectors. Use multiple techniques for comprehensive coverage.

1. Basic Record Enumeration

Query all common record types for a domain.

# Query all record types
dig example.com ANY

# Comprehensive enumeration
for type in A AAAA MX NS TXT SOA CNAME SRV; do
    echo "=== $type Records ==="
    dig +short example.com $type
done

# Using dnsrecon
dnsrecon -d example.com -t std

2. Subdomain Brute Forcing

Guess subdomains using wordlists.

Testing Checklist

• Run basic subdomain enumeration
• Try multiple wordlists (small, medium, large)
• Check for wildcard DNS (*.example.com)
• Use permutation techniques (dev, staging, prod)
• Combine passive and active enumeration

# Using gobuster
gobuster dns -d example.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Using ffuf
ffuf -u http://FUZZ.example.com -w subdomains.txt -v

# Using fierce
fierce --domain example.com

# Using dnsenum
dnsenum example.com

# Using dnsrecon brute
dnsrecon -d example.com -t brt -D /usr/share/wordlists/subdomains.txt

# Check for wildcard
dig nonexistent12345.example.com
# If returns IP, wildcard is configured

3. Passive Subdomain Discovery

Find subdomains without touching target DNS.

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

# Using subfinder (passive)
subfinder -d example.com -silent

# Using amass (passive)
amass enum -passive -d example.com

# Using theHarvester
theHarvester -d example.com -b all

# Google dorking
# site:*.example.com -www

# DNSDumpster API
curl -s "https://api.hackertarget.com/hostsearch/?q=example.com"

# SecurityTrails (requires API key)
curl "https://api.securitytrails.com/v1/domain/example.com/subdomains" \
    -H "APIKEY: your-api-key"

4. Reverse DNS Sweeping

Find hostnames from IP ranges.

# Single reverse lookup
dig -x 192.168.1.1

# Sweep a /24 network
for i in {1..254}; do
    host 192.168.1.$i 2>/dev/null | grep "pointer"
done

# Using dnsrecon
dnsrecon -r 192.168.1.0/24

# Using nmap
nmap -sL 192.168.1.0/24 | grep "("

Zone Transfers

TL;DR: Zone transfers (AXFR) are meant for DNS replication between servers. Misconfigured servers may allow anyone to download the entire zone - a goldmine of information.

What is a Zone Transfer?

┌─────────────────┐         AXFR Request          ┌─────────────────┐
│  Primary DNS    │ ◄─────────────────────────────│  Secondary DNS  │
│  (Master)       │                               │  (Slave)        │
│                 │  ────────────────────────────►│                 │
│  example.com    │        Full Zone Data         │  example.com    │
│  zone file      │        (all records)          │  zone copy      │
└─────────────────┘                               └─────────────────┘

         ▲
         │  AXFR Request (Attacker)
         │
    ┌────┴────┐
    │ Attacker│  If allowed: ALL DNS records exposed!
    └─────────┘

Why It’s Dangerous

A successful zone transfer reveals:

• All subdomains (including internal ones)
• All IP addresses
• Mail servers
• Internal naming conventions
• Network topology hints

Testing Checklist

• Identify all name servers for domain
• Attempt zone transfer on each NS
• Try both TCP and UDP
• Document all discovered records
• Check for internal/staging subdomains

# First, find name servers
dig +short example.com NS

# Attempt zone transfer with dig
dig @ns1.example.com example.com AXFR

# Using host
host -t axfr example.com ns1.example.com

# Using nslookup
nslookup
> server ns1.example.com
> set type=AXFR
> example.com

# Using dnsrecon
dnsrecon -d example.com -t axfr

# Try all name servers
for ns in $(dig +short example.com NS); do
    echo "Trying $ns..."
    dig @$ns example.com AXFR
done

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.
example.com.        3600    IN    MX     10 mail.example.com.
example.com.        3600    IN    A      93.184.216.34
www.example.com.    3600    IN    A      93.184.216.34
mail.example.com.   3600    IN    A      93.184.216.35
internal.example.com. 3600  IN    A      10.0.0.5        ; INTERNAL!
staging.example.com.  3600  IN    A      10.0.0.10       ; STAGING!
admin.example.com.    3600  IN    A      93.184.216.40   ; ADMIN PANEL!

; Transfer failed.

DNS Attacks

1. DNS Cache Poisoning

Inject false DNS records into resolver cache.

┌─────────┐                    ┌───────────┐
│ Victim  │ ──── DNS Query ───►│  Resolver │
└─────────┘                    └─────┬─────┘
                                     │
     ┌───────────────────────────────┼───────────────────────────────┐
     │                               │                               │
     │ Legitimate                    │            Attacker           │
     │   ▼                           │               ▼               │
┌────────────┐                       │        ┌───────────┐          │
│ Real DNS   │ ── Slow Response ────►│◄────── │ Fast Fake │          │
│ Server     │                       │        │ Response  │          │
└────────────┘                       │        └───────────┘          │
     │                               │               │               │
     │                               │               │               │
     └───────────────────────────────┼───────────────┼───────────────┘
                                     │               │
                              Resolver accepts       │
                              first response ────────┘
                                     │
                                     ▼
                              ┌─────────────┐
                              │ Cache now   │
                              │ poisoned    │
                              └─────────────┘

# Check if resolver validates DNSSEC
dig +dnssec example.com

# Check source port randomization
dig porttest.dns-oarc.net TXT

# Expected secure output:
# "Your resolver at X.X.X.X is GOOD: 26 ports seen"

# Vulnerable output:
# "Your resolver at X.X.X.X is POOR: 1 ports seen"

2. DNS Spoofing (MITM)

Intercept and modify DNS responses on the network.

# Using ettercap (MITM + DNS spoof)
# Create dns.txt:
# *.target.com A 192.168.1.100

ettercap -T -q -i eth0 -M arp:remote /192.168.1.1// /192.168.1.50// -P dns_spoof

# Using bettercap
bettercap -iface eth0
> set dns.spoof.domains target.com
> set dns.spoof.address 192.168.1.100
> dns.spoof on
> arp.spoof on

3. DNS Tunneling

Exfiltrate data or establish C2 through DNS queries.

┌─────────────┐     DNS Query: data.encoded.attacker.com    ┌─────────────┐
│   Victim    │ ──────────────────────────────────────────► │  Attacker   │
│   Network   │                                             │  DNS Server │
│             │ ◄────────────────────────────────────────── │             │
└─────────────┘     DNS Response: TXT "encoded response"    └─────────────┘
        │                                                          │
        │                                                          │
   DNS traffic                                               Decode data
   allowed through                                           from queries
   firewall

# Look for unusually long DNS queries
tcpdump -i eth0 port 53 -vv | grep -E "A\?.{50,}"

# Check for high DNS query volume
tcpdump -i eth0 port 53 -c 1000 | wc -l

# Using zeek/bro for DNS analysis
zeek -r capture.pcap local

# Tools that use DNS tunneling:
# - iodine
# - dnscat2
# - dns2tcp

4. DNS Rebinding

Bypass same-origin policy using DNS.

1. Victim visits attacker.com
   └──► DNS returns: attacker.com = 1.2.3.4 (attacker IP)
   └──► Page loads malicious JavaScript

2. JavaScript waits for DNS TTL to expire

3. JavaScript makes request to attacker.com
   └──► DNS now returns: attacker.com = 192.168.1.1 (internal IP!)
   └──► Browser thinks it's same origin
   └──► Access internal resource!

5. Subdomain Takeover

Claim abandoned subdomains pointing to external services.

┌───────────────┐       CNAME       ┌──────────────────────┐
│ blog.target.  │ ─────────────────►│ target.ghost.io      │
│     com       │                   │ (DOESN'T EXIST!)     │
└───────────────┘                   └──────────────────────┘
        │
        │ Attacker registers target.ghost.io
        ▼
┌───────────────┐       CNAME       ┌──────────────────────┐
│ blog.target.  │ ─────────────────►│ target.ghost.io      │
│     com       │                   │ (ATTACKER CONTROLLED)│
└───────────────┘                   └──────────────────────┘

Vulnerable Services:

• AWS S3 (NXDOMAIN on bucket)
• GitHub Pages
• Heroku
• Azure
• Ghost.io
• Shopify
• Many more…

Testing Checklist

• Enumerate all subdomains
• Check CNAME records for each
• Identify external service CNAMEs
• Verify service ownership/existence
• Attempt to claim abandoned services

# Find CNAMEs
dig +short subdomain.target.com CNAME

# Check if service exists
curl -I https://subdomain.target.com
# 404 from service provider = potential takeover

# Using subjack
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -v

# Using nuclei
nuclei -l subdomains.txt -t takeovers/

# Manual check for S3
dig +short s3.target.com CNAME
# Returns: bucket-name.s3.amazonaws.com
aws s3 ls s3://bucket-name
# "NoSuchBucket" = TAKEOVER POSSIBLE

DNS Security (DNSSEC)

TL;DR: DNSSEC adds cryptographic signatures to DNS responses, preventing tampering. Check if targets use it and look for misconfigurations.

How DNSSEC Works

┌─────────────────────────────────────────────────────────┐
│                    DNSSEC Chain of Trust                │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Root Zone (.)         ──► Signs .com DS record         │
│       │                                                 │
│       ▼                                                 │
│  .com TLD              ──► Signs example.com DS record  │
│       │                                                 │
│       ▼                                                 │
│  example.com           ──► Signs A, MX, TXT records     │
│                                                         │
│  Each level vouches for the level below                 │
│                                                         │
└─────────────────────────────────────────────────────────┘

DNSSEC Record Types

DNSSEC Vulnerabilities

# Check if domain uses DNSSEC
dig +dnssec example.com

# Verify DNSSEC chain
dig +sigchase +trusted-key=./root.key example.com

# Check for DNSKEY
dig example.com DNSKEY

# Check DS record at parent
dig example.com DS

# NSEC walking (zone enumeration)
# If using NSEC (not NSEC3):
ldns-walk @ns1.example.com example.com

# Or using dnsrecon
dnsrecon -d example.com -t nsec

DNS Over HTTPS/TLS

TL;DR: DoH/DoT encrypt DNS queries, hiding them from network monitoring. Know how to detect and analyze these protocols.

Comparison

Security Implications

For Pentesters:

• Client DNS queries hidden from network inspection
• Can bypass DNS-based security controls
• Exfiltration via DoH is harder to detect

For Defenders:

• Can’t inspect DNS for threat detection
• DNS-based blocklists may be bypassed
• Need TLS inspection or endpoint controls

# Query using DoH (cloudflare)
curl -H "accept: application/dns-json" \
    "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

# Using kdig for DoT
kdig -d @1.1.1.1 +tls example.com

# Using dog (modern DNS client)
dog example.com --tls @1.1.1.1

# Detect DoH traffic
# Look for connections to known DoH providers:
# - cloudflare-dns.com
# - dns.google
# - doh.opendns.com

Tools for DNS Testing

Command Line Tools

Online Tools

Practice Labs

Beginner

Intermediate

Home Lab Setup

# Set up BIND9 for practice
apt install bind9 bind9utils

# Configure zone for testing zone transfers
# Edit /etc/bind/named.conf.local
zone "testlab.local" {
    type master;
    file "/etc/bind/zones/testlab.local";
    allow-transfer { any; };  # Vulnerable config for practice
};

# Create zone file at /etc/bind/zones/testlab.local
$TTL    604800
@       IN      SOA     ns1.testlab.local. admin.testlab.local. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.testlab.local.
ns1     IN      A       192.168.1.10
www     IN      A       192.168.1.11
mail    IN      A       192.168.1.12
secret  IN      A       192.168.1.100

Glossary

What’s Next?

Now that you understand DNS, continue your learning path:

Summary

DNS is foundational for penetration testing:

1. Enumeration - DNS reveals subdomains, infrastructure, and services
2. Zone Transfers - Misconfigured servers leak entire zones
3. Attacks - Cache poisoning, spoofing, tunneling, rebinding
4. Subdomain Takeover - Dangling CNAMEs can be claimed
5. DNSSEC - Adds security but can be misconfigured
6. DoH/DoT - Encrypted DNS changes detection landscape

Always include thorough DNS enumeration in your reconnaissance phase. The information gathered here guides your entire engagement.

Found this guide helpful? Check out the other posts in the SecureKhan penetration testing series.