Week 4 Day 1 — NETW-0014

0:00–0:30
Lecture

0:30–1:50
Lab 4A

1:50–2:00
Debrief

0:00 – 0:30Lecture · 30 min

Why split-horizon DNS exists and how BIND9 views implement it

Part 1 — The split-horizon problem (8 min)

Draw the scenario on the board: S1 has two IPs — 172.17.x.x (external, classroom network) and 192.168.50.1 (internal, LAN1). Both internal and external clients want to reach www.yourname.net. The single DNS A record currently points to one IP. Ask: "Which IP should it point to?"
If it points to the external IP (172.17.x.x): internal clients (S2, S3) route a request for yourname.net out through the NAT gateway and back in through the external NIC — hairpin routing. This is inefficient, may not work depending on firewall rules, and is completely unnecessary. Internal clients should go directly to 192.168.50.1.
If it points to the internal IP (192.168.50.1): external clients (Windows host on the classroom network) can't reach it — 192.168.50.1 is a private address not routable outside the lab network.
The solution: the same domain name resolves to different IPs depending on who asks. Internal clients get the internal IP. External clients get the external IP. This is split-horizon DNS — also called split-view, split-brain, or split DNS. It is the standard approach in corporate networks where internal and external services share domain names.

Part 2 — BIND9 views (12 min)

BIND9 implements split-horizon using view blocks in named.conf.local. Each view has: a name (quoted string), a match-clients directive (which source IPs this view applies to), and zone declarations for all zones this view should answer. A view can also have its own recursion, allow-query, and forwarders settings.
Write the skeleton on the board:
view "internal" {
match-clients { 192.168.50.0/24; 127.0.0.1; };
recursion yes;
zone "yourname.net" { type primary; file "...internal..."; };
};
view "external" {
match-clients { any; };
recursion no;
zone "yourname.net" { type primary; file "...external..."; };
};
View ordering: BIND checks views top to bottom. The first view whose match-clients matches the source IP of the query is used — no further views are checked. This means internal must appear before external. If external (match-clients { any; }) appeared first, every client would match it, and the internal view would never be reached.
Zones must be inside views: Once you use views, every zone declaration must be inside a view. A zone defined both inside and outside a view block causes BIND9 to refuse to start. This means the reverse zone from Week 3 also needs to be moved into the view structure.
Named ACLs: Rather than repeating IP lists in every view, define a named ACL once and reference it by name:
acl "internal-nets" { 192.168.50.0/24; 192.168.51.0/24; 127.0.0.1; };
Then use: match-clients { "internal-nets"; };
ACLs are defined in named.conf.options before the options block.
Recursion no on external view: This prevents S1 from being used as a recursive resolver by external clients. Without it, anyone on the internet could use S1 to resolve any domain — making it an open resolver. Open resolvers are exploited in DNS amplification attacks. Turning off recursion for external clients means S1 will only answer queries about zones it is authoritative for when queried from external IPs.

Part 3 — Zone file differences (10 min)

The internal zone file for yourname.net contains internal IPs: s1.yourname.net → 192.168.50.1, s2 → 192.168.50.2, etc. Clients inside the lab use these addresses for direct, efficient access.
The external zone file for yourname.net contains public IPs: s1.yourname.net → 172.17.x.x (S1's external IP). External clients reach the server through the classroom network. Typically the external zone has fewer records — only what external clients should see. Internal-only hosts (S2, S3) don't need to be in the external zone.
Naming convention for zone files: internal zone → db.yourname.net.internal, external zone → db.yourname.net.external. This makes it immediately obvious which file belongs to which view when listing /etc/bind/.

0:30 – 1:50Lab 4A · 80 min

Lab 4A — Migrate yourname.net into BIND9 views with separate internal/external zone files

Part 1 — Backup existing DNS configuration (10 min)

Before touching anything, back up all zone files and named.conf.local:
sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.pre-views
sudo cp /etc/bind/db.yourname.net /etc/bind/db.yourname.net.pre-views
sudo cp /etc/bind/db.yourname.rev /etc/bind/db.yourname.rev.pre-views
Verify named-checkconf passes before starting: sudo named-checkconf. Fix anything that's broken before the migration.

Part 2 — Define the internal-nets ACL (10 min)

Edit /etc/bind/named.conf.options. Before the options { } block, add the ACL definition:
acl "internal-nets" {
192.168.50.0/24;
192.168.51.0/24;
127.0.0.1;
};
Validate: sudo named-checkconf. ACL syntax errors are common — the semicolons after each network and after the closing brace are all required.

Part 3 — Restructure named.conf.local with view blocks (25 min)

Edit /etc/bind/named.conf.local. Replace its entire contents with the following view structure (using your own domain name and IPs):
view "internal" {
match-clients { "internal-nets"; };
recursion yes;
allow-recursion { "internal-nets"; };

zone "yourname.net" {
type primary;
notify yes;
allow-query { any; };
allow-transfer { 192.168.50.2; };
file "/etc/bind/db.yourname.net.internal";
};

zone "50.168.192.in-addr.arpa" {
type primary;
file "/etc/bind/db.yourname.rev.internal";
};
};

view "external" {
match-clients { any; };
recursion no;

zone "yourname.net" {
type primary;
notify no;
allow-query { any; };
file "/etc/bind/db.yourname.net.external";
};
};
Validate: sudo named-checkconf. Common errors at this stage: missing semicolons after zone block closing braces, view block not closed, or file paths that don't exist yet (which is expected — the zone files haven't been created yet). named-checkconf will not complain about missing files — that error appears only when named tries to load them.

Part 4 — Create internal and external zone files (35 min)

Internal zone file — copy from the existing zone as a base:
sudo cp /etc/bind/db.yourname.net /etc/bind/db.yourname.net.internal
The internal zone file stays largely the same — it already has the 192.168.50.x IPs. Update the serial number.
External zone file:
sudo cp /etc/bind/db.yourname.net /etc/bind/db.yourname.net.external
Edit to replace internal IPs with external ones:
· s1 A record → S1's external IP (172.17.x.x)
· Remove s2 and s3 A records — external clients don't need internal-only hosts
· Keep www CNAME → s1
· Update serial number
Internal reverse zone file:
sudo cp /etc/bind/db.yourname.rev /etc/bind/db.yourname.rev.internal
No changes needed — PTR records point to internal hostnames which is correct for internal clients.
Validate all three zone files:
sudo named-checkzone yourname.net /etc/bind/db.yourname.net.internal
sudo named-checkzone yourname.net /etc/bind/db.yourname.net.external
sudo named-checkzone 50.168.192.in-addr.arpa /etc/bind/db.yourname.rev.internal
Restart BIND9: sudo systemctl restart named. Check the journal for both zone load lines — internal and external. Any errors will identify which zone file and what line number.

Lab 4A complete when: named-checkconf passes. named-checkzone passes for all three zone files. BIND9 restarts cleanly. Journal shows both internal and external zones loaded for yourname.net.

1:50 – 2:00Debrief · 10 min

Ask: "What happens if the external view is placed before the internal view in named.conf.local?" — every query matches the external view first (because any matches everything), the internal view is never reached, and internal clients get external IPs. View order is not optional.
Preview Tuesday: we can see the zones loaded in the journal, but have we confirmed the split is actually working? Tuesday is about verifying the different responses from inside and outside.

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

Explain split-horizon DNSDescribe the problem it solves and draw the network scenario that makes it necessary

Define a named ACLWrite an acl block in named.conf.options and reference it by name in a view's match-clients directive

Write view blocks in named.conf.localStructure internal and external views with correct match-clients, recursion, and zone declarations

Create separate zone files per viewMaintain internal (192.168.x.x) and external (172.17.x.x) versions of the same zone with appropriate records in each

Common issues and fixes

Issue	Likely cause	Fix
named-checkconf: "view 'internal': zone already in another view"	Old zone declarations still exist outside the view blocks — they weren't removed when the views were added	Edit named.conf.local and ensure there are no zone declarations outside the view blocks. All zones must be inside a view once views are used
BIND9 fails to start: "not found" for zone file	Zone file path in the view declaration doesn't match the actual file path/name	Check paths carefully — the file names must include .internal or .external suffix. Verify with: ls /etc/bind/db.*
named-checkconf passes but both views return the same response	Both zone files have the same records (internal file not updated)	Verify the external zone file has the external IP (172.17.x.x) for s1, not the internal IP
Reverse zone breaks after migration to views	Reverse zone not included inside the internal view block	The reverse zone declaration must be inside one of the view blocks. It typically belongs in the internal view only, since external clients don't need PTR lookups for internal addresses

← Week 4 Overview Lab 4A Handout Day 2 →