Various ideas and variants for bind-dyndb-ldap
reimplementation/replacements.
Daemon + subset of bind-dyndb-ldap
- synchronous update
- depends on BIND internals
Daemon
- zone and BIND reconfiguration
- generates
zone {} sections for named.conf (+ other config)
- zone definition is using
zone { database "ldap"; }
- likely needs full config parser, e.g. Augeas
- rndc reconfig
- rndc addzone/modzone/delzone commands
LDAP driver
- is subset of bind-dyndb-ldap
- written in C
- high performance and synchronous writes
Daemon + new BIND external update protocol
- synchronous update
- depends on new update protocol between BIND and the daemon
Daemon
- zone and BIND reconfiguration + data synchronization
- generates
zone {} sections for named.conf (+ other config)
- zone definition is using
update-policy { externalv2 }
- kind of update proxy between LDAP and BIND
- speaks LDAP on one side and a BIND’s protocol on the other side
BIND enhancements
- new
update-policy like externalv2 which sends updates from
BIND to a external daemon before the update is accepted
- new protocol have to transfer all the data about the update including
protocol/client adresses/full RDATA
- should the new protocol contain a “reply” which can contain modified
records?
- e.g. client sent
update add A 192.0.2.1, should the protocol
allow the daemon to return the A record update and add PTR record
update?
Daemon with standard protocols
Daemon
- uses
SyncRepl (RFC
4533), DNS update (RFC
2136), and IFXR/AXFR (RFC
1995/RFC
5936) to synchronize data
between LDAP and BIND
- generates config snippets
- generates
zone {} sections for named.conf (+ other config)
- zone definition allows local zone transfers and updates (between
BIND and the local daemon)