NTDS events 2087 and 2088 — DNS lookup failure caused replication to fail
2088 means replication succeeded by falling back to NetBIOS or a fully qualified name; 2087 means it failed outright. Both say DNS is broken — 2088 is the warning before 2087.
What you see
Directory Service log records 2087 or 2088 naming a partner DC. Replication may still be working, which is why 2088 is often ignored until it becomes 2087.
What is actually wrong
The partner's host record or its _msdcs CNAME is missing, stale, or the DC is querying a DNS server that does not host the zone.
Codes and articles
The fix
Repair the DNS records the DCs use to find each other
Either event is present. Treat 2088 with the same urgency as 2087 — it is the same fault, currently masked by a fallback.
Run the DNS test and read the failures rather than the summary.
dcdiag /test:dns /v /eOn each DC, re-register its records.
ipconfig /registerdnsnltest /dsregdnsRestart-Service Netlogon
Check for stale records belonging to decommissioned DCs and delete them.
Get-DnsServerResourceRecord -ZoneName '_msdcs.example.local' -RRType CName | Format-Table HostName, RecordData -AutoSizeA CNAME pointing at a DC that no longer exists makes replication attempts hang and then fail, and dcdiag reports it as a lookup failure.
Confirm scavenging is enabled so stale records do not accumulate again.
Get-DnsServerScavengingForce replication.
repadmin /syncall /AdeP
dcdiag /test:dnsrepadmin /replsummary
Reference
Related faults
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.