- Alle Räder stehen still, wenn Dein starker Arm das will
- Kommentar zu aktuellen Hypes um DNS
- HTTPS Absicherung mit DANE durch Middleboxen
- Bereit zum Wechsel des Schlüssels der Root Zone?
- Der Hauptschlüssel des Internets wird gewechselt
- Outsourcing mit Hindernissen
- DNS(SEC) Fehler bei einer Versicherung
Bereit zum Wechsel des Schlüssels der Root Zone?
Während der ICANN Diskussionen@AtLarge kam die Frage auf, wie man als einfacher Nutzer testen kann, ob man von dem DNSSEC Key Rollover der Root Zone betroffen ist. Das ist erstaunlich schwierig oder vollkommen trivial. Je nachdem was man will.
Das Rollover Problem
DNSSEC funktioniert im Grundsatz so, dass die Elternzone einen Verweis auf den aktiven Schlüssel der Kindzone setzt. Auf diese Weise kann man in der Kindzone der Schlüssel leicht gewechselt werden, indem man parallel den Verweis in der Elternzone aktualisiert.
Für die Root-Zone ist es nicht so einfach, weil es schlicht keine Elterzone für die Root gibt. Das Schlüsselmaterial der Root kommt stattdessen aus den (Festplatten-)Speichern der Resolver-Server. Aber wie kommt es da rein?
Zum einen kann man das Schlüsselmaterial manuell eintragen. Das hat man anfangs auch gemacht. Die Daten fanden sich in Zeitungen, auf Webseiten etc. pp. Inzwischen wird das Schlüsselmaterial von den Software- / Betriebssystemherstellern vorinstalliert mit ausgeliefert. Eine noch andere Möglichkeit besteht darin, während der Erstinstallation den aktuellen Schlüssel ungeprüft abzurufen und zu speichern.
Das Problem besteht nun darin, den Schlüssel zu wechseln. Die Abermillionen von Installationen müssen also neue Schlüsseldaten bekommen. Normalerweise eine unmögliche Aufgabe. Seit einigen Jahren gibt es aber ein automatisiertes Verfahren: RFC5011. Im Kern besagt der RFC, der Resolver soll alle Schlüssel, die er mit Hilfe der bekannten Schlüssel validieren kann, abzuspeichern hat. Damit kennt und vertraut er den neuen Schlüsseln, sobald er sie sieht.
Ob das in der Praxis funktioniert, wurde nicht wirklich getestet. Dieser Root KSK Rollover ist der erste Versuch, das zu tun. Und natürlich muss man damit rechnen, dass es schief geht. Es kann aus ganz unterschiedlichen Gründen schief gehen, z.B. könnte der Festplattenbereich durch den Resolver nicht beschreibbar sein.
Wenn es schief geht, kann der Resolver keinerlei DNS Anfragen mehr beantworten. Gar keine. Und nun stelle man sich vor, dieser betroffene Resolver steht bei einem großen Internetprovider: Es gibt einen Blackout für alle Kunden dieses Providers.
Konsequenzen
Wie viele solche Resolver es gibt, ist nicht bekannt. ICANN hat also beschlossen, den für letzten Oktober geplanten Rollover auszusetzen.
Neuere Methoden, ob ein Resolver den neuen Schlüssel schon gelernt hat, wurde in den letzten Monaten entwickelt und ausgerollt. Allerdings ist die Verbreitung dieser neuen Methoden auf die gut gepflegten Systeme beschränkt, die sowieso kein Problem mit dem Rollover haben werden. Eine Aufklärung des problematischen Dunkelfelds ist nicht zu erwarten.
Nun steht die Frage im Raum, ob und wann ein neuer Anlauf genommen wird. Neue Daten sind jedenfalls nicht zu erwarten.
Andererseits besteht das Problem, dass immer mehr Geräte auf den Markt kommen, die gar nicht in der Lage sind einen Root Schlüssel zu wechseln. Hier stehen die vielen unsupporteten IoT-Geräte im Vordergrund. Je länger man also mit dem Rollover wartet, desto mehr Anbieter können einen Rollover ignorieren. Nur ein regelmäßiger Wechsel zwingt die Industrie und die Admins zu eine korrekten Vorgehensweise.
Ängste
Das Thema ist emotionsgeladen:
- Will ich riskieren, dass mein Internet ausfällt?
- Wer wird mich (als Admin) verantwortlich machen, wenn es zu Ausfällen kommt?
- Wer wird mich (als ICANN) verantwortlich machen, wenn es zu Ausfällen kommt?
- Wie viele Leute werden einfach DNSSEC ausschalten, anstatt das Problem richtig zu beheben?
Dazu muss vorrangig die Frage beantwortet werden, ob man überhaupt betroffen ist.
Dazu gibt es eigentlich nur zwei Fälle:
- Mein ISP (Resolver) kann DNSSEC und validiert. Dann kann es passieren, dass der KSK Rollover schief geht.
- Mein ISP (Resolver) validiert DNSSEC nicht. Dann betrifft der Rollover mich (und ihn) gar nicht.
Um diese beiden Fälle einfach zu überprüfen, habe ich auf Anregung von Alan Greenberg eine Webseite erstellt, die den aktuellen Stand beim Nutzer ermittelt und den betreffenden Fall anzeigt.
Wie man den Stand von DNSSEC ermittelt
Natürlich kann man nicht aktiv DNS im Browser sprechen, um diese Fälle zu unterscheiden. Eine aktive Programmierung jeder Art fällt also schon mal flach.
Was man aber machen kann, ist Teile der Webseite so abzulegen, dass ein DNSSEC validierender Resolver diese nicht abrufen kann. Ich habe mich dazu entschieden eine Webseite mit unterschiedlichem CSS zu machen.
<link rel="stylesheet" href="dnssec.css"> <link rel="stylesheet" href="http://css.fail.donnerhacke.de/dnssec-fail.css">
Der zweite Teil des CSS überschreibt die vorherige Einstellung:
$ cat dnssec.css
.failed { display: none; }
.dnssec { display: block; }
$ cat dnssec-fail.css
.failed { display: block; }
.dnssec { display: none; }Er kann aber nur abgerufen werden, wenn der Resolver keine DNSSEC Validerung macht.
Um das hin zu bekommen, muss absichtlich ein stabiler Fehler im DNSSEC-Setup erzeugt werden. Der Fehler muss so stabil sein, dass er den normalen Betrieb und automatische Korrekturmaßnahmen überlebt. Ich habe mich zu einer fehlerhaften Delegation entschieden:
$ORIGIN donnerhacke.de. fail NS avalon.iks-jena.de. NS broceliande.iks-jena.de. DS 12345 8 2 1234...
Die delegierte Zone ist dann nicht signiert, obwohl die Elternzone behauptet, sie müsse es sein.
Das schaut dann so aus:
Ein validierender Resolver kann das nicht auflösen und antwortet:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10476 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;css.fail.donnerhacke.de. IN AAAA ;; Query time: 49 msec ;; SERVER: 100.100.100.100#53
Ein nicht validierender Resolver kommt dagegen zu folgendem Ergebnis:
donnerhacke.de. NS avalon.iks-jena.de. donnerhacke.de. NS broceliande.iks-jena.de. ;; Received 185 bytes from 2001:678:2::53#53(a.nic.de) in 25 ms css.fail.donnerhacke.de. CNAME pro.donnerhacke.de. pro.donnerhacke.de. AAAA 2001:4bd8:1:1:209:6bff:fe49:79ea donnerhacke.de. NS broceliande.iks-jena.de. donnerhacke.de. NS avalon.iks-jena.de. ;; Received 219 bytes from 2001:4bd8:52:1:20a:e4ff:fe80:bec8#53(broceliande.iks-jena.de) in 1 ms
Die abgerufene Webseite wird also, in Abhängigkeit von den DNSSEC-Fähigkeiten des Resolvers, unterschiedlich aussehen.
Und nun gehe hin und teste Deinen Resolver: *click*