DNS-Schlüsselwechsel: Am 11.10. ist es so weit

  • Allgemein

  • mad.de
  • 642 Aufrufe 0 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • DNS-Schlüsselwechsel: Am 11.10. ist es so weit

    Der Countdown läuft, am kommenden Donnerstag wird der DNS-Vertrauensanker gewechselt. Je mehr Nutzer davon wissen, desto glatter sollte es laufen.

    Am 11. Oktober tauscht die Internet Corporation for Assigned Names and Numbers (ICANN) den Trust Anchor des Domain Name System aus, den Vertrauensanker. Wenn alles wie geplant abläuft, wird niemand etwas davon bemerken. Wenn nicht, dann fällt für manche Nutzer der Internet-Dienst weitgehend aus.
    Denn bevor ein PC oder Smartphone einen Server im Internet erreichen kann, braucht er dessen Internet-Adresse. Diese erhält er normalerweise, indem er dem DNS-Resolver des Providers die Ziel-Domain mitteilt (zum Beispiel ct.de). Der Resolver befragt dann den für diese Domain zuständigen DNS-Server und liefert dem anfragenden PC oder Smartphone die zugehörige IP-Adresse (zum Beispiel 193.99.144.80). Bleibt der Resolver stumm, kann der PC das Ziel nicht ansteuern. Und genau dieses Fehlerbild könnten manche DNS-Resolver ab dem 11. Oktober verursachen.

    Schwedische Domäne
    Der DNS-Verkehr ist nicht verschlüsselt, DNS-Antworten können aber signiert sein (DNSSEC). Die Signaturen können DNS-Resolver nutzen, um die Echtheit der DNS-Antworten und die Vertrauenswürdigkeit des zuständigen DNS-Servers zu validieren. Laut ICANN-CTO David Conrad hängt der Internet-Dienst für weltweit rund 25 Prozent aller Nutzer von validierenden Resolvern ab. Die wichtigsten Resolver stehen bei den Providern.
    Von den insgesamt 1536 in der Root-Zone verzeichneten Domains (.de, .com, .net) sind laut aktueller ICANN-Statistik derzeit 1400 signiert. Die meisten signierten Domains sind in der schwedischen Adresszone aufgeführt: 1,2 Millionen von 1,7 Millionen se.-Domains sind per DNSSEC abgesichert. Schweden hat DNSSEC als weltweit erstes Land eingeführt.
    Für die Validierung brauchen Resolver den Vertrauensanker (kryptografischer Schlüssel). Haben sie nach dem Stichtag nur den alten, scheitert die Validierung und sie müssen die erhaltenen DNS-Antworten verwerfen. Das ist schwerwiegender, als es zunächst klingt: Weil die Root-Zone und auch viele Top-Level-Domains signiert sind, muss ein solcher Resolver auch deren DNS-Antworten verwerfen. So kann er aber nicht den für die angefragte Domain zuständigen DNS-Server finden. Dabei spielt es keine Rolle, ob die angefragte Domain signiert ist oder nicht. Geräte, die diese Resolver befragen, sind dann weitgehend vom Internet abgeschnitten, denn sehr viele moderne Anwendungen setzen auf dem Domain Name System auf.

    Zweiter Anlauf
    Weil der Austausch von Schlüsseln zu einer guten Kryptographiehygiene gehört, war der Wechsel des Vertrauensankers (Key Rollover) seit Signierung der Root-Zone im Jahr 2010 beschlossene Sache. Entsprechend hat die ICANN den Schlüsseltausch mit viel Vorlauf und akribisch vorbereitet. Eigentlich sollte er schon am 11. Oktober 2017 ablaufen. Er musste aber knapp vor dem Stichtag abgeblasen werden, denn Analysen zufolge hatten viele validierende Resolver nur den alten Vertrauensanker. Mittlerweile geht die Netzverwaltung von allenfalls minimalen Problemen bei Providern aus.
    Bei den Analysen kamen unter anderem teils fehlerhafte Implementierungen ans Licht, deaktivierte oder aus anderen Gründen scheiternde automatische Updates in den Resolvern und andere Probleme. Einige Fehlerquellen wurden innerhalb des vergangenen Jahres behoben.
    Zwar müsse man davon ausgehen, dass rund um den Globus immer noch ein paar Resolver-Betreiber nicht vorbereitet sind, sagte ICANN-CTO Conrad. Doch laut APNIC-Forscher Geoff Huston haben im April dieses Jahres allenfalls 0,05 Prozent aller Nutzer solche Resolver konfiguriert (siehe dazu seine Analyse der Telemetrie-Daten Measuring Root Zone KSK Trust). Die ICANN listet aktuell rund 24.000 einzelne IP-Adressen, die seit September 2017 mindestens einmal nur den alten Vertrauensanker gemeldet haben. Die Dunkelziffer dürfte weit höher liegen, weil bisher nur die beiden Resolver BIND9 und Unbound Telemetriedaten liefern.

    24.000 IP-Adressen melde alten Vertrauensanker
    Das klingt nach viel und ist für jeden Betroffenen ein ernstes Problem. Auf den allgemeinen Internet-Betrieb sollten sich die noch immer nicht aktualisierten Resolver aber nicht auswirken. Die Provider sind sicher, dass ihre aktualisiert sind. Übrig bleiben sollten dann nur Resolver bei Unternehmen, Entwicklern und Nutzern von Routern, die solche Resolver mit oder ohne Wissen betreiben. Viele der 24.000 IP-Adressen tauchen nicht regelmäßig in den Telemetriedaten der ICANN auf, wie man es bei dauerhaft betriebenen Resolvern erwartet, sondern nur gelegentlich. Man kann mutmaßen, dass solche Resolver in gelegentlich gestarteten virtuellen Maschinen oder Docker-Containern stecken. Welche Ursachen die Aktualisierung verhindern können und wie man die Probleme beseitigt, haben wir kürzlich im Beitrag Domain Name System: Vorsichtsmaßnahmen für den DNS-Schlüsseltausch zusammengefasst.
    Der Schlüsselaustausch ist gut vorbereitet und getestet. Dennoch sollte man nicht vergessen, dass eine solche Infrastruktur-Änderung am Internet noch nie durchgeführt worden ist. Das macht den 11. Oktober nicht nur für Internet-Veteranen spannend. Drücken Sie die Daumen und informieren Sie potenzielle Resolver-Betreiber in Ihrem Bekanntenkreis. Es ist wichtig, dass möglichst viele Nutzer auf den Wechsel des Vertrauensankers vorbereitet sind. Wes Hardacker, ein an Telemetrieanalysen beteiligter Spezialist des Information Sciences Institute an der University of Southern California betont: Je mehr Information über den Key Rollover in Umlauf kommt, desto wahrscheinlicher ist, dass die Dinge glatt laufen.

    Quelle: DNS-Schlüsselwechsel: Am 11.10. ist es so weit |
    heise online

    Update 11.10.2018:

    DNS-Schlüsselwechsel: Wie man DNS-Ausfälle erkennt, was dagegen hilft

    Am 11.10. wechselt die ICANN den DNS-Vertrauensanker. Dabei kann es zu Ausfällen von Internet-Diensten kommen. Wir fassen zusammen, was dagegen hilft.

    Am 11.10.2018 läuft die Gültigkeit des aktuellen Vertrauensankers aus und ab dann gilt nur noch der neue, der längst schon im Umlauf ist. Die Umstellung hat die ICANN akribisch vorbereitet, sodass eigentlich nichts schief gehen sollte.
    Es kann aber auch zu Ausfällen des Domain Name System kommen (DNS). Dann funktionieren die allermeisten Internet-Dienste nicht mehr. Beispielsweise stützen sich Mail-Clients, Messenger, Web-Browser und viele andere Programme auf das DNS. Beim Schlüsselwechsel ist der DNS-Resolver die Achillessehne des DNS – fehlt einem Resolver der neue Vertrauensanker, kann er DNS-Anfragen von Internet-Geräten nicht zu IP-Adressen auflösen. Und ohne die IP-Adressen können die Geräte keine Ziele im Internet ansteuern.
    Warum das so ist, haben wir zum Beispiel an dieser Stelle ausführlich beschrieben. Für Administratoren, die validierende Resolver betreuen, haben wir im Beitrag " Vorsichtsmaßnahmen für den DNS-Schlüsseltausch" zusammengefasst, woran es beim Schlüsselwechsel hapern kann und wie man den fehlenden neuen Vertrauensanker nachrüstet.

    Der alte Schlüssel wird um 11.10.2018,16:00 Uhr UTC aus dem Domain Name System entfernt (Coordinated Universal Time). In Europa entspricht das 18:00 Uhr CEST (Central European Summer Time). Resolver, die den Anker noch im Cache haben, dürfen ihn entsprechend seinem TTL-Eintrag dann noch 48 Stunden lang nutzen, bevor sie ihn tilgen. Erst wenn diese allerletzte Frist abgelaufen ist, dürften sich also lauernde Probleme manifestieren. Das betrifft den Zeitraum vom 11.10.2018, 18:00 Uhr bis zum 13.10.2018, 17:59.

    Die wichtigsten und größten Resolver bezogen auf die Anzahl der versorgten Teilnehmer unterhalten die Internet-Provider. Diese sind auf den Schlüsselwechsel vorbereitet; darauf deuten Telemetriedaten der ICANN hin. Resolver kann aber jede Firma unterhalten und auch jeder Nutzer. Solche Resolver können in virtuellen Maschinen, in Docker-Containern, in Routern und sogar in VPN-Clients stecken. Seit September 2017 hat die ICANN weltweit 24.000 IP-Adressen gezählt, die einen Resolver mit veraltetem Vertrauensanker melden. Die Dunkelziffer dürfte höher liegen, weil nur die Resolver Bind9 und Unbound Telemetriedaten senden.
    Manche Nutzer und auch Administratoren treffen nun Vorkehrungen für den Fall, dass sie am Stichtag ein Resolver hängen lässt. Dafür kann man Rufnummern von Kollegen bereithalten, mit denen man sich über Probleme austauschen will oder auch Debugging-Tools zusammenstellen auf dem Laptop. Für Reisende, die mit sehr leichtem Gepäck unterwegs sind, sind Monitoring-Tools für Smartphones empfehlenswert. Eine Liste solcher Anwendungen für Android und iOS finden Sie im c't-Artikel "Mobile Paketprüfer, Netzwerk-Analyse-Tools für Android und iOS".

    VPN-Dienste, Hosts-Datei, VoIP-Telefonie
    Für VPN-Clients gilt: Aktualisieren Sie die Software möglichst noch vor dem Stichtag. Telemetriedaten zufolge gibt es mindestens einen VPN-Anbieter, der in seinen iOS- und Android-Clients einen validierenden Resolver mit veraltetem Vertrauensanker verwendet hat. Dafür gibt es seit einigen Wochen Updates. ICANN kann bisher nicht angeben, um welchen VPN-Anbieter es sich handelt, sodass sicherheitshalber jeder VPN-Client aktualisiert werden sollte.
    Auf einem PC könnte theoretisch helfen, die IP-Adressen der wichtigsten Domains im Internet zu notieren. Dafür eignet sich die hosts-Datei (/etc/hosts auf Unix-Systemen, %systemroot%\system32\drivers\etc auf Windows). In der Praxis hilft das aber nicht, wenn man eine moderne Webseite ansteuern will. Viele davon sind nur noch verschlüsselt zu erreichen und dabei kommen TLS-Zertifikate zum Einsatz, die an den Domainnamen gebunden sind. Kann der nicht aufgelöst werden, scheitert der Aufbau der TLS-Verbindung. Man kann dann zwar zum Beispiel eine IP-Adresse in den Browser eingeben, aber der kommt dann oft nur bis zu einem Redirector, der seinerseits auf eine TLS-verschlüsselte Domain verweist. Das ist etwa bei heise.de der Fall.
    Viele Telefonanschlüsse gründen mittlerweile auf der VoIP-Technik. Ein VoIP-Telefon oder Client stützt sich für die Registrierung bei seinem SIP-Server ebenfalls auf den DNS-Dienst. Sollte das scheitern, funktioniert die Telefonie von diesem Client aus nicht. Ersatzweise kann man dann auf Mobilfunkgeräte ausweichen.
    Falls es auf Smartphones ebenfalls knirscht und keine Telefonate zustande kommen: Möglicherweise versucht das Smartphone VoLTE für den Telefoniedienst zu nutzen. Auch dieser hängt am DNS. Dann sollte es helfen, LTE abzuschalten, um die Telefonie auf UMTS oder GSM zurückzuzwingen.

    Schnelle Analyse, schnelle Abhilfe
    Was kann man tun, wenn man einen PC, Tablet oder Smartphone nutzt, und der darin konfigurierte Resolver schlapp macht, sodass "das Internet nicht geht"? Zunächst: Analysieren Sie das Problem genau, bevor Sie irgendetwas umkonfigurieren. Und: Denken Sie vor jeglichen Umstellungen daran, diese nach der Reparatur des betreffenden Resolvers wieder zurückzustellen auf den Ausgangszustand.
    Nicht jeder Internet-Störung liegt ein DNS-Problem zu Grunde. Wie findet man heraus, dass DNS nicht funktioniert?
    [*] Auf einem PC kann man für schnelle Analysen das Kommandozeilen-Tool ping verwenden. Testen Sie mit ping, ob eine bekannte und zuverlässige Domain erreichbar ist.
    [*] Auf einem mobilen Gerät kann man Monitor-Apps wie Fing verwenden. Fing gibt es sowohl für iOS als auch für Android.
    ping 193.99.144.80
    ping ct.de
    Wenn die erste Antwort Echo-Pakete liefert, die zweite aber nicht, dann antwortet der auf dem prüfenden Gerät konfigurierte DNS-Resolver nicht. Möglicherweise liegt es dann tatsächlich am fehlenden neuen Vertrauensanker. Wenn schon der erste Befehl keine Echo-Pakete liefert, funktioniert der Internet-Zugang nicht und die Ursache liegt ganz woanders.

    Ausweich-Resolver im Router
    Für DSL-, Glasfaser- und Kabelanschlüsse liegen die Lösungen auf der Hand: Wenn der aktuelle Resolver nicht funktioniert, dann trägt man einen anderen ein. Wenn etwa der Resolver des Providers stumm bleibt, stellt man vorübergehend einen offenen Resolver von Anbietern wie Google (z. B. 8.8.8.8) oder Cloudflare (z. B. 1.1.1.1) im Router ein – und umgekehrt.

    Die Änderung im Router gilt dann für alle Geräte im LAN, die ihre DNS-Einstellungen per DHCP vom Router beziehen. Starten Sie die Geräte neu oder trennen Sie sie kurz vom LAN, damit die Änderungen wirksam werden.
    Wenn Sie Geräte mit manueller Netzwerkkonfiguration betreiben, müssen Sie einen Ausweich-Resolver in diesen per Hand ändern. Fangen Sie das aber sicherheitshalber erst dann an, wenn die Änderung im Router tatsächlich Früchte trägt. Offene Resolver sollte man möglichst nur vorübergehend verwenden, denn man liefert so den DNS-Serverbetreibern genaue Informationen darüber, welche Ziele man im Internet ansteuert. Der eigene Provider gilt in Deutschland als vertrauenswürdig.
    Wer Googles DNS-Resolver nutzt (zum Beispiel 8.8.8.8) und nach dem Schlüsselwechsel keine DNS-Antworten erhält, sollte auf den DNS-Resolver seines Providers zurückstellen. Google verwaltet den Vertrauensanker nämlich manuell und möglicherweise ist beim Wechsel etwas schief gegangen. Allein in Deutschland hängen knapp 34 Prozent der Anwender von Googles DNS-Diensten ab.

    Ausweich-Resolver für unterwegs
    Wer mit einem Laptop unterwegs auf einen stummen Resolver in einem WLAN-Hotspot trifft, kann den zugehörigen Eintrag leicht in den Netzwerk-Einstellungen ändern. Das gilt auch für Android und für iOS. Falls das nicht hilft, kann es daran liegen, dass der Hotspot-Betreiber den üblichen unverschlüsselten DNS-Verkehr zu externen Resolvern unterbindet. Dann kann das Protokoll DNScrypt helfen.
    DNSCrypt spezifiziert eine verschlüssselte Kommunikation mit speziellen Resolvern. Diesen DNS-Verkehr kann ein Hotspot-Betreiber nicht als solchen identifizieren. Einzelheiten zu DNScrypt finden Sie hier. Clients für DNScrypt gibt es für iOS, Android, Linux, Windows und macOS. Hier sind einige Beispiele:
    [*] DNSCloak (iOS)
    [*] Simple DNSCrypt (Windows)
    [*] dnscrypt-proxy (Kommandozeile, Linux, macOS, Windows)
    [*] dnscrypt-proxy auf Android nutzen
    [*]
    Alternativ kann man ein VPN in Kombination mit einem funktionierenden Resolver nutzen. Der VPN-Client muss den Server anhand seiner IP-Adresse ansprechen können; DynDNS-Namen funktionieren nicht, solange der konfigurierte Resolver DNS-Anfragen nicht auflöst. Für diesen Ansatz kommen also praktisch nur VPN-Server in Frage, die eine feste öffentliche IP-Adresse haben. Und VPN-Server und Client müssen so eingestellt sein, dass sämtlicher Client-Verkehr über den Server ins Internet geht. Im Client kann man dann einen beliebigen DNS-Resolver eintragen, der gerade funktioniert (zum Beispiel 1.1.1.1 von Cloudflare oder 8.8.8.8 von Google). Nachteilig daran ist, dass die Latenz zunimmt, weil die Pakete zunächst zum VPN-Server gehen, bevor dieser sie zum Ziel gibt. Deshalb dauert es länger, bis zum Beispiel Webseiten aufgebaut sind. DNScrypt dürfte daher die bessere Wahl sein.
    Wenn Sie noch weitere Fragen und konkrete Resolver-Probleme haben, können Sie diese im Forum zu dieser Meldung stellen. Der
    DNS-Experte Carsten Strotmann wird am Donnerstag ab 18 Uhr vier Stunden lang Ihre Fragen beantworten – und auch am Vormittag des Freitags noch einmal vier Stunden bereitstehen.

    Quelle: DNS-Schuesselwechsel-Wie-man-DNS-Ausfaelle-erkennt-was-dagegen-hilft-4187064.html

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von mad.de () aus folgendem Grund: Formatierung