[bind10-dev] LDAP in BIND 10

[Petr Spacek]

Hello,

On 10.4.2013 14:47, Michal 'vorner' Vaner wrote:
> 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.

Thank you for your time!

Now I have few more questions :-)

Who is responsible for SOA serial incrementation?

Does BIND increment the serial automatically for changes received by 'data 
source' asynchronously?
Or - is serial incrementation an independent 'change set' sent to the backend 
if the first (real) 'data change' was finished?
Or - is the 'data source' the piece responsible for SOA serial maintenance 
(i.e. only 'data change' is sent to the 'data source' and the rest is in hand 
of backend)?

Is there an important difference between changes coming from DNS dynamic 
updates and changes coming via 'listener'/'data source' asynchronously?


How it will work with DNSSEC?

Would it be possible to use own data source and DNSSEC in-line signing at the 
same time? Would be changed records re-signed automatically by BIND?

Or more generally - what is required from the 'data source' to implement for 
the DNSSEC support?

Is 'data source' obliged to implement 'Get lexically next record' method or is 
enough to provide 'Go through the whole zone' method? I mean - is BIND able to 
find lexically-next record in in-memory cache or is it mandatory to implement 
such logic in 'data source' itself?

> 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.
Exactly. We have some users with dynamic update rate in order of ~ 10 updates 
per second. Full zone reload can't work in such environment.

> 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.
Could you be more specific? Is the following sequence okay?

1) Some update came in via DNS dynamic update.
2) Update is passed to 'data source'.
3) Data source decides if update should be accepted or refused.

4) ??? Now we need to apply the change to in-memory data/cache. How it is 
supposed to work? Is it something like internal IXFR between 'data source' and 
in-memory cache?

Would it be possible to simply transform 'change request' structure (passed by 
front-end to 'data source') to another data structure like 'description of 
changes'/little IXFR and pass it back to BIND?

Or does BIND some periodical check like 'give me current serial' and then 
'give me differences between serial XXXX and current serial'?


Thank you for your time!

-- 
Petr^2 Spacek