This problem may occur due to old entries in the DNS zone of the previous domain, probably due to a deregistration failure. See WITP75674
for additional information about this event.
This issue may occur if you have implemented a single-label domain namespace. Microsoft does not recommend that you use Active Directory directory service domains with single-label DNS names. If you want to keep your single-label DNS structure, see ME826743
to initiate dynamic registration or deletion of the DNS records.
I also got that even on my server, which has 2 NICís and is the only DC in the domain (hence holds Active Directory and DNS). The first NIC was left with the defaults (DHCP for IP and DNS) the other one was using 127.0.0.1 as a DNS on the private LAN. This was causing the event. Yet I configured my server to reply to DNS requests only on the private LAN interface ("Interfaces" tab of the DNS server properties in the MMC snap-in). Therefore, I removed the internet NIC IP address from the list and left only the private LAN. It is important in such a configuration that the private LAN TCP/IP DNS property is not pointing to 127.0.0.1 (localhost) but to the actual DNS server IP in the private LAN, 192.168.<xxx>.<xxx> in my case. It is close to Bjarni Thorís analysis in that the DNS server IP must appear there.
There is another significant source of event id 5781. If your domain is named with a simple (single-label name; one without a period ("dot", ".")), then the client will not perform DNS dynamic updates. Therefore, a domain name like "home" or "local" would qualify. The "fix" is to add "UpdateTopLevelDomainZones" = 0x1 to "HKLM\System\CurrentControlSet\Services\DnsCache\Parameters" and then reboot the system. See Q 300684 for this and more details.
This error may occur in several circumstances. See ME259277
for a general approach on troubleshooting this error message.
The event can also be caused by start of NETLOGON service before DNS if hosted on same Domain Controller - see ME193888
- adding DNS as a dependency for Netlogon service - (link below)
One particular condition is when a DNS server running BIND is used a forwarder in a Windows 2000-based DNS. Due to its behavior on caching DNS records, a response to a DNS query made by a Windows 2000 server to dynamically register a client computer name may appear as not being authoritative (even if it is). In this case the Windows 2000 server informs the client that the request failed. As per Microsoft, this problem was fixed with SP1.
says that when a Windows 2000-based Active Directory-integrated DNS server that hosts a global catalog boots, the registration of specific SRV records may not succeed. The service startup order prevents certain SRV records from being registered because those services start before DNS is ready to receive registrations on a global catalog server. To work around this behavior, specify a different Windows 2000-based Active Directory-integrated DNS server on the DNS tab in the Advanced TCP/IP Settings dialog box.
Microsoft's KB article ME311354
only tells you half the story, there is another file called netlogon.dnb that holds those records. That file should be removed as well as doing what ME311354
tells you to do. Stale resource records now disappear for good.
I had this test machine that was a DC running DNS. I was getting this error, every two hours. I got rid of this error as follows:
1. In the TCP/IP properties of the machine I selected "Advanced" and then "DNS"
2. In the "DNS server addresses, in order of use:" I put the IP of my DNS server at the top, then the forwarders.
Before the 5781 I was getting the 5782 error - for that I made the recommended changes in the registry:
Create a new DWORD value and name it: DnsUpdateOnAllAdapters. Set the value to 1.
The eventid 5781 can occur if you have multiple domains with a delegated zone for each domain and only the root domain runs Service Pack 3 and the rest Service Pack 2. If you make a network capture you can see that the netlogon services recieves a server failure when query a soa record for a DsaGuid._msdcs.Forestname record. You can reproduce the error by using nslookup / set type=soa and enter the DsaGuid._msdcs.Forestname record you find the networkcapture
In ServicePack 3 Microsoft changed some things in the way DNS server responds to queries. So a DC running Service Pack 2 cannot handle this type of response. So the solution is..make sure all domain controllers in the forest are running Service Pack 3.