Event ID 5781: dynamic registration of domain controller DNS records failed

Fix it now

Microsoft publishes 5781 as “Dynamic registration or deletion of one or more DNS records associated with DNS domain ‘<domain>’ failed.” It comes from Net Logon, not from DNS. Clients that already know a domain controller keep working, so the damage shows up slowly, in new sign-ins and in other sites.

dcdiag /test:RegisterInDNS /DnsDomain:corp.example.com
dcdiag /test:DNS /DnsRecordRegistration
ipconfig /all

1. Read the RegisterInDNS output. Microsoft documents this test as checking whether the directory server can register the locator records other computers need, including whether the authoritative zone can be contacted, whether an adapter has a primary DNS server, whether the namespace is disjoint, whether dynamic updates are possible, and whether the locator records come back.
2. Check the server’s own resolver settings. Every DNS server listed must host the directory zone or be able to reach a server that does; a public resolver in the adapter settings guarantees this event.
3. In DNS Manager, open the zone’s properties and confirm dynamic updates are permitted. With updates set to none, no domain controller will ever register anything.
4. Restart Net Logon on the domain controller and re-run the two tests.

If your directory zone is a single label, treat that as the cause rather than a puzzle: Microsoft documents 5781 as a symptom of single-label DNS names, where clients and DCs cannot dynamically register records in the zone.

If both tests pass and the locator records resolve, you are done. If not, the next section covers what a domain controller has to publish and why it fails.

Why it happens

Nobody creates a domain controller’s locator records by hand. Net Logon works out the set of names the server must own – the service records clients query to find a domain controller, the alias that carries the server’s directory identifier, and its host records – and registers them as dynamic updates. Event 5781 is that registration failing, and Microsoft’s published text names the DNS domain the records belong to.

Two conditions have to hold for the update to succeed. The DNS server the domain controller is configured to use must be authoritative for the zone or able to reach one that is, and the zone itself must accept dynamic updates. For a directory-integrated zone the setting to use is secure updates only, which lets a machine update the records it already owns and refuses updates from anything else.

Microsoft documents one configuration where this event appears consistently and no zone setting fixes it: a domain with a single-label DNS name. In that case clients may be unable to register records dynamically in the single-label forward lookup zone, and the domain controllers log 5781 in their system logs as a matter of course. That is a naming decision to unwind, not a registration problem to troubleshoot.

The rest of the events in this family – 5774, 5775 and 6702 – are not published by Microsoft. Read them for the record names, DNS server addresses and status values they carry. A 5774 naming one record and one DNS server tells you exactly which zone to look at, and that is more useful than any definition of the number would be.

Full reference

The events

Only 5781 is published. The three companions are still useful, because each names a specific record and a specific DNS server, which is a narrower question than the one 5781 asks.

The tests Microsoft documents for this

Why nothing breaks immediately

Clients cache the domain controller they used, so an estate whose domain controllers have stopped registering records carries on working for a while. The failures appear as machines move between sites, reboot, or need a domain controller they have never talked to before. That delay is the reason this event gets closed as low priority and then reopened weeks later as an apparently unrelated authentication problem in one office.

Registering by hand is a poor answer

You can create the records manually, and occasionally during a recovery you have to. It is a bad long-term arrangement because the set includes an alias keyed to the server’s directory identifier, and any hand-built set has to be maintained by hand every time a domain controller is added, removed or readdressed. A missed edit produces exactly this problem again, with no event to tell you, because nothing tried to register anything.

Multi-homed domain controllers

• A domain controller with a backup, storage or cluster network should register only its production address.
• Turn off DNS registration on the non-production adapters rather than relying on binding order.
• Delete the records those adapters already created; turning registration off does not remove what is already published.
• Check the result by resolving the server’s name and confirming only the intended addresses come back.
• Repeat the check after any adapter or teaming change, because rebuilding a team commonly restores the default.

Secure updates and what they protect

Setting a zone to accept updates from anything makes this event disappear, and it is the wrong trade. Secure updates tie each record to the account that owns it, so a machine can maintain its own records and nothing else. An open zone lets any host on the network overwrite any record, including the ones clients use to find domain controllers. If the only way to make registration succeed is to open the zone, the registration is failing for a reason worth finding.

Every code this article covers

Confirm the fix worked

1. dcdiag /test:RegisterInDNS /DnsDomain:<domain> passes on the affected domain controller.
2. dcdiag /test:DNS /DnsRecordRegistration reports no registration failures.
3. The locator service records for the domain resolve and list this server.
4. Only the intended addresses come back when the server’s name is resolved.
5. No new 5781 or 5774 appears after the next Net Logon restart.

Questions people ask about this