Week 3 Day 4 — NETW-0014

0:00–0:10
Recap

0:10–1:45
Lab 3D

1:45–1:55
Bonus

1:55–2:00
Wrap

0:00 – 0:10Recap · 10 min

Forward DNS verified — now extend with reverse and redundancy

Quick check: dig @192.168.50.1 s1.yourname.net — should return S1's IP. Ask: "What is a reverse DNS lookup, and when would you need it?" — maps IP to hostname. Applications: SSH login logs showing hostnames instead of IPs; email servers check PTR records to verify that a sending mail server's IP matches its claimed hostname; security tools use PTR for readable output in reports.
Explain in-addr.arpa: reverse zones use a special domain that reverses the IP octets. For the 192.168.50.0/24 network, the reverse zone is 50.168.192.in-addr.arpa. The octets are reversed because DNS hierarchy reads left-to-right (general → specific), but IP addresses read left-to-right (network → host) — reversing the octets aligns them properly in the DNS tree.

0:10 – 1:45Lab 3D · 95 min

Lab 3D — Reverse zone, secondary DNS on S2, zone transfer verification, allow-transfer, dig

Part 1 — Add the reverse zone declaration (15 min)

Edit /etc/bind/named.conf.local on S1. Add the reverse zone declaration below the existing forward zone:
zone "50.168.192.in-addr.arpa" {
type primary;
notify no;
allow-query { any; };
file "/etc/bind/db.yourname.rev";
};
The zone name reverses the first three octets of your network and appends .in-addr.arpa.
Validate: sudo named-checkconf. Fix any errors before creating the database file.

Part 2 — Create the reverse zone database file (20 min)

Copy the reverse template: sudo cp /etc/bind/db.127 /etc/bind/db.yourname.rev. Edit: sudo nano /etc/bind/db.yourname.rev.
Build the reverse zone file:
$TTL 2D
@ IN SOA s1.yourname.net. hostmaster.yourname.net. (
2024112101 ; serial
3600 ; refresh
3600 ; retry
3600 ; expire
3600 ) ; minimum
@ NS s1.yourname.net.
1 PTR s1.yourname.net.
2 PTR s2.yourname.net.
The host portion only is used — 1 refers to 192.168.50.1, 2 refers to 192.168.50.2. PTR targets must be FQDNs with trailing dots.
Validate: sudo named-checkzone 50.168.192.in-addr.arpa /etc/bind/db.yourname.rev. Restart BIND9. Verify in the journal: look for both zones loading successfully.
Test: dig @192.168.50.1 -x 192.168.50.1. Should return s1.yourname.net.. Also test: nslookup 192.168.50.2 192.168.50.1. Should return s2.yourname.net.

Part 3 — Configure S2 as a secondary DNS server (30 min)

BIND9 is already installed on S2 from Lab 3C. Edit /etc/bind/named.conf.local on S2. Add the secondary zone declaration:
zone "yourname.net" {
type secondary;
file "db.yourname.net";
primaries { 192.168.50.1; };
};
Add the same declaration for the reverse zone with file "db.yourname.rev".
On S1, tell BIND to allow zone transfers to S2. Edit /etc/bind/named.conf.local on S1 and add allow-transfer { 192.168.50.2; }; inside each zone declaration:
zone "yourname.net" {
type primary;
notify yes; (change from 'no' to trigger notification on change)
allow-query { any; };
allow-transfer { 192.168.50.2; };
file "/etc/bind/db.yourname.net";
};
Restart BIND9 on S1. Then restart BIND9 on S2. Watch the S2 BIND9 log for the transfer: sudo journalctl -u named -f. You should see:
transfer of 'yourname.net/IN' from 192.168.50.1#53: Transfer status: success
Verify S2 can answer queries for the zone: dig @192.168.50.2 s1.yourname.net. Confirm the zone loaded from the transfer file in /var/cache/bind/.
Test the allow-transfer restriction: from S1 or another machine, attempt a full zone transfer from S2: dig @192.168.50.1 yourname.net AXFR from S2's perspective — only S2 should be allowed. Try from S3: dig @192.168.50.1 yourname.net AXFR — should return REFUSED.

Part 4 — Using dig for DNS interrogation (30 min)

dig syntax and output sections:
dig @server domain [type]
Output sections: QUESTION — what was queried. ANSWER — the result records. AUTHORITY — the authoritative nameserver for the zone. ADDITIONAL — glue records (A records for nameservers mentioned in AUTHORITY).
Status field: NOERROR = found, NXDOMAIN = name doesn't exist, REFUSED = server won't answer this query, SERVFAIL = server error.
Useful dig examples to test:
dig @192.168.50.1 yourname.net ANY — query all record types
dig @192.168.50.1 s1.yourname.net — standard A query
dig @192.168.50.1 -x 192.168.50.1 — reverse lookup (PTR)
dig @192.168.50.1 yourname.net NS — nameserver records
dig @192.168.50.1 yourname.net SOA — SOA record (verify serial)
dig @192.168.50.1 yourname.net AXFR — full zone transfer (should succeed from S1 to itself)
dig @192.168.50.1 yourname.net AXFR from S3 — should return REFUSED
Internet dig test: dig @172.17.0.1 google.com — verify S1 forwards to classroom DNS for internet names. dig @192.168.50.1 google.com — verify S1 also forwards correctly when queried directly.

Lab 3D complete when: Reverse zone loaded and PTR records resolve correctly via dig -x. S2 has successfully transferred both zones from S1 (confirmed in logs). S2 can answer queries for yourname.net. allow-transfer restricts AXFR to S2 only — S3 receives REFUSED. dig examples tested and output sections documented in lab sheet.

1:45 – 1:55Bonus · 10 min

Public zone transfer with dig — what AXFR reveals

Attempt a zone transfer of a permissive public test domain: dig @nsztm1.digi.ninja zonetransfer.me AXFR. This domain exists specifically to demonstrate zone transfer exposure.
Read the output — count the record types returned: A, AAAA, MX, TXT, SRV, CNAME. Ask: "If this were an internal corporate DNS zone, what would an attacker learn from this output?" — every server name and IP, mail server addresses, internal service names (SRV records), sometimes internal notes in TXT records.
Contrast with S1: dig @192.168.50.1 yourname.net AXFR from S3 — REFUSED. The allow-transfer restriction prevents this exact scenario.

1:55 – 2:00Wrap · 5 min

The DNS infrastructure built this week is used in Week 4 (Nginx virtual host config references yourname.net), Week 5 (VPN peer identification), and Week 6 (Docker service discovery). Make sure zones are working and S2 has a successful zone transfer before Monday.
Preview Friday's assessment: build a zone from a specification in 75 minutes. Required: forward zone with SOA/NS/A/CNAME, reverse zone with PTR records, named-checkzone passing, dig verification. The specification will use a different domain name — students cannot copy their Lab 3C zone file directly.

Learning outcomes — by end of Day 4, students can…

Build a reverse lookup zoneWrite a zone declaration using in-addr.arpa notation and create a zone file with correct PTR records and trailing dots on FQDNs

Configure secondary DNSWrite a type secondary zone declaration on S2 with the primaries directive, and verify successful zone transfer in the BIND9 log

Restrict zone transfersAdd allow-transfer to a primary zone and confirm AXFR is refused from unauthorised sources

Use dig for DNS interrogationQuery specific record types, interpret all four dig output sections, and explain what AXFR exposes

Common issues and fixes

Issue	Likely cause	Fix
Reverse lookup returns NXDOMAIN	PTR records missing trailing dots on FQDNs, or zone not reloaded after adding PTR records	Every PTR target must end with a dot: `1 PTR s1.yourname.net.` Reload: `sudo systemctl reload named`
Zone transfer on S2 fails — "connection refused" in log	S1's named.conf.local still has notify no and no allow-transfer for S2	Add `allow-transfer { 192.168.50.2; };` to both zone declarations on S1. Change `notify no` to `notify yes`. Restart S1's named
dig AXFR from S2 returns REFUSED	allow-transfer not yet added to S1's zone, or added to wrong zone block	Check S1's named.conf.local — allow-transfer must be inside the zone block, not outside it. Run named-checkconf after editing
S2's zone transfer succeeds but dig @S2 returns SERVFAIL	S2's BIND9 loaded a corrupted or incomplete zone file from the transfer	Delete the cached file on S2: `sudo rm /var/cache/bind/db.yourname.net`. Restart S2's named to re-transfer

← Day 3 Lab 3D Handout Day 5 →