Proposed patch to bring the TTL in line with the ipa-client-install one
sssd-ttl.diff

Patch file suitable for RHEL6
0049-TTL-fix.patch

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=847716 (Red Hat Enterprise Linux 6)

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=847716 847716]

IMHO default TTL should be configurable (and same as in ipa-client-install, of course).

I agree it should be configurable - this was just a quick fix to bring both into line with no configuration cahnges etc that might effect current systems...

I'm planning over the next couple of weeks to contribute to both SSSD and IPA with suitable code to do so ...

I'll create a ticket later to track this (make TTL for updates configurable) and update with progress for a future release there...

Left in NEEDS_TRIAGE for prioritization.

proposed_priority: => Important

Fields changed

milestone: NEEDS_TRIAGE => Temp milestone

Patch was contributed by the reporter and acked on the list.

patch: 0 => 1

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

priority: major => minor

Fields changed

priority: minor => major

Fixed in master: 4fb12db

Fields changed

resolution: => fixed
status: new => closed

Fields changed

description: I have verified this on the current master (was initially discovered on Centos 6.3)...

Steps to reproduce:

1) Add a client to IPA including the --enable-dns-updates argument.
2) Verify that the TTL is 1200 seconds on the record after it has been added as per the value in the ipa-client-install python script.
3) Arrange for the IP address to change in some way on the client.
4) Restart the client
5) Check the TTL of the record on the DNS server - it will now be 86400 instead of 1200.

Although for most use cases 1 day would be fine for a rapid VM churn environment (eg fresh build host created each time in continuous integration or something similar) this could cause incorrect resolution... and is a confusion for the user given the change from the initial TTL put in place... in addition a systems administrator could not override this since the record is deleted and added by SSSD and as a consequence ipa dnsrecord-mod would only have an effect until update and not maintain the TTL afterwards... => I have verified this on the current master (was initially discovered on Centos 6.3)...

Steps to reproduce:

1. Add a client to IPA including the --enable-dns-updates argument.
2. Verify that the TTL is 1200 seconds on the record after it has been added as per the value in the ipa-client-install python script.
3. Arrange for the IP address to change in some way on the client.
4. Restart the client
5. Check the TTL of the record on the DNS server - it will now be 86400 instead of 1200.

Although for most use cases 1 day would be fine for a rapid VM churn environment (eg fresh build host created each time in continuous integration or something similar) this could cause incorrect resolution... and is a confusion for the user given the change from the initial TTL put in place... in addition a systems administrator could not override this since the record is deleted and added by SSSD and as a consequence ipa dnsrecord-mod would only have an effect until update and not maintain the TTL afterwards...
design: =>
design_review: => 0
fedora_test_page: =>

For tickets already closed set the field to "Want"

selected: => Want

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2518

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.