[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Freeipa-devel] DNSSEC support design considerations

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]