Homelab Build — Part 5 — DNS

What This Part Covers

Part 4 promoted dc01 and dc02 and confirmed they replicate, but it deliberately left DNS in whatever state Install-ADDSForest -InstallDns put it in. That’s fine for standing up a forest — it is not fine to leave permanently. This part makes two things explicit: which server dc01 and dc02 forward unresolved queries to, and whether stale records ever get removed.

Think of the forwarder setting as the lab’s only deliberate opinion about where “the rest of the internet” lives. Everything internal already resolves through AD-integrated DNS; the forwarder is the one line that decides what happens when a query is for something outside lab.example.com entirely.

Why This Needs a Deliberate Forwarder, Not the Inherited One

When Install-ADDSForest -InstallDns ran on dc01 in Part 4, the new DNS Server service typically carried over whatever forwarder dc01’s own network settings pointed at right before promotion — in this lab, that was pfSense’s Servers-segment interface, 10.10.10.1, which Part 4 had configured as dc01’s temporary DNS client server. That happens to be a reasonable forwarder for this lab, but “happens to be reasonable” and “was deliberately chosen and verified” are different things, and only one of them belongs in a build worth trusting.

pfSense’s own resolver ultimately reaches the internet through the lab’s WAN connection, so forwarding to 10.10.10.1 keeps external DNS traffic consolidated at the same box already doing NAT and firewalling for the lab — one place to see what’s leaving the network, instead of two domain controllers each independently querying root servers.

Forwarders, Conditional Forwarders, and Root Hints

A DNS server configured with a forwarder tries its own zones and cache first. Only if that fails does it forward the query — as a recursive query — to the configured forwarder IP addresses, in the order they’re listed. If none of them answer, and root hints are still enabled, the server falls back to iterative queries against the internet root servers directly.

A conditional forwarder is the same idea scoped to one specific domain name rather than everything: queries for names ending in a particular suffix go to a specific set of servers, while everything else follows the normal forwarder or root hints path. This lab has no other DNS namespace to conditionally forward to yet — that becomes relevant if a future part adds a second forest or a partner domain, not before.

Configuring the Forwarder

Set the forwarder explicitly on both dc01 and dc02 rather than trusting whichever one inherited a working setting during promotion. Set-DnsServerForwarder overwrites the existing forwarder list, so this is safe to run even if the current value already happens to be correct.

# On dc01 and dc02: set pfSense as the explicit forwarder, keep root hints enabled as a fallback
Set-DnsServerForwarder -IPAddress 10.10.10.1 -UseRootHint $true -PassThru

# Confirm the forwarder list and whether root hint fallback is enabled
Get-DnsServerForwarder

Checking the Zone’s Replication Scope

Install-ADDSForest -InstallDns created lab.example.com as an Active Directory-integrated zone stored in the domain-wide DomainDnsZones application partition by default — meaning it replicates to every DNS server running on a domain controller in lab.example.com, which today is both dc01 and dc02. That is the correct scope for a single-domain forest like this one; ForestDnsZones scope only matters once a second domain joins the forest and needs to see the same zone.

# Confirm the zone is AD-integrated and check its current replication scope
Get-DnsServerZone -Name "lab.example.com" | Select-Object ZoneName, ZoneType, IsDsIntegrated, ReplicationScope

Enabling Aging and Scavenging

Aging and scavenging are disabled by default on every Windows DNS zone and server, on purpose — Microsoft’s own guidance is to enable them only once every interval involved is understood, because a misconfigured combination deletes records that are still in use. This lab is exactly the environment scavenging is meant for: VMs get rebuilt, renamed, and re-IP’d constantly as later parts of this series experiment, and none of that cleans up its old DNS records on its own.

Zone-level aging replicates with the AD-integrated zone once enabled — set it once, on either DC, and it propagates. Server-level scavenging does not replicate; it has to be enabled individually on whichever server actually does the scavenging.

# On either DC: enable aging on the zone with the standard 7-day/7-day defaults
Set-DnsServerZoneAging -Name "lab.example.com" -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00 -ScavengeServers 10.10.10.10

# On dc01 only: enable server-level scavenging, since dc01 is the one designated scavenge server
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00

With the defaults above, a record becomes eligible for scavenging only after both the no-refresh and refresh intervals elapse — 14 days combined — and the next scavenging cycle after that actually deletes it. Records added manually rather than through dynamic updates get a zero timestamp and are excluded from scavenging entirely unless that timestamp is deliberately reset, so anything hand-entered as a static record — a future file server’s A record, say — is already safe by default.

Verifying the Configuration

Confirm both settings landed before relying on them, and check the DNS event log after the first cycle rather than assuming silence means success.

# Confirm zone aging settings and which server is designated to scavenge
Get-DnsServerZoneAging -Name "lab.example.com"

# Confirm server-level scavenging is enabled and the interval that was set
Get-DnsServerScavenging

# Force an immediate scavenging pass instead of waiting a full 7-day cycle, and see what it would remove
Start-DnsServerScavenging -Verbose

DNS Configuration Issues

Final Thoughts

DNS in this lab now does two things it wasn’t doing after Part 4: it forwards external queries somewhere chosen on purpose, and it cleans up after itself. Neither one shows up as a visible feature — they show up as the absence of a future problem, which is exactly the kind of homelab work that’s easy to skip and expensive to have skipped once a dozen rebuilt VMs have left stale A records scattered through the zone.

What’s still missing on purpose: no certificate authority yet, so no LDAPS or internal TLS; no Group Policy beyond the domain defaults; and dc01 and dc02 still trust whatever time source they picked up during promotion, unverified. Time is next, because Part 7’s certificate authority depends on clocks staying close enough together for certificate validity checks to behave.