Error 8524 DNS lookup failure: replication cannot resolve the source DC

Fix it now

Error 8524 is published as the DSA operation being unable to proceed because of a DNS lookup failure. Before you touch DNS, check Microsoft’s first documented cause: the source DC is offline or gone, and only its stale NTDS Settings object is keeping the destination trying.

repadmin /showrepl <fqdn of source DC>
ipconfig /all
dcdiag /test:dns /v /e /f:dnsresults.txt

1. Read the DSA Object GUID out of the repadmin /showrepl output for the partner that is failing. Everything else uses it.
2. Ask whether that partner still exists. If it has been decommissioned or force-removed, the fix is metadata cleanup, not DNS: ntdsutil, metadata cleanup, connections, connect to server <healthy partner>, quit, remove selected server <name>.
3. If it does exist, test the record that matters against each DNS server the destination uses: nslookup -type=cname <guid>._msdcs.<forest root DNS name> <dns server ip>
4. If the alias does not resolve, force the source DC to register it: net stop netlogon & net start netlogon on the source.
5. Test the host record too, and re-register it if it is missing: nslookup -type=A+AAAA <fqdn of source DC> <dns server ip>, then ipconfig /registerdns on the source.

Query each DNS server by address rather than relying on whatever the resolver picks. The whole point is finding the server that has a different answer from the others.

If replication resumes, stop here. If it does not, the next section explains which record is being looked up and why you have never created it by hand.

Why it happens

When the Knowledge Consistency Checker builds a connection between two controllers, it records the partner by the GUID of its NTDS Settings object rather than by name. Names change; the GUID does not. To turn that GUID back into an address, the controller looks up an alias record of the form <ObjectGUID>._msdcs.<forest root DNS name>, which the partner registers automatically. That alias points at the partner’s own host record, and everything else follows from there.

Microsoft’s cause list for 8524 has six entries and the first one is not about DNS at all: the source DC is offline or no longer exists, but its NTDS Settings object still exists in the destination DC’s copy of Active Directory. The destination keeps trying to reach a partner that has gone, and the failure it reports is a DNS lookup failure because the lookup for a decommissioned machine naturally fails. Anyone who starts by rebuilding a zone here has been sent to the wrong place by the error text.

The remaining five causes are DNS in the ordinary sense: the source failed to register its records because its own DNS client settings do not point at servers that host, forward or delegate the _msdcs.<forest root> zone; the destination’s DNS client settings have the same problem; the records exist somewhere but not on the servers the destination queries, because of replication latency, a replication failure or a zone transfer failure; forwarders or delegations prevent cross-domain resolution; or a DNS server in the path is simply not working.

Full reference

The record you are actually looking for

The fully qualified alias for a domain controller takes the form <ObjectGUID from the source DC's NTDS Settings object>._msdcs.<forest root domain>. For a controller with GUID 8a7baee5-cd81-4c8c-9c0f-b10030574016 in the contoso.com forest, that is 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com. You get the GUID from repadmin /showrepl <fqdn of the source DC>, which prints it as the DSA Object GUID.

The queries, in the order that isolates the fault

Run each of these against the primary and the secondary DNS server of the source, and then against those of the destination. Four machines, four answers, and the one that differs is your fault. Doing it without naming the server is how people conclude that DNS is fine when one of four servers has a stale answer.

Forcing registration, correctly

Those are the two documented actions and they are not interchangeable. Restarting Netlogon registers the locator and alias records; ipconfig /registerdns registers the host record. If the alias is present and the host record is not, the lookup still fails, and only the second command helps.

Removing a partner that has gone

1. From Active Directory Users and Computers, connect to a replication partner of the removed DC, expand Domain Controllers, right-click the computer object and delete it. Confirm that the DC is permanently offline and cannot be demoted, and let it move any operations master roles it held.
2. Or from Sites and Services, expand the site, Servers, the server, right-click NTDS Settings and delete it, confirm the same prompt, then delete the server object itself.
3. Or from the command line: ntdsutil, metadata cleanup, connections, connect to server <partner>, quit, remove selected server <name>, then quit out.
4. If any of those fails with access denied, clear “Protect object from accidental deletion” on the computer object and the NTDS Settings object and try again.
5. Confirm the object no longer appears under Domain Controllers, and that the server object has no NTDS Settings beneath it.

Events, and which one to act on

Microsoft’s wording on 2088 is worth taking at face value: invalid DNS configuration may be affecting other essential operations including logon authentication and access to network resources, and you should resolve it immediately. A forest full of 2088 warnings is a forest that will produce 2087 errors the next time anything changes.

Domain controller DNS settings that stop this recurring

• Point each controller at another controller first and at itself second. A controller that resolves only through itself can become isolated from the forest and will not notice.
• Keep public resolvers off the adapter entirely. Put external resolution in the DNS server’s forwarders, where it belongs.
• Confirm that every DNS server a controller uses hosts, forwards to, or delegates the _msdcs.<forest root> zone. That is Microsoft’s phrasing and it is the test that matters.
• Run dcdiag /test:dns /v /e /f:<file> across the forest periodically rather than only when something breaks, and read what it flags.

Every code this article covers

Confirm the fix worked

1. Resolve the partner’s GUID alias from the previously failing controller, against each of its DNS servers by address, and confirm they all agree.
2. Run dcdiag /test:dns /v /e /f:dnsresults.txt and confirm the tests pass on both controllers.
3. Run repadmin /replsummary and confirm no partner reports a failure or a stale last-success time.
4. Check the Directory Service log over the following day for new 2087 or 2088 entries.
5. If you removed a stale partner, confirm it no longer appears in Sites and Services or under Domain Controllers.

Questions people ask about this