On 11.6.2016 21:22, Petr Spacek wrote:
> Hello,
> 
> bind-dyndb-ldap 10.0 alpha 1 is available for testing (finally).
> 
> AFAIK it implements all the critical functionality for FreeIPA 4.4, namely
> RecordGenerator & default TTL support necessary for FreeIPA DNS locations.
> 
> 
> Limitations
> ===========
> BIND has to be reloaded ("rndc reload" at least) after each change in server's
> config or zone's default TTL.
> 
> In case of FreeIPA it means that server-mod command which touches server's DNS
> location has to be followed by "rndc reload" on the affected replica.
> 
> 
> Outlook
> =======
> I'm looking for a solution for quite a while now but it is an asynchronous
> parallel event hell.
> 
> We will probably end up with big hammer like "reconnect to LDAP and re-parse
> everything". Most likely it will be error prone and racy (think about DNS
> updates in the middle of re-synchronization) but any fine-grained approaches
> seem to be even more fragile and even racier. Yuck.

Detailed analysis revealed that even 'reconnect to LDAP and re-parse
everything' hammer is unreliable and we do not have enough time to fix it.
Fixing it would require major refactoring of bind-dyndb-ldap internals.


Following alternative was considered, too:
Extend ipa-dnskeysyncd (daemon in Python) to trigger named restart when
particular attributes in LDAP are modified.

Unfortunately automatic restart could easily cause global DNS failure if e.g.
a script was used to modify locations on multiple IPA servers.

The main problem is that bind-dyndb-ldap start (and also shutdown) takes some
time if the LDAP database is not empty. During that time request are either
not answered at all or are being answered with NXDOMAIN answer.

For database with 3 DNS zones, 1 small (primary IPA domain) and 2 filled with
64k A records (1 record / name) it takes ~ 20 seconds to load the data and 60
seconds to shutdown the BIND. I.e. one restart means ~ 80 seconds of outage.

Plan
====
For this reason me and Petr Vobornik decided against automatic restart. Next
version of FreeIPA will issue a warning that admin has to manually restart
named on affected servers.


Comments are welcome.

Petr^2 Spacek


> Implemented designs
> ===================
> - https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator
> - https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/PerServerConfigInLDAP
> 
> Fixed tickets
> =============
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/126
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/162
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/70
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/164
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/165
> - https://fedorahosted.org/bind-dyndb-ldap/ticket/146
> 
> COPR packages
> =============
> https://copr.fedorainfracloud.org/coprs/pspacek/bind-dyndb-ldap/build/339004/
> 
> SRPM
> ====
> https://pspacek.fedorapeople.org/bind-dyndb-ldap/bind-dyndb-ldap-10.0-0.1alpha.fc23.src.rpm
> 
> Git branch
> ==========
> https://github.com/pspacek/bind-dyndb-ldap/tree/server_config_in_ldap4
> 
> Git commit
> ==========
> 6722382b2344fd5acd6ba9fa858c139c16e3de99
> 
> 
> Enjoy.
> 


-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to