DNS and DHCP for Enterprise Networks — Production Configuration and Troubleshooting

DNS and DHCP are the two services every device on your network depends on before it can do anything else. A workstation that can’t get an IP address can’t register with Teams. An IP phone that can’t resolve a DNS name can’t reach the call manager. A Webex endpoint that gets the wrong DNS server hands back failures at the signaling layer before a single SIP packet leaves the building.

These services are foundational and they fail quietly. No alarm fires when a DHCP scope exhausts. No alert triggers when a DNS forwarder stops responding. The first sign something is wrong is usually a call that won’t connect or a user who can’t sign in — and by then the troubleshooting clock is already running.

This article covers production DNS and DHCP configuration for enterprise environments — Windows Server AD-integrated DNS, Windows Server and Cisco IOS Layer 3 switch DHCP — and the troubleshooting approach for when things go wrong.

DNS — How It Affects UCaaS

Before getting into configuration, it’s worth being explicit about why DNS matters for Teams and Webex specifically.

Every cloud UCaaS platform depends on DNS resolution to connect endpoints to infrastructure. When a Teams client starts up, it resolves a series of Microsoft hostnames to find its signaling and media endpoints. When a Webex phone powers on, it resolves Cisco cloud addresses to register. When a user makes a call, the platform resolves additional addresses in the call path.

If DNS fails at any point in that chain — wrong server, failed forwarder, blocked query, expired TTL — the call fails. Not with an obvious error message that says “DNS failed.” With a generic connection error, a timeout, or a call that simply never connects.

Three DNS failure modes that show up repeatedly in UCaaS deployments:

Internal DNS servers that can’t resolve external names. AD-integrated DNS zones handle internal name resolution correctly but rely on forwarders to resolve external hostnames. If the forwarders are misconfigured, unreachable, or pointing to an internal server that also can’t reach the internet, Teams and Webex resolution fails silently.

Overly restrictive DNS policies. Security-hardened environments sometimes implement DNS filtering or response policy zones (RPZ) that block resolution for certain domain patterns. Microsoft 365 and Webex domains occasionally get caught in these filters. The result looks identical to a network failure — resolution times out, calls don’t connect.

Split DNS misconfiguration. Environments with split DNS — different responses for internal vs external queries — can return incorrect results for Microsoft 365 or Webex domains if the internal zone is configured incorrectly or the records are stale.

Windows Server AD-Integrated DNS — Production Configuration

AD-integrated DNS stores zone data in Active Directory rather than flat zone files. Every domain controller that runs DNS is an authoritative source for the zone, replication happens through AD replication channels, and changes made on any DC propagate automatically. This is the correct architecture for enterprise environments — it eliminates single points of failure and removes manual zone file management.

DNS Forwarder Configuration

Forwarders are what your internal DNS servers use to resolve names outside your AD zone. Every internal DNS server needs forwarders configured and tested.

In DNS Manager, navigate to the server properties and select the Forwarders tab. Add your forwarder addresses in order of preference.

For most environments, use your ISP’s DNS servers or public resolvers as forwarders. Google (8.8.8.8, 8.8.4.4) and Cloudflare (1.1.1.1, 1.0.0.1) are reliable options. If your environment uses a security-focused DNS resolver (Cisco Umbrella, Cloudflare Gateway), those go here.

Via PowerShell:

# Set DNS forwarders on the local DNS server
Set-DnsServerForwarder -IPAddress "8.8.8.8","8.8.4.4" -PassThru

# Verify forwarder configuration
Get-DnsServerForwarder

Conditional Forwarders

If your environment has multiple AD domains or needs to resolve specific external zones through a particular DNS server — common in environments with split DNS or partner network integration — conditional forwarders handle this cleanly.

# Add a conditional forwarder for a specific domain
Add-DnsServerConditionalForwarderZone -Name "partnerdomain.com" `
  -MasterServers "192.168.100.10" -PassThru

Verifying Microsoft 365 and Webex Resolution

After configuring forwarders, verify that your internal DNS servers can resolve the domains Teams and Webex depend on. Run these from a domain-joined machine using your internal DNS:

# Test Teams resolution
Resolve-DnsName teams.microsoft.com
Resolve-DnsName login.microsoftonline.com
Resolve-DnsName outlook.office365.com

# Test Webex resolution
Resolve-DnsName webex.com
Resolve-DnsName wbx2.com
Resolve-DnsName ciscospark.com

Every query should return IP addresses. A timeout or NXDOMAIN response means your forwarder chain is broken somewhere.

DNS Scavenging

Stale DNS records accumulate in AD-integrated zones over time — decommissioned machines, renamed devices, IP address changes that weren’t cleaned up. In environments where DHCP registers DNS records dynamically, stale records compound quickly. Enable scavenging to clean them up automatically.

# Enable scavenging on the DNS server
Set-DnsServerScavenging -ScavengingState $true `
  -ScavengingInterval 7.00:00:00 -PassThru

# Enable aging on a specific zone
Set-DnsServerZoneAging -Name "yourdomain.local" `
  -Aging $true -NoRefreshInterval 7.00:00:00 `
  -RefreshInterval 7.00:00:00 -PassThru

Standard practice: no-refresh interval of 7 days, refresh interval of 7 days. Records older than 14 days without a refresh get scavenged. Adjust based on your environment’s DHCP lease times.

DHCP — Windows Server vs Layer 3 Switch

DHCP can live in two places in a production enterprise environment: Windows Server or a Layer 3 core switch. Both are valid. The choice depends on what you already have and what you’re comfortable managing.

Windows Server DHCP — centralized, GUI-managed, integrates with AD and DNS for dynamic record registration, easy to audit and report on. The right choice when you have a Windows Server infrastructure and want DHCP management alongside your other server tools.

Layer 3 Switch DHCP — distributed, lives on the device closest to the endpoints, eliminates the need for DHCP relay in some topologies. The right choice when you want to reduce server dependency for a function that the network infrastructure can handle natively.

Windows Server DHCP — Production Configuration

Scope Design

Each VLAN needs its own DHCP scope. Scope boundaries should match your subnet boundaries exactly — a scope for 10.10.20.0/24 should have a range that stays within that subnet and excludes any statically assigned addresses.

# Create voice VLAN scope
Add-DhcpServerv4Scope -Name "Voice - VLAN 20" `
  -StartRange 10.10.20.10 -EndRange 10.10.20.254 `
  -SubnetMask 255.255.255.0 -State Active

# Set scope options
Set-DhcpServerv4OptionValue -ScopeId 10.10.20.0 `
  -Router 10.10.20.1 `
  -DnsServer 10.10.40.10 `
  -LeaseTime 1.00:00:00

# Add option 150 for Cisco on-prem call manager
Set-DhcpServerv4OptionValue -ScopeId 10.10.20.0 `
  -OptionId 150 -Value "10.10.40.20"

# Add option 66 for cloud phone provisioning (if applicable)
Set-DhcpServerv4OptionValue -ScopeId 10.10.20.0 `
  -OptionId 66 -Value "tftp.yourdomain.com"

# Create data VLAN scope
Add-DhcpServerv4Scope -Name "Data - VLAN 10" `
  -StartRange 10.10.10.10 -EndRange 10.10.10.254 `
  -SubnetMask 255.255.255.0 -State Active

Set-DhcpServerv4OptionValue -ScopeId 10.10.10.0 `
  -Router 10.10.10.1 `
  -DnsServer 10.10.40.10 `
  -LeaseTime 8.00:00:00

Note the lease time difference — voice scope at 1 day, data scope at 8 days. Voice endpoints move more frequently and shorter leases keep the IP inventory clean. Covered in more detail in VLAN Design for Voice Networks.

DHCP Relay (IP Helper)

When DHCP server and clients are on different subnets — which they always are in a properly segmented environment — DHCP broadcast requests need to be forwarded to the server. This is handled by an IP helper address on the SVI of each VLAN, configured on your Layer 3 switch or router.

interface Vlan20
 description Voice
 ip address 10.10.20.1 255.255.255.0
 ip helper-address 10.10.40.10

The helper address points to your Windows DHCP server on the Servers VLAN. Without this, endpoints on any VLAN other than the one the DHCP server is on will never receive an address.

DHCP Failover

A single DHCP server is a single point of failure. Windows Server DHCP supports failover between two servers — one active, one standby — with automatic synchronization of lease data.

# Configure DHCP failover between two servers
Add-DhcpServerv4Failover -Name "DHCP-Failover" `
  -PartnerServer "dhcp2.yourdomain.local" `
  -ScopeId 10.10.10.0,10.10.20.0,10.10.30.0 `
  -Mode HotStandby -ServerRole Active `
  -SharedSecret "YourSharedSecret" -Force

Hot standby mode keeps the secondary server ready to take over immediately if the primary fails. Split scope mode is an alternative — each server handles 50% of the range — but hot standby is simpler to manage and the right choice for most environments.

Cisco IOS Layer 3 Switch DHCP — Production Configuration

For environments where DHCP lives on the core switch, configuration is straightforward. The switch handles scopes for each VLAN directly without needing a relay — the SVI is the gateway and the DHCP pool serves the same subnet.

ip dhcp excluded-address 10.10.10.1 10.10.10.9
ip dhcp excluded-address 10.10.20.1 10.10.20.9

ip dhcp pool DATA
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 10.10.40.10
 lease 8

ip dhcp pool VOICE
 network 10.10.20.0 255.255.255.0
 default-router 10.10.20.1
 dns-server 10.10.40.10
 option 150 ip 10.10.40.20
 option 66 ascii tftp.yourdomain.com
 lease 1

Excluded addresses cover the gateway IP and any statically assigned devices at the low end of the range. Everything above the exclusion range is available for dynamic assignment.

For environments where a downstream switch is handling DHCP for a remote VLAN, the same ip helper-address configuration on the SVI forwards DHCP requests to the switch acting as server.

Troubleshooting — Common Failure Scenarios

DHCP scope exhaustion. Endpoints stop receiving addresses, or receive APIPA addresses (169.254.x.x). The scope has run out of available leases.

# Check scope utilization on Windows Server
Get-DhcpServerv4ScopeStatistics -ScopeId 10.10.20.0

# On Cisco IOS
show ip dhcp pool VOICE
show ip dhcp binding

If a scope is above 80% utilization, expand the range or reduce lease times to free up addresses faster. An exhausted voice scope means phones stop registering — calls fail at the endpoint level before they reach the network.

DNS forwarder failure. Internal names resolve correctly, external names (Microsoft 365, Webex) time out.

# Test resolution from the DNS server directly
Resolve-DnsName teams.microsoft.com -Server 127.0.0.1

# Check forwarder health
Get-DnsServerForwarder

# Test forwarder reachability
Test-NetConnection -ComputerName 8.8.8.8 -Port 53

If the forwarder is unreachable, DNS falls back to root hints — which works but is slow. If root hints are also blocked by firewall policy, external resolution fails entirely.

DHCP relay not working. Endpoints on a VLAN get APIPA addresses despite DHCP server being up and scope having available leases.

Check the helper address on the SVI first — missing or pointing to the wrong server is the most common cause. Then verify the firewall or ACL between the VLAN and the DHCP server isn’t blocking UDP 67/68. DHCP relay traffic from the switch SVI to the server is a unicast packet on UDP 67 — it needs to pass through any ACL on the path.

Stale DNS records causing connection failures. A device that was decommissioned or renamed still has a DNS record pointing to its old IP address. A new device takes that IP address and gets unexpected traffic, or a hostname resolves to a dead address.

# Find stale records for a specific hostname
Get-DnsServerResourceRecord -ZoneName "yourdomain.local" -Name "oldhost"

# Remove a stale record
Remove-DnsServerResourceRecord -ZoneName "yourdomain.local" `
  -RRType A -Name "oldhost" -Force

Enable scavenging as described above to prevent stale record accumulation long-term.

Small deployments without local DNS infrastructure. Not every environment needs an internal DNS server. A 1–10 person office with no on-premises servers, no Active Directory, and no local resources has no reason to run local DNS. Endpoints point directly to public resolvers — Google (8.8.8.8, 8.8.4.4) or Cloudflare (1.1.1.1) — and resolution for Teams and Webex works fine. This is a completely valid configuration at that scale. Don’t add infrastructure complexity a small deployment doesn’t need. The considerations in this article apply when you have an AD environment, internal resources that need name resolution, or a deployment large enough that public DNS creates a dependency you can’t control.

FortiGate DNS — an inherited configuration note. Some environments use the FortiGate firewall as a DNS server for internal clients. This works at small scale but introduces a dependency on the firewall for a service that should be independent of it — if the firewall is rebooted for a firmware update or fails over during a HA event, DNS goes with it. If you inherit this configuration, it functions but plan to migrate DNS to Windows Server or a dedicated resolver when the opportunity presents itself. Don’t build new deployments on firewall DNS.

What Comes Next

With DNS and DHCP solid, the next article covers one of the most searched topics in VoIP — the one-way audio problem. Troubleshooting One-Way Audio in VoIP — Root Cause and Fix breaks down every common cause of one-way audio across Teams, Webex, and SIP trunk deployments and gives you a systematic approach to finding the root cause fast.

For the VLAN and DHCP scope design that feeds into the configuration in this article, VLAN Design for Voice Networks covers the full segmentation architecture including voice scope design and option configuration.