Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question

migrated from superuser.com Aug 8 '12 at 9:25

This question came from our site for computer enthusiasts and power users.

    
Whoops, yes. Serverfault would probably be best. How can I migrate, other than manually re-entering the question? –  Shadur Aug 8 '12 at 9:24
    
Like that poof :) –  slhck Aug 8 '12 at 9:25
1  
10 minutes is a pretty absurd amount of time -- what's the exact command you're using to generate the key? –  Cakemox Aug 8 '12 at 9:43
    
Added the commands into the question. –  Shadur Aug 8 '12 at 10:26

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
    
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 8 '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 8 '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 8 '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

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.

share|improve this answer
    
That'd at least take the edge off the problem, but again, 3200+ keys to generate... –  Shadur Aug 8 '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 (safenet-inc.com/uploadedFiles/About_SafeNet/Resource_Library/…) –  Chopper3 Aug 8 '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 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 at 4:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.