Die stille DNS-Schwachstelle, die gefälschte Websites ermöglichte
Wenn Sie eine Website besuchen, verbindet sich Ihr Computer nicht mit einem Namen wie "example.com". Stattdessen benötigt er eine IP address. Ihr Computer sendet eine Anfrage an einen resolver, normalerweise Ihren Router oder ISP, der dann verschiedene DNS-Server konsultiert, um die korrekte IP address zu finden.
Frühe DNS-Antworten waren anfällig, da sie sich auf eine einfache 16-Bit-Transaktions-ID verließen, um Antworten mit Anfragen abzugleichen. Obwohl diese ID half, Abfragen zu organisieren, bot sie keinen kryptografischen Nachweis der Identität des Absenders. Angreifer konnten einen resolver mit gefälschten Antworten überfluten, indem sie eine der 65.536 möglichen IDs erraten haben. Wenn eine gefälschte Antwort vor der legitimen eintraf, akzeptierte der resolver diese und speicherte die bösartigen Daten im Cache.
Dieser grundlegende Fehler wurde 2008 durch die Entdeckung des Kaminsky attack eklatant deutlich. Dan Kaminsky demonstrierte, wie man diese Schwachstelle ausnutzt, indem man beliebige, nicht existierende Subdomains ins Visier nimmt, was es Angreifern ermöglichte, den autoritativen Nameserver-Eintrag einer Domain schnell zu vergiften. Dies legte das weit verbreitete Risiko von DNS cache poisoning offen und unterstrich die dringende Notwendigkeit einer sichereren DNS-Architektur.
Die langfristige Lösung, DNSSEC, war bereits 2005 formuliert worden. Sie führte eine kryptografische Authentifizierung ein, die sicherstellt, dass jeder Schritt in der DNS-Abfragekette – von den Root-Servern bis zu den einzelnen Domain-Servern – die Authentizität des nächsten überprüfen kann. Dieses System etablierte eine Vertrauenskette, die verhindert, dass Angreifer betrügerische Informationen einschleusen und Benutzer auf bösartige Websites umleiten.
Die Vertrauenskette endet bei einem Root-Schlüssel
DNSSEC, die langfristige Lösung für DNS-Schwachstellen, verwendet Public-Key-Kryptografie, um Abfragen abzusichern. Jeder Signierer verfügt über einen private key, um digitale Signaturen für DNS-Daten zu generieren, und einen entsprechenden public key zur Verifizierung. Resolver verwenden diese public keys, um zu bestätigen, dass DNS-Daten während der Übertragung nicht verändert wurden, was ihre Authentizität sicherstellt.
Eine Vertrauenskette erstreckt sich von der DNS-Root bis zu einzelnen Domains. Wenn ein resolver example.com abfragt, fragt er zuerst die Root-Server ab, die für die .com Top-Level-Domain (TLD) Server bürgen. Die .com-Server bürgen dann für den eigenen DNS-Server von example.com. Jede übergeordnete Zone signiert kryptografisch die public keys ihrer untergeordneten Zonen und schafft so einen lückenlosen Validierungspfad.
Der Root Zone Key Signing Key (KSK) ist einzigartig; es gibt keine höhere DNS-Instanz, die ihn authentifizieren könnte. Daher muss sein public key als trust anchor in allen DNSSEC-validierenden resolvern vorkonfiguriert sein. Wer auch immer den privaten Teil des KSK kontrolliert, könnte gefälschte Root-Daten signieren und damit die gesamte DNS-Vertrauenskette untergraben. Dieser kritische private key wird in einem hochsicheren, air-gapped Hardware Security Module aufbewahrt und nur während streng kontrollierter Key Ceremonies mit mehreren Beteiligten aufgerufen.
Einblicke in die Zeremonie, die einen Schlüssel geheim halten soll
Die Wahrung der Geheimhaltung des Root-Schlüssels erfordert ein ausgeklügeltes, mehrschichtiges Sicherheitsprotokoll, das in einer sicheren Einrichtung in Culpeper, Virginia, durchgeführt wird. Dieser Standort, der von ICANN und Public Technical Identifiers (PTI) betrieben wird, schützt die Hardware Security Modules (HSMs), die den private key generieren und speichern. Der Zugang zum Zeremonienraum umfasst mehrere Sicherheitskontrollen, gefolgt von einem verschlossenen Käfig und schließlich Tresoren, die die HSMs selbst enthalten.
Der Signaturprozess ist eine Sicherheitsmaßnahme mit mehreren Personen. Sieben ernannte Crypto Officers, die aus der globalen Internet-Community stammen und unabhängig von ICANN sind, halten jeweils einen Sicherheitsschlüssel für ihr individuelles Schließfach. Um das HSM zu aktivieren und einen geschützten Vorgang durchzuführen, müssen mindestens drei Crypto Officers physisch anwesend sein und ihre einzigartigen Sicherheitsschlüssel einfügen.
Zeremonien sind öffentlich beobachtbar und dokumentiert, was Transparenz gewährleistet. Die Teilnehmer starten einen Laptop von einem vertrauenswürdigen, schreibgeschützten Betriebssystem und verifizieren dessen kryptografischen Fingerabdruck laut. Sobald die drei Sicherheitsschlüssel eingefügt sind, leitet ein einzelner Befehl den Schlüsselerzeugungsprozess innerhalb des air-gapped HSM ein. Der private Schlüssel verlässt diese sichere Umgebung niemals, außer als verschlüsseltes Backup. Die Kennung des neuen Schlüssels, wie 38696 für den Schlüssel von 2024, wird dann aufgezeichnet, und der Prozess endet damit, dass alle Teilnehmer ein Papierskript unterschreiben. Weitere Details zu diesen Verfahren finden Sie in der Dokumentation zu den IANA Root KSK Ceremonies.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Was ändert sich bei einem Root-Key-Rollover?
Key-Rollovers führen einen neuen Key Signing Key (KSK) ein, der den alten als aktiven Signaturschlüssel für den DNSKEY-Datensatz der Root-Zone ersetzt. Während der neue Schlüssel Monate im Voraus generiert und zertifiziert wird, findet der eigentliche "Rollover" statt, wenn er zum primären Signaturschlüssel wird und seine öffentliche Komponente für alle DNSSEC-validierenden Resolver als Trust Anchor verfügbar sein muss.
Das Versäumnis, diesen Trust Anchor zu aktualisieren, kann zu erheblichen Ausfällen führen. Ein Resolver mit einem veralteten öffentlichen Schlüssel kann Signaturen, die vom neuen KSK generiert wurden, nicht validieren und weist alle DNS-Antworten für signierte Domains zurück. Dies führt dazu, dass Benutzer SERVFAIL-Fehler sehen, wodurch Websites unerreichbar erscheinen, selbst wenn ihre Server voll funktionsfähig sind.
Moderne DNSSEC-validierende Resolver, wie die von ISPs oder öffentlichen Diensten wie Cloudflare 1.1.1.1 und Google 8.8.8.8, nutzen in der Regel automatisierte Trust-Anchor-Updates, was die meisten Risiken mindert. Ältere Router-Firmware oder manuell konfigurierte Systeme können jedoch hinterherhinken und erfordern explizite Updates. Wenn Sie DNS-Fehler feststellen, die mit einem Rollover zusammenfallen, ist die Aktualisierung Ihrer Router-Firmware oder Resolver-Software ein guter erster Schritt. Denken Sie daran, dass der DNSSEC-Schutz sowohl von signierten Domains als auch von validierenden Resolvern abhängt.
Häufig gestellte Fragen
Was ist der DNSSEC-Master-Key des Internets?
Es ist der private Teil des Key Signing Key (KSK) der Root-Zone, der zum Signieren der DNSSEC-Schlüssel der Root-Zone verwendet wird. Sein öffentliches Gegenstück ist ein Trust Anchor für validierende Resolver.
Warum benötigt das DNS DNSSEC?
DNSSEC fügt kryptografische Signaturen hinzu, die es validierenden Resolvern ermöglichen zu prüfen, ob DNS-Daten authentisch und unverändert sind, was dazu beiträgt, die Annahme gefälschter Antworten zu verhindern.
Kann ein Root-Key-Rollover meine Internetverbindung unterbrechen?
Er kann das DNS für Benutzer hinter einem validierenden Resolver stören, der den neuen Trust Anchor nicht gelernt hat. Der Resolver kann Antworten zurückweisen und gibt dabei häufig SERVFAIL zurück.
Wie wird der Root-Key geschützt?
Der private Schlüssel wird in sicherer Hardware aufbewahrt, und Schlüsseloperationen erfordern mehrere autorisierte Teilnehmer. Zeremonien nutzen kontrollierte Einrichtungen, dokumentierte Verfahren und öffentliche Aufzeichnungen.