Der Abend des 5. Mai war für viele Administratoren, die Dienste und Webseiten mit .de-Domain betreuen, nicht vergnüglich: Kurz vor 22 Uhr schlugen Monitoringsysteme Alarm, Kunden und Mitarbeiter lösten Supportfälle aus und die Fehlersuche begann – Websites waren nicht erreichbar, Apps funktionierten nicht und VPN-Verbindungen scheiterten. Die Ursache lag aber nicht bei Betreibern von Diensten, sondern an zentraler Stelle: Im Domain Name System (DNS) der Zone .de, genauer in deren DNSSEC-Konfiguration.

Verantwortlich für die Konfiguration ist die DENIC eG, die bisher über den Vorfall nur knapp Auskunft gibt. Am Mittwoch hat sich der Staub zwar gelegt, die Störung ist beseitigt und manche Details zu den Ereignissen werden klarer. Der Blick in die DNS-Daten zeigt aber auch: Die genaue Ursache kann nur die DENIC erklären, eine Stellungnahme steht noch aus. Zur Rekonstruktion der Ereignisse haben wir die historischen DNS-Einträge untersucht, die der Dienst dnsviz.net aufzeichnet.

Was ist passiert

DNSSEC hat die Aufgabe, DNS-Antworten mit digitalen Signaturen gegen Manipulationen zu schützen. Ohne DNSSEC könnten Angreifer Antworten fälschen, wenn sie den Verkehr zwischen Client und Resolver abfangen und verändern. DNSSEC arbeitet mit asymmetrischer Kryptografie, also mit Schlüsselpaaren aus öffentlichem und privatem Schlüssel. Die öffentlichen Schlüssel werden in einem Eintrag vom Typ DNSKEY im DNS hinterlegt. Zum Signieren von Antworten gibt es längere Zone-Signing-Keys (ZSK), die wiederum mit einem kürzeren Key-Signing-Key (KSK) signiert werden.

Geprüft wird die Integrität einer DNS-Antwort schrittweise und zwar von hinten, ausgehend von der Root-Zone, deren Schlüsseln der Anfragende vertrauen muss. Die Root-Zone verweist, digital signiert, auf die zuständigen Nameserver der Toplevel-Domain – konkreten Fall .de. Liefern die einen gültigen signierten Verweis auf den Nameserver, der für diese Domain zuständig ist, wird dieser befragt. Wenn eine Signatur auf dem Weg fehlerhaft ist, wird die ganze Kette als fehlerhaft betrachtet und die Namensauflösung scheitert. Das ist das gewünschte Verhalten, das vor Manipulationen schützt.

In regelmäßigen Abständen werden die Zone-Signing-Keys auf Ebene der Toplevel-Domains getauscht. Weil das ein zentraler Schritt mit weitreichenden Folgen ist, passiert das in mehreren Schritten: Am 2. Mai hat die DENIC als Verantwortliche für die Zone .de einen neuen öffentlichen Schlüssel mit der ID 33834 bekanntgegeben. Das passierte so rechtzeitig, dass sich der neue Eintrag im DNS herumsprechen konnte. Signiert wurde mit dem neuen Schlüssel vorerst nicht, das übernahm der alte Schlüssel 32911. Erstmals als signierender Schlüssel in Erscheinung trat 33834 am 5. Mai um 21:43 (19:43 UTC) in einer Signatur (RRSIG) für den SOA-Eintrag der Zone .de. SOA steht für „Start of Authority“, der Eintrag enthält Informationen zur Zone selbst. Diese Signatur war aus noch ungeklärter Ursache ungültig. Die Daten von dnsziv zeigen: Alle 6 zuständigen Nameserver lieferten zu diesem Zeitpunkt diese defekte Signatur mit dem Schlüssel 33834 aus.

Gegen 21:59 waren die ersten Gegenmaßnahmen zu erkennen: Einer der Nameserver, n.de.net, lieferte ab da einen neuen RRSIG-Eintrag für den SOA-Eintrag mit einer gültigen Signatur, signiert mit dem neuen Schlüssel 33834. Die anderen fünf Server verbreiteten weiter die falsche Signatur.

Um 22:27 zeigte sich ein neues Bild: n.de.net lieferte wieder eine ungültige Signatur, jetzt hatten a.nic.de und z.nic.de gültige Einträge mit dem alten Schlüssel 33834 zu bieten – jedoch unterschiedliche per IPv4 und IPv6. z.nic.de zeigte parallel auch noch eine defekte Signatur. Um 22:31 dann der nächste Zustand, jetzt waren fünf Server in der Lage, richtig mit dem neuen Schlüssel 33834 zu signieren und nur n.de.net, der dieses Kunststück zuvor schon vollbracht hatte, lag mit seinem Eintrag daneben. Nur drei Minuten später lieferten zur Abwechslung alle falsche Antworten, in kurzen Abständen kamen immer andere Kombinationen von den Servern, die alle ungültig waren.

Um 22:50 hatten sich zwischendurch die meisten Server auf eine gemeinsame gültige Signatur mit dem alten geeinigt, nur n.de.net lag weiter daneben. Das änderte sich erstmals um 1:15 am 6. Mai (23:15 UTC), als wieder alle Server korrekte Antworten parat hatten – wenn auch noch nicht perfekt: a.nic.de und z.nic.de lieferten parallel zwei Signaturen, immerhin waren beide gültig. Um 1:17 dann endlich der erwünschte Zustand: Sechs Nameserver konnten eine gültige Signatur erzeugen. Weil es nicht gelungen war, alle sechs Nameserver zu überzeugen, gleichzeitig mit 33834 zu signieren, waren zu diesem Zeitpunkt alle auf den Schlüssel 32911 ausgewichen, der Schlüsseltausch wurde also rückabgewickelt. Daran hat sich bis zum Nachmittag des 6. Mai nichts geändert, bisher gab es keinen erneuten Versuch, den Schlüssel 33834 wieder einzusetzen.

Was folgt daraus

Der Blick in die historischen DNS-Daten zeigt: Mit dem Schlüssel 33834 war etwas faul, zumindest im Zusammenspiel mit SOA-Einträgen. Andere DNS-Einträge konnten zu jeder Zeit erfolgreich signiert werden. 15 Minuten nach der ersten ungültigen Signatur begannen deren Gegenmaßnahmen. Trotz einigen Wirrungen gelang es aber nicht, den Schlüssel auf allen sechs Servern für SOA-Signaturen zu nutzen. Um den Ausfall in den Griff zu bekommen, entschied man sich dann, diese wieder mit dem Schlüssel 32911 zu signieren.

Für .de-Domains ist ein solcher Ausfall wegen eines DNSSEC-Fehlers bisher einmalig. Im Jahr 2022 gab es in Schweden mit der Domain .se Probleme, die auf DNSSEC zurückzuführen waren. Russland hatte 2024 mit .ru-Domains ein DNSSEC-Problem. Ursächlich damals war eine doppelt vergebene Keytag-ID.

DENIC ist jetzt in der Verantwortung, die Ursache des Problems zu benennen und zu erklären, welche Gegenmaßnahmen ergriffen wurden. Unbeantwortet ist auch die Frage, warum die Signaturprobleme nicht bereits in einer Testumgebung aufgefallen sind.

(jam)

Wer auf dem Wasser unterwegs ist, weiß: Wenn sich etwas in der Schraube verheddert, endet die Bootsfahrt abrupt. Warum sollte sich das, was auf dem Wasser wirkt, nicht auch in der Luftfahrt nutzen lassen? Forscher vom Karlsruher Institut für Technologie (KIT) wollen Drohnen unschädlich machen, indem sie ihre Rotoren blockieren.

Das Konzept ist relativ einfach: Eine Abschusseinrichtung schleudert dünne Ketten in Richtung der Drohne. „Die Ketten umschlingen beim Kontakt den Drohnenkörper und die Rotoren. Dadurch verlieren die Rotoren ihre Beweglichkeit und die Drohne stürzt ab“, beschreibt Claus Mattheck, der das Verfahren gemeinsam mit externen Partnern entwickelt hat.

Ein Ingenieurbüro untersuchte das Verhalten von Ketten mit Durchmessern von drei bis vier Millimetern beim Aufprall auf Drohnen. Bei den Simulationen wurden laut Mattheck unter anderem Reibung, Geometrie und Bewegungsabläufe einbezogen.

Simulationen und Feldtests

In den Simulationen habe das Team „die grundsätzliche Tauglichkeit der Methode“ gezeigt, sagt Mattheck. „Weitere Verifikationen erfolgten experimentell durch Schussversuche im Ballistikzentrum Sternenfels.“ Die Ergebnisse der Simulationen und der Feldtests beschreibt das Team in den Fachzeitschriften Aerospace & Defence und Konstruktionspraxis.

Das Team suchte einen „möglichst einfachen, robusten und kurzfristig einsetzbaren Ansatz zur Drohnenabwehr“. Vorbild waren die Bolas, die Südamerika eingesetzten Wurfwaffen. Diese bestehen aus mehreren Schnüren mit Gewichten am Ende. Sie werden zum Fangen von Tieren eingesetzt, deren Beine durch Bolas umschlungen werden. „Statt Kugeln an Seilen verwenden wir dünne Ketten, die sich in Simulationsrechnungen als überlegen erwiesen haben“, sagt Mattheck.

Unerwünschte Drohnen

Immer häufiger werden unerwünschte Drohnen in der Nähe von Flughäfen, militärischen Einrichtungen oder kritischen Infrastrukturen gesichtet. Experten suchen nach Möglichkeiten, die unbemannten Luftfahrzeuge unschädlich zu machen, etwa mit Laser oder Mikrowellen.

Das DLR will Drohnen mit Netzen fangen oder von Abfangdrohnen rammen lassen. Schließlich gibt es noch die handfeste Möglichkeit, eine Drohne einfach abzuschießen – was aber nicht ohne Risiko für Umstehende ist: „Ein besonderer Vorteil der Ketten als Geschoss ist, dass sie herabfallend weniger Potenzial für Kollateralschäden haben als ein kompaktes Geschoss gleicher Masse“, sagt Mattheck.

(wpl)

Die Standard Performance Evaluation Corporation (SPEC) aktualisiert nach neun Jahren ihren wichtigsten Benchmark: Auf SPEC CPU 2017 folgt SPEC CPU 2026 mit einem runderneuerten Unterbau. Der zugrundeliegende Test wächst von 43 auf 52 Teil-Benchmarks.

Anders als andere Benchmarks wie Cinebench oder Geekbench enthalten alle SPEC-CPU-Versionen keine fertige Installationsdatei. Das verantwortliche Konsortium stellt den Quellcode bereit, den Tester selbst kompilieren müssen. Die Idee dahinter: So läuft der Test auf allerlei Hardware und Nutzer können den Benchmark beliebig optimieren, etwa auch um neue CPU-Funktionen auszunutzen.

Hinter SPEC stecken die wichtigsten CPU-Designer, Serverhersteller, Hyperscaler und Forscher. Mit dabei sind etwa AMD, Intel, Nvidia, ARM, Ampere, IBM, Microsoft, Oracle, Supermicro, HPE, Dell, Cisco, Lenovo und SiFive.

SPEC CPU ist in der Industrie weitverbreitet, auch als Standard-Benchmark bei AMD und Intel. Unter Privatanwendern fristet die Suite ein Nischendasein, weil zusätzlich zum jeweiligen Kompilieren die Bedienung per Kommandozeile hinzukommt.

Neue Test-Suite

Wie schon seine Vorgänger stammen alle Teil-Benchmarks von SPEC CPU 2026 „aus der echten Welt“. Das Konsortium sucht dazu Anwendungen aus, die es in seine Suite aufnimmt. Überraschung: Der Render-Teil mit Blender fällt ersatzlos raus, ebenso der x264-Encoder für das Videoformat H.264. Neu dabei sind etwa CPython, ein FLAC-Audio-Encoder und die Datenbank-Engine SQLite.

Bild 1 von 3

Der Basisdurchgang (Base) limitiert alle 52 Teil-Benchmarks auf einen einzigen Compiler mit denselben Flags. „Peak“ erlaubt Compiler-Optimierungen pro Teil-Benchmark, um die Leistung jeweils zu maximieren. Nutzer müssen in C, C++ und Fortran optimieren.

SPEC CPU 2026 kann auch moderne Serverprozessoren mit 128 CPU-Kernen und mehr auslasten. Einige der Integer-Tests sollen mit vielen Instruktionen explizit das Prozessor-Front-End überlasten, das die Befehle übersetzt und dann an die Rechenwerke verteilt.

Die Test-Suite inkludiert jetzt aber auch explizit Einplatinencomputer wie Raspberry Pis und RISC-V-Prozessoren. Die offizielle Datenbank führt etwa Ergebnisse mit dem Raspi 5 16 GByte auf (mit offensichtlich wenigen Punkten).

Viele Threads brauchen viel RAM

Jede laufende Instanz benötigt 2 GByte RAM. Wer einen modernen Desktop-Prozessor wie AMDs Ryzen 9 9950X3D2 mit 32 Threads auslasten will, benötigt also 64 GByte Arbeitsspeicher. Ein 128-Kerner mit 256 Threads erfordert 512 GByte.

Eine Lizenz für SPEC CPU 2026 kostet standardmäßig 3000 US-Dollar. Upgrader von der 2017er-Version zahlen 2000 US-Dollar (befristet bis 3. November 2026). Gemeinnützige Organisationen zahlen 750 US-Dollar. Akkreditierte Universitäten und Hochschulen bekommen die Lizenz kostenlos.

(mma)