Domain Name System: Vorsichtsmaßnahmen für den DNS-Schlüsseltausch

Sollte es Angreifern gelingen, einen DNSSEC-Schlüssel zu knacken, können sie glaubwürdig aussehende, aber falsche DNS-Antworten verbreiten. Damit lassen sich zum Beispiel Zugriffe auf Online-Banken an präparierte Server umlenken.

Deshalb müssen DNSSEC-Schlüssel ab und zu gewechselt werden. Das steht am 11. Oktober für die DNS-Root-Zone an. Genauer: Ab diesem Stichtag müssen Provider und überhaupt alle Betreiber von DNS-Resolvern, die die Sicherheitstechnik DNSSEC verwenden, einen neuen Vertrauensanker nutzen. Andernfalls fällt ihr DNS-Dienst aus. Und ohne DNS funktionieren moderne Internet-Services nicht – Teilnehmer, die DNS-Anfragen an einen solchen Resolver senden, sind dann vom Internet weitgehend abgeschnitten.

Richtig oder falsch?

Weltweit sind viele Millionen DNS-Resolver mit DNSSEC im Einsatz. Diese prüfen anhand von DNSSEC-Signaturen, ob DNS-Antworten unverfälscht sind und ob sie aus einer vertrauenswürdigen Quelle stammen (Validierung). In Deutschland sind zurzeit rund ein Viertel der Teilnehmer von validierenden Resolvern abhängig. Die wichtigsten stehen bei den Providern.

Aber einen Resolver kann jeder Internet-Teilnehmer auf eigene Faust betreiben. Das ist generell nützlich, zum Beispiel, um die DNS-Abfrage zu beschleunigen oder um die Privatsphäre zu wahren. Denn Betreiber können sehen, welche Ziele die Rechner im Internet ansteuern, die deren Resolver befragen. Deshalb setzen auch Firmen- und Heim-Administratoren eigene Resolver ein. Zu beachten ist, das auch manche Router validierende Resolver nutzen. Das kann auch ohne Wissen des Eigners der Fall sein.

Doch bis zum Stichtag ist nun noch eine Woche Zeit. Falls Sie selbst einen validierenden Resolver betreiben, prüfen Sie, ob er den neuen Vertrauensanker schon hat. Geben Sie die Information an Kollegen und Bekannte weiter. Was genau zu tun ist, haben wir ab dem Abschnitt „Validierende Resolver richtig konfigurieren“ zusammengefasst.

Die ICANN, die für den Schlüsselwechsel zuständig ist, hat bisher keine Erfahrungen damit, sie tauscht diesen Schlüssel das erste Mal. Dabei ist der Schlüsselwechsel in der Root-Zone kein Problem. Den neuen Schlüssel hat die ICANN längst publiziert (Trust Anchor). Das Problem ist die Verteilung des neuen Trust Anchor an die Resolver-Betreiber. Einen ersten Anlauf hatte die ICANN bereits 2017 unternommen und ganz knapp vor der Umsetzung abgebrochen. Laut ersten Telemetriedaten hatten noch zu wenige Resolver den neuen Trust Anchor verwendet. Die ICANN musste von weltweit bis zu 750 Millionen potenziell Betroffenen Internet-Teilnehmern ausgehen.

Fehlkonfigurierte Resolver

Die Organisation hat in der Folge die Provider mit fehlkonfigurierten Resolvern kontaktiert und diese geben nun an, den neuen Vertrauensanker eingerichtet zu haben. Deshalb geht die ICANN von einem reibungslosen Schlüsselwechsel aus. Aktuell sind weltweit mehr als eine Million Resolver-Instanzen eingerichtet, die Telemetriedaten senden (Bind9 und Unbound). Davon melden allein in Deutschland zwar 0,05 Prozent nur den alten Vertrauensanker – was immer noch zu viele wären, wenn es sich um Resolver von Providern handelte.

Doch den verwendeten IP-Adressen zufolge muss es sich um Firmen- oder Heim-Administratoren handeln, die diese Resolver wissentlich oder unwissentlich betreiben. Diese zu kontaktieren wäre für die ICANN ein zu hoher Aufwand. Um so wichtiger ist, dass Heim- und Firmen-Admins ihre Resolver-Konfiguration prüfen.

Warum der DNS-Dienst scheitert

Andernfalls scheitert ab dem 11.10.2018 deren DNS-Auflösung. Zwar sind weltweit sehr viele Domains nicht per DNSSEC abgesichert (nicht signiert), aber es spielt keine Rolle, ob Nutzer signierte oder unsignierte Domains ansteuern – in beiden Fällen können sie durch einen fehlkonfigurierten, validierenden Resolver weitgehend vom Internet abgeschnitten werden.

Der Grund ist einfach: Wenn ein Resolver die Sicherheitstechnik DNSSEC verwendet, muss er signierte DNS-Antworten validieren. Das ist bei DNS-Antworten von der Root-Zone und den Top-Level-Domains zwangsläufig der Fall, denn diese sind signiert. Um die Signaturen prüfen zu können, braucht er den gültigen Trust Anchor (Vertrauensanker). Davon gibt es aktuell zwei: einen neuen, der seit dem 2. Februar 2017 gilt (Seriennummer 20326) und einen alten, dessen Gültigkeit am 11.10. ausläuft (Seriennummer 19036).

Fehlt dem validierenden Resolver der neue Trust Anchor, kann er ab dem 11.10.2018 keine DNS-Antworten der Root-Zone und der zugehörigen Top-Level-Domains validieren. Damit darf er DNS-Antworten, die von diesen DNS-Servern kommen, nicht verwenden. Deshalb findet er weder die Adressen von angefragten Top-Level-Domains, noch die der zugehörigen Domains oder Subdomains. Er kann schlicht gar keine DNS-Antworten liefern. Für Geräte, die einen solchen Resolver befragen, ist das Internet kaputt. Bis der Resolver-Betreiber das Problem beseitigt hat, kann man sich mit einem Wechsel auf andere DNS-Resolver behelfen, und etwa die von Google oder Cloudflare verwenden.

Validierende Resolver richtig konfigurieren

Aktuell verwenden in Deutschland rund 26 Prozent der Internet-Nutzer einen validierenden DNS-Resolver. Das geht aus einer Analyse des APNIC hervor. Der Anteil schwankt von Monat zu Monat. Den bisherigen Höchstwert von 42 Prozent verzeichnete das APNIC Anfang 2016. Im April 2017 betrug der Anteil rund 39 Prozent. Anscheinend schalten einige Provider die Validierung mal ein und mal wieder aus. Gründe nennen sie nicht; natürlich sind Testläufe als Ursache denkbar.

Der Schlüsseltausch eines DNS-Resolvers kann aus diversen Gründen scheitern:

• Der Resolver holt den neuen Trust Anchor nicht automatisch (RFC 5011) oder ist auf manuelle Administration der DNSSEC-Schlüssel eingestellt. Beispielsweise administriert Google den Vertrauensanker manuell.

• Der DNS-Resolver lädt den neuen Vertrauensanker zwar, kann ihn aber nicht speichern. Das kommt vor, wenn das Dateisystem voll ist, nur lesend eingehängt ist oder dem DNS-Resolver-Prozess die Schreibrechte fehlen. Das Verhalten kann gewünscht sein – jedenfalls fällt es im normalen Betrieb nicht auf, da Resolver üblicherweise keine Dateien speichern.

• Der DNS-Resolver hat eine eigene Kopie der DNS-Root-Zone und spricht daher nicht mit der DNS-Root-Zone.

• Der DNS-Resolver soll zwar den Schlüssel gemäß RFC 5011 automatisch aktualisieren, aber er ist nicht ausreichend lange durchgängig online (30 Tage sind erforderlich) und kann daher den Austausch nicht abschließen.

• Der DNS-Resolver wird von einer älteren Linux- oder Unix- Distribution installiert, die nur den alten Vertrauensanker enthält.