Notice: Due to size constraints and loading performance considerations, scripts referenced in blog posts are not attached directly. To request access, please complete the following form: Script Request Form Note: A Google account is required to access the form.
Disclaimer: I do not accept responsibility for any issues arising from scripts being run without adequate understanding. It is the user's responsibility to review and assess any code before execution. More information

No Reverse Looup Zone : No PTR records….

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
The correct fix to this is register the record, like this:
  1. From DNS Management find the Reverse Lookup Zone
  2. Right click and choose New Zone 



  3. We then require a primary zone 



  4. We then need to replication to all domain controller in the local domain



  5. Next we need an IPv4 reverse lookup zone


  6. The we need to enter the network address, this will in this example create the zone 86.168.192.in-addr.arpa as below


  7. We then only require secure updates


  8. 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
Script : Create-PTRRecords.ps1

# 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.

Previous Post Next Post

نموذج الاتصال