KSK rollover im Beispiel

Da die Double-Signature-Methode zeitweise zwei Schlüssel zum Signieren benutzt und damit die Signaturlängen verdoppelt, wird diese Methode eigentlich nur für den KSK empfohlen. Da der KSK nur die DNSKEYs signiert, hält sich der Größenzuwachs der Zone in Grenzen.

Ausgangslage

Wir gehen hier davon aus, der derzeit aktuelle KSK der Zone kein Ablauf- ("Inactivation"), und Löschdatum ("Deletion") hat.

Prozedur

Die Vorgehensweise ist für einen "30-Tage-Rollover" grob umrissen wie folgt:

1. Einen zweiten KSK „neu" erzeugen

dieser läuft nie ab, wenn kein -D und -I gesetzt wird,
aber das Publication Datum (-P) auf jetzt (now) setzen
und das Activation Datum (-A) auf jetzt (now) setzen.

2. Das Inactivation Datum (-I) des bestehenden KSK „alt“ auf 1 Monat (+30d) in der Zukunft stellen

3. Das Deletion Datum (-D) des bestehenden KSK „alt“ auf 2 Monate (+60d) in der Zukunft stellen

Rollperiode

Die Perdiodenabschnitte für Publication, Activation, Inactivation und Deletion kann man auch kürzer setzen, um den Rollover schneller durchzuführen. Die minimale Untergrenze ist durch die übliche TTL von 1 Tag in den Caching resolvern gegeben, d.h. 2 Tage sind minimal möglich.

Üblich sind Zeiten von 10, 20 oder wie in unserem Beispiel 30 Tagen. Die Prozedur gestaltet sich mit entsprechend angepassten Werten aber gleich!

Details

Wenn die beiden Schlüssel im Schlüsselverzeichnis, das in named.conf konfiguriert ist, liegen, dann sollte der Rest mit „auto-dnssec maintain“ und „inline-signing“ automatisch gehen.

Die Rollover-Methoden sind auch im „DNSSEC-Guide“ von ISC in der Sektion 4.6 noch einmal kurz beschrieben:
https://ftp.isc.org/isc/dnssec-guide/dnssec-guide.pdf

Grundsätzliche Demonstration am Beispiel eines KSK:

Der existierende, derzeitige KSK hat die key-id 12364


Kws01.ws.dnssec.bayern.+008+12364.key  Kws01.ws.dnssec.bayern.+008+12364.private

; This is a key-signing key, keyid 12364, for ws01.ws.dnssec.bayern.
; Created: 20180308133040 (Thu Mar  8 14:30:40 2018)
; Publish: 20180308133040 (Thu Mar  8 14:30:40 2018)
; Activate: 20180308133040 (Thu Mar  8 14:30:40 2018)
ws01.ws.dnssec.bayern. IN DNSKEY 257 3 8 AwEAAdl4eD8UbSBGgUW3ImOX1ZBjM4O6flkINGsHg
7TRD3iQI53mBXhu puooamjmtW7zJK7gq+dEF8T8gM3drxNohxU3WhtXfXyfCASs62dARAwJ V6KBEvzOo
PIirRy7lD6JaHzLvHZmhlErsbnbhvyQFUPFAxYWPp8l09+z EI3LUvvjvMk29iZRVeLEWeR18E9IQ5mYLU
sCY5w8A/dGse/1EZOM4eUJ kk/Sf+DP5grw5XY3m1GpToxp1wHpWn5vOZHUMig5lgJSIGOXn2ik2Efl 8+
SElrk893Dv+EgaVku7W7cioJuPL0ah1B9aDL6V6momqwjbWTDjj0fB Dg9KFlFLywE=

Er hat nur ein Publish und Activate-Datum, ist also schon publiziert und aktiv, läuft aber nie ab, und wird nie aus der Zone entfernt werden.

Dann erzeugt man mit dnssec-keygen den neuen KSK für den Rollover, der gemäß der Double-Signature-Methode:

dnssec-keygen -a 8 -b 2048 -f KSK -P now -A now -n ZONE ws01.ws.dnssec.bayern 
Generating key pair.................................................................+++ ...........................................+++ 
Kws01.ws.dnssec.bayern.+008+50140

ab sofort (-P now) in der Zone veröffentlicht werden soll und wird auch sofort (-A now) aktiv zum Signieren verwendet.

Man hat zwei Schlüsselpaare, wobei der neue KSK die key-id 50140 hat:

-rw-r--r-- 1 root root  625 Mar  8 14:30 Kws01.ws.dnssec.bayern.+008+12364.key
-rw------- 1 root root 1776 Mar  8 14:30 Kws01.ws.dnssec.bayern.+008+12364.private
-rw-r--r-- 1 root root  625 Mar 12 13:01 Kws01.ws.dnssec.bayern.+008+50140.key
-rw------- 1 root root 1776 Mar 12 13:01 Kws01.ws.dnssec.bayern.+008+50140.private

Nun muss man noch ein Inactivation-Datum (-I +30d) in 30 Tagen und Deletion-Datum (-D +60d) in 60 Tagen für den alten KSK setzen, die natürlich von den Werten, die wir für das Publication- und Activation-Datum des alten KSK gewählt haben, abhängen - d.h. die Werte für eine kürze Rollperiode entsprechend anpassen.


dnssec-settime -I +30d -D +60d *12364*.key
./Kws01.ws.dnssec.bayern.+008+12364.key
./Kws01.ws.dnssec.bayern.+008+12364.private

Das sind mit den 30 Tagen Zeitspannen wie schon in oberen Abschnitt beschrieben, eher großzügige Werte. Mit 10 oder 20 Tagen kann man einen KSK rollover schneller durchziehen.

Überprüfung

Mit dnssec-coverage kann man die korrekte Überlappung überprüfen:

dnssec-coverage -K . ws01.ws.dnssec.bayern


Checking scheduled KSK events for zone ws01.ws.dnssec.bayern, algorithm RSASHA256...
  Thu Jan 08 13:30:40 UTC 2018:
    Publish: ws01.ws.dnssec.bayern/008/12364 (KSK)
    Activate: ws01.ws.dnssec.bayern/008/12364 (KSK)
  Fri Apr 08 11:51:08 UTC 2018:
    Publish: ws01.ws.dnssec.bayern/008/50140 (KSK)  
    Activate: ws01.ws.dnssec.bayern/008/50140 (KSK)
  Sun Mai 08 12:51:31 UTC 2018:
    Inactive: ws01.ws.dnssec.bayern/008/12364 (KSK)
  Tue Jun 07 12:51:31 UTC 2018:
    Delete: ws01.ws.dnssec.bayern/008/12364 (KSK)
No errors found

Für die Zeit von April 08 11:51:08 UTC 2018 bis Mai 08 12:51:31 UTC 2018 werden dann die ZSKs mit beiden KSKs signiert. Zu beachten ist, wie auch schon erwähnt, dass der alte Schlüssel nicht sofort aus der alten Zone gelöscht werden darf, da in den caching resolvers noch alte Signaturen überprüft können werden müssen.

Wichtig ist natürlich die Kommunikation des KSK an die Parentzone über den Registrar (z.B. DFN). Diese erfolgt kurz bevor der neue KSK in der Zone publiziert wird.

Standby-Key

Solange ein aktiver KSK in der Zone existiert, der für Signaturen verwendet wird, ist ein zweiter inaktiver KSK in der Parentzone kein Beinbruch. DNSViz würde eine Wanrnung geben, wenn der als zweiter DS eingetragene KSK noch ins leere läuft. So lange der alte noch vorhanden ist, ist das kein DNSSEC-Fehler, da immer noch eine sichere Delegation über den aktiven Schlüssel möglich ist.

DNSViz moniert das aber als Warning, und für eine konsistentes Vorgehen, ist es dann besser, zwei KSK auch aktiv zu haben.

Die Uni Regensburg verwendet standardmäßig zwei KSKs, einen aktiven und einen standby KSK:

http://dnsviz.net/d/uni-regensburg.de/dnssec/

Hier sieht man, dass der ZSK (Typ 256) mit beiden KSKs (Typen 257) signiert wird:

dig -t DNSKEY uni-regensburg.de +dnssec +short

257 3 8 AwEAAeFM+2zMdnGsMett7C+y2+CutjzZSUBtR3tFgJ0lsm39a5ZgB1Wm 6WCrjAeMVIF7FZGgS8+sScav+dDCepaExkLzQQ4UnwCteEgwHfCUXOwY QKgaK9EWga5ekVEEhXGRmUOBWIx42iceFUCNlYH10qyX/P0uqx1t4YFq XQXlTKdhzSWBRSOiqvxFtid/oGtZNfw2M10Or5a43bh1HJMc0pi49bsH 2MA3I6IBy32yX/0Sqpb9705zuAzxuc3JIb8bLMzbaXdkyNx0VkjJzRSe 0CMSyyXtbd4f/hz1y6i80TfMowk83rkarJhxE4kL4uFRkPAbkuFN/q6p vJtnnps6Y8s=
257 3 8 AwEAAeKnU86X3ytsUeMbdm100AVxT5y7lPiPAEAOYZre1bbadvT48flT aJpgWi5Y6OXfE3piLEAMO/z/hHLqRMav7PnJzkIKlfaai6SUnhKtS+V4 sQUlZ9SWLTQocGaFP+ygjOporNBhqSxt3vvk6wl3eEAjHLem842BnotC mtX2n0hqTWpY8psQCI/iWUVJjG3KB8OREYsUq3RVavoIAZ7pMhaesjHK A7Wt6DjNx6HXb9XG+m7Am5QwHpBeCxbtVKSnN4dR1zYMgBmp+8rgOSX7 PNLOvFWegdLtJRH3XU1+996mfL3cqYy9Tp6e9TVbby+1Dv7LnOgMPivK EL3jVg8Zaxk=
256 3 8 AwEAAatuCv5Qqjy4r/zgIeeDAJTmofUo4echyH2UBW5CbNJOmRKwu6+X O93ULy4zT59YzPiGJU6uLaofJqd7zQZC2zXEFKNrGLy55AuQXaYypSOi DAnp/005nAXoquziGpdnoGdu4VZOkJMRD4zCq3330A+tSly0MHafO8U2 csjf4jOUy0m3zr6lMqr9tU4mKVOmWpHwJyhPOQmIxPr8zNykr0IeVmbz zv84I68T/cQJYiT7y2xamkyNRFlNptE3QHHex8KL6AgxS4YL/5NUlmOC tATwsyJeZ7kMGusiUO9YuVgUetX6Wf3+PZPm9i7mcm9KB3A59cYPCnoL IJETTHCDS1s=
DNSKEY 8 2 86400 20180331134046 20180301124046 32815 uni-regensburg.de. CXU583CxGmWAeCStHbIFdISnZyvxQDArOE2xS6j2PnOKzAtuCDxuwR7n 261VZpGA26NU4u07oj+I8JHuvVhV7+PIIIMkaochEuo2g7m7lhoBEyUH 044qafkKBUB1nioE+51gpIB979h4GDyYxegmLUI2JVZWIDhvbcibPNgY OCoWwPlBHfiumG1v0t/Ss8oshmL39jt5KDjcHmmf8zqsMkkgwXRG+W31 NpB24DOPQAWxmHELL04ApifxbEJYEgzJ/rd4Vc2GN9YUSOSL+XgzOPgo vxkehIBtstEWYj0VDjIvHJ3WMCKVyppFpSPWtV7RqTgyYUUC3Xm8Fh90 2bFjmA==
DNSKEY 8 2 86400 20180331134046 20180301124046 38089 uni-regensburg.de. L87AMakSmK6yy85Gl0pHRIKEz4YhZ3XIx74iUHgejIgHecJ4WDul34Qf lrYn0uG6cRf6TqPmLA2Ka8P6zU9UJ+fL0ccTSwFAFBa2MB0a7JZNL+xE vj2PnM9UDLB4597g7qCMaNAP+QQH3vMki99hIHnb7JejXqCz7ZhGq49u KMefz4GY1TiGrBVwzJJtVa4vb61HGBRFjk0k/htDwU01vA0dgGBVpsNd szHpu9QLQ/PJlKRE4qgUogdEOzK9SpaCf1Z5Z+XFIHBlxz9NOZBmmnah LqEI0Wyd8i39sfq9/Ni1zYvTPACQtGKVeKEABQfwddEwmSIDxb7u1iWZ 1fPG5w==
DNSKEY 8 2 86400 20180331134046 20180301124046 42063 uni-regensburg.de. gzuNtcDi/XexyRKvRLFP/aIYcUTLqNE5SDuHFSssPFoghZSNA33p9JoP j6+LGiBiPzWk+TDqk/xqv6AlINT0Gqoh+bPfrX5ygqBuWYn/wLgGspbU x4551dPmdJDeK/MaG3AuM5Abn/pt2wPPisyjxb26aKSE+8nUai/YsfaO 2dKwZPzc3DYAg8kaKzfmyRKRuHCVi3AhHBQF49UFSrqoc56ohRoZzfR0 NmpLyhMO87rjxVuRpTz5kX4GHFIoVzfrsnba4W9TCqQqnIxDK/dV+blA iftcbu+9UNiHMO2YY0vUhNYbvkwlvUFldDHbUXd/B5yzLlwmp8bxLyVx qXlGYQ==

Will man den einen der beiden KSKs aus der Zone nehmen, setzt man das Inactivation- und Deletion-Datum entsprechend in der Zukunft, um den Schlüssel - ähnlich der zweiten Phase eines vollständigen Rollovers - nicht mehr zum Signieren zu verwenden, und nach einer einer weiteren Warteperiode (→ Caching resolver beachten!) aus der Zone zu entfernen.

In dieser ausführlichen Beschreibung sieht der Vorgang komplizierter aus als er eigentlich ist. Grundsätzlich sollte er auch zur Übung mit Zeiten der Kadenz (+10d) für die Testzone durchführbar sein, um für die Übung nicht zu viel Zeit zu verlieren.