Hide Forgot
Description of problem: Right now upstream bind-dyndb-ldap supports persistent search only for zones. That allows the name server to immediately read new/modified DNS zones when they are added/removed from LDAP. We would need to extend this feature also for DNS records so that records in given zone (for example A record for foo.example.com in zone example.com) or records directly in zone (for example MX record directly in zone example.com) are immediately loaded when they are changed in LDAP. Actual results: Record is changed but its resolvable after the record validity expires. Expected results: Changed record is immediately res Additional info:
This bug has been created as a RFE based on #689637 which has been fixed as documentation fix for now. This new feature would enable us to have a more convenient solution for the users and have any changed DNS record immediately resolvable (and do not have to wait for bind-dyndb-ldap cache ttl).
Update for the state of the current upstream persistent search feature: The zone-only persistent search has been improved so that DNS records directly in the zone (MX record directly in zone example.com) as in https://bugzilla.redhat.com/show_bug.cgi?id=689637 are updated in the name server immediately. This would solve 689637 (and its duplicates) completely when released for RHEL. Implementing a full persistent search would allow us to get immediate changes not only for zone records, but standard records too.
There is a bunch of upstream tickets about persistent search: https://fedorahosted.org/bind-dyndb-ldap/ticket/44 https://fedorahosted.org/bind-dyndb-ldap/ticket/40 https://fedorahosted.org/bind-dyndb-ldap/ticket/57 Optimization only tickets: https://fedorahosted.org/bind-dyndb-ldap/ticket/37 https://fedorahosted.org/bind-dyndb-ldap/ticket/41
Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/9a5c2090eb996f131a6d96e997b0db8e762716ba
Moving back to ASSIGNED, I did not notice that this upstream ticket is just a part of solution.
Another psearch bugs are: https://fedorahosted.org/bind-dyndb-ldap/ticket/32 (closed) https://fedorahosted.org/bind-dyndb-ldap/ticket/53 (blocks this bug) https://fedorahosted.org/bind-dyndb-ldap/ticket/72
Upstream ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/73
Verified using: ipa-server-3.0.0-8.el6.x86_64 tests for psearch pass: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-dns-psearch-01 psearch is enabled when ipa server is installed :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ PASS ] :: File '/etc/named.conf' should contain 'psearch yes' :: [ LOG ] :: Duration: 0s :: [ LOG ] :: Assertions: 1 good, 0 bad :: [ PASS ] :: RESULT: ipa-dns-psearch-01 psearch is enabled when ipa server is installed :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-dns-psearch-02 create a new zone and check the zone with dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Executing: ipa dnszone-add --name-server=ipaqavmh.testrelm.com. --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 westford.testrelm.com :: [ PASS ] :: Create a new zone :: [ LOG ] :: Executing: dig westford.testrelm.com SOA | grep NS | grep ipaqavmh.testrelm.com. :: [ PASS ] :: checking with dig to ensure that the new zone got created with the correct name server :: [ LOG ] :: Duration: 3s :: [ LOG ] :: Assertions: 2 good, 0 bad :: [ PASS ] :: RESULT: ipa-dns-psearch-02 create a new zone and check the zone with dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-dns-psearch-03 add record of type txt and check the record with dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Executing: ipa dnsrecord-add westford.testrelm.com txt --txt-rec none=1.2.3.4 :: [ PASS ] :: add record type txt :: [ LOG ] :: Executing: dig txt.westford.testrelm.com TXT | grep none=1.2.3.4 :: [ PASS ] :: make sure dig can find the txt record :: [ LOG ] :: Duration: 2s :: [ LOG ] :: Assertions: 2 good, 0 bad :: [ PASS ] :: RESULT: ipa-dns-psearch-03 add record of type txt and check the record with dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-dns-psearch-04 update record's txt value and check using dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Executing: ipa dnsrecord-mod westford.testrelm.com txt --txt-rec=none=1.2.3.4 --txt-data=newip=5.6.7.8 :: [ PASS ] :: modify record type txt :: [ LOG ] :: Executing: dig txt.westford.testrelm.com TXT | grep newip=5.6.7.8 :: [ PASS ] :: make sure dig can find updated txt record :: [ LOG ] :: Duration: 3s :: [ LOG ] :: Assertions: 2 good, 0 bad :: [ PASS ] :: RESULT: ipa-dns-psearch-04 update record's txt value and check using dig :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: ipa-dns-psearch-05 update record's txt value again and check zone has a new serial that is higher than previous serial :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Executing: ipa dnsrecord-mod westford.testrelm.com txt --txt-rec=newip=5.6.7.8 --txt-data=newip=8.7.6.5 :: [ PASS ] :: update record type txt :: [ PASS ] :: new serial after updating record is higher. Was: 2010010704; New: 2010010705 :: [ LOG ] :: Duration: 2s :: [ LOG ] :: Assertions: 2 good, 0 bad :: [ PASS ] :: RESULT: ipa-dns-psearch-05 update record's txt value again and check zone has a new serial that is higher than previous serial
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0359.html