none
Lots of Errors in DHCP Event Log - 20317 and 20320 RRS feed

  • Question

  • I've recently moved our DHCP to a new server as we've built new Server 2016 DCs and decommissioned the old.

    I've noticed I'm getting an awful lot of errors logged in event viewer around 2 areas in particular;

    Error 20317

    • Forward record registration for IPv4 address [[10.100.2.16]] and FQDN Galaxy-A5-2017becca.DOMAIN.INTERNAL failed with error SERV_FAIL. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.

    This is then followed by

    Error 20320

    • PTR record registration for IPv4 address [[10.100.2.16]] and FQDN Galaxy-A5-2017becca.DOMAIN.INTERNAL failed with error SERV_FAIL. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.

    One thing to note is this only happens from our DHCP Scope that serves BYOD.  Secure updates are enabled on the DNS forward lookup zone and we do have the following Reverse Lookup Zones;

    • 10.in-addr.arpa
    • 168.192.in-addr.arpa
    • 25.172.in-addr.arpa

    Aswell as the default 0., 127. and 255.

    Have read various articles around DHCP, I've populated the DHCP credentials with a Domain Administrator account to test, but nothing appears to be getting rid of these errors.  And as it's BYOD I get tons of them a day.

    Any ideas what could be causing it?

    • Edited by Mr Killian Friday, November 10, 2017 1:31 PM
    Friday, November 10, 2017 1:31 PM

All replies

  • Hi Mr Killian,

    As far as I know,Dynamic DNS updates are attempts to update the PTR record, which is often done in conjunction with HOST A record update. In order to send a PTR update an SOA query is made first for the reverse record for the host to see who is authoritative to accept the update.

    In case the DNS Server does not have a reverse lookup zone, an error sent back to the DHCP server is interpreted as a general update failure, and this would cause re-queuing of the update request at the DHCP server, eventually causing a queue build-up.

    >> Secure updates are enabled on the DNS forward lookup zone and we do have the following Reverse Lookup Zones

    DHCP has ownership of the Forward and Reverse entries in DNS,please refer to the following link to ensure that the DHCP Server has the ability to update the DNS:

    https://blogs.msmvps.com/acefekay/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-timestamps-and-the-dnsproxyupdate-group/

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, November 13, 2017 6:55 AM
  • Hi Mr Killian,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 14, 2017 7:05 AM
  • Hi Mr Killian,

    Did you have any updates?

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 16, 2017 8:16 AM
  • Apologies Candy, my son has been unwell so I haven't been in.

    I did make some of the changes suggested by the post however it doesn't look to have resolved it yet.  I suspect this may have to do with the hosts owning the records rather than DHCP.  Assuming I may need to clear out all host names (except those created manually - is there any way to tell this actually?) and let DHCP register them?

    New error log now looks like this;

    • The DNS registration for DHCPv4 Client IP address 10.100.0.61 , FQDN Robs-IPhone-2.DOMAIN.INTERNAL and DHCID AAEBiGeSvHj+R5h2geMvpQkSzpnHSGxi+HkumFbCOlKA/Mc= has been denied as there is probably an existing client with same FQDN already registered with DNS.

    • Forward record registration for IPv4 address [[10.100.0.61]] and FQDN Robs-IPhone-2.DOMAIN.INTERNAL failed with error SERV_FAIL. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.

    • PTR record registration for IPv4 address [[10.100.0.61]] and FQDN Robs-IPhone-2.DOMAIN.INTERNAL failed with error SERV_FAIL. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.

    Friday, November 17, 2017 9:10 AM
  • Hi Mr Killian,

    Thanks for your updating.

    This is a quick note to let you know that I am currently performing research on this issue and will get back to you as soon as possible. I appreciate your patience.

    If you have any updates during this process, please feel free to let me know.

    Best Regards,

    Candy



    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, November 20, 2017 9:54 AM
  • Hi ,

    Is the Secure Updates Only enabled on the zone?

    Have you tried to add the DHCP Server object in Active Directory to the DnsUpdateProxy group and then check again?

    Please check if the following link is helpful:

    Dynamic DNS registration process can cause queue build up and failures

    https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 23, 2017 7:44 AM
  • Hi ,

    Did you have any updates?

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 28, 2017 1:30 AM