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 neuens 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:

// include DNSSEC trust anchors
include "/etc/bind/bind.keys";

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:

named[10675]: set up managed keys zone for view internal, file '3bed2cb3a3acf7b6a8ef408420cc682d5520e26976d354254f528c965612054f.mkeys'

(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:

KEYDATA 20170721070630 20140301100110 19700101000000 257 3 8 (
        AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
        bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
        /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
        JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
        oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
        LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
        Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
        LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
        ) ; KSK; alg = RSASHA256; key id = 19036
KEYDATA 20170721070630 20170811070618 19700101000000 257 3 8 (
        AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
        iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
        7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
        LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
        efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
        pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
        A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
        9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
        ) ; KSK; alg = RSASHA256; key id = 20326

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:

server:
  # The following line will configure unbound to perform cryptographic
  # DNSSEC validation using the root trust anchor.
  auto-trust-anchor-file: "<%= @unbound_key_dir -%>/<%= @unbound_key_name -%>"

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 aktualiserte bind.keys-Version “zu Fuß” zu verteilen, zumindest für ältere Versionen.