NSEC3 salt lifetime (and some other DNSSEC params): sane value?

Niobos niobos at dest-unreach.be
Fri Sep 17 18:26:21 UTC 2010


Hi,

I'm playing around with the different timers of DNSSEC. Usually these
timers are a balance between a low overhead vs quick propagation:
* A high TTL gives more caching and thus less load on the authoritative
server; but it takes a long time for updates to propagate.
* A short RRSIG lifetime limits the amount of time old answers can be
replayed; but requires regular resigning

Or they are a balance between low overhead and security:
* A DNSKEY (ZSK or KSK) used for a long time risks being cracked;
changing it often requires maintenance.

But for the NSEC3 salt, I can't really figure out what the components
are... If someone is brute-forcing the NSEC3 hashes (cfr Daniel
Bernstein's presentation), changing the salt requires only a minuscule
change on their end. I see no reason to change the NSEC3 salt at all.

So the question is: what is a normal lifetime of an NSEC3 salt, and for
what reason?

And while I'm at it: what lifetimes, keylengths and algo's are popular
for ZSK's and KSK's? Are your keys stored online or offline?

I'm thinking of using ZSK's of 1280bits for a year (since I'm lazy) and
KSK's of 2048bits until I feel like changing it (i.e. pretty much
indefinitely). This would allow the KSK to be offline, and only needed
once a year.
I'd like to use NSEC3 with RSA/SHA-512, but that might be unreasonable
strong compared to my lazy lifetimes. On the other hand, RSA/SHA1 is
more compatible (eg with bind 9.6).
My signature lifetime will probably be 3 weeks, resigning every week.
With 1 week expire timers, it leaves 1 week of margin to correct errors.
Are these values/argo's sane?

Thx,
Niobos

PS: don't try talking me into using NSEC. I'm using NSEC3 "because I
can", not that it would be any problem at all if they walked my zone.




More information about the bind-users mailing list