2nd DC freshly created cant be contacted and does not autnenticate users

Question

I have a primary DC (win 2k19) managing a network and decided to add a 2nd DC in case of any failure for the PDC. The 2nd DC is also win 2k19, setup went OK and it seems that replication was OK as well, time is synced between both. Windows firewall on DC2 is disabled.

When I shut down the PDC and tried to check that secondary DC will act and respond, it did not work, doing nslookup from client, it does not work.

When I fire Azure Users and Computers, I see that everything was transfered from DC1 to DC2

When Issuing the following command when DC1 is up and running

 .\nltest /dclist:salam.net

I get

Get list of DCs in domain 'salam.net' from '\SALAMMAIN.salam.net'. SALAMMAIN.salam.net [PDC] [DS] Site: Default-First-Site-Name DC2.salam.net [DS] Site: Default-First-Site-Name The command completed successfully

Running

ping salam.net

on both machines DCs gives same result, it responds with the DC2 IPv4.

DNS roles installed on both DCs

I have set the IP address of DC1 and 127.0.0.1 for Preferred DNS on DC1.

I have set the IP address of DC1 and 127.0.0.1 for Preferred DNS on DC2

issuing nslookup salamn.net

I get

Server: dc1.salam.net Address: 192.168.1.13 *** dc1.salam.net can't find salamn.net: Non-existent domain

I really dont understand the 3rd statement when it has already found dc1 and its IP

When I run

repadmin /syncall /AdeP on both DCs, I get 
	SyncAll terminated with no errors.

but running on DC2 (the new DC)

dcdiag /test:replications

I get

DsReplicaGetInfo() failed with status 8453 (0x2105) Replication access was denied.

As I said, when I disconnect Dc1 from network no authentication happens with DC2 and need to bring back DC1 in the network

Answer 1

Hi Salam,

The issue is with DNS configuration and replication permissions. Right now, both DCs are pointing to DC1 as their preferred DNS, which means when DC1 is offline, DC2 cannot resolve queries properly. On each DC, set the preferred DNS to its own loopback (127.0.0.1) and the alternate DNS to the other DC’s IP. For example, DC1 should use 127.0.0.1 as preferred and DC2’s IP as alternate, while DC2 should use 127.0.0.1 as preferred and DC1’s IP as alternate. This ensures each DC can resolve names independently when the other is down.

The replication error 8453 indicates that the DC2 machine account does not have sufficient replication permissions. Verify that DC2 is a member of the “Domain Controllers” OU and that the NTDS settings object exists under Sites and Services. Also check that the “Authenticated Users” group has “Replicating Directory Changes” permission on the domain root in Active Directory. Run dcdiag /test:replications /v again after confirming.

Finally, make sure clients are configured to use both DCs as DNS servers, not just DC1. If clients only point to DC1, they will fail when it is offline. Once DNS is corrected and replication permissions fixed, DC2 will be able to authenticate and serve as a proper backup when DC1 is unavailable. Best Regards.

Answer 2

The second domain controller is online but not being used because of DNS and replication registration issues. Focus on DNS client configuration, DC locator records (_msdcs), and replication permissions.

1. Fix DNS client settings on both DCs

On each DC, the preferred DNS server must be another working DC, not itself, until all locator records are correctly registered and replicated.

Use the pattern from the “DNS island” guidance:

• Choose one DC (for example, DC1) as the primary DNS for the forest root.
• Configure DNS on DCs as follows:
  • DC1: Preferred DNS = DC1 (its own IP). Alternate DNS = DC2 (optional, but must not point to itself as alternate).
  • DC2: Preferred DNS = DC1 (DC1’s IP). Alternate DNS = DC2 (its own IP) or another DC, but never only itself.

This avoids the “DNS island” situation where a DC points only to itself and is missing other DCs’ locator records.

2. Verify _msdcs CNAME and SRV records

The error DsReplicaGetInfo() failed with status 8453 (Replication access was denied) and the fact that clients cannot use DC2 when DC1 is down strongly suggest missing or incomplete DC locator records in DNS.

On DC2:

1. Run ipconfig /all and confirm the DNS Servers list shows DC1’s IP first.
2. Use nslookup to query the CNAME for DC2’s NTDS Settings object GUID on the DNS servers DC2 points to, as described in the replication troubleshooting:

      nslookup -type=cname <DC2-NTDS-GUID>._msdcs.<forest-root> <DC1-DNS-IP>
      nslookup -type=cname <DC2-NTDS-GUID>._msdcs.<forest-root> <DC2-DNS-IP>
   

3. If the CNAME is missing on either DNS server, restart Netlogon on DC2 to force registration:

      net stop netlogon & net start netlogon
   

4. Ensure that the _msdcs.<forest-root> zone exists only once (no duplicate zones in different replication scopes) and that SRV records such as _ldap._tcp.pdc._msdcs.<domain> and other LDAP SRV records for all DCs are present. If SRV records are missing, restarting Netlogon on the DCs will repopulate them; then ensure AD replication is healthy so changes replicate across DNS servers.
5. Confirm DNS and DC reachability from clients

On a domain member client:

1. Check firewall/ports between client and both DCs: UDP 53 (DNS) and UDP/TCP 389 (LDAP) must be open.
2. Run:

      nltest /dsgetdc:<domain> /force /kdc
   

   This should list both DC1 and DC2 as available DCs.
3. Run:

      nslookup <DC2-FQDN>
      nslookup <domain-FQDN>
   

   If nslookup fails to resolve DC2 or the domain when DC1 is offline, DNS on DC2 is not serving all required records; re-check the _msdcs zone and SRV/CNAME registration as above.
4. Address replication access denied (8453)

The 8453 error on dcdiag /test:replications from DC2 indicates that DC2 cannot authenticate properly to replicate from DC1. Once DNS is corrected and the CNAME/SRV records are properly registered and replicated, rerun:

repadmin /syncall /AdeP

If 8453 persists, verify that DC2’s computer account and NTDS Settings object are correct and that there are no duplicate NTDS objects for DC2. Ensure that DC2 is using valid domain credentials (its machine account) and that there are no network/firewall blocks on LDAP/Kerberos between DC1 and DC2.

5. Test failover again

After fixing DNS and replication:

1. With both DCs online, confirm:
   • nltest /dclist:<domain> shows both DCs.
   • dcdiag /test:replications passes on both DCs.
2. Gracefully shut down DC1.
3. On a client, run:

      nltest /dsgetdc:<domain> /force /kdc
   

   It should now select DC2.
4. Test logons and access to shared resources.

If authentication still fails when DC1 is down, check for:

• Clients still pointing only to DC1 for DNS (they must list DC2 as DNS as well).
• Negative caching or clients repeatedly selecting a DC that is shutting down. To avoid this, stop Netlogon (and KDC) on a DC before shutting it down so clients are forced to choose another DC.

---

References:

• DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain
• Active Directory Replication Error 8524: The DSA operation is unable to proceed because of a DNS lookup failure
• Error "The namespace cannot be queried. The specified domain either does not exist or cannot be contacted" with DFS Namespaces
• Event ID 5719, Error 1311, or Error 1355 - Domain controller or domain not found
• Domain members fail authentication when domain controller is shut down