DNSSEC: je verkeer beschermen tegen vervalsing

Elke naam die je machine vandaag opzocht, geloofde hij. Je bank, je updates, je mailserver. Er kwam een antwoord van het netwerk terug en nergens controleerde iets of het kwam van de organisatie die de naam bezit of van wie als eerste een pakket wist te plaatsen. Op een gewoon DNS-antwoord staat geen handtekening, er valt niets te verifiëren, en er is niets dat het zou merken als er iets mis was. Dat was een redelijk ontwerp in 1983 en het is dat al heel lang niet meer.

DNSSEC is precies daarvoor de oplossing, en het is niet nieuw en niet duur. De eigenaar van de zone ondertekent zijn records. De zone erboven publiceert een hash van hun sleutel en ondertekent die, en zo verder omhoog, tot de keten uitkomt bij één rootsleutel die je resolver van geboorte af aan kent. Alles wat de keten controleert kan een echt antwoord van een vervalst antwoord onderscheiden. Het is sinds 2005 een standaard, de root is sinds juli 2010 ondertekend, en de registries publiceren de records voor niks.^{1 2}

De top van de boom is af. Ik heb voor dit stuk de live rootzone geteld en 1.351 van de 1.438 topleveldomeinen zijn ondertekend, alle 1.038 generieke erbij. Daarna valt het van een klif. Van de 2.390 gov.uk-domeinen die nog resolven zijn er negenendertig ondertekend, en negen daarvan zijn dorpsraden. MI6 kreeg het voor elkaar. Het National Cyber Security Centre niet.

Dit is wat een vervalst antwoord werkelijk kost en wat ondertekenen daaraan doet, geteld in de live rootzone op 27 september 2026 en verder omlaag door de overheid, de banken, de distributies waarvan je installeert en de certificaatautoriteiten. Eén commando per domein, niemands toestemming nodig, en elke naam vermeld zodat je het met mijn keuzes oneens kunt zijn in plaats van met mijn rekenwerk. Daaronder ligt de vraag die ik eigenlijk beantwoord wilde zien. Tweeënveertig jaar nadat Mockapetris DNS opschreef: is de reden dat vrijwel niemand ondertekent dat vrijwel niemand ooit begreep wat DNS beloofde?

Wat DNSSEC is, en waar het voor dient

In één zin: DNSSEC zet een cryptografische handtekening op DNS-antwoorden, zodat een resolver kan bewijzen dat een antwoord van de eigenaar van de zone kwam en niet van wie toevallig als eerste antwoordde.

Het is geen versleuteling, geen firewall en geen filter. Het is een handtekening en een sleutelketen die teruggaat naar één sleutel die je resolver al vertrouwt. Dat is het hele idee.

Nu de aanval, want het protocol slaat pas ergens op als je hebt gezien waar het voor dient.

Een resolver die om een naam vraagt stuurt een query en wacht. Het antwoord wordt gematcht op een handvol velden: de querynaam, het type, de bron- en bestemmingsadressen en -poorten, en een transactie-ID van 16 bit. Wie een pakket kan produceren dat op die velden past, vóórdat het echte antwoord er is, wint. De resolver cachet de vervalsing en geeft hem aan elke client die erom vraagt, zolang als de aanvaller heeft gezegd.

Het werk van Dan Kaminsky uit 2008 is wat iedereen zich half herinnert.³ Wat ertoe doet is niet dat cachevergiftiging bestond, want dat was er al jaren voor bekend. Het is dat hij een manier vond om de gok eindeloos te herhalen. Vraag om een naam die niet bestaat, en elke mislukte poging kost niets en laat je meteen opnieuw proberen, dus de aanvaller racet niet langer één keer tegen een gecacht record dat een dag meegaat. Het antwoord van de industrie was willekeur toevoegen: willekeurige bronpoorten bovenop het willekeurige transactie-ID, wat de gok van één op 65.536 naar ongeveer één op twee miljard bracht.

Dat is een groter getal. Het is geen bewijs.

En de mitigatie brokkelt sindsdien af, want elk van die velden is een gok die moeilijker is gemaakt in plaats van een feit dat controleerbaar is gemaakt. Poortwillekeur wordt ongedaan gemaakt door een NAT die poorten voorspelbaar herschrijft. Fragmentatie-aanvallen omzeilen het matchen volledig. Off-path-aanvallen blijven in nieuwe vormen terugkomen, en elke vorm krijgt zijn eigen pleister.

Ondertekenen beëindigt de discussie. Een ondertekend antwoord verifieert tegen een sleutel die de resolver aan de root kan ketenen, of het doet dat niet, en geen hoeveelheid raden levert een aanvaller een geldige handtekening op.

Wat het winnen van die race ze werkelijk oplevert

Wees er concreet over, want “cachevergiftiging” klinkt abstract en de gevolgen zijn dat niet.

De derde rij maakt van een DNS-probleem een certificaatprobleem. Domeingevalideerde uitgifte werkt door jou te vragen een record te publiceren en dat vervolgens op te zoeken. Kan een aanvaller sturen wat de CA tijdens die lookup te zien krijgt, dan geeft de CA hem echte papieren voor jouw naam, en daarna is het slotje in de browser van hem. Alles wat een gebruiker is geleerd te controleren zal zeggen dat de site in orde is.

De vierde rij is de stille. Een vervalst antwoord hoeft niemand ergens heen te sturen. Een updatedienst naar een zwart gat wijzen is genoeg, en niets in de stack is gebouwd om te schreeuwen over updates die nooit aankwamen.

Wat ondertekenen daaraan doet

Het mechanisme is eenvoudiger dan zijn reputatie.

Elke ondertekende zone heeft een sleutelpaar. De eigenaar van de zone ondertekent elke recordset met de private helft en publiceert er een RRSIG naast. De publieke helft komt als DNSKEY in de zone te staan. Tot zover bewijst dit niets, want een aanvaller die een A-record kan vervalsen kan er een DNSKEY bij vervalsen.

Wat het dichttimmert is het DS-record, en de DS staat in de bovenliggende zone, niet in die van jou. Het is een hash van jouw sleutel, gepubliceerd en ondertekend door de zone erboven. Dus uk staat garant voor jouw sleutel, de root staat garant voor uk, en je resolver kende van geboorte af precies één ding: de sleutel van de root.²

Drie recordtypes doen het werk, en je wilt weten welke welke is, want maar één ervan is andermans werk:

Je kunt de eerste twee de hele middag in je eentje publiceren en er verandert niets. Tot de ouder een DS publiceert ben je een ondertekende zone die niemand kan verifiëren, en dat komt op hetzelfde neer als een niet-ondertekende zone met extra werk erin.

$ 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)

In het midden staat de eigen zone van deze site. uk staat er garant voor, algoritme 13 is ECDSA P-256, en een validerende resolver kan elk antwoord erover terugbewijzen tot aan de root. bbc.co.uk geeft niets terug, dus dat kan daar niet.

Eén commando vertelt je of een zone in de vertrouwensketen zit. Publiceert de ouder geen DS voor je, dan ben je niet ondertekend, wat je verder ook hebt geconfigureerd, en een validerende resolver behandelt elk antwoord over jouw domein als onverifieerbaar.

Dat ene record is de hele test.

Wat het niet doet

Het is goed dat ronduit te zeggen, want overdrijven is de halve reden dat mensen het wantrouwen.

Over die laatste rij struikelen mensen. DNSSEC bewijst dat het antwoord kwam van wie de zone beheert. Het heeft geen enkele mening over de vraag of die partij deugt.

Het doet precies één ding. Het maakt het vervalsen van een antwoord rekenkundig onhaalbaar in plaats van slechts onwaarschijnlijk.

Hoe je elke zone controleert, ook die van iemand anders

Dit is het deel dat de rest van dit stuk mogelijk maakt, en het kost één commando.

Een zone zit in de vertrouwensketen als zijn ouder een DS voor hem publiceert. Dat is de hele test, en je kunt hem tegen iedereen draaien, zonder toestemming, vanaf elke machine:

dig +short damiendye.uk DS

Iets terug betekent ondertekend. Niets terug betekent niet ondertekend, wat de zone verder ook geconfigureerd heeft.

Wil je meer dan een ja of nee, dan zijn er nog drie het kennen waard:

Twee valkuilen voordat je je eigen resultaten vertrouwt, want ze hebben me allebei te pakken gehad.

dig +short … DS drukt een CNAME-keten af als de naam een alias is, en een hostnaam met cijfers erin lijkt genoeg op een DS-record om een naïef script om de tuin te leiden. Een echte DS heeft vier velden: key tag, algoritme, digesttype, hex-digest. Match op die vorm, of je telt niet-ondertekende zones als ondertekend.

Een DS onder een niet-ondertekende ouder betekent niets. De keten moet de root bereiken. update.microsoft.com heeft een DS, en microsoft.com niet, dus de tak is hoe dan ook onverifieerbaar. Controleer altijd het hele pad, niet één niveau.

Alles in de rest van dit stuk is zo gemeten. Geen scanner, geen dashboard van een derde, geen ranglijst van een leverancier. Vraag de ouder of hij garant staat voor het kind, en eis dat het antwoord als een DS parseert.

De rootzone is af

Hier is de heersende wijsheid simpelweg verouderd. Mensen praten nog steeds over DNSSEC alsof de infrastructuur het probleem is.

Ik heb de live rootzone opgehaald op 27 september 2026, serial 2026092701, en de delegaties geteld tegen de DS-records.⁴

Elk generiek topleveldomein is ondertekend. Alle 1.038, zonder uitzondering, omdat ICANN’s Registry Agreement het eist van alles wat onder het nieuwe gTLD-programma is gedelegeerd. De 87 die niet ondertekend zijn, zijn vrijwel allemaal landcodes, en de lijst bestaat grotendeels uit kleine gebieden en een handvol staten:

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 staat erbij, wat eerder een curiositeit is dan een probleem, want niemand doet er iets mee. Net als het Vaticaan, Noord-Korea, Cuba en Syrië. Net als tk, dat jarenlang de grootste bron van gratis domeinen op internet was en daarmee een betrouwbare bron van misbruik.

Dus de top van de boom is klaar. De registries deden het moeilijke deel, het dure deel en het deel dat internationale coördinatie vroeg, en maakten het af. Wat er onder dit punt gebeurt, valt dus niet op de infrastructuur te schuiven.

En dan houdt het abrupt op

Onder het TLD keert het beeld volledig om.

Ik heb voor elke verzameling hieronder op dezelfde manier gemeten: vraag de ouder om een DS, accepteer alleen een record dat ook werkelijk als een DS parseert. Alles hier is geteld op 27 september 2026.

Vierennegentig procent aan de top. Anderhalf procent aan de onderkant. De vertrouwensketen is een ketting met het ene uiteinde aan de muur geschroefd en het andere op de vloer.

Een woord over de methode, want een getal dat zo slecht is verdient er een. De gov.uk-rij is een telling en geen steekproef: het is elk tweedeniveaudomein in het eigen gepubliceerde register van de overheid, gefilterd op de 2.390 die nog resolven. De andere rijen zijn samengestelde lijsten van de organisaties waarvan vervalsing werkelijk pijn zou doen, wat een oordeel is, en ik heb elke naam erin hieronder vermeld zodat je het met mijn keuzes oneens kunt zijn in plaats van met mijn rekenwerk.

De overheidstelling: 39 van de 2.390

De officiële lijst met gov.uk-domeinen die de overheid publiceert telt 3.004 tweedeniveaunamen. Daarvan resolven er nog 2.390. Negenendertig zijn ondertekend.

Voor de details, één ding over dat register. De meest recente versie die gov.uk publiceert is gedateerd 1 oktober 2016.⁵ Tien jaar oud, voor de gezaghebbende lijst van de domeinen waarop de Britse staat antwoordt. Dat is een eigen kleine bevinding en daar laat ik het bij.

Kijk nu naar welke negenendertig.

Lees die eerste kolom nog eens. De geheime inlichtingendienst heeft zijn zone ondertekend. Het National Cyber Security Centre niet.

GCHQ evenmin, en dat is de moederorganisatie van het NCSC zelf. De Cyber Essentials-regeling evenmin, die bestaat om te certificeren dat de beveiliging van anderen toereikend is. Ik ga niet doen alsof dat iets anders is dan opmerkelijk.

En negen van de negenendertig zijn dorps- en gemeenteraden. Abinger. Aldenham. Ashmansworth. Wheathampstead. Frampton on Severn. Plaatsen met een secretaris, een parttime website en een budget waar in Whitehall geen dag advieswerk van betaald kan worden. Zij kregen het voor elkaar. HMRC, dat de belastinggegevens van elke volwassene in het land beheert, niet.

Mag ik vragen wat er in het proces dat toelaat. Niet wie: wat. Want het NCSC publiceert richtlijnen waarin het anderen vertelt DNSSEC uit te rollen, en de dienst die de richtlijn schrijft heeft niet gedaan wat de richtlijn zegt. Of het is belangrijk, en dan had het orgaan dat dat zegt het jaren geleden moeten doen, of het is dat niet, en dan moet de richtlijn dát zeggen.

Het excuus dat aangeboden zal worden is schaal en legacy. Dat overleeft de eerste kolom niet. somerset.gov.uk is een eenheidsgemeente die 580.000 mensen bedient en hij is ondertekend. birmingham.gov.uk is een eenheidsgemeente die 1,1 miljoen mensen bedient en hij is het niet. Hetzelfde land, dezelfde registry, dezelfde registrars, hetzelfde geld beschikbaar voor dezelfde leveranciers. De een deed het.

De software waarvan je updates haalt

Dit is het deel dat je meer zorgen zou moeten baren dan de banken, en het is het deel dat vrijwel niemand meet.

Elke machine die je draait haalt op gezette tijden code ergens vandaan, en dat ergens vindt hij door het aan DNS te vragen.

Negenennegentig distributies en BSD’s, waarvan er zesennegentig nog resolven. Negentien zijn ondertekend.

Negentien van de zesennegentig. En de namen in die niet-ondertekende lijst zijn niet obscuur: Ubuntu, Red Hat, SUSE, Oracle, Arch, Alpine, NixOS, Rocky, elke Ubuntu-smaak, en zowel kernel.org als gnu.org.

Van de beveiligings- en privacydistributies verwachtte ik dat ze anders zouden zijn, en dat zijn ze grotendeels niet. Tails en Whonix hebben ondertekend, wat past. Kali, Parrot, Qubes, Trisquel en PureOS niet, wat niet past. OpenBSD heeft in vijfentwintig jaar een reputatie opgebouwd met het precies goed doen van deze klasse dingen en heeft openbsd.org niet ondertekend, terwijl FreeBSD, NetBSD, HardenedBSD en MidnightBSD dat allemaal wel hebben.

De pakketregisters komen dicht bij een schone veeg in de verkeerde kolom: npm, crates.io, RubyGems, Packagist, Docker Hub en Quay zijn allemaal niet ondertekend. pypi.org is de uitzondering, en eer wie eer toekomt, want het is ook een van de meest aangevallen.

Microsoft, en het updatekanaal

Vier van de zesentwintig Microsoft-zones zijn ondertekend, en ze zitten allemaal in één hoek van de omgeving:

De Outlook- en Office-namen zijn ondertekend en verder niets, wat eruitziet als de beslissing van één team in plaats van die van een bedrijf. Let op wat er in de rechterkolom naast de updatedienst staat: github.com en npmjs.com, twee van de grootste distributiepunten voor code op internet, allebei van Microsoft, allebei niet ondertekend.

$ 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 is ondertekend, dus er staat technisch niets in de weg. Microsoft zou vanmiddag een DS kunnen publiceren.

Het standaardantwoord op waarom dat niet uitmaakt is dat DNS maar één laag is. Updatepakketten zijn code-ondertekend, de client controleert de handtekening, en het verkeer loopt over TLS. Breek de DNS en je krijgt nog steeds geen code uitgevoerd.

Dat antwoord hangt volledig af van de soliditeit van dat ondertekenen. Die is er niet geweest.

Wees precies over die laatste rij, want mensen overdrijven hem. De gestolen sleutel ondertekende identiteitstokens, geen binaries. Hij hoort om een andere reden in de tabel: het beheer van Microsofts ondertekenmateriaal faalde, twee jaar lang onopgemerkt, via een crashdump en een gecompromitteerd engineeraccount.

De rijen erboven zijn de faalgevallen van code-ondertekening, en die zijn erger. Twee keer in één jaar zette Microsofts eigen hardwarecertificeringsprogramma een Microsoft-handtekening op een werkende rootkit en leverde die uit. Geen vervalst certificaat, geen gestolen sleutel. Het legitieme proces, dat malware ondertekent, precies zoals ontworpen.

Dus de verdediging waardoor je DNS als optioneel kunt behandelen is in elf jaar tijd ondermijnd door vervalsing, door procesmisbruik en door sleuteldiefstal. Een aanvaller met een handtekening die de machine accepteert is geen gedachte-experiment. Voor een statelijke actor is het een inkoopprobleem, geen onderzoeksprobleem.

Geef die aanvaller een vervalst DNS-antwoord en het plaatje is compleet: ondertekende code die zij beheersen, geleverd vanaf een server die de machine voor Microsoft houdt, over een verbinding waar niets in de stack vragen bij stelt. Dat is Flame, met beter sleutelmateriaal.

DNSSEC is de enige laag in die keten die zich niets aantrekt van wiens ondertekensleutel de aanvaller heeft. Het valideert het pakket niet, het valideert waar de machine heen is gestuurd, en het faalt onafhankelijk van elk certificaat en elke handtekening in het spel. Wat precies is wat je van een tweede laag wilt, en precies waarom het niet de laag zou moeten zijn die uitstaat.

En er is een goedkopere aanval die geen sleutel nodig heeft. Vervals het antwoord zodat de updatedienst nergens nuttigs uitkomt, en de machine patcht nooit meer. Geen foutmelding waar de gebruiker iets mee doet, geen alarm, alleen een vloot die stilletjes achteropraakt terwijl het dashboard groen blijft. Als ik een omgeving wilde hebben die over zes maanden klaar is om uit te buiten, zou ik er niets naartoe duwen. Ik zou er alleen voor zorgen dat er niets aankwam.

De banken, volledig

Dit keer geen steekproef. Achtennegentig Britse banken en bouwfondsen, die allemaal op de dag zelf resolveden, van de winkelstraat tot aan fondsen met één kantoor en een victoriaanse naam.

Dertien zijn ondertekend.

Achtendertig bouwfondsen. Geen enkele ondertekend. Dat zijn de instellingen die de hypotheek op heel wat huizen houden.

Twee patronen in die ondertekende kolom vallen op. Lloyds Banking Group heeft drie van zijn merken ondertekend, lloydsbank.com, halifax.co.uk en bankofscotland.co.uk, en de Co-operative Bank heeft ze allebei ondertekend. Het besluit wordt dus één keer genomen, op organisatieniveau, en daarna toegepast. Er zit geen drempel per domein in.

En Monzo heeft ondertekend terwijl Starling dat niet heeft. Twee challengerbanken die binnen een jaar van elkaar zijn opgericht, op vergelijkbare moderne infrastructuur, met dezelfde toezichthouder en dezelfde beschikbare registrars. De een deed het.

De ene plek waar iedereen het wel doet

Kijk naar de laatste twee namen in de ondertekende kolom: allica.bank en weatherbys.bank.

.bank is een beperkt topleveldomein dat wordt beheerd door fTLD Registry Services, en de beveiligingseisen ervan maken DNSSEC verplicht, naast TLS en e-mailauthenticatie, met jaarlijkse herverificatie van elke registrant.⁹

Twee is een klein getal, dus neem het als demonstratie en niet als statistiek. De eis is nog steeds het enige dat veranderde.

Dat is het antwoord op elk excuus verderop in dit stuk, en het komt voordat de excuses er zijn. Dezelfde banken, dezelfde leveranciers, dezelfde budgetten en dezelfde vaardigheden leveren 13% naleving op wanneer het optioneel is en 100% wanneer iemand jaarlijks controleert. Er veranderde technisch niets. Iemand vroeg er gewoon om.

Niemand bewaakt de bewakers

Eén certificaatautoriteit van de negen.

Dit zijn de organisaties wier hele bedrijf eruit bestaat te bewijzen dat iets is wat het beweert te zijn. Het zijn ook de organisaties die domeincontrole valideren via DNS, door jou te vragen een record te publiceren en dat vervolgens op te zoeken. De lookup die bepaalt of je een certificaat voor een domein krijgt is bij acht van deze negen een lookup die niemand kan verifiëren.

Geen hypothetisch geval, dat. Het is de gedocumenteerde vorm: vervals de validatielookup, laat het certificaat aan jou uitgeven, en nu heb jij geldige papieren voor een naam die niet van jou is. DNSSEC is een van de weinige dingen die dat wezenlijk moeilijker maken, en de mensen die het het meest zou beschermen hebben het niet uitgerold.

Ik zeg het je gratis en voor niets. Is je verdienmodel identiteit en heb je je eigen zone niet ondertekend, dan is het argument dat het moeilijk is niet voor jou beschikbaar.

En wie controleert er eigenlijk?

Ondertekenen is maar de helft. Een ondertekende zone beschermt niemand tenzij er aan de andere kant iets de handtekening verifieert, en hier wordt het beeld slechter in plaats van beter.

Er zijn twee plekken waar validatie kan gebeuren, en ze zijn niet gelijkwaardig:

Vrijwel alle validatie ter wereld is van de eerste soort. Google, Cloudflare en Quad9 valideren allemaal, en samen bedienen ze een enorm aantal gebruikers. Dat telt. Maar het betekent dat de eigenschap die de meeste mensen hebben mijn resolver zegt dat dit in orde was is.

Wat elk besturingssysteem kan

Twee daarvan verdienen meer dan een rij.

Apple deed het werk stilletjes. iOS 16 en macOS Ventura voegden DNSSEC-validatie aan de clientkant toe, in Apples eigen woorden op WWDC 2022: “iOS 16 and macOS Ventura now support client side DNSSEC validation.”¹⁰ Het is opt-in in plaats van automatisch, en het is opt-in op de juiste granulariteit, zodat een applicatie die erom geeft er per sessie of per request om kan vragen:

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true

Een echte validerende resolver op een telefoon, die handtekeningen op het apparaat controleert, en vrijwel niemand merkte op dat het uitkwam. Daarvoor bood mDNSResponder kDNSServiceFlagsValidate aan iedereen die bereid was de C-API te gebruiken.

Android biedt het niet. De DNS-resolver is sinds Android 10 een bij te werken module en kreeg DNS over TLS in Android 9, dus op DNS-gebied heeft het platform niet stilgezeten. Maar noch de AOSP-resolverdocumentatie noch de publieke DnsResolver-API documenteert DNSSEC-validatie, en de reden dat bibliotheken als MiniDNS bestaan en adverteren dat ze “DNSSEC close to your application” brengen, is dat het platform het niet brengt. Ik kon geen primaire bron vinden die botweg stelt dat het onmogelijk is, dus ik houd het niet hoger dan: wordt niet aangeboden, en je zou het zelf moeten schrijven.

En zelfs waar het werkt wordt het weggegooid

Nog één ding, van deze machine, dat ik niet verwachtte te vinden.

De upstream-resolver hier valideert en zegt dat ook. systemd-resolved gooit dat met DNSSEC=no weg voordat enige applicatie het ziet:

# ---- 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

Dezelfde naam, hetzelfde antwoord, dezelfde seconde. Vóór de drop-in deed de upstream het werk, zette de AD-bit, en liet de lokale daemon hem op de grond vallen. De standaard is dus niet simpelweg we valideren hier niet, hij is we valideren hier niet, en we geven het oordeel van wie het wel deed niet door. Daarna is de bit terug, en deze keer is hij van ons in plaats van andermans bewering.

resolvectl zet het oordeel in woorden, en het scheidt de twee die ertoe doen:

$ 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

Let op wat de tweede niet is. Het is geen fout. Een niet-ondertekende zone komt terug als niet-geauthenticeerd en niet als bogus, de resolutie slaagt, en nergens klaagt iets. Dat is het hele probleem met 1,63% herschreven als een commando: validatie aanzetten laat niet-ondertekende zones niet falen, het maakt ze zichtbaar, en alleen voor wie gaat kijken.

Het grootste client-OS zakt voor de meest elementaire controle

Nu het andere uiteinde van de schaal, en daar is het geen nek-aan-nekrace.

De Windows-DNS-client is, in Microsofts eigen beschrijving, “security-aware” maar “non-validating”. Hij voert geen DNSSEC-validatie uit. Hij kan er niet toe gebracht worden. Wat hij in plaats daarvan doet is zijn geconfigureerde DNS-server vragen te valideren, en vervolgens in het antwoord naar de AD-bit kijken.¹¹

Drie dingen daarover, en geen daarvan is klein:

• Hij controleert nooit een handtekening. De sterkste garantie die beschikbaar is voor het grootste clientbesturingssysteem ter wereld is één bit, gezet door welke machine er ook antwoordde.
• Hij doet dat niet eens standaard. De client zet alleen de DO-bit en eist AD voor namespaces die in de Name Resolution Policy Table staan, een Group Policy-object dat iemand bewust moet configureren. Staat daar geen regel in, dan draagt de query helemaal geen DNSSEC-verwachting mee.
• Microsoft zegt dat de bit IPsec nodig heeft om iets te betekenen. Hun documentatie is expliciet dat, omdat de client niet valideert en op de server leunt, “IPsec is used to establish this trust relationship”. Een AD-bit die over een niet-geauthenticeerde verbinding binnenkomt is een bewering van wie er het eerst was, en dat is precies de aanval waarvoor deze hele technologie bestaat.

Dus op de desktop met de grootste geïnstalleerde basis, uit de doos: geen validatie, geen AD-eis, en geen geauthenticeerd kanaal naar de resolver. De meest elementaire controle staat niet alleen uit. Hij is nooit gebouwd.

En de gebruikelijke verdediging, dat clientbesturingssystemen dit soort dingen nu eenmaal niet doen, stierf in 2022. Apple leverde validatie op het apparaat aan elke iPhone en Mac in hetzelfde jaar waarin Microsoft dat niet deed. De vergelijking is niet langer desktop tegen server, of mobiel tegen vast. Het is de ene leverancier die het bouwde tegen de andere die dat niet heeft gedaan.

Dat doet er meer toe dan hetzelfde gat op Linux, vanwege wie het raakt. Een Linux-server wordt meestal beheerd door iemand die validatie vanmiddag aan kan zetten en weet wat een DS-record is. De machines die helemaal niet kunnen valideren, bij geen enkele instelling, zijn de machines die op de bureaus staan bij de organisaties waarvan de zones in de tabellen hierboven niet ondertekend zijn. systemd-resolved levert de mogelijkheid uitgeschakeld, en dat is een besluit dat je in één regel terugdraait.¹² Het Fisher-Price OS (Windows) levert zonder de mogelijkheid.

De dienst die door DNS bijeen wordt gehouden

Alles tot hier ging over namen op het publieke internet. Hetzelfde gat bestaat binnen het gebouw, en daar is het dragend.

Active Directory heeft voor niets een vast adres. Een machine die lid is van het domein weet niet waar zijn domeincontroller woont, dus vraagt hij het aan DNS. Het locatorproces bevraagt _ldap._tcp.dc._msdcs.<domain> voor de controllers en _kerberos._tcp voor de KDC, en waar hij zich tegen gaat authenticeren is wat daarop terugkomt.¹³

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

Vervals dat antwoord en de machine brengt zijn authenticatieverkeer naar een host die jij hebt uitgekozen. Wees duidelijk over wat dat wel en niet is: Kerberos geeft geen ticket aan een bedrieger die de sleutels niet heeft, dus dit is op zichzelf geen domeinovername. Het is een positie in het pad, en daar worden de interessante aanvallen uit opgebouwd. Forceer de terugval naar NTLM en relay hem. Ga in het midden zitten van verkeer dat naar een controller had moeten gaan. Of wijs de hele omgeving naar niets en kijk hoe de aanmeldingen stoppen.

Group Policy, aanmeldscripts, gekoppelde schijven en elke trust stroomafwaarts van de aanmelding worden allemaal op dezelfde manier gevonden. Het is de meest waardevolle verzameling namen die de meeste organisaties bezitten, en hij zit daar niet ondertekend.

Microsoft bouwde de serverhelft van de oplossing, en bouwde die goed. Een AD-geïntegreerde zone kan ondertekend worden, online ondertekenen van dynamische zones landde in Windows Server 2012, en omdat de zone in de directory leeft, repliceren de private ondertekensleutels via de AD-replicatie zelf naar de andere DNS-servers.¹⁴ Het werkelijk lastige deel van DNSSEC, sleutels bij de machines krijgen die ze nodig hebben, is hier veertien jaar geleden opgelost door het ding waar de zone toch al doorheen repliceerde.

Dan stopt het op dezelfde twee plekken als al het andere:

Dus de interne zone die bepaalt welke machine jouw domeincontroller mag zijn, is in de meeste omgevingen even niet-ondertekend als de publieke. Het verschil is dat geen buitenstaander het kan tellen, dus er staat in dit stuk geen tabel die iemand te schande zet. Ga naar je eigen kijken voordat je iets aanneemt.

Het besturingssysteem hoort dit te doen, en het hoort aan te staan

Waarmee ik bij het deel kom dat ik wil beargumenteren in plaats van tellen.

Een DNS-antwoord valideren is werk voor het besturingssysteem. Het zit in dezelfde klasse als de klok goed houden, een verzameling vertrouwde certificaten meedragen en een TLS-stack hebben, en om dezelfde redenen: elke applicatie heeft het nodig, vrijwel geen daarvan zou het moeten schrijven, en de controle moet één keer gebeuren, op een plek waar hij goed gedaan kan worden. Die discussie hebben we voor certificaten lang geleden beslecht. Niemand levert een mailclient met zijn eigen privémening over root-CA’s.

Drie van de vier platforms hierboven kunnen het al. Geen enkele doet het uit de doos:

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

Dat is de ingecompileerde standaard, als commentaar uitgeschreven zodat een beheerder hem kan zien. De eigen handleiding van systemd heeft een andere opvatting en raadt allow-downgrade in het algemeen aan, en true overal waar de upstream betrouwbaar is.¹⁵ De code wordt geleverd, het root-vertrouwensanker wordt geleverd, en de documentatie wordt geleverd met de aanbeveling het aan te zetten. De standaard zegt nog steeds nee.

Die kolom is het hele probleem. Een eis is één hefboom, en de .bank-telling laat zien wat die doet. Een standaardwaarde is dezelfde hefboom zonder handhaving, want hij beslist de uitkomst voor iedereen die het configuratiebestand nooit opent, en dat is vrijwel iedereen. Optioneel leverde ons 1,63% bij de overheid en 13% in het bankwezen. Mensen kiezen niet uit zichzelf voor beveiliging die ze niet kunnen zien, en gelijk hebben over de techniek heeft daar nog nooit iets aan veranderd.

Het eerlijke bezwaar is dat standaard valideren gebruikers breekt wanneer niet de zone stuk is maar de upstream-resolver. Daar is allow-downgrade voor, en dat is een echt compromis en geen gratis compromis, want een downgrade is iets wat een aanvaller bewust kan uitlokken. Toch zou allow-downgrade leveren in plaats van een kale no een enorme verbetering zijn, en het zou de breuk leggen waar hij hoort, bij wie in 2026 nog een resolver draait die geen DNSSEC aankan.

Validatie aanzetten, en welk stuk van Fedora is

Vrijwel alles wat volgt is van systemd en niet van Fedora, en draait hetzelfde op Debian, Ubuntu of Arch. Twee dingen hier zijn werkelijk van de distributie:

Upstream kiest allow-downgrade in meson_options.txt, wat de compromisinstelling is en niet de dappere.¹⁶ Fedora compileert hem naar no en levert vervolgens een tweede hoofdconfiguratiebestand, en omdat alleen het eerst gevonden bestand wordt gebruikt, is het bestand dat de standaardwaarden documenteert niet langer het bestand dat geldt.¹⁵ Bewerk dus geen van beide. De leverancierskopie is die van het pakket en een update geeft je je wijziging zo terug; de /etc-kopie is een bestand waarvan de andere regels stilzwijgend afwezig zijn.

Gebruik in plaats daarvan een drop-in, zoals het blok hierboven doet. Hij overschrijft welk hoofdbestand er ook won, overleeft pakketupdates, en bevat alleen wat jij veranderde. Controleer het resultaat met systemd-analyze cat-config systemd/resolved.conf, dat elk bestand afdrukt in de volgorde waarin het wordt toegepast en beslecht wat er werkelijk won.

Drie instellingen, en de keuze tussen de laatste twee is een echte:

Begin op allow-downgrade, want een kapotte resolver kost je dan niets. Ga naar yes zodra resolvectl status veertien dagen supported heeft gezegd en je weet wat je upstream werkelijk is. De details per distributie voor overal wat geen Fedora is staan in het resolved-stuk.¹²

Wat houdt mensen dan werkelijk tegen

Goed. De cijfers zijn de cijfers. Waarom?

Er worden vier redenen gegeven, en het is niet allemaal onzin.

Sleutelbeheer was een echt obstakel en is dat grotendeels niet meer. Ondertekenen betekende vroeger je eigen sleutelceremonies draaien, eraan denken opnieuw te ondertekenen voordat handtekeningen verliepen, en sleutels met de hand rollen op een schema dat je zelf moest bijhouden. Dat werk wordt op de meeste beheerde platforms nu door de DNS-provider gedaan, en ondertekenen is een schakelaar. Het is niet niks, maar het is geen project meer.

De faalmodus is het eerlijke bezwaar, en het is de enige van de vier waar ik echt sympathie voor heb. Doe DNSSEC verkeerd en je domein degradeert niet, het verdwijnt. Elke validerende resolver weigert je records, en dat is wat hij hoort te doen, en de mensen die je niet kunnen bereiken kunnen door jou niet te horen krijgen waarom, want dat vertellen vereist DNS.

Drie dingen maken het erger dan een gewone storing:

• Het faalt op een klok, niet op een wijziging. Handtekeningen hebben een vervaldatum. Een zone waar sinds dinsdag niemand aan heeft gezeten kan zondag weg zijn omdat een hertekentaak stilletjes stopte met draaien.
• Het faalt voor sommigen en niet voor anderen. Alleen validerende resolvers wijzen je af. Je eigen monitoring meldt, als die niet valideert, dat de site kerngezond is terwijl een groeiend deel van internet je niet kan bereiken.
• Het faalt in de laag die je gebruikt om dingen te repareren. Toegang op afstand, je statuspagina en je eigen e-mail kunnen allemaal onder de naam vallen die zojuist verdween.

Die angst is rationeel, hij heeft grote operators uit de lucht gehaald, en elk eerlijk pleidooi voor DNSSEC moet ermee gaan zitten in plaats van hem weg te wuiven.

Maar let op de vorm ervan: het is een angst voor een operationele discipline die je nu niet hebt, niet een angst voor de technologie.

En let op wie er in elke kolom betaalt. Een niet-ondertekende zone die wordt vervalst kost je klanten, stilletjes, en niemand meldt een incident omdat niemand het ooit merkt. Een ondertekende zone die verloopt kost jou, onmiddellijk, in het openbaar, met jouw naam op de postmortem. Het zijn allebei faalgevallen. Maar één ervan komt in iemands doelstellingen terecht.

Certificaten hadden hetzelfde probleem en losten het twee keer op: het falen werd zichtbaar gemaakt, en daarna werd het geautomatiseerd. Een browserwaarschuwing maakte een verlopen certificaat ieders probleem, monitoring volgde, en toen maakte Let’s Encrypt van verlengen iets wat een cronjob om drie uur ’s nachts deed. Niets daarvan maakte certificaten in principe makkelijker. Het maakte ze vergeten moeilijker.

Ondersteuning door providers is tien minuten controleren waard, niet aannemen. Sommige registrars maken van het publiceren van een DS nog steeds een supportticket. Heel veel niet.

En de laatste is het echte antwoord, wat de .bank-registry eerder in dit stuk al bewees. Er is geen browserslotje voor DNSSEC. Geen klant heeft ooit een bank gekozen omdat zijn zone ondertekend was, geen auditor laat je erop zakken, en geen algemene regelgeving in het Verenigd Koninkrijk eist het. Het voordeel is volledig onzichtbaar wanneer het werkt, de prijs van het verkeerd doen is een storing met jouw naam erop, en degene die die storing draagt is niet degene die de eer zou krijgen.

Zet een eis en een jaarlijkse controle voor diezelfde instellingen en de naleving gaat van 13% naar allemaal. Aan de technologie veranderde tussen die twee getallen niets. Aan de budgetten, de leveranciers of de vaardigheden ook niet. De enige variabele was of er iemand zou gaan kijken.

Gegeven die prikkels is het verrassende niet dat 1,63% van de overheidsdomeinen ondertekend is. Het is dat er negenendertig zijn.

Aanzetten zonder jezelf uit de lucht te halen

Het hele risico zit op één plek, dus steek de moeite daarin. Het verlopen van handtekeningen is de storing die aankomt zonder dat iemand ergens aan heeft gezeten, dus alarmeer erop:

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

Behandel het als een certificaat. Bewaak de datum, alarmeer ruim van tevoren, en maak de verlenging automatisch zodat het alarm een vangnet is en geen werkwijze.

Zet het daarna aan op een rustig moment, op iets anders dan je primaire domein, en laat het veertien dagen liggen voordat je het domein doet dat ertoe doet. Staat je DNS op een beheerd platform, dan is het ondertekenen zelf zeer waarschijnlijk een schakelaar, en de enige werkelijk handmatige stap is het deponeren van de DS bij je registrar.

Is dit dezelfde mislukking als IPv6?

Het is de voor de hand liggende vergelijking, dus ik heb beide standaarden in dezelfde populaties op dezelfde dag gemeten. Dezelfde organisaties, dezelfde mensen, twee besluiten.

Negentien keer verder in de overheid, op dezelfde domeinen.

Ga nu even zitten bij wat wat is. IPv6 raakt elke router, elke host en elke applicatie, en wil jarenlang dual stack parallel. DNSSEC ondertekenen is een schakelaar en één record dat je bij je registrar plakt.

De veel zwaardere klus verslaat de makkelijke overal waar ik keek. Wat de comfortabele verklaring uitsluit dat infrastructuurstandaarden nu eenmaal zo gaan, langzaam en met tegenzin. DNSSEC beweegt niet langzaam. Het beweegt niet.

Eén verschil hoort alleen bij DNSSEC. Rol IPv6 uit en je krijgt er iets voor terug: bereikbaarheid, geen carrier-grade NAT te kopen. Onderteken je zone en jij persoonlijk krijgt niets. De bescherming landt bij je gebruikers, en alleen bij degenen achter een validerende resolver. Je neemt een permanent storingsrisico op je namens mensen die je nooit zult ontmoeten, en dat is moeilijker aan een bestuur voor te leggen dan welk technisch obstakel in dit stuk ook.

Ik heb de IPv6-helft van dit betoog elders geschreven en herhaal hem hier niet.¹⁷

Komt het doordat we DNS nog steeds niet begrijpen?

Tweeënveertig jaar sinds Mockapetris het in november 1983 opschreef.¹⁸ Zestien sinds de root werd ondertekend.

Ik denk dat het begripsprobleem echt is, en ik denk dat het specifieker is dan dat mensen niet weten hoe DNS werkt. Genoeg bekwame engineers kunnen recursie, delegatie en caching prima beschrijven. Wat ontbreekt is één stap verder, en dat is de stap die ertoe doet.

Vrijwel niemand heeft zich eigen gemaakt dat DNS een autorisatiesysteem is.

Het wordt als leidingwerk behandeld. Een opzoektabel. Iets wat namen in nummers omzet en toebehoort aan wie het netwerk beheert, mentaal opgeborgen naast DHCP. En dat kader is verkeerd op een manier die stilletjes veel beslist, want in de praktijk is het DNS-antwoord wat bepaalt naar welke machine je verkeer gaat, van welke server je updates komen, en welke host een certificaatautoriteit voor de jouwe houdt. Wie het antwoord beheerst, beheerst alle drie.

Je ziet het misverstand in het patroon van wie er ondertekend heeft. Niet budget, en ook niet vaardigheid, en zodra je het op een rij zet is het moeilijk als iets anders te lezen dan een patroon van wat elk van hen denkt dat DNS is:

De mensen die het dichtst bij DNS als ding op zich staan hebben allemaal ondertekend. De mensen die het als nutsvoorziening afnemen niet, vrijwel zonder uitzondering, hoe goed voorzien en hoe veiligheidsbewust ze zichzelf ook achten. GCHQ heeft niet ondertekend. Acht van de negen certificaatautoriteiten hebben niet ondertekend. Dat zijn geen organisaties met een tekort aan slimme mensen of aan dreigingsmodellen.

Dat is ook waarom het antwoord op Kaminsky in 2008 was om de gok moeilijker te maken in plaats van het ding af te maken dat raden irrelevant maakt. De gok moeilijker maken is een loodgietersoplossing, en loodgieterij is hoe de industrie DNS had opgeborgen.

Een generatie leerde DNS als een telefoonboek, en werkte het lemma nooit bij toen het stilletjes het ding werd dat bepaalt met wie je praat.

We hebben het gebouwd en het toen laten liggen

De registries, de operators en de standaardenmensen deden het moeilijke deel. Ze schreven het, bevochten het tien jaar lang door de IETF, ondertekenden de root in een ceremonie met getuigen, en kregen 100% van de generieke topleveldomeinen ondertekend. Dat is een echt stuk collectief ingenieurswerk en het is af.

En daarna deden wij, de rest, ons deel niet, want ons deel is saai, onzichtbaar, draagt alle persoonlijke keerzijde en geen van de eer, en niemand controleert het.

Dat is de vorm van elke standaard die niemand handhaaft: de kosten worden alleen gedragen, en het voordeel komt pas opdagen wanneer genoeg anderen ze ook hebben gedragen. Dus de registries droegen ze, en de mensen die de richtlijnen over het dragen ervan publiceren deden dat niet.

Alleen was de klus hier kleiner dan vrijwel al die andere. De keten was al gebouwd, en betaald, door iemand anders. Het enige wat overbleef was één record.

En als dit het stuk is dat we kunnen zien

Nog één gedachte, en ik wil duidelijk zijn dat het een gevolgtrekking is en geen meting, want al het andere in dit stuk is geteld en dit niet.

DNSSEC is ongeveer de makkelijkste beveiligingsmaatregel die er is om te beoordelen. Het kost niets, het werk is een middag, de standaard is al twintig jaar af, en iedereen kan het van buitenaf met één commando controleren zonder toestemming te vragen. Geen audit, geen vragenlijst, geen geheimhoudingsverklaring. Eén dig.

Wat zegt 1,6% je dan over de maatregelen die je van hieruit niet kunt zien?

Elke rij onder de eerste is moeilijker dan ondertekenen, kost echt geld, heeft een eigenaar nodig, en deelt de eigenschap die DNSSEC de kop kostte: onzichtbaar wanneer het werkt, en niemand van buiten die controleert. Het enige dat de bovenste rij van de rest scheidt is dat jij hem kunt controleren, gratis, bij wie dan ook, nu meteen.

Heeft een organisatie het gratis ding van een middag niet gedaan, dat door een vreemde met één commando te verifiëren is, dan ben ik niet geneigd aan te nemen dat ze de dure dingen wel heeft gedaan, die een programma kosten en alleen geverifieerd kunnen worden door iemand die ze binnenlaten.

De voor de hand liggende zet is dat tegen de inbraakgeschiedenis toetsen, en dat heb ik geprobeerd. Van 23 Britse organisaties met gedocumenteerde grote incidenten zijn er 22 niet ondertekend.

Dat getal bewijst niets en ik ga niet doen alsof van wel. Bij een basispercentage van 1,6% is één ondertekende organisatie in een lijst van 23 precies wat het toeval voorspelt. Erger nog, de ondertekende verzameling bestaat uit negen dorpsraden en drie nationale parken terwijl de niet-ondertekende verzameling elk groot ministerie en elke grote stad bevat, dus omvang bepaalt zowel wie er wordt aangevallen als wie er in het nieuws belandt. Elke vergelijking van inbraakcijfers tussen de twee groepen zou meten hoe groot een organisatie is, niet of ze heeft ondertekend.

Dus nee, ik kan je niet laten zien dat ondertekende organisaties minder worden gehackt. Niemand kan dat met gegevens die iemand kan krijgen, en wie iets anders zegt houdt je voor de gek.

De organisaties die geraakt werden schreven op wat er faalde

Je hebt mijn gevolgtrekking niet nodig, want ze hebben het zelf gepubliceerd, en wat er faalde is de lijst hierboven.

De British Library is de beste van allemaal, want zij schreven het vrijwillig en gedetailleerd op na hun ransomware-aanval van 2023. Hun eigen evaluatie noemt de oorzaken: binnenkomst hoogstwaarschijnlijk via een account van een derde partij op een Terminal Services-server zonder multifactorauthenticatie, waarna verouderde infrastructuur en beperkte netwerksegmentatie de aanvallers door de omgeving lieten bewegen, terwijl de groeiende complexiteit van toegang door derden intern in 2022 als risico was gemeld en er een jaar later nog steeds zat.¹⁹ De ICO kwam tot dezelfde conclusies.²⁰

Drie rijen van de tabel hierboven dus, van binnenuit bevestigd door de organisatie zelf in plaats van door mij van buitenaf afgeleid.

En voordat iemand dat als stok gebruikt: de British Library verdient het tegenovergestelde, en ik zal nadrukkelijk zijn over waarom.

Ze waren open. Vrijwel niemand anders is dat. Er was geen enkele verplichting om er een woord over op te schrijven. Het standaarddraaiboek na een incident is zo weinig zeggen als de wet toestaat, het door een communicatieteam halen, weigeren iets specifieks te bevestigen, en wachten tot de nieuwscyclus verder trekt. Dat is wat de meeste organisaties in de niet-ondertekende kolommen hierboven deden toen zij aan de beurt waren, en het is de reden dat het schrijven van deze paragraaf überhaupt afhangt van het besluit van één instelling om zich anders te gedragen.

In plaats daarvan publiceerden ze een evaluatie van achttien pagina’s die hun eigen tekortkomingen benoemde, zodat andere instellingen ervan konden leren. Dat is het gedrag dat je van elke organisatie in dit stuk zou willen en van vrijwel geen enkele krijgt. De reden dat ik je kan laten zien wat er werkelijk faalt binnen een gehackte organisatie is dat de British Library besloot het je te vertellen.

En er is een tweede reden waarom de rest stil blijft, die erger is dan een communicatiestrategie. Sommigen zijn er niet meer.

KNP Logistics vervoerde sinds 1865 vracht als Knights of Old. In juni 2023 kwam de Akira-groep binnen, versleutelde het bedrijf en vroeg ongeveer vijf miljoen pond. In september was de groep insolvent en zaten 730 mensen zonder werk.²¹ Honderdachtenvijftig jaar, in veertien weken weg, en daar schrijft niemand lessen voor je op.

Dus wanneer de niet-ondertekende kolommen hierboven stil lijken, bestaat die stilte uit drie verschillende dingen: organisaties die nog niet geraakt zijn, organisaties die geraakt zijn en zo weinig zeiden als de wet toestaat, en organisaties die geraakt zijn en er niet meer zijn. Alleen de eerste groep heeft nog tijd om te handelen.

Wat het volgende de eerlijke toets van mijn eigen betoog maakt in plaats van een goedkope sneer. Ik heb hun zone gecontroleerd:

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

bl.uk is niet ondertekend. britishlibrary.co.uk evenmin. Twee jaar na een ransomware-aanval die de instelling maandenlang stillegde, na een openbare evaluatie, na een bevinding van de ICO, en na de grondigste ronde beveiligingsaandacht die een organisatie ooit krijgt, is de gratis maatregel die een middag kost en die een vreemde met één commando kan verifiëren nog steeds niet gedaan.

Ik lees dat niet als nalatigheid, en ik denk niet dat het ze erger maakt dan de niet-ondertekende organisaties die niets hebben gepubliceerd. Ik lees het als het sterkste bewijs in dit stuk voor waar het hele ding over ging. Als DNSSEC hier niet gedaan wordt, bij een organisatie die door het vuur is gegaan, de lessen heeft opgeschreven en de toezichthouder erover heen heeft gehad, dan wordt het niet overgeslagen omdat mensen onzorgvuldig zijn. Het wordt overgeslagen omdat niets en niemand het ooit op de lijst zet.

Dat is de eerlijke versie van het betoog. Niet niet-ondertekende zones veroorzaken inbraken, wat onbewijsbaar en waarschijnlijk onwaar is. Eerder: de maatregelen die niemand van buiten kan zien zijn, op het gepubliceerde bewijs van de organisaties die het hebben meegemaakt, precies even verwaarloosd als de ene maatregel die iedereen van buiten kan zien. DNSSEC is niet de oorzaak. Het is de steekproef die je mag nemen.

Daarom is de meting überhaupt de moeite waard. Niet omdat een niet-ondertekende zone op zichzelf het einde van de wereld is, maar omdat het een van de zeer weinige beveiligingseigenschappen is die een buitenstaander eerlijk kan controleren, gratis, bij wie dan ook, zonder binnengelaten te worden. Behandel het als een rookmelder en niet als een oordeel, en ga daarna de moeilijkere vragen stellen aan wie hem laat afgaan.

Het enige deel dat jij in de hand hebt

Waarmee alleen het deel overblijft dat je zelf in de hand hebt. Je eigen zone. Niet die van het NCSC, niet die van Microsoft, niet die van je bank.

Ga je ouder vragen of hij garant voor je staat:

dig +short yourdomain.uk DS

Komt dat leeg terug, dan ben je niet ondertekend, en op de meeste beheerde DNS is de oplossing in 2026 een schakelaar en een DS-record bij je registrar. Zet het aan, en bewaak daarna de vervaldatum zoals je je certificaten al bewaakt, want dat is de discipline die het hele ding werkelijk nodig heeft.

Dat is de hele klus. Eén record, en een datum in je monitoring.

Dus doe alsjeblieft in elk geval deze ene. Niet omdat er een toezichthouder aankomt, want voor de meesten van jullie komt die niet, en niet omdat iemand je zal bedanken, want dat doen ze niet. Doe het omdat er niemand komt, en een standaard die je nakomt terwijl niemand controleert is de enige soort die ooit iets waard was.

Negenendertig dorpssecretarissen en een geheime dienst kregen het voor elkaar. Schouders eronder en regel het.