Chapter 8 Addressing & DNS
IP addresses as bits, subnet maths by hand, routing tables and ARP, sizing a network for a cluster, and DNS from the program's lookup to the root servers - including the ndots trap.
In plain words
Think of a city. Every house has a street address, the city is split into neighbourhoods, and at each crossroads there is a signpost that says "for the harbour, go left". When you want to visit a friend you usually know their name, not their address, so you look it up in a phone book first.
Networking works the same way. An IP address is the house number, a subnet (10.0.3.0/24) is the neighbourhood, the routing table (ip route) is the signposts, ARP (ip neigh) is knocking on the right door on your own street, and DNS (getent, dig, resolvectl) is the phone book. This chapter teaches each of those on oncall-lab, then puts them in the order you check them when something "cannot reach" something else.
Why it matters on call
Most "the app is down" tickets that are not a crash are one of four things: the name resolves to the wrong address, the packet takes the wrong route, two networks use the same addresses, or a cache still holds an old answer. After this chapter you can tell which in a few commands instead of guessing.
It also pays off outside incidents. When someone proposes a new network range, you can check sizes and overlaps in your head. When someone asks for a /24 for a 50-machine cluster, you know which questions to ask first. And subnet maths, "what happens when you type a URL" and "how does DNS resolution work" are standard platform and SRE interview questions. The next chapter (connections, encryption and web requests) builds directly on this one.
Lessons
- An address is a 32-bit number
- CIDR without a calculator
- Carving an address space: alignment, overlap, and plans you cannot undo
- Cloud subnets and sizing a cluster of machines
- The routing table: which way does a packet go
- Layer 2: ARP and the neighbour table
- How a name becomes an address on Ubuntu
- Reading dig properly
- Records, TTLs, negative caching and split horizon
- Search domains and the ndots trap
- A method for "I cannot reach X"
19 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Why learn IP arithmetic when ipcalc and online calculators exist?
Because the moments that matter do not have a calculator in them: a design meeting, an interview whiteboard, a quick look at a change that adds 10.1.4.0/22 next to 10.1.6.0/24. You need to see "that overlaps" in two seconds. The arithmetic is also how you understand why a route matched or why a subnet is full. Use ipcalc as the answer key, not as the brain.
Where will I use this outside the lab box?
Everywhere there is a network. Cloud networks are address ranges split into subnets with the same alignment rules; their route tables use longest prefix match like ip route; and every program on every server resolves names through the same kind of chain you trace here. The cloud adds a few reserved addresses per subnet, which the chapter shows. Learn the Linux version once and the rest is the same ideas with a different screen.
What order should I check things in when something cannot be reached?
Name, route, neighbour, port, packets. getent hosts X for what the app resolves, ip route get IP for the path, ip neigh for the next hop, nc -zv IP PORT for the service, tcpdump for the wire. Each step assumes the previous one is fine, so skipping ahead (checking the firewall first) is how an hour disappears. The last lesson of the chapter drills exactly this.
Is networking on my Mac the same as on the Ubuntu box?
The ideas are the same, the tools differ. macOS uses ifconfig, netstat -rn and route get, and its resolver is mDNSResponder, not systemd-resolved. Ubuntu uses the ip command, systemd-resolved behind 127.0.0.53, and netplan for permanent settings. Learn the Ubuntu versions: they are what you meet on servers.
Do I need IPv6 for this?
Not deeply yet. The chapter focuses on IPv4 because nearly every company network you will touch is IPv4-first. You will see IPv6 in passing: ::1 in /etc/hosts, AAAA questions that programs send next to A, and fe80:: entries in ip neigh. The ideas (prefixes, longest match, neighbour lookups) carry over; only the address length changes.