[Freeipa-devel] DNSSEC support design considerations

[Simo Sorce]

----- Original Message -----
> 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.

Can you elaborate why a rewrite would be needed ? What constraint we do not meet ?

> 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

Sounds very interesting.


> == 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.

Why the persistent search would be required ?

> - 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.

I am not sure I understand what this means. Does it mean you cannot change single
cache entries on the fly when a change happens in LDAP ? Or something else ?

> => 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.


This look like an advantage ? Why is it a disadvantage ?

> => As a side effect, BIND can start even if connection to LDAP server is down
> - this can improve infrastructure resiliency a lot!

Same as above ?

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

Why SOA serial is a problem ?

> 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.

I would like to know more details about the reasons before I can usefully comment.

Thanks for the research work done so far!

Simo.

-- 
Simo Sorce * Red Hat, Inc. * New York