[Freeipa-devel] DNSSEC support design considerations

[Petr Spacek]

On 22.5.2013 21:58, Simo Sorce wrote:
> On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote:
>> Wow, it is pretty slow.
> Yeah this is what I expected, crypto is not really fast.
[...]
>> The simplest way how to mitigate problem with slow start-up is:
>> 1) Store signed version of the zone on the server's file system.
>> 2) Load signed version from disk during start up.
>> 3) In the background, do full zone reload+resign.
>> 4) Switch old and new zones when it is done.
>
> Maybe instead of 3/4 we can do something that requires less computation.
> We can take the list of records in the zone, and load the list of
> records from LDAP.
>
> Here we set also the persistent search but we lock it so any update is
> queued until we are done with the main resync task.
> (We can temporarily also refuse DNS Updates I guess)
>
> We cross check to find which records have been changed, which have been
> removed, and which have been added.
> Discard all the records that are unchanged (I assume the vast majority)
> and then proceed to delete/modify/add the difference.
>
> This would save a large amount of computation at every startup, even if
> in the background the main issue here is not just time, but the fact
> that you pegged the CPU to 98% for so long.
>
>> It will consume some computing power during start up, but the implementation
>> should be really simple. (BIND naturally can save and load zones :-))
>
> I do not think the above would be much more difficult, and could save
> quite a lot of computing if done in the right order and within a bind
> database transaction I guess.

It sounds doable, I agree. Naturally, I plan to start with 'naive'/'in-memory 
only' implementation and add optimizations when the 'naive' part works.

>>> The idea is that _location is dynamic though, isn't it ?
[...]
>> This is how I understood the design. Is it correct? If it is, then the value
>> is static from server's point of view. The 'dynamics' is a result of moving
>> client, because client is asking different servers for an answer.
>
> Uhmm true, so we could simply store all the fields from within the
> plugin so that RBTDB can sign them too.
>
> I think my only concern is if the client can ever load some data from
> one server and then some other data from another and find mismatching
> signatures.
I didn't find any note about cross-checks between DNS servers. IMHO it doesn't 
matter, as long as signature matches the public key in the zone.

I think that some degree of inconsistency is natural part of DNS. Typically, 
all changes are propagated from the 'master'/'root of the tree topology' 
through multiple levels of slaves to the 'leaf slaves'.

Signatures contain timestamps and are periodically re-computed (in order of 
weeks) and it takes some time to propagate new signatures through the whole tree.

>>> What changes are going to be required in bind-dyndb-ldap to use RBTDB
>>> from Bind ? Do we have interfaces already ? Or will it require
>>> additional changes to the glue code we currently use to load our plugin
>>> into bind ?
>>
>> I have some proof-of-concept code. AFAIK no change to public interfaces are
>> necessary.
>>
>> There are 40 functions each database driver have to implement. Currently, we
>> have own implementation for most of them and some of them are NULL because are
>> required only for DNSSEC.
>>
>> The typical change from our implementation to the native one looks like this:
>>
>> static isc_result_t
>> find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
>>        dns_rdatatype_t type, unsigned int options, isc_stdtime_t now,
>>        dns_dbnode_t **nodep, dns_name_t *foundname, dns_rdataset_t *rdataset,
>>        dns_rdataset_t *sigrdataset)
>> {
>> - [next 200 lines of our code]
>> +       return dns_db_find(ldapdb->rbtdb, name, version, type, options, now,
>> +                          nodep, foundname, rdataset, sigrdataset);
>> }
>>
>> Most of the work is about understanding how the native database work.
>
> I assume rbtdb is now pretty stable and semantic changes are quite
> unlikely ?

BIND (with our patches) has defined interface for database backends. Either 
bind-dyndb-ldap and RBTDB implement this interface, so semantic change is very 
very unlikely.

The plan is to use the 'public' RBTDB interface to avoid any touch between 
bind-dyndb-ldap and 'internal knobs' in RBTDB.

>> At the moment I'm able to load data from LDAP and push them to the native
>> database except the zone serial. It definitely needs more investigation, but
>> it seems doable.
>
> Well if we store the data in the b permanently and synchronize at
> startup I guess the serial problem vanishes completely ? (assuming we
> use timestamp based serials)
Yes, basically we don't need to write it back to LDAP at all. The behaviour 
should be same as with current implementation.

>>>> <sarcasm>
>>>> Do you want to go back to 'light side of the force'? So we should start with
>>>> designing some LDAP->nsupdate gateway and use that for zone maintenance. It
>>>> doesn't solve adding/reconfiguring of zones on run-time, but it could be
>>>> handled by some stand-alone daemon with an abstraction layer at proper place.
>>>> </sacrasm>
>>>
>>> Well the problem is loading of zones, that is why nsupdate can't be
>>> used, we'd have to dump zones on the fly at restart and pile up
>>> nsupdates if bind is not available, and then handle the case where for
>>> some reason nsupdate fails and bind and LDAP get out of sync.
>>
>> Yes, it is definitely not a simple task, but IMHO it could work. Some glue
>> logic specific for particular DNS server will be required in any case (for
>> zone addition/removal/reconfiguration - in BIND's case some tooling around
>> 'rndc' tool), but most of the 'synchronization logic' can be done in generic way.
>>
>> I can imagine that 'synchronization daemon' could be simpler than current code
>> (323 780 bytes ; 11 909 lines of C).
>
> No, trust me synchronization is alwys fraught with nasty corner cases
> and things getting out of sync. In fact I think we should implement the
> re-sync I am asking for at load time at regular intervals so that even
> if the internal database and LDAP go out fo sync we fix that every X
> hours by performing a smart re-sync (which hopefully normally will
> simply consist in comparing 2 snapshots (internal and LDAP) and finding
> that they are basically in sync).
I agree that some periodical re-synchronization would be handy even for 
current solution.


It looks that we agree on nearly all points (I apologize if overlooked 
something). I will prepare a design document for transition to RBTDB and then 
another design document for DNSSEC implementation.

>>> Also would mean nsupdates made by clients would not be reported back to
>>> LDAP.
>> I don't agree. DNS has incremental zone transfers (RFC 1995) and change
>> notification mechanism (RFC 1996). A standard compliant DNS server can send
>> notification about changes in the zone and the (hypothetical) 'synchronization
>> daemon' can read the changes via IXFR.
>
> And we are reimplementing half of the protocols again :)
We don't have to implement LDAP protocol because we have openldap libraries 
and there are libraries for DNS too. Why we would have to implement DNS? :-)

Anyway, it doesn't matter for now, I'm not pushing towards 'synchronization 
daemon' at the moment.

-- 
Petr^2 Spacek