MODULE 03 — WEB

DNS Resolution

The internet's phone book — how domain names like "example.com" get translated into IP addresses your computer can actually use.

What is DNS?

The Domain Name System (DNS) is often called the "phonebook of the internet." It translates human-readable domain names (like www.example.com) into IP addresses (like 93.184.216.34) that computers use to route traffic across networks. Every time you type a URL in your browser, send an email, or make an API call — DNS is working behind the scenes.

Without DNS, you'd have to memorize IP addresses for every website you want to visit. Imagine typing 142.250.80.46 instead of google.com. DNS makes the internet usable for humans.

DNS is hierarchical (organized in a tree structure), distributed (no single server holds all records), and cached at multiple levels for performance. Critically for security, traditional DNS queries are largely unencrypted — anyone on the network path can see which domains you're resolving.

DNS uses UDP port 53 for most queries (fast, small responses) and falls back to TCP port 53 for larger responses (zone transfers, responses > 512 bytes).

Key Terms

Domain Name: A human-readable address (e.g., example.com) that maps to one or more IP addresses.
FQDN: Fully Qualified Domain Name — the complete domain path including all labels and the root (e.g., www.example.com.).
Resolver: A DNS server that receives queries from clients and resolves them by querying other servers. Your ISP or services like 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare).
TTL (Time to Live): How long (in seconds) a DNS record is cached before it must be re-queried. A TTL of 300 = 5 minutes.
Zone: A portion of the DNS namespace managed by a specific organization or administrator (e.g., everything under example.com).
Authoritative Server: The DNS server that holds the actual records for a domain and provides definitive answers (not cached copies).

DNS Hierarchy

DNS is organized as an inverted tree. At the very top is the root zone (represented by a dot .), managed by 13 sets of root server clusters worldwide. Below that are the Top-Level Domains (TLDs) like .com, .org, .net, and country-code TLDs like .uk, .de. Each TLD delegates authority to individual domain registrars and their authoritative nameservers.

Root Servers (.) — 13 server clusters (a.root-servers.net → m.root-servers.net)
TLD Servers (.com, .org, .net, .io, .uk) — Managed by registries (Verisign, PIR)
Authoritative NS (ns1.example.com) — Holds the actual DNS records
IP Address: 93.184.216.34 — The final answer

DNS Record Types

DNS doesn't just store IP addresses — it stores many types of records. Each record type serves a different purpose. Here are the most important ones:

A Record

Maps a domain to an IPv4 address. The most common record type.

example.com → 93.184.216.34
AAAA Record

Maps a domain to an IPv6 address (128-bit). Increasingly important as IPv4 addresses run out.

example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME Record

Canonical Name — an alias that points to another domain. Used for subdomains and CDNs.

www.example.com → example.com
MX Record

Mail Exchanger — specifies which server handles email for the domain. Has a priority value (lower = preferred).

example.com MX 10 mail.example.com
TXT Record

Stores arbitrary text. Used for SPF (email sender verification), DKIM (email signing), domain verification (Google, Let's Encrypt), and more.

example.com TXT "v=spf1 include:_spf.google.com ~all"
NS Record

Nameserver — identifies which DNS servers are authoritative for the domain.

example.com NS ns1.examplehost.com
SOA Record

Start of Authority — contains zone metadata: primary NS, admin email, serial number, refresh/retry/expire timers.

PTR Record

Pointer — reverse DNS: maps an IP address back to a domain name. Used in email verification and logging.

34.216.184.93.in-addr.arpa → example.com

Real-World: Why Does TTL Matter?

Imagine you're migrating your website to a new server with a different IP address. If your A record has a TTL of 86400 (24 hours), ISP resolvers worldwide will keep sending users to the old IP for up to 24 hours after you make the change. That's why before a migration, you lower the TTL to 300 (5 minutes) a day in advance — so the old long-TTL entries expire, and when you switch, the change propagates within minutes.

Conversely, CDN providers like Cloudflare often use very low TTLs (auto = ~5 min) so they can dynamically route traffic, while stable services use high TTLs (3600+) to reduce DNS lookup overhead and improve performance.

Full DNS Resolution Process (Step by Step)

When you type www.example.com in your browser and press Enter, a complex chain of lookups occurs — usually in under 100 milliseconds. Here's exactly what happens:

  1. Browser Cache Check: Your browser first checks its own DNS cache. Chrome stores DNS for up to 60 seconds by default. If a recent lookup exists, it's used immediately (no network request needed).
  2. OS Cache Check: If not in browser cache, the OS resolver is queried. On Linux, this is controlled by systemd-resolved or nsswitch.conf. On Windows, the DNS Client service.
  3. Hosts File: Before making a network query, the OS checks /etc/hosts (Linux/Mac) or C:\Windows\System32\drivers\etc\hosts (Windows). Entries here override DNS — useful for development and testing, but also exploited by malware.
  4. Recursive Resolver Query: If no cache hit, the query goes to your configured recursive resolver (typically your ISP's DNS server, or public resolvers like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare)).
  5. Resolver Cache: The recursive resolver checks its own cache first. Since it serves many users, there's a good chance someone recently resolved the same domain. If cached and TTL hasn't expired, the answer is returned immediately.
  6. Root Server Query: On a complete cache miss, the resolver queries one of the 13 root server clusters. The root doesn't know the IP of www.example.com, but it knows who manages .com and responds with a referral to the .com TLD servers.
  7. TLD Server Query: The resolver queries the .com TLD server. It responds: "I don't have the IP, but the authoritative nameservers for example.com are ns1.example.com and ns2.example.com."
  8. Authoritative Server Query: The resolver queries the authoritative nameserver directly. This server holds the actual DNS zone file for example.com.
  9. Answer: The authoritative server responds with the A record: 93.184.216.34 and a TTL value (e.g., 3600 seconds).
  10. Caching & Response: The resolver caches the result for the duration of the TTL, then returns the IP to your browser. Future queries for the same domain will be answered from cache until TTL expires.

DNS Security Threats

DNS was designed in the 1980s without security in mind. Traditional DNS queries travel in plaintext UDP, making them visible to anyone on the network path. This creates numerous attack vectors:

DNS Spoofing / Cache Poisoning

The attacker races to send a forged DNS response to a resolver before the legitimate response arrives. If successful, the fake answer (pointing to an attacker-controlled IP) gets cached and served to all users who query that domain.

Impact: Users are silently redirected to phishing sites that look identical to the real ones. The Kaminsky Attack (2008) demonstrated this could be done at massive scale.

Defense: DNSSEC (cryptographic verification), randomized source ports, 0x20 encoding (random case in queries).

DNS Tunneling

Attackers encode data within DNS queries and responses to create a covert communication channel. Since DNS traffic is rarely blocked by firewalls, it can be used to exfiltrate stolen data or establish command-and-control (C2) channels with malware.

How it works: Data is encoded as subdomains: dGhpcyBpcyBzZWNyZXQ.evil.com — the authoritative server for evil.com decodes the base64 subdomain.

Defense: Monitor for unusually long domain queries, high query volume to single domains, and high-entropy subdomains.

DNS Amplification DDoS

The attacker sends DNS queries with the victim's spoofed source IP to open recursive resolvers. The resolvers send their (much larger) responses to the victim. A 60-byte query can produce a 4,000+ byte response — a 70x amplification factor.

Impact: The victim is overwhelmed with traffic they never requested, causing denial of service.

Defense: BCP38 ingress filtering, disable open resolvers, response rate limiting (RRL).

Domain Hijacking

An attacker gains unauthorized access to a domain's registrar account and changes the DNS records (NS records, A records) to point to their own servers. This gives them complete control over the domain.

Impact: All traffic, including email, is redirected to attacker infrastructure. Used in high-profile attacks against banks and governments.

Defense: Registrar lock, 2FA on registrar accounts, registry lock (expensive but secure).

DNS Security Solutions

DNSSEC

Adds cryptographic signatures to DNS records. Resolvers can verify that a response truly came from the authoritative server and wasn't tampered with. Doesn't encrypt queries — only validates authenticity.

DNS over HTTPS (DoH)

Encrypts DNS queries inside HTTPS connections (port 443). Makes DNS queries indistinguishable from regular web traffic. Supported by Firefox, Chrome, and public resolvers like Cloudflare (1.1.1.1).

DNS over TLS (DoT)

Encrypts DNS queries using TLS on a dedicated port (853). Unlike DoH, it uses a separate port which makes it easier to manage/block at the network level. Supported by Android 9+ ("Private DNS").

DNS Filtering / Sinkholing

Organizations use DNS filtering (Pi-hole, OpenDNS, Cisco Umbrella) to block queries to known malicious domains. Sinkholing redirects malware C2 domains to a controlled server for analysis.

DNS Reconnaissance Commands

DNS enumeration is one of the first steps in any penetration test or bug bounty engagement. Here are the essential commands:

$ nslookup example.com — Quick DNS lookup (works on Windows too)
$ dig example.com A +short — Get just the IP address (A record)
$ dig example.com ANY — Request all record types at once
$ dig example.com MX — Find mail servers (useful for phishing recon)
$ dig +trace example.com — Show the full resolution path from root servers
$ dig -x 93.184.216.34 — Reverse DNS lookup (IP → domain)
$ host -t TXT example.com — Get TXT records (SPF, DKIM, verification strings)
$ dig @8.8.8.8 example.com — Query a specific resolver (useful for comparing results)
Tip: For subdomain enumeration, tools like subfinder, amass, and dnsrecon automate the process and can discover hidden subdomains that may expose sensitive services (staging servers, admin panels, forgotten APIs).

DNS Resolution Simulator

Enter a domain and watch the step-by-step DNS resolution process unfold in real-time.

Try:
Browser
Your Machine
Resolver
8.8.8.8
Root
a.root-servers.net
TLD
.com server
Authoritative
ns1.example.com
Resolution Log
// DNS resolution log — click "Resolve" to start

Knowledge Check

All certification names are referenced for educational purposes only. This project is not affiliated with any certification body.