Share via

DNS Errors 5014 and 4013

Rob Christensen 0 Reputation points
2026-06-04T20:53:59.86+00:00

I am getting these errors and my Active Directory is not syncing across all 3 of my domains. #dns

#server 2016

Windows for business | Windows Server | Directory services | Active Directory
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tracy Le 9,030 Reputation points Independent Advisor
    2026-06-04T21:40:27.9266667+00:00

    Hi Rob Christensen,

    I see you are dealing with a critical replication blockage across your infrastructure, evidenced by DNS Event IDs 4013 and 5014. These errors typically point to a classic where your Domain Controllers hosting Active Directory-integrated DNS zones cannot start their DNS service because they are waiting on initial inbound AD replication, but replication is failing because name resolution is broken. To isolate and break this loop, you should check your network card settings on each DC and ensure they do not point exclusively to themselves or to offline replication partners for name resolution.

    To bypass this deadlock and restore directory synchronization, you should temporarily configure the DNS Server service startup type to Manual on the affected DCs and reboot the machines. This action prevents Active Directory from hanging during boot while waiting on a non-functional DNS layer. Once the DCs fully advertise and complete their initial Active Directory inbound replication tracking, you can start the DNS Server service manually and return its startup type back to Automatic.

    Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

    Tracy Le.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-04T20:54:14.3766667+00:00

    DNS events 4013 and 5014 together indicate that domain controllers hosting AD‑integrated DNS zones are having trouble starting DNS because Active Directory replication and name resolution to other DCs are not working correctly. This directly impacts AD replication across domains.

    Key points from Event 4013:

    • DNS Server service startup is delayed because it cannot load AD‑integrated zones until initial Active Directory inbound replication completes.
    • DCs must resolve the CNAME GUID records and corresponding A/AAAA records of their replication partners in the _msdcs.<forest‑root‑domain> and domain DNS zones.
    • If DCs cannot resolve those names (because DNS is misconfigured, DCs are offline, or records are stale), initial sync stalls and DNS logs 4013.

    Typical causes in this scenario:

    1. DCs/DNS servers are pointing to the wrong DNS servers
      • DCs hosting AD‑integrated DNS zones are configured to use:
        • Only themselves as DNS, or
        • DNS servers that are offline, non‑existent, or do not host the required _msdcs and domain zones.
    2. Stale or missing DNS records for DCs
      • Missing, duplicate, or stale CNAME GUID records and host A/AAAA records for domain controllers in _msdcs.<forest‑root‑domain> and domain zones.
    3. Network or topology issues
      • DCs booted on an isolated network, network adapter/stack not functional, or references to DCs that are turned off or decommissioned.
    4. All/most DCs rebooted at the same time
      • Multiple DCs in a site rebooted together, each waiting on the others for name resolution and replication, causing 15–25 minute hangs and 4013.

    Recommended troubleshooting and fixes:

    1. Verify DC DNS client configuration
    • On each domain controller (in all three domains):
      • Ensure preferred and alternate DNS servers:
        • Are online at Windows startup.
        • Host, forward, or delegate the _msdcs.<forest‑root‑domain> and the domain DNS zones.
        • Can resolve the DCs’ CNAME GUID records and host A/AAAA records.
    • Avoid single points of failure:
      • Do not configure a DC to point only to itself or a single DNS server, except in a single‑DC forest.
      • In multi‑DC environments, hub‑site DCs should point to other hub‑site DNS servers as preferred/alternate, then to themselves as a final alternate.
      • Branch‑site DCs should point to a hub‑site DNS server as preferred, an in‑site/nearest DNS as alternate, and finally to themselves.
    1. Check for stale or missing DC records
    • In the DNS zones (_msdcs.<forest‑root‑domain> and each domain zone):
      • Confirm that each DC has:
        • A CNAME GUID record under _msdcs.<forest‑root‑domain>.
        • Matching host A/AAAA records.
      • Remove references to DCs that no longer exist.
      • Ensure scavenging is not so aggressive that it deletes valid DC records.
    1. Confirm AD replication and name resolution
    • Look for NTDS replication events 2087 and 2088 on DCs:
      • These indicate that a DC cannot resolve the CNAME GUID of a source DC or is falling back to other name resolution methods.
    • Ensure DCs can resolve each other by:
      • CNAME GUID → FQDN → NetBIOS name.
      • If necessary, temporarily use WINS, HOSTS, or LMHOSTS to allow DCs to resolve each other, noting that WINS is more scalable.
    1. Handle known bad configurations and startup delays
    • If DCs are stuck during boot because of this issue:
      • Set the DNS Server service startup type to Manual on the affected DC.
      • Reboot, wait for the DC to fully advertise and complete AD replication.
      • Then start the DNS Server service manually.
    • This prevents AD from waiting on DNS to start when DNS itself is blocked by incomplete replication.
    1. Clean up DC references and topology
    • Remove references to:
      • Stale DCs that no longer exist.
      • DCs that are permanently offline.
    • Bring offline or non‑functioning DCs back online if they are still part of the topology.
    1. Operational best practices to prevent recurrence
    • Stagger reboots of DCs/DNS servers so that not all potential replication partners/DNS servers are down at once.
    • Use UPS and, where needed, generators to keep key DCs/DNS servers online during power events.
    • Avoid placing all DNS servers on the same physical host or in a single site.

    Registry‑based bypass (not recommended except as last resort)

    • Some guidance suggests setting:
      • HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
        • Repl Perform Initial Synchronizations = 0 (REG_DWORD)
    • This disables initial sync requirements but is not recommended for production or ongoing use. It should only be used temporarily in critical situations and then reverted to the default.

    Addressing the above DNS and replication configuration issues on each DC in all three domains will resolve the 4013/5014 events and restore proper Active Directory synchronization.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.