Linux Secure Dynamic DNS Update with Windows DNS

  • Article

Earlier this week I was asked for recommendations on how to register Linux systems in DNS. While the records could be manually entered (or scripted) as static DNS records, it would be ideal if the process were more "dynamic". Windows clients register dynamically why not Linux. There were ideas about DHCP performing DNS registration on behalf of the client, etc.

I responded with "Linux clients can dynamically register in DNS". That statement resulted in a funny look. The person responded with "... no… maybe I didn’t explain… it would be nice if they registered in DNS directly, using secure dynamic updates."

Again… I responded with "…like I said, Linux clients can dynamically register in DNS… Microsoft DNS… configured for secure dynamic updates. Let me explain…"

The System Security Services Daemon (SSSD) for Linux is quickly becomes the foremost method for domain joining Linux systems to Microsoft Active Directory. SSSD has been around since 2008. It is a Fedora hosted project that has recently moved into the mainstream channels / repos. Formerly it could be found in EPEL. It is available for the majority of the mainstream Linux distros (RedHat, CentOS, Fedora, SUSE, Ubuntu, Debian, Gentoo, FreeBSD, etc).

SSSD allows the domain joined Linux clients to perform secure dynamic updates in DNS.

I recommended that the person domain join their systems with SSSD and they would have their dynamic DNS solution.

A day later, they came back with the same problem. "… OK… I followed your instructions and domain joined the first Linux system. It authenticates to AD just fine, but it does not dynamically register in DNS. What did I do wrong?"

So we began to see if ALL the instructions were followed. J

SECURE DYNAMIC UPDATE ZONES

Linux secure dynamic DNS updates using SSSD are based on the understanding that the clients are securely authenticating as themselves (not a user). Since they are securely communicating to Active Directory, SSSD expects to be performing an update to a DNS zone that is configure for Secure only updates.

[caption id="attachment_295" align="alignnone" width="399"]Active Direcctory DNS Zone Properties Active Direcctory DNS Zone Properties for a zone configured for Secure Dynamic Updates[/caption]

Later on, I’ll cover what happens if your zones are NOT secure or are supporting secure and non-secure updates.

To diagnose the issue, we updated the /etc/sssd/sssd.conf file. We set the [domain/<domainfqdn>] debug level to 9. For the most part, any level from 5 and up would be sufficient.

 debug_level = 9

Then we restarted SSSD. The next step was to tail the log and look for the dns communications.

[caption id="attachment_315" align="alignnone" width="1186"]SSSD Domain Log The log can be found at /var/log/sssd/sssd_[domainname].log where [domainname] is the logging facility entry name in the /etc/sssd/sssd.conf file.[/caption]

There were two primary error entries.

  1.  [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [5]: Input/output error

  2.  [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [5]: Input/output error

However… those entries were the effect; not a symptom. The entries that should catch your eye are:

  1.  [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'usmdua8006' in DNS

  2.  [sdap_dyndns_dns_addrs_done] (0x0040): Could not receive list of current addresses [5]: Input/output error

The very KEY item to focus on is the data that is being registered in DNS. The data should be a fully qualified name. In this example, the value 'usmdua8006' is NOT a fully qualified name. 'usmdua8006' is the single label name for the system. That leads us to the hostname. 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.

Viewing this from the DNS server displays the same issue. The DNS server will fail to register a single label record.

[caption id="attachment_305" align="alignnone" width="744"]Frame captured with Network Monitor 3.4 Frame captured with Network Monitor 3.4[/caption]

The solution is that the LINUX hostname must be the fully qualified name.  For example in CentOS 7, use hostnamectl to set the hostname to the FQND.

 hostnamectl set-hostname usmdua8006.contoso.corp

See your distribution specific documentation for setting the hostname properly.

For this example the hostname is updated to the FQDN. The SSSD service is restarted.

[caption id="attachment_325" align="alignnone" width="1181"]SSSD Domain Log The log can be found at /var/log/sssd/sssd_[domainname].log where [domainname] is the logging facility entry name in the /etc/sssd/sssd.conf file.[/caption]

You can see by the log tail that the update is successful.

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.

[caption id="attachment_275" align="alignnone" width="399"]DNS Record Security Properties The DNS record security tab reflects the record owner being the Active Directory computer account (Kerberos principal).[/caption]

[caption id="attachment_345" align="alignnone" width="400"]DNS Host Record Properties The record time stamp indicates that it is a dynamic record versus a static record.[/caption]

Now the problem is resolved.

NON-SECURE DYNAMIC UPDATE ZONES

As discussed earlier, what happens if the DNS zones are configured for "None" or "Nonsecure and Secure"?  This causes an interesting problem.

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.

[caption id="attachment_335" align="alignnone" width="1184"]SSSD Domain Log The log can be found at /var/log/sssd/sssd_[domainname].log where [domainname] is the logging facility entry name in the /etc/sssd/sssd.conf file.[/caption]

The logs will show a failure to update the record with three key entries.

  1.  [sdap_dyndns_update_done] (0x0080): nsupdate failed, retrying with server name

  2.  [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [1432158232]: Dynamic DNS update failed

  3.  [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158232]: Dynamic DNS update failed

While the update failed, you will notice something odd. A DNS record was created. Upon close examination of the record’s security, you will not see the host’s authentication.

[caption id="attachment_285" align="alignnone" width="400"]DNS Host Record Security Note that the DNS record security tab is missing the Active Directory computer account (Kerberos principal).[/caption]

What is even more confusing is the effect you see if the zone is set to "Nonsecure and Secure".  If the zone is set to "None", no update of any kind is done.  If the zone is set to "Nonsecure and Secure" (allowing anonymous updates), every 15 minutes, the DNS record disappears. 15 minutes later it will be back. What is going on?

To understand what happens here, you must look at the design of the DNS update process. As seen in the verbose logs, every 15 minutes (the default),

  1. SSSD will perform a lookup on the host’s record.
  2. If the record exists, SSSD will attempt to delete it
  3. SSSD will send along Kerberos authentication token to use during the registration process (using the rights of the computer account).**
  4. SSSD will issue a new record update registration.
  5. SSSD will send along Kerberos authentication token to use during the registration process (using the rights of the computer account).**

If the zone is nonsecure or set to "none " and the record does NOT exist, at step 3, DNS will create the DNS record (A(host) and PTR). The DNS server will then discard the authentication token as it is not needed (the record was registered… end of process).

SSSD will not get the expected returned response of a successful authenticated update. SSSD will throw and error.

Now, 15 minutes later, the process restarts. However, a record DOES already exist. SSSD will send a delete notification. SSSD will send along the authentication token. DNS will delete the DNS record and discard the authentication token. This unexpected response to SSSD will generate an error. Dynamic DNS processing will stop for that cycle. Because of this, no DNS record is recreated. This means until the NEXT cycle runs in 15 minutes, the client will be unresolvable (and cause great confusion every 15 minutes).

Hopefully this explains a number of scenarios and how to set to proper configuration.  Enjoy your more modern Linux dynamic DNS experience!

**Note – Due to modern DNS client cache, the momentary delete / recreate of the DNS record is not noticed by clients. They will continue to resolve the LINUX host throughout the process.

Comments

  • Anonymous
    March 16, 2017
    The comment has been removed
    • Anonymous
      March 16, 2017
      The comment has been removed
  • Anonymous
    June 15, 2017
    Jeff, Nice article, very detailed explanation of the inner workings of SSSD.Do you have any recommendations on the contents of the SSSD.conf file? So far, I have been letting realm build it for me when I do a realm join. Realm doesn't seem to be picking the best options.
    • Anonymous
      June 16, 2017
      Josh, A detailed domain join posting is on my list.... just need to finish it. What issues are you running into exactly? Are you leveraging the AD domain UID/GID posix attributes (RFC 2307/2307bis) to map to or are you using the AD user SID ( basically is ldap_id_mapping set to true or false)?
      • Anonymous
        July 01, 2017
        Any chance this is coming soon? Need to be able to automate this in an Azure ARM template.