On 08/19/2011 06:49 AM, Martin Kosek wrote:
> On Tue, 2011-08-16 at 10:59 +0200, Martin Kosek wrote:
>> On Mon, 2011-08-15 at 10:22 -0400, Dmitri Pal wrote:
>>> On 08/15/2011 08:20 AM, Martin Kosek wrote: 
>>>> A new version of bind-dyndb-ldap has been released. Thanks to the new
>>>> persistent search feature, the name server can immediately pull new DNS
>>>> zones when they are created in IPA.
>>>> Since the bind-dyndb-ldap plugin has not been released in F-15 yet, one
>>>> has to use the provided src.rpm:
>>>> http://mkosek.fedorapeople.org/bind-dyndb-ldap/srpm/bind-dyndb-ldap-0.2.0-5.fc17.src.rpm
>>>> or rpms I built for x86_64 F-15:
>>>> http://mkosek.fedorapeople.org/bind-dyndb-ldap/x86_64/
>>>> There is one setback though. When I investigated DNS persistent search
>>>> behavior I still miss the ability to detect changes to the DNS zone
>>>> itself. Adding a record (for example MX record) to the zone does not
>>>> trigger an update of the zone in nameserver cache. We still have to wait
>>>> for cache timeout (argument "cache_ttl"). We cannot therefore use this
>>>> feature as a solution of:
>>>> https://fedorahosted.org/freeipa/ticket/1114
>>>> https://fedorahosted.org/freeipa/ticket/1125
>>>> https://fedorahosted.org/freeipa/ticket/1126
>>> So what are our options here?
>> I see we have the following options here:
>> 1) Consult this with AdamT and let him enhance bind-dyndb-ldap to track
>> not only add/modification operations with DNS zone (for example
>> modifying SOA record of example.com - this works), but also adding of a
>> new DNS record to the zone (a new MX record in example.com) or even to
>> regular DNS records (A record foo.example.com).
>> When I spoke with Adam last week (for following 2 weeks he is on PTO) he
>> said it is doable but has a potential if creating bugs in the plugin so
>> he implemented just the first part that we see.
>> 2) Let user adjust "cache_ttl" parameter. This bind-dyndb-ldap parameter
>> sets validity of the internal DNS record cache. When a DNS record is
>> changed/updated, user can get the updated value after $cache_ttl
>> seconds.
>> This is the same for updating DNS records in the zone (MX of
>> example.com) and updating regular DNS records (A record of
>> foo.example.com).
>> User can set it to the value that reflects his needs for the speed of
>> propagation of the DNS record updates and requirements on DNS
>> performance. We just have to make sure that this behavior is clearly
>> explained in our documentation.
>> Martin
> I see no further opinions, here is what I propose:
> 1) Let us use the current bind-dyndb-ldap persistent search feature as
> is, so that this feature can be tested
> - if it is well accepted, we can ask Adam to implement persistent search
> also for DNS records, i.e. records directly in zone records (MX) and for
> records in zones (A)
> - this would be implemented in another version of bind-dyndb-ldap - we
> should ask AdamT for time expectations when he returns from PTO
> 2) Make sure that current DNS behavior is well documented, and users are
> aware of that when they change/add a record, it may be seen after
> $cache_ttl seconds or when they reload the cache using `rndc reload`.
> 3) Tickets 1114, 1125 and 1126 would be closed as documentation fix.
> 4) Ticket 649 (An option to push updates) can be partially solved with
> the documentation fixes in step 3) and fully when full persistent search
> is implemented.
> Martin

Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to