Seite 4: DNSSEC-Schlüsselpositionen

Inhaltsverzeichnis

Schlüsselpositionen

Den ZSK zu erneuern ist zumindest auf Linux-Rechnern, auf denen die wesentlichen DNSSEC-Techniken und Programme etabliert wurden, nicht sonderlich schwierig. Mit Hilfe der Tools, die zu Nameservern wie BIND oder Unbound gehören, erzeugt man einen neuen Schlüssel, fügt ihn der Zonendatei hinzu, signiert den Eintrag mit einem gültigen KSK und schon kann er verwendet werden – jedenfalls in der Theorie. In der Praxis muss man wegen der auf vielen Ebenen verteilten DNS-Caches teilweise sehr lange warten, bis ein ZSK-Update überall angekommen ist, sodass man den neuen Schlüssel nicht sofort nutzen kann.

Ab wann er sich schadlos nutzen lässt, kann man aber hinreichend genau anhand von TTL-Werten der Einträge in der Zonendatei bestimmen (Time To Live, Dauer der Gültigkeit). Die TTL kann zwar durchaus auf mehrere Jahre gesetzt werden (maximal sind 232–1 Sekunden möglich !!!soll heissen 2 hoch 32 -1), aber das ist nicht empfehlenswert. Üblicherweise beträgt die TTL 24 Stunden. Beim ZSK-Wechsel geht man in der Praxis vom doppelten Wert der längsten in der Zonendatei verwendeten TTL aus. Bis dahin sollten alle interessierten Resolver (Namensauflöser) den neuen ZSK verinnerlicht haben – und erst ab diesem Zeitpunkt signiert man alle Daten mit dem neuen ZSK. Den alten ZSK belässt man noch in der Zonendatei, damit alte, in Caches befindliche Signaturen noch eine Weile gültig sind. Erst wenn ein weiterer TTL-Zyklus verstrichen ist, tilgt man den alten ZSK aus der Zonendatei.

Wenn während der TTL-Wartefrist DNS-Anfragen eingehen, entsteht eine knifflige Situation, denn die neue Signatur gilt ja noch nicht und die alte würde erneut bei irgendeinem Resolver im Cache landen und so die Frist verlängern. Die DNSSEC-Väter haben sich aus dieser Klemme herausgewunden, indem sie für eine Weile gleichzeitig zwei gültige Schlüssel zugelassen haben – den alten und den aktuellen. Während der TTL-Frist werden nun alle Antworten mit beiden Schlüsseln signiert und beide Signaturen mit der Antwort geschickt. Ein Resolver, der den alten Schlüssel im Cache hat, kann damit also die Antwort wie bisher verifizieren. Ein Resolver, der den alten Schlüssel nicht hat, kann die Antwort mit einem der beiden Schlüssel verifizieren. In beiden Fällen legen die Resolver aber beide Schlüssel in den Cache ab. Wenn dann bei der nächsten Anfrage die Signatur mit dem alten Schlüssel fehlt, hat der Resolver bereits den neuen und kann damit die Antwort verifizieren.

Bei der Erneuerung des KSK muss man äußerste Vorsicht walten lassen, denn Fehler können komplette Domains lahmlegen und das unter Umständen für sehr lange, wenn der TTL-Wert hoch ist. Der Vorgang ähnelt aber der ZSK-Erneuerung – man erzeugt einen neuen Schlüssel, fügt ihn der Zonendatei hinzu und signiert ihn dort mit dem alten KSK. Zusätzlich muss der neue KSK aber auch alle anderen KSK und alle ZSK der betreffenden Zone signieren. Anschließend wartet man wieder eine TTL-abhängige Frist ab und kontaktiert dann die Registry, damit dort der neue KSK aufgenommen wird. Nach einer weiteren Wartezeit kann der alte KSK entfernt werden.