Was sind akzeptable Schlüssellängen für DNSSEC KSK / ZSK?

Ich wurde beauftragt, die Implementierung von DNSSEC auf unseren Nameservern zu untersuchen. Während die technische Seite davon (Schlüssel generieren, Zonen signieren, Rollover vorbereiten) relativ einfach ist, bin ich auf ein logistisches Problem gestoßen.

Aus der Dokumentation, die ich gelesen habe, geht hervor, dass 1024 Bit eine gute Größe für einen Zonensignaturschlüssel haben. Das richtige Verfahren wäre ein ZSK für jede Zone mit einem Rollover von etwa einem Monat

Auf einem relativ schnellen Computer mit anständiger Entropie dauert es jedoch bis zu 10 Minuten, um einen 1024-Bit-Schlüssel zu generieren ... Und der ISP, für den ich arbeite, arbeitet für Hosts über dreitausend Zonen. Wenn ich den Prozess nicht irgendwie von Anfang bis Ende automatisiere, wird dies nicht praktikabel sein - und selbst wenn ich es tue, wäre es bis zum Ende des Prozesses fast Zeit, mit dem nächsten Rollover zu beginnen.

Kurz gesagt, das ist nicht machbar. Im Moment beschränke ich DNSSEC auf Kunden, die explizit danach fragen, aber das ist bestenfalls eine Notlösung.

Meine Fragen:

• Gehe ich mit der Schlüssellänge weit über Bord?
• Wie kann ich den Prozess der Schlüsselgenerierung beschleunigen?
• Sollte ich für jede Zone sowie für ZSKs individuelle Schlüsselsignaturschlüssel erstellen?

BEARBEITEN: Die genauen Befehle, die ich zum Generieren der Schlüssel verwende, wurden hinzugefügt:

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

dnssec-keygenliest /dev/randomstandardmäßig aus. Wenn die Entropie auf Ihrem System niedrig ist, erhalten Sie nicht genügend zufällige Daten, um die Schlüssel rechtzeitig zu generieren. Strace wird wahrscheinlich viele Dinge zeigen wie:

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 blockiert, wenn nicht genügend Entropie vorhanden ist, daher kann es eine Weile dauern.

Sie haben einige Möglichkeiten, um dies viel schneller zu machen. Am einfachsten ist die Veränderung zu verwenden , -r /dev/randomum -r /dev/urandomden nicht-blockierende (aber nicht so sicher) Zufallszahlengenerator zu verwenden. Dies gilt möglicherweise nicht als sicher für etwas wie einen GPG- oder SSH-Schlüssel, den Sie voraussichtlich mehrere Jahre lang verwenden werden, aber es ist wahrscheinlich sicher für etwas, das Sie alle 30 Tage ändern werden.

Eine andere Möglichkeit besteht darin, etwas wie EGD oder Hged als Ersatz für zu verwenden /dev/random.

Wenn Sie ein viel sichereres RNG wünschen, sind Sie mit einem dedizierten Hardware-RNG besser dran. Diese sind für DNSSEC wahrscheinlich übertrieben, es sei denn, Sie verwalten TLDs oder Bankdomänen.

Vielleicht möchten Sie sich für die KSK an / dev / random halten, aber / dev / urandom sollte für die ZSKs gut sein.

Ich denke, allgemeiner Konsens ist, dass Ihr ZSK 1024-Bit sein und vierteljährlich und Ihr KSK 2048-Bit und alle paar Jahre gerollt werden sollte.