DNS and HTTP in 6 minutes — Cybersecurity Fundamentals

Recognise how attackers abuse DNS and HTTP, and spot the patterns those attacks leave in logs.

Why it matters

DNS and HTTP are the two protocols almost every user touches every minute, which makes them the two protocols attackers abuse most. You already know how they work from Networking Fundamentals. This lesson is the defender's six-minute version: the abuse patterns that matter and how they show up in logs.

DNS: when the phone book lies

DNS turns names such as bank.example into IP addresses. If an attacker can change the answer, victims go to the attacker's server while their browser shows the right name. There are several ways to change or misuse the answer.

Abuse	What happens	Defences
Cache poisoning	A resolver is tricked into storing a forged answer, so everyone using it gets the wrong address	Random source ports and query IDs, DNSSEC validation
Domain hijacking	The attacker takes over the registrar account and changes the real records	MFA on the registrar account, registrar lock, alerts on record changes
Typosquatting and look-alikes	`examp1e.com` or `example-login.com` registered for phishing	Monitor new registrations, register common typos, train users
DNS tunnelling	Data hidden inside DNS queries to sneak out past firewalls	Watch for very long or random subdomains and high query volume to one domain
Amplification	Small spoofed queries to open resolvers produce big replies aimed at a victim	Do not run open resolvers; rate-limit responses

DNSSEC adds digital signatures to DNS records so a validating resolver can tell whether an answer is genuine. It protects the integrity of the answer, not its privacy. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the query between you and the resolver, which protects privacy on the local network, but they also mean the network team can no longer see those queries, which is why some companies restrict them.

Spotting tunnelling in a DNS log

Normal lookups look like this:

10:02:11 host-14 A   www.wikipedia.org
10:02:12 host-14 A   fonts.gstatic.com

Tunnelling often looks like this:

10:15:01 host-22 TXT 4a6f686e2053...6d697468.x7q.example-c2.net
10:15:01 host-22 TXT 31323334203...9393939.x7q.example-c2.net
10:15:02 host-22 TXT 4d61696e2053...7472656574.x7q.example-c2.net

The giveaways: long random-looking labels (hex-encoded data), many queries per second from one host, the same unusual parent domain every time, and lots of TXT queries. None of these proves an attack on its own, but together they are worth investigating.

HTTP: reading the web's paper trail

Every HTTP request carries a method, a path, headers and sometimes a body, and the server answers with a status code. Web server access logs record most of this, and the patterns tell you a lot:

203.0.113.9 "POST /login HTTP/1.1" 401
203.0.113.9 "POST /login HTTP/1.1" 401
203.0.113.9 "POST /login HTTP/1.1" 401   (x 400 in 5 minutes)
198.51.100.7 "GET /.env HTTP/1.1" 404
198.51.100.7 "GET /wp-admin/ HTTP/1.1" 404
198.51.100.7 "GET /phpmyadmin/ HTTP/1.1" 404
192.0.2.44 "GET /download?file=../../../etc/passwd HTTP/1.1" 400
192.0.2.80 "GET /search?q=%27%20OR%201%3D1-- HTTP/1.1" 500

Reading it:

Hundreds of 401s on /login from one address: password guessing (brute force) or credential stuffing with leaked passwords. Defences: rate limits, lockouts, MFA.
Many 404s for well-known admin paths and secret files: an automated scanner looking for forgotten software or leaked config files. Make sure files like .env are never served.
../ in a parameter: a path traversal attempt to read files outside the web folder.
' OR 1=1-- (URL-encoded as %27%20OR%201%3D1--): a SQL injection probe. The 500 status is the worrying part, because it suggests the input reached the database and broke a query.

Headers defenders care about

Servers can send response headers that make browsers enforce extra rules:

Strict-Transport-Security (HSTS): always use HTTPS for this site.
Content-Security-Policy (CSP): only run scripts from approved sources, which limits cross-site scripting.
X-Content-Type-Options: nosniff and X-Frame-Options / CSP frame-ancestors: block content-type tricks and clickjacking.
Cookie flags Secure, HttpOnly and SameSite: keep session cookies off plain HTTP, away from page scripts, and out of most cross-site requests.

You will see these again in module 2.

Common mistakes

Treating 404s as harmless noise. Most are, but a scan followed by a 200 on /.env is a breach.
Only watching inbound requests. DNS logs from your own machines are one of the best places to spot malware calling home.
Forgetting the registrar. A strong server is useless if someone can log in to the domain account with a reused password and repoint the records.
Logging secrets. Do not log full request bodies or authorization headers; logs get copied and shared.

Quick recap

DNS abuse changes or misuses the answer: poisoning, hijacking, look-alike domains, tunnelling and amplification.
DNSSEC protects answer integrity; DoH and DoT protect query privacy.
HTTP logs reveal brute force (many 401s), scanning (many 404s), traversal (../) and injection probes (odd quotes and SQL keywords, especially with 500s).
Security headers and cookie flags tell the browser to enforce extra protections.