[dnssec-deployment] Extra memory requirements caused by DNSSEC?

[Lutz Donnerhacke]

* Jeroen Massar wrote:
> I recently did a small checkup if we could enable DNSSEC for the zones
> used for SixXS, but memory usage scared me a bit.

Great news! Thank you for your effort.

> The thing is, we have a few zones, but they are somewhat largish:
>  729002 0.0.1.0.8.b.4.1.1.0.0.2.ip6.arpa.db
> signed it becomes:
> 6560499 0.0.1.0.8.b.4.1.1.0.0.2.ip6.arpa.db.signed

I had the same problem:
  4389346 dnssec.iks-jena.de (unsigned data)

> But we have at the moment 25 of those plus the forwards and then also
> quite a number of other zones, eg for the /48 delegations. Bind already
> chews about 100mb of memory for ~30mb of zones, which is actually not
> too bad (tuning tips welcome of course ;). But as can be seen from the
> above, we get an increase from 700kb to 6.5mb, which is nearly a factor
> 10 memory increase, which would cause memory usage to most likely rise
> to the neighborhood of 1Gb.

Bind's memory overhead does not go linear with the zone size. I noticed,
that bind memory usage seems to be optimized for a large amount of small
zones.

Same is true for the dnssec toolchain. They work better for small zones and
become unusable for large ones. I.e. signing my complete DLV tooks over 90
minutes.

Even the load process seems to be optimized for small zones. The startup and
reload process does check the validity of the signed zones on loading the
new data. I my case it took about 30 minutes to verify the zone on startup.
In this time bind does not answer any questions.

Therefore I split the zone into smaller parts and got a much more smooth
operation.

> As such what I am wondering, does anyone have memory requirement
> statistics, eg serving a lot of _large_ zones with and without DNSSEC
> and what the requirements for each are. Also another thing there is when
> having to rotate keys, all the zones have to be rekeyed, which will eat
> some nice resources too. Any papers on that?

You already know:
 http://www-x.antd.nist.gov/dnssec/dnssec-perform.html
 ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf
 http://www.net.informatik.tu-muenchen.de/~anja/feldmann/papers/dnssec05.pdf
 http://www.net.in.tum.de/teaching/projects/docs/ager_DA_mar2005.pdf
 
> problem. There are only a ~30 /40's for the reverses and of course
> sixxs.net|com|org as forward to delegate which should not be a big
> problem to get arranged I guess.

Please do so.

> Even though we held a poll a few months back and response was 0, I do
> think that introducing DNSSEC will be a good thing, as it gives quite a
> lot of users the ability to start using it for their reverses.

Some already did.

> At the moment I am thinking of trying to get entries in the relevant
> DLVs and only DNSSEC delegating the 'small' zones, thus not the tunnel
> forward/reverses, which are separate /48's in the /40's. This would at
> least allow the users to delegate their zones DNSSEC signed and with a
> tree at least up to us. The user will then simply be able to login to
> the site, and like configuring their nameservers, be able to add keys,
> thus automating the delegation portion, though rotation will be fun.

Your proposed deployment strategy is likely to work.