7

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
Shadur
  • 1,297
  • 1
  • 10
  • 20

2 Answers2

4

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.

Cakemox
  • 24,141
  • 6
  • 41
  • 67
  • Is there a good way to inject more entropy into the system? I've tried running a major kernel compile at the same time, but it didn't speed things up much... – Shadur Aug 08 '12 at 10:39
  • Try EGD, PRNGD, or haveged. Entropy Broker looks promising as well. I have not personally tried these; I prefer urandom or hardware :) – Cakemox Aug 08 '12 at 11:01
  • I'm gonna see if I can get the manager to spring for some hardware. We *are* angling for a couple of government contracts, so... – Shadur Aug 08 '12 at 13:58
  • The manager was okay with it, and we've bought a simtec USB entropy generator. Works like a charm -- KSK generation now takes *seconds* rather than minutes. – Shadur Aug 17 '12 at 10:26
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.

Chopper3
  • 100,240
  • 9
  • 106
  • 238
  • That'd at least take the edge off the problem, but again, 3200+ keys to generate... – Shadur Aug 08 '12 at 10:32
  • You can't make an omelette without breaking eggs, if you have that many to do and you care about security you could buy some dedicated hardware to help - we use SafeNet HSMs (http://www.safenet-inc.com/uploadedFiles/About_SafeNet/Resource_Library/Resource_Items/Solution_Briefs_EDP/SafeNet_Solution_Brief_Protecting_DNSSEC.pdf?n=7060) – Chopper3 Aug 08 '12 at 10:37
  • If you need bulk randomness, there's a few QRNG's available online that can seed your local PRNG. I use http://qrng.anu.edu.au as an example. If you need amounts exceeding the goodwill of such websites, there are both TRNG and QRNG devices available from vendors with good reputations (some have questioned Intel and Via's chips, citing possible NSA involvement). – Chris S Feb 19 '14 at 04:06