Baby, roll it one more time …
DNS-Root-Zone und KSK-Rollover: Warum der erste Versuch scheiterte
Im Oktober 2017 sollte der für die Sicherheit des Domain Name Systems bedeutsame Hauptschlüssel erstmals im Rahmen üblicher Kryptografie-Hygiene getauscht werden. Nur zwei Wochen vor dem Termin mussten die Fachleute diesen Plan jedoch dringend verschieben, denn anscheinend waren einige wichtige Server nicht mit dem neuen Schlüssel bestückt. Heute ist klar, warum. Und es gibt einen neuen Plan.
Was war passiert? DNS-Entwickler hatten im August 2017 eine neue Version des BIND9-Servers veröffentlicht, der erstmals Telemetriedaten zur Verbreitung des neuen Hauptschlüssels der DNS-Root-Zone liefern sollte (Key Signing Key, KSK). Das war wichtig, denn DNS-Resolver, die ausschließlich den alten Schlüssel nutzen, während in der Root-Zone nur der neue steckt, können gar keine DNS-Anfragen mehr auflösen – für Teilnehmer, die einen solchen Resolver nutzen, ist das Internet kaputt. Vor allem die DNS-Resolver von Providern, die sehr viele Teilnehmer versorgen, hätten also parallel zum alten auch schon den neuen KSK per Telemetrie melden sollen, wenn sie den neuen BIND9-Server nutzten.
Der BIND9-Server lieferte die Telemetriedaten gemäß der noch frischen RFC-Spezifikation 8145. Und seine ersten Meldungen waren besorgniserregend: Obwohl der Schlüsselwechsel (Rollover) mit sehr langem Vorlauf geplant war, hatten manche großen Provider ihn anscheinend versäumt. Den Ergebnissen zufolge drohte der DNS-Dienst bei weltweit jedem vierten Internet-Nutzer auszufallen. Die ICANN sprach zwischenzeitlich von 750 Millionen potenziell Betroffenen.
Irreführende Telemetrie
Inzwischen weiß man, dass nicht alle Messwerte korrekt waren und man weiß auch, warum: Wenn Teilnehmer den BIND9-Server in Eigenregie im Forwarding-Modus zum DNS-Resolver des Providers betreiben und nur den alten Key installiert haben, wird das gemäß dem RFC 8145 fälschlich unter der IP-Adresse des Providers protokolliert. Richtig wäre, wenn in diesem Szenario die IP-Adresse des Kunden verzeichnet werden würde. So sieht es aber aus, als hätte der Provider den Key-Rollover versäumt. Das Problem ist also viel kleiner, als es im September 2017 noch schien.
In der Folge hatten ICANN-Mitarbeiter betroffene Provider mühsam per E-Mail und Telefon befragt, ob sie den KSK-Rollover vollzogen, also den neuen Vertrauensanker installiert haben. Das haben nun alle Befragten bejaht und die ICANN plant daher einen neuen Rollover-Anlauf für den 11. Oktober 2018.
Wer also einen modernen DNS-Resolver mit der Sicherheitstechnik DNSSEC verwendet und die kryptografisch geschützten Daten validiert, sollte unbedingt sicherstellen, das der Resolver den neuen Vertrauensanker nutzt. Es ist derselbe, der schon für Oktober 2017 eingeplant war und hat die Key-ID 20326.
Starthilfe
Betreiber können auf einer von der ICANN eingerichteten Webseite selbst prüfen, ob Ihr DNS-Resolver den neuen Vertrauensanker nutzt (siehe ct.de/y68z). Manche Resolver eignen sich für eine automatische Aktualisierung des Schlüssels. Falls diese scheitert, kann es je nach Resolver und dessen Konfiguration an verschiedenen Ursachen liegen. Für etliche gängige Resolver haben wir aufgeführt, woran es hapern kann und wie man die Problemchen beseitigt. Anleitungen für verbreitete Unix-, Linux- und Windows-DNS-Server finden Sie unter ct.de/y68z.
Das fehlerhafte Telemetrie-Protokoll RFC 8145 wird nun durch das neue Verfahren „KSK-Roll-Sentinel“ ersetzt (siehe ct.de/y68z). Für den KSK-Rollover im Oktober 2018 dürfte das neue Protokoll zwar zu spät kommen. Aber der bald laufende erste KSK-Rollover dürfte nicht der letzte sein. (dz@ct.de)
KSK-Rollover-Praxis:ct.de/y68z