Run a lab DNS zone with forward and reverse records, and watch the TTL

short · 50 min · Objective 2.2

Task

Make win-srv an authoritative DNS server for a lab zone, lab.internal, with A, CNAME, MX and PTR records, then query every record from lin-srv with dig. Change a record and watch a caching resolver keep the old answer until the TTL runs out -- the behaviour that makes DNS changes need planning.

Steps

  1. On win-srv, create a primary forward zone lab.internal and a reverse zone for 192.168.56.0/24. Add A records for lin-srv and win-srv, a CNAME files pointing to lin-srv, an MX record pointing to win-srv, and PTR records for both servers. Give the files CNAME's target a TTL of 300 seconds.
  2. From lin-srv, query each record directly against win-srv with dig @192.168.56.20, including dig -x for the reverse lookups, and save all the output to lab/dns/records.txt.
  3. Configure unbound on lin-srv to forward lab.internal to win-srv, query files.lab.internal through it, and save the answer with its TTL to lab/dns/cached-1.txt.
  4. Within five minutes of step 3, while unbound still holds the answer, change the lin-srv A record on win-srv to a different address. Query lin-srv.lab.internal against win-srv directly and through unbound, and save both answers to lab/dns/after-change.txt.
  5. Record in lab/dns/ttl.txt how long the stale answer would last and how you would have planned the change to shorten that.

Verify

These checks run in a POSIX shell: Terminal on macOS or Linux, and on Windows Git Bash (it comes with Git for Windows) or WSL. A stock Windows PowerShell or Command Prompt has no awk or grep, so there the first line fails.

grep -Ec 'IN[[:space:]]+(A|CNAME|MX|PTR)[[:space:]]' lab/dns/records.txt
grep -Ec 'IN[[:space:]]+PTR' lab/dns/records.txt
grep -Ec 'IN[[:space:]]+A[[:space:]]' lab/dns/after-change.txt
awk '/IN[[:space:]]+A[[:space:]]/ {print $NF}' lab/dns/after-change.txt | sort -u | wc -l
grep -Eic 'ttl|lower' lab/dns/ttl.txt

The records file has answers of all four types including PTR, and the after-change file has two A answers that disagree -- the authoritative server's new address and the resolver's cached old one -- so the last count prints 2. If it prints 1, you queried the authoritative server twice.

Notes

unbound-control flush lin-srv.lab.internal would clear the cached answer immediately, which is the resolver-side equivalent of ipconfig /flushdns. You cannot flush every resolver in the world, which is why the TTL is lowered before a planned change.

This is an independent study companion for CompTIA Server+ SK0-005 and is not produced by or endorsed by CompTIA.