Week 8: DNS -- The Domain Name System

Every HTTP request you have ever made started with a DNS lookup. DNS is a distributed database mapping human-readable names to IP addresses. This week you trace the full delegation chain from root servers to authoritative nameserver to your browser, using both packet captures and dig.

Theme

When you type virtuscyberacademy.org into a browser, your operating system sends a DNS query to your configured resolver (probably your router or a public resolver like 8.8.8.8). The resolver may have the answer cached. If not, it goes out to find the answer by traversing the DNS hierarchy: it asks the root servers who is authoritative for .org, asks the .org TLD servers who is authoritative for virtuscyberacademy.org, and asks the authoritative server for the actual IP address. The whole process takes 50-150ms and happens before any TCP connection. dig +trace shows you every step.

Reading (~60 minutes)

1. Stevens TCP/IP Illustrated Ch 14 ("DNS: The Domain Name System") -- full chapter: the DNS hierarchy; record types; the resolution algorithm; caching; the DNS message format
2. Kurose & Ross Ch 2 §2.4 ("DNS -- The Internet's Directory Service"): the recursive-resolver + authoritative-server architecture
3. Optional: Julia Evans, "How DNS Works" blog post at https://jvns.ca/blog/2022/01/11/how-to-find-ip-addresses/ -- a plain English complement to Stevens

Lecture outline (~2 hours)

Section 1: The DNS hierarchy

• DNS is a distributed hierarchical database. No single server holds all DNS records.
• Three tiers:
  1. Root servers: 13 logical root servers (A through M), geographically distributed via anycast. Know who is authoritative for every top-level domain (TLD).
  2. TLD servers: one or more servers per TLD (.org, .com, .net, .uk, etc.). Know who is authoritative for every second-level domain within the TLD.
  3. Authoritative name servers: the servers a domain owner controls. Hold the actual DNS records for a domain.
• Your resolver traverses this hierarchy when it does not have a cached answer.

Section 2: Record types

In dig: dig A virtuscyberacademy.org, dig MX virtuscyberacademy.org, dig TXT virtuscyberacademy.org.

Section 3: Recursive resolution step by step

When your resolver does not have virtuscyberacademy.org cached:

1. Query a root server: "Who is authoritative for .org?"
2. Root server returns NS records pointing to the .org TLD servers
3. Query a .org TLD server: "Who is authoritative for virtuscyberacademy.org?"
4. TLD server returns NS records pointing to the domain's authoritative servers
5. Query the authoritative server: "What is the A record for virtuscyberacademy.org?"
6. Authoritative server returns the IP address
7. Resolver caches the result for the TTL specified in the answer
8. Resolver returns the IP address to your application

dig +trace virtuscyberacademy.org shows each of these steps with the actual servers queried and the actual responses.

Section 4: Caching and TTL

• Every DNS record has a TTL (time to live), specified in seconds
• Resolvers cache records for the TTL duration; subsequent queries for the same name return the cached answer without hitting the authoritative server
• Low TTL (60-300s): changes propagate quickly; resolver load is higher
• High TTL (3600-86400s): changes propagate slowly; resolver load is lower
• dig reports the TTL in the answer section. If the answer is cached, the TTL decrements each second; a TTL of 47 on an A record with a nominal TTL of 300 means the record was cached 253 seconds ago.
• Negative caching (NXDOMAIN): "this domain does not exist" responses are also cached, for the time specified in the SOA record's negative TTL field

Section 5: DNSSEC, DoT, DoH

• Standard DNS is unencrypted and unauthenticated. Any observer on the network can see your DNS queries.
• DNSSEC: cryptographic signatures on DNS records; proves the answer came from the authoritative server and has not been tampered with. Does not encrypt; only authenticates.
• DNS-over-TLS (DoT): sends DNS traffic over a TLS connection to port 853 instead of UDP port 53. Encrypts queries from your machine to your resolver. Does not help with what the resolver does after that.
• DNS-over-HTTPS (DoH): sends DNS traffic as HTTPS to port 443. Looks identical to web traffic; harder for firewalls to block or monitor. Used by modern browsers (Firefox, Chrome) by default with trusted resolvers like Cloudflare.
• NET-201 covers DNSSEC implementation; this week covers the concept.

Labs (~90 minutes)

Lab 8-1: DNS Deep-Dive (labs/lab-8-1-dns-deepdive.md)

Independent practice (~7 hours)

1. Read Stevens Ch 14 in full; note the exact byte layout of the DNS message format
2. Run dig +trace virtuscyberacademy.org. Write down the name of each server queried at each step. How many total DNS queries did dig make?
3. Load fundamentals-dns-query.pcap in pcap-tools. In the query packet: what is the transaction ID? What flags are set? What record type is requested? In the reply packet: what is the answer section? What is the TTL?
4. Load dns-lookup.pcap (the upstream-mirrored version from the catalog). How does this capture differ from the fundamentals version? Are there multiple query/response pairs?
5. Run dig TXT google.com and dig MX google.com. What do the TXT records say? What are the MX priorities?

Reflection prompts (~30 minutes)

1. DNS queries reveal every domain name your computer looks up. An observer watching your DNS traffic knows which websites you visit, even if the HTTP traffic is encrypted. What are the privacy implications?
2. DNSSEC prevents attackers from spoofing DNS responses, but it does not encrypt queries. What threat model does DNSSEC address? What threat model does DoT/DoH address?
3. DNS caching makes the system efficient but introduces a delay after a DNS record changes. If you change your server's IP address, why might some users still be reaching the old address hours later?
4. The 13 root servers are a single logical point of coordination for the entire Internet's naming system. Is this a vulnerability? (Look up how anycast makes the "13 servers" resilient.)
5. CNAME records create chains: www.example.com -> example.cdn.com -> example.prod.cdn.com -> 203.0.113.5. How many DNS queries does resolving www.example.com require if nothing is cached?

What comes next

Week 9 covers HTTP: the application layer that rides on top of TCP and TLS. You will trace an HTTP/1.1 conversation in full and complete a tour of the academy pcap-tools workbench.