[bind10-dev] LDAP in BIND 10

[Michal 'vorner' Vaner]

Good morning

On Wed, Apr 10, 2013 at 12:25:28PM +0200, Petr Spacek wrote:
> On 9.4.2013 11:41, Michal 'vorner' Vaner wrote:
> > 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.

Looking at it again, it seems you'd not want a separate process here, but what
we call a data source.

A data source is a dynamic library which is placed in predefined directory and
has a fixed interface. It implements routines to:
 * Go through the whole zone
 * Provide specific data from the zone
 * Update the zone

Bind10 then loads the library (as configured) and uses it to provide data. We
have an in-memory implementation of data source that we use as a cache in front
of other data sources. So, you'd implement the „Go through the whole zone“
routine and configured bind10 to have the in-memory cache. It would load the
zone on startup/update to in-memory and would otherwise use only the cache to
answer.

Currently, the loading is done inside each authoritative server. But, as Jinmei
mentioned, we are working on a separate program that would do the loading and
prepared the in-memory image for the authoritative server processes. Then, you
didn't have to write anything more than just the translation from LDAP to RRs
(or string data, depending on which version of interface you'd use), but if the
loading crashed, it would bring down only the module preparing the image,
authoritative server could still answer queries.

> 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)

You could use the data source here too. We have a DDNS module which uses the
library to „push“ actual data into the backend. So, if you'd implement the
„Update the zone“ functionality, DDNS could use it right away.

The only bit I don't see direct support for is the push directly to the
in-memory image (we currently expect to go through the backend). But as you
said, LDAP doesn't provide the differences, so it would require reload of the
whole zone, which may be too expensive.

But if you implemented some kind of local cache for last few updates (it
wouldn't have to be in LDAP), it could be used to do fast updates too.

Or you could make it client-server. The server is the separate listener process,
clients are the libraries. But I guess it would be needlessly more work than
needed.

With regards

-- 
Let me show you my collection of bugs.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130410/d631dfe3/attachment.bin>