DNSSEC Signierungs-Algorithmus wechseln


Eine DNS-Zone zu signieren ist mit heutiger Software nicht mehr schwierig oder kompliziert. Die Schwierigkeiten im Betrieb von signierten Zonen sind selten angewendete Prozeduren, wofür teilweise noch die Software-Unterstützung fehlt, sei dies in der Signierungssoftware oder in Monitoring- und Debugging-Tools. Eine solche selten angewendete Prozedur ist der Wechsel des DNSSEC Signierungs-Algorithmus.

Als SWITCH die DNSSEC-Signierung für die ccTLDs CH und LI im Jahr 2009 entwickelte und testete, entschied sie sich für den DNS Security-Algorithmus RSASHA1-NSEC3-SHA1 (RFC 5155). Aktuell ist der DNS Security-Algorithmus RSA/SHA-256 (RFC5702) einer der verbreitetsten Signierungs-Algorithmen unter TLDs (NANOG 56, E. Lewis), welcher auch von der Root-Zone verwendet wird. SWITCH hat in den letzten Wochen einen sogenannten Key Algorithm Rollover durchgeführt und auf den DNS Security-Algorithmus RSA/SHA-256 gewechselt.

Bevor wir die speziellen Anforderungen des Key Algorithm Rollover anschauen, hilft es, das Verfahren eines normalen Key Rollover zu verstehen. Ein Key Rollover kann aus operationellen Gründen nötig sein (z.B. gemäss dem DNSSEC-Policy and Practice Statement, RFC 6841) oder aus Sicherheitsgründen, wenn ein oder mehrere Schlüssel kompromittiert wurden. Für einen Key Rollover stehen mehrere Methoden zur Verfügung, welche alle das Ziel haben, einen Schlüssel auszutauschen. Wobei die Zonen-Einträge respektive deren Signaturen während dieser Zeit stets validieren sollen.

ZSK-Rollover
Eine effiziente Methode um den Zone Signing Key (ZSK) auszutauschen ist die Pre-Publication Methode (RFC 4641bis (draft)), weil die Zonengrösse während des Rollovers nicht zunimmt.

Der Trick dieser Methode ist, dass der neue DNSKEY vor der aktiven Nutzung im DNSKEY-Set der Zone hinzugefügt wird. Wenn garantiert werden kann, dass alle DNS-Resolver sowohl den neuen wie auch den alten DNSKEY im Cache haben, wird der aktive ZSK zum signieren geändert. Der alte DNSKEY wird erst aus der Zone entfernt, nachdem Signaturen vom alten ZSK aus den Caches abgelaufen sind.

Für den ZSK-Rollover gibt es noch weitere Methoden wie Double-Signature oder Double-RRSIG. Beide Methoden haben aber den Nachteil, dass die Anzahl Signaturen während des Rollover verdoppelt werden. Für grosse Zonen wie z.B. die ccTLD CH eignen sich diese Methoden deshalb weniger. In einer Key Rollover Prozedur wechselt man auch den Key Signing Key (KSK) aus. Die möglichen Methoden für den KSK-Rollover sind hier nicht erwähnt und beschrieben, können aber im RFC 4641bis (draft) nachgelesen werden.

Key Algorithm Rollover
Will man den Signierungs-Algorithmus austauschen, kann man nicht die oben erwähnten Methoden anwenden. RFC 4035 im Kapitel 2.2 spezifiziert folgende Voraussetzung:

There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.

Das heisst soviel wie, dass man Signaturen für alle publizierten DNS Signierungs-Algorithmen benötigt. Würde man z.B. die Pre-Publication Methode für den ZSK-Rollover anwenden, so publiziert man den neuen Signierungs-Algorithmus bevor man diesen nutzt. Dies widerspricht der oben erwähnten Spezifizierung. In der Praxis führt dies auf DNS-Resolvern, welche z.B. mit der Software Unbound laufen, zu Validierungsfehlern. ISC BIND ist hier weniger strikt und zeigt keinen Validierungsfehler an.

Der Key Algorithm Rollover gemäss RFC 4641bis (draft) publiziert deshalb die Signaturen des neuen ZSK bevor der DNSKEY publiziert wird. Erst wenn garantiert werden kann, dass im Cache eines DNS-Resolvers sowohl die Signaturen des alten und neuen ZSK existieren, wird der neue ZSK publiziert. Damit wird die Voraussetzung aus RFC 4035 im Kapitel 2.2 erfüllt. Dasselbe Vorgehen ist nötig um den alten ZSK aus dem DNSKEY-Set zu entfernen. Zuerst wird der alte ZSK aus dem DNSKEY-Set entfernt und erst, wenn garantiert werden kann, dass im Cache eines DNS-Resolvers nur noch der DNSKEY des neuen ZSK existiert, können die Signaturen des alten ZSK entfernt werden.

Der Algorithm Rollover hat einen wesentlichen Nachteil. Während der Rollover-Prozedur werden die Zonen-Einträge doppelt signiert. Diese Tatsache ist für grosse Zonen wie die ccTLD CH einschneidend, deshalb ist eine gute Planung Voraussetzung. Für Zonen mit weniger als einer 6-stelligen Zahl von Zonen-Einträgen ist diese Tatsache aber nicht erheblich.

Empfehlung
Der DNSSEC-Standard wird sich in den nächsten Jahren weiterentwickeln und neue Algorithmen und Verfahren werden in die Produkte eingepflegt. Wenn Sie für Ihre DNSSEC-Zone in nächster Zeit einen anderen Signierungs-Algorithmus verwenden möchten, sollten Sie die Produkt-Unterstützung für einen Algorithm Rollover prüfen. Grundsätzlich steht es Ihnen natürlich auch frei, die Zone neu zu signieren und so einem Algorithm Rollover auszuweichen. Setzen Sie DNSSEC-Monitoring oder Debugging-Tools ein, ist auch hier eine Abklärung für geplante Prozeduren sinnvoll. Bekannte Tools wie „dig“ (mit Option +sigchase) oder der DNSViz erkennen momentan einen Algorithm Rollover nicht und können Warnungen anzeigen, die zu keinem Fehler führen und deshalb, wenn richtig interpretiert, ignoriert werden können.