[Freeipa-devel] DNSSEC support design considerations
pspacek at redhat.com
Tue May 14 13:55:53 UTC 2013
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
-- #7 Allow limiting of the cache
== Disadvantages ==
- Support for configurations without persistent search will complicate things
-- 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
- 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
More information about the Freeipa-devel