[SSSD] Design Discussion: Active Directory DNS updates

Jakub Hrozek jhrozek at redhat.com
Mon Mar 18 08:46:07 UTC 2013


On Sun, Mar 10, 2013 at 09:46:49AM -0400, Simo Sorce wrote:
> Excellent Design page, comments in line.
> 
> On Fri, 2013-03-08 at 23:15 +0100, Jakub Hrozek wrote:
> > Hi,
> > 
> > I have created a design page to discuss DNS updates of Active Directory
> > clients:
> > https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates
> > 
> > For your convenience, the wiki page is also copied below.  Comments and
> > feedback are appreciated.
> > 
> > == Active Directory client DNS updates ==
> > Related ticket(s):
> > * [https://fedorahosted.org/sssd/ticket/1504 RFE AD dyndns updates]
> > 
> > === Problem Statement ===
> > Clients enrolled to an Active Directory domain may be allowed to update
> > their DNS records stored in AD dynamically. At the same time, Active
> > Directory servers support DNS aging and scavenging, which means that stale
> > DNS records might be removed from AD after a period of inactivity.
> > 
> > While DNS scavenging is not enabled on Active Directory servers by default,
> > the SSSD should support this use case and refresh its DNS records to
> > simulate the behavior of Windows AD clients and keep their address records
> > from being removed if scavenging is used. The SSSD should also enable the
> > clients to update their DNS records if their IP address changes.
> > 
> > === Overview of Windows client side DNS updates ===
> > This section provides a brief overview of how Windows clients may update
> > their DNS records and how scavenging is configured and performed in a
> > Windows domain. For more complete information, please follow the links at
> > the bottom of this page.
> > 
> > ==== Windows Resource Record information ====
> > To be able to detect if the resource record is stale, every dynamically
> > created RR in the Windows DNS has a timestamp that is updated with the
> > dynamic update if scavenging is enabled. Manually created DNS records do
> > not have a timestamp. In order to update the timestamp, the DNS records
> > are refreshed periodically even if they actually haven't changed, just to
> > bump the timestamp.
> > 
> > A special timestamp value of 0 can be set to the resource record, indicating
> > unlimited lifetime of the record. Such record is never scavenged.
> > 
> > ==== Update and refresh ====
> > When a Windows client updates its DNS information, it may perform either an update or a refresh.
> >     * an ''update'' is performed when the IP address of a client
> >       changes. Involves a refresh and a change of the IP address(es).
> >     * a ''refresh'' does not change the IP addresses themselves, but rather
> >       only updates the timestamp of existing resource record, keeping it
> >       from being scavenged.
> >     
> > In order to maintain a heartbeat on the resource records, the Windows
> > clients perform updates and/or refreshes under conditions outlined in the
> > next section.
> > 
> > ==== Scavenging timeouts ====
> > In the zone properties, there are two timeout settings that are affecting the scavenging
> >  * No-refresh interval - minimal interval between last refresh after which
> >    the record can be refreshed again
> >  * Refresh interval - interval during which the refreshes are allowed. After
> >    the refresh interval passes, the stale records can be scavenged. In other
> >    words, the refresh interval starts at `timestamp + no_refresh_interval`.
> > 
> > ==== Windows clients update and refresh intervals ====
> > For Windows clients, refreshes or updates generally occur for the following
> > reasons:
> >  * the computer is restarted
> >  * the DHCP lease is renewed
> >  * periodicaly every 24 hours by default
> >   * this is configurable in the windows registry using
> >     the `DefaultRegistrationRefreshInterval` key under the
> >     `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters`
> >     subkey
> > 
> > The SSSD updates should be modeled to be close to what the Windows clients do.
> > 
> > ==== SSSD clients refresh intervals ====
> > The SSSD would perform the dynamic DNS update or refresh under the following
> > conditions:
> >  * the back end becomes online
> >   * this would also cover the case where computer is restarted. For
> >     long-running deployments where the SSSD is almost never offline, the
> >     back end would only ever become online after bootup
> >  * periodically based on a configuration option
> >   * the configuration option could be named `ad_dyndns_refresh_interval`
> >     or similar and it would default to 24 hours
> >   * the granularity will be hours. AD interface also allows to set the
> >     refresh and no-refresh interval in hours, too, so our granularity should
> >     not be lower. Seconds, on the other hand, seems too granular.
> 
> I think seconds is perfectly fine, even if Windows normally sticks to
> hour granularity. It would allow us to renew faster, like every 1.5
> hours or so if DHCP leases are very short. In general it's not a big
> deal to write hours in seconds.
> 

Fair enough, having to write 86400 instead of 24 was the main reason I
chose hours. I don't really mind.

> >   * admin could change the option to be same as DHCP lease for example to
> >     simulate the case where Windows workstations refresh the address after
> >     lease is renewed
> > 
> > === Overview of the solution ===
> > Because the DNS records scavenging is not on by default on the server
> > side, the client side DNS updates would be off by default as well. A new
> > configuration option, called `ad_dyndns_update` (bool)  would control
> > whether the DNS update should be performed.
> > 
> > ==== Addresses used during the update ====
> > We will reuse a similar mechanism used in the IPA provider where the
> > address used to connect to the AD server LDAP connection is used by
> > default. Optionally, for machines that use IP aliasing or setups that wish
> > to update both IPv4 and IPv6 addresses of an interface at the same time
> > there will be an option `ad_dyndns_iface`.
> > 
> > Contrary to IPA dynamic DNS update that generates the PTR record in the
> > bind dyndb plugin, AD wouldn't update the PTR record on its own when only
> > A/AAAA record is updated. To be able to keep the forward and reverse zones
> > in sync, the AD dynamic update message would also include updating the
> > PTR records. PTR records update would not be on by default and could be
> > turned on by setting an option (perhaps `ad_dyndns_update_ptr`) to true.
> > 
> > ==== Future and optional enhancements ====
> >  * Currently the information on whether scavenging is enabled and how
> >    often is it performed is stored in GPOs. When SSSD has the ability to
> >    process Group Policies, we would add a new special value to the
> >    periodical update option that would tell the SSSD to simply honour the
> >    Group Policies.
> >  * We could also integrate with netlink to perform IP address refresh on DHCP lease renewals. This could be filed as a separate ticket and implemented later.
> > 
> > === Implementation details ===
> > For the update itself, we can simply use the nsupdate utility the way we
> > use it in IPA domain. The update code is already there, it is mostly a
> > matter of splitting the code to be IPA-agnostic.
> > 
> > One change compared to the IPA code would be that IPA only sends the refresh
> > when the addresses change, to avoid unnecessary zone transfers on the IPA
> > server.  As stated above Windows clients typically refresh their address
> > even if nothing changed, so our update code would run unconditionally,
> > too, based on timed events.
> > 
> > 1. The use of `resolv_init` in the dynamic DNS update code should be
> >    inspected. If it is not needed anymore and the resolver code could
> >    already be told per-request to only go to DNS and ignore `/etc/hosts`,
> >    the initialization should be removed.
> > 1. A new module shared between IPA and AD providers shall be created. This
> >    module will contain generic functions related to dynamic DNS update such as:
> >   * a variant of `ipa_dyndns_add_ldap_iface` decoupled from IPA dependencies
> >   * function to gather all addresses of an interface
> >   * utility functions
> > 1. The existing `fork_nsupdate_send` request would be split out to a generic
> >    request that calls nsupdate with a specified message. This request would be
> >    placed in the module created in the previous step. The IPA provider would
> >    be converted to use these new generic request. The interface might look like:
> > {{{
> >     struct tevent_req *be_nsupdate_send(struct tevent_context *ev, const char *nsupdate_msg);
> >     errno_t be_nsupdate_recv(struct tevent_req *req, int *child_retval);
> > }}}
> > 1. In the AD provider, a variant of IPA dyndns code would be created,
> >    using AD specific data structures and options. This interface would
> >    consist of a tevent request that would wrap `fork_nsupdate_send` using
> >    `struct ad_options` and an initializer function called on provider startup.
> > 1. If the `ad_dyndns_update` option was set to `true`, then the AD provider would:
> >  * set up a periodic task running each `ad_dyndns_refresh_interval` hours
> >    updating the DNS records
> >  * set up an online callback to run the DNS update when the back end
> >    goes online
> > 
> > === List of all new configuration options ===
> >  1. `ad_dynds_update` `(bool)` -- whether to perform the dynamic DNS
> >      update. Defaults to false.
> >  1. `ad_dyndns_refresh_interval` `(integer)` - how often to run the periodic
> >      task to refresh the resource record
> >  1. `ad_dyndns_iface` `(string)` - instead of updating the DNS with the
> >      address used to connect to LDAP, which is the default, use all addresses
> >      configured on a particular interface
> >  1. `ad_dyndns_update_ptr` `(bool)` - whether to also update the reverse
> >      zone when updating the forward zone
> 
> I think we can avoid making these options AD specific.
> If you look closely all of them could be used in IPA as well, including
> update_ptr, which we are thikning of introducing now that Petr came up
> with a possible ACI to control PTR updates that is better than the
> automatic sync we built on the server side.
> 
> By using a single set of attributes (just drop the 'ad_' prefix) we can
> keep the code as generic and shared as possible.
> 

I'm all for generic shared code, but then it would sound like even LDAP
provider for instance supports the dynamic updates..also the ipa_
options are already there and we should support them anyway.



More information about the sssd-devel mailing list