The myth with DHCP, AD-integrated DNS, DNSUpdateProxy etc RRS feed

  • Question

  • Hello community,

    after searching several days for answers and solutions and after different statements I'm really tired :-(


    In our environment we use Microsoft DHCP (2012 R2) to serve clients (windows and non-windows) with IP's. AD-joined windows-clients are registering themself in DNS (AD-integrated) and this is working fine. Now we notice some strange behaviour with non-windows-clients like MAC, Linux etc. Partially they're getting no DNS-entry or extremly delayed (hours later). I've checked DHCP-Log (C:\Windows\system32\dhcp\) and I see a lot of entries with:

    31,03/23/17,11:33:18,DNS Update Failed,,hostname.domain.local,,,0,6,,,,,,,,,2

    Yesterday I was playing around with my test-client (ubuntu) and tried different solutions with no success. There was no dns-entry created. This morning when I came to work, suddenly I found a dns-entry with a timestamp from yesterday 10pm (when my test-client was offline!). So it seems there is a huge delay. But we have no replication issues (repadmin /replsum and dcdiag is fine!)

    My Setup:

    • Active Directory on Windows Server 2012 R2 DC's
    • AD integrated DNS
    • Windows Server 2012 R2 DHCP
    • DHCP is configured with credentials (IPv4 -> Properties -> Advanced -> Credentials) to dynamic update DNS
    • DHCP-computer-account is member of DNSUpdateProxy-group

    My questions:

    1. does the user-account (configured in DHCP to update dynamic DNS) need to be member of DNSUpdateProxy-group? I can't find any official reference and in some blog-post they write YES and in some other they say NO
    2. I cannot find "DNSUpdateProxy"-group in security-tab of my DNS-Zones. Even I cannot find this group in a clean and brand new deployed test-lab! Or is that group somewhere set deep in the configuration and cannot be modified?
    3. If I have to set manually rights to my DNS-zones -> which rights do I have to setup and for which account/group?
    4. Regarding the delay at creating there any possibility to check if there is a queue?

    What can I do?!

    Every help is appreciated!
    Thank you

    Thursday, March 23, 2017 11:17 AM

All replies

  • Hi Miranda,

    In answer to your questions:

    1) The user account shouldn't be in that group, just the DHCP server/s.

    2) Its an AD group and membership is managed as you'd manage any other group.

    3) You shouldn't need to do this.

    4) I'm not sure on this one, I'd have to check.

    Is the problem affecting all non-Windows machines or just some?  Can you please check you have Name Protection enable (it should be by default I believe) -  If it is enabled and your non-Windows machines have the same hostnames as Windows machines, that would prevent them getting registered in DNS.  

    If you try and register a non-Windows client in DNS, is there a local DNS on site you can connect to to see if the update has appeared?

    Thursday, March 23, 2017 1:40 PM
  • Hi,

    2) I know it's an AD-Group, but normally the group should be visible on the security of DNS-zones, so I can reproduce which rights the group has on dns-zones...

    4) Name-protection is enabled. The non-windows-clients do have another naming-scheme so there are no duplicate hostnames. Normally the DHCP-server should register the non-windows-clients in dns via his membership in DNSUpdateProxy and due to the credentials. But again - yesterday the dns-record was created hours later (when my test-client was off and I was not longer in the office)...its weired


    Thursday, March 23, 2017 2:22 PM
  • Hi,

    There is no 'bad address' or anything logged in the DHCP console for the non-Win machines is there and the machines are all obtaining IPs correctly yeah?

    In your DHCP logs are all the failures error code 31 or are you getting different ones too?  Is there anything else useful in the event logs on the DNS and DHCP servers?

    Is DHCP installed on a DC?  If so, then I think the DHCP service inherits the security permissions of the DC.  Instead you should set up a dedicated service account with a strong password and not set to expire.   I think the account just needs domain user permissions, nothing special.  Then use that to authenticate DHCP.

    • Edited by Stu Cousins Thursday, March 23, 2017 7:29 PM extra info added
    • Proposed as answer by John Lii Monday, April 10, 2017 10:17 AM
    Thursday, March 23, 2017 7:09 PM
  • Hi,

    Just want to confirm the current situations.

    Please feel free to let us know if you need further assistance.

    Best Regards,


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

    Monday, April 10, 2017 10:17 AM