Home / server / Questions / 415419
Accepted
Shadur
Asked: 2012-08-09 01:03:35 +0800 CST

What are acceptable key lengths for DNSSEC KSK/ZSK?

  • 772

I've been tasked to look into implementing DNSSEC on our name servers. While the technical side of this (generate keys, sign zones, prepare rollovers) are relatively straightforward, I've run into a logistical problem.

From the documentation I've been reading, 1024 bits is a good size for a Zone-Signing Key, and proper procedure would be one ZSK for each zone with about a one-month rollover

However, it takes up to 10 minutes on a reasonably fast computer with decent entropy to generate an 1024-bit key... And the ISP I work for hosts over three thousand zones. Unless I somehow automate the process from start to finish, this isn't going to be workable -- and even if I do, by the time the process finishes it'd be almost time to start with the NEXT rollover.

In short, this isn't feasible. Right now I'm restricting DNSSEC to customers who explicitly ask for it, but that's stopgap at best.

My questions:

  • Am I going way overboard with the key length?
  • How can I speed up the key generation process?
  • Should I create individual Key-signing keys for each zone as well as ZSKs?

EDIT: Added the exact commands I'm using to generate the keys:

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256 -f KSK -b 1280 -n ZONE example.com 
Generating key pair.............................+++++ ...+++++ 
Kexample.com.+008+10282

real    9m46.094s
user    0m0.092s
sys 0m0.140s

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256  -b 1280 -n ZONE example.com 
Generating key pair.........................+++++ .........+++++ 
Kexample.com.+008+22173

real    12m47.739s
user    0m0.124s
sys 0m0.076s
domain-name-system

2 Answers

  1. Best Answer

    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.

    • 4

  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.

    • 2