DNSSEC: Deinen Verkehr vor Fälschung schützen

Jeden Namen, den deine Maschine heute nachgeschlagen hat, hat sie geglaubt. Deine Bank, deine Updates, deinen Mailserver. Eine Antwort kam aus dem Netz zurück, und nirgendwo hat irgendetwas geprüft, ob sie von der Organisation stammt, der der Name gehört, oder von demjenigen, der als Erster ein Paket loswurde. Auf einer gewöhnlichen DNS-Antwort liegt keine Signatur, es gibt nichts zu verifizieren, und nichts würde bemerken, wenn etwas nicht stimmte. 1983 war das ein vernünftiger Entwurf, und seit Langem ist er keiner mehr.

DNSSEC behebt genau das, und es ist weder neu noch teuer. Der Besitzer der Zone signiert seine Einträge. Die Zone darüber veröffentlicht einen Hash seines Schlüssels und signiert den, und so weiter nach oben, bis die Kette einen einzigen Root-Schlüssel erreicht, den dein Resolver von Geburt an kennt. Alles, was die Kette prüft, kann eine echte Antwort von einer gefälschten unterscheiden. Es ist seit 2005 ein Standard, die Root ist seit Juli 2010 signiert, und die Registries veröffentlichen die Einträge umsonst.^{1 2}

Die Spitze des Baums ist fertig. Ich habe für diesen Beitrag die Live-Root-Zone gezählt, und 1.351 von 1.438 Top-Level-Domains sind signiert, alle 1.038 generischen darunter. Dann geht es über die Klippe. Von den 2.390 gov.uk-Domains, die noch auflösen, sind neununddreißig signiert, und neun davon sind Gemeinderäte. Der MI6 hat es hinbekommen. Das National Cyber Security Centre nicht.

Das hier ist, was eine gefälschte Antwort tatsächlich kostet und was Signieren dagegen tut, gezählt aus der Live-Root-Zone am 27. September 2026 und hinunter durch Behörden, Banken, die Distributionen, von denen du installierst, und die Zertifizierungsstellen. Ein Befehl pro Domain, niemandes Erlaubnis nötig, und jeder Name aufgelistet, damit du über meine Auswahl streiten kannst statt über meine Rechnung. Darunter liegt die Frage, die ich eigentlich beantwortet haben wollte. Zweiundvierzig Jahre nachdem Mockapetris DNS aufgeschrieben hat: Signiert fast niemand, weil fast niemand je verstanden hat, was DNS versprochen hat?

Was DNSSEC ist und wofür es da ist

In einem Satz: DNSSEC legt eine kryptografische Signatur auf DNS-Antworten, sodass ein Resolver beweisen kann, dass eine Antwort vom Besitzer der Zone kam und nicht von demjenigen, der es geschafft hat, als Erster zu antworten.

Es ist keine Verschlüsselung, keine Firewall und kein Filter. Es ist eine Signatur und eine Schlüsselkette, die zu einem einzigen Schlüssel zurückführt, dem dein Resolver ohnehin vertraut. Das ist die ganze Idee.

Jetzt der Angriff, denn das Protokoll ergibt erst Sinn, wenn du gesehen hast, wofür es da ist.

Ein Resolver, der nach einem Namen fragt, schickt eine Anfrage und wartet. Die Antwort wird über eine Handvoll Felder zugeordnet: den abgefragten Namen, den Typ, Quell- und Zieladresse samt Ports, und eine 16-Bit-Transaktions-ID. Wer ein Paket erzeugen kann, das zu diesen Feldern passt, bevor die echte Antwort eintrifft, gewinnt. Der Resolver cacht die Fälschung und reicht sie an jeden Client weiter, der fragt, so lange der Angreifer es gesagt hat.

Dan Kaminskys Arbeit von 2008 ist die, an die sich alle halb erinnern.³ Entscheidend ist nicht, dass Cache Poisoning existierte, denn das war schon Jahre vorher bekannt. Entscheidend ist, dass er einen Weg fand, den Rateversuch beliebig oft zu wiederholen. Frag nach einem Namen, den es nicht gibt, und jeder Fehlversuch kostet nichts und lässt dich sofort erneut probieren, sodass der Angreifer nicht mehr einmal gegen einen zwischengespeicherten Eintrag antritt, der einen Tag hält. Die Antwort der Branche war mehr Zufall: zufällige Quellports zusätzlich zur zufälligen Transaktions-ID, was das Raten von eins zu 65.536 auf etwa eins zu zwei Milliarden brachte.

Das ist eine größere Zahl. Es ist kein Beweis.

Und diese Abmilderung erodiert seitdem, denn jedes dieser Felder ist ein Rateversuch, den man erschwert hat, und keine Tatsache, die man prüfbar gemacht hat. Port-Zufall wird von einem NAT ausgehebelt, das Ports vorhersagbar umschreibt. Fragmentierungsangriffe umgehen die Zuordnung ganz. Off-Path-Angriffe kommen in immer neuen Formen wieder, und jeder bekommt seinen eigenen Patch.

Signieren beendet die Diskussion. Eine signierte Antwort verifiziert entweder gegen einen Schlüssel, den der Resolver bis zur Root verketten kann, oder eben nicht, und kein noch so ausdauerndes Raten verschafft einem Angreifer eine gültige Signatur.

Was ihnen der Sieg in diesem Rennen tatsächlich einbringt

Werd konkret, denn „Cache Poisoning“ klingt abstrakt und die Folgen sind es nicht.

Die dritte Zeile macht aus einem DNS-Problem ein Zertifikatsproblem. Domain-validierte Ausstellung funktioniert so, dass man dich bittet, einen Eintrag zu veröffentlichen, und ihn dann nachschlägt. Kann ein Angreifer die Antwort kontrollieren, die die Zertifizierungsstelle bei dieser Abfrage sieht, stellt sie ihm echtes Papier auf deinen Namen aus, und danach gehört das Schloss im Browser ihm. Alles, worauf Nutzer trainiert wurden zu achten, sagt, die Seite sei in Ordnung.

Die vierte Zeile ist die leise. Eine gefälschte Antwort muss niemanden irgendwohin schicken. Einen Update-Dienst in ein schwarzes Loch zu zeigen genügt, und nichts im Stack ist dafür gebaut, wegen Updates Alarm zu schlagen, die nie ankamen.

Was das Signieren dagegen tut

Der Mechanismus ist einfacher als sein Ruf.

Jede signierte Zone hält ein Schlüsselpaar. Der Zonenbesitzer signiert jeden Eintragssatz mit der privaten Hälfte und veröffentlicht daneben ein RRSIG. Die öffentliche Hälfte steht als DNSKEY in der Zone. Bis hierhin beweist das nichts, denn ein Angreifer, der einen A-Eintrag fälschen kann, kann auch ein passendes DNSKEY fälschen.

Was es schließt, ist der DS-Eintrag, und das DS liegt in der übergeordneten Zone, nicht in deiner. Es ist ein Hash deines Schlüssels, veröffentlicht und signiert von der Zone über dir. Also bürgt uk für deinen Schlüssel, die Root bürgt für uk, und dein Resolver kam mit genau einem Wissen zur Welt: dem Schlüssel der Root.²

Drei Eintragstypen erledigen die Arbeit, und du willst wissen, welcher welcher ist, denn nur einer davon ist die Aufgabe eines anderen:

Du kannst die ersten beiden einen ganzen Nachmittag lang allein veröffentlichen, und es ändert nichts. Bis der Elternteil ein DS veröffentlicht, bist du eine signierte Zone, die niemand verifizieren kann, was dasselbe ist wie eine unsignierte Zone mit zusätzlicher Arbeit darin.

$ dig +short @127.0.0.53 uk DS
43876 8 2 A107ED2AC1BD14D924173BC7E827A1...

$ dig +short @127.0.0.53 damiendye.uk DS
2371 13 2 A5B2825C57899A5A15EE9703832C8358E0D19EF29DC72DD83C691ED77C33BD7F

$ dig +short @127.0.0.53 bbc.co.uk DS
                                          (nothing)

Das in der Mitte ist die eigene Zone dieser Seite. uk bürgt für sie, Algorithmus 13 ist ECDSA P-256, und ein validierender Resolver kann darum jede Antwort über sie bis zur Root beweisen. bbc.co.uk liefert nichts zurück, also kann er es nicht.

Ein Befehl sagt dir, ob eine Zone in der Vertrauenskette hängt. Veröffentlicht der Elternteil kein DS für dich, bist du nicht signiert, was immer du sonst konfiguriert hast, und ein validierender Resolver behandelt jede Antwort über deine Domain als nicht verifizierbar.

Dieser eine Eintrag ist der ganze Test.

Was es nicht tut

Das gehört klar gesagt, denn das Überverkaufen ist die halbe Erklärung dafür, warum Leute misstrauisch sind.

Über die letzte Zeile stolpern Leute. DNSSEC beweist, dass die Antwort von dem kam, der die Zone kontrolliert. Es hat nicht die geringste Meinung dazu, ob derjenige anständig ist.

Es tut genau eine Sache. Es macht das Fälschen einer Antwort rechnerisch aussichtslos statt bloß unwahrscheinlich.

Wie du jede Zone prüfst, auch die von anderen

Das hier ist der Teil, der den Rest dieses Beitrags möglich macht, und er braucht einen Befehl.

Eine Zone hängt in der Vertrauenskette, wenn ihr Elternteil ein DS für sie veröffentlicht. Das ist der ganze Test, und du kannst ihn gegen jeden laufen lassen, ohne Erlaubnis, von jeder Maschine aus:

dig +short damiendye.uk DS

Kommt etwas zurück, ist sie signiert. Kommt nichts zurück, ist sie es nicht, was die Zone sonst auch konfiguriert hat.

Wenn du mehr willst als Ja oder Nein, lohnen sich drei weitere:

Zwei Fallen, bevor du deinen eigenen Ergebnissen traust, denn beide haben mich beim Messen für diesen Beitrag erwischt.

dig +short … DS gibt eine CNAME-Kette aus, wenn der Name ein Alias ist, und ein Hostname mit Ziffern darin sieht einem DS-Eintrag ähnlich genug, um ein naives Skript hereinzulegen. Ein echtes DS hat vier Felder: Key-Tag, Algorithmus, Digest-Typ, Hex-Digest. Prüf auf diese Form, sonst zählst du unsignierte Zonen als signiert.

Ein DS unter einem unsignierten Elternteil bedeutet nichts. Die Kette muss die Root erreichen. update.microsoft.com hat ein DS, microsoft.com nicht, also ist der Ast trotzdem nicht verifizierbar. Prüf immer den ganzen Pfad, nicht eine Ebene.

Alles, was im Rest dieses Beitrags gezählt ist, wurde so gemessen. Kein Scanner, kein fremdes Dashboard, keine Ranglisten eines Anbieters. Frag den Elternteil, ob er für das Kind bürgt, und bestehe darauf, dass die Antwort als DS parst.

Die Root-Zone ist fertig

Hier ist die überlieferte Weisheit schlicht veraltet. Leute reden über DNSSEC immer noch so, als wäre die Infrastruktur das Problem.

Ich habe am 27. September 2026 die Live-Root-Zone geholt, Seriennummer 2026092701, und die Delegierungen gegen die DS-Einträge gezählt.⁴

Jede einzelne generische Top-Level-Domain ist signiert. Alle 1.038, ohne Ausnahme, weil ICANNs Registry Agreement es für alles verlangt, was unter dem neuen gTLD-Programm delegiert wurde. Die 87 unsignierten sind fast ausschließlich Ländercodes, und die Liste besteht überwiegend aus kleinen Territorien und einer Handvoll Staaten:

ae ao aq ba bb bo bs cd cf cg ck cu cv cw do eg fk gb gf gh gm gp gq gt gu
hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz ne ni np nr om pa pf
pk pn ps qa sd sl sm so st sv sy sz td tg tj tk to va vg vi ye zw

gb steht da drin, was eher eine Kuriosität als ein Problem ist, denn niemand benutzt es für irgendwas. Ebenso der Vatikan, Nordkorea, Kuba und Syrien. Ebenso tk, das jahrelang die größte Quelle kostenloser Domains im Internet war und eine verlässliche Quelle für Missbrauch gleich dazu.

Die Spitze des Baums ist also erledigt. Die Registries haben den schweren Teil gemacht, den teuren Teil und den Teil, der internationale Abstimmung brauchte, und sie haben ihn zu Ende gebracht. Insofern kann nichts unterhalb dieses Punkts der Infrastruktur angelastet werden.

Und dann ist Schluss

Unterhalb der TLD dreht sich das Bild vollständig um.

Ich habe für jede Gruppe darunter gleich gemessen: den Elternteil nach einem DS fragen, und nur einen Eintrag akzeptieren, der tatsächlich als solcher parst. Alles hier wurde am 27. September 2026 gezählt.

Vierundneunzig Prozent an der Spitze. Anderthalb Prozent am Boden. Die Vertrauenskette ist eine Kette, deren eines Ende an der Wand verschraubt ist, während das andere auf dem Boden liegt.

Eine Anmerkung zur Methode, denn eine so schlechte Zahl verdient eine. Die gov.uk-Zeile ist eine Vollerhebung und keine Stichprobe: Sie umfasst jede Second-Level-Domain im amtlich veröffentlichten Register der Regierung, gefiltert auf die 2.390, die noch auflösen. Die anderen Zeilen sind kuratierte Listen der Organisationen, deren Fälschung tatsächlich wehtäte, und das ist eine Ermessensentscheidung, weshalb ich unten jeden Namen darin aufgeführt habe, damit du mit meiner Auswahl uneins sein kannst statt mit meiner Rechnung.

Die Vollerhebung beim Staat: 39 von 2.390

Die amtliche Liste der gov.uk-Domains, die die Regierung veröffentlicht, umfasst 3.004 Second-Level-Namen. Davon lösen 2.390 noch auf. Neununddreißig sind signiert.

Vor dem Detail noch etwas zu diesem Register. Die aktuellste Fassung, die gov.uk veröffentlicht, ist auf den 1. Oktober 2016 datiert.⁵ Ein Jahrzehnt alt, für die maßgebliche Liste der Domains, unter denen der britische Staat antwortet. Das ist ein eigener kleiner Befund, und ich lasse ihn so stehen.

Jetzt schau dir an, welche neununddreißig.

Lies die erste Spalte noch einmal. Der britische Auslandsgeheimdienst hat seine Zone signiert. Das National Cyber Security Centre nicht.

GCHQ auch nicht, und das ist die Mutterorganisation des NCSC. Das Programm Cyber Essentials auch nicht, das es gibt, um zu bescheinigen, dass die Sicherheit anderer Leute angemessen ist. Ich werde nicht so tun, als wäre das irgendetwas anderes als bemerkenswert.

Und neun der neununddreißig sind Gemeinde- und Stadträte. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Orte mit einem Schriftführer, einer nebenher gepflegten Website und einem Budget, das keinen Beratertag in Whitehall decken würde. Die haben es hinbekommen. HMRC, die die Steuerakte jedes Erwachsenen im Land hält, nicht.

Darf ich fragen, was im Prozess das zulässt. Nicht wer: was. Denn das NCSC veröffentlicht Leitlinien, die anderen Leuten sagen, sie sollen DNSSEC ausrollen, und die Abteilung, die die Leitlinien schreibt, hat nicht getan, was die Leitlinien sagen. Entweder ist es wichtig, dann hätte die Stelle, die das sagt, es vor Jahren tun müssen, oder es ist es nicht, dann sollten die Leitlinien genau das sagen.

Die angebotene Ausrede werden Größe und Altlasten sein. Sie überlebt die erste Spalte nicht. somerset.gov.uk ist eine Einheitsgemeinde für 580.000 Menschen und ist signiert. birmingham.gov.uk ist eine Einheitsgemeinde für 1,1 Millionen und ist es nicht. Gleiches Land, gleiche Registry, gleiche Registrare, gleiches Geld für die gleichen Dienstleister. Eine hat es getan.

Die Software, von der du Updates beziehst

Das ist der Teil, der dir mehr Sorgen machen sollte als die Banken, und es ist der Teil, den fast niemand misst.

Jede Maschine, die du betreibst, holt sich nach Plan Code von irgendwoher, und sie findet dieses Irgendwo, indem sie DNS fragt.

Neunundneunzig Distributionen und BSDs, sechsundneunzig davon lösen noch auf. Neunzehn sind signiert.

Neunzehn von sechsundneunzig. Und die Namen in der unsignierten Liste sind nicht obskur: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, jede Ubuntu-Variante, und sowohl kernel.org als auch gnu.org.

Bei den Sicherheits- und Privatsphäre-Distributionen hatte ich erwartet, dass sie anders sind, und meist sind sie es nicht. Tails und Whonix haben signiert, was passt. Kali, Parrot, Qubes, Trisquel und PureOS nicht, was nicht passt. OpenBSD hat sich fünfundzwanzig Jahre lang einen Ruf darauf aufgebaut, genau diese Klasse von Dingen richtig zu machen, und hat openbsd.org nicht signiert, während FreeBSD, NetBSD, HardenedBSD und MidnightBSD es alle getan haben.

Die Paket-Registries sind nahe an einem Durchmarsch in der falschen Spalte: npm, crates.io, RubyGems, Packagist, Docker Hub und Quay sind allesamt unsigniert. pypi.org ist die Ausnahme, und Ehre, wem Ehre gebührt, denn es gehört auch zu den meistangegriffenen.

Microsoft und der Update-Kanal

Vier von sechsundzwanzig Microsoft-Zonen sind signiert, und sie liegen alle in einer Ecke des Bestands:

Die Outlook- und Office-Namen sind signiert und sonst nichts, was nach der Entscheidung eines Teams aussieht und nicht nach der eines Konzerns. Achte darauf, was in der rechten Spalte neben dem Update-Dienst steht: github.com und npmjs.com, zwei der größten Code-Verteilpunkte im Internet, beide Microsoft, beide unsigniert.

$ dig +short @127.0.0.53 windowsupdate.com DS
                                          (nothing)
$ dig +short @127.0.0.53 microsoft.com DS
                                          (nothing)
$ dig +short @127.0.0.53 com DS
19718 13 2 8ACBB0CD28F41250A80A491389424...

com ist signiert, also steht technisch nichts im Weg. Microsoft könnte heute Nachmittag ein DS veröffentlichen.

Die Standardantwort darauf, warum das egal sei, lautet, DNS sei nur eine Schicht. Update-Pakete sind codesigniert, der Client prüft die Signatur, und der Verkehr läuft über TLS. Brich das DNS, und du bekommst trotzdem keinen Code zur Ausführung.

Diese Antwort hängt vollständig davon ab, dass das Signieren solide ist. Das war es nicht.

Sei bei der letzten Zeile genau, denn Leute übertreiben sie. Der gestohlene Schlüssel signierte Identitätstoken, keine Binaries. Sie gehört aus einem anderen Grund in die Tabelle: Die Verwahrung von Microsofts Signaturmaterial versagte, zwei Jahre lang unentdeckt, über einen Crash-Dump und ein kompromittiertes Entwicklerkonto.

Die Zeilen darüber sind die Versagen beim Codesignieren, und sie sind schlimmer. Zweimal in einem Jahr setzte Microsofts eigenes Hardware-Zertifizierungsprogramm eine Microsoft-Signatur auf ein funktionierendes Rootkit und lieferte es aus. Kein gefälschtes Zertifikat, kein gestohlener Schlüssel. Der legitime Prozess, der Schadsoftware signiert, genau wie entworfen.

Die Verteidigung, die es erlaubt, DNS als optional zu behandeln, wurde also über elf Jahre hinweg durch Fälschung, durch Prozessmissbrauch und durch Schlüsseldiebstahl unterlaufen. Ein Angreifer mit einer Signatur, die die Maschine akzeptiert, ist kein Gedankenexperiment. Für einen staatlich gestützten Akteur ist das ein Beschaffungsproblem und kein Forschungsproblem.

Gib diesem Angreifer eine gefälschte DNS-Antwort, und das Bild ist vollständig: signierter Code, den er kontrolliert, geliefert von einem Server, den die Maschine für Microsofts hält, über eine Verbindung, die nichts im Stack hinterfragt. Das ist Flame, mit besserem Schlüsselmaterial.

DNSSEC ist die einzige Schicht in dieser Kette, der es egal ist, wessen Signaturschlüssel der Angreifer hält. Es validiert nicht die Nutzlast, es validiert, wohin die Maschine geschickt wurde, und es versagt unabhängig von jedem Zertifikat und jeder Signatur im Spiel. Genau das willst du von einer zweiten Schicht, und genau deshalb sollte sie nicht die sein, die abgeschaltet ist.

Und es gibt einen billigeren Angriff, der gar keinen Schlüssel braucht. Fälsch die Antwort so, dass der Update-Dienst nirgendwohin Nützliches auflöst, und die Maschine patcht schlicht nie. Kein Fehler, auf den die Nutzerin reagieren würde, kein Alarm, nur eine Flotte, die still zurückfällt, während das Dashboard sagt, alles sei in Ordnung. Wollte ich einen Bestand, der in sechs Monaten ausbeutbar ist, würde ich ihm nichts ausspielen. Ich würde nur dafür sorgen, dass nichts ankommt.

Die Banken, vollständig

Diesmal keine Stichprobe. Achtundneunzig britische Banken und Bausparkassen, jede einzelne an dem Tag auflösend, von der Einkaufsstraße hinunter bis zu Kassen mit einer Filiale und einem viktorianischen Namen.

Dreizehn sind signiert.

Achtunddreißig Bausparkassen. Keine einzige signiert. Das sind die Institute, die die Hypothek auf sehr viele Häuser halten.

Zwei Muster in der signierten Spalte stechen heraus. Die Lloyds Banking Group hat drei ihrer Marken signiert, lloydsbank.com, halifax.co.uk und bankofscotland.co.uk, und die Co-operative Bank hat beide ihrer Marken signiert. Die Entscheidung fällt also einmal, auf Organisationsebene, und wird dann angewandt. Keine Hürde pro Domain darin.

Und Monzo hat signiert, während Starling es nicht hat. Zwei Challenger-Banken, im Abstand von einem Jahr gegründet, auf vergleichbar moderner Infrastruktur, mit derselben Aufsicht und denselben verfügbaren Registraren. Eine hat es getan.

Der eine Ort, an dem es alle tun

Schau dir die letzten beiden Namen in der signierten Spalte an: allica.bank und weatherbys.bank.

.bank ist eine beschränkte Top-Level-Domain, betrieben von fTLD Registry Services, und ihre Sicherheitsanforderungen machen DNSSEC verpflichtend, neben TLS und E-Mail-Authentifizierung, mit jährlicher Neuprüfung jedes Registranten.⁹

Zwei ist eine kleine Zahl, nimm es also als Demonstration und nicht als Statistik. Die Anforderung bleibt trotzdem das Einzige, was sich geändert hat.

Das ist die Antwort auf jede Ausrede weiter unten in diesem Beitrag, und sie kommt vor den Ausreden. Dieselben Banken, dieselben Dienstleister, dieselben Budgets und dieselben Fähigkeiten bringen 13 % Erfüllung, wenn es optional ist, und 100 %, wenn jemand jährlich nachsieht. Technisch hat sich nichts bewegt. Jemand hat einfach gefragt.

Niemand bewacht die Wächter

Eine Zertifizierungsstelle von neun.

Das sind die Organisationen, deren gesamtes Geschäft darin besteht, zu beweisen, dass etwas das ist, was es zu sein behauptet. Es sind auch die Organisationen, die die Kontrolle über eine Domain über DNS prüfen, indem sie dich bitten, einen Eintrag zu veröffentlichen, und ihn dann nachschlagen. Die Abfrage, die darüber entscheidet, ob du ein Zertifikat für eine Domain bekommst, ist bei acht dieser neun eine Abfrage, die niemand verifizieren kann.

Nichts Hypothetisches daran. Es ist die dokumentierte Form: Fälsch die Prüfabfrage, lass dir das Zertifikat ausstellen, und jetzt hältst du gültiges Papier für einen Namen, der dir nicht gehört. DNSSEC gehört zu den wenigen Dingen, die das spürbar schwerer machen, und die Leute, die es am meisten schützen würde, haben es nicht ausgerollt.

Eins sage ich dir gratis. Wenn dein Geschäftsmodell Identität ist und du deine eigene Zone nicht signiert hast, steht dir das Argument, es sei schwer, nicht zur Verfügung.

Und wer prüft eigentlich?

Signieren ist nur die halbe Sache. Eine signierte Zone schützt niemanden, solange nicht am anderen Ende etwas die Signatur verifiziert, und hier wird das Bild schlechter statt besser.

Es gibt zwei Orte, an denen Validierung stattfinden kann, und sie sind nicht gleichwertig:

Nahezu alle Validierung der Welt ist von der ersten Art. Google, Cloudflare und Quad9 validieren alle und decken zusammen eine enorme Zahl von Nutzern ab. Das zählt etwas. Aber es heißt, dass die Eigenschaft, die die meisten Leute haben, lautet: mein Resolver sagt, das war in Ordnung.

Was die einzelnen Betriebssysteme können

Zwei davon verdienen mehr als eine Zeile.

Apple hat die Arbeit still gemacht. iOS 16 und macOS Ventura haben clientseitige DNSSEC-Validierung ergänzt, in Apples eigenen Worten auf der WWDC 2022: „iOS 16 and macOS Ventura now support client side DNSSEC validation.“¹⁰ Sie ist opt-in statt automatisch, und sie ist opt-in in der richtigen Granularität, sodass eine Anwendung, der es wichtig ist, sie pro Sitzung oder pro Anfrage anfordern kann:

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true

Ein echter validierender Resolver auf einem Telefon, der Signaturen auf dem Gerät prüft, und fast niemand hat mitbekommen, dass er ausgeliefert wurde. Davor stellte mDNSResponder kDNSServiceFlagsValidate für jeden bereit, der bereit war, die C-API zu benutzen.

Android bietet es nicht an. Der DNS-Resolver ist seit Android 10 ein aktualisierbares Modul und bekam in Android 9 DNS over TLS, die Plattform hat bei DNS also nicht stillgestanden. Aber weder die AOSP-Resolver-Dokumentation noch die öffentliche DnsResolver-API dokumentiert DNSSEC-Validierung, und der Grund, warum es Bibliotheken wie MiniDNS gibt, die damit werben, „DNSSEC close to your application“ zu bringen, ist, dass die Plattform es nicht mitbringt. Ich habe keine Primärquelle gefunden, die rundheraus sagt, es sei unmöglich, also sage ich es nicht stärker als: nicht angeboten, und du würdest es selbst schreiben.

Und selbst dort, wo es funktioniert, wird es weggeworfen

Noch eine Sache von dieser Maschine, mit der ich nicht gerechnet hatte.

Der Upstream-Resolver hier validiert und sagt das auch. systemd-resolved wirft das mit DNSSEC=no weg, bevor irgendeine Anwendung es sieht:

# ---- before: stock Fedora, DNSSEC=no ----------------------------------
$ dig @192.0.2.53  damiendye.uk A | grep flags      # the upstream
;; flags: qr rd ra ad

$ dig @127.0.0.53  damiendye.uk A | grep flags      # the local stub
;; flags: qr rd ra

# ---- the fix: two lines in a drop-in ----------------------------------
$ sudo mkdir -p /etc/systemd/resolved.conf.d
$ printf '[Resolve]\nDNSSEC=allow-downgrade\n' \
    | sudo tee /etc/systemd/resolved.conf.d/10-dnssec.conf
$ sudo systemctl restart systemd-resolved

# ---- after: same query, same stub, nothing else changed ---------------
$ resolvectl status | grep -m1 DNSSEC=
                    DNSSEC=allow-downgrade/supported

$ dig @127.0.0.53  damiendye.uk A | grep flags
;; flags: qr rd ra ad

Gleicher Name, gleiche Antwort, gleiche Sekunde. Vor dem Drop-in hat der Upstream die Arbeit gemacht, das AD-Bit gesetzt, und der lokale Daemon hat es fallen lassen, die Voreinstellung ist also nicht schlicht wir validieren hier nicht, sie ist wir validieren hier nicht, und wir geben auch das Urteil von niemandem weiter, der es getan hat. Danach ist das Bit zurück, und diesmal ist es unseres statt der Behauptung eines anderen.

resolvectl formuliert das Urteil aus, und es trennt die beiden, auf die es ankommt:

$ resolvectl query damiendye.uk | tail -2
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no

$ resolvectl query ncsc.gov.uk | tail -2
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no

Achte darauf, was das zweite nicht ist. Es ist kein Fehler. Eine unsignierte Zone kommt unbeglaubigt zurück statt bogus, die Auflösung gelingt, und nirgendwo beschwert sich etwas. Das ist das ganze Problem mit 1,63 %, neu formuliert als Befehl: Validierung anzuschalten lässt unsignierte Zonen nicht scheitern, es macht sie sichtbar, und nur für den, der hinschaut.

Das größte Client-Betriebssystem scheitert an der einfachsten Prüfung

Jetzt das andere Ende der Skala, und es ist nicht knapp.

Der Windows-DNS-Client ist, in Microsofts eigener Beschreibung, „security-aware“, aber „non-validating“. Er führt keine DNSSEC-Validierung durch. Man kann ihn nicht dazu bringen. Was er stattdessen tut, ist, seinen konfigurierten DNS-Server um Validierung zu bitten und dann in der Antwort nach dem AD-Bit zu suchen.¹¹

Drei Dinge dazu, und keines davon ist klein:

• Er prüft nie eine Signatur. Die stärkste Garantie, die dem größten Client-Betriebssystem der Welt zur Verfügung steht, ist ein einzelnes Bit, gesetzt von der Maschine, die zufällig geantwortet hat.
• Nicht einmal das tut er standardmäßig. Der Client setzt das DO-Bit und verlangt AD nur für Namensräume, die in der Name Resolution Policy Table stehen, einem Gruppenrichtlinienobjekt, das jemand bewusst konfigurieren muss. Steht keine Regel darin, trägt die Abfrage überhaupt keine DNSSEC-Erwartung.
• Microsoft sagt, das Bit braucht IPsec, um etwas zu bedeuten. Ihre Dokumentation ist ausdrücklich, dass, weil der Client nicht validiert und sich auf den Server stützt, „IPsec is used to establish this trust relationship“. Ein AD-Bit, das über eine nicht authentifizierte Strecke eintrifft, ist eine Behauptung von dem, der zuerst da war, und genau dieser Angriff ist der, den diese ganze Technik verhindern soll.

Auf dem Desktop mit der größten installierten Basis also, ab Werk: keine Validierung, keine AD-Anforderung, und kein authentifizierter Kanal zum Resolver. Die einfachste Prüfung ist nicht bloß abgeschaltet. Sie wurde nie implementiert.

Und die übliche Verteidigung, Client-Betriebssysteme machten so etwas einfach nicht, starb 2022. Apple lieferte geräteseitige Validierung an jedes iPhone und jeden Mac, im selben Jahr, in dem Microsoft es nicht tat. Der Vergleich ist nicht mehr Desktop gegen Server oder mobil gegen fest. Es ist ein Hersteller, der es gebaut hat, gegen einen, der es nicht hat.

Das wiegt schwerer als dieselbe Lücke unter Linux, wegen der Betroffenen. Ein Linux-Server wird meist von jemandem betrieben, der die Validierung heute Nachmittag anschalten könnte und weiß, was ein DS-Eintrag ist. Die Maschinen, die überhaupt nicht validieren können, bei keiner Einstellung, sind die, die in den Organisationen auf den Schreibtischen stehen, deren Zonen in den Tabellen oben unsigniert sind. systemd-resolved liefert die Fähigkeit abgeschaltet aus, und das ist eine Entscheidung, die du in einer Zeile umkehren kannst.¹² Das Fisher-Price OS (Windows) bringt die Fähigkeit gar nicht erst mit.

Der Dienst, den DNS zusammenhält

Alles bisher waren Namen im öffentlichen Internet. Dasselbe Loch existiert im Gebäude, und drinnen ist es tragend.

Active Directory hat für nichts eine feste Adresse. Eine in die Domäne eingebundene Maschine weiß nicht, wo ihr Domänencontroller wohnt, also fragt sie DNS. Der Locator-Prozess fragt _ldap._tcp.dc._msdcs.<domain> nach den Controllern und _kerberos._tcp nach dem KDC ab, und was zurückkommt, ist das, wogegen sie sich authentifiziert.¹³

dig +short _ldap._tcp.dc._msdcs.corp.example SRV

Fälsch diese Antwort, und die Maschine trägt ihren Authentifizierungsverkehr zu einem Host, den du ausgesucht hast. Sei ehrlich, was das ist und was nicht: Kerberos gibt einem Hochstapler ohne die Schlüssel kein Ticket, das ist für sich genommen also keine Domänenübernahme. Es ist eine Position im Pfad, und daraus werden die interessanten Angriffe gebaut. Erzwing den Rückfall auf NTLM und leite ihn weiter. Setz dich mitten in Verkehr, der zu einem Controller gehen sollte. Oder zeig den ganzen Bestand ins Leere und sieh zu, wie die Anmeldungen aufhören.

Gruppenrichtlinien, Anmeldeskripte, verbundene Laufwerke und jede Vertrauensstellung unterhalb der Anmeldung werden alle genauso gefunden. Es ist der wertvollste Satz von Namen, den die meisten Organisationen besitzen, und er sitzt da unsigniert.

Microsoft hat die Server-Hälfte der Lösung gebaut, und gut gebaut. Eine AD-integrierte Zone kann signiert werden, Online-Signierung dynamischer Zonen kam mit Windows Server 2012, und weil die Zone im Verzeichnis liegt, replizieren die privaten Signaturschlüssel über die AD-Replikation selbst zu den anderen DNS-Servern.¹⁴ Der wirklich unangenehme Teil von DNSSEC, nämlich Schlüssel zu den Maschinen zu bringen, die sie brauchen, wurde hier vor vierzehn Jahren von genau dem gelöst, worüber die Zone ohnehin schon replizierte.

Dann hört es an denselben zwei Stellen auf wie alles andere:

Die interne Zone, die entscheidet, welche Maschine dein Domänencontroller sein darf, ist in den meisten Beständen also genauso unsigniert wie die öffentliche. Der Unterschied ist, dass kein Außenstehender sie zählen kann, weshalb es in diesem Beitrag keine Tabelle gibt, die jemanden bloßstellt. Geh und schau dir deine eigene an, bevor du etwas annimmst.

Das Betriebssystem sollte das tun, und es sollte an sein

Womit ich zu dem Teil komme, den ich argumentieren statt zählen will.

Eine DNS-Antwort zu validieren ist Betriebssystemarbeit. Sie gehört in dieselbe Klasse von Aufgaben wie die Uhr richtig zu halten, einen Speicher vertrauenswürdiger Zertifikate zu führen und einen TLS-Stack zu haben, und aus denselben Gründen: Jede Anwendung braucht es, fast keine sollte es selbst schreiben, und die Prüfung muss einmal passieren, an einer Stelle, wo sie ordentlich gemacht werden kann. Für Zertifikate haben wir diese Diskussion vor langer Zeit beigelegt. Niemand liefert ein Mailprogramm mit einer eigenen privaten Meinung über Root-CAs aus.

Drei der vier Plattformen oben können es bereits. Keine einzige tut es ab Werk:

$ grep DNSSEC= /usr/lib/systemd/resolved.conf   # Fedora 44, systemd 259.9
#DNSSEC=no

Das ist die einkompilierte Voreinstellung, auskommentiert hingeschrieben, damit eine Administratorin sieht, was sie ist. systemds eigenes Handbuch vertritt eine andere Ansicht und empfiehlt allgemein allow-downgrade und true überall dort, wo man sich auf den Upstream verlassen kann.¹⁵ Der Code wird ausgeliefert, der Root-Vertrauensanker wird ausgeliefert, und die Dokumentation wird ausgeliefert und empfiehlt, es anzuschalten. Die Voreinstellung sagt weiterhin nein.

Diese Spalte ist das ganze Problem. Eine Anforderung ist ein Hebel, und die .bank-Zahl weiter oben zeigt, was sie bewirkt. Eine Voreinstellung ist derselbe Hebel, ohne dass jemand etwas durchsetzen müsste, denn sie entscheidet den Ausgang für alle, die die Konfigurationsdatei nie öffnen, und das sind so ziemlich alle. Optional hat uns 1,63 % beim Staat und 13 % im Bankwesen gebracht. Menschen entscheiden sich nicht aktiv für Sicherheit, die sie nicht sehen können, und mit der Technik recht zu haben hat daran noch nie etwas geändert.

Der redliche Einwand ist, dass Validieren ab Werk Nutzer lahmlegt, wenn der Upstream-Resolver kaputt ist und nicht die Zone. Dafür ist allow-downgrade da, und es ist ein echter Kompromiss und kein geschenkter, denn ein Downgrade ist etwas, das ein Angreifer bewusst provozieren kann. Trotzdem wäre es eine enorme Verbesserung, allow-downgrade statt eines glatten no auszuliefern, und es würde den Schaden dorthin legen, wo er hingehört: zu dem, der 2026 immer noch einen Resolver betreibt, der mit DNSSEC nicht umgehen kann.

Validierung anschalten, und welcher Teil davon Fedoras ist

Fast alles, was folgt, ist systemds und nicht Fedoras und läuft auf Debian, Ubuntu oder Arch genauso. Zwei Dinge hier sind wirklich die der Distribution:

Upstream wählt in meson_options.txt allow-downgrade, also die Kompromisseinstellung und nicht die mutige.¹⁶ Fedora kompiliert es auf no und liefert dann eine zweite Haupt-Konfigurationsdatei, und da nur die erste gefundene Datei benutzt wird, ist die, die die Voreinstellungen dokumentiert, nicht mehr die, die gilt.¹⁵ Bearbeite also keine von beiden. Die Herstellerkopie gehört dem Paket, und ein Update gibt dir deine Änderung postwendend zurück; die /etc-Kopie ist eine Datei, deren übrige Zeilen stillschweigend fehlen.

Nimm stattdessen ein Drop-in, was der Block weiter oben tut. Es überschreibt, welche Hauptdatei auch gewonnen hat, es übersteht Paket-Updates, und es enthält nur das, was du geändert hast. Prüf das Ergebnis mit systemd-analyze cat-config systemd/resolved.conf, das jede Datei in der angewandten Reihenfolge ausgibt und klärt, was tatsächlich gewonnen hat.

Drei Einstellungen, und die Wahl zwischen den letzten beiden ist eine echte:

Fang mit allow-downgrade an, denn ein kaputter Resolver kostet dich dann nichts. Wechsle auf yes, sobald resolvectl status vierzehn Tage lang supported gesagt hat und du weißt, was dein Upstream tatsächlich ist. Die Details pro Distribution für alles außer Fedora stehen im Resolved-Beitrag.¹²

Was hält die Leute also wirklich auf

Also gut. Die Zahlen sind die Zahlen. Warum?

Vier Gründe werden genannt, und sie sind nicht alle Unsinn.

Schlüsselverwaltung war ein echtes Hindernis und ist es meistens nicht mehr. Signieren hieß früher, eigene Schlüsselzeremonien zu fahren, rechtzeitig vor Ablauf der Signaturen neu zu signieren und Schlüssel von Hand nach einem Plan zu rollen, den du selbst im Blick behalten musstest. Diese Arbeit macht auf den meisten verwalteten Plattformen heute der DNS-Anbieter, und Signieren ist ein Schalter. Es ist nicht nichts, aber es ist kein Projekt mehr.

Der Fehlerfall ist der redliche Einwand, und er ist der einzige der vier, für den ich echtes Verständnis habe. Mach DNSSEC falsch, und deine Domain verschlechtert sich nicht, sie verschwindet. Jeder validierende Resolver weist deine Einträge zurück, was er auch soll, und die Leute, die dich nicht erreichen, können von dir nicht erfahren, warum, denn dafür bräuchte es DNS.

Drei Dinge machen es schlimmer als einen gewöhnlichen Ausfall:

• Es scheitert an einer Uhr, nicht an einer Änderung. Signaturen haben ein Ablaufdatum. Eine Zone, die seit Dienstag niemand angefasst hat, kann am Sonntag weg sein, weil ein Nachsignierungsjob still aufgehört hat zu laufen.
• Es scheitert für die einen und nicht für die anderen. Nur validierende Resolver weisen dich zurück. Deine eigene Überwachung meldet die Seite, wenn sie nicht validiert, als kerngesund, während ein wachsender Teil des Internets dich nicht erreicht.
• Es scheitert auf der Schicht, mit der du Dinge reparierst. Fernzugriff, deine Statusseite und deine eigene E-Mail können alle unter dem Namen liegen, der gerade verschwunden ist.

Diese Furcht ist rational, sie hat große Betreiber vom Netz genommen, und jede redliche Argumentation für DNSSEC muss sich mit ihr hinsetzen, statt sie wegzuwischen.

Aber achte auf ihre Form: Es ist die Furcht vor einer betrieblichen Disziplin, die du derzeit nicht hast, nicht die Furcht vor der Technik.

Und achte darauf, wer in welcher Spalte zahlt. Eine unsignierte Zone, die gefälscht wird, kostet deine Kunden, lautlos, und niemand meldet je einen Vorfall, weil es nie jemand herausfindet. Eine signierte Zone, die abläuft, kostet dich, sofort, öffentlich, mit deinem Namen auf dem Post-mortem. Beides sind Fehler. Nur einer davon taucht in irgendjemandes Zielvereinbarung auf.

Zertifikate hatten dasselbe Problem und haben es gleich doppelt gelöst: Der Fehler wurde sichtbar gemacht, und dann wurde er automatisiert. Eine Browser-Warnung machte ein abgelaufenes Zertifikat zu jedermanns Problem, Überwachung folgte, und dann machte Let’s Encrypt die Erneuerung zu etwas, das ein Cron-Job um drei Uhr morgens erledigt. Nichts davon machte Zertifikate im Prinzip einfacher. Es machte das Vergessen schwerer.

Unterstützung durch Anbieter ist zehn Minuten Prüfen wert statt einer Annahme. Manche Registrare machen aus der Veröffentlichung eines DS immer noch ein Support-Ticket. Viele nicht.

Und der letzte Punkt ist die eigentliche Antwort, was die .bank-Registry weiter oben in diesem Beitrag bereits bewiesen hat. Es gibt kein Browser-Schloss für DNSSEC. Kein Kunde hat je eine Bank gewählt, weil ihre Zone signiert war, kein Prüfer lässt dich deswegen durchfallen, und keine allgemeine Vorschrift im Vereinigten Königreich verlangt es. Der Nutzen ist vollständig unsichtbar, wenn es funktioniert, der Preis für einen Fehler ist ein Ausfall mit deinem Namen daran, und die Person, die diesen Ausfall trägt, ist nicht die Person, die die Anerkennung bekäme.

Stell denselben Instituten eine Anforderung und eine jährliche Prüfung vor die Nase, und die Erfüllung geht von 13 % auf jedes einzelne. An der Technik hat sich zwischen diesen beiden Zahlen nichts geändert. An den Budgets, den Dienstleistern oder den Fähigkeiten auch nicht. Die einzige Variable war, ob jemand nachsehen würde.

Angesichts dieser Anreize ist das Überraschende nicht, dass 1,63 % der Behördendomains signiert sind. Überraschend ist, dass es neununddreißig sind.

Anschalten, ohne dich selbst vom Netz zu nehmen

Das ganze Risiko sitzt an einer Stelle, also steck die Mühe dorthin. Der Ablauf der Signatur ist der Fehler, der eintrifft, ohne dass jemand etwas angefasst hat, also alarmiere darauf:

dig +dnssec damiendye.uk SOA | awk '/RRSIG/ {print "sig expires", $9}'

Behandle es wie ein Zertifikat. Behalt das Datum im Auge, alarmiere weit davor, und mach die Erneuerung automatisch, damit der Alarm eine Rückfallebene ist und kein Arbeitsablauf.

Dann schalt es zu einer ruhigen Zeit an, an etwas, das nicht deine Hauptdomain ist, und lass vierzehn Tage vergehen, bevor du die machst, auf die es ankommt. Liegt dein DNS auf einer verwalteten Plattform, ist das Signieren selbst sehr wahrscheinlich ein Schalter, und der einzige wirklich manuelle Schritt ist, das DS bei deinem Registrar zu hinterlegen.

Ist das dasselbe Versagen wie bei IPv6?

Es ist der naheliegende Vergleich, also habe ich beide Standards in denselben Gruppen am selben Tag gemessen. Dieselben Organisationen, dieselben Leute, zwei Entscheidungen.

Neunzehnmal weiter beim Staat, auf denselben Domains.

Und jetzt setz dich damit hin, was wovon ist. IPv6 berührt jeden Router, jeden Host und jede Anwendung und will jahrelang Dual-Stack parallel betrieben haben. DNSSEC-Signierung ist ein Schalter und ein Eintrag, den du bei deinem Registrar einfügst.

Die weit schwerere Aufgabe schlägt die leichte überall, wo ich hingesehen habe. Womit die bequeme Erklärung ausfällt, dass Infrastrukturstandards eben so laufen, langsam und widerwillig. DNSSEC bewegt sich nicht langsam. Es bewegt sich nicht.

Ein Unterschied gehört DNSSEC allein. Roll IPv6 aus, und du bekommst etwas zurück: Erreichbarkeit, kein Carrier-Grade NAT, das du kaufen musst. Signier deine Zone, und du persönlich bekommst nichts. Der Schutz landet bei deinen Nutzern, und nur bei denen hinter einem validierenden Resolver. Du nimmst ein dauerhaftes Ausfallrisiko auf dich, zugunsten von Leuten, die du nie treffen wirst, und das ist schwerer vor einen Vorstand zu bringen als jedes technische Hindernis in diesem Beitrag.

Die IPv6-Hälfte dieser Argumentation habe ich anderswo geschrieben und wiederhole sie hier nicht.¹⁷

Liegt es daran, dass wir DNS immer noch nicht verstehen?

Zweiundvierzig Jahre, seit Mockapetris es im November 1983 aufgeschrieben hat.¹⁸ Sechzehn, seit die Root signiert wurde.

Ich halte das Verständnisproblem für real, und ich halte es für spezifischer, als dass Leute nicht wüssten, wie DNS funktioniert. Eine Menge fähiger Ingenieurinnen und Ingenieure kann Rekursion, Delegierung und Caching bestens beschreiben. Was fehlt, ist einen Schritt weiter, und dieser Schritt ist der, auf den es ankommt.

Fast niemand hat verinnerlicht, dass DNS ein Autorisierungssystem ist.

Es wird als Installation behandelt. Als Nachschlagetabelle. Als etwas, das Namen in Zahlen verwandelt und dem gehört, der das Netz betreibt, gedanklich neben DHCP abgelegt. Und dieser Rahmen ist auf eine Weise falsch, die still sehr viel entscheidet, denn in der Praxis ist die DNS-Antwort das, was entscheidet, zu welcher Maschine dein Verkehr geht, von welchem Server deine Updates kommen und welchen Host eine Zertifizierungsstelle für deinen hält. Wer die Antwort kontrolliert, kontrolliert alle drei.

Man sieht das Missverständnis im Muster, wer signiert hat. Nicht Budget, und auch nicht Können, und wenn man es einmal nebeneinanderlegt, ist es schwer als etwas anderes zu lesen denn als Muster dessen, was DNS für jeden von ihnen ist:

Die Leute, die DNS als Sache an sich am nächsten sind, haben alle signiert. Die Leute, die es als Versorgungsleistung konsumieren, haben es fast ausnahmslos nicht, wie gut ausgestattet und wie sicherheitsbewusst sie sich auch halten. GCHQ hat nicht signiert. Acht von neun Zertifizierungsstellen haben nicht signiert. Das sind keine Organisationen, denen es an klugen Köpfen oder an Bedrohungsmodellen fehlt.

Das ist auch der Grund, warum die Antwort auf Kaminsky 2008 lautete, das Raten zu erschweren, statt den Ausbau dessen zu Ende zu bringen, was Raten irrelevant macht. Das Raten zu erschweren ist eine Installationsreparatur, und als Installation hatte die Branche DNS abgelegt.

Eine Generation hat DNS als Verzeichnis gelernt und den Eintrag nie überarbeitet, als es still zu dem wurde, was entscheidet, mit wem du redest.

Wir haben es gebaut und dann liegen lassen

Die Registries, die Betreiber und die Standardisierer haben den schweren Teil gemacht. Sie haben ihn geschrieben, ihn ein Jahrzehnt lang durch die IETF gestritten, die Root in einer Zeremonie mit Zeugen signiert und 100 % der generischen Top-Level-Domains signiert bekommen. Das ist ein echtes Stück gemeinsamer Ingenieursarbeit, und es ist fertig.

Und dann haben wir übrigen unseren Teil nicht gemacht, weil unser Teil langweilig ist, unsichtbar, das ganze persönliche Risiko trägt und keine Anerkennung, und weil niemand nachsieht.

Das ist die Form jedes Standards, den niemand durchsetzt: Die Kosten trägt man allein, und der Nutzen zeigt sich erst, wenn genug andere sie auch getragen haben. Also haben die Registries sie getragen, und die Leute, die die Leitlinien zum Tragen veröffentlichen, haben es nicht.

Nur war die Aufgabe hier kleiner als fast alle davon. Die Kette war schon gebaut und bezahlt, von jemand anderem. Übrig blieb ein einziger Eintrag.

Und wenn das der Teil ist, den wir sehen können

Ein letzter Gedanke, und ich will klarstellen, dass er eine Schlussfolgerung ist und keine Messung, denn alles andere in diesem Beitrag ist gezählt und das hier nicht.

DNSSEC ist ungefähr die am leichtesten zu beurteilende Sicherheitsmaßnahme, die es gibt. Sie kostet nichts, die Arbeit ist ein Nachmittag, der Standard ist seit zwanzig Jahren fertig, und jeder kann sie von außen mit einem Befehl prüfen, ohne zu fragen. Kein Audit, kein Fragebogen, keine Geheimhaltungsvereinbarung. Ein dig.

Was sagt dir 1,6 % also über die Maßnahmen, die man von hier draußen nicht sehen kann?

Jede Zeile unter der ersten ist schwerer als eine Zone zu signieren, kostet echtes Geld, braucht jemanden, der sie verantwortet, und teilt genau die Eigenschaft, die DNSSEC versenkt hat: unsichtbar, wenn sie wirkt, und niemand prüft von außen nach. Das Einzige, was die oberste Zeile vom Rest trennt, ist, dass du sie prüfen kannst, umsonst, über jeden, sofort.

Hat eine Organisation die kostenlose Sache nicht gemacht, die einen Nachmittag dauert und die eine Fremde mit einem Befehl verifizieren kann, neige ich nicht zu der Annahme, dass sie die teuren Sachen gemacht hat, die ein Programm brauchen und nur von jemandem verifiziert werden können, den sie hereinlässt.

Der naheliegende Schritt ist nun, das gegen die Vorfallsakte zu testen, und ich habe es versucht. Von 23 britischen Organisationen mit dokumentierten schweren Vorfällen sind 22 unsigniert.

Diese Zahl beweist nichts, und ich werde nicht so tun als ob. Bei einer Grundrate von 1,6 % ist eine signierte Organisation in einer Liste von 23 genau das, was der Zufall vorhersagt. Schlimmer noch: Die signierte Menge besteht aus neun Gemeinderäten und drei Nationalparks, während die unsignierte Menge jedes große Ministerium und jede große Stadt umfasst, also treibt die Größe sowohl, wer angegriffen wird, als auch, wer in den Nachrichten landet. Jeder Vergleich der Vorfallsraten zwischen den beiden Gruppen würde messen, wie groß eine Organisation ist, und nicht, ob sie signiert hat.

Also nein, ich kann dir nicht zeigen, dass signierte Organisationen seltener kompromittiert werden. Das kann niemand, nicht mit Daten, an die irgendjemand herankommt, und wer dir etwas anderes erzählt, macht sich etwas vor.

Die getroffenen Organisationen haben aufgeschrieben, was versagt hat

Du brauchst meine Schlussfolgerung nicht, denn sie haben es selbst veröffentlicht, und was versagt hat, ist die Liste oben.

Die British Library ist die beste davon, weil sie es nach ihrem Ransomware-Angriff von 2023 freiwillig und ausführlich aufgeschrieben hat. Ihr eigener Bericht benennt die Ursachen: Einstieg höchstwahrscheinlich über ein Drittanbieterkonto auf einem Terminaldienste-Server ohne Mehrfaktor-Authentifizierung, dann Altinfrastruktur und begrenzte Netzwerksegmentierung, die den Angreifern erlaubten, sich über den Bestand zu bewegen, wobei die wachsende Komplexität des Drittanbieterzugangs intern schon 2022 als Risiko vermerkt war und ein Jahr später immer noch bestand.¹⁹ Die Datenschutzaufsicht ICO kam zu denselben Schlüssen.²⁰

Drei Zeilen der Tabelle oben also, von der Organisation selbst von innen bestätigt statt von mir hier draußen gefolgert.

Und bevor jemand daraus einen Stock macht: Die British Library verdient das Gegenteil, und ich werde deutlich sagen, warum.

Sie waren offen. Fast niemand sonst ist das. Es gab keinerlei Verpflichtung, auch nur ein Wort davon aufzuschreiben. Das übliche Drehbuch nach einem Vorfall lautet, so wenig zu sagen, wie das Gesetz erlaubt, es durch eine Kommunikationsabteilung zu geben, jede konkrete Bestätigung abzulehnen und zu warten, bis die Nachrichtenlage weiterzieht. Genau das haben die meisten Organisationen in den unsignierten Spalten oben getan, als sie an der Reihe waren, und darum hängt es an der Entscheidung einer einzigen Institution, sich anders zu verhalten, dass dieser Abschnitt überhaupt geschrieben werden kann.

Stattdessen haben sie einen achtzehnseitigen Bericht veröffentlicht, der ihre eigenen Versäumnisse benennt, öffentlich, damit andere Institutionen daraus lernen können. Das ist das Verhalten, das man sich von jeder Organisation in diesem Beitrag wünschen würde und von fast keiner bekommt. Der Grund, warum ich dir zeigen kann, was in einer kompromittierten Organisation tatsächlich versagt, ist, dass die British Library sich entschieden hat, es dir zu sagen.

Und es gibt einen zweiten Grund, warum die übrigen schweigen, und der ist schlimmer als eine Kommunikationsstrategie. Manche von ihnen gibt es nicht mehr.

KNP Logistics bewegte seit 1865 als Knights of Old Fracht. Im Juni 2023 kam die Akira-Gruppe herein, verschlüsselte das Unternehmen und verlangte etwa fünf Millionen Pfund. Bis September war die Gruppe insolvent und 730 Menschen waren ihre Arbeit los.²¹ Hundertachtundfünfzig Jahre, weg in vierzehn Wochen, und dort schreibt niemand irgendwelche Lehren für dich auf.

Wenn die unsignierten Spalten oben also still wirken, besteht diese Stille aus drei verschiedenen Dingen: Organisationen, die noch nicht getroffen wurden, Organisationen, die getroffen wurden und so wenig sagten, wie das Gesetz erlaubt, und Organisationen, die getroffen wurden und weg sind. Nur die erste Gruppe hat noch Zeit zu handeln.

Was das Nächste zur redlichen Prüfung meiner eigenen Argumentation macht und nicht zum billigen Seitenhieb. Ich habe ihre Zone geprüft:

$ dig +short bl.uk DS
                                          (nothing)
$ dig +short bl.uk DNSKEY
                                          (nothing)

bl.uk ist unsigniert. britishlibrary.co.uk ebenfalls. Zwei Jahre nach einem Ransomware-Angriff, der die Institution monatelang lahmlegte, nach einem öffentlichen Bericht, nach einem ICO-Befund und nach der gründlichsten Runde sicherheitstechnischer Aufmerksamkeit, die eine Organisation je bekommt, ist die kostenlose Maßnahme, die einen Nachmittag dauert und die eine Fremde mit einem Befehl verifizieren kann, immer noch nicht erledigt.

Ich lese das nicht als Nachlässigkeit, und ich halte sie deswegen nicht für schlechter als die unsignierten Organisationen, die gar nichts veröffentlicht haben. Ich lese es als den stärksten Beleg in diesem Beitrag für das, worum es die ganze Zeit ging. Wenn DNSSEC nicht einmal hier gemacht wird, bei einer Organisation, die durchs Feuer gegangen ist, die Lehren aufgeschrieben hat und über die die Aufsicht gegangen ist, dann wird es nicht übersprungen, weil Leute nachlässig sind. Es wird übersprungen, weil es nichts und niemand je auf die Liste setzt.

Das ist die redliche Fassung der Argumentation. Nicht unsignierte Zonen verursachen Einbrüche, was unbeweisbar und vermutlich falsch ist. Sondern: Die Maßnahmen, die von außen niemand sehen kann, sind nach dem veröffentlichten Zeugnis derer, die es durchgemacht haben, genauso vernachlässigt wie die eine Maßnahme, die von außen jeder sehen kann. DNSSEC ist nicht die Ursache. Es ist die Probe, die du ziehen darfst.

Und deshalb lohnt sich die Messung überhaupt. Nicht weil eine unsignierte Zone für sich genommen der Weltuntergang wäre, sondern weil sie eine der ganz wenigen Sicherheitseigenschaften ist, die eine Außenstehende ehrlich, umsonst und über jeden prüfen kann, ohne hereingelassen zu werden. Behandle sie als Rauchmelder und nicht als Urteil, und dann geh und stell die härteren Fragen an den, bei dem er losgeht.

Der einzige Teil, den du kontrollierst

Womit der einzige Teil bleibt, den irgendeine von uns tatsächlich kontrolliert. Deine eigene Zone. Nicht die des NCSC, nicht die von Microsoft, nicht die deiner Bank.

Geh und frag deinen Elternteil, ob er für dich bürgt:

dig +short yourdomain.uk DS

Kommt das leer zurück, bist du nicht signiert, und auf den meisten verwalteten DNS-Plattformen ist die Lösung 2026 ein Schalter und ein DS-Eintrag bei deinem Registrar. Schalt es an, und behalt dann den Ablauf so im Auge, wie du deine Zertifikate ohnehin schon im Auge behältst, denn das ist die Disziplin, die die Sache tatsächlich braucht.

Das ist die ganze Aufgabe. Ein Eintrag, und ein Datum in deiner Überwachung.

Also bitte, mach wenigstens diese eine Sache. Nicht weil eine Aufsichtsbehörde kommt, denn für die meisten von euch kommt keine, und nicht weil dir jemand danken wird, denn das wird niemand. Mach es, weil niemand kommt, und weil ein Standard, den du einhältst, wenn keiner nachsieht, der einzige ist, der je etwas wert war.

Neununddreißig Gemeindeschreiber und ein Geheimdienst haben es hinbekommen. Reiß dich zusammen und bring es hinter dich.