RHEL6, Active Directory and Dynamic DNS

Latest response

I have a scripted Active Directory configuration, using Winbind, Samba and SSSD, then running adcli and net join commands, which allows me to use AD for user authentication.

Registering a Red Hat box also results in a Dynamic DNS entry being created in the Wintel infrastructure, which is all good, too.

However, the Dynamic DNS entry expires after 14 days ("DNS Scavenging", they seem to call it in the Wintel world). I would have assumed that winbindd would send the same DNS updates that a Wintel client does, but it seems not.

I have found the nsupdate tool (and the -g switch to it), but can't find how to send the correct authentication details with it - what does anybody here do with RHEL6 and Active Directory?


Same problem here, tried the nsupdate as well without success. The only workaround is to change the DNS entry to static, which won't solve the problem, but at least doesn't let DNS to delete the record(s).


I am pretty certain this is related to the fact that when joining to the domain, the record is not regularly refreshed/updated by SSSD (same issue exists with machine account passwords).

I detailed the issue here (specifically how machine accounts are set to no-expire as a 'workaround'):

I have switched to using IPAM with static DNS record creation to resolve this issue.

Just had this bite me again in RHEL 7.2. I have a scenario where realm join is doing the initial dynamic update (have confirmed this with a packet capture), but it appears SSSD isn't updating the record after this, resulting in the scavenging behaviour discussed in the original post.

This seems contrary to the documentation that ships with SSSD in RHEL 7. There is a slide deck from FreeIPA specifically on the subject that states that the dynamic DNS update will update the server periodically by default (in 1.11):


Slide 8 states "dyndns_update" "enabled by default", and the following:

enables automatic DNS updates in Active Directory DNS server 
with IP address of sssd client

Has anyone else had issues with the dynDNS not being periodically updated?


Interestingly the man page for sssd.conf that ships with 1.13 contains no mention of the dyndns options? is this an oversight?

+1 to this issue -- I've experienced it (and continue to) on RHEL6 and 7 -- Solution at this point is to static everything, but it's not without it's issues.

As I posted above (in 2015), we have given up on this capability and have moved everything to static. Almost two years later and this is still how we are working around the issue (even in 7.3).

As part of our migration to 7 (currently 7.3), this has been giving us a real headache and holding up deployment into production. The main problem for us has been PTR records disappearing long before the scavenge interval. I think I've tracked this one down, which I thought I'd share. It might help someone out there.

DNS server configuration is two Windows 2K12R2 DCs using AD zones. Each server reports itself as the master server in its SOA record which I understand is best-practice.

The thing which sunk us is we were running dnsmasq as a caching name server on the clients, critically with the "all-servers" option.

SSSD 1.14.0 (RHEL 7.3) refreshes PTR records by deleting them with nsupdate -g, and then recreating them with a subsequent and separate call to nsupdate -g. You can see this by turning up the SSD logging to 6. Sadly, what the logging won't tell you is which DNS server nsupdate picks to send its update to!

With the local dnsmasq "all-servers" option set, and the SOA records configured as described, we've caught the two invocations of nsupdate picking different servers to delete and recreate the PTR record. It's a classic race condition. If the 1st message (delete) gets sent to a busy server, it seems it can get actioned after the 2nd message (add) has been processed by the less busy server. The result is the PTR record vanishes.

The client reports no errors. On the DNS servers, only a delete operation is logged.

So to anyone else in the same boat having probs, I'd suggest checking any local DNS caching you may have enabled.