Art of Codeartofcode
Lesson 11 of 15

4. DNS

1
The picture to keep in your head
2
4.1 Why do we need names at all?
3
4.2 What are the parts of a domain name?
4
4.3 What happens, step by step, when a name is looked up?
5
4.4 What kinds of DNS records are there?
6
4.5 What is a TTL, and why does DNS cache so much?
7
4.6 How can DNS spread users across servers or send them to the nearest one?
8
4.7 Why do DNS changes "take time to propagate"?
9
4.8 What happens when DNS fails?
10
Memory card and where the analogy breaks
11
Practice: five levels
12
Interview questions
13
Solutions
14
Sources
15
Code lab
4. DNS

Practice: five levels

3 min read+10 XP

Assignments

Five levels. Do them in order. Answers are in "Solutions" at the end, so try first.

Level 1: Think (no code)

A. Which record type would you add?

  1. Point api.example.com at the server 203.0.113.30.
  2. Point blog.example.com at a blogging platform that says "point your domain to hosting.blogplatform.net".
  3. Receive email for @example.com on two mail servers, with one as backup.
  4. Prove to a search console that you own example.com.
  5. Give example.com an IPv6 address.

B. True or false? Explain each.

  1. "After I change a DNS record, it's pushed to every server in the world within a few minutes."
  2. "If I give my site four A records, users will never reach a dead server."
  3. "I can make example.com (the bare domain) a CNAME to my hosting provider."

Level 2: Calculate

Assume about 10,000 resolvers worldwide send your users' questions to your authoritative name servers.

  1. With a TTL of 300 seconds, about how many queries a second reach your authoritative servers?
  2. With a TTL of 60 seconds? With 1 day?
  3. A resolver is 10 ms from the user, and 30 ms from each of the root, TLD and authoritative servers. How long does a lookup take with an empty cache? With the answer already in the resolver's cache?
  4. You move to new servers. The record's TTL was 1 day and you didn't lower it. In the worst case, how long might some users keep going to the old servers?

Level 3: Build

Write a toy recursive resolver in Python, with no real network calls. Simulate the hierarchy with dictionaries: a root that refers .com to a TLD server, a TLD server that refers example.com to ns1.example.com, and an authoritative server with an A record for shop.example.com, an A record for example.com, and a CNAME www.example.com → example.com.

Your resolve(name, now) must:

  1. Walk root → TLD → authoritative on an empty cache (3 queries).
  2. Answer from the cache while the TTL hasn't run out (no new queries).
  3. Ask again after the TTL expires.
  4. Follow a CNAME to the final IP address.
  5. Return None for a name that doesn't exist, and cache that for a short time.

Level 4: Debug

The bookstore moves to new servers. The runbook says:

1. Start the new servers at 198.51.100.7. 2. Change the A record for shop.example.com to 198.51.100.7 (TTL: 86400) 3. Switch off the old servers at 203.0.113.20 immediately.

The next day, support is flooded: "the site's been down for me since yesterday." Monitoring shows the new servers are healthy.

  1. Find the bug. Explain step by step why some users can't reach the site.
  2. Rewrite the runbook.

Level 5: Design

The bookstore expands to users in India, Europe and the US. It will run servers in Mumbai, Frankfurt and Virginia.

Deliver:

  1. How DNS sends each user to a nearby region.
  2. What happens when the whole Frankfurt region goes down, and how fast users move.
  3. Your TTL choices for the main records, and why.
  4. How you protect the site if your DNS provider itself has an outage.
  5. One limit of DNS-based routing, and how you'd work around it.