DNS (Domain Name System) is the backbone of name resolution in Windows networks. The DNS Server role in Windows Server translates hostnames to IP addresses and back, enabling clients to locate domain controllers, mail servers, web servers, and other network resources. In Active Directory environments, DNS is mandatory – AD relies entirely on DNS SRV records for service discovery and domain controller location.
This guide walks through installing and configuring the DNS Server role on Windows Server 2025 and 2022. We cover forward and reverse lookup zones, common record types (A, CNAME, MX, PTR), forwarders, conditional forwarders, DNSSEC basics, and client configuration. Both Server Manager (GUI) and PowerShell methods are included. For the official reference, see the Microsoft DNS Server documentation.
Prerequisites
Before you begin, make sure the following are in place:
- A server running Windows Server 2025 or Windows Server 2022 (Desktop Experience or Server Core)
- A static IP address configured on the server – DNS servers must not use DHCP
- Administrator access to the server
- If integrating with Active Directory: Active Directory Domain Services installed and configured
- TCP/UDP port 53 open in Windows Firewall (the DNS role opens this automatically)
Step 1: Install the DNS Server Role
You can install the DNS Server role through Server Manager or PowerShell. Both methods achieve the same result.
Method 1: Install DNS via Server Manager
Open Server Manager and follow these steps:
- Click Manage in the top right, then select Add Roles and Features
- Click Next past the “Before You Begin” page
- Select Role-based or feature-based installation, click Next
- Select the local server from the server pool, click Next
- Check the box for DNS Server. When prompted to add required features, click Add Features
- Click Next through Features and DNS Server pages
- Click Install and wait for the installation to complete
No reboot is required after installing the DNS Server role.
Method 2: Install DNS via PowerShell
Open an elevated PowerShell prompt and run the following command to install the DNS Server role along with its management tools:
Install-WindowsFeature -Name DNS -IncludeManagementToolsThe output confirms a successful installation with Success showing True and Restart Needed showing No:
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {DNS Server, DNS Server Tools}Verify the DNS Server service is running:
Get-Service -Name DNSThe output should show the DNS service with a status of Running:
Status Name DisplayName
------ ---- -----------
Running DNS DNS ServerStep 2: Configure a Forward Lookup Zone
A forward lookup zone resolves hostnames to IP addresses. This is the most common DNS query type – when a client asks “what is the IP of server1.example.com?”, the forward lookup zone provides the answer.
Create Forward Lookup Zone via DNS Manager
Open DNS Manager from Server Manager (Tools > DNS) and follow these steps:
- Right-click Forward Lookup Zones and select New Zone
- Click Next on the wizard welcome page
- Select Primary zone. If the server is a domain controller, check Store the zone in Active Directory for AD-integrated DNS
- For AD-integrated zones, choose the replication scope (To all DNS servers running on domain controllers in this domain is the typical choice)
- Enter the zone name – for example,
example.com - For non-AD zones, accept the default zone file name (
example.com.dns) - Select whether to allow dynamic updates. For AD-integrated zones, choose Allow only secure dynamic updates
- Click Finish to create the zone
Create Forward Lookup Zone via PowerShell
To create an AD-integrated primary zone with PowerShell, run:
Add-DnsServerPrimaryZone -Name "example.com" -ReplicationScope "Domain" -DynamicUpdate "Secure"For a standalone (file-backed) primary zone without Active Directory integration:
Add-DnsServerPrimaryZone -Name "example.com" -ZoneFile "example.com.dns" -DynamicUpdate "None"Verify the zone was created by listing all forward lookup zones:
Get-DnsServerZone | Where-Object {$_.IsReverseLookupZone -eq $false}Your new zone should appear in the output alongside the default zones:
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
example.com Primary False True False False
TrustAnchors Primary False True False FalseStep 3: Configure a Reverse Lookup Zone
A reverse lookup zone maps IP addresses back to hostnames. This is used by applications that need to verify the identity of a connecting client through reverse DNS (PTR) queries. Many mail servers require valid reverse DNS for incoming connections.
Create Reverse Lookup Zone via DNS Manager
In DNS Manager, right-click Reverse Lookup Zones and select New Zone:
- Select Primary zone and optionally check Store the zone in Active Directory
- Choose IPv4 Reverse Lookup Zone
- Enter the Network ID – for example,
10.0.1for the 10.0.1.0/24 subnet - Configure dynamic updates (Secure for AD-integrated zones)
- Click Finish
Create Reverse Lookup Zone via PowerShell
Create an AD-integrated reverse lookup zone for the 10.0.1.0/24 network:
Add-DnsServerPrimaryZone -NetworkID "10.0.1.0/24" -ReplicationScope "Domain" -DynamicUpdate "Secure"For a standalone file-backed reverse zone:
Add-DnsServerPrimaryZone -NetworkID "10.0.1.0/24" -ZoneFile "1.0.10.in-addr.arpa.dns" -DynamicUpdate "None"Verify the reverse zone exists:
Get-DnsServerZone | Where-Object {$_.IsReverseLookupZone -eq $true}The output lists the reverse lookup zone along with its type and status:
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
1.0.10.in-addr.arpa Primary False True True False
0.in-addr.arpa Primary False False True False
127.in-addr.arpa Primary False False True False
255.in-addr.arpa Primary False False True FalseStep 4: Add DNS Records (A, CNAME, MX, PTR)
With the zones created, you can now add the DNS records that clients will query. Below are the most common record types you will work with in a production environment.
Add an A Record (Host Record)
An A record maps a hostname to an IPv4 address. To create an A record for server1.example.com pointing to 10.0.1.10:
Add-DnsServerResourceRecordA -ZoneName "example.com" -Name "server1" -IPv4Address "10.0.1.10" -CreatePtrThe -CreatePtr flag automatically creates a corresponding PTR record in the reverse lookup zone. This saves you from creating the PTR record separately.
Add a CNAME Record (Alias)
A CNAME record creates an alias that points to another hostname. This is useful for giving friendly names to services – for example, pointing www.example.com to server1.example.com:
Add-DnsServerResourceRecordCName -ZoneName "example.com" -Name "www" -HostNameAlias "server1.example.com"Add an MX Record (Mail Exchange)
An MX record directs email for the domain to the specified mail server. The preference value determines priority when multiple mail servers exist – lower numbers have higher priority:
Add-DnsServerResourceRecordMX -ZoneName "example.com" -Name "." -MailExchange "mail.example.com" -Preference 10The -Name "." means the MX record applies to the zone root (example.com itself, not a subdomain).
Add a PTR Record (Reverse Lookup)
PTR records map an IP address back to a hostname. If you did not use the -CreatePtr flag when creating an A record, add the PTR manually:
Add-DnsServerResourceRecordPtr -ZoneName "1.0.10.in-addr.arpa" -Name "10" -PtrDomainName "server1.example.com"In this example, -Name "10" represents the last octet of IP 10.0.1.10.
Verify DNS Records
List all records in the forward lookup zone to confirm they were created:
Get-DnsServerResourceRecord -ZoneName "example.com"The output displays all records in the zone including SOA, NS, A, CNAME, and MX records:
HostName RecordType Type Timestamp TimeToLive RecordData
-------- ---------- ---- --------- ---------- ----------
@ SOA 6 0 01:00:00 [1][dc1.example.com.][hostmaster.example...]
@ NS 2 0 01:00:00 dc1.example.com.
@ MX 15 0 01:00:00 [10][mail.example.com.]
server1 A 1 0 01:00:00 10.0.1.10
www CNAME 5 0 01:00:00 server1.example.com.Step 5: Configure DNS Forwarders
DNS forwarders tell your DNS server where to send queries it cannot resolve from its own zones. Without forwarders, the server uses root hints to walk the DNS hierarchy from the root servers down – which works but is slower. Forwarders send unresolved queries directly to a known DNS resolver like Google DNS or Cloudflare DNS.
Configure Forwarders via DNS Manager
In DNS Manager, right-click the server name and select Properties:
- Go to the Forwarders tab
- Click Edit
- Add the IP addresses of your upstream DNS resolvers (for example,
8.8.8.8and1.1.1.1) - Click OK, then Apply
Configure Forwarders via PowerShell
Add Google DNS and Cloudflare DNS as forwarders:
Set-DnsServerForwarder -IPAddress "8.8.8.8","1.1.1.1" -UseRootHint $trueThe -UseRootHint $true parameter tells the server to fall back to root hints if the forwarders are unreachable. Verify the configuration:
Get-DnsServerForwarderThe output confirms the configured forwarder addresses and timeout settings:
UseRootHint : True
Timeout(s) : 3
EnableReordering : True
IPAddress : {8.8.8.8, 1.1.1.1}
ReorderedIPAddress : {8.8.8.8, 1.1.1.1}Step 6: Configure Conditional Forwarders
Conditional forwarders route DNS queries for a specific domain to a designated DNS server. This is essential in multi-domain environments where you need your DNS server to resolve names in a partner or child domain without configuring a full zone transfer. For example, if your network needs to resolve names in partner.local, you forward those queries directly to the partner’s DNS server.
Add Conditional Forwarder via DNS Manager
In DNS Manager, expand the server node:
- Right-click Conditional Forwarders and select New Conditional Forwarder
- Enter the DNS domain name – for example,
partner.local - Add the IP addresses of the DNS servers for that domain (for example,
10.0.2.10) - Optionally check Store this conditional forwarder in Active Directory to replicate it to other DCs
- Click OK
Add Conditional Forwarder via PowerShell
Create a conditional forwarder for partner.local that sends queries to 10.0.2.10 and stores the configuration in Active Directory:
Add-DnsServerConditionalForwarderZone -Name "partner.local" -MasterServers "10.0.2.10" -ReplicationScope "Domain"For standalone servers without AD integration, omit the -ReplicationScope parameter:
Add-DnsServerConditionalForwarderZone -Name "partner.local" -MasterServers "10.0.2.10"Verify the conditional forwarder was created:
Get-DnsServerZone | Where-Object {$_.ZoneType -eq "Forwarder"}The output shows the conditional forwarder zone:
ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned
-------- -------- ------------- -------------- ------------------- --------
partner.local Forwarder False True False FalseStep 7: DNS Security with DNSSEC
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records, protecting against cache poisoning and man-in-the-middle attacks. When DNSSEC is enabled, DNS responses are digitally signed, and clients can verify the authenticity of the records they receive.
Sign a Zone with DNSSEC via DNS Manager
In DNS Manager, right-click the zone you want to sign:
- Select DNSSEC > Sign the Zone
- Choose Customize zone signing parameters for full control, or use the defaults for a quick setup
- Configure the Key Signing Key (KSK) – the default RSA/SHA-256 with 2048-bit key length is a good choice
- Configure the Zone Signing Key (ZSK) – again, RSA/SHA-256 with 1024 or 2048-bit key length
- Configure NSEC or NSEC3 for authenticated denial of existence. NSEC3 is recommended as it prevents zone enumeration
- Review the settings and click Next to sign the zone
Sign a Zone with DNSSEC via PowerShell
Sign the zone using PowerShell with the Invoke-DnsServerZoneSign cmdlet. First, add the signing keys, then sign:
Invoke-DnsServerZoneSign -ZoneName "example.com" -SignWithDefault -ForceVerify the zone is signed by checking its properties:
Get-DnsServerZone -Name "example.com" | Select-Object ZoneName, IsSignedThe output confirms the zone is now signed:
ZoneName IsSigned
-------- --------
example.com TrueDNSSEC works best when clients are configured to validate signatures. In an AD environment, configure the Windows Firewall to allow DNS traffic and deploy NRPT (Name Resolution Policy Table) rules via Group Policy to enforce DNSSEC validation on client machines.
Step 8: Configure Clients to Use the DNS Server
After setting up the DNS server, client machines need to be pointed to it for name resolution. In a DHCP environment, update the DHCP scope options to distribute the new DNS server address. For static configurations, set the DNS server on each client.
Set DNS Server on Windows Clients via PowerShell
On the client machine, identify the network adapter name first:
Get-NetAdapter | Select-Object Name, Status, InterfaceIndexThen set the DNS server address. Replace Ethernet0 with your adapter name and 10.0.1.5 with your DNS server IP:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses ("10.0.1.5","8.8.8.8")The first address (10.0.1.5) is the primary DNS server – your new Windows DNS server. The second (8.8.8.8) acts as a fallback if the primary is unreachable.
Set DNS Server via DHCP Scope Options
If you run DHCP on Windows Server, update the scope options to distribute the DNS server address automatically to all DHCP clients:
Set-DhcpServerv4OptionValue -ScopeId "10.0.1.0" -DnsServer "10.0.1.5" -DnsDomain "example.com"Clients will receive the new DNS server address at their next DHCP lease renewal.
Step 9: Verify DNS Resolution
Testing DNS resolution confirms that your server is responding to queries correctly. Windows provides two tools for this – the classic nslookup and the modern Resolve-DnsName PowerShell cmdlet. For the complete PowerShell DNS cmdlet reference, see the DnsServer module documentation.
Test with nslookup
Query your DNS server for the A record you created earlier. Replace 10.0.1.5 with your DNS server IP:
nslookup server1.example.com 10.0.1.5A successful response shows the server that answered and the resolved IP address:
Server: dc1.example.com
Address: 10.0.1.5
Name: server1.example.com
Address: 10.0.1.10Test reverse DNS lookup for the PTR record:
nslookup 10.0.1.10 10.0.1.5The reverse lookup returns the hostname associated with that IP:
Server: dc1.example.com
Address: 10.0.1.5
Name: server1.example.com
Address: 10.0.1.10Test with Resolve-DnsName
The Resolve-DnsName cmdlet provides more detailed output and supports querying specific record types:
Resolve-DnsName -Name "server1.example.com" -Server "10.0.1.5" -Type AThe output includes the record type, TTL, and IP address:
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
server1.example.com A 3600 Answer 10.0.1.10Query the MX record to verify mail routing configuration:
Resolve-DnsName -Name "example.com" -Server "10.0.1.5" -Type MXThe output shows the mail exchange server and its preference value:
Name Type TTL Section NameExchange Preference
---- ---- --- ------- ------------ ----------
example.com MX 3600 Answer mail.example.com 10Query the CNAME record to verify the alias resolves correctly:
Resolve-DnsName -Name "www.example.com" -Server "10.0.1.5" -Type CNAMEThe output shows the alias pointing to the canonical name:
Name Type TTL Section NameHost
---- ---- --- ------- --------
www.example.com CNAME 3600 Answer server1.example.comDNS Record Types Reference
The following table summarizes the most common DNS record types and their purpose in a Windows Server DNS environment:
| Record Type | Purpose | Example |
|---|---|---|
| A | Maps a hostname to an IPv4 address | server1.example.com -> 10.0.1.10 |
| AAAA | Maps a hostname to an IPv6 address | server1.example.com -> fd00::10 |
| CNAME | Creates an alias pointing to another hostname | www.example.com -> server1.example.com |
| MX | Directs email to a mail server with priority | example.com -> mail.example.com (priority 10) |
| PTR | Maps an IP address to a hostname (reverse DNS) | 10.0.1.10 -> server1.example.com |
| NS | Identifies authoritative name servers for a zone | example.com -> dc1.example.com |
| SOA | Start of Authority – zone metadata (serial, refresh, retry) | Primary server, admin email, timers |
| SRV | Locates services (critical for Active Directory) | _ldap._tcp.example.com -> dc1.example.com:389 |
| TXT | Stores text data (SPF records, domain verification) | example.com -> “v=spf1 mx -all” |
SRV records are particularly important in Active Directory environments. AD clients use SRV records to locate domain controllers, Global Catalog servers, Kerberos KDCs, and LDAP services. These records are created automatically when a server is promoted to a domain controller with the Active Directory Domain Services role.
Conclusion
You now have a fully functional DNS Server on Windows Server 2025/2022 with forward and reverse lookup zones, A/CNAME/MX/PTR records, forwarders, conditional forwarders, and DNSSEC signing. DNS is the foundation of every Windows network – a misconfigured DNS server will break Active Directory authentication, email routing, and client connectivity.
For production environments, run DNS on at least two domain controllers for redundancy, enable DNS logging for troubleshooting (Set-DnsServerDiagnostics -All $true), and monitor DNS query performance with Windows Performance Monitor. Keep your zones clean by enabling scavenging to remove stale dynamic records automatically.
