DNS Server: Edit Name Server Record, Resolve button

Occasional Contributor


I am configuring a DNS Server on Windows Server 2022 Datacenter (in a test lab environment) and I want to change (resolve) the "Unknown" status with the right IP address.
Is there a PowerShell command (including .NET API) or CMD commands to use in order to accomplish what the "Resolve" button does?

Thank you.

4 Replies



Hi, Martinik.


Based on your screenshots and question, there's a couple of points that need to be made here.


  1. You don't want to touch the _msdcs zone at all, ever. Don't directly change any zone settings for it or add/remove/modify any records within it - there's other control mechanisms outside DNS that handle this, and if there's issues such as missing records, the root causes will be outside of DNS. All you'll see through looking at the zone itself are the symptoms (such as missing or stale records.)
  2. If you're seeing a value of "Unknown", you need to check that the A and PTR records exist for the domain controller in question. You'd look for the A record under your "zero.local" forward lookup zone and the PTR record under the appropriate reverse lookup zone.


A common oversight from many administrators is that they do not create the reverse lookup zone meaning PTR records fail to register.


You also want to check the network interface on the domain controller and verify that it is pointing to itself for DNS.


For example, if I have a network interface on the domain controller named "Ethernet" with an IPv4 address of, then I want to ensure that the primary DNS server on that interface is also set to


Similarly, within the DNS management console, if you go to Server -> Properties, you want to ensure that under the "Listeners" tab, all the IP addresses are registered to listen on (unless there's a compelling reason for some to remain unregistered.)


Here's some example screenshots to help with the above descriptions.


How a zone's properties should look when A and PTR records have successfully automatically registered



Successful automatic registration of the domain controller's A (and AAAA) records in the forward zone



Successful automatic registration of the domain controller's PTR records in the reverse zones (IPv4 example only)



DNS Server configured to listen on all addresses




The DNS client addresses used on the domain controller (i.e. pointing to itself first, plus one other in my case)




If the necessary forward and reverse zones exist, and your domain controller is able to properly register its own A and PTR records within those zones, you should not be seeing "Unknown" in your first screenshot. The "resolve" button isn't the answer to root cause of this issue.






Hi, Lain. Thank you for your detailed answer. Nice post :)


_msdcs, known as "Microsoft Domain Controller Service" contains srv records and is used for locating domain controller for their services. It contains generic srv records, ldap records, etc. If it's not configured properly, unexpected things will appear; you know what I mean. :)

To replicate my case, use the following in a clean install OS: Windows Server 2022 Datacenter.

#- LAN1: custom (VMnet11):
- no DHCP
#- Edit VM and change the Network adapter from Host-only to Custom VMnet 11
#- Start VM, go to "Control Panel\Network and Internet\Network Connections" and rename the network adapter: LAN1

Write-Host "Rename the server and restart it"
Rename-Computer -NewName 'DC1' -Force -PassThru -Restart

################################# After the command execution, the server will be restarted

Write-Host "Configure the IP address for LAN1"
New-NetIPAddress -InterfaceAlias "LAN1" -AddressFamily IPv4 -IPAddress -PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "LAN1" -ServerAddresses

Write-Host "Install Active Directory Domain Services role"
Add-WindowsFeature AD-Domain-Services -IncludeAllSubFeature -IncludeManagementTools

Write-Host "Promote server to Domain Controller with default config (the server will be restarted). The password for Directory Services Restore Mode (DSRM): Password1"
Import-Module ADDSDeployment; Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "WinThreshold" -DomainName "zero.local" -DomainNetbiosName "ZERO" -ForestMode "WinThreshold" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$false -SysvolPath "C:\Windows\SYSVOL" -Force:$true -SafeModeAdministratorPassword (ConvertTo-SecureString -AsPlainText "Password1" -Force)

################################# After the command execution, the server will be restarted

Write-Host "Reconfigure both IPv4 and IPv6 addresses. The "ResetServerAddresses" will reset DNS section for both IPv4 and IPv6 types."
Get-DnsClientServerAddress -InterfaceAlias "LAN1" -AddressFamily IPv6 | Set-DnsClientServerAddress -ResetServerAddresses
Set-DnsClientServerAddress -InterfaceAlias "LAN1" -ServerAddresses


Before continue with the manual steps, check the DNS Server settings to view the "Unknown" status, as in my initial post.


#- Manual Procedure: Open DNS console and make these settings (first interaction with DNS console)
- Step 1:
- Open DNS console and r-click\Properties on DC1\Forward Lookup Zones\_msdcs.zero.local
- go to Name Servers tab
- press Edit button
- press Resolve button and make sure the IP address has a green icon



- Step 2:
- create a new Reverse Lookup Zones:
Add-DnsServerPrimaryZone -ComputerName "" -NetworkId "" -ReplicationScope Forest -DynamicUpdate Secure -PassThru

- Step 3:
- r-click\Properties on our zone DC1\Reverse Lookup Zones\0.168.192.in-addr.arpa
- go to Name Servers tab
- press Edit button
- press Resolve button and make sure the IP address has a green icon


- Step 4:
- r-click\Properties on DC1\Forward Lookup Zones\zero.local\dc1 Host(A) record
- check the "Update associated pointer (PTR) record"


- Step 5:
- add new records in the "DC1\Forward Lookup Zones\zero.local" zone for the most important servers; they will be static records:
Add-DnsServerResourceRecord -ZoneName "zero.local" -ComputerName "" -A -Name "SRV1" -IPv4Address "" -CreatePtr -Verbose
Add-DnsServerResourceRecord -ZoneName "zero.local" -ComputerName "" -A -Name "SRV2" -IPv4Address "" -CreatePtr -Verbose
Add-DnsServerResourceRecord -ZoneName "zero.local" -ComputerName "" -A -Name "SRV3" -IPv4Address "" -CreatePtr -Verbose
Add-DnsServerResourceRecord -ZoneName "zero.local" -ComputerName "" -A -Name "SRV4" -IPv4Address "" -CreatePtr -Verbose




I still have the initial question. :)





With respect to your flow, under the "manual steps" section:


  1. Get rid of Steps 1, 3 and 4 as these are not necessary;
  2. After your Step 2 (which is now the first step), run the following commands:

The DNS records within the _msdcs zone are managed dynamically by the NETLOGON service which is why you should not be making manual changes there. If that is not occurring then there is an underlying problem that needs resolving - manual manipulation is never the right way to fix DNS records in this zone.


You can control which record are registered via mechanics such as group policy (preferred option), registry entries and old-school DOS commands (both being less preferable options.)


Skipping to the forward and reverse zones (both of which support dynamic and require secure updates), a domain controller will manage its own A and PTR record registrations via the DNS Client service. There is precisely zero reason to manually check the "update PTR option". Even statically-assigned IP addresses automatically re-register every 24 hours.


The Resolve button doesn't achieve anything from a configuration perspective.


If the green tick icon isn't displaying then it's because reverse name resolution hasn't been completed, or the temporary scenario during setup where you still have a failed reverse lookup cached in the DNS client.


A quick way of cross-checking this is with a basic nslookup command such as:


nslookup microsoft.com.


At the top of the output, if you get "server: unknown" (example below) then you definitely still have a configuration issue. While there's a number of possible causes, the most likely for the workflow from below is that there's nothing saying to the server "re-register your DNS records" after the reverse lookup zone has been created - all those commands have already been done before the zone is created making it impossible for the server to have registered its PTR.



Once the server has automatically registered its PTR, and perhaps allowing a couple of minutes for any negative cached lookups to have expired (you can manually flush them if you want to), you'll find within the zone properties that the IP addresses are listed instead of "Unknown", which is the default experience when everything is configured correctly (i.e. the Resolve button isn't necessary.)


As a case in point, here's a screenshot of the DNS MMC automatically resolving my external ISP forwarders (the first one is done, the second in progress, which is what I wanted to show). I don't need to click Resolve at all.







Edited to relocate an image.

If you will create a new Domain Controller (no internet access) based on my scripts, you will see why the manual steps are needed. Take a closer look.

My manual steps are not changing settings, they are only resolving names that are already in place.

The command you mentioned, "Register-DnsClient" will create a dynamic PTR, which is not right if my A record is static and I want it to remain static. The "Update associated pointer (PTR) record" is a better option because you only have to set it once and it will be configured for all A records.
Waiting for 24 hours to re-register a PTR is not an option and in the end, all PTRs will be dynamic even if I have static A records. (By default, Windows registers A and PTR resource records every 24 hours regardless of the computer's role. To change this time, add the DefaultRegistrationRefreshInterval (the interval is set in seconds) registry entry under the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters)

My initial question is still open. :)