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. * 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
=== How to test === 1. Test that forward and reverse zone updates work * Make sure DNS updates are enabled on the zone * Right-click the zone and select the "General" tab * There is a combo-box labeled "Dynamic updates". Toggle it to "Secure only". * Click "Apply" * Prepare a client with dynamically updated DNS address * the easiest way is to join the client with realmd - `realm join ad.domain.example.com` * Test updates when the address has changed * Change the address of a client * Perform an action that would trigger an online callback such as login * In the AD MMC check if the DNS address is the same as the new address on the client * Depending on the settings of `ad_dyndns_iface` or `ad_dyndns_update_ptr` also check if all expected addresses have been updated in both forward and reverse zones. * Test periodic refresh * Set the periodic refresh (`ad_dyndns_refresh_interval` in this document) to some low value * Wait until that value passes or modify the system time * The timestamp of the resource records would be changed after SSSD ran its periodic task 1. Test DNS scavenging * Enroll two SSSD clients into AD * Turn one of them off after enrollment. This client will be scavenged. * Let the other one up and set its `ad_dyndns_refresh_interval` to a value shorter than the scavenging interval * Enable DNS scavenging on the server * In the DNS MMC console, right-click the DNS server in the tree view, select Properties and navigate to the "Advanced" tab * Enable the "Enable automatic scavenging of stale records" toggle and select a meaningful period * Hit apply * Enable DNS scavenging for the zone * Open the DNS administrative console * Right-click the zone and select the "General" tab. * Click the "Aging" button * Enable the "Scavenge stale resource records" toggle * Set the no refresh and refresh interval to a low value. * Check the "This zone can be scavenged after" text box. It should list a date and time shortly in the future. * Let the scavenging interval pass * The client that was turned off after enrollment should be scavenged. You should no longer be able to see its records in the DNS zones on the server. * The other client's DNS records should remain intact in the DNS MMC console
=== Links and recources === * [http://technet.microsoft.com/en-us/library/cc759204%28v=ws.10%29.aspx Understanding aging and scavenging] * [http://technet.microsoft.com/en-us/library/cc757041%28v=ws.10%29.aspx Using DNS Aging and Scavenging] * [http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-... Don't be afraid of DNS Scavenging. Just be patient. by MSFT Networking Team]
=== Author(s) === * Jakub Hrozek jhrozek@redhat.com
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.
- 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.
- 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.
- 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
- 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); }}}
- 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.
- 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 ===
- `ad_dynds_update` `(bool)` -- whether to perform the dynamic DNS update. Defaults to false.
- `ad_dyndns_refresh_interval` `(integer)` - how often to run the periodic task to refresh the resource record
- `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
- `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.
=== How to test ===
- Test that forward and reverse zone updates work
- Make sure DNS updates are enabled on the zone
- Right-click the zone and select the "General" tab
- There is a combo-box labeled "Dynamic updates". Toggle it to "Secure only".
- Click "Apply"
- Prepare a client with dynamically updated DNS address
- the easiest way is to join the client with realmd - `realm join ad.domain.example.com`
- Test updates when the address has changed
- Change the address of a client
- Perform an action that would trigger an online callback such as login
- In the AD MMC check if the DNS address is the same as the new address on the client
- Depending on the settings of `ad_dyndns_iface` or `ad_dyndns_update_ptr` also check if all expected addresses have been updated in both forward and reverse zones.
- Test periodic refresh
- Set the periodic refresh (`ad_dyndns_refresh_interval` in this document) to some low value
- Wait until that value passes or modify the system time
- The timestamp of the resource records would be changed after SSSD ran its periodic task
- Test DNS scavenging
- Enroll two SSSD clients into AD
- Turn one of them off after enrollment. This client will be scavenged.
- Let the other one up and set its `ad_dyndns_refresh_interval` to a value shorter than the scavenging interval
- Enable DNS scavenging on the server
- In the DNS MMC console, right-click the DNS server in the tree view, select Properties and navigate to the "Advanced" tab
- Enable the "Enable automatic scavenging of stale records" toggle and select a meaningful period
- Hit apply
- Enable DNS scavenging for the zone
- Open the DNS administrative console
- Right-click the zone and select the "General" tab.
- Click the "Aging" button
- Enable the "Scavenge stale resource records" toggle
- Set the no refresh and refresh interval to a low value.
- Check the "This zone can be scavenged after" text box. It should list a date and time shortly in the future.
- Let the scavenging interval pass
- The client that was turned off after enrollment should be scavenged. You should no longer be able to see its records in the DNS zones on the server.
- The other client's DNS records should remain intact in the DNS MMC console
=== Links and recources ===
- [http://technet.microsoft.com/en-us/library/cc759204%28v=ws.10%29.aspx Understanding aging and scavenging]
- [http://technet.microsoft.com/en-us/library/cc757041%28v=ws.10%29.aspx Using DNS Aging and Scavenging]
- [http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-... Don't be afraid of DNS Scavenging. Just be patient. by MSFT Networking Team]
=== Author(s) ===
- Jakub Hrozek jhrozek@redhat.com
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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.
- 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.
- 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
- 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); }}}
- 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.
- 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 ===
- `ad_dynds_update` `(bool)` -- whether to perform the dynamic DNS update. Defaults to false.
- `ad_dyndns_refresh_interval` `(integer)` - how often to run the periodic task to refresh the resource record
- `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
- `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.
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
also the ipa_ options are already there and we should support them anyway.
Yes but that is easy we can alias the old configuration options onto the new ones for the IPA backend.
Simo.
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
also the ipa_ options are already there and we should support them anyway.
Yes but that is easy we can alias the old configuration options onto the new ones for the IPA backend.
OK, what would you suggest would be documented in manpages, then? Only the new options with IPA manpage also carrying a note that also the old options are supported for backwards compatibility?
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
also the ipa_ options are already there and we should support them anyway.
Yes but that is easy we can alias the old configuration options onto the new ones for the IPA backend.
OK, what would you suggest would be documented in manpages, then? Only the new options with IPA manpage also carrying a note that also the old options are supported for backwards compatibility?
Probably the right way to go, yeah.
Simo.
On Mon, Mar 18, 2013 at 10:27:13AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
OK, but we need to document that setting these options only has effect for the AD and IPA providers.
also the ipa_ options are already there and we should support them anyway.
Yes but that is easy we can alias the old configuration options onto the new ones for the IPA backend.
OK, what would you suggest would be documented in manpages, then? Only the new options with IPA manpage also carrying a note that also the old options are supported for backwards compatibility?
Probably the right way to go, yeah.
I've amended the design page. You can view the diff here: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates?acti...
And the full page here: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates
On Mon, 2013-03-18 at 18:47 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 10:27:13AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
OK, but we need to document that setting these options only has effect for the AD and IPA providers.
Any reason why we cannot make it work with arbitrary backends ?
Simo.
On Mon, Mar 18, 2013 at 02:25:15PM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 18:47 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 10:27:13AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote:
I'm all for generic shared code, but then it would sound like even LDAP provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
OK, but we need to document that setting these options only has effect for the AD and IPA providers.
Any reason why we cannot make it work with arbitrary backends ?
How about authentication? Do you think it is reasonable to always presume GSS-TSIG? I'm afraid that going this way would force us to support a whole array of weird configuration and authentication options for all kinds of homebrew server configurations.
On Mon, 2013-03-18 at 20:04 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 02:25:15PM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 18:47 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 10:27:13AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote: > > I'm all for generic shared code, but then it would sound like even > LDAP > provider for instance supports the dynamic updates..
This would be a positive feature imo.
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
OK, but we need to document that setting these options only has effect for the AD and IPA providers.
Any reason why we cannot make it work with arbitrary backends ?
How about authentication? Do you think it is reasonable to always presume GSS-TSIG? I'm afraid that going this way would force us to support a whole array of weird configuration and authentication options for all kinds of homebrew server configurations.
Well there are only 3 options: GSS-TSIG or TSIG or non-signed updates. I guess we can have an option to mark what we'll be using and start supporting only GSS-TSIG and non-signed.
I do not think we need to support TSIG right now, we could and it would only add the need to point to a secret key, but we can leave it out for now I think.
Simo.
On Mon, Mar 18, 2013 at 03:21:39PM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 20:04 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 02:25:15PM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 18:47 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 10:27:13AM -0400, Simo Sorce wrote:
On Mon, 2013-03-18 at 15:09 +0100, Jakub Hrozek wrote:
On Mon, Mar 18, 2013 at 08:29:48AM -0400, Simo Sorce wrote: > On Mon, 2013-03-18 at 09:46 +0100, Jakub Hrozek wrote: > > > > I'm all for generic shared code, but then it would sound like even > > LDAP > > provider for instance supports the dynamic updates.. > > This would be a positive feature imo. >
Yes, but I was trying to say that given their provider-agnostic names, the options might confuse the user into setting them in an LDAP provider and expeciting them to work, while in reality only AD and IPA would be implemented.
I think it should a generic provider and AD and IPA should just have different defaults, like with many other things.
OK, but we need to document that setting these options only has effect for the AD and IPA providers.
Any reason why we cannot make it work with arbitrary backends ?
How about authentication? Do you think it is reasonable to always presume GSS-TSIG? I'm afraid that going this way would force us to support a whole array of weird configuration and authentication options for all kinds of homebrew server configurations.
Well there are only 3 options: GSS-TSIG or TSIG or non-signed updates. I guess we can have an option to mark what we'll be using and start supporting only GSS-TSIG and non-signed.
I do not think we need to support TSIG right now, we could and it would only add the need to point to a secret key, but we can leave it out for now I think.
OK, in general this plan sounds good. I have amended the design page again: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates?acti...
The other concern I have is the time constraints. I would rather focus on having the infrastructure ready and well tested in all providers for 1.10 but only rigorously testing and documenting the options in IPA and man AD for 1.10 as stated in the design page. Or alternatively, including the support as an experimental feature which wouldn't turn up in Fedora in RHEL but could enabled with a simple configure switch.
On Mon, Mar 18, 2013 at 08:56:01PM +0100, Jakub Hrozek wrote:
OK, in general this plan sounds good. I have amended the design page again: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates?acti...
Sorry, that edit was incomplete. Please see this link: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryDNSUpdates?acti...
sssd-devel@lists.fedorahosted.org