I noticed DNS registration issues encountered in a Windows Server environment — in this particular scenario, the A Record was successfully being registered, but not the corresponding PTR record.
The PTR (or pointer record) was not being registered in DNS and the PTR record is how you take an IP address and resolve it back to the name of the server, this is known as reverse DNS.
Let’s take a look into why the PTR record was not being published…..
The problem of the missing PTR
My environment had a properly configured forward lookup zone (e.g. bear.local), but the reverse zone (e.g. 32.10.172.in-addr.arpa
) had not yet been created.
As expected, Windows servers registered their A records successfully via dynamic DNS (registerdns
or boot-time registration), but no PTR records were created — because the reverse zone simply didn’t exist at that point.
Later, I created the reverse zone manually on the DNS server.
🛑 Note: When deploying new network ranges — such as adding a new subnet or VLAN — you should create the associated reverse lookup zone at the same time. Failing to do so can result in missing PTR records and inconsistent reverse DNS lookups down the line. Windows won’t retry PTR registration unless explicitly triggered — and even then, it may not behave as expected.
However, the servers didn’t attempt to re-register their PTR records automatically, even though the zone was now in place. Running ipconfig /registerdns
didn't resolve the issue either — A records were already there, and the command doesn't always force a retry of PTR registration under these conditions.
Solution : Create Reverse lookup zone
Windows doesn’t retroactively attempt to register a PTR record if the reverse zone didn’t exist during the original registration attempt. and when ipconfig /registerdns
is run later, Windows may skip PTR registration if:
- Existing A record is current and valid
- No DNS registration errors were thrown before (i.e., silent PTR failure)
- The reverse zone was not previously accessible, but now is
- From DNS Management find the Reverse Lookup Zone
- Right click and choose New Zone
- We then require a primary zone
- We then need to replication to all domain controller in the local domain
- Next we need an IPv4 reverse lookup zone
- The we need to enter the network address, this will in this example create the zone 86.168.192.in-addr.arpa as below
- This will then confirm the zone and you have created that reverse lookup zone
Workaround : Manually Toggling the 'Register PTR' Flag in DNS
- When you open the A record in DNS Manager, there’s a checkbox labeled “Update associated pointer (PTR) record.”
- If you untick and then re-tick that box (followed by Apply), the DNS server immediately generates the missing PTR record — as long as the reverse zone now exists.
This method preserves ownership (i.e., the computer account remains the owner) and does not delete or recreate the A record, however if you have a large list of servers this can be tedious, the correct apprach here is to create the zone correctly and get the server rebooted.
This approach is not recommended and your user account will be the owner for that DNS record.
Bodge : Creating the PTR Record Remotely
Let’s go through the workflow of the script, for the script to function from your management server, you need to have remote DNS tools installed.
- Reads a list of hostnames from servers.txt
- Queries their existing A record from DNS
- Determines if a PTR record exists for their IP
- If missing, creates the PTR record on the DNS server
- The PTR records will be owned and managed by the account that runs the script
# Configuration
$dnsServer = "dnssrv1.bear.local"
$forwardZone = "bear.local"
$reverseZone = "32.10.172.in-addr.arpa"
$serversFile = "servers.txt"
$servers = Get-Content -Path $serversFile
foreach ($server in $servers) {
# Ensure FQDN
if ($server -notlike "*.$forwardZone") {
$fqdn = "$server.$forwardZone"
} else {
$fqdn = $server
}
# Get A record
$aRecord = Get-DnsServerResourceRecord -ComputerName $dnsServer -ZoneName $forwardZone -Name $server -RRType "A" -ErrorAction SilentlyContinue
if (-not $aRecord) {
Write-Warning "No A record found for $fqdn. Skipping..."
continue
}
$ip = $aRecord.RecordData.IPv4Address.ToString()
$ptrName = ($ip -split '\.')[-1] # Assumes /24 zone
# Check if PTR already exists
$existingPtr = Get-DnsServerResourceRecord -ComputerName $dnsServer -ZoneName $reverseZone -Name $ptrName -RRType "PTR" -ErrorAction SilentlyContinue
if ($existingPtr) {
Write-Host "PTR already exists for $ip ($fqdn). Skipping."
continue
}
# Create PTR record
try {
Add-DnsServerResourceRecordPtr -ComputerName $dnsServer -ZoneName $reverseZone -Name $ptrName -PtrDomainName $fqdn -TimeToLive 01:00:00
Write-Host "✅ Created PTR record: $ip -> $fqdn"
}
catch {
Write-Warning "❌ Failed to create PTR for $fqdn. Error: $_"
}
}
When the script completes you would need to for each PTR record remove your accountfrom the AC and manually added in the computer account of the server it referencing with read and write control.
This is problem caused by not creating the reverse zone before declining servers to that specific address range, The district will get you out of reverse lookup problems, but it will ultimately not fix the root cause.
Conclusion
This is one of those subtle DNS issues where the OS doesn't behave intuitively — the server believes it registered its DNS correctly, even if the PTR was never created. And because there’s no explicit error, there’s no retry.
If you deploy reverse zones after machines have already registered their A records, you’ll likely run into this silent PTR omission.