DNSFS: Der gruseligste Cloud-Speicher-Hack, den du je sehen wirst

Fangen wir mit einem Gedankenexperiment an. Stell dir vor, du speicherst deine Dateien nicht auf AWS S3, nicht auf einer fancy verteilten Datenbank, sondern in den DNS-Caches von Millionen Servern weltweit. Deine Daten wären wortwörtlich rund um den Globus unterwegs – fragmentiert auf Geräten, die dir nicht gehören, in Resolvern, von deren Existenz du wahrscheinlich nicht mal wusstest.

Klingt nach Science-Fiction, oder? Nun, jemand hat es tatsächlich gebaut.

Die DNS-Cache-Entdeckung, die alles ins Rollen brachte

Bevor es ans Eingemachte geht, reden wir über etwas, das die meisten Entwickler als selbstverständlich hinnehmen: DNS TTLs. Wenn du einen Domainnamen abfragst, speichert der Resolver das Ergebnis für eine bestimmte Zeit zwischen, bevor er wieder nachschaut. Die meisten von uns denken, das sind ein paar Minuten oder maximal Stunden.

Aber hier kommt der Clou: Manche Resolver speichern Einträge fröhlich eine ganze Woche lang, wenn man sie nett darum bittet.

Diese Entdeckung führte zu einer faszinierenden Frage: Wenn DNS-Caches Daten so lange halten können, könnten wir dann gezielt Dateien darin speichern? Nicht nur Domain-Abfragen, sondern echte Daten?

Die Antwort: Überraschenderweise ja.

DNSFS: Dateispeicher direkt vor aller Augen versteckt

DNSFS lässt sich von einem früheren Hack namens PingFS inspirieren, der Daten in den Nutzdaten von ICMP-Ping-Paketen versteckte. Das Problem an PingFS? Du musstest ständig Pakete hin- und herschicken, um die Daten am Leben zu halten. Hörtest du auf zu senden, waren deine Daten weg.

DNSFS verbessert dieses Konzept enorm. Weil DNS-Resolver Antworten zwischenspeichern, bleibt ein Datenstück in ihrem Cache erhalten, sobald du es dort abgelegt hast – ohne dass du es immer wieder anfragen musst. Der Resolver erledigt die Arbeit für dich.

Denk einen Moment darüber nach. Du nutzt im Grunde die Infrastruktur anderer Leute – ohne deren Wissen – als verteiltes, redundantes Dateispeichersystem.

So funktioniert das Ganze

Die technische Umsetzung ist ebenso clever wie bedenklich.

Damit das funktioniert, brauchst du offene DNS-Resolver – Server, die Anfragen für beliebige Domains beantworten, nicht nur für die, für die sie authoritativ sind. Technisch gesehen sollten diese vom öffentlichen Internet abgeschirmt sein, weil sie ein DDoS-Reflektionsrisiko darstellen. Aber die Realität sieht anders aus: Millionen von Geräten werden mit falsch konfigurierten DNS-Diensten ausgeliefert, die von überall erreichbar sind.

Das System funktioniert, indem es Dateien in winzige Stücke zerlegt, diese als DNS-Abfragen kodiert und quer durchs Internet verteilt. Jeder Resolver, der eine solche Abfrage empfängt und zwischenspeichert, hält nun ein Stück deiner Datei. Um die Daten wiederherzustellen, fragst du einfach dieselben Resolver an und setzt die Stücke zusammen.

Das Schöne (und Erschreckende) daran: Die Daten bleiben im Cache, bis die TTL abläuft – keine dauerhafte Verbindung nötig.

Das Internet nach offenen Resolvern abscannen

Hier wird es beeindruckend und gleichzeitig leicht unheimlich.

DNSFS aufzubauen bedeutet, offene Resolver im gesamten Internet zu finden. Das erfordert das Scannen von Milliarden IP-Adressen, um herauszufinden, welche davon DNS-Abfragen für beliebige Domains beantworten.

Ein Entwickler nutzte masscan in Kombination mit cleveren BPF-Filtern (Berkeley Packet Filter), um effizient nur die nützlichen Resolver zu identifizieren – und autoritative-only-Server sowie anderen Datenmüll herauszufiltern. Das Ergebnis: Fast 4 Millionen offene DNS-Resolver weltweit.

Die geografische Verteilung ist aufschlussreich. China führt mit über 1,4 Millionen offenen Resolvern, gefolgt von den USA, Südkorea, Russland und Brasilien. Aber die wirklich interessante Metrik zeigt sich bei der Normalisierung nach Internetnutzern: Kleine Nationen wie St. Kitts und Nevis haben eine bemerkenswert hohe Resolver-Dichte – ungefähr ein Resolver pro 51 Einwohner.

Warum das wichtig ist (jenseits des Coolness-Faktors)

Klarstellung: DNSFS ist absolut keine Produktiv-Speicherlösung. Es ist langsam, unzuverlässig, völlig ungeprüft und arguably ein Sicherheits-Albtraum. Ein vollständiges Internet-Scan nach offenen Resolvern wirft auch ernsthafte ethische Fragen zu Einwilligung und Netzwerkgrenzen auf.

Aber darum geht es hier nicht.

DNSFS verkörpert genau das kreative, Grenzen-verschiebende Denken, das unser Verständnis vernetzter Systeme voranbringt. Es zeigt, wie viel falsch konfigurierte Infrastruktur im Internet existiert, und regt wichtige Diskussionen über Security-Hardening an. Es demonstriert die überraschende Persistenz von Cache-Daten in verteilten Systemen. Und es beweist, wie scheinbar starre Protokolle auf unerwartete Weise umfunktioniert werden können.

Es erinnert uns auch daran, dass das Internet viel chaotischer ist, als wir oft annehmen. Diese Millionen offener Resolver? Sie laufen auf Heimroutern, IoT-Geräten, Unternehmensausrüstung und allem dazwischen. Die meisten Administratoren haben keine Ahnung, dass ihre DNS-Dienste von außen erreichbar sind.

Die Lehren für Entwickler

DNSFS wird bald deine Anwendungsdaten speichern, aber es bietet wertvolle Lektionen:

Protokolle sind nur Ausgangspunkte. DNS wurde für die Namensauflösung entwickelt. Das bedeutet nicht, dass es darauf beschränkt ist.

Sicherheitsannahmen sind entscheidend. Offene Resolver existieren, weil jemand etwas falsch konfiguriert hat. Überprüfe immer die Exposition deiner Infrastruktur.

Kreative Einschränkungen bringen Innovation hervor. Die besten Hacks entstehen oft aus der Arbeit mit unerwarteten Limitierungen. DNSFS existiert, weil jemand fragte: „Was wäre, wenn wir den Cache nutzen?"

Das Internet ist seltsamer und formbarer, als die meisten von uns annehmen. Manchmal sind die interessantesten Systeme diejenigen, die eigentlich überhaupt nicht funktionieren sollten.

Kennst du ungewöhnliche Protocol-Exploits oder kreative Infrastruktur-Hacks? Das NameOcean-Team hört gerne von den einfallsreichen Wegen, auf denen Entwickler Technologie an ihre Grenzen treiben.