Lab 15 DNS Security Investigation

Mission Overview

Welcome to Lab 15 — DNS Security Investigation.

In Lab 14, you learned how to capture network traffic, identify protocols, reconstruct TCP conversations, and correlate packet evidence.

Now you will focus specifically on one of the most valuable sources of network-security evidence:

Domain Name System — DNS

Nearly every modern application and endpoint depends on DNS.

Before a system communicates with:

portal.example.test

it often first needs to determine:

Which IP address belongs to this name?

That means DNS can provide investigators with evidence about:

• which domains a system attempted to access

• which DNS server answered

• what address was returned

• whether resolution succeeded

• whether communication followed

• when those events occurred

Mission Goal: Capture and analyze DNS activity in an authorized training environment, understand common DNS record types and response behavior, reconstruct domain-to-IP resolution timelines, identify unusual DNS patterns, and produce a DNS Security Investigation Report.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	DNS Security Investigation
Secondary Skill	Network Evidence Correlation
Environment	Isolated GoHackersCloud Lab
Primary Tools	Wireshark, dig, nslookup
Evidence	PCAP + DNS query/response records
Primary Outcome	DNS Investigation Register
Testing Type	Passive Analysis + Controlled Queries
Safety Level	Authorized Lab Only

Learning Objectives

By completing this lab, you will be able to:

• explain the purpose of DNS

• understand DNS clients and resolvers

• distinguish recursive and authoritative DNS concepts

• identify DNS queries and responses

• understand common DNS record types

• analyze A and AAAA records

• understand CNAME relationships

• review MX and TXT records

• identify DNS response codes

• recognize NXDOMAIN responses

• understand DNS TTL

• analyze DNS over UDP and TCP conceptually

• capture DNS traffic

• filter DNS packets in Wireshark

• use dig safely

• use nslookup

• correlate DNS answers with subsequent connections

• build DNS timelines

• classify expected and unusual DNS activity

• create DNS evidence suitable for security investigations

DNS Investigation Methodology

Use:

Query → Resolver → Response → Destination → Communication → Correlation → Security Conclusion

Conceptually:

Application
    │
    ▼
Domain Name
    │
    ▼
DNS Query
    │
    ▼
Resolver
    │
    ▼
DNS Response
    │
    ▼
IP Address
    │
    ▼
Network Connection
    │
    ▼
Security Interpretation

The important question is not simply:

“Which DNS queries exist?”

Ask:

“Why was this name resolved, what answer was returned, and what happened afterward?”

Lab Architecture

Example:

                  GHC Ethical Hacking Lab
                       192.168.56.0/24
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
           Kali           DNS Server        Web Server
      192.168.56.10      192.168.56.53     192.168.56.30
             │                │
             │ DNS Query      │
             ├───────────────►│
             │                │
             │ DNS Response   │
             │◄───────────────┤
             │
             │ TCP/HTTP
             └────────────────────────────────►

Your actual lab may use:

• a local DNS server

• a router-provided resolver

• a virtual lab resolver

• another designated DNS system

Use only approved systems.

Part 1 — Confirm Scope

Document:

Client:

Client IP:

Authorized DNS Server:

DNS Server IP:

Authorized Training Domain:

Authorized Subdomains:

Capture Interface:

External DNS:
Allowed / Not Required

Testing Start:

Excluded Domains:

Avoid generating unnecessary DNS traffic to unrelated public domains.

Part 2 — Rules of Engagement

Permitted

• querying approved lab domains

• capturing your own DNS traffic

• examining DNS packets

• comparing resolver answers

• querying common DNS record types for authorized training domains

• analyzing failed lookups

• correlating DNS to subsequent network traffic

• reviewing TTL values

• documenting DNS patterns

Not Required

• DNS cache poisoning

• spoofing

• resolver exploitation

• DNS amplification

• denial-of-service testing

• unauthorized zone transfers

• DNS tunneling

• exfiltration

• altering DNS records

• querying private third-party infrastructure unnecessarily

The lab focuses on:

DNS as security evidence.

Part 3 — Create the Workspace

Create:

Ethical-Hacking-Labs/
└── Lab-15/
    ├── Notes/
    ├── Captures/
    │   ├── baseline/
    │   ├── dns-a/
    │   ├── dns-cname/
    │   ├── dns-failure/
    │   └── combined/
    ├── Evidence/
    │   ├── Queries/
    │   ├── Responses/
    │   ├── Timelines/
    │   └── Correlation/
    ├── Screenshots/
    ├── Findings/
    └── Report/

Create:

Lab-15-Investigation-Journal.md

Suggested structure:

# Lab 15 — DNS Security Investigation

## Mission Objective

## Scope

## DNS Architecture

## Resolver

## Authorized Domains

## Queries

## Responses

## A Records

## AAAA Records

## CNAME Records

## MX Records

## TXT Records

## Failed Lookups

## TTL Analysis

## DNS Timeline

## Network Correlation

## Expected Activity

## Unusual Activity

## Findings

## Evidence

## Recommendations

## Lessons Learned

Part 4 — Understand DNS

Humans usually prefer names:

training.lab

Computers communicate using addresses such as:

192.168.56.30

DNS provides the mapping:

training.lab
      ↓
192.168.56.30

At a simplified level:

Application
    │
    ▼
DNS Resolver
    │
    ▼
IP Address
    │
    ▼
Application Connects

Part 5 — Identify Your Configured Resolver

On Kali, inspect:

cat /etc/resolv.conf

You may see:

nameserver 192.168.56.53

Record:

Configured Resolver:

Resolver IP:

Search Domain:
If configured

Depending on your Linux environment, resolver configuration may also be managed by systemd-resolved or NetworkManager.

Part 6 — Use resolvectl Where Available

Run:

resolvectl status

where supported.

Observe:

• interfaces

• DNS servers

• search domains

• resolver configuration

Do not change the settings.

Part 7 — Understand Stub vs Recursive Resolver

A client commonly sends a query to a resolver.

Conceptually:

Client
  │
  ▼
Local / Recursive Resolver
  │
  ▼
DNS Infrastructure
  │
  ▼
Authoritative Answer

The client does not necessarily contact every DNS server itself.

Part 8 — Understand the DNS Hierarchy

Conceptually:

                  Root
                   │
                   ▼
                  TLD
               .com / .org
                   │
                   ▼
            Authoritative DNS
                   │
                   ▼
           host.example.test

The exact process can be influenced by:

• caching

• recursive resolvers

• forwarding

• local zones

Part 9 — Capture a DNS Baseline

Start Wireshark on the authorized lab interface.

Capture for approximately:

30–60 seconds

without intentionally creating traffic.

Use the display filter:

dns

Record:

Queries Observed:

Resolvers:

Domains:

Unexpected DNS Activity:

Save:

dns-baseline.pcapng

Part 10 — Generate a Controlled A Record Query

For an approved training hostname:

dig training.lab A

Replace training.lab with your actual training domain.

The result may include:

QUESTION SECTION

and:

ANSWER SECTION

Record only relevant information.

Part 11 — Use Short Output

For a simple answer:

dig +short training.lab A

Example:

192.168.56.30

This can help verify the expected result quickly.

Part 12 — Understand an A Record

An A record maps a hostname to an IPv4 address.

Example:

training.lab
     │
     ▼
A
     │
     ▼
192.168.56.30

Create:

Name	Record	Value
training.lab	A	192.168.56.30

Part 13 — Capture the A Query in Wireshark

Apply:

dns

Find your query.

Inspect:

Domain Name System

Record:

Transaction ID:

Flags:

Questions:

Query Name:

Query Type:

Query Class:

Part 14 — Analyze the A Response

Find the matching response.

Record:

Transaction ID:

Query Name:

Answer Type:

Answer Address:

TTL:

Response Code:

The query and response can be paired using the transaction ID and conversation context.

Part 15 — Understand DNS Transaction IDs

A DNS request includes an identifier.

Conceptually:

Query
ID 0x1234
    │
    ▼
Resolver
    │
    ▼
Response
ID 0x1234

This helps clients associate responses with requests.

Do not use transaction IDs alone as a security conclusion.

Part 16 — Understand TTL

DNS records commonly contain a:

Time To Live — TTL

Example:

training.lab
A
192.168.56.30
TTL: 300

The TTL indicates how long the answer may typically be cached.

Conceptually:

DNS Answer
    │
    ▼
Cache
    │
    ▼
TTL Expires
    │
    ▼
Resolve Again

Part 17 — Understand Caching

Suppose the first request generates DNS traffic.

A second request shortly afterward may produce no new external DNS query because the result is cached.

This is important during investigations.

Absence of a DNS packet does not prove the hostname was not used.

Part 18 — Query an AAAA Record

Run:

dig training.lab AAAA

An AAAA record maps a hostname to IPv6.

Conceptually:

training.lab
      ↓
AAAA
      ↓
IPv6 Address

If the lab does not use IPv6, the response may contain no answer.

Document that accurately.

Part 19 — Understand CNAME Records

A CNAME creates an alias relationship.

Example:

portal.training.lab
        │
        ▼
CNAME
        │
        ▼
web.training.lab
        │
        ▼
A
        │
        ▼
192.168.56.30

This can create a chain of DNS evidence.

Part 20 — Query a CNAME

If your training environment provides one:

dig portal.training.lab CNAME

Record:

Alias:

Canonical Name:

TTL:

Do not invent a CNAME if the lab does not contain one.

Part 21 — Follow the CNAME Relationship

If:

portal.training.lab

points to:

web.training.lab

query:

dig web.training.lab A

Now build:

portal.training.lab
        ↓
web.training.lab
        ↓
192.168.56.30

This becomes part of your DNS relationship map.

Part 22 — Understand MX Records

MX records identify mail-exchange infrastructure for a domain.

Example:

example.test
     │
     ▼
MX
     │
     ▼
mail.example.test

For an authorized training domain:

dig training.lab MX

Only query record types relevant to the lab.

Part 23 — Understand MX Priority

An MX response may conceptually contain:

10 mail1.training.lab
20 mail2.training.lab

Lower preference values generally indicate higher priority.

Record:

Priority	Mail Host
10	mail1.training.lab
20	mail2.training.lab

Part 24 — Understand TXT Records

TXT records can hold text-based information used for many purposes.

They may support:

• domain verification

• mail-security policies

• service configuration

For an authorized training domain:

dig training.lab TXT

Do not automatically interpret a TXT record as sensitive information.

Context matters.

Part 25 — Review NS Records

NS records identify authoritative nameservers.

Use:

dig training.lab NS

Record:

Domain:

Authoritative Name Servers:

This helps map DNS infrastructure.

Part 26 — Build the DNS Record Inventory

Create:

Name	Record Type	Value	TTL	Source
training.lab	A	192.168.56.30		dig
portal.training.lab	CNAME	web.training.lab		dig
training.lab	MX	mail.training.lab		dig
training.lab	NS	dns.training.lab		dig

Only include records that actually exist.

Part 27 — Understand Common DNS Record Types

Record	Purpose
A	IPv4 address
AAAA	IPv6 address
CNAME	Alias
MX	Mail server
NS	Name server
TXT	Text/service policy
PTR	Reverse lookup
SOA	Zone authority information

You do not need to memorize every DNS record type for this lab.

Part 28 — Perform a Reverse Lookup

For your authorized lab address:

dig -x 192.168.56.30

Reverse DNS commonly uses a:

PTR

record.

Record:

IP:

PTR Name:

Response:

A missing PTR record does not mean the host is insecure.

Part 29 — Use nslookup

As an alternative:

nslookup training.lab

Record:

Resolver:

Name:

Address:

Compare this with dig.

The tools may present information differently but rely on DNS resolution.

Part 30 — Generate a Failed Lookup

Use an explicitly fictional name within your lab namespace.

Example:

dig does-not-exist.training.lab A

Do not use arbitrary external domains.

Capture the response.

Part 31 — Understand NXDOMAIN

A response may return:

NXDOMAIN

Meaning conceptually:

The requested DNS name does not exist in the relevant DNS namespace.

Record:

Query:

Response Code:

Answer:

Part 32 — Identify NXDOMAIN in Wireshark

Use:

dns

Select the response.

Look for the DNS response code.

Create:

Time	Client	Query	Result
	Kali	does-not-exist.training.lab	NXDOMAIN

Part 33 — Understand Why NXDOMAIN Matters

During security investigations, many failed lookups may indicate:

• mistyped names

• broken software

• outdated configuration

• service discovery

• misconfigured applications

• unusual automated activity

But:

NXDOMAIN ≠ malicious activity.

Context and frequency matter.

Part 34 — Generate a Small Failure Pattern

Within the lab only, manually query a few designated nonexistent training names.

Example:

lab-missing-01.training.lab
lab-missing-02.training.lab
lab-missing-03.training.lab

Keep the number small.

The goal is simply to see how multiple failed queries appear in packet evidence.

Part 35 — Compare Successful vs Failed Resolution

Successful

Query
  ↓
NOERROR
  ↓
Answer
  ↓
IP

Failed

Query
  ↓
NXDOMAIN
  ↓
No Requested Host

This pattern is useful when building DNS timelines.

Part 36 — Understand DNS Response Codes

Common codes include:

Code	Meaning
NOERROR	Query processed successfully
FORMERR	Format error
SERVFAIL	Server failed to complete request
NXDOMAIN	Name does not exist
REFUSED	Server refuses query

Not every non-zero response is a security issue.

Part 37 — Investigate SERVFAIL Conceptually

If you encounter:

SERVFAIL

possible causes can include:

• resolver failure

• upstream DNS issues

• DNSSEC validation problem

• authoritative server problems

• configuration errors

Document the evidence before assigning cause.

Part 38 — Understand UDP and TCP DNS

Traditional DNS commonly uses:

UDP/53

but DNS can also use:

TCP/53

for certain situations.

The investigator should understand:

DNS
   ≠
Always UDP

Part 39 — Filter DNS UDP Traffic

Use:

udp.port == 53

or:

dns && udp

Record whether your queries use UDP.

Part 40 — Filter DNS TCP Traffic

Use:

dns && tcp

You may see none during the lab.

That is acceptable.

Document:

TCP DNS observed:
Yes / No

Part 41 — Correlate DNS with Web Traffic

Start a clean capture.

Then:

1. perform an approved DNS lookup

2. browse to the resolved training service

3. stop the capture

You should conceptually observe:

DNS Query
    ↓
DNS Response
    ↓
TCP SYN
    ↓
TCP Connection
    ↓
HTTP / TLS

Part 42 — Build the Correlation Timeline

Example:

Time	Event
10:10:01	Query training.lab
10:10:01	Answer 192.168.56.30
10:10:02	TCP SYN to .30:443
10:10:02	TLS connection
10:10:03	Encrypted application traffic

This is far stronger than reviewing DNS alone.

Part 43 — Understand Domain-to-IP Correlation

Your investigation might establish:

User/Application
       ↓
training.lab
       ↓
192.168.56.30
       ↓
TCP/443

This connects:

Name → Address → Communication

Part 44 — Build the DNS Communication Map

Example:

                    Kali
                     │
                     │ DNS
                     ▼
                 Resolver
                     │
                     ▼
              training.lab
                     │
                     ▼
              192.168.56.30
                     │
                     ▼
                  TCP/443
                     │
                     ▼
              Training Web App

Part 45 — Filter Queries Only

Wireshark can distinguish query and response packets.

A commonly useful display filter is:

dns.flags.response == 0

This displays DNS queries.

Record the query names.

Part 46 — Filter Responses Only

Use:

dns.flags.response == 1

This displays DNS responses.

Compare the number of requests and responses.

Part 47 — Filter a Specific DNS Name

Where supported by your Wireshark version, use an appropriate DNS-name field filter for the training name.

Alternatively:

1. identify one known DNS packet

2. inspect the query-name field

3. right-click the field

4. apply it as a display filter

This avoids guessing syntax if versions differ.

Part 48 — Review DNS Packet Timing

Record:

Query Time:

Response Time:

A slow DNS response can contribute to application delays.

But one slow response does not automatically indicate DNS attack activity.

Part 49 — Understand Resolver Caching in Evidence

Run:

dig training.lab A

twice.

Compare:

Query Time

TTL

Depending on the resolver and caching configuration, you may observe changes.

Do not expect identical results in every environment.

Part 50 — Understand Negative Caching

Failed DNS responses can also be cached.

Conceptually:

NXDOMAIN
    ↓
Negative Cache
    ↓
Repeated Query May Not Reach Authoritative Infrastructure Immediately

This matters when interpreting DNS evidence.

Part 51 — Analyze TTL Patterns

Suppose multiple answers have TTL values:

300
300
300

and another:

5

Do not automatically classify the low TTL as malicious.

Possible legitimate reasons include:

• load balancing

• dynamic infrastructure

• failover

• CDN architecture

DNS findings require context.

Part 52 — Understand High Query Volume

Large DNS volumes can have many legitimate explanations:

• browsing

• cloud applications

• endpoint software

• updates

• telemetry

• service discovery

Security investigations should focus on:

Pattern + Context + Destination + Timing

not volume alone.

Part 53 — Identify Repeated Queries

Use Wireshark statistics or filtering to look for repeated queries.

Create:

Query	Count	Expected
training.lab	3	Yes
missing.training.lab	5	Lab-generated

Do not create huge query volumes for demonstration.

Part 54 — Understand Unusual DNS Patterns

Patterns that might warrant investigation include:

• repeated failed names

• unusual domains

• unexpected resolvers

• very long labels

• high-frequency requests

• domains inconsistent with host role

• new domains appearing immediately before suspicious connections

These are investigative leads.

They do not independently prove malicious activity.

Part 55 — Long DNS Names

A legitimate DNS name can be long.

Therefore:

Long Domain Name
       ≠
DNS Tunneling

Tunneling assessment generally requires multiple indicators such as:

• repetitive structured queries

• unusual lengths

• high entropy

• high frequency

• specific record types

• traffic volume

• behavioral context

This lab does not attempt DNS tunneling.

Part 56 — Understand DNS Tunneling Conceptually

Conceptually, DNS can be abused to encode information into queries or responses.

However, this lab focuses only on recognizing the investigative indicators, not creating such traffic.

Security analysts should correlate:

DNS Pattern
    +
Endpoint Activity
    +
Network Connections
    +
Threat Intelligence
    +
Business Context

before drawing conclusions.

Part 57 — Identify the Resolver Used

Your host may be expected to use:

192.168.56.53

Suppose you instead observe queries to another DNS server.

That may deserve investigation.

Create:

Client	Resolver	Expected
Kali	192.168.56.53	Yes
Web Server	192.168.56.53	Yes
Unknown	192.168.56.99	Review

Part 58 — Why Unexpected Resolvers Matter

Organizations often use approved resolvers to provide:

• logging

• filtering

• policy enforcement

• threat detection

• consistent name resolution

Direct use of an unexpected resolver can reduce visibility or indicate configuration drift.

But confirm business requirements before creating a finding.

Part 59 — Review DNS Source Ports

You may observe communication such as:

192.168.56.10:54321
        ↓
192.168.56.53:53

Port 53 is the DNS server port.

The client typically uses an ephemeral source port.

This parallels the TCP client-port concept from Lab 14.

Part 60 — Correlate DNS with Process Evidence Conceptually

Network evidence may tell you:

192.168.56.10 queried training.lab

Endpoint evidence can sometimes answer:

Which process generated the query?

This introduces an important investigation model:

DNS
 +
Network
 +
Endpoint
 =
Stronger Attribution

You will explore this more deeply in SOC and incident-response labs.

Part 61 — Build the DNS Investigation Register

Create:

ID	Time	Client	Resolver	Query	Type	Result	Follow-Up
DNS-01		Kali	Resolver	training.lab	A	NOERROR	Web connection
DNS-02		Kali	Resolver	missing.training.lab	A	NXDOMAIN	Expected lab
DNS-03		Web	Resolver	unknown.lab	A	NOERROR	Investigate

Part 62 — Build the DNS Relationship Map

Example:

portal.training.lab
        │
        │ CNAME
        ▼
web.training.lab
        │
        │ A
        ▼
192.168.56.30
        │
        │ TCP/443
        ▼
Training Web Server

This relationship map can explain why the system connected to a particular address.

Part 63 — Build the DNS Timeline

Example:

10:10:01
Query training.lab A
       ↓
10:10:01
Answer 192.168.56.30
       ↓
10:10:02
TCP 192.168.56.30:443
       ↓
10:10:02
TLS handshake
       ↓
10:10:03
Application communication

This is a complete investigative story.

Part 64 — Finding Example: Unexpected DNS Resolver

Finding:
System uses a DNS resolver outside the approved lab configuration.

Observation:
Network evidence showed DNS queries from the training host to a
resolver not present in the approved DNS architecture.

Security Relevance:
Use of unauthorized resolvers may bypass expected DNS logging,
filtering, or policy controls.

Recommendation:
Restrict DNS resolution to approved resolvers where appropriate
and investigate configuration that directs hosts elsewhere.

Do not report this unless the resolver is genuinely unexpected.

Part 65 — Observation Example: Repeated NXDOMAIN

Observation:
Training endpoint generated repeated failed DNS queries.

Evidence:
The PCAP contains multiple NXDOMAIN responses for a series of
nonexistent training hostnames.

Security Relevance:
Repeated lookup failures can result from misconfiguration,
broken applications, or automated activity.

Next Step:
Correlate the query names and timestamps with endpoint process
and application evidence.

Part 66 — Positive Control Example

Positive Control:
Host uses the designated DNS resolver.

Evidence:
All observed DNS requests from the training endpoint were sent
to the approved internal resolver.

Security Value:
Centralized resolution supports consistent DNS policy,
monitoring, and investigation.

Part 67 — Avoid Unsupported Conclusions

Do not write:

The endpoint is infected because it generated DNS queries.

Instead:

The endpoint generated DNS queries to the following names.
Further correlation is required to establish whether the
activity is expected.

Professional investigation separates:

Evidence from interpretation.

Part 68 — Confidence Levels

Use:

Confirmed

Direct DNS evidence establishes the event.

Probable

Evidence strongly supports a conclusion but additional context is required.

Possible

Interesting activity requiring further evidence.

Expected

Matches the lab architecture and generated activity.

Unexplained

Observed but not yet attributable.

Part 69 — Evidence Requirements

Capture:

Evidence 01

DNS resolver configuration.

Evidence 02

Baseline DNS capture.

Evidence 03

A query.

Evidence 04

A response.

Evidence 05

AAAA query.

Evidence 06

CNAME relationship where available.

Evidence 07

MX record where available.

Evidence 08

TXT record where available.

Evidence 09

PTR lookup.

Evidence 10

NXDOMAIN query.

Evidence 11

DNS query-only filter.

Evidence 12

DNS response-only filter.

Evidence 13

Successful DNS-to-network correlation.

Evidence 14

DNS relationship map.

Evidence 15

DNS timeline.

Evidence 16

DNS Investigation Register.

Evidence 17

Final PCAP.

Evidence 18

Evidence-file hash.

Part 70 — Preserve the PCAP

Save:

dns-investigation.pcapng

Hash it:

sha256sum dns-investigation.pcapng

Record:

Evidence File:

SHA-256:

Capture Date:

Capture Interface:

Analyst:

Scope:

Keep an unchanged original.

Part 71 — Mission Challenge

Generate a controlled sequence:

1. Start Wireshark

2. Query training hostname

3. Query a designated nonexistent hostname

4. Browse the resolved web service

5. Stop Capture

6. Analyze DNS + TCP/TLS

Then answer:

Client:

Resolver:

Training Domain:

A Record:

AAAA Record:

CNAME:
If applicable

MX:
If applicable

TXT:
If applicable

PTR:

Successful Query:

Successful Response:

Failed Query:

Failed Response Code:

NXDOMAIN Observed:

TTL:

DNS Transport:

DNS Server Port:

Query Source Port:

Resolved IP:

Connection After Resolution:

Destination Port:

HTTP/TLS Observed:

Approved Resolver Used:

Unexpected Resolver:

Repeated Queries:

Unexpected Domains:

Highest-Priority Observation:

Final Conclusion:

Part 72 — What Not to Do

This lab does not require:

DNS cache poisoning

DNS spoofing

DNS amplification

Resolver exploitation

Zone modification

Unauthorized zone transfers

DNS tunneling

DNS exfiltration

Large query generation

Denial-of-service testing

Querying real private domains without authorization

The objective is:

Observe → Resolve → Correlate → Explain

Part 73 — Troubleshooting

dig Is Missing

On some systems, the DNS utilities package may not be installed.

Use:

nslookup training.lab

or the resolver tools already present in the lab.

Do not modify the environment unless installation is part of the lab design.

DNS Filter Shows Nothing

If you access:

http://192.168.56.30

directly, DNS is not required.

Use an approved hostname instead.

Query Does Not Appear in Capture

Possible causes include:

• wrong interface

• local cache

• another resolver interface

• encrypted DNS

• query generated before capture started

Check the network path.

dig Returns No Answer

Possible explanations include:

• record does not exist

• wrong record type

• wrong DNS server

• DNS configuration issue

• authoritative zone does not contain that record

Record the actual response.

CNAME Is Not Present

Not every hostname uses CNAME.

Do not force the result.

Document:

CNAME:
Not observed

Query Uses an Unexpected Resolver

Check:

cat /etc/resolv.conf

and:

resolvectl status

where available.

Document before changing configuration.

Mission Deliverables

Complete:

• scope confirmed

• resolver identified

• DNS architecture documented

• baseline captured

• A record queried

• A response analyzed

• AAAA reviewed

• CNAME reviewed where available

• MX reviewed where available

• TXT reviewed where available

• PTR reviewed

• successful lookup captured

• failed lookup captured

• NXDOMAIN identified

• TTL reviewed

• UDP/TCP DNS behavior reviewed

• query-only filtering completed

• response-only filtering completed

• resolver use validated

• DNS-to-network correlation completed

• DNS relationship map created

• DNS timeline created

• expected activity classified

• unusual activity documented

• PCAP preserved

• PCAP hashed

• DNS Investigation Register completed

• final report completed

Lab Report Template

# Lab 15 — DNS Security Investigation

## Executive Summary

## Mission Objective

## Scope

## DNS Architecture

## Resolver Configuration

## Authorized Domains

## Capture Methodology

## Evidence Integrity

## DNS Query Analysis

## DNS Response Analysis

## A Records

## AAAA Records

## CNAME Records

## MX Records

## TXT Records

## PTR Records

## TTL Analysis

## Failed Resolution

## DNS Response Codes

## Resolver Analysis

## DNS-to-Network Correlation

## DNS Relationship Map

## DNS Timeline

## Expected Activity

## Unusual Activity

## Security Observations

## Positive Controls

## Findings

## Recommendations

## Evidence

## Limitations

## Lessons Learned

## Conclusion

Knowledge Check

Question 1 — What is DNS used for?

DNS helps translate names such as:

training.lab

into network information such as IP addresses.

Question 2 — What does an A record contain?

An IPv4 address associated with a hostname.

Question 3 — What does an AAAA record contain?

An IPv6 address associated with a hostname.

Question 4 — What is a CNAME?

A DNS record that aliases one name to another canonical name.

Question 5 — What does NXDOMAIN mean?

The queried DNS name does not exist according to the responding DNS system.

Question 6 — Does NXDOMAIN automatically indicate malicious activity?

No.

Failed lookups can result from ordinary typing mistakes, application errors, stale configurations, or many other causes.

Question 7 — Why is TTL important?

It influences how long DNS information may be cached before another resolution is required.

Question 8 — Why correlate DNS with subsequent TCP traffic?

Because it can establish:

Domain
   ↓
Resolved IP
   ↓
Actual Connection

rather than showing only that a name was looked up.

Question 9 — Why might unexpected resolvers be security relevant?

They can bypass approved DNS logging, filtering, policy enforcement, or organizational visibility.

Question 10 — Does a long DNS query prove DNS tunneling?

No.

A tunneling conclusion requires multiple correlated indicators and supporting evidence.

Skills Achieved

After completing this lab, you should understand:

• DNS architecture

• resolver configuration

• DNS queries and responses

• A records

• AAAA records

• CNAME records

• MX records

• TXT records

• NS records

• PTR records

• DNS TTL

• DNS caching

• NXDOMAIN

• DNS response codes

• UDP/TCP DNS awareness

• Wireshark DNS filtering

• dig

• nslookup

• DNS relationship mapping

• DNS timeline reconstruction

• DNS-to-network correlation

• expected vs unusual DNS activity

• DNS evidence preservation

• professional DNS investigation reporting

Professional Takeaway

DNS investigation should not stop at:

“This host queried this domain.”

A security investigator asks:

“Which system generated the query, which resolver handled it, what answer was returned, what did that answer resolve to, what communication followed, and does that activity make sense for this host?”

Use:

Client → Query → Resolver → Response → IP → Connection → Context → Conclusion

The strongest DNS investigations combine:

DNS Evidence
     +
Network Evidence
     +
Asset Context
     +
Timeline
     =
Defensible Security Conclusion

What’s Next?

➡️ Lab 16 — Privilege Assessment

You have now worked across:

Network Discovery
      ↓
Service Assessment
      ↓
Host Security
      ↓
Web Security
      ↓
Packet Analysis
      ↓
DNS Investigation

In the next lab, you will examine privilege boundaries across authorized Linux and Windows training systems.

The focus will not be exploitation.

You will assess:

• current user privileges

• administrative groups

• sudo rights

• Windows administrator membership

• service identities

• scheduled tasks

• file and directory permissions

• privileged application components

• least privilege

• privilege boundaries

• risky privilege relationships

• security-control effectiveness

The methodology becomes:

Identity → Granted Privilege → Resource → Security Boundary → Risk → Evidence

By the end of Lab 16, you should be able to answer:

“Which users, services, and application components possess elevated privileges, are those privileges justified, and where could excessive privilege increase security risk?”