Internal DNS Zone Management

Scope: All DTC-managed client environments with Active Directory
Audience: T1 / T2 / T3 Technicians
Last Updated: March 2026
Version: 1.0

1. Purpose

This document covers the internal DNS zone management responsibilities that live on the Domain Controller — zone configuration, conditional forwarders, split DNS behavior, and DNS scavenging. These are separate from external DNS filtering (DNSFilter) and from the UDM's DNS policy configuration.

Why this matters: The UDM is the sole DNS server for all endpoints (per the Ubiquiti Config Quick Reference standard). But the UDM doesn't host AD-integrated zones — it forwards AD domain queries to the DC via Forward Domain rules. The DC still owns and manages the internal DNS zones that Active Directory depends on. If those zones are unhealthy, Forward Domain rules have nothing useful to forward to.

2. How DNS Resolution Works (DTC Standard)

Understanding the flow prevents misconfiguration. Every query follows this path:

ENDPOINT (workstation, phone, printer, server)
  │  DNS server = UDM gateway IP (assigned via DHCP, Auto DNS Server = Enabled)
  │
  ▼
UDM GATEWAY (sole DNS server for ALL devices)
  │
  ├─ Query matches a Forward Domain rule (e.g., ad.company.com)?
  │    YES → Forward to Domain Controller IP(s) listed in the rule
  │           DC resolves from its AD-integrated zones
  │
  ├─ Query matches a static A or CNAME record on the UDM?
  │    YES → UDM resolves it locally, returns the answer
  │
  └─ Everything else (external queries)?
       → Forward to upstream DNS (DNSFilter 103.247.36.36/37)

The DC never receives queries directly from endpoints. It only receives forwarded queries from the UDM for the AD domain. This is by design — it centralizes DNS visibility on the UDM and ensures all external queries go through DNSFilter for content filtering and threat protection.

3. Internal DNS Zones on the Domain Controller

3.1 What Lives on the DC

The DC hosts AD-integrated DNS zones that Active Directory created automatically during domain promotion (dcpromo). These zones are critical — AD literally cannot function without them.

Forward Lookup Zone — The AD Domain (e.g., ad.company.com)

Contains:

A records for domain-joined machines (servers, workstations) — registered automatically via DHCP/dynamic DNS
SRV records for AD services — _ldap._tcp, _kerberos._tcp, _gc._tcp, _msdcs subzone — these are how workstations find domain controllers for authentication, GPO processing, and replication
Manually created A records for any resources that need internal name resolution but aren't domain-joined (rare in DTC environments)

Reverse Lookup Zones (optional)

Maps IP → hostname. Not strictly required for AD but useful for diagnostics. DTC does not mandate reverse lookup zones — they're nice to have, not a blocker.

_msdcs Subdomain

A delegated zone (or sub-zone) that holds the DC locator records. If this zone is missing or corrupted, workstations cannot locate domain controllers. This is the most critical DNS zone in the environment.

3.2 What Does NOT Live on the DC

Important: In AD environments, static DNS entries for servers belong in Windows DNS Server on the DC ONLY. The UDM's Forward Domain rule forwards AD domain queries to the DC, which resolves them from its own zone. Do NOT create duplicate static entries on the UDM for AD environments. The UDM handles external DNS independently — internet uptime should never depend on Windows Server being operational.

In workgroup/cloud-only environments (no AD), static DNS entries go on the UDM only — there is no Windows DNS Server.

External domain resolution — The DC does not resolve google.com, vendor sites, or cloud services. Those go UDM → DNSFilter.
Static entries for infrastructure devices — In AD environments, BDR, QNAP, printers, and reverse proxy entries belong in Windows DNS Server on the DC (the Forward Domain rule handles forwarding). In workgroup environments, these go on the UDM as static A/CNAME records.
DNSFilter configuration — DNSFilter is configured on the UDM's WAN upstream settings and in the DNSFilter portal. The DC has no involvement.

3.3 Quick Health Check (Run on DC)

# Verify DNS zones exist and are AD-integrated
Get-DnsServerZone | Select-Object ZoneName, ZoneType, DsIntegrated | Format-Table -AutoSize

# Verify critical SRV records exist (replace YOURDOMAIN.LOCAL)
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.YOURDOMAIN.LOCAL" -Type SRV

# Verify DNS service is running
Get-Service DNS | Select-Object Name, Status, StartType

Expected output:

The AD domain zone shows ZoneType: Primary, DsIntegrated: True
SRV records return DC hostnames and ports
DNS service is Running with StartType: Automatic

4. Conditional Forwarders

4.1 What They Are

A conditional forwarder tells a DNS server: "When you get a query for THIS specific domain, send it to THAT specific DNS server instead of using your default forwarders."

In the DTC model, the UDM's Forward Domain rules serve this function for most scenarios. But conditional forwarders on the DC itself are needed in specific situations.

4.2 When to Use Conditional Forwarders on the DC

Scenario 1: Multi-Domain AD Trusts

If a client has a trust relationship with another AD domain (e.g., a DSO acquiring a practice), the DC needs to know how to resolve the other domain's SRV records for trust authentication.

Example: ad.mainoffice.com trusts ad.newpractice.com

On the ad.mainoffice.com DC: Add conditional forwarder for ad.newpractice.com → IP of ad.newpractice.com DC
On the UDM: Add Forward Domain rule for ad.newpractice.com → same DC IP

Both are needed — the UDM forwards endpoint queries, and the DC uses its own conditional forwarder for server-to-server trust operations.

Scenario 2: Vendor-Specific Internal Domains

Rare, but if a dental software vendor requires resolution of an internal domain that isn't the AD domain (e.g., a vendor appliance that serves its own DNS zone), a conditional forwarder on the DC can route those queries correctly.

Scenario 3: Multi-Site with Separate DNS Infrastructure

4.3 How to Configure (on the DC)

PowerShell:

# Add a conditional forwarder
Add-DnsServerConditionalForwarderZone -Name "ad.newpractice.com" -MasterServers 10.0.2.10

# Verify
Get-DnsServerZone -Name "ad.newpractice.com"

# Remove if no longer needed
Remove-DnsServerZone -Name "ad.newpractice.com" -Force

DNS Manager GUI:

Open DNS Manager → right-click Conditional Forwarders → New Conditional Forwarder
DNS Domain: the target domain FQDN
IP addresses: the DNS server(s) for that domain
Check Store this conditional forwarder in Active Directory if you want it replicated to all DCs in the domain

Don't forget the UDM side: If endpoints also need to resolve the forwarded domain, add a matching Forward Domain rule on the UDM. The DC conditional forwarder only handles queries that reach the DC — and in the DTC model, queries only reach the DC because the UDM forwarded them.

4.4 Tier Responsibilities

Tier	Scope
T1	Does not configure conditional forwarders. Escalate if a trust or multi-domain scenario is suspected.
T2	Can add/remove conditional forwarders for documented scenarios. Must also configure the matching UDM Forward Domain rule.
T3	Designs multi-domain DNS architecture, trust relationships, and complex forwarding chains.

5. Split DNS Behavior

5.1 What "Split DNS" Means at DTC

Split DNS means the same hostname resolves to different IPs depending on where the query originates. In the DTC architecture, split DNS happens naturally through the UDM's Forward Domain rules.

How it works:

A query for server01.ad.company.com from a workstation on the LAN → UDM → Forward Domain rule → DC → returns internal IP (e.g., 10.0.1.10)
A query for server01.ad.company.com from the public internet → public DNS has no record → resolution fails (as intended — internal resources are not publicly resolvable)

This is the correct behavior. Internal resources resolve internally. External resources resolve externally. The UDM sits in the middle and routes appropriately.

5.2 When Split DNS Causes Problems

Problem: AD domain uses a publicly routable name the client doesn't own

Example: A practice uses null.com or corp.com as their AD domain. Internally, server.null.com should resolve to 10.0.1.10. But publicly, null.com resolves to someone else's IP.

In the UDM-centric model, the Forward Domain rule handles this — queries for null.com go to the DC, not to public DNS. But if the Forward Domain rule is missing, broken, or the WARP client bypasses it, queries escape to public DNS and return wrong results.

Fix: Ensure the Forward Domain rule exists and matches the exact AD domain FQDN. For WARP environments, configure Local Domain Fallback in Cloudflare Zero Trust (see Cloudflare WARP SOP).

Problem: Dental cloud services that need both internal and external resolution

Some dental platforms (Dentrix Ascend Connector, Eaglesoft eServices, Open Dental eConnector) need to reach external cloud endpoints. These resolve through the normal external path: UDM → DNSFilter → public DNS. No special configuration needed — the Forward Domain rule only captures queries matching the AD domain. Everything else goes upstream automatically.

5.3 Verification

# From a workstation — verify internal resolution goes through UDM
nslookup server01.ad.company.com
# Server should show UDM gateway IP, answer should show internal IP

# Verify external resolution also works
nslookup google.com
# Server should show UDM gateway IP, answer should show public IP

# If nslookup shows a DC IP as the server instead of UDM → endpoint DNS is misconfigured
ipconfig /all
# DNS Servers should show ONLY the UDM gateway IP

6. DNS Scavenging

6.1 What It Is

DNS scavenging is Windows DNS Server's mechanism for automatically removing stale (outdated) DNS records. When a machine leaves the network — decommissioned workstation, replaced server, old laptop — its DNS A record stays behind unless scavenging cleans it up.

6.2 Why It Matters

Stale records cause intermittent and confusing name resolution issues. A workstation might resolve OLDSERVER to an IP that no longer exists, or worse, to an IP that's been reassigned to a different device. In dental environments, this can manifest as intermittent PMS connection failures that are difficult to diagnose.

6.3 Current State

DNS scavenging is not universally configured across DTC client environments. When troubleshooting stale DNS record issues, check whether scavenging is enabled and consider configuring it.

6.4 How to Check

# Check scavenging status
Get-DnsServerScavenging

# Expected output if enabled:
# ScavengingState  : True
# ScavengingInterval : 7.00:00:00 (7 days)
# LastScavengeTime : [timestamp]

6.5 How to Enable

Prerequisites:

Scavenging must be enabled in TWO places: on the DNS server AND on each zone
Only enable on the DC that is the primary DNS server for the site

Step 1 — Enable on the DNS Server:

Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

Step 2 — Enable on the Zone:

Set-DnsServerZoneAging -Name "ad.company.com" -Aging $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

What the intervals mean:

No-Refresh Interval (default 7 days) — After a record is registered/refreshed, the DNS server ignores refresh attempts for this period. Prevents unnecessary replication traffic.
Refresh Interval (default 7 days) — After the no-refresh interval, the record can be refreshed. If it ISN't refreshed within this window, it becomes eligible for scavenging.
Scavenging Interval (default 7 days) — How often the server runs the scavenging process to delete eligible stale records.

In practice: A record that stops being refreshed will be cleaned up after approximately 14-21 days (no-refresh + refresh + next scavenging cycle).

6.6 Caution

Static records are immune — Records with timestamps of 0 (static) are never scavenged. Manually created A records for servers with static IPs should be set as static.
Don't enable on all zones blindly — Only enable on the forward lookup zone for the AD domain. Do not enable on _msdcs or reverse lookup zones without understanding the implications.
Test first — After enabling, monitor for 2-3 weeks before assuming it's working correctly. Check the DNS Server event log for scavenging activity.

6.7 Tier Responsibilities

Tier	Scope
T1	Does not configure scavenging. Can run `Get-DnsServerScavenging` to check status during troubleshooting.
T2	Can enable scavenging on single-DC environments using the procedure above.
T3	Handles multi-DC scavenging design, troubleshooting scavenging that deletes records it shouldn't, and scavenging in complex AD topologies.

7. DNSFilter Is a Separate Concern

This section exists to prevent a common source of confusion.

Internal DNS zone management (this document) and DNSFilter (external DNS filtering) are completely separate systems that serve different purposes at different layers.

	Internal DNS (DC)	DNSFilter (External)
What it does	Resolves AD hostnames, SRV records, internal names	Filters external DNS queries for malware, content policy
Where it runs	Windows DNS Server on the Domain Controller	DNSFilter cloud service (103.247.36.36/37)
Who configures it	T2/T3 techs on the DC	T2 techs in the DNSFilter portal + UDM WAN settings
What it affects	AD authentication, GPO, dental software server connections	Web browsing, cloud service access, threat protection
Managed via	DNS Manager / PowerShell on the DC	DNSFilter portal (app.dnsfilter.com) + Dynu DNS for IP verification

The UDM connects them but they don't interact directly:

UDM Forward Domain rule → sends AD queries to the DC
UDM upstream DNS → sends external queries to DNSFilter

If DNSFilter goes down, internal AD resolution is unaffected (the DC still answers AD queries). If the DC goes down, external DNS still works (DNSFilter still resolves public names). They are independent failure domains.

When techs get confused:

"DNS is broken" → First determine: is it internal names (DC issue) or external names (DNSFilter/upstream issue)?
"DNSFilter is blocking something" → This is never an internal DNS zone issue. Check the DNSFilter portal.
"Server hostname doesn't resolve" → This is never a DNSFilter issue. Check the DC's forward lookup zone and the UDM's Forward Domain rule.

8. Troubleshooting Quick Reference

Symptom	Likely Cause	Check
` nslookup server.ad.company.com ` fails	Forward Domain rule missing on UDM, or DC DNS service down	Verify Forward Domain rule exists. Check `Get-Service DNS` on DC.
SRV records missing ( `\_ldap.\_tcp` )	DC DNS zone corrupted, or netlogon service not running	` net stop netlogon && net start netlogon ` on DC. Run `<span class="editor-theme-code"><span class="editor-theme-code">dcdiag /test:dns</span></span>` .
Stale A record returns wrong IP	DNS scavenging not enabled, or record was manually created as static	Delete stale record manually. Consider enabling scavenging.
Internal names resolve but external don't	UDM upstream DNS (DNSFilter) unreachable, or Dynu DNS IP mismatch	Check UDM WAN DNS settings. Verify Dynu A record matches current public IP.
Workstation queries DC directly (not UDM)	Endpoint DNS not set to UDM gateway	` ipconfig /all ` → DNS should show UDM gateway IP only. Fix DHCP or static config.
Conditional forwarder not working	Forwarder configured on DC but no matching Forward Domain rule on UDM	Add Forward Domain rule on UDM for the same domain.
AD trust authentication failing	Missing conditional forwarder for the trusted domain	Add conditional forwarder on DC AND Forward Domain rule on UDM for the trusted domain.

9. Escalation Guidelines

Tier Handles Escalate When

**T1**

Tier	Handles	Escalate When
T1	Verify endpoint DNS points to UDM ( `ipconfig /all` ), run `<span class="editor-theme-code"><span class="editor-theme-code">nslookup</span></span>` tests, check DNS service status, flush DNS cache	DC DNS service issues, zone problems, any forwarder configuration
T2	Enable/configure DNS scavenging, add/remove conditional forwarders, verify/create Forward Domain rules on UDM, clean up stale DNS records	Multi-DC environments, AD trust DNS design, zone corruption
T3	Multi-domain DNS architecture, trust relationship design, complex conditional forwarder chains, DNS zone rebuilds, AD domain rename DNS implications	N/A — T3 is top tier

Verify endpoint DNS points to UDM ( `ipconfig /all` ), run

nslookup

tests, check DNS service status, flush DNS cache

DC DNS service issues, zone problems, any forwarder configuration

**T2** Enable/configure DNS scavenging, add/remove conditional forwarders, verify/create Forward Domain rules on UDM, clean up stale DNS records Multi-DC environments, AD trust DNS design, zone corruption

**T3** Multi-domain DNS architecture, trust relationship design, complex conditional forwarder chains, DNS zone rebuilds, AD domain rename DNS implications N/A — T3 is top tier

10. Document Control

Version	Date	Author	Changes
1.0	March 2026	IT Support Engineering	Initial release. Internal DNS zone management, conditional forwarders, split DNS, DNS scavenging, DNSFilter separation.

Confidential — Internal Use Only

Network Architecture

DHCP & DNS

Remote Access

VoIP Operations

VoIP Troubleshooting & Network Diagnostic SOP

Internal DNS Zone Management

Firewall Rules & Port Requirements Master Reference

Windows Workstations MSA Standard Configuration

Windows In-Place Upgrade

Backup & Data Protection Standards

SaaS Backup Standards

Cloud Backup Architecture Standards

Workload-Instance Bucket Architecture

Client Credential Administration Standard

Operational UUID (OUID) Standard

Build for Unreliable Integrations

Writes Are Jobs, Reads Are Cached

Everything Has a Timestamp and a Deadline

Webhook-Driven, Reconciler-Bounded

Explicit Handling of Absent Data

Branding in the Environment, Not the Code

Versioned, Signed, and Tagged

Closed Records Are Immutable Until Proven Otherwise

Observability Is a First-Class Citizen

Every Integration Has a Resume Endpoint

Internal DNS Zone Management

1. Purpose

2. How DNS Resolution Works (DTC Standard)

3. Internal DNS Zones on the Domain Controller

3.1 What Lives on the DC

3.2 What Does NOT Live on the DC

3.3 Quick Health Check (Run on DC)

4. Conditional Forwarders

4.1 What They Are

4.2 When to Use Conditional Forwarders on the DC

4.3 How to Configure (on the DC)

4.4 Tier Responsibilities

5. Split DNS Behavior

5.1 What "Split DNS" Means at DTC

5.2 When Split DNS Causes Problems

5.3 Verification

6. DNS Scavenging

6.1 What It Is

6.2 Why It Matters

6.3 Current State

6.4 How to Check

6.5 How to Enable

6.6 Caution

6.7 Tier Responsibilities

7. DNSFilter Is a Separate Concern

8. Troubleshooting Quick Reference

9. Escalation Guidelines

10. Document Control