[Freeipa-devel] DNSSEC support design considerations

[Simo Sorce]

On Wed, 2013-05-22 at 17:01 +0200, Petr Spacek wrote:
> Right, it is good idea. I never tried really big zone (for some reason?).
> 
> Command: /usr/bin/time dnssec-signzone -n 1 -o example.net example.net
> Signing was limited to single core (parameter -n 1).
> 
> Unsigned zone: 327 285 bytes, ~ 10 000 A records and several other records
> Signed zone: 10 847 688 bytes
> Results:
> 38.28user 0.09system 0:38.80elapsed 98%CPU (0avgtext+0avgdata 18032maxresident)k
> 0inputs+21200outputs (0major+4646minor)pagefaults 0swaps
> 
> Wow, it is pretty slow.

Yeah this is what I expected, crypto is not really fast.

> CPU: Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz
> Operating memory: 4 GB of DDR3 @ 1333 MHz
> 
> 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.

> > Well given an IPA infrastructure uses Dynamic Updates I expect data to
> > change frequently enough that if you have an outage that lasts more than
> > a handful of minutes the data in the saved copy will not match the data
> > in LDAP.
> I agree, that is definitely true, but I think that the most important pieces 
> are NS, SRV and A records for servers. They are not changed that often.
> 
> IMHO admins would be happier if they have 100 records from 10 000 out of date 
> but the infrastructure works than without any records at all (and broken 
> infrastructure).
> 
> Again, there can be some LDAP-synchonization-timeout and DNS server can stop 
> responding to queries when synchronization is lost for longer time.

This may be a reasonable compromise.

> > The idea is that _location is dynamic though, isn't it ?
> The value seems to be 'dynamic', but only from client's point of view. AFAIK 
> there are three options:
> 1) _location is configured for particular client statically in LDAP
> 2) Each individual server has own default value for _location (for clients 
> without explicit configuration).
> 3) Each individual server can be configured to override all values in 
> _location with one fixed value, i.e. all clients (e.g. in bandwith-constrained 
> location) will use only the local server.
> 
> 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.

> > Anyway what if we do not sign _location records ?
> > Will DNSSEC compliant clients fail in that case ?
> I'm not 100 % sure, but I see two problems:
> 
> 1) It seems that opt-out is allowed only for delegation points (NS records 
> belonging to sub-domains).
> http://tools.ietf.org/html/rfc5155#section-6
> 
> 2) Opt-out allows an attacked to insert unsigned data in the replies.
> http://www.stanford.edu/~jcm/papers/dnssec_ndss10.pdf section 3.4

I think for location discovery this may be a problem we can accept.
But if we can avoid it we probably should.

> Anyway, I don't think that it is necessary.

ok.

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

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

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

> > 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 :)

> The way from LDAP to DNS is not simple, that is definitely true ...
> 
> > Using nsupdate was considered, it just is not feasible.
> 
> We should reconsider it during migration from BIND9 to something else :-)

Well, we'll think about that once we decide it is time I guess :-)

Simo.

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