🔄 Topic

Analyzing DNS and ICMP traffic to understand why a website or service failed to respond.

🎯 Goal

Practice reading network traffic as evidence and identify the likely cause of a DNS-related incident.

🛠 What I Did

Today I worked through a Google Cybersecurity Certificate activity involving DNS and ICMP traffic.

The scenario involved a user or team noticing that a website was unreachable.

The important traffic pattern was:

  • a DNS query was sent using UDP
  • the query targeted DNS service port 53
  • instead of receiving a normal DNS response, the client received an ICMP error
  • the ICMP message indicated that the destination or port was unreachable

Simplified traffic flow:

Client
    ↓
DNS query using UDP
    ↓
Destination port 53
    ↓
No normal DNS response
    ↓
ICMP error returned
    ↓
Likely DNS service, firewall, or port issue

The important clue was that the problem was not necessarily the website itself.

The failure happened earlier in the chain: name resolution.

If DNS fails, the browser may never even learn which IP address belongs to the domain.

🔗 Key Cybersecurity Connections

This matters because users often report symptoms, not root causes.

A user may say:

The website is down.

But the real issue could be:

  • DNS server unavailable
  • DNS service stopped
  • firewall blocking UDP port 53
  • client using the wrong DNS server
  • network path broken
  • routing issue
  • DNS server overloaded
  • denial-of-service activity against DNS infrastructure

The SOC mindset is to follow the evidence layer by layer.

Do not assume the web server is down just because the page does not load.

The failure may happen before HTTP or HTTPS traffic even starts.

🔍 Investigation Questions

  • What time did the incident occur?
  • Which user or system reported the problem?
  • Was the DNS query sent successfully?
  • Which DNS server was queried?
  • Was UDP port 53 involved?
  • Was there a normal DNS response?
  • Was there an ICMP error?
  • Did the ICMP message say port unreachable?
  • Was the DNS server online?
  • Was a firewall blocking DNS traffic?
  • Did the issue affect one host or many hosts?
  • Were there abnormal spikes in DNS traffic before the failure?

🚨 Detection Opportunities

Potential detection patterns:

  • repeated DNS queries with no valid response
  • ICMP destination unreachable messages after DNS requests
  • many clients failing DNS resolution at the same time
  • DNS server receiving traffic but not responding
  • firewall denying UDP port 53
  • sudden increase in DNS errors
  • DNS server process stopped or crashed
  • DNS service reachable by ping but not listening on port 53

Example event pattern:

protocol=UDP
destination_port=53
action=query_sent
response=ICMP_port_unreachable
likely_issue=DNS_service_unavailable

This is stronger than simply writing:

Website unavailable.

The evidence points to the DNS resolution path.

🧭 MITRE ATT&CK Techniques

No MITRE ATT&CK technique should be forced if the evidence only shows a service failure.

If later evidence proves malicious activity, possible mappings may include:

  • T1498 — Network Denial of Service
  • T1499 — Endpoint Denial of Service
  • T1071 — Application Layer Protocol

The important lesson is not to over-label an outage as an attack without evidence.

🗺 Visual Investigation Diagram

User enters website
    ↓
Browser needs IP address
    ↓
Client sends DNS query
    ↓
UDP port 53
    ↓
ICMP error returned
    ↓
DNS resolution fails
    ↓
Website appears unavailable

⚠ Challenges

The main challenge was understanding why UDP and ICMP appeared together.

At first, it can feel strange because DNS normally uses UDP, while ICMP is usually associated with ping.

But ICMP is also used for error reporting.

So the ICMP packet was not the original DNS request.

It was the network saying:

The UDP request could not be completed.

Another challenge was avoiding premature conclusions.

A failed website request does not automatically mean the web server is down.

📚 What I Learned

I learned that ICMP is more than ping.

ICMP can report network problems such as:

  • destination unreachable
  • port unreachable
  • time exceeded
  • fragmentation needed

I also learned that DNS is an early dependency for many user-facing services.

If DNS breaks, many applications look broken even if the actual application servers are healthy.

This is why DNS logs and packet captures are so useful in incident analysis.

➡ Next Steps

  • Practice reading DNS traffic in Wireshark
  • Compare normal DNS replies with ICMP error responses
  • Learn common ICMP message types
  • Build a mini lab where DNS is intentionally stopped
  • Observe what the client sees when DNS fails
  • Write a short incident summary using evidence, not guesses

🧠 Reflection

This was a good reminder that investigation is about sequence.

Before asking why a website failed, I need to ask:

Did the client resolve the domain name?

If the answer is no, the investigation stays at DNS.

Jumping straight to the web server would be weak analysis.

🧩 Lessons Learned

What worked

Following the traffic flow step by step.

What broke

Initially seeing UDP and ICMP as unrelated.

Why it broke

I was thinking of protocols as separate topics instead of understanding how one protocol can report errors about another.

Fix / takeaway

Separate the original request from the error response.

In this case:

  • DNS query = UDP
  • failure message = ICMP

📈 Skill Progression Context

This builds SOC investigation discipline.

Real alerts and incidents often begin with vague symptoms.

The analyst’s job is to translate symptoms into evidence:

  • protocol
  • port
  • source
  • destination
  • response
  • error message
  • likely failure point

This is exactly the kind of thinking needed for network triage and incident reports.

😄 TL;DR

The website was not necessarily dead.

DNS may have failed before the browser even knew where to go.