Active Directory's proper functioning heavily depends on DNS SRV records. These records enable clients to locate domain controllers through standard DNS queries. When records like _ldap._tcp.dc._msdcs or _kerberos._tcp.dc._msdcs go missing, authentication and replication break down completely.

First, verify the records are truly missing with this PowerShell check:

Get-DnsServerResourceRecord -ZoneName "_msdcs.yourdomain.com" -RRType "SRV" | 
Where-Object {$_.RecordData.DomainName -like "*_ldap*"} | 
Format-Table HostName, RecordData

Key indicators of trouble:

• Missing _ldap, _kerberos, _gc records
• Domain controllers not registering themselves
• Event ID 5774 in Directory Service logs

For manual recreation (last resort method):

# PowerShell method to recreate _ldap record
Add-DnsServerResourceRecord -Srv -ZoneName "_msdcs.yourdomain.com" 
-Name "_ldap._tcp.dc" 
-DomainName "dc01.yourdomain.com" 
-Priority 0 
-Weight 100 
-Port 389 
-TimeToLive 01:00:00

The GUID-based records (like {GUID}._msdcs) are machine-specific and should regenerate automatically once proper services restart.

Ensure these settings are correct:

# Verify DNS registration settings
Get-NetAdapter | Set-DnsClient -RegisterThisConnectionsAddress $true

# DC-specific registration check
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" | 
Select-Object UseDynamicDns

For scavenging configuration (use cautiously):

Set-DnsServerScavenging -ScavengingState $true 
-RefreshInterval 7.00:00:00 
-NoRefreshInterval 7.00:00:00

Here's a complete restoration script I've used successfully:

# DC SRV Record Restoration Script
$domain = "yourdomain.com"
$dcName = hostname
$dnsServers = Get-DnsServer -ComputerName $dcName

foreach ($server in $dnsServers) {
    # Standard SRV records
    $records = @(
        @{Name="_ldap._tcp.dc"; Proto="tcp"; Port=389},
        @{Name="_ldap._tcp.gc"; Proto="tcp"; Port=3268},
        @{Name="_kerberos._tcp.dc"; Proto="tcp"; Port=88}
    )
    
    foreach ($rec in $records) {
        try {
            Add-DnsServerResourceRecord -Srv -ZoneName "_msdcs.$domain" 
                -Name $rec.Name 
                -DomainName "$dcName.$domain" 
                -Priority 0 
                -Weight 100 
                -Port $rec.Port 
                -ComputerName $server.IPAddress
        }
        catch {
            Write-Warning "Failed to create $($rec.Name): $_"
        }
    }
    
    # Force Netlogon to re-register
    Restart-Service Netlogon -Force
    Register-DnsClient
}

Implement this monitoring check:

# Daily monitoring script
$requiredRecords = @(
    "_ldap._tcp.dc._msdcs",
    "_kerberos._tcp.dc._msdcs",
    "_ldap._tcp.pdc._msdcs"
)

foreach ($record in $requiredRecords) {
    $exists = Resolve-DnsName -Name "$record.$domain" -Type SRV -ErrorAction SilentlyContinue
    if (-not $exists) {
        Send-MailMessage -To "admin@domain.com" 
            -Subject "Critical AD DNS Record Missing: $record" 
            -Body "The $record SRV record is missing from DNS!"
    }
}

When your _msdcs zone records vanish suddenly, it's not just a DNS issue - it's an authentication crisis. These records are the backbone of Active Directory's service discovery mechanism. The absence of _ldap._tcp.dc._msdcs and _kerberos._tcp.dc._msdcs records effectively blinds clients to domain controller locations.

First, verify the extent of the damage with PowerShell:

# Check basic DNS functionality
Test-DnsServer -IPAddress 192.168.1.10 -Context DnsServer

# Verify SRV records existence
Resolve-DnsName -Type SRV -Name "_ldap._tcp.dc._msdcs.yourdomain.com"

# Check DC registration status
Get-WinEvent -LogName "Directory Service" -MaxEvents 20 | 
    Where-Object {$_.Id -eq 5774} | Format-List

For global record regeneration, execute this sequence on each DC:

# Stop Netlogon service temporarily
Stop-Service Netlogon -Force

# Clear existing registration
ipconfig /flushdns
ipconfig /registerdns

# Force service registration
net stop netlogon && net start netlogon

# Trigger full DNS registration
nltest /dsregdns

When automated methods fail, you'll need surgical precision. Here's a sample script to rebuild critical records:

# PowerShell script to recreate essential SRV records
Import-Module DnsServer

$domain = "yourdomain.com"
$dc1IP = "192.168.1.10"
$dc2IP = "192.168.1.11"

# LDAP records
Add-DnsServerResourceRecord -Srv -Name "_ldap._tcp.dc._msdcs.$domain" 
    -DomainName $domain -Priority 0 -Weight 100 -Port 389 
    -Target "dc1.$domain"

# Kerberos records
Add-DnsServerResourceRecord -Srv -Name "_kerberos._tcp.dc._msdcs.$domain" 
    -DomainName $domain -Priority 0 -Weight 100 -Port 88 
    -Target "dc1.$domain"

# GC records
Add-DnsServerResourceRecord -Srv -Name "_ldap._tcp.gc._msdcs.$domain" 
    -DomainName $domain -Priority 0 -Weight 100 -Port 3268 
    -Target "dc1.$domain"

Implement these monitoring safeguards:

• Create a scheduled task to verify SRV records weekly
• Enable debug logging for DNS registration events
• Configure alerting for Netlogon registration failures

Those cryptic SID-based records (e.g., 1a1b2c3d-1234-5678-abcd-0123456789ab._msdcs) are actually GUIDs representing:

# To find your DC's GUID:
Get-ADDomainController -Identity YourDC | Select-Object NTDSettingsObjectGUID

These are automatically regenerated when the Netlogon service restarts, provided the DC can write to DNS.