DNSSEC: KSK in der root-Zone
Es steht ja nun schon einige Zeit im Raum, aber langsam wird es konkret: In der DNS Root Zone wird es einen KSK Rollover geben. KSK Rollover sind jetzt nichts so besonderes - ich habe selbst durchaus schon einige davon mitgemacht, aber wenn das die weltweit wichtigste DNS-Komponente überhaupt betrifft, dann ist das natürlich eine etwas andere Hausnummer.
Nachdem sich der Trust Anchor ändert, ist es natürlich auf allen DNSSEC-fähigen
Resolvern notwendig, sich darum zu kümmern, diesen neuen Trust Anchor auch lokal
einzupflegen. Dazu gibt es aber eine gute Nachricht: Wie in diesem
Link
beschrieben muss man zumindest bei BIND erstmal nicht viel machen. Hat man in
der Konfiguration auf managed-keys
gesetzt, so sollte sich der Nameserver
selber über das in IETF RFC 5011
definierte Verfahren einen neuen Trust Anchor suchen. Netterweise liefert ISC
den BIND schon seit mindestens Version 9.8 mit einer Version der Datei
bind.keys aus, welche das richtig
macht. Eingebunden wird die via:
|
|
Leider loggt BIND nicht wirklich etwas, wenn er den Key aktualisiert. Allerdings
ist es kein großes Problem, einfach in die relevanten Files in Cache zu schauen.
Verwendet ein System keine Views, dann sucht man nach einem File namens
managed-keys.bind
. Verwendet man Views, dann loggt BIND beim starten brav, wo
er den Kram ablegt:
|
|
(Hinweis: Modernere BIND-Inkarnationen sparen es sich, den Filenamen zu hashen, wenn der View-Name nur für einen Filenamen gültige Zeichen enthält).
In diesem File erwartet man nun drei Einträge für Trust Anchors: Einen für die mittlerweile obsolete DLV Registry und zwei für die root-Zone:
|
|
Bei dem Key 19036 handelt es sich um den alten Key, 20326 ist der neue, welcher dieses Jahr aktiv gehen soll.
Auch bei Unbound funktioniert das Update relativ gut, sofern der Server Schreibrechte auf das Key-File hat. Ich verwende die folgende Konfiguration:
|
|
Dabei kümmert sich Puppet darum, dass das Verzeichnis @unbound_key_dir
und
auch das Key-File @unbound_key_name
dem User unbound
gehören. Auch Unbound
hat erwartungsgemäß keine Probleme damit gehabt, den neuen Trust Anchor zu
erlangen.
Was ich noch hinzufügen möchte: RFC5011 erfordert immer, dass man zumindest
einen gültigen Trust Anchor hat. Das heisst, es wäre schon angebracht, sich
darum zu sorgen, dass neue Installationen hier ein aktuelles File bekommen. Im
Fall von Unbound wird man den Key wahrscheinlich eh mit einem Aufruf von
unbound-anchor -a
erzeugen, und im Fall von BIND bietet es sich an, die
aktualisierte bind.keys
-Version “zu Fuß” zu verteilen, zumindest für ältere
Versionen.