Academy/Network Security Fundamentals/Module 4

Module 4 of 5

80% complete

Module 4

DNS & HTTP Traffic

The Domain Name System

DNS is the internet's phone book. When you type a domain name into a browser, a series of distributed servers translates that name into an IP address your device can route to. Understanding DNS is essential for network defenders — it is used both legitimately for every web request and maliciously for command-and-control, data exfiltration, and phishing infrastructure.

DNS Hierarchy

DNS is structured as an inverted tree with three key levels:

→

Root DNS servers — 13 logical root server clusters (operated by 12 organizations) that know the locations of all TLD name servers. Queried first when no cached answer is available.

→

TLD name servers — authoritative for top-level domains like .com, .net, .in, .gov. They point queries to the correct authoritative server for each domain.

→

Authoritative name servers — the final authority for a specific domain. They hold the actual DNS records (A, MX, CNAME, etc.) and return the answer to the query.

Recursive vs Iterative Resolution

Process	Who Does the Work	Used By
Recursive	Resolver queries on client's behalf until final answer obtained	Your ISP's resolver, 8.8.8.8, 1.1.1.1
Iterative	Each server returns a referral; requester follows up themselves	Recursive resolvers querying root/TLD servers

When you query 8.8.8.8 for example.com, Google's resolver performs iterative queries to root → TLD → authoritative servers and returns the final answer to your device. Your device made one recursive query; the resolver made multiple iterative queries internally.

DNS Record Types

Record	Full Name	Purpose	Example
A	Address	Maps hostname to IPv4 address	example.com → 93.184.216.34
AAAA	IPv6 Address	Maps hostname to IPv6 address	example.com → 2606:2800::1
MX	Mail Exchanger	Identifies mail servers for domain	example.com → mail.example.com (priority 10)
CNAME	Canonical Name	Alias pointing to another hostname	www.example.com → example.com
TXT	Text	Arbitrary text — SPF, DKIM, DMARC, verification	v=spf1 include:_spf.google.com ~all
NS	Name Server	Lists authoritative name servers for domain	ns1.example.com, ns2.example.com
PTR	Pointer	Reverse DNS — maps IP to hostname	34.216.184.93.in-addr.arpa → example.com
SOA	Start of Authority	Zone metadata: primary NS, serial, TTL defaults	Authority and zone transfer information

DNS TTL

TTL (Time to Live) is a value in seconds attached to each DNS record. Resolvers and clients cache the record for the TTL duration. A low TTL (e.g., 60 seconds) means rapid propagation of changes but more queries. A high TTL (e.g., 86400 = 24 hours) reduces query load but slows propagation. During an incident, lowering TTL before making IP changes ensures quicker cutover.

DNS Security

DNSSEC — Digital Signatures for DNS

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses. Each zone signs its records with a private key; validators check those signatures using the corresponding public key. The chain of trust flows from the root zone downward.

RRSIG records — cryptographic signatures over resource record sets
DNSKEY records — public keys used to verify RRSIG signatures
DS records — delegation signer records linking parent zone to child zone key
NSEC/NSEC3 records — authenticated denial of existence (prove a name does not exist)

DNSSEC Limitation

DNSSEC protects the integrity of DNS responses — it prevents tampering in transit. It does NOT encrypt DNS queries or responses. An observer on the network can still see which domains you are resolving.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Protocol	Transport	Port	Key Benefit
DoH	HTTPS (TLS + HTTP/2)	443	Blends with normal web traffic — hard to block without DPI
DoT	TLS directly	853	Dedicated port — easier to filter or monitor at enterprise perimeter

Both protocols encrypt DNS queries end-to-end between the client and the resolver, preventing eavesdropping or tampering. Enterprise security teams must account for DoH/DoT when implementing DNS-based security controls — if users bypass corporate resolvers using encrypted DNS, DNS filtering becomes ineffective.

Common DNS Attacks

DNS cache poisoning (Kaminsky attack) — inject forged records into a resolver cache, redirecting users to attacker-controlled servers
DNS spoofing — intercept and forge DNS responses in transit (mitigated by DNSSEC and encrypted DNS)
DNS tunneling — encode data in DNS queries/responses to exfiltrate data or create covert C2 channels through DNS traffic
NXDomain attacks — flood resolver with queries for non-existent domains, exhausting resources
DNS amplification DDoS — send small queries with spoofed source IPs; large responses flood the victim
Subdomain takeover — claim an abandoned subdomain's cloud resource (e.g., unclaimed S3 bucket) to serve malicious content

HTTP Protocol

HTTP (Hypertext Transfer Protocol) is the foundation of all web communication. It is a request-response protocol: the client sends a request, the server returns a response. Security professionals must understand HTTP deeply to identify attacks, misconfigurations, and data exfiltration attempts.

HTTP Methods

Method	Purpose	Body?	Idempotent?
GET	Retrieve a resource	No	Yes
POST	Submit data, create resource	Yes	No
PUT	Replace a resource completely	Yes	Yes
PATCH	Partially update a resource	Yes	No
DELETE	Remove a resource	No	Yes
HEAD	GET without response body — check headers only	No	Yes
OPTIONS	Discover supported methods (CORS preflight)	No	Yes

HTTP Status Codes

Range	Category	Key Examples
1xx	Informational	100 Continue, 101 Switching Protocols
2xx	Success	200 OK, 201 Created, 204 No Content
3xx	Redirection	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	Client Error	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx	Server Error	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Security-Relevant Status Codes

401 vs 403: A 401 means the request lacks valid credentials (unauthenticated). A 403 means credentials are valid but permissions are insufficient (unauthorized). Returning 404 instead of 403 for restricted resources is a common technique to avoid revealing that a resource exists.

Critical HTTP Headers

Host — identifies the target domain; essential for virtual hosting (required since HTTP/1.1)
User-Agent — identifies the client application and OS; commonly used for device fingerprinting
Content-Type — describes the media type of the body (e.g., application/json, multipart/form-data)
Authorization — carries credentials: Basic (Base64), Bearer (JWT token), or Digest
Cookie — sends stored session cookies to the server with every request
Set-Cookie — server instructs client to store a cookie (Secure, HttpOnly, SameSite attributes matter for security)
X-Forwarded-For — identifies original client IP when request passes through a proxy or load balancer
Content-Security-Policy — restricts which sources the browser may load resources from (defense against XSS)
Strict-Transport-Security — forces browser to use HTTPS for a specified duration (HSTS)

HTTP vs HTTPS

HTTPS adds a TLS layer between TCP and HTTP. All request and response data — including headers, body, URLs after the hostname, and cookies — is encrypted in transit. An attacker performing a man-in-the-middle attack on HTTP can read and modify everything; on properly implemented HTTPS, they see only the destination hostname (via SNI) and connection metadata.

TLS Handshake (Simplified)

→

1. Client Hello — client sends supported TLS versions, cipher suites, and a random value.

→

2. Server Hello — server selects cipher suite, sends its certificate, and its random value.

→

3. Certificate validation — client verifies the server certificate against trusted CAs.

→

4. Key exchange — client and server establish a shared session key using ECDHE or similar.

→

5. Finished — both sides send a Finished message encrypted with the session key; secure channel established.

HTTP Strict Transport Security (HSTS)

HSTS instructs browsers to only access a domain over HTTPS for a specified period. Once a browser has seen the HSTS header, it will refuse to connect over plain HTTP, even if the user types http:// — it upgrades the request internally. This eliminates the window where first-visit MITM attacks could downgrade the connection.

Common HTTP-Based Attacks

Man-in-the-Middle (MITM) — attacker positions between client and server on unencrypted HTTP, reading and modifying traffic in real time
Session hijacking — steal session cookie (via network sniffing on HTTP or XSS) and replay it to authenticate as the victim
HTTP header injection — inject newline characters into headers to split responses or poison caches
HTTP request smuggling — exploit inconsistencies between front-end and back-end HTTP parsing to bypass security controls
Clickjacking — embed target site in a hidden iframe, trick user into clicking UI elements believing they are interacting with a different page

HTTP/2 and HTTP/3

Feature	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC (UDP-based)
Multiplexing	No (head-of-line blocking)	Yes (streams)	Yes (QUIC streams)
Header compression	None	HPACK	QPACK
Server push	No	Yes	Yes
Encryption	Optional (TLS)	Required in practice	Always encrypted (QUIC)
Head-of-line blocking	Yes	At TCP level	Eliminated

From a security perspective, HTTP/2 and HTTP/3 multiplexing can complicate deep packet inspection — traditional IDS/IPS tools designed for HTTP/1.1 may not correctly parse multiplexed streams. NGFWs with proper HTTP/2 and HTTP/3 application decoders handle this correctly.

Previous Module Next Module