[Freeipa-devel] DNSSEC support design considerations

[Petr Spacek]

Hello list,

I investigated various scenarios for DNSSEC integration and I would like to 
hear your opinions about proposed approach and it's effects.


The most important finding is that bind-dyndb-ldap can't support DNSSEC 
without rewrite of the 'in-memory database' component. Fortunately, it seems 
that we can drop our own implementation of the internal DNS database 
(ldap_driver.c and cache.c) and re-use the database from BIND (so called RBTDB).

I'm trying to reach Adam Tkac with the question "Why we decided to implement 
it again rather than re-use BIND's code?".


Re-usage of BIND's implementation will have following properties:


== Advantages ==
- Big part of DNSSEC implementation from BIND9 can be reused.
- Overall plugin implementation will be simpler - we can drop many lines of 
our code and bugs.
- Run-time performance could be much much better.

- We will get implementation for these tickets "for free":
-- #95  wildcard CNAME does NOT work
-- #64 	IXFR support (IMHO this is important!)
-- #6 	Cache non-existing records

And partially:
-- #7 	Allow limiting of the cache


== Disadvantages ==
- Support for configurations without persistent search will complicate things 
a lot.
-- Proposal => Make persistent search obligatory. OpenLDAP supports LDAP 
SyncRepl, so it should be possible to make plugin compatible with 389 and 
OpenLDAP at the same time. I would defer this to somebody from users/OpenLDAP 
community.

- Data from LDAP have to be dumped to memory (or to file) before the server 
will start replying to queries.
=> This is not nice, but servers usually are not restarted often. IMHO it is a 
good compromise between complexity and performance.
=> It should be possible to save old database to disk (during BIND shutdown or 
periodically) and re-use this old database during server startup. I.e. server 
will start replying immediately from 'old' database and then the server will 
switch to the new database when dump from LDAP is finished.
=> As a side effect, BIND can start even if connection to LDAP server is down 
- this can improve infrastructure resiliency a lot!


== Uncertain effects ==
- Memory consumption will change, but I'm not sure in which direction.
- SOA serial number maintenance is a open question.


Decision if persistent search is a 'requirement' or not will have significant 
impact on the design, so I will write the design document when this decision 
is made.

-- 
Petr^2 Spacek