What are acceptable key lengths for DNSSEC KSK/ZSK?

Solution 1:

dnssec-keygen reads from /dev/random by default. If the entropy on your system is low, you won't get enough random data to generate the keys in a timely manner. strace will probably show lots of stuff like:

select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "5%\5\32\316\337\241\323", 46)  = 8
read(3, 0x7fff5b6c3df0, 38)             = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\305\35\201c\31\343\251\21", 38) = 8
read(3, 0x7fff5b6c3df0, 30)             = -1 EAGAIN (Resource temporarily unavailable)

/dev/random blocks if there isn't enough entropy, so it could take a while.

You have a few options to make this go much faster. The easiest is to use change -r /dev/random to -r /dev/urandom to use the non-blocking (but not as secure) random number generator. This may not be considered secure for something like a GPG or SSH key which you'd expect to use for several years, but it's probably safe for something you'll be changing every 30 days.

Another option is to use something like EGD or haveged as a replacement for /dev/random.

If you want a much more secure RNG, you're better off with a dedicated hardware RNG. These are probably overkill for DNSSEC unless you're managing TLDs or bank domains.

You may want to stick to /dev/random for the KSK, but /dev/urandom should be good for the ZSKs.

Solution 2:

I think general consensus is that your ZSK should be 1024-bit and rolled around every quarter and your KSK should be 2048-bit and rolled around every couple of years.