Migrated DCs to 2019 getting numerous 20319 Events

[Troy Davis]

Just migrated DCs over to 2019 and I'm seeing a large number of Event 20319 Name Registration with the user NETWORK SERVICE.

"Forward record registration for IPv4 address [[x.x.x.x]] and FQDN CompName.domain.local failed with error 9005 (DNS operation refused."

This almost seems like NETWORK SERVICE needs to have some sort of permissions somewhere that I'm not finding in my google searches.

When I migrated, I deleted all DHCP leases to force them all to get new, and I can see them all in DNS (even reverse lookup zone they are listed).  - Should I have deleted them out of the reverse zone as well?  Maybe that's the problem?

PDC - DHCP, DNS, all FSMO

SDC - DHCP (hot spare), DNS, GC

Option 006 I have both DCs listed, I have DHCP credentials set up (nothing has changed from the previous DC and the account isn't locked)

[#2]

I'd check if the reverse zone for this network subnet even exists.

[#3]

@Dave Patrick 

Please see the above screenshot showing the reverse zone exists as well as the tag that is referenced in the one event is listed in the reverse zone...

[#4]

I see that but we cannot tell from what you posted that it is correct for the network and mask so might try recreating the zone.

[#5]

@Dave Patrick 

Thanks for the reply btw...what more information would you need to determine if it is the correct reverse zone?

[#6]

Some examples here for classful and classless subnets.

https://support.microsoft.com/en-us/help/174419/how-to-configure-a-subnetted-reverse-lookup-zone-on-...

[#7]

@Dave Patrick 

I guess I don't understand what you are trying to say.  I was asking what you wanted me to show you or tell you to determine if it was correct?  Sorry if I'm being dense today.

Everything migrated over from the old 2012R2 DC w/out issue.  Same reverse zone and everything that was on the old PDC/SDC.  Is there some sort of permissions that NETWORK SERVICE should have to update DNS or is that all handled by the DHCP User credentials that is set up.  Because as you can see from the screenshot, the reverse record is being updated (the migration took place on 08/10/2019).  So I'm at a loss as to why they are being updated, yet I'm getting those events.

Reverse Lookup Zones container have the following:

0.in-addr.arpa

127.in-addr.arpa

255.in-addr.arpa

xx.xx.xx.in-addr.arpa

[#8]

---

I guess I don't understand what you are trying to say. 

---

You asked what information? So I was just providing some insight. Might also check this one.

https://blogs.technet.microsoft.com/poshchap/2016/03/11/configure-dns-dynamic-update-credentials-for...

[#9]

@Dave Patrick 

You made the comment [quote]I see that but we cannot tell from what you posted that it is correct for the network and mask so might try recreating the zone.[/quote]

That's what I was responding to, wondering what information you required to tell if it was correct for the network/mask...

As far as your link...I already have that set up

Everything was working prior to the cut over.  Migration went well, no issues with promo and data sync.  Set the DNS dynamic update credentials and everything works as my users aren't having any issues, I can ping/connect to computers.  I'm not seeing these errors on my SDC, but I'm assuming that's because it is only in Hot Spare...which...that is the only difference...prior I had my DCs in load balancing for DHCP, I switched it over to Hot Spare this time.  Other than that, that's all I can see that I've changed.  

So you don't think there is a permission anywhere for NETWORK SERVICE?  I just restored my old PDC to my test lab and I'm not seeing anything different...

...again, thank you for your replies.

[#10]

Ok, I get it now, you're replying two posts back. I guess you're wanting something concrete here without trying anything. For that I'd suggest starting a case here with product support where you can screen share, etc. so they can look directly at things. Something not possible here in forums.

https://support.microsoft.com/en-us/hub/4343728/support-for-business

[#11]

@Dave Patrick 

Never said I wouldn't try anything.  The only thing you've suggested that I don't already have done is to recreate the zone.  I was just trying to clarify what it is that you were saying about not having enough information.  I was just trying to give that to you so you have whatever it is you needed to give more indepth suggestions on what to do to resolve this other than recreating the reverse lookup zone.

Am I in the wrong forum to discuss possible fixes?  Sorry if that's the case.

[#12 · Accepted solution]

Actually think I just figured it out.  Seems I forgot to update the DnsUpdateProxy Security Group with the new DCs.

One thing I also noticed was that the computers that kept showing up in the 20319 events all had their computer account instead of the DHCP Update account having permissions on its DNS entry. Deleted the computer and added DHCP Update with the same rights as all the other computers that did have DHCP Update...released/renewed and all seems to be well. 

So, I'm going to mark the solution as the following:  make sure all is set up according to https://blogs.msmvps.com/acefekay/2016/08/13/dynamic-dns-updates-how-to-get-it-to-work-with-dhcp-sca...

This is where I noticed that I forgot to update the DnsUpdateProxy SG with the new DCs.  Then, on the problematic computer's DNS entry, I had to manually delete the computer account permissions and add the DHCP Update credential permissions.  When I released/renewed, I no longer had the 20319 events.