Part 6 – DNS Records, Zone Discovery and Wildcard Handling

Introduction

DNS looks boring until you realise how much it reveals.
Before a web app responds, DNS decides where your request goes.
That small decision leaks architecture, cloud usage, third-party services and sometimes serious security gaps.

In this part, we will slow down and read DNS properly.
Not theory.
Not memorising record types.
Only what actually helps in web app recon.

Think of DNS as the wiring diagram behind the application.

Why DNS matters in web app recon

DNS decides which server handles traffic
Misconfigured records expose internal or forgotten infrastructure
CNAME chains often point to third-party services
TXT records leak verification tokens and internal tooling
Wildcard DNS creates false positives if you do not handle it correctly

If CT logs show you names, DNS shows you relationships.

What to check in DNS (only what matters)

A records
Point directly to IP addresses.

AAAA records
IPv6 equivalents of A records.

CNAME records
Aliases pointing to other domains or cloud services.

TXT records
Verification tokens, SPF, DKIM, ownership proofs.

MX records
Mail routing, sometimes reveals internal mail providers.

NS records
Authoritative name servers and DNS providers.

SOA record
Zone ownership and refresh behaviour.

We focus on these. Ignore the rest unless needed.

Tools you will use

dig
dnsx
massdns
nslookup
host
amass (DNS enrichment mode)
jq, grep, sort

Simple tools. Strong signal.

Step-by-step DNS recon workflow

1. Basic DNS snapshot (starting point)

Run this on your main domain first.

dig example.com ANY +noall +answer

What this tells you

A and AAAA records
Name servers
Sometimes TXT and MX records

This gives a quick overview of how the domain is structured.

2. Checking A and AAAA records

dig example.com A +short
dig example.com AAAA +short

Why this matters

Multiple IPs may indicate load balancers
IP ranges can reveal cloud providers
IPv6-only services are often forgotten in testing

Tag these IPs for later IP and ASN mapping.

3. CNAME discovery (very important)

dig www.example.com CNAME +short

Look carefully at the output.

Examples:

example.azurewebsites.net
example.s3.amazonaws.com
example.fastly.net

These immediately tell you:

Cloud provider
Potential takeover scenarios
External dependencies

Always save CNAME targets separately.

4. Bulk DNS enrichment with dnsx

Once you have a subdomain list from Parts 3 and 5:

dnsx -l subdomains.txt -a -aaaa -cname -resp -silent -o dns_enriched.txt

What you get

IPs
IPv6
CNAMEs
Resolution confirmation

This becomes your DNS inventory file.

TXT records – small but powerful

TXT records often expose:

Domain ownership verification
Google Workspace or Microsoft tenant IDs
SPF and DKIM configurations
Third-party service integrations

Check TXT records:

dig example.com TXT +short

Also check subdomains:

dig _github-challenge-example.example.com TXT +short

Why attackers care

Tenant IDs help in phishing and auth research
Third-party integrations show trust relationships

Do not abuse this data. Use it to understand architecture.

MX records and mail infrastructure

dig example.com MX +short

This reveals:

Email provider
Mail routing priority
Sometimes internal mail servers

Mail infrastructure matters for:

Password reset flows
Email-based authentication
Phishing risk analysis

NS and SOA records

dig example.com NS +short
dig example.com SOA +short

Why this matters

Shows DNS provider
Helps identify delegated zones
Useful during subdomain takeover analysis

Zone transfer checks (AXFR)

Most zones block this.
But when it works, it is huge.

First identify name servers:

dig example.com NS +short

Then try zone transfer:

dig @ns1.example.com example.com AXFR

If it succeeds

You get the full zone file
All subdomains in one go

If it fails

That is normal
Move on without forcing it

Never brute force AXFR.

Wildcard DNS detection (critical step)

Wildcard DNS creates fake positives during enumeration.

Test with random subdomain:

dig random123456.example.com A +short

If it resolves:

You have wildcard DNS

Confirm pattern:

for i in {1..5}; do dig random$i.example.com +short; done

If all return the same IP or CNAME:

Treat results carefully

Filtering wildcard noise

Do not trust resolution alone.
Always combine with HTTP checks later.

Strategy:

Compare content length
Compare headers
Compare page titles

Wildcard DNS is common on CDNs.
Filtering is mandatory.

Detecting dangling DNS records

Dangling records happen when:

DNS points to a service that no longer exists
Cloud resource is deleted but DNS remains

Common patterns:

CNAME to cloud services
NXDOMAIN or service-specific error responses

Example check:

dig orphan.example.com CNAME +short

Then open the CNAME target in browser.

If service says:

“No such app”
“Resource not found”

This becomes a takeover candidate (verify responsibly).

How DNS data feeds takeover checks

From DNS recon, create a list of:

CNAMEs pointing to external services
Unresolved targets
Error-returning services

These go directly into:

Subdomain takeover checks
Cloud footprint analysis

DNS is the bridge between names and ownership.

Real-world use-cases

Finding forgotten admin panels via old A records
Discovering staging apps via CNAMEs
Identifying cloud services used by the app
Spotting takeover-prone dangling records
Understanding trust relationships between services

These are repeatable wins.

Mini lab exercise (30 minutes)

Use a lab domain or one you own.
Run basic DNS snapshot:

dig yourdomain.com ANY +noall +answer

Extract A, CNAME, TXT:

dig yourdomain.com A +short
dig yourdomain.com CNAME +short
dig yourdomain.com TXT +short

Test wildcard DNS:

dig random-test-123.yourdomain.com +short

Enrich subdomains with dnsx:

dnsx -l subdomains.txt -a -cname -resp -silent -o dns_inventory.txt

Pick one interesting CNAME and research the service it points to.

Write short notes in your tracker.

Common mistakes and how to avoid them

Mistake: Ignoring DNS after subdomain discovery
Fix: DNS explains ownership and trust

Mistake: Trusting wildcard DNS blindly
Fix: Always validate via HTTP behaviour

Mistake: Skipping TXT records
Fix: TXT records often reveal integrations

Mistake: Forcing zone transfers
Fix: Try once. Move on if blocked

Quick command summary

A and AAAA:

dig example.com A +short
dig example.com AAAA +short

CNAME:

dig www.example.com CNAME +short

TXT:

dig example.com TXT +short

Bulk DNS enrichment:

dnsx -l subdomains.txt -a -cname -resp -silent -o dns_enriched.txt

Wildcard test:

dig random123.example.com +short

Zone transfer attempt:

dig @ns1.example.com example.com AXFR

What to do after this Part

Feed CNAME targets into takeover analysis
Use DNS-resolved hosts for URL and JS collection
Tag cloud providers for later cloud-specific checks
Combine DNS and CT data for higher confidence

DNS recon sharpens everything that comes next.

Next post preview

Part 7 – Subdomain Permutation and Brute Force (Advanced)

We will cover:

Smart wordlists
Context-aware permutations
ffuf and shuffledns pipelines
Reducing noise
When brute force actually makes sense

This builds directly on DNS and CT work.

Closing thought

DNS is quiet.
That is why it is powerful.

Read it carefully and it will tell you how the application is really built.

Disclaimer

This material is for educational purposes only. Use it ethically and only against targets you own or have explicit permission to test. Do not use any techniques described here in ways that break laws, platform rules, or third-party rights. If in doubt, stop and get permission.

Share the Post:

CyberXsociety