Week 4, Day 2 — DNS Views Verification

Lab 4B — Verify split responses, test recursion, update zone content per view

Part 1 — Verify internal view response from S2 (20 min)

• From S2 (a 192.168.50.x source — matches the internal view): dig @192.168.50.1 s1.yourname.net. Should return 192.168.50.1 (the internal IP). Also test: dig @192.168.50.1 yourname.net — should return the internal zone's SOA record.
• Test recursion from S2: dig @192.168.50.1 google.com. S2 is in the internal view which has recursion yes. This should resolve successfully, forwarding to the classroom DNS.
• Record both the IP returned and the view name BIND9 used. To see which view handled the query, check the BIND9 query log if query logging is enabled, or use the authority section of the dig output — the SOA record will tell you which zone file was used.

Part 2 — Verify external view response from Windows host (20 min)

• On the Windows host, open Command Prompt or PowerShell. The Windows host is on the 172.17.x.x classroom network — its source IP does not match the internal-nets ACL, so it should be served by the external view.
• Query S1 using its external IP:
  nslookup s1.yourname.net [S1-external-IP]
  Should return S1's external IP (172.17.x.x) — the external zone file record.
• Test recursion from the Windows host: nslookup google.com [S1-external-IP]. Should fail or return SERVFAIL/REFUSED — the external view has recursion no, so S1 won't resolve internet names for external clients.
• Record the results in the lab sheet comparison table.

Part 3 — Update zone content to reflect view differences (25 min)

• Enhance the internal zone file with additional records: add an A record for a new internal-only host. Increment the serial. Reload named: sudo systemctl reload named. Verify the new record resolves from S2 but not from the Windows host (it's not in the external zone).
• This demonstrates the core use case: internal services (databases, management interfaces, monitoring servers) have DNS records that internal clients can resolve, but external clients have no knowledge of them.
• For the external zone: ensure www.yourname.net resolves to S1's external IP from the Windows host. This is what an internet user would see — the web server's public-facing address. Browse to http://S1-external-IP from the Windows host to confirm connectivity. (Nginx isn't installed yet — the default Nginx page is fine for now.)

Part 4 — Secondary DNS with views (35 min)

• S2 currently has secondary zone declarations from Week 3. With views now in use on S1, S2 needs to be updated — it must also use views, and its zone declarations must be inside view blocks that match S1's structure.
• On S2, edit /etc/bind/named.conf.local. Restructure the secondary declarations inside a view block:
  view "internal" {
match-clients { any; }; // S2 serves all clients from its internal data
zone "yourname.net" {
type secondary;
file "db.yourname.net.internal";
primaries { 192.168.50.1; };
};
};
  Note: S2 only needs the internal view — it serves internal clients on LAN1. It doesn't need to replicate the external zone unless it also serves as an external nameserver. Keep it simple.
• Restart named on S2. Check the journal for zone transfer from S1. Verify S2 answers queries for yourname.net with the internal IP.