DHCP Exhaustion and Split DNS After a Campus Expansion
A university campus serves 8,000 concurrent endpoints across three buildings: about 2,000 wired staff devices, 4,500 student laptops and phones on Wi-Fi, and 1,500 guest devices. DHCP runs on two Windows servers in a 50/50 failover relationship serving a single /20 (10.50.0.0/20) for the student SSID, with an 8-day lease; wired staff use static addresses except for 300 printers. At 10:00 each weekday students report "no internet" and capture 169.254.x.x addresses; the servers show 100% pool utilization but only about 3,800 unique clients. Guests receive addresses from the same /20. DNS is handled by two domain controllers for the internal zone corp.local; the VPN concentrator pushes only external resolvers, so remote staff resolve intranet.example.com to its public IP, and their sessions hairpin through the internet edge, where the firewall drops them. The university owns example.edu but not example.com.
1. Diagnose the 10:00 exhaustion and propose scope and lease changes with numbers.
Read the worked answer
Diagnosis. A /20 provides 4,094 addresses. Subtract the gateway, the broadcast and a handful of reservations and you have roughly 4,090 usable. The student and guest populations alone total 6,000 devices, and with 8-day leases almost every address ever handed out stays unavailable for a week. The pool is under-sized by design, not by a rogue client. The clue that only 3,800 clients appear is expected: the servers count distinct leases, while devices that failed to get one never show up, and stale leases from departed devices occupy the rest.
Fix.
- Split the scopes. Student Wi-Fi: 10.50.16.0/19 gives 8,190 addresses for 4,500 concurrent devices with roughly 80% headroom, which covers the September spike. Guest: 10.50.8.0/21 with a 4-hour lease and client isolation, since guests churn fast and rarely stay a day.
- Wired staff per building: /22 each, 8-day lease is fine there. Printers: static reservations in a dedicated /24.
- Wireless lease of 4–8 hours, not 8 days; with a 4-hour lease, 4,500 concurrent devices generate churn that a /19 absorbs comfortably.
- Keep DHCP failover in hot-standby with 5% reserve, enable conflict detection, and add DHCP snooping on access ports so a rogue server cannot hand out addresses.
- Alert at 70% pool utilization, not at 100%; the 10:00 cliff should have been visible as a trend for days.
2. How would you fix the VPN split-DNS problem given that the university owns example.edu but not example.com?
Read the worked answer
Root cause. The internal namespace lives in corp.local, which is not delegated in public DNS and conflicts with mDNS conventions. Meanwhile intranet.example.com exists publicly, presumably at the internet edge, so a VPN client using only external resolvers gets a public answer, opens a session to the public VIP, and the edge firewall drops the hairpin. The fix is a naming and resolver-policy change, not a firewall rule.
Design.
- Move internal services into a delegated subdomain of the owned domain, for example intranet.example.edu, with an internal zone on the domain controllers and a public zone that either omits the host or points it at the reverse proxy. Do not use .local.
- Use split-horizon DNS: internal resolvers answer authoritatively for the internal view; external resolvers never see the internal records. Note that split horizon and DNSSEC conflict on the same name, so keep signed public names separate from internal-only names.
- Push the internal resolvers (or a DNS proxy on the concentrator) to VPN clients via DHCP option 6 or the VPN profile, with a conditional forwarder for the rest. If split tunneling is used, ensure the route to the internal resolver is included in the tunnel.
- Interim, before renumbering: publish a VPN-only record set, or front the intranet with a reverse proxy that is reachable from the internet edge, and remove the firewall drop for that specific VIP and port rather than allowing general hairpin traffic.
The judgement point: hairpinning is a symptom of a naming decision made years earlier; fixing DNS is cheaper and safer than opening the edge.