[bind10-dev] LDAP in BIND 10

[Petr Spacek]

On 9.4.2013 11:41, Michal 'vorner' Vaner wrote:
> On Tue, Apr 09, 2013 at 10:54:33AM +0200, Petr Spacek wrote:
>> Basically, we start own thread and this 'listener' thread sits on LDAP
>> connection and waits for entry change notifications. The listener fires a new
>> event for each change, each event is handled asynchronously by functions
>> internal to backend.
>
> Is this a thread inside bind?
Yes, we call isc_thread_create(), i.e. the thread shares the same address 
space as the named itself.

> In bind10, you probably could create a listener module (separate program) that
> would listen and push updates.
This is very interesting. What about following scenarion?
1) 'Listener' process is started and it 'attaches' itself to BIND.
2) Listener downloads all the data from LDAP.
3) Listener pushed the data to some in-memory database in BIND.
4) BIND uses this in-memory database to reply to all queries.

The goal is to make BIND process independent on external database as much as 
possible, so BIND will continue to reply to DNS queries from in-memory 
database even if 'listener' or database server crashed.

It could create interesting combination: Use the flexibility of external 
replicated database and at the same time use stability and performance of 
in-memory database.

What about dynamic updates? Would listener be able to receive events from 
BIND? I.e.
1) Listener hooks itself to dynamic update processing.
2) Dynamic update request is redirected from in-memory database to listener.
3) Now the behaviour depends on listener:
3a) Listener pushes the change to in-memory database (after successful write 
to remote database)
or
3b) Listener refuses the update (if connection to database server is down)


>> Would it be possible to do this?
>> 1) Load old 'image' during startup and start replying to queries from the image.
>> 2) In background, load all new data from LDAP and create new 'image'.
>> 3) Switch to the new 'image'.
>> 4) Drop old image from memory.
>
> Yes. Something like that is planned. We would fall back to full reload in case
> the diffs are not available.
>
>> And also:
>> 0) Disable this mechanism completely :-)
>
> By disable, you mean the caching, or the load of old and just wait for the new
> one on each start? Yes would be to both.

This sounds as really good idea, thank you!

-- 
Petr^2 Spacek