Chapter 7 · Hands-on labs
Six short labs that turn the slides into commands you actually run — resolve names, walk the DNS hierarchy, watch TTLs tick down, sniff DNS on the wire, and capture a real DHCP DORA handshake. Each maps to a Chapter 7 topic and ends by connecting what you saw back to the concept.
dnsutils (dig, nslookup), tcpdump, nmap. If one is missing: sudo apt install -y dnsutils tcpdump nmap. The ❯ is just the prompt — the Copy button copies only the command.The basic lookup — name → IPv4 (the A record):
dig +short www.google.com A
142.250.74.36
Other record types — IPv6, mail and name servers:
dig +short google.com AAAA dig +short google.com MX dig +short google.com NS
2607:f8b0:4004:c07::71 10 smtp.google.com ns1.google.com ns2.google.com ...
Same question, three tools. Compare their output styles:
nslookup www.google.com host www.google.com
dig shows the most detail.dig example.com A and read the full output (no +short). Which record type is in the ANSWER section, and what is its TTL? (answer below)Trace the whole hierarchy — dig starts at the root and follows referrals down:
dig +trace www.google.com
. NS a.root-servers.net. <- root com. NS a.gtld-servers.net. <- TLD (.com) google.com. NS ns1.google.com. <- authoritative www.google.com. A 142.250.74.36 <- the answer
Each block is one level replying “I don’t know, but ask this server” — the referral chain from the slides, made visible.
Ask one specific level yourself — query a root server directly and watch it refer you to .com:
dig @a.root-servers.net www.google.com
+trace performs the iterative walk itself: root delegates to the TLD, the TLD delegates to the authoritative server, and only the authoritative server returns the real A record.+trace output, which server type finally returns the A record — root, TLD, or authoritative? (answer below)Who is your resolver? The server that caches on your behalf:
cat /etc/resolv.conf resolvectl status 2>/dev/null | grep -i "DNS Server" || true
Query twice, fast. Watch the TTL in the ANSWER section shrink the second time:
dig example.com | grep -A1 "ANSWER SECTION" sleep 5 dig example.com | grep -A1 "ANSWER SECTION"
;; ANSWER SECTION: example.com. 3600 IN A 93.184.216.34 ;; ANSWER SECTION: example.com. 3595 IN A 93.184.216.34
The TTL fell by ~5 seconds — the resolver is counting down the cached entry’s life. When it hits 0, the next query goes back to the authoritative server.
dig and look at the flags: line. Is the aa (authoritative answer) flag set when you ask your local resolver? (answer below)Start the sniffer in Terminal A — watch UDP port 53:
sudo tcpdump -i any -n udp port 53
Trigger a lookup in Terminal B (use a fresh name so it isn’t already cached):
dig kali.org
IP 192.168.1.23.51512 > 192.168.1.1.53: A? kali.org. IP 192.168.1.1.53 > 192.168.1.23.51512: A kali.org. 192.124.249.13
One packet out to port 53 (the question), one packet back (the answer) — DNS is a quick UDP question-and-answer, just as the slide says.
A? query with its matching reply — the on-the-wire proof that DNS is a UDP/53 request-response protocol.dig for the same name twice while tcpdump runs. Why do you see packets the first time but maybe not the second? (answer below)You’ll send a DHCP Discover safely with nmap’s broadcast script and watch the whole exchange in tcpdump. Do this only on your own LAN / lab.
Start the sniffer in Terminal A — DHCP uses UDP ports 67 & 68:
sudo tcpdump -i any -n port 67 or port 68
Send a Discover in Terminal B (nmap builds and broadcasts it for you):
sudo nmap --script broadcast-dhcp-discover
| broadcast-dhcp-discover: | IP Offered: 192.168.1.57 | Server Identifier: 192.168.1.1 | IP Address Lease Time: 1 day |_ Router / DNS Servers: 192.168.1.1
IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from ... Discover IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply ... Offer IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request ... Request IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply ... ACK
Read the packets: source 0.0.0.0 → destination 255.255.255.255, ports 68 → 67 (client → server) and 67 → 68 back — the exact values from the slides.
What did DHCP give you? Your address, gateway and DNS server:
ip -br addr ip route | grep default resolvectl status 2>/dev/null | grep -i "DNS Server" || cat /etc/resolv.conf
Read the lease itself (path varies by client — try each):
cat /var/lib/dhcp/dhclient.leases 2>/dev/null sudo grep -ri "lease\|dhcp" /var/lib/NetworkManager/ 2>/dev/null | head
lease {
fixed-address 192.168.1.23;
option routers 192.168.1.1;
option dhcp-lease-time 86400;
option domain-name-servers 192.168.1.1;
}DNS in reverse — turn an IP back into a name with a PTR lookup:
dig -x 8.8.8.8 +short
dns.google.
dig -x uses a PTR record to map the IP back to a name — both chapter concepts, on your own machine.dhcp-lease-time 86400. How long is that, and what must happen before it expires? (answer below)Lab 1. The ANSWER section holds an A record; the number before IN A (e.g. 3600) is its TTL in seconds — how long resolvers may cache it.
Lab 2. The authoritative server returns the real A record. The root and TLD servers only hand back referrals (NS records) pointing one level deeper.
Lab 3. No — when you ask your local resolver, the aa flag is not set: the answer is cached/relayed, i.e. unauthoritative. You’d only see aa when querying the authoritative server directly.
Lab 4. The first lookup isn’t cached, so it goes out over UDP/53 and you see both packets. The second is served from the resolver’s cache (while the TTL lasts), so no new query leaves — caching in action.
Lab 5. The server is on port 67, the client on port 68. Discover/Request go 68 → 67; Offer/Ack come back 67 → 68.
Lab 6. 86400 seconds = 24 hours. Before it expires the client must renew the lease (typically at ~50% of the lease time) or it loses the address.
| This lab’s tool | Connects to… |
|---|---|
| dig / nslookup (Labs 1–3) | Chapter 2 — addressing & the resolver’s place in the stack |
| tcpdump on UDP/53 & 67/68 (Labs 4–5) | Chapter 8 — UDP, the transport DNS & DHCP ride on |
| DHCP DORA & broadcast (Lab 5) | Chapter 4 & the NSSA-241 capstone — configuring a DHCP server on a router |
| dig -x / PTR (Lab 6) | Chapter 4 & 6 — IP addressing and the in-addr.arpa reverse zone |