1

The service runs but shows access is denied. This is the primary AD, and secondary appears to be fully operational with no errors.

How to restore or reload the DNS services? Rebooting and Netlogon service restarts have had no change.

6 Spice ups
2

Can you be clearer, where says access denied?

Are you using an account that has permissions to view the DNS?

What do each DC use for their DNS?

Any clues in the event logs?

We’re going to need more information about the setup to help.

1 Spice up
3

So the primary AD server somehow had a DNS corruption/failure. The secondary appears to have been unaffected. But primary was also the local DHCP server among everything else.

So I’ve gotten a little farther since. I’ve transferred the FSMO roles to the second AD server, and AD DNS appears to be working, but exporting and restoring the DHCP services is not operational.

I’ve imported the DHCP scopes and they’re all listed correctly, but the second AD server does not respond to DHCP requests at all, and seems to have assigned a 169. address as its name, despite being authorized under its static IP.

It is the root DNS for the domain and LAN now, and public internet is accessible. but AD services like Exchange are still unavailable. ie: I can lookup the server, but services don’t respond.

All the settings appear to be correct, but systems on the LAN still can’t get a DHCP address or when set statically, can lookup servers but the AD services aren’t responding. So for example, Outlook cannot connect to Exchange, and even OWA is unavailable.

4

DHCP shouldn’t really be on a DC, but make sure you update any DHCP helpers or DHCP relays, otherwise everything will still think that DC1 is the DHCP server.

You’ve ignored most of what I asked for though, I’m specifically interested in the DNS servers you have for clients and what the DCs themselves point to.

I don’t need IPs, just what they are.

2 Spice ups
5

the DNS servers for clients have always been DC1 and DC2. DC1 is the one that failed, DC2 has been promoted to FSMO. They only have root forwarders/default for public lookups.

6

The DCs may have forwarders or use root hints, but what are their DNS.

Do they point to themselves, each other, somewhere else?

Your DHCP issue, assuming you’re authorized it and updated the helpers/relays should be up and running soon.

7

You mean the actual zone lookups?

they point to themselves for the AD zones - originally DC1. Everything else should be going externally to root forwarders. In the case of AD2, it’s 127.0.0.1, and secondary DNS was AD1’s IP. And vice-versa for the failed AD1.

8

What @Rod-IT is asking is, what DNS servers are configured in the network interface on DC1?

Your domain controllers should have statically-assigned addresses and should not get their addresses from DHCP – especially the DHCP server should have a static address. But let’s not confuse the DNS issue with DHCP issues right now if we don’t have to; let’s just focus on the DNS issues for now.

Further, on domain controllers, the network interface should be configured with the other domain controller as the primary DNS server, and 127.0.0.1 (localhost) as the secondary.

What network profile is in force on DC1? It should be “Domain” not “Public” or “Private”.

Side note that doesn’t really apply here but I include for completeness:

Best practice in an AD environment with only one DC, the DC’s NIC should have 127.0.0.1 as the only DNS server. In an environment with more than two DCs, each DC’s NIC should specify two other DC’s as DNS servers, and 127.0.0.1 as tertiary.

There are other, unconventional DNS configurations that can be made to work properly in an AD environment, but I won’t discuss those here as that’s way outside the scope of discussion. Suffice to say that you shouldn’t specify non-AD DNS servers in an AD environment unless you really understand how DNS works in this environment.

1 Spice up
9

If the AD DNS service is running but showing access denied, sounds like a permissions issue on the DNS service itself or something got out of sync between the primary and secondary. First thing I’d check is if the DNS server service is actually using the correct credentials and has access to the AD database. Make sure the service is running under the right context, usually Local System. Also check the DNS folder permissions in C:\Windows\System32\dns to make sure nothing got messed up there.

You could try stopping the DNS service, backing up and then deleting the zone files from System32\dns, then starting the service again to see if it pulls clean data from the secondary. Since your secondary is healthy, it should replicate the zones back down as long as AD replication is working right.

Also double check event logs under DNS Server and Directory Service for any errors tied to replication or security.

If nothing works, dcdiag /test:DNS /v and repadmin /showrepl might give you better clues about what’s failing and where. Could be a lingering metadata or permission issue that needs manual cleanup.

1 Spice up
10

They should point to each other as their first DNS and 127.0.0.1 as the secondary. The way you have it configured is wrong, if they connect to 127.0.0.1 first, they wont look at the other DNS server, nor replicate, so it’s possible DC1 is problematic because of this.

Obligatory plug

11

(post deleted by author)

12

AD DNS service appears to be fully operational on DC2, the only error was the order of the DNS queries. DC2 does pass the DCdiag tests, only RREG is listed as FAIL. All others are PASS or WARN status.

And for replication there’s nothing to replicate to now, DC1 is down.

13

Got it. If DC2 is passing most of the dcdiag tests and DNS is functional aside from the query order, that’s a good sign it’s not completely broken. The RREG failure usually points to an issue with dynamic registration of the DC’s own records in DNS. That could be caused by a permissions problem, misconfigured network settings, or something off in the DNS zone itself.

Here’s what I’d check next:

Make sure DC2 is using its own IP and loopback (127.0.0.1) for DNS, not pointing to an external resolver or just DC1. If it’s not using itself, it might not be registering its records properly.

Run ipconfig /registerdns on DC2 manually and then check the DNS logs and the zone to see if it actually tries to write.

Look in the zone (under _msdcs and _sites especially) to see if DC2’s A and SRV records are there or missing.

Verify the zone allows secure dynamic updates and that DC2 has permission to update it.

Also worth checking if the computer account for DC2 still has full rights to the zone in AD. If there’s a replication hiccup or old metadata, that could block updates too.

If everything else is working and this is the only red flag, it’s probably just a registration issue rather than a deeper replication or config problem. Still, worth chasing down so it doesn’t bite you later.

14

Make sure DC2 points to DC1 first and then 127.0.0.1 for secondary. (DC1 should point to DC2 first and 127.0.0.1 second)

Run

ipconfig /registerdns
dcdiag /fix

It may take several hours after fixing the DNS resolvers on the NIC before replication straightens itself out.

Run this from both DCs from an admin cmd or powershell prompt. Look for errors.

repadmin /showrepl

15

Here’s what I’d check next:

Make sure DC2 is using its own IP and loopback (127.0.0.1) for DNS, not pointing to an external resolver or just DC1. If it’s not using itself, it might not be registering its records properly.

Run ipconfig /registerdns on DC2 manually and then check the DNS logs and the zone to see if it actually tries to write.

Look in the zone (under _msdcs and _sites especially) to see if DC2’s A and SRV records are there or missing.

Verify the zone allows secure dynamic updates and that DC2 has permission to update it.

Those do appear to check out OK, there were no errors on the registration, it is listed in the zones under _msdcs & _sites.

Even when statically pointed to DC2 for DNS, clients are still having issues with AD services tho. They are able to lookup IPs, both AD and public DNS. So the DC2 DNS is clearly responding and forwarding queries.

DCDiag /fix results appear mostly clean and operational.

The only errors it appears to throw are the DC1 being down, and warnings on NTPClient.

16

Run

ipconfig /registerdns
dcdiag /fix

It may take several hours after fixing the DNS resolvers on the NIC before replication straightens itself out.

Run this from both DCs from an admin cmd or powershell prompt. Look for errors.

repadmin /showrepl

As I mentioned, DCdiag appears to be operational. And barebones DNS seems operational on DC2.

The two immediate problems now are DHCP, and Exchange functionality. DHCP I expect can be fixed by finding and rerouting the DHCP helper/pointers, but the DHCP server set up on DC2 appears functional but I have no way to test it as-yet. It’s listed as a 169. address, however it is authorized for the DC2 hostname, and the service is bound to the DC2 IP so it should respond to requests. There are no devices on the server LAN that would make DHCP requests tho - it’s all desktop and other clients from remote subnets.

And static IPs mean devices can reach the DC2 DNS and do lookups. But some AD functionality still isn’t working and I don’t know if that’s the DC2 server functionality not operating, or the Exchange server not polling it correctly.

Exchange functionality appears to be borked - the server is running and receiving email, and external IMAP and POP clients can get in and send and receive email, but Outlook clients cannot. It has been repointed to DC2 for DNS lookups, but no other changes and of course I haven’t rebooted it either. OWA is operational as well, so the server obviously can authenticate users.

So I’m better off than earlier, but still not 100% functional, and haven’t even started on restoring/replacing the DC1.

17

169 address on the DC? Do you have multiple nics on that server? If so are all but 1 disabled?

18

sorry, maybe that was a bit misleading or incorrect. Yes, the DC2 does have dual NIC, only one of which is active. The DC2 system had the DHCP role installed/applied today after DC1 failed, and now the DHCP service identifies itself by that 169. address since the role was applied, I’m not sure how or why since it has a working static IP on its working live NIC. And that NIC/IP is also authorized for the DHCP service, and the service is bound to that IP as well.

The DHCP service on the old DC1 identified itself by the hostname. I don’t know where the new service pulled that apipa address from, other than the unused, disconnected NIC. Should I be removing the role/DHCP service and readding it with that unused NIC disabled or removed? It should respond to the requests on the DC2 IP given the service says its authorized and bound to that IP right?

19

Make sure that other nic is actually disabled.

Open the DHCP console and connect to the server. Right click on the server in the left side of the pane and select Add/Remove bindings.

Does it show a check mark next to the actual IP of the server? If not do you have the option to select it?

20

LOL… the above is getting really confusing ??

If DNS service fails and/or DNS data corruption occurs (on a DC or any server), just disable the service, remove the feature, run “ipconfig /flushDNS” & reboot.
After the reboot, add the DNS feature & ensure that the service starts. Then run “IPconfig /registerDNS” especially for DCs. Check the DNS server is working.

Logically you do not need to change the DNS server IP address (even for DCs) as the DNS server IP should have already been set a long time ago when the 2 DCs were setup ?

Then if you are using a physical server or a VM with 2 NICs, what you should be doing is not to disable the 2nd NIC (or 3rd NICs) but create a NIC teaming so that you get only 1 IP address while using 2 NICs or 3 NICs ?