Basisbeveiliging meet de juiste toepassing van DNSSEC sinds 2018. Hiervoor werd het script dnscheck gebruikt, dat later zou veranderen in Zonemaster. Eisen voor versleuteling zijn in de loop der jaren strenger geworden; daarom was het tijd om het script bij te werken.
De bijgewerkte meting levert strengere resultaten op met de bijbehorende terugval. Onze meting is op twee punten anders dan het standaardbeleid; dat wordt in dit artikel uitgelegd. De update is op 7 april aangezet en geldt voor alle gemeten domeinen.
Zonemaster kan tegenwoordig meer, en die extra controles worden meegenomen in een nieuwe meting over de robuustheid van DNS. De nieuwe meting gaat aan op 4 mei en wordt hoogstens als oranje beoordeeld. Wie alvast de eigen domeinen wil controleren, kan dat op zonemaster.se. Ook voor deze meting wordt een aangepast beleid gebruikt. Meer daarover staat in het laatste hoofdstuk van dit artikel.
Vind je transparantie, veiligheid, soevereiniteit, toegankelijkheid en privacy belangrijk? Word dan deelnemer van de Internet Cleanup Foundation en ondersteun onze missie om het internet transparant te maken. We meten al meer dan 10.000 organisaties en 300.000 adressen en maken deze informatie beschikbaar voor iedereen. Meer over deelnemerschap.
“Wij” hebben nog 38% te winnen… of toch 68%
DNSSEC is een complexe technologie. Het uiteindelijke doel is te garanderen dat een domeinnaam en IP-adres bij elkaar horen, bijvoorbeeld “basisbeveiliging.nl” en 185.71.61.127. De meeste sitebeheerders hoeven niet te weten hoe deze technologie precies werkt. Voor hen is het niet meer dan “niets doen” of een vinkje aanzetten in een beheeromgeving. Voor de rest is het een uitdaging.
In Nederland wordt DNSSEC op 62% van alle .nl-domeinen toegepast. Dat gebeurt veelal door grotere registratiepartijen zoals TransIP en Metaregistrar. Zij hebben de schaal om kortingsregelingen van SIDN, zoals de Registrar Scorecard, om te zetten in zakelijke voordelen: hogere winst, kwalitatief betere dienstverlening en beter onderscheidend vermogen ten opzichte van kleinere partijen. Rekenvoorbeeld: het ging ooit om een korting van 28 cent per domein, maal 300.000 domeinen van een grote partij = € 84.000 per jaar. De overige duizend kleinere partijen moeten hetzelfde werk doen, maar met minder geld want ze hebben minder domeinen. De exacte beoordelingen, verdeelsleutel en bedragen van de recentere Registrar Scorecard hebben we niet kunnen vinden. In 2024 werd er € 900.000 aan kortingen vergeven, ten opzichte van € 1,5 miljoen in 2019.
Deze financieel gedreven insteek zorgt ervoor dat Nederland wereldwijd op de 9e plaats staat als het gaat om toepassing van DNSSEC. Ter vergelijking: koplopers Estland en Finland halen een dekking van 94%; dat is 22% meer dan “ons”. Maar bij al die percentages mist het allerbelangrijkste: zijn daadwerkelijk gebruikte en belangrijke domeinen voorzien van deze beschermlaag? Als we inzoomen op het gebruik van DNSSEC in Nederland, dan zien we dat het ontbreekt op erg veel belangrijke domeinen.
Basisbeveiliging biedt sinds januari 2024 een klassement waarmee sectoren per meting kunnen worden vergeleken. Als we kijken naar onze oude en minder strenge DNSSEC-meting, zien we behoorlijke verschillen in adoptie per sector. De Nederlandse overheid haalt tussen de 83% en 96%. Universiteiten behalen 57% en politieke partijen slechts 32%. Er is dus geen sector die perfect scoort. De laagste adoptie bij politieke partijen komt op de wereldranglijst uit op de 156e plek: daar staan “wij als Nederland” dus in sommige sectoren.
De cijfers van de nieuwe meting zijn nog niet binnen en zullen een negatiever beeld schetsen.
Ontwikkeling van de nieuwe meting
In de bijgewerkte versie van Zonemaster worden erg veel (nieuwe) controles uitgevoerd, bijvoorbeeld op sleutellengte en juiste algoritmen. Het zijn er ongeveer 120. De belangrijkste winst ten opzichte van de voorgaande versie zit in de documentatie: deze is uitgebreid en wijst naar de gebruikte standaarden waarop de metingen zijn gebaseerd.
Wij houden van projecten als Zonemaster: het is overduidelijk het levenswerk van DNS-liefhebbers, geschreven in de programmeertaal Perl. De software is open source en de ontwikkeling wordt betaald door The Swedish Internet Foundation, die het .se- en het .nu-domein beheert. In de programmatuur is aan alles gedacht en wij hebben nog niet alle functionaliteiten, zoals vertalingen, kunnen meenemen.
Hoewel de nieuwe meting strenger en vollediger is, zullen we in eerste instantie nog afwijken van één eis die voortvloeit uit de nieuwe TLS-richtlijnen van het NCSC. Dat punt is de minimale RSA-sleutellengte. Wij zullen alles wat onder de 2048 bit zit op onvoldoende zetten: dat is strenger dan voorheen, maar niet volgens de richtlijn. Eigenlijk moeten we sleutellengtes pas op voldoende zetten als ze langer zijn dan 3072 bits. Dat lukt nog even niet en we weten ook niet zeker of dit voor DNSSEC net zo noodzakelijk is als voor TLS. Wij hebben hiervoor een wijzigingsverzoek aangemaakt in Zonemaster en dit wordt geëvalueerd voor de volgende versie van tool. Wij zijn nog aan het kijken of wij misschien al eerder deze meting kunnen bijwerken; dat zal dan gebeuren voor de aanloopperiode van de certificatenregen van 2026.
Er is verder nog één andere belangrijke afwijking: wij zien dat de bescherming tegen “zonewalking” meer kwaad dan goed doet. Dit betekent dat alle afwijkingen rondom de techniek NSEC3 vooralsnog worden ingeschaald op laag risico. Wij overwegen om alleen NSEC1/3 met ondersteuning voor zone walking goed te keuren. Dat is controversieel, maar wij denken dat het verdedigbaar is. Onze motivatie daarvoor staat in het volgende hoofdstuk. Wij horen graag onderbouwde kritiek of steunbetuigingen op dit voornemen.
Ons aangepaste beleidsbestand voor Zonemaster staat hier; het origineel staat hier. Wij vertalen de waardes van Zonemaster als volgt: Error vertaalt zich naar hoog risico, warning naar midden, notice naar laag en info en debug naar oké (deze worden niet getoond om ruis te voorkomen). Critical wordt gebruikt voor testfouten en wordt niet negatief beoordeeld in het rapport.
Liegen met NSEC doet meer kwaad dan goed
Onze ervaring is dat transparantie zorgt voor betere veiligheid: het zorgt voor grip op systemen. Het vereist altijd zorgvuldige overweging om iets online te zetten, omdat beschikbaarheid, integriteit en vertrouwelijkheid belangrijk zijn. Hier staan wat voorbeelden.
Er bestaat een sterke beveiligingsstroming die waarde hecht aan onduidelijkheid. Want wie onduidelijk is, hoeft minder veilig te zijn… zo lijkt de gedachte. Argumenten die onduidelijkheid stimuleren, zijn defense-in-depth en speculatie over niet benoemde “risico’s van zone enumeration”. Er is echter wel één goed argument voor onduidelijkheid: het levert wat geld op.
In DNSSEC zit een speciaal stuk techniek dat ervoor zorgt dat subdomeinen lastiger te vinden zijn. Dit zijn “White/Black lies” en het is redelijk goed in het vaag houden welke (sub)domeinen bestaan… ware het niet dat het stelselmatig wordt ondermijnd op allerlei manieren. Dit leidt tot problemen op basis van foutieve aannames over de bescherming die het biedt.
Domeinen en leugens
Domeinen en subdomeinen worden gebruikt om informatie logisch te ordenen met namen. De gemiddelde lengte van alle subdomeinen in Basisbeveiliging is ongeveer 12 tekens.
Een domein heeft vaak meerdere subdomeinen, zoals “nieuw” en “www”. In oudere versies van DNSSEC werd dit openbaar, omdat er tussen de subdomeinen “nieuw” en “www” een bepaalde ruimte zit, bijvoorbeeld niets met een m, o, p, q, r, enzovoort. NSEC was zo ontworpen dat iedereen kon opvragen hoeveel ruimte er was en daarmee kon achterhalen welke (sub)domeinen er bestonden. NSEC3 maakte dit iets moeilijker: er kwam een versleuteld antwoord terug dat gekraakt moest worden.
De leugentechnologie van NSEC werkt op de volgende manier. Wie vraagt: “Wat is de volgende in de lijst?” krijgt geen antwoord of een onjuist antwoord, zoals “xww”, dan “yww” en dan “zww”.
Defense in depth
Defense in depth is het principe dat een aanvaller door meerdere beveiligingslagen moet. Vanuit dat idee is het verborgen houden van subdomeinen een beschermlaag: de aanvaller moet erachter zien te komen welke subdomeinen bestaan. Subdomeinen die je weet, daar mag je naartoe. Subdomeinen die je niet weet… ook. En in principe mag je eindeloos gokken of ze bestaan.
Er wordt dus niet beschermd tegen het vinden of uitlekken van subdomeinen, terwijl dat op allerlei manieren gebeurt.
Er is een levendige handel in lijsten met domeinen en subdomeinen. Met tools als DNSRecon en hashcat worden lijsten gemaakt en verhandeld door (cybersecurity)bedrijven, maar sommige DNS-beheerders verkopen hun data voor extra omzet. Hier gaan vele miljoenen in om. Wie meer internetverkeer ziet, kan het beste aanvallen en verdedigen. Wie de diepste zakken heeft, wint. Wanneer het gaat om “nation state threats” zijn de zakken oneindig diep en is niets ongezien, omdat op landelijk niveau al het DNS-verkeer kan worden ingezien.
Zone enumeration
Leugens worden gebruikt om zone-enumeratie te voorkomen. Dat is het opsommen van alle domeinen in een zone, zoals .se, of het opsommen van alle subdomeinen van een domein. Het grootste risico van deze “aanval” is dat er mogelijk gevoelige informatie naar buiten komt die al verborgen had moeten zijn. Met andere woorden: waar zone-enumeratie wordt beperkt, stinkt het… of het mag stinken.
Leveranciers zoals Cloudflare gebruiken als voorbeeld dat het onwenselijk is dat iemand alle diensten op het Amerikaanse .mil-adres kan vinden. Het exacte probleem hiervan wordt niet benoemd, maar geïmpliceerd: het raden van een (sub)domein kan leiden tot de ondermijning van de veiligheid van een land of militaire operatie. Zulke nalatigheid is onrealistisch.
Zakelijk gezien is er een ander argument: sommige bedrijven maken per klant een mooi subdomein aan. Uit concurrentieoverwegingen mogen anderen niet zien welke dat zijn. Maar wie de KVK tegen de subdomeinen aanhoudt, krijgt dan toch het antwoord: als dit wat waard is, zal iemand dat proberen. In dat geval is een map per klant ook mogelijk.
Door het afschermen van subdomeinen zien we voornamelijk dat organisaties hun eigen beheer lastiger maken. De afscherming voorkomt een eenduidig antwoord op de vraag “Wat heb ik online staan?”, waardoor een volgende afdeling producten en diensten koopt om erachter te komen wat er online staat. En dan kopen ze de duurdere variant, omdat die meer zekerheid biedt. Maar de extra zekerheid is niet de garantie die je eerder wel had. Dat is allemaal erg omslachtig en onhandig, maar vooral zonde van de tijd en het geld.
De hyperspecifieke use-case is niet realistisch
Geheimhouden van een online dienst op het openbare internet is heel erg lastig. Wie zoiets wil, komt al snel uit op besloten netwerken zoals gemnet en een gewoon VPN.
Wie toch iets via het openbare internet wil doen én DNS wil gebruiken, heeft het extra zwaar. Er moet de garantie zijn dat niemand het domein opvraagt via een DNS-server die deze data kan uitlekken. Ook niet op vakantie in een ander land bijvoorbeeld, en dat is nagenoeg onmogelijk. Er moet dan de afweging gemaakt worden: “Wie vertrouw ik?” in plaats van: kan dit op een veiligere manier?
Andere spelregels voor verborgen diensten over het openbare internet blijven hetzelfde:
- Er mag nooit een openbaar versleutelingscertificaat op worden aangevraagd, want dan verschijnt het subdomein in de certificate transparency logs, die openbaar zijn.
- Alle stukken waar staat opgeschreven welk subdomein wordt gebruikt, moeten geheim worden gehouden.
- Medewerkers mogen het ook niet noemen in chatberichten op platforms die niet volledig in eigen beheer zijn (afhankelijk van wie je vertrouwt).
Stel dat het toch moet, dan kan in ieder geval DNS worden vermeden als plaats waar iets uitlekt. Bijvoorbeeld het gebruik van een obscuur IPv6-adres tussen diensten waarvan het netwerkpad voorspelbaar is (voor zover dat mogelijk is). Als een domein of dienst écht geheim moet zijn, dan is het openbare internet niet de juiste plaats.
Het fundament van het internet is open
Technisch gezien is het correct: opzettelijk onjuiste antwoorden verbergen welke domeinen bestaan. Maar deze beschermingslaag is niet meer dan een dun plakje gatenkaas dat een verkeerd gevoel van veiligheid geeft. De handel in namen, het onbeperkte gokken, openbare logbestanden en andere factoren ondermijnen deze beschermingslaag structureel. Het gebruik deze afscherming maakt voornamelijk het beheer en beveiligen van domeinen lastiger (en duurder) voor organisaties. Het is zowel makkelijker en goedkoper om transparant te werken, wat leidt tot meer veiligheid.
Het internet als technologie is fundamenteel open, inclusief het namensysteem. Dat is de verkeerde plaats om iets te verbergen. De openheid van het internet is wat heeft geleid tot het succes ervan. Dit anders willen zien is een mismatch en leidt tot het afsluiten en ondermijnen van het internet. Wij pleiten voor transparantie, omdat dit leidt tot de laagste kosten en de hoogste veiligheid.
Om deze reden beoordeelt Basisbeveiliging fouten in NSEC en NSEC3 hoogstens als laag risico, ofwel groen.
Vooraankondiging meting robuustheid DNS
DNS is de veroorzaker van allerlei problemen op het internet. Ook grote spelers zoals Amazon, Facebook en Cloudflare zijn down geweest door fouten in hun DNS-instellingen. In de aankomende meting probeert Basisbeveiliging advies te geven over hoe DNS robuuster kan worden ingericht.
Deze nieuwe meting is gebaseerd op de 56 overige metingen in Zonemaster. We krijgen deze “gratis” en, gezien het zorgt voor een stabieler internet, leek het ons juist om ook hiervan de meetresultaten te beoordelen en mee te nemen in Basisbeveiliging.
De nieuwe meting maakt overduidelijke foutsituaties en tekortkomingen inzichtelijk. Maar ook deze meting gebruiken we niet zoals die wordt geleverd. Zo worden de tests Connectivity 3 en 4 overgeslagen, omdat dit geen rekening houdt met anycast; alleen oordelen op heuristiek is niet voldoende. Ook laten we de SPF-policyvalidatie van Zone 11 over aan internet.nl, zodat het aansluit op het Nederlandse beleid.
Wie alvast deze nieuwe meting wil proberen, kan een kijkje nemen op zonemaster.se.
