Tutorial 1.2

DNS and Web Infrastructure

Chapter 2 · Web Protocols
~2.5 hours Intermediate DNS · Record Types · CDN

Overview

The Domain Name System (DNS) is the phonebook of the internet. It translates human‑readable domain names (like example.com) into machine‑readable IP addresses. In this tutorial, you will explore the hierarchical structure of DNS, the resolution process, record types, caching, and how DNS underpins modern web infrastructure such as load balancers and Content Delivery Networks (CDNs).

Why this matters: DNS is a critical component of web performance and reliability. Understanding it helps you troubleshoot issues, optimise latency, and design resilient architectures.

Learning Objectives

  • Describe the hierarchical structure of DNS (root, TLD, authoritative).
  • Trace the DNS resolution process from browser to root server.
  • Identify common DNS record types (A, AAAA, CNAME, MX, TXT).
  • Explain how DNS caching and TTL affect performance.
  • Describe how DNS is used for load balancing and CDN routing.

1. DNS Hierarchy

DNS is a distributed, hierarchical database. The hierarchy consists of:

  • Root Servers: The top of the hierarchy (13 logical root server clusters, operated by different organisations). They point to TLD servers.
  • Top‑Level Domain (TLD) Servers: Manage domains like .com, .org, .uk, etc. They point to authoritative name servers.
  • Authoritative Name Servers: Serve the actual DNS records for a specific domain (e.g., ns1.example.com). They provide the final answer.
  • Recursive Resolvers: Usually provided by ISPs or public services (like Google’s 8.8.8.8). They query the hierarchy on behalf of the client.

This distributed design ensures no single point of failure and allows for decentralised management.

2. DNS Resolution Process

When you type example.com into your browser:

  1. Browser Cache: The browser checks its own cache.
  2. OS Cache: If not found, the operating system checks its cache.
  3. Recursive Resolver: The query is sent to the configured resolver (e.g., your ISP).
  4. Root Server: The resolver asks a root server for example.com. The root replies with the address of the .com TLD server.
  5. TLD Server: The resolver asks the .com TLD for example.com. The TLD replies with the authoritative name server for example.com.
  6. Authoritative Server: The resolver asks the authoritative name server for the A record of example.com. It receives the IP address.
  7. Response: The resolver caches the answer and returns the IP to the browser.

This entire process typically takes < 100ms due to caching at every level.

// Example dig output (simplified)
;; QUESTION SECTION:
;example.com.         IN  A
;; ANSWER SECTION:
example.com.  86400  IN  A  93.184.216.34

3. DNS Record Types

  • A (Address): Maps a domain to an IPv4 address.
  • AAAA: Maps a domain to an IPv6 address.
  • CNAME (Canonical Name): Alias of one domain to another (e.g., www.example.com → example.com).
  • MX (Mail Exchange): Specifies mail servers for the domain.
  • TXT: Arbitrary text, used for verification (SPF, DKIM, etc.).
  • NS (Name Server): Delegates a subdomain to a specific authoritative server.
  • SOA (Start of Authority): Contains administrative information about the zone (serial, refresh, retry).

Choosing the right record type is essential for configuring web services, email, and subdomains.

4. Caching & TTL

To reduce latency and load on authoritative servers, DNS responses are cached. The TTL (Time‑to‑Live) value in each record specifies how long a resolver should cache it.

  • Short TTL (e.g., 60s): Use for dynamic failover or load balancing. Increases query volume.
  • Long TTL (e.g., 86400s = 24h): Use for stable records. Reduces latency and load.

Caching happens at the browser, OS, recursive resolver, and even at intermediate proxies. Flushing the cache is often the first step in troubleshooting DNS issues.

5. Load Balancing & CDN

DNS is a powerful tool for distributing traffic and improving performance.

DNS‑based Load Balancing

  • Round‑Robin: The authoritative server returns multiple A records in a rotating order.
  • Geo‑DNS: Returns different IPs based on the client’s geographic location (latency‑based routing).
  • Weighted Routing: Distributes traffic based on server capacity.

Content Delivery Networks (CDNs)

CDNs use DNS to direct users to the nearest edge server. When you request a resource, a CDN’s DNS server responds with the IP of the closest PoP (Point of Presence), drastically reducing latency and load on the origin server.

Example: Cloudflare, Akamai, and Fastly all use geo‑DNS to route traffic to edge locations worldwide.

6. DNS Security (DNSSEC)

DNS is inherently insecure – responses can be spoofed (DNS spoofing / cache poisoning). DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify authenticity.

  • RRSIG: Digital signature for a record set.
  • DNSKEY: Public key used to verify signatures.
  • DS: Delegation signer – establishes a chain of trust from the parent zone.

While not universally deployed yet, DNSSEC is increasingly important for critical infrastructure and financial services.

Quiz

Question 1

Which DNS record type is used to map a domain name to an IPv4 address?

  • AAAA
  • A
  • CNAME
  • MX
Show answer
B. A (Address) record.

Question 2

What is the purpose of the TTL field in a DNS record?

  • It specifies the time to live of the domain registration.
  • It tells resolvers how long to cache the record.
  • It sets the expiry date of the SSL certificate.
  • It defines the zone transfer interval.
Show answer
B. It tells resolvers how long to cache the record.

Question 3

Which of the following is a primary security extension for DNS?

  • SSL
  • TLS
  • DNSSEC
  • SSH
Show answer
C. DNSSEC (Domain Name System Security Extensions).

Exercises

Exercise 1

Describe the step‑by‑step process a recursive resolver follows when resolving www.google.com. Include the roles of the root, TLD, and authoritative servers.

Sample answer
  1. The resolver checks its cache for www.google.com.
  2. It queries a root server for www.google.com. The root responds with the TLD server for .com.
  3. The resolver queries the .com TLD server, which responds with the authoritative name servers for google.com (e.g., ns1.google.com).
  4. The resolver queries the authoritative name server for the A record of www.google.com, receiving the IP address.
  5. The resolver caches the result and returns the IP to the client.

Exercise 2

Explain the difference between an A record and a CNAME record. When would you use a CNAME?

Sample answer

A record: Directly maps a domain to an IP address. It is the final result of a DNS lookup.

CNAME record: Aliases one domain name to another. For example, www.example.com → example.com. The resolver will then look up the A record for example.com.

When to use: Use CNAME when you want multiple subdomains to point to the same server without duplicating IPs (e.g., blog.example.com → example.com). However, a CNAME cannot coexist with other record types (like MX) for the same name.

Homework

Homework 1

A company operates a global e‑commerce site. They want to reduce latency for users in different regions. Design a DNS‑based strategy to achieve this, explaining which record types and techniques (e.g., Geo‑DNS, CDN) you would use. (300–400 words)

Sample answer

Strategy: Use a combination of Geo‑DNS and a CDN.

  1. Geo‑DNS (using A/AAAA records): Deploy application servers in multiple regions (e.g., US‑East, EU‑West, AP‑South). Configure authoritative DNS with a latency‑based routing policy. When a user in Europe queries the domain, the DNS returns the IP of the EU‑West server. This reduces round‑trip time (RTT).
  2. CDN (using CNAME): For static assets (images, CSS, JS), use a CDN like Cloudflare or Fastly. Point a subdomain like static.example.com via a CNAME to the CDN endpoint. The CDN’s DNS will automatically route users to the nearest edge cache.
  3. Health Checks & Weighted Routing: Use shorter TTLs (e.g., 60s) so that if a region fails, the DNS can quickly reroute traffic to a healthy region. Weighted records can also distribute load based on capacity.

This approach minimises latency, reduces origin server load, and provides high availability through geographic redundancy.

Mini‑Project

DNS Tracing with dig

Use the command‑line tool dig (available on Linux, macOS, or WSL) to trace the DNS resolution of a domain of your choice (e.g., github.com).

Run the following commands and document the output:

  • dig github.com – basic A record lookup.
  • dig github.com +trace – trace the full resolution path from root to authoritative.

Explain which servers were contacted and what records were returned at each step.

Sample command output and explanation

Command: dig github.com +trace

Output (simplified):

;; Received 512 bytes from 198.41.0.4#53(a.root-servers.net)
.com.  172800  IN  NS  a.gtld-servers.net.
;; Received 1220 bytes from 192.5.6.30#53(a.gtld-servers.net)
github.com.  172800  IN  NS  ns1.p16.dynect.net.
;; Received 220 bytes from 204.74.66.1#53(ns1.p16.dynect.net)
github.com.  60  IN  A  140.82.121.3

Explanation:

  1. The root server (a.root-servers.net) returned the .com TLD servers.
  2. The .com TLD server (a.gtld-servers.net) returned the authoritative name servers for github.com.
  3. The authoritative server (ns1.p16.dynect.net) returned the A record with IP 140.82.121.3.

This shows the complete delegation chain from root to authoritative.

Tutorial Summary

In this tutorial, you learned about the hierarchical DNS architecture, the step‑by‑step resolution process, and the most important record types. You explored how caching and TTL impact performance, and how DNS enables advanced infrastructure like load balancing and CDNs. The practical exercises and mini‑project gave you hands‑on experience with DNS tools and concepts.

Key takeaway: DNS is the invisible backbone of the web. Mastering its workings allows you to optimise performance, improve reliability, and troubleshoot connectivity issues effectively.