Ms dhcp not updating dns
If you look in Microsoft DNS, you will see that the record is created.
Upon close inspection of the security (Advanced view), you will see that the Linux host itself (as seen by its Kerberos principle name / computer object name), registered the record. NON-SECURE DYNAMIC UPDATE ZONES As discussed earlier, what happens if the DNS zones are configured for "None" or "Nonsecure and Secure"? In both scenarios, where we set the DNS zone to either None" or "Nonsecure and Secure", we will see a correctly formatted fully qualified name but then see a failure. DNS will delete the DNS record and discard the authentication token. This means until the NEXT cycle runs in 15 minutes, the client will be unresolvable (and cause great confusion every 15 minutes).
'usmdua8006' is the single label name for the system. A hostname can be a single label name of a node on a network or it can be a fully qualified name (example: 'usmdua8006.contoso.corp') If you look in the screenshot above, you will see that the LINUX hostname is a single label name.
DNS forward and reverse lookup zones accept secure dynamic updates only.
Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Visit Stack Exchange I'm afraid that you're going to have to approach this from the client end.
Windows clients register dynamically why not Linux. I responded with "…like I said, Linux clients can dynamically register in DNS… SSSD allows the domain joined Linux clients to perform secure dynamic updates in DNS. It authenticates to AD just fine, but it does not dynamically register in DNS. " So we began to see if ALL the instructions were followed.
There were ideas about DHCP performing DNS registration on behalf of the client, etc. I recommended that the person domain join their systems with SSSD and they would have their dynamic DNS solution. Linux secure dynamic DNS updates using SSSD are based on the understanding that the clients are securely authenticating as themselves (not a user).
What is even more confusing is the effect you see if the zone is set to "Nonsecure and Secure". This unexpected response to SSSD will generate an error. Hopefully this explains a number of scenarios and how to set to proper configuration.