DNSSEC

DNSSEC is een cryptografische beveiliging voor het DNS-protocol. Het Domain Name System (DNS) verzorgt de vertaling van domeinnamen naar IP-adressen (en andersom). Zo moet je computer (de client) een nameserver raadplegen voor het adres example.nl alvorens contact te kunnen zoeken met de bijbehorende webserver op een IP-adres van de vorm 192.0.2.36 of 2001:db8::2:14 (IPv6). Maar ook e-mail en andere internet-protocollen maken gebruik van ditzelfde systeem. DNSSEC voorziet de DNS-informatie (de records) van een digitale handtekening, zodat de client kan controleren of de inhoud authentiek is.

DNS is een van de oudste internetprotocollen die we nog steeds gebruiken. Het is ontwikkeld in de eerste helft van de jaren '80, inmiddels bijna 40 jaar geleden (de oudste RFC's (882/883) dateren uit 1983, de oudste die nog actueel zijn (1034/1035) uit 1987).

Omdat internet in die tijd vooral een academische aangelegenheid was, werkten deelnemers veelal met elkaar samen op basis van vertrouwen. Beveiliging was dan ook geen groot aandachtspunt bij het ontwerp van die protocollen, laat staan een integraal onderdeel daarvan zoals dat nu het geval is.

Ondanks zijn leeftijd is DNS nog steeds een van de belangrijkste protocollen van het internet: als DNS niet meer werkt, werkt internet effectief niet meer.

En weet je DNS te kraken, dan ben je (criminele) spekkoper.

Juist omdat DNS zo oud is en onderdeel van de haarvaten van het internet, is de beveiling ervan pas relatief laat ontwikkeld. De basis van DNSSEC zoals we dat nu gebruiken is gedefinieerd in RFC 4033, 4034 en 4035, alle 3 daterend uit 2005. Ter vergelijking: SSL (de voorloper van TLS voor de beveiliging van het webverkeer) dateert uit 1995.

Hoewel we in Nederland een van de voortrekkers van DNSSEC zijn, is de wereldwijde adoptie (en dan vooral aan de zijde van domeinnaamhouders) nog steeds minimaal.

DNSSEC beschermt ook alleen de authenticiteit (integriteit) van de DNS-informatie, niet de vertrouwelijkheid ervan. Uitbreidingen van DNS die het transport van DNS-informatie beschermen zijn pas de afgelopen jaren ontwikkeld:

• DNS-over-TLS (DoT): RFC 7858 en 8310 uit 2016/2018

• DNS-over-HTTPS (DoH): RFC 8484 uit 2018

• DNS-over-QUIC (DoQ): RFC 9250 uit 2022

Het primaire doel van DNSSEC is om de authenticiteit van DNS-informatie te waarborgen, waarmee DNS spoofing onmogelijk wordt.

Dat is belangrijk voor domeinnaamhouders, omdat het belang van een goed beveiligde digitale ingang sterk is toegenomen:

• voor bedrijven, waarvoor veel van de interactie met klanten, partners en leveranciers naar internet is verschoven

• voor overheden en andere organisaties, die onderling en met burgers en bedrijven steeds meer via internet communiceren

• voor internetgebruikers die ook online op de betrouwbaarheid van een merk of organisatie moeten kunnen rekenen

Een onveilige internetdienst, laat staan een kraak, levert immers zowel reputatie- als zakelijke/financiële schade op.

En dat is ook belangrijk voor internetgebruikers, omdat internet steeds meer wordt gebruikt als een platform voor de opslag van waardevolle informatie en het uitvoeren van financiële transacties. Denk aan internetbankieren, online beleggen en betalingen bij webshops. DNSSEC is voor de gebruiker een garantie dat zijn internetverkeer op de juiste plaats terecht komt.

Daarnaast maakt de cryptografische beveiliging van de informatie in het DNS-systeem deze infrastructuur nu ook geschikt voor de distributie van andersoortige informatie waarvan de authenticiteit gegarandeerd moet zijn. Daarmee biedt DNSSEC mogelijkheden voor hele nieuwe internettoepassingen. Voorbeelden daarvan zijn:

• SPF, DKIM en DMARC

• DANE

• SSHFP

Voor bedrijven is veel van de interactie met klanten, partners en leveranciers al naar internet verschoven. Ook overheden en andere organisaties communiceren onderling en met burgers en bedrijven steeds meer via internet. Daarmee is ook het belang van een goed beveiligde digitale ingang sterk toegenomen. Bezoekers moeten ook online op de betrouwbaarheid van een merk of organisatie kunnen rekenen. Een onveilige internetdienst, laat staan een kraak, levert zowel reputatie- als zakelijke/financiële schade op.

Weet een kwaadwillende DNS-informatie op de DNS-server, onderweg of bij de client te veranderen, dan kan hij die client naar een valse server sturen (DNS spoofing). Op die manier kunnen paswoorden en andere vertrouwelijke gegevens worden buitgemaakt, of geld en omzet worden gestolen.

DNSSEC beschermt de autoritatieve nameserver en het transport van de DNS-informatie. Dat is voor aanbieders van internetdiensten een garantie dat verkeer van bezoekers inderdaad op de juiste plaats terecht komt.

Internet wordt steeds meer gebruikt als een platform voor de opslag van waardevolle informatie en het uitvoeren van financiële transacties. Denk maar aan internetbankieren, online beleggen en betalingen bij webshops. Inmiddels weet iedereen wel dat hij dergelijke transacties alleen mag uitvoeren bij een beveiligde webserver (te herkennen aan het bekende slotje in de webbrowser).

Weet een kwaadwillende DNS-informatie op de DNS-server, onderweg of bij de client te veranderen, dan kan hij de internetgebruiker naar een identieke maar valse webserver sturen (DNS spoofing). De gebruiker kan dat op geen enkele manier zien: de website is een exacte kopie en zelfs het slotje is gewoon aanwezig. Op die manier kunnen dus logingegevens, of persoonlijke of zakelijke informatie worden buitgemaakt.

DNSSEC beschermt de autoritatieve nameserver en het transport van de DNS-informatie. Dat is voor de gebruiker een garantie dat zijn internetverkeer op de juiste plaats terecht komt.

Jazeker:

• DNSSEC in zijn huidige, moderne vorm bestaat al meer dan 15 jaar: de basis van DNSSEC zoals we dat nu gebruiken is gedefinieerd in RFC 4033, 4034 en 4035, alle 3 daterend uit 2005. DNSSEC wordt door de .nl-zone ondersteund sinds 2012.

• De ondersteuning van DNSSEC (ondertekening) is door ICANN verplicht gesteld vanaf 1 januari 2014, wat betekent dat in ieder geval alle nieuwe gTLD's deze beveiligingstechnologie ondersteunen. Op dit moment wordt DNSSEC door ruim 90 procent van alle ccTLD's ondersteund (situatie december 2022). De toepassing van DNSSEC binnen de TLD's wisselt wel enorm. Nederland is wereldwijd een van de koplopers als het gaat om de ondertekening van domeinnamen: inmiddels is bijna 60 procent van alle .nl-domeinen met DNSSEC beveiligd (situatie december 2022).

• Wereldwijd zit het aandeel internetgebruikers dat gebruik maakt van een validerende resolver op dit moment rond de 30 procent (situatie december 2022). Voor Europa ligt het gebruik van DNSSEC-validatie nu op ruim 40 procent. En met een adoptiegraad van ongeveer 60 procent zit Nederland ook voor wat betreft DNSSEC-validatie (eindelijk) op het niveau van de landen om ons heen.

• DNSSEC wordt ondersteund door alle actief onderhouden DNS-servers en -resolvers. Uitzonderingen zijn dnsmasq (alleen forwarding) en djbdns (verouderd). Interoperabiliteit tussen de verschillende servers en resolvers is geen enkel probleem. Testen voor interoperabiliteit van veelgebruikte software voor bedrijfsmatige inzet is niet nodig.

• DNSSEC wordt ondersteund door alle gangbare netwerkmanagement-software en -tools. Dat geldt ook voor provider-platforms als Plesk, cPanel en DirectAdmin.

• DNSSEC wordt ondersteund door alle gangbare operating systems, zowel open source als proprietary.

• DNSSEC wordt ondersteund door de meeste registrars en resellers. Dat betekent dat klanten sleutelmateriaal (DS-records) aan de bovenliggende zone kunnen laten toevoegen voor zones die zij zelf beheren (typisch in de beheeromgeving bij hun NS-verwijzingen), en dat zij zones die door de registrar worden beheerd kunnen laten ondertekenen.

• Kennis, ervaring en ondersteuning voor DNSSEC zijn breed beschikbaar bij leveranciers en dienstverleners.

Kortom: DNSSEC is een bewezen, robuuste technologie. Dit alles maakt investeringen in en de implementatie van DNSSEC risicoloos wat de technologie betreft.

De Nederlandse overheid heeft een belangrijke voortrekkersrol bij de acceptatie van DNSSEC. In 2012 — een maand na de landelijke uitrol — werd DNSSEC (tegelijkertijd met DKIM) door het Forum Standaardisatie toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst. Sindsdien zijn overheidsorganisaties dus min-of-meer verplicht om hun domeinen en systemen met DNSSEC te beveiligen. Berichtgeving over de slechte beveiliging van gemeentelijke sites was in juni 2016 aanleiding voor de toenmalige Minister van Binnenlandse Zaken om de gemeenten aan te sporen om eind 2017 hun domeinnamen met DNSSEC (en TLS, DKIM en SPF) te hebben beveiligd.

Daarnaast is het Forum Standaardisatie initiatiefnemer van de Internet.nl portal. Daar kun je je verbindingen en domeinen testen op de toepassing van een zestal moderne internet-standaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een score, waarmee je ook een kwantitatieve indicatie krijgt van je 'compliance'. Inmiddels zijn er op die manier al honderdduizenden tests uitgevoerd.

Waar overheidsorganisaties in 2014 nog sterk achterliepen met hun DNSSEC-implementaties hadden zij die achterstand bij de inventarisatie van 2017 meer dan goedgemaakt.

DNSSEC (en DKIM) zijn in 2012 door Forum Standaardisatie, onderdeel van de ministeries van Economische Zaken en Binnenlandse Zaken, toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst (ptolu). Dat betekent dat alle (semi-)overheidsorganisaties sindsdien min-of-meer verplicht zijn om hun domeinen en systemen met DNSSEC te beveiligen. Concreet moeten alle relevante standaarden die op de ptolu-lijst staan worden opgenomen in aanbestedingen boven de 50.000 euro, tenzij er goede argumenten zijn om dat niet te doen. Daarmee is de invoering van DNSSEC in de publieke sector veelal onderdeel van vernieuwingen in de IT-infrastructuur.

De afgelopen jaren zijn ook SPF en STARTTLS in combinatie met DANE aan de ptolu-lijst toegevoegd. En voor DMARC gebeurde dat in 2018. Deze standaarden verzorgen de beveiliging van mail-transport [1, 2], en bouwen daarvoor alle voort op de cryptografische infrastructuur van DNSSEC.

Op dit moment wordt de laatste hand gelegd aan de Wet Generieke Digitale Infrastructuur (WGDI). Een van de opties is om alle standaarden op de ptolu-lijst verplicht te stellen en een sanctiebepaling in de wet op te nemen.

Naar aanleiding van een onderzoek van Binnenlands Bestuur waaruit bleek dat gemeenten nauwelijks gebruik maakten van moderne internetstandaarden voor beveiligde e-mail heeft de toenmalige Minister van Binnenlandse Zaken in 2016 gesteld dat DNSSEC en de andere internetstandaarden op de ptolu-lijst uiterlijk eind 2017 bij alle gemeenten geïmplementeerd moeten zijn.

In aanvulling op de ptolu-lijst zijn binnen het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) ook zogenaamde Streefbeeldafspraken overeengekomen. Die houden in dat het gebruik van moderne internetstandaarden op overheidsdomeinen inmiddels op 100 procent had moeten zitten: de meest recente afspraak was voor IPv6 en die liep eind 2021 af. De laatste jaren stagneerde de verdere adoptie van al deze standaarden echter [1, 2].

SIDN, de beheerder van het .nl-topleveldomein, heeft niet alleen een belangrijke rol bij de uitrol van DNSSEC in Nederland, maar ook bij de ontwikkeling van deze beveiligingstechnologie. Zo is het verhuisprotocol, waarmee ondertekende domeinnamen naar een andere operator/registrar verhuisd kunnen worden zonder de DNSSEC-beveiliging daarvoor te hoeven onderbreken, voor een goed deel bedacht door SIDN Labs (en opgenomen in RFC 6781). Daarvoor is ook een uitbreiding op het EPP-protocol ontwikkeld om sleutelmateriaal via de registry van de nieuwe naar de oude operator over te dragen (inmiddels gestandaardiseerd als RFC 8063).

Daarnaast stimuleerde SIDN de adoptie van DNSSEC middels het instellen van een financiële incentive-regeling: door registrars een korting te geven op domeinen die DNSSEC toepassen, probeerden we omslagpunten in investeringen in DNSSEC dichterbij te brengen.

Inmiddels is de DNSSEC-incentive afgebouwd en vervangen door een bredere regeling: Vanaf 2023 is een minimum percentage aan DNSSEC-ondertekende .nl-domeinnamen voor registrars randvoorwaarde om überhaupt in aanmerking te komen voor de andere incentives (voor beveiligde e-mail, IPv6 en actief gebruik).

Het originele DNS-protocol is kwetsbaar maar niet onveilig. Ondanks zijn leeftijd is het protocol verbazingwekkend robuust gebleken tegen de vervalsing van DNS-informatie (DNS spoofing). Over de jaren (decennia!) heen zijn er wel verschillende aanvalsmethoden ontwikkeld, maar deze waren niet makkelijk uit te voeren en/of konden relatief makkelijk gepareerd worden. In de praktijk blijken dergelijke aanvallen dan ook zeldzaam.

Waar inbreuken op het protocol voorheen alleen theoretisch van aard waren, toonde Dan Kaminsky in 2008 echter een echt gat in het DNS-ontwerp aan. Daarmee konden kwaadwillenden daadwerkelijk valse informatie in de caches van de meestgebruikte DNS-servers te injecteren.

Na de publicatie van de Kaminsky-aanval was het lange tijd relatief rustig aan het DNS-front. Maar in november 2020 kwam de veiligheid van DNS weer groot in het nieuws met de publicatie van de 'SAD DNS'-aanval. De ontdekkers maakten gebruik van een nieuw side-channel om valse DNS-informatie in een caching resolver te injecteren.

En precies een jaar later kwam dezelfde onderzoeksgroep met een nieuwe 'cache poisoning'-aanval. Deze methode werkt conceptueel hetzelfde als de vorige, vandaar dat deze aanval nu de naam SAD DNS 2.0 heeft meegekregen.

Deze recente aanvalsmethoden draaien om het achterhalen van de momentane uitgaande UDP-poort van de resolver. Daarmee wordt de bescherming van de Source Port Randomization, de originele oplossing tegen de klassieke 'DNS cache poisoning'-aanval en de Kaminsky-aanval, tenietgedaan.

Op dit moment zijn de clients nog veruit het zwakste punt. Naarmate de veiligheid daar verbetert, zullen kwaadwillenden hun aandacht verleggen naar de DNS-servers en het transport van de DNS-informatie. De afgelopen jaren is dan ook hard gewerkt om DNSSEC, dat al veel langer bestaat, snel uit te ontwikkelen en te implementeren. Deze beveiligingstechnologie biedt een structurele oplossing voor dit type aanvallen. Een validerende resolver zal die valse informatie immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

DNSSEC is een cryptografische beveiliging voor DNS-informatie. Door de DNS-records van een digitale handtekening te voorzien, is de authenticiteit van die data gegarandeerd.

DNSSEC is een voorwaarts compatibele uitbreiding van het originele DNS-protocol. Dat betekent dat DNSSEC ingevoerd kon worden zonder dat daarvoor de bestaande DNS-infrastructuur op de schop moest. Ondanks dat het om een grote en complexe uitbreiding gaat, is DNSSEC keurig netjes ingepast in het bestaande DNS-protocol.

De DNSSEC-beveiliging bestaat uit 2 onderdelen:

• de records op de autoritatieve nameservers moeten van een digitale handtekening worden voorzien

• resolvers die DNS-informatie opvragen moeten de bijbehorende handtekeningen controleren

Ontbreekt een van deze twee onderdelen – dat wil zeggen dat de betreffende zone niet ondertekend is of de resolver geen validatie doet – dan verloopt de DNS-opvraging, -uitwisseling en -verwerking gewoon zoals voorheen. Voor verouderde nameservers en resolvers die zelfs geen weet hebben van deze beveiligingstechnologie, is DNSSEC dus een volledig transparante toevoeging op het DNS-systeem.

DNS-nameservers die DNSSEC ondersteunen, bieden de mogelijkheid om zones te ondertekenen. Dat betekent dat alle DNS-informatie in een zone van een digitale handtekening wordt voorzien (in de vorm van een RRSIG-record).

Omdat alle informatie in het DNS-systeem wordt opgevraagd, getransporteerd en verwerkt per RRset, wordt ook één RRSIG-record per complete RRset gegenereerd. De RRSIG-records zijn records precies zoals andere recordtypen, wat betekent dat ze ook in de zone worden opgenomen en voor opvraging beschikbaar zijn.

DNSSEC-validerende resolvers vragen niet alleen de normale DNS-records op, maar ook de bijbehorende DNSSEC-records (middels de DO-vlag, onderdeel van EDNS0). Als een zone inderdaad ondertekend is, komt met elke RRset ook een RRSIG-record mee. De resolver gebruikt de digitale handtekening in het RRSIG-record om de inhoud van de RRset op authenticiteit te controleren. Alleen als de digitale handtekening overeenkomt met de inhoud van de RRset (of als de zone geen DNSSEC-beveiliging bevat) wordt de binnengekregen informatie doorgegeven aan de applicatie (en opgeslagen in de cache van de resolver).

Naast de digitale handtekeningen (in de RRSIG-records) wordt ook de publieke sleutel (in de vorm van een DNSKEY-record) in de zone opgenomen. De hash-waarde (een digitaal uittreksel) van die publieke sleutel wordt (in de vorm van een DS-record) in de bovenliggende zone gepubliceerd. Omdat het DS-record in de bovenliggende zone ook daar weer van een digitale handtekening is voorzien, is de authenticiteit daarvan gegarandeerd. Op die manier wordt een cryptografische vertrouwensketen (chain of trust) bestaande uit RRSIG-DNSKEY-DS-links opgebouwd die stapsgewijs helemaal teruggaat tot aan de root.

De publieke sleutel voor de root zone is een zogenaamde well-known waarde die als trust anchor in elke validerende resolver is geïnstalleerd.

Domeinnaamhouders merken in principe niets van DNSSEC. Deze beveiligingsstandaard is een volledig transparante toevoeging op het bestaande DNS-systeem. Dat betekent dat DNSSEC op een domein aangezet kan worden zonder dat de houder of internetgebruikers daar "last" van hebben.

Voor domeinnaamhouders en internetgebruikers die DNSSEC ondersteunen wordt er voor beide partijen automatisch een sterke cryptografische beveiliging aan het DNS-systeem toegevoegd. Een adres waarvan de digitale handtekening niet klopt wordt dan door de client geblokkeerd. Gebruikers die nog geen DNSSEC ondersteunen blijven ondertekende domeinen gewoon op de oude manier gebruiken.

Internetgebruikers merken in eerste instantie niets van DNSSEC. Dit is vooral een technische aangelegenheid voor de (stub) resolver, het onderdeel van het besturingssysteem op hun client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen. Kan de authenticiteit van een ondertekend DNS-record niet geverifieerd worden, dan wordt de toegang tot het betreffende adres echter geblokkeerd. Dat in tegenstelling tot bijvoorbeeld ongeldige server-certificaten tijdens het browsen; daar kan men ervoor kiezen (in het pop-up window) om een website toch te bezoeken. Wat een gebruiker indirect natuurlijk wel merkt van DNSSEC is dat internet op termijn veiliger wordt.

Voor domeinnaamhouders en internetgebruikers die DNSSEC ondersteunen wordt er voor beide partijen automatisch een sterke cryptografische beveiliging aan het DNS-systeem toegevoegd. Een adres waarvan de digitale handtekening niet klopt wordt dan door de client geblokkeerd. Gebruikers die nog geen DNSSEC ondersteunen blijven ondertekende domeinen gewoon op de oude manier gebruiken.

DNSSEC is een belangrijke toevoeging aan het DNS-systeem. Het primaire doel ervan is om de authenticiteit van DNS-informatie te waarborgen, waarmee DNS spoofing onmogelijk wordt. Dat betekent ook dat dit beveiligingsprotocol niet alles afdekt:

• niet de client: DNSSEC beschermt alleen de inhoud van DNS-informatie zoals die ondertekend op de name-servers wordt gepubliceerd en naar de client wordt getransporteerd. De client zelf (het eindpunt) is echter niet beveiligd. Is een PC bijvoorbeeld besmet met malware, dan zijn meestal ook de (stub) resolver (het onderdeel van het besturingssysteem op de client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen) en de locale cache te manipuleren. Zo kan sommige malware de hosts-tabel aanpassen, waarmee DNS compleet omzeild wordt.

• alleen authenticiteit, geen vertrouwelijkheid: DNSSEC beschermt alleen de authenticiteit van DNS-informatie. Dat wil zeggen dat de digitale handtekening garandeert dat de DNS-antwoorden zoals die bij de (validerende) client aankomen overeenkomen met de informatie op de autoritatieve name-servers. Zowel de queries als de responses zelf zijn echter niet versleuteld en kunnen tijdens het transport door "iedereen" gelezen worden. DNSSEC biedt dus geen vertrouwelijkheid. DoT, DoH en DoQ zijn alle drie uitbreidingen van DNS die wel het transport van DNS-informatie beschermen. Ze zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).

• wel cryptografisch compleet, niet cryptografisch waterdicht: Hoewel de DNSSEC-vertrouwensketen cryptografisch compleet is, is deze niet cryptografisch waterdicht. Op elke overgang naar de bovenliggende zone (strikter: bij elke delegatie) bevindt zich immers een administratieve knip waar de beheerder van de bovenliggende zone het DS-record zou kunnen verwijderen. Omdat de aanwezigheid van een DS-record bepalend is voor het al dan niet aanwezig zijn van DNSSEC in de onderliggende zone, wordt daarmee de DNSSEC-bescherming voor de betreffende zone uitgeschakeld. Andere (meer in het oog lopende) mogelijkheden zijn het veranderen van een sleutel of het toevoegen van een extra DS-record. Een dergelijke aanpassing van het geregistreerde sleutelmateriaal in de .nl-zone zou in principe uitgevoerd kunnen worden door een (digitale) inbreker, een medewerker van SIDN, iemand in de aanleverketen (serviceprovider – registrar – reseller), of op verzoek van de overheid. Het primaire belang van SIDN ligt echter bij de domeinnaamhouders, registrars en serviceproviders. Inbreuk op de haar toevertrouwde functie zou uitsluitend kunnen worden afgedwongen na een gerechtelijk bevel, maar dat is tot op heden nog nooit voorgekomen.

De meeste clients bevatten zelf alleen een stub resolver en laten de recursieve queries – en daarmee de validatie – over aan de caching DNS-servers die ze via DHCP of NDP van de access-provider of netwerkbeheerder toegewezen krijgen. Die clients vertrouwen op de AD-vlag die door de DNS-servers na positieve validatie in de DNS-response wordt aangezet. Meestal blijft dus het traject tussen de stub resolver en de DNS-server – de zogenaamde 'Last Mile' – onbeveiligd.

DoT, DoH en DoQ zijn alle 3 uitbreidingen van DNS die wel het transport van DNS-informatie beschermen. Ze zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).

DNSSEC beschermt alleen de authenticiteit van DNS-informatie. Dat wil zeggen dat de digitale handtekening garandeert dat de DNS-antwoorden zoals die bij de (validerende) client aankomen overeenkomen met de informatie op de autoritatieve nameservers. Zowel de queries als de responses zelf zijn echter niet versleuteld en kunnen tijdens het transport door "iedereen" gelezen worden. DNSSEC biedt dus geen vertrouwelijkheid.

Daarnaast bevatten de meeste clients zelf alleen een stub resolver en laten de recursieve queries – en daarmee de validatie – over aan de caching DNS-servers die ze via DHCP of NDP van de internet accessprovider of netwerkbeheerder toegewezen krijgen. Meestal blijft dus het traject tussen de stub resolver en de DNS-server – de zogenaamde 'Last Mile' – onbeveiligd.

DoT, DoH en DoQ zijn alle 3 uitbreidingen van DNS die wel het (end-to-end) transport van DNS-informatie beschermen. Ze zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).

Nederland is wereldwijd een van de koplopers als het gaat om de ondertekening van domeinnamen: inmiddels is bijna 60 procent van alle .nl-domeinen met DNSSEC beveiligd (situatie december 2022). Dat hebben we met name te danken aan de registrars: veel van hen hebben na de officiële introductie van DNSSEC in 2012 de door hun beheerde domeinnamen in bulk ondertekend.

SIDN stimuleerde de adoptie van DNSSEC middels het instellen van een financiële incentive-regeling. Deze is voor registrars onderdeel van de Registrar Score Card (RSC). Door registrars een korting te geven op domeinen die DNSSEC toepassen, proberen we omslagpunten in investeringen in DNSSEC dichterbij te brengen. Inmiddels wordt de DNSSEC-incentive afgebouwd, om daarna te worden vervangen door een bredere regeling.

Hoewel het aandeel beveiligde domeinnamen nog steeds doorstijgt, gaat dit inmiddels wel tergend langzaam: de afgelopen vier jaar zaten we op een groei van 1 à 2 procentpunt per jaar.

https://images.ctfassets.net/yj8364fopk6s/2b8zHsZDyQkjXEhfhjbCgS/7d6fd097a11867e0c50bca7edf463450/stats.sidnlabs.nl-DNSSECbeveiligd-20221206.png

Uit een in 2014 gemaakte inventarisatie bleek dat er wel grote verschillen bestaan tussen de verschillende sectoren. In 2017 werd deze inventarisatie nog eens herhaald. Hoewel daaruit bleek dat het aandeel ondertekende domeinnamen over hele breedte sterk was toegenomen, waren die grote onderlinge verschillen er nog steeds. Waar de overheden hun eerdere achterstand inmiddels meer dan goed hadden gemaakt, liepen de banken en de internetsector nog steeds sterk achter.

Op dit moment is grofweg 60 procent van alle binnenkomende queries op de autoritatieve servers voor .nl afkomstig van validerende resolvers (situatie december 2022). Let op dat het hier niet gaat om (alleen) de Nederlandse resolvers maar om resolvers wereldwijd. De meeste van die queries zijn afkomstig van de grote cloudleveranciers: Google, Microsoft, Amazon en Cloudflare. Vandaar ook dat de meeste queries afkomstig zijn van resolvers in de VS (ruim 25 procent), en slechts 10 procent van resolvers in Nederland zelf.

https://images.ctfassets.net/yj8364fopk6s/3sPTKJLK6Eu2uNL59EChQU/586fb547f8b75c7fa5f695070f2ee2dc/stats.sidnlabs.nl-DNSSECqueries-20221206.png

https://images.ctfassets.net/yj8364fopk6s/7D2KXaDwJMSCyPrjTLuNkk/eb8e037c5141c1ab9a315bc6094f44fa/stats.sidnlabs.nl-DNSSECresolverNetwerken-20220807.png

https://images.ctfassets.net/yj8364fopk6s/1pT8G7bgFkpMaxxakRcKK4/03ad8d215e1827e448d425643c90e950/stats.sidnlabs.nl-DNSSECresolverLocations-20221206.png

Wat betreft de validatie liepen we in Nederland lange tijd achter op de rest van de wereld. Specifiek voor de Nederlandse internetgebruikers was het probleem dat de 2 grootste Nederlandse access-providers, KPN en Ziggo, beide geen validatie op hun DNS-servers ondersteunden. In 2020 heeft KPN (eindelijk) validatie aangezet voor zijn KPN/Telfort-klanten. VodafoneZiggo ondersteunt echter nog steeds geen validatie. Daarmee maakt nu ongeveer 60 procent van de Nederlandse internetgebruikers gebruik van een validerende resolver.

https://images.ctfassets.net/yj8364fopk6s/5DVqp8ensDxctdx4bK9CSB/b71287d7d8a081f3305c352fc0fe461c/stats.sidnlabs.nl-DNSSECresolverNLnetwerken-20221206-compleet.png

https://images.ctfassets.net/yj8364fopk6s/3Zty47erq7Fr75yrBpmPhU/098c1814f57bb52aabe481c939fc8392/APNIC-DNSSECvalidationNL-20221206.png

https://images.ctfassets.net/yj8364fopk6s/7AfiaBOmZRqGKBMoCbJRB2/eaeb6e41e2d390a342b16353190bd606/APNIC-DNSSECvalidationKPN-20221206.png

https://images.ctfassets.net/yj8364fopk6s/3cXgSNqzOct00oJoI9A51Q/e9319212a6f4579333af5c2d043fdfee/APNIC-DNSSECvalidationVodafoneZiggo-20221206.png

De Nederlandse overheid heeft een belangrijke voortrekkersrol bij de adoptie van DNSSEC. In 2012 – een maand na de officiële introductie – werd DNSSEC (tegelijkertijd met DKIM) door Forum Standaardisatie toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst (ptolu). Sindsdien zijn overheidsorganisaties dus min-of-meer verplicht om hun domeinen en systemen met DNSSEC te beveiligen. Berichtgeving over de slechte beveiliging van gemeentelijke sites was in juni 2016 aanleiding voor de toenmalige Minister van Binnenlandse Zaken om de gemeenten aan te sporen om eind 2017 hun domeinnamen met DNSSEC (en TLS, DKIM en SPF) te hebben beveiligd.

Daarnaast is Forum Standaardisatie initiatiefnemer van het Platform Internetstandaarden [1, 2] en de Internet.nl portal. Daar kun je je verbindingen en domeinen testen op de toepassing van zes moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een gecombineerde totaalscore, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance". Inmiddels zijn er op die manier al honderdduizenden tests uitgevoerd.

Waar overheidsorganisaties in 2014 nog sterk achterliepen met hun DNSSEC-implementaties, hadden zij die achterstand bij de inventarisatie van 2017 meer dan goedgemaakt.

Zo (relatief) goed als het inmiddels gaat met de adoptie van DNSSEC in Nederland, zo slecht gaat het met de adoptie van DNSSEC wereldwijd. Vooral de toepassing van DNSSEC binnen de topleveldomeinen (dat wil zeggen: de ondertekening van domeinnamen) blijft wereldwijd gezien sterk achter.

De ondersteuning van DNSSEC is door ICANN verplicht gesteld vanaf 1 januari 2014, wat betekent dat in ieder geval alle nieuwe gTLD's deze beveiligingstechnologie ondersteunen.

Op dit moment wordt DNSSEC (ondertekening) door ruim 90 procent van alle ccTLD's ondersteund (situatie mei 2024). Op het kaartje hieronder kun je zien dat het vooral ccTLD's in Afrika en het Midden-Oosten zijn die DNSSEC nog niet ondersteunen.

https://images.ctfassets.net/yj8364fopk6s/3ovMRCMnTRRwPFkutj40uv/6d09badf8d716ef0ec6771505ec05211/ISOC-Pulse-DNSSEC-20221208.png

De toepassing van DNSSEC binnen de TLD's wisselt enorm en is sterk afhankelijk van:

• een financiële incentive-regeling van de betreffende registry

• voor ccTLD's: het aantal grote accessproviders binnen de betreffende regio en hun beleid

• overheidsbeleid met betrekking tot moderne internetbeveiligingsstandaarden in het algemeen en DNSSEC in het bijzonder

Onderstaande grafiek laat de ontwikkeling van DNSSEC in de best presterende Europese ccTLD's zien (situatie augustus 2022). Naast de Nederlandse .nl-zone doen ook Tsjechië (.cz), Noorwegen (.no) en Zweden (.se) het goed, met een adoptiegraad die boven de 50 procent ligt (net als het hier ook populaire .nu-domein). Snelle stijgers zijn Zwitserland (.ch) en Denemarken (.dk).

SIDN heeft de afgelopen jaren een belangrijke bijdrage geleverd aan de ontwikkeling van de DNSSEC-standaard, net als de Zweedse registry Internetstiftelsen en de Tsjechische registry CZ.NIC. Daarnaast ondersteunde SIDN direct of indirect de ontwikkeling en deployment van DNS(SEC)-software: veelgebruikte pakketten als PowerDNS [1, 2], Unbound, NSD en OpenDNSSEC worden allemaal in Nederland ontwikkeld.

CZ.NIC doet vergelijkbare dingen met de ontwikkeling van Knot DNS, Knot Resolver en de DNSSEC/TLSA Validator (die laatste wordt niet langer onderhouden).

Maar belangrijkste: naast SIDN hebben ook de Zweedse, Tsjechische en Noorse registry’s een financiële incentive-regeling (en de .nu-zone wordt beheerd door de Zweedse registry).

Hoe belangrijk een actieve rol van de registry en een incentive voor de adoptie van DNSSEC zijn, kun je zien aan de "toepassing" ervan in de internationale gTLD's .com, .net, .org en .info: in deze (en vele andere) zones is het gebruik van DNSSEC verwaarloosbaar.

https://images.ctfassets.net/yj8364fopk6s/12JnSQ8oVt3pfd5bxgZgKq/7cca57394e51aeb5fdb79c98c942f4f5/diagram_grouped-screenshot2.png

Wereldwijd zit het aandeel internetgebruikers dat gebruik maakt van een validerende resolver op dit moment rond de 30 procent (situatie december 2022). Na een stagnatie in de COVID-jaren is de adoptie over het afgelopen jaar wel weer met grofweg 5 procentpunt gestegen.

https://images.ctfassets.net/yj8364fopk6s/6pJMKoN5oXoU6JuqDY9Kqi/2d16910af69972d80a6c1d01896f4859/APNIC-DNSSECvalidationWorldXA-20221206.png

Voor Europa ligt het gebruik van DNSSEC-validatie nu op ruim 40 procent. Ook daar zie je een toegenomen groei over het afgelopen jaar.

https://images.ctfassets.net/yj8364fopk6s/KVa1WLeRi0R8zO7RiKgCB/3d47544e004cf16837a9bf5a4a7cea42/APNIC-DNSSECvalidationEuropeXE-20221206.png

Met een adoptiegraad van ongeveer 60 procent zit Nederland ook voor wat betreft DNSSEC-validatie eindelijk op het niveau van de landen om ons heen. De Scandinavische landen doen het een stuk beter; de Zuid-Europese landen en GB/IE een heel stuk slechter.

https://images.ctfassets.net/yj8364fopk6s/33G7mG2tflUs9PDasYcZmS/58f5f3bb7ee50100df41d82a411d6413/APNIC-DNSSECvalidationEuropeXEmapNL-20221206.png

De infrastructuur en faciliteiten voor de ondertekening van .nl-domeinennamen zijn al sinds 2012 volledig operationeel. In principe kan elke .nl-domeinnaam nu dus met DNSSEC worden beveiligd. Bovendien kunnen domeinnamen sinds 2013 ook tussen verschillende registrars verhuisd worden, zonder dat die beveiliging daarbij verbroken hoeft te worden.

Is het beheer van de DNS-informatie ondergebracht bij een registrar of een andere operator, dan moet deze zijn domeinnamen ondertekenen en de publieke sleutels via de administratieve interface uploaden naar SIDN, de beheerder van het .nl-topleveldomein. Veel registrars hebben de door hun beheerde domeinnamen inmiddels in bulk ondertekend.

Doe je het beheer van de DNS-informatie zelf – dat wil zeggen dat je eigen DNS-servers hebt staan – dan begint de implementatie met het genereren van een cryptografisch sleutelpaar. De private sleutel wordt gebruikt om de resource record sets (RRsets) in de betreffende zone te ondertekenen. De publieke sleutel moet je via het administratieve dashboard van de registrar of serviceprovider uploaden naar SIDN. De beheerder van het .nl-topleveldomein heeft deze mogelijkheid ook opgenomen in zijn interface voor de registrars. Registrars en serviceproviders kunnen het invoerveld voor die publieke sleutel nu dus bij de invoervelden voor de nameservers aan hun klanten aanbieden in hun administratieve dashboards.

Deze laatste mogelijkheid moet je ook gebruiken als het beheer van de DNS-informatie is ondergebracht bij een operator als CDN-aanbieder CloudFlare.

Alle veelgebruikte DNS-servers ondersteunen inmiddels DNSSEC. Zij voorzien ook in tools voor onder andere het genereren van de sleutelparen en het ondertekenen van de records. Bij BIND (named), de meest gebruikte DNS-server buiten de wereld van de grote registrars, worden van origine bijvoorbeeld 'dnssec-keygen' (voor het genereren van een cryptografisch sleutelpaar) en 'dnssec-signzone' (voor het ondertekenen van de records) meegeleverd.

Hoewel de laatste versies van BIND zelf steeds meer mogelijkheden bieden voor het volledig automatiseren van ondertekening en sleutelbeheer, kunnen we voor grote installaties de combinatie met OpenDNSSEC aanraden. Dit pakket automatiseert niet alleen de ondertekening maar neemt ook het volledige sleutelbeheer voor zijn rekening.

Grote operators, zoals de meeste registrars, gebruiken veelal PowerDNS. Deze DNS-server heeft het gebruik van DNSSEC zo veel mogelijk geautomatiseerd en transparant gemaakt. Menig operator die voorheen een ander pakket gebruikte, is juist vanwege die goede DNSSEC-ondersteuning naar PowerDNS overgestapt.

Ook de appliances van Infoblox– proprietary-oplossingen gebaseerd op Linux en BIND die vaker in zakelijke omgevingen worden ingezet – ondersteunen DNSSEC out-of-the-box. Aanzetten is na de eerste configuratie slechts een kwestie van aanvinken. Eerder was de DNSSEC-functionaliteit van de Infoblox appliances echter sterk verouderd en hebben we het gebruik ervan voor nieuwe implementaties afgeraden.

SIDN heeft in de loop der tijd een hele serie hands-on artikelen gepubliceerd over de DNSSEC-ondertekening op de meest gebruikte autoritatieve nameservers. Hieronder geven we een overzicht van de belangrijkste kenmerken van deze softwarepakketten. Moet je nog kiezen voor een DNS(SEC)-oplossing, dan komt dit overzicht hopelijk van pas bij het maken van je afweging.

• Infoblox appliance Deze kant-en-klare systemen worden met name gebruikt door grote commerciële organisaties. De ondertekening van een zone is slechts een kwestie van aanklikken. Beide keren dat we deze appliance hebben bekeken (de laatste keer was zomer 2018), moesten we echter concluderen dat de software in ieder geval wat DNSSEC betreft ernstig verouderd was.

• BIND named BIND named is de de facto (open-source) standaard op Linux en andere Unix-achtige systemen, en daarmee de meest gebruikte DNS-server (buiten de wereld van de grote registrars). Vanaf versie 9.11 is ook het sleutelbeheer volledig te automatiseren. Daarmee zijn losse scripts en cron jobs of de inzet van OpenDNSSEC niet meer nodig. Na de initiële configuratie lopen het genereren van sleutelparen, het ondertekenen van zone files, het rollen van sleutels en het beheer van sleutels allemaal vanzelf.

• PowerDNS Authoritative Server PowerDNS is een Nederlands (open-source) product dat zijn grote doorbraak te danken heeft aan de implementatie van DNSSEC. Waar de ondertekening van domeinen op andere autoritatieve servers destijds nogal wat voeten in de aarde had, hanteerde PowerDNS vanaf het begin een turnkey-aanpak. Andere onderscheidende kenmerken zijn de schaalbaarheid en snelheid. Vrijwel alle grote service providers die hun domeinen in bulk ondertekenden, deden dat dan ook op basis van de Authoritative Server. Hoewel de software een mooie architectuur heeft, kan het door de uitgebreidheid ervan wel even duren voordat je je weg hebt gevonden.

SIDN heeft in de loop der tijd een hele serie hands-on artikelen gepubliceerd over de DNSSEC-ondertekening op autoritatieve name-servers:

• DNSSEC-ondertekening op BIND named

• DNSSEC-ondertekening op de PowerDNS Authoritative Server

• DNSSEC-ondertekening op een Infoblox appliance

Een overzicht van de belangrijkste kenmerken van deze softwarepakketten vind je hier.

Daarnaast publiceert SIDN regelmatig nieuwsberichten, technische artikelen, rapporten en cases over DNSSEC op sidn.nl.

Beheerders die de werking van DNSSEC willen controleren, kunnen daarvoor de tools gebruiken die worden meegeleverd met hun DNS-server, of de veelgebruikte BIND netwerk-tool 'dig' (met de '+dnssec'-optie).

Heb je je DNSSEC-configuratie eenmaal voor elkaar, dan zijn er online tools die een complete check op een domein uitvoeren, zoals deze van Verisign:

• https://dnssec-debugger.verisignlabs.com/

Of DNSViz van Sandia (levert een mooi grafisch overzicht):

• https://dnsviz.net/

https://images.ctfassets.net/yj8364fopk6s/R5iirPB9q16YszMK9qwgO/dc4528a156aae414ed2259ee95648610/DNSViz-sidn.nl-2023-01-23-08_47_03-UTC.svg

SIDN Labs heeft een online tool beschikbaar waarmee een hele lijst van domeinnamen in één keer gecontroleerd kan worden (let op: deze tool wordt in de loop van 2023 uitgefaseerd):

• DNSSEC Portfolio Checker

Op de Internet.nl-portal kun je je verbindingen en domeinen testen op de toepassing van een zestal moderne internet-standaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een gecombineerde totaalscore, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance".

Op Internet.nl-portal kun je je verbindingen en domeinen testen op de toepassing van 6 moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een gecombineerde totaalscore, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance". Specifiek voor het testen van DNSSEC (en IPv6) aan gebruikerszijde vind je hier hun Connection Test:

• https://conn.internet.nl/connection/

Let op! Als DNSSEC niet ondersteund blijkt te worden, wil dat niet noodzakelijkerwijs zeggen dat de eigen (stub) resolver (het onderdeel van het besturingssysteem op de client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen) een probleem heeft. Vaak maakt deze (via DHCP) gebruik van de caching DNS-servers van de accessprovider.

Beheerders van autoritatieve nameservers zullen regelmatig de cryptografische sleutelparen voor hun ondertekende zones moeten vervangen.

Bijvoorbeeld als onderdeel van een periodieke update. Dat kan zijn omwille van de veiligheid, bijvoorbeeld vanwege een achterhaalde sleutellengte of een onveilig geworden algoritme, of omwille van de tijd die aanvallers nodig hebben om een 'brute force'-aanval uit te voeren. Dat kan zijn om in geval van calamiteiten voldoende routine te hebben met het vervangingsproces (vergelijk het maandelijks opstarten van het noodaggregaat). En dat kan zijn bij de overstap naar een andere operator/registrar.

Veel urgenter dan deze reguliere gevallen wordt de vervanging wanneer geheim sleutelmateriaal uitgelekt of anderszins gecompromitteerd is.

Bij een nette overstap naar een nieuw sleutelpaar blijft de DNS-dienst voor iedereen bereikbaar en wordt de bescherming van DNSSEC niet onderbroken.

Zomaar cryptografisch materiaal gepubliceerd in het DNS-systeem vervangen door iets nieuws kan echter niet. Omdat DNSSEC-records net als alle andere DNS-records door de resolvers gecachet worden, moet je er rekening mee houden dat oude informatie nog een tijdje op internet gebruikt blijft worden (en wel zo lang als gespecificeerd in de TTL-waarde van de betreffende records).

Dat betekent dat er altijd een zogenaamde key rollover zal moeten plaatsvinden. Daarbij wordt eerst de nieuwe sleutel geïntroduceerd en gepropageerd, pas waarna de oude sleutel kan worden uitgefaseerd. Tijdens een rollover zullen er dus tijdelijk 2 (gedeeltelijke) sets van de DNSSEC-records naast elkaar gebruikt worden.

Het is goed om het belang en de werking van rollovers te kennen. Ook aanpassingen in DNS-records voor andere, op DNSSEC voortbouwende beveiligingsstandaarden moeten immers met een rollover doorgevoerd worden.

BIND versie 10 was een compleet nieuwe ontwikkeling ten opzichte van versie 9. Zo is de software geschreven in C++ (voor de kern) en Python (voor de interface), en is de architectuur opgebouwd uit meerdere daemons (vergelijkbaar met de Postfix MTA). De ontwikkeling van BIND10 werd onder andere gesponsord door SIDN.

In 2014 heeft ISC versie 1.2.0 van BIND10 onder de nieuwe naam Bundy aan de internet community overgedragen. De hoop was dat de open-source gemeenschap de verdere ontwikkeling op zich zou nemen, maar dat is niet gebeurd. De verschillen met versie 9 bleken te groot: de enige overeenkomst was dat zone files voor versie 9 nog steeds konden worden ingelezen, en dan kun je net zo goed naar PowerDNS overstappen, wat veel grote operators ook hebben gedaan. Bovendien waren belangrijke onderdelen nog niet geïmplementeerd: de BIND10 software ondersteunt wel DNSSEC maar doet zelf nog geen ondertekening, en de recursieve resolver is nog niet bruikbaar. Op dit moment ligt de verdere ontwikkeling van Bundy nog steeds stil.

De DHCP-server die als onderdeel van BIND10 is ontwikkeld is ondergebracht in het Kea-project en wordt wel verder ontwikkeld door ISC.

ISC gaat voorlopig gewoon door met de verdere ontwikkeling van BIND versie 9.

Uitgebreide, praktische informatie voor de configuratie van BIND named vind je hier:

• Hands-on: DNSSEC-ondertekening op BIND named

• Hands-on: DNSSEC-validatie op BIND named

Om zeker te weten dat de vertaling van domeinnaam naar IP-adres waterdicht beveiligd is, moet de hele keten veilig zijn. Dat geldt niet alleen voor alle autoritatieve nameservers betrokken bij de domeinnaam zelf, maar ook voor de caching DNS-servers bij de accessprovider en de client bij de eindgebruiker.

De meeste clients bevatten zelf alleen een stub resolver en laten de recursieve queries – en daarmee de validatie van DNSSEC– over aan de caching DNS-servers die ze via DHCP of NDP van de accessprovider of netwerkbeheerder toegewezen krijgen. Die clients vertrouwen op de AD-vlag die door de DNS-servers na positieve validatie in de DNS-response wordt aangezet. Meestal blijft dus het traject tussen de stub resolver en de DNS-server – de zogenaamde 'Last Mile' – onbeveiligd.

Hier in Nederland behoren Freedom, BIT en Edutel tot de kleinere accessproviders die al langere tijd DNSSEC op hun netwerk valideren. Van de 2 grootste Nederlandse providers heeft alleen KPN in 2020 (eindelijk) validatie aangezet voor zijn KPN/Telfort-klanten. Maar Ziggo ondersteunt zelfs nu nog steeds geen validatie op zijn DNS-servers (situatie februari 2023).

Netwerkbeheerders die DNSSEC voor hun gebruikers willen valideren, kunnen daarvoor bijvoorbeeld gebruik maken van BIND named of de PowerDNS Recursor [1, 2]. Beheerders van kleinere netwerken kunnen dnsmasq inzetten, een gecombineerde DNS/DHCP-server die ook DNSSEC ondersteunt.

Eindgebruikers die een gegarandeerd veilige DNS-resolver willen, moeten daarvoor zelf de Unbound resolver of een andere validerende resolver installeren. De installatie en configuratie van Unbound met DNSSEC-Trigger beschrijven we hier. Maar er zijn ook andere opties voor eindgebruikers beschikbaar.

Weet tenslotte dat DNSSEC alleen de inhoud van de DNS-informatie beschermt zoals die ondertekend op de autoritatieve nameservers wordt gepubliceerd en naar de client wordt getransporteerd. De client zelf (het eindpunt) is echter niet beveiligd. Is een pc bijvoorbeeld besmet met malware, dan zijn meestal ook de (stub) resolver (het onderdeel van het besturingssysteem op de client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen) en de locale cache te manipuleren. Zo kan sommige malware de hosts-tabel aanpassen, waarmee DNS compleet omzeild wordt.

SIDN heeft in de loop der tijd een hele serie hands-on artikelen gepubliceerd over de validatie van DNSSEC op de meest gebruikte (caching) resolvers. Hieronder geven we een overzicht van de belangrijkste kenmerken van deze softwarepakketten. Moet je nog kiezen voor een DNS(SEC)-oplossing, dan komt dit overzicht hopelijk van pas bij het maken van je afweging.

• Unbound en DNSSEC-Trigger De validerende resolver Unbound is een Nederlands (opensource) pakket. Heb je alleen een validerende resolver nodig, dan is Unbound waarschijnlijk een betere optie dan BIND named, en zeker veel beter dan de stub resolvers die met Linux of Windows worden meegeleverd. De software is compact en snel, en is inmiddels de standaard resolver op diverse Linux-distributies, alsook op FreeBSD en OpenBSD. In combinatie met DNSSEC-Trigger biedt Unbound bovendien een hele makkelijke oplossing voor end-to-end-validatie door mobiele gebruikers.

• Infoblox appliance Voor de configuratie van DNSSEC-validatie op een Infoblox appliance hoef je op recentere versies van NIOS in principe niet meer te doen dan de default-instellingen te controleren. Deze mogelijkheid is wat ons betreft echter alleen relevant voor organisaties die al Infoblox in huis hebben. Beide keren dat we deze appliance hebben bekeken (de laatste keer was zomer 2018), moesten we namelijk concluderen dat de software in ieder geval wat DNSSEC betreft ernstig verouderd was.

• PowerDNS Recursor PowerDNS is een Nederlands (opensource) product dat zijn grote doorbraak te danken heeft aan de implementatie van DNSSEC. De Recursor ondersteunt DNSSEC-validatie vanaf versie 4.0. Het belangrijkste onderscheid met de Unbound resolver is dat de instellingen in het configuratiebestand zich beperken tot bekende server-aangelegenheden, terwijl de configuratie van Unbound bestaat uit één lange lijst van zowel opties voor server- als DNSSEC/protocol-specifieke zaken. Wil je meer van de PowerDNS Recursor, dan kan dat door het inladen van aparte startup/run-time programma's voor de ingebouwde Lua engine.

• BIND named BIND named kan fungeren als (autoritatieve) nameserver en/of (caching) resolver. Omdat de software met de ontwikkeling van DNSSEC is meegeëvolueerd, is net als bij de ondertekening ook voor de validatie de geboden functionaliteit sterk afhankelijk van de softwareversie. Heb je alleen een validerende resolver nodig, dan is Unbound waarschijnlijk een betere optie.

Dit bericht verwijst naar de evaluatie van 6 veelgebruikte validerende resolvers door netwerk/infrastructuur-architect Tore Anderson. Unbound en de Knot Resolver worden door hem sterk aanbevolen. De laatste versies van PowerDNS Recursor en BIND named doen hun werk ook goed, maar hebben volgens Anderson geen meerwaarde boven Unbound en de Knot Resolver.

SIDN heeft in de loop der tijd een hele serie hands-on artikelen gepubliceerd over DNSSEC-validatie op (caching) resolvers:

• DNSSEC-validatie met Unbound en DNSSEC-Trigger

• DNSSEC-validatie op BIND named

• DNSSEC-validatie met de PowerDNS Recursor

• DNSSEC-validatie op een Infoblox appliance

Een overzicht van de belangrijkste kenmerken van deze softwarepakketten vind je hier.

Daarnaast publiceert SIDN regelmatig nieuwsberichten, technische artikelen, rapporten en cases over DNSSEC op sidn.nl.

De AD-vlag (Authentic Data) wordt door (caching) DNS-servers gebruikt om aan te geven dat zij de DNSSEC-records hebben gevalideerd. Een client hoeft deze controle dan niet meer zelf uit te voeren. In zijn DNS-query vraagt de (stub-)resolver om validatie (en de RRSIG-records) door de DO-vlag (DNSSEC OK) te zetten – met de netwerk-tool dig zou je daarvoor de optie '+dnssec' gebruiken. De DNS-server kan dan met de DNS-records ook de AD-vlag meesturen. Op die manier neemt deze dus niet alleen de caching maar ook de validatie voor zijn rekening.

Maar let op bij het testen van een validerende DNS-server: de specificatie van DNSSEC (RFC 4035, sectie 3.1.6) bepaalt dat autoritatieve nameservers geen validatie hoeven doen voor hun eigen domeinen. Zij mogen de AD-vlag dan wel zetten, maar alleen als zij hun autoritatieve records op een veilige manier hebben gekregen. Dat moet dan wel apart geconfigureerd worden.

Inmiddels is de rol van de AD-vlag uitgebreid: was deze voorheen alleen gedefinieerd voor DNS-responses, nu kan de AD-vlag ook worden gebruikt in DNS-queries. In RFC 6840, sectie 5.7, kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-queries uit te zetten. Nu levert het aanzetten van de AD-vlag in de DNS-query alleen informatie over de uitkomst van de validatie op (middels de AD-vlag in de DNS-response), maar niet meer de RRSIG-records zelf. De netwerk-tool dig ondersteunt deze mogelijkheid inmiddels via de '+adflag'-optie. De DO-vlag blijft zoals voorheen gebruikt worden om ook de RRSIG-records op te vragen.

Het crypto-technische antwoord luidt natuurlijk: nooit! Omdat het traject tussen de (stub-)resolver en (caching) DNS-server in het algemeen niet is beveiligd, kan de inhoud van de DNS-response via een man-in-the-middle (MITM)-aanval altijd veranderd worden, zonder dat de client dat detecteert. Dat betekent dat de inhoud van de records en alle meta-data (de headers) in principe niet te vertrouwen zijn.

Hoewel het voor de handliggend (en efficiënt) is om de validatie van DNSSEC te combineren met het cachen van DNS-records, wordt daarbij wel de cryptografisch beveiligde DNSSEC-keten ingekort. In het ideale geval loopt deze immers van de root zone (.) helemaal tot aan het bijbehorende trust anchor op de client. Als ook de validatie op de caching DNS-servers uitgevoerd wordt, moet dus een nieuwe technologie voor het laatste stuk van het traject worden ingezet om het transport van de AD-vlag te beveiligen.

Voor dit probleem van 'The Last Mile' waren eerder al verschillende oplossingen beschikbaar:

• De uitwisseling van DNS-informatie kan beveiligd worden met TSIG (Transaction SIGnature). Dit protocol wordt vaak gebruikt om DNS-records tussen autoritatieve nameservers uit te wisselen, en om updates voor Dynamische DNS vanaf de DHCP-servers naar de DNS-server te beveiligen. TSIG is ook te gebruiken tussen resolver en DNS-server, maar is daar geen voor de hand liggende optie. Omdat dit protocol gebaseerd is op symmetrische cryptografie , moet eerst een geheime, gedeelde sleutel tussen client en server worden uitgewisseld.

• DNSCrypt is wel gebaseerd op een asymmetrisch protocol, en daarmee beter geschikt voor de beveiliging van 'The Last Mile'. Het wordt gebruikt door DNS-dienstverlener OpenDNS om het verkeer met hun clients te versleutelen. Het systeem is een afgeleide van DNSCurve, ontwikkeld door Daniel J. Bernstein (DJB), die een naam heeft hoog te houden waar het gaat om het schrijven van veilige, snelle internet-software. Hij is onder andere de ontwikkelaar van qmail, djbdns en EdDSA. DNSCrypt wordt met name ondersteund door OpenDNS en is beschikbaar voor Windows, Linux, macOS en de iPhone.

• DNSSIG zet zich af tegen DNSCrypt. Het wil vooral een zo transparant mogelijke oplossing zijn, door gebruik te maken van het TXT-record.

• Met Secure Dynamic Update heeft Microsoft een protocol ontwikkeld voor de tunneling van DNS-verkeer. Dit systeem maakt gebruik van de GSS-API en een variant van Kerberos.

Ondanks alle eerdere initiatieven en ideeën, is geen van deze technologieën uiteindelijk (structureel) ingezet om 'The Last Mile' te beveiligen. In plaats daarvan zijn de open standaarden DoT, DoH en DoQ nu dé manier om het transport van DNS-verkeer te beschermen. Deze standaarden zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).

De AD-vlag is (zonder verdere bescherming) wel te gebruiken op een netwerk waar de beveiliging van 'The Last Mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten access-netwerken van internetproviders en mobiele operators. Daar kan DNSSEC-validatie samen met DNS-caching gecentraliseerd worden op de recursing DNS-servers.

De meeste clients bevatten zelf alleen een stub resolver en laten de recursieve queries – en daarmee de validatie – over aan de caching DNS-servers die ze via DHCP of NDP van de access-provider of netwerkbeheerder toegewezen krijgen. Die clients vertrouwen op de AD-vlag die door de DNS-servers na positieve validatie in de DNS-response wordt aangezet. Meestal blijft dus het traject tussen de stub resolver en de DNS-server – de zogenaamde 'Last Mile' – onbeveiligd.

Bovendien biedt het DNS-protocol geen mogelijkheid om door te geven wat er precies is misgegaan als een DNSSEC-validatie mislukt is; een adres waarvan de digitale handtekening niet klopt wordt door de resolver simpelweg geblokkeerd.

De verwachting is dan ook dat validatie op de client steeds meer de standaard gaat worden. Daarmee wordt immers het probleem van de 'Last Mile' verholpen. Daarnaast kunnen webbrowsers en andere applicaties op de client zelf nog valideren. Zij kunnen de gebruiker dan ook een inhoudelijke foutmelding geven.

Deze jaren zien we vooral een trend naar de toepassing van DoT, DoH en DoQ in resolvers en applicaties. Deze technologieën beschermen echter alleen het transport tussen de resolver en applicatie enerzijds en de ingestelde DNS-dienst anderzijds. De authenticiteit van de DNS-informatie wordt op deze manier niet beschermd; daarvoor is nog steeds DNSSEC-validatie nodig.

De verwachting is dat validatie op de client steeds meer de standaard gaat worden. Daarmee wordt immers het probleem van de 'Last Mile' verholpen. Daarnaast kunnen webbrowsers en andere applicaties op de client zelf nog valideren. Zij kunnen de gebruiker dan ook een inhoudelijke foutmelding geven.

Deze jaren zien we vooral een trend naar de toepassing van DoT, DoH en DoQ in resolvers en applicaties. Deze technologieën beschermen echter alleen het transport tussen de resolver en applicatie enerzijds en de ingestelde DNS-dienst anderzijds. De authenticiteit van de DNS-informatie wordt op deze manier niet beschermd; daarvoor is nog steeds DNSSEC-validatie nodig.

Netwerkbeheerders die DNSSEC voor hun gebruikers willen valideren kunnen daarvoor bijvoorbeeld gebruik maken van BIND named of de PowerDNS Recursor [1, 2]. Beheerders van kleinere netwerken kunnen dnsmasq inzetten, een gecombineerde DNS/DHCP-server die ook DNSSEC ondersteunt.

Eindgebruikers die een gegarandeerd veilige DNS-resolver willen, zullen daarvoor zelf de Unbound resolver of een andere validerende resolver moeten installeren. De installatie en configuratie van Unbound met DNSSEC-Trigger beschrijven we hier.

Maar er zijn ook andere opties voor eindgebruikers beschikbaar:

• DNSSEC-validatie in systemd-resolved (een stub resolver onderdeel van de systemd suite voor Linux)

• Unwind: een validerende forwarding DNS-resolver (een drop-in replacement voor Unbound, gemaakt door de ontwikkelaars van OpenBSD)

• Stubby: een validerende forwarding DNS-resolver met DoT-ondersteuning

Sowieso zijn wij van mening dat DNS-resolving en DNSSEC-validatie niet op applicatieniveau maar op het niveau van het operating system thuishoort; de webbrowser is lang niet de enige gebruiker van DNS op een systeem.

De Valibox is een software-image waarmee eindgebruikers hun draadloze thuis/kantoor-netwerk in een keer van end-to-end DNSSEC-validatie kunnen voorzien.

De software is ontwikkeld door SIDN Labs, de onderzoeksafdeling van SIDN, en gebaseerd op de open-source pakketten OpenWrt en Unbound. Op dit moment worden 4 verschillende hardware devices ondersteund: de GL-Inet AR-150 en MT300A, de VirtualBox en de Raspberry Pi 4B.

Vanaf versie 1.2.0 bevat de Valibox ook het SPIN-onderdeel (Security for In-home Networks), waarmee gebruikers in detail kunnen zien wat de apparaten en apparaatjes in hun netwerk allemaal naar buiten sturen – denk aan het Internet of Things (IoT). Andersom wordt potentieel gevaarlijk verkeer van buiten naar binnen tegengehouden, waarmee dit access point dus ook als een persoonlijke firewall fungeert.

In de periode van juli 2015 tot november 2017 draaide SIDN een pilot met een DNSSEC-validerende DNS-dienst. Het primaire doel was om zelf informatie te verzamelen over problemen veroorzaakt door validatiefouten. Het tweede doel was om te onderzoeken of SIDN een dergelijke dienst misschien voor een breed publiek beschikbaar zou moeten maken. Met een validerende DNS service zou enerzijds het gat dat de accessproviders laten liggen worden gevuld. Anderzijds zou daarmee een niet-commerciële tegenhanger van Google's Public DNS beschikbaar komen. Belangrijke meerwaarde daarbij is dat de privacy van de gebruikers dan wel volledig zou worden gewaarborgd.

Een van de uitkomsten van de pilot is dat deze validerende DNS-service niet zal worden uitgebouwd tot een volledige publieke dienst. Validatiefouten zijn allang geen probleem meer. Inmiddels zijn er meerdere grote aanbieders van publieke DNS-diensten. En het aantal providers dat DNSSEC-validatie aan zet groeit langzaam maar gestaag door.

Voor DNSSEC is een aantal nieuwe record-typen aan het originele DNS-protocol toegevoegd:

De eerste 4 record-typen zijn gedefinieerd in RFC 4034. Deze worden gebruikt voor het opbouwen van de cryptografische vertrouwensketen (chain of trust).

De NSEC3 en de NSEC3PARAM record-typen zijn gedefinieerd in RFC 5155. Deze worden gebruikt voor de NSEC3-beveiliging.

Daarnaast zijn er later nog verschillende andere record-typen toegevoegd voor uitbreidingen op het DNSSEC-protocol.

Naast de nieuwe record-typen waren voor DNSSEC ook belangrijke uitbreidingen op het originele DNS-protocol zelf nodig. De Extension Mechanisms for DNS (EDNS(0), gedefinieerd in RFC 6891) hebben de pseudo-RR OPT aan de 'additional data'-sectie toegevoegd, waarmee ruimte voor extra vlaggen en parameters beschikbaar kwam.

Om te beginnen kan een DNS-client nu aangeven wat het maximumaantal bytes is dat hij kan verwerken in zijn UDP-buffer. Daarmee is de pakketgrootte van DNS (responses) over UDP niet langer beperkt tot 512 bytes. Deze limiet was onderdeel van de DNS-specificatie en gebaseerd op de minimale grootte die IPv4 specificeert voor de UDP-buffer. Daarmee hoefden DNS-clients geen eigen UDP-buffer te implementeren. Heeft een client niet genoeg aan een afgebroken DNS-response, dan kan hij dezelfde query opnieuw naar de resolver sturen, maar dan over het inefficiëntere TCP-transportprotocol. Deze uitbreiding was nodig om ook de digitale handtekeningen (in de RRSIG-records) met de RRsets over UDP mee te kunnen sturen.

Daarnaast zijn voor DNSSEC de volgende 3 vlaggen gedefinieerd (waarvan de eerste in het OPT-pseudorecord):

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232

Let op dat je RRSIG-records op dezelfde manier kunt opvragen als traditionele DNS-records, maar dat je deze digitale handtekeningen niet moet gebruiken om eerder opgevraagde RRsets te valideren. Dat gaat (mogelijk) mis bij dynamische records waarbij de digitale handtekening on-the-fly gegenereerd wordt (waarbij de records een TTL van 1 hebben).

De basis van DNSSEC is gedefinieerd in deze 3 RFC's:

• RFC 4033: DNS Security Introduction and Requirements

• RFC 4034: Resource Records for the DNS Security Extensions

• RFC 4035: Protocol Modifications for the DNS Security Extensions

Met belangrijke aanvullingen, uitbreidingen en verduidelijking in deze RFC's:

• RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence [NSEC3]

• RFC 7583: DNSSEC Key Rollover Timing Considerations

• RFC 6781: DNSSEC Operational Practices, Version 2

• RFC 6840: Clarifications and Implementation Notes for DNS Security (DNSSEC)

• RFC 8499: DNS Terminology

De 'chain of trust' refereert naar de cryptografische keten van vertrouwen die middels DNSSEC wordt opgebouwd over de verschillende niveaus van de DNS-hiërarchie. Clients (resolvers) ontvangen van de DNS-server antwoorden voorzien van een digitale handtekening (in het RRSIG record). De authenticiteit van deze records kan gecontroleerd worden met behulp van de publieke sleutel voor dit domein (in het DNSKEY-record). Deze wordt door de domeinnaamhouder (via zijn registrar) één niveau hoger in de DNS-hiërarchie verankerd (door middel van het DS-record), waarmee deze schakel in de vertrouwensketen gesloten wordt.

Voor een .nl-domeinnaam staat de publieke sleutel dus op de systemen van SIDN, de beheerder van het .nl top-level domein. Deze levert via zijn nameservers desgevraagd een ondertekende hash-code (een digitaal uittreksel, in het DS-record) van de publieke sleutel voor de betreffende domeinnaam. Daarmee kan een resolver verifiëren dat de publieke sleutel die bij het ondertekende antwoord van de DNS-server past, inderdaad dezelfde sleutel is als de sleutel die eerder door de houder van de domeinnaam bij de beheerder van het hogerliggende domein is geregistreerd.

De publieke sleutel voor het .nl top-level domein is op zijn beurt weer ondertekend door de root (.). Op dit allerhoogste niveau wordt de basis gelegd voor al het vertrouwen in de keten daaronder. Wie de key signing ceremony voor het root-sleutelpaar bekijkt, ziet hoe serieus deze zaak wordt genomen.

Hieronder lopen we stapsgewijs door de cryptografische vertrouwensketen helemaal terug naar de root, bij de validatie van de naam www.example.nl:

• de naam www.example.nl zelf wordt gevalideerd door de bijbehorende digitale handtekening (in het RRSIG-record) te controleren met behulp van de publieke sleutel die in de vorm van een DNSKEY-record ook in de zone example.nl gepubliceerd wordt;

• de authenticiteit van de publieke sleutel (in het DNSKEY-record) in de zone example.nl is geborgd middels het afgeleide DS-record dat in de .nl-zone gepubliceerd wordt;

• de authenticiteit van het DS-record voor example.nl in de .nl-zone is geborgd middels de digitale handtekening in het bijbehorende RRSIG-record in de .nl-zone;

• de digitale handtekening in het RRSIG-record in de .nl-zone wordt gecontroleerd met behulp van de publieke sleutel die in de vorm van een DNSKEY-record ook in de .nl-zone gepubliceerd wordt;

• de authenticiteit van de publieke sleutel (in het DNSKEY-record) in de .nl-zone is geborgd middels het afgeleide DS-record dat in de root zone gepubliceerd wordt;

• de authenticiteit van het DS-record voor de nl-zone in de root zone is geborgd middels de digitale handtekening in het bijbehorende RRSIG-record in de root zone;

• de digitale handtekening in het RRSIG-record in de root zone wordt tenslotte gecontroleerd met behulp van de publieke sleutel die als well-known waarde in elke validerende resolver is geïnstalleerd als trust anchor.

DNSSEC maakt gebruik van digitale handtekeningen om de DNS-antwoorden van de name-server te ondertekenen. Tesamen met het ondertekende antwoord ontvangt de client ook de publieke sleutel voor dat domein. Daarmee kan hij verifiëren dat de handtekening onder een DNS-antwoord echt is. De authenticiteit van de publieke sleutel zelf kan weer gecontroleerd worden bij de name-server van het hogerliggende domein. Voor het domein sidn.nl zou dat dus de name-server voor het .nl-domein zijn. Deze levert desgevraagd een ondertekende hash code (een digitaal uittreksel) van de publieke sleutel.

De publieke sleutel voor het .nl-domein is op zijn beurt weer ondertekend door de root (.). Op dit allerhoogste niveau wordt de basis gelegd voor al het vertrouwen in de keten ('chain of trust') daaronder. Wie de key signing ceremony voor de root servers bekijkt, ziet hoe serieus deze zaak wordt genomen.

Voor het ondertekenen van een zone is in principe 1 cryptografisch sleutelpaar voldoende. De private key wordt gebruikt om de DNS-records te ondertekenen (in de RRSIG-protocol), en vervolgens op een goed beveiligde plaats bewaard. De public key wordt gepubliceerd in het DNSKEY-record zodat deze publiek beschikbaar is. Op die manier kan iedereen de handtekeningen onder de DNS-records controleren. Hetzelfde DNSKEY-record wordt via de registrar ook naar de beheerder van het hogerliggende domein gestuurd. Daar wordt deze door de beheerder ondertekend en als DS-record gepubliceerd. Deze handtekening bewijst dat de public key die in het DNSKEY-record staat echt is. En daarmee is deze schakel in de chain of trust' gesloten.

Het voordeel van deze configuratie is de relatieve eenvoud. Het nadeel is dat elke rollover een wijziging in de bovenliggende zone vereist, en dus een interactie met de beheerder daarvan.

In de praktijk wordt dan ook meestal met een cascade (dat wil zeggen: een hiërarchische serie) van 2 sleutelparen gewerkt:

Het ZSK-sleutelpaar (de Zone Signing Keys) wordt dan gebruikt om de DNS-records te ondertekenen en te valideren. Dit paar wordt in het algemeen per zone gegenereerd, zodat hij makkelijk vervangen of ververst kan worden. Bovendien kan een lichtere versleuteling worden gebruikt, zodat de lengte van de records beperkt blijft. In dit geval wordt de public key van het ZSK-paar niet naar de beheerder van het hogerliggende domein gestuurd, maar wordt deze ondertekend met de private key van het KSK-paar:

Het KSK-sleutelpaar (de Key Signing Keys) wordt alleen gebruikt om de DNSKEY-records te ondertekenen (inclusief zijn eigen publieke sleutel), niet voor de andere DNS-records. Een DNSKEY-record met daarin een publieke KSK-sleutel is te herkennen aan de gezette SEP-vlag (Secure Entry Point; zie RFC 3757). Alleen van dit KSK-paar wordt wordt de publieke sleutel naar de beheerder van de bovenliggende zone gestuurd voor publicatie als DS-record.

In een dergelijke gecascadeerde KSK/ZSK-configuratie hoef je bij vervanging van het ZSK-sleutelpaar nooit het nieuwe sleutelmateriaal naar de beheerder van de bovenliggende zone te sturen. Bovendien kan voor het KSK-paar sterkere versleuteling worden ingezet. Hoewel meestal voor elke zone afzonderlijk ook een eigen KSK-paar wordt aangemaakt, zijn er ook operators die hetzelfde KSK-paar voor meerdere zones gebruiken.

Omdat het gebruik van een KSK/ZSK-configuratie de standaard is, komt deze configuratie ook in veel RFC's terug, en wordt bij een enkelvoudig sleutelpaar van Combined Signing Keys (CSK) gesproken.

Hieronder kun je zien dat zowel de root zone als de .nl-zone gebruikmaken van DNSSEC-algoritme nummer 8 (RSA/SHA-256).

Beide sleutelparen voor de root zone hebben een sleutellengte (voor RSA) van 2048 bits (de sleutellengte voor het ZSK-sleutelpaar is in 2017 opgehoogd van 1024 naar 2048 bits, waardoor de 2 nu gelijk zijn).

De sleutellengte van het ZSK-sleutelpaar voor de .nl-zone staat nog op 1024 bits. SIDN wil het algoritme binnen niet al te lange tijd opwaarderen van nummer 8 naar nummer 13 (ECDSA-P256/SHA-256). We bespreken de voordelen van het gebruik van ECDSA-cryptografie hier.

https://images.ctfassets.net/yj8364fopk6s/1FCUMEZCWcKemYt4JXjLHY/604a9eca71b5740188ebf1ddf7dbc635/DNSViz-nl-2023-01-07-07_00_43-UTC.png

Cryptografisch materiaal gepubliceerd in het DNS-systeem kan niet zomaar worden vervangen door iets nieuws. Omdat DNSSEC-records net als alle andere DNS-records door de resolvers gecachet worden, moet je er rekening mee houden dat oude informatie nog een tijdje op internet gebruikt blijft worden (en wel zo lang als gespecificeerd in de TTL-waarde van de betreffende records).

Dat betekent dat er altijd een zogenaamde key rollover zal moeten plaatsvinden. Daarbij wordt eerst de nieuwe sleutel geïntroduceerd en gepropageerd, pas waarna de oude sleutel kan worden uitgefaseerd. Tijdens een rollover zullen er dus tijdelijk 2 (gedeeltelijke) sets van de DNSSEC-records naast elkaar gebruikt worden.

Key rollovers voer je typisch uit bij het vervangen van het cryptografische sleutelpaar, een verandering in de cryptografische parameters, of bij de verhuizing van een domeinnaam. Daarvoor zijn in principe 2 verschillende algoritmen beschikbaar (al kun je de eerste alleen gebruiken bij de vervanging van het sleutelpaar):

• de Pre-Publish Rollover, waarbij eerst het nieuwe sleutelpaar in gebruik genomen wordt (naast het oude sleutelpaar), en daarna de digitale handtekeningen worden vervangen; zijn die handtekeningen overal bekend (dat wil zeggen: ook de oude handtekeningen overal uit de caches verdwenen), dan kan het oude sleutelpaar opgeruimd worden

• de Double-Signature Rollover, waarbij eerst de nieuwe handtekeningen gepubliceerd worden (naast de oude handtekeningen), en daarna parallel aan de oude

  vertrouwensketen van beneden naar boven een nieuwe keten wordt opgebouwd; pas als de nieuwe vertrouwensketen in zijn geheel overal bekend is, kan de oude vertrouwensketen opgeruimd worden

Let op dat KSK- en ZSK-rollovers verschillend zijn: Een ZSK-rollover kun je geheel in eigen beheer en dus volledig geautomatiseerd uitvoeren, terwijl een KSK-rollover de registratie van nieuw sleutelmateriaal bij de bovenliggende zone vereist.

Bovendien kun je de Pre-Publish Rollover alleen gebruiken voor de vervanging van het sleutelpaar: De verhuizing van een DNSSEC-beveiligde domeinnaam verloopt via een specifiek verhuisprotocol gebaseerd op de Double-Signature Rollover. En voor de overstap naar een ander algoritme kun je alleen een Double-Signature Rollover gebruiken omdat je een nieuw algoritme alleen van onder naar boven (RRSIG – DNSKEY – DS) in de DNSSEC-vertrouwensketen kunt introduceren (hieronder in detail uitgelegd).

De Pre-Publish Rollover bestaat uit de volgende stappen:

• een nieuw sleutelpaar wordt gegenereerd;

• de nieuwe publieke sleutel wordt gepubliceerd in de vorm van een DNSKEY-record (naast het bestaande DNSKEY-record), tezamen met het afgeleide DS-record in de bovenliggende zone (naast het bestaande DS-record);

• zolang de oude vertrouwensketen nog volledig beschikbaar is voor validatie, is het geen probleem dat de RRSIG-records voor het nieuwe sleutelpaar nog ontbreken;

• na het verstrijken van het maximum van de TTL van het oude DNSKEY-record, en de TTL van het oude DS-record plus de refresh-tijd van de bovenliggende zone, weet je zeker dat zowel het nieuwe DNSKEY-record als het nieuwe DS-record overal beschikbaar zijn;

• de nieuwe private sleutel wordt nu gebruikt om nieuwe digitale handtekeningen

  te genereren in de vorm van RRSIG-records (ter vervanging van de bestaande RRSIG-records op basis van de oude private sleutel), waarmee de nieuwe vertrouwensketen compleet is;

• na het verstrijken van de TTL van de oude RRSIG-records weet je zeker dat nergens nog oude RRSIG-records aanwezig zijn;

• nu kan het oude DNSKEY-record worden verwijderd uit de zone, en het oude DS-record uit de bovenliggende zone;

waarmee de rollover is afgerond.

Let op dat we hier geen rekening hebben gehouden met:

• de propagatietijd van nieuwe records van een hidden (administratieve) master naar de publieke nameservers

• of met de tijd die de registry nodig heeft om de TLD-zone (met daarin de DS-records) te verversen

Rollovers met bijbehorende timing-overwegingen worden in detail besproken in respectievelijk RFC 6781 en RFC 7583 (secties 3.2 en 3.3).

De timing-aspecten van DNSSEC in bredere zin bespreken we uitgebreid in dit artikel.

De Double-Signature Rollover bestaat uit de volgende stappen:

• een nieuw sleutelpaar wordt gegenereerd

• de nieuwe private sleutel wordt gebruikt om nieuwe digitale handtekeningen

  te genereren in de vorm van RRSIG-records (naast de bestaande RRSIG-records), die samen met het nieuwe DNSKEY-record (ook naast het bestaande DNSKEY-record) in de zone worden gepubliceerd, net als het nieuwe bijbehorende DS-record (ook naast het bestaande DS-record) in de bovenliggende zone (hoewel je dit protocol-technisch gezien in 1 keer mag doen, zul je deze stappen in de praktijk niet tegelijkertijd maar achter elkaar uitvoeren)

• hoewel hiermee in 1 keer een complete vertrouwensketen parallel aan de bestaande vertrouwensketen wordt opgezet, moet de oude keten blijven bestaan zolang alle nieuwe RRSIG-, DNSKEY- en DS-records nog niet overal beschikbaar zijn (voor een geldige validatie moet tenminste 1 van de vertrouwensketens steeds compleet zijn)

• na het verstrijken van het maximum van de TTL van de oude RRSIG-records, de TTL van het oude DNSKEY-record, en de TTL van het oude DS-record plus de refresh-tijd van de bovenliggende zone, weet je zeker dat zowel de nieuwe RRSIG-records als de nieuwe DNSKEY- en DS-records overal beschikbaar zijn (en daarmee de complete nieuwe (parallelle) vertrouwensketen)

• (dit is het minimum; een langere wachttijd met marge is vanzelfsprekend geen probleem)

• nu kunnen de oude RRSIG-records en het oude DNSKEY-record uit de zone verwijderd worden, net als het oude DS-record uit de bovenliggende zone

waarmee de rollover is afgerond.

Let op dat we hier geen rekening hebben gehouden met:

• de propagatietijd van nieuwe records van een hidden (administratieve) master naar de publieke nameservers;

• of met de tijd die de registry nodig heeft om de TLD-zone (met daarin de DS-records) te verversen.

Rollovers met bijbehorende timing-overwegingen worden in detail besproken in respectievelijk RFC 6781 en RFC 7583 (secties 3.2 en 3.3).

De timing-aspecten van DNSSEC in bredere zin bespreken we uitgebreid in dit artikel.

De onderlinge voor- en nadelen van de Pre-Publish Rollover en de Double-Signature Rollover staan samengevat in onderstaande tabel:

DNSSEC ondersteunt meerdere cryptografische algoritmen. De rollover naar een ander algoritme verloopt precies zoals de Double-Signature Rollover naar een nieuw sleutelpaar. [BIND named]

Je kunt de overstap naar een nieuw sleutelpaar en een nieuw algoritme ook combineren in een enkele rollover. Omwille van de continuïteit raden we je echter aan om voor de overstap naar een ander algoritme niet je reguliere (geautomatiseerde) rollover-proces aan te passen, maar in dat geval een aparte rollover uit te voeren.

Let op dat je niet zomaar verschillende algoritmen door elkaar kunt gebruiken. RFC 6840 (sectie 5.11) formuleert een aantal beperkingen:

1. de DS- en DNSKEY-records zijn bepalend voor de algoritmen die gebruikt worden om de zone te ondertekenen:

2. een (ondertekende) zone moet een DNSKEY-record hebben voor elk algoritme (niet: elke sleutel!) dat in de DS-records voorkomt; let op dat dit niet andersom geldt: niet elke algoritme dat in de DNSKEY-records voorkomt moet ook in de DS-records voorkomen

3. een zone moet ondertekend zijn met elk algoritme (niet: elke sleutel!) dat in de DNSKEY-records voorkomt. Samen met de regel (2) hierboven betekent dit dat er wel RRSIG-records (en vervolgens DNSKEY-records) in de zone mogen voorkomen voor een algoritme dat niet in de DS-records voorkomt. Dit maakt een algoritme-overstap via een Double-Signature rollover mogelijk. Een overstap middels een Pre-Publish Rollover kan dus niet: je mag immers geen nieuw algoritme in de DNSKEY-records introduceren waarvoor (nog) geen RRSIG-records beschikbaar zijn.

4. kortom: voor elk algoritme (niet: elke sleutel!) gebruikt in de DS- en DNSKEY-records moet altijd een complete set handtekeningen (RRSIG-records) aanwezig zijn (signature completeness)

Hoewel de RFC de achterliggende rationale niet expliciet maakt, is het uitgangspunt van deze regels een compartimentering van de vertrouwensketen op basis van algoritmen. De vertrouwensketen is van boven (de root/parent) naar beneden (de delegaties) opgebouwd en alleen de aanwezigheid van een DS-record is bepalend voor het al dan niet ondertekend zijn van de zone. Daardoor kun je de ondertekening van een zone van onderaf opbouwen – eerst de RRSIG-records, dan het DNSKEY-record, en tenslotte het DS-record – en van algoritme wisselen op de knip tussen DNSKEY- en DS-record (waarbij je in feite van onderaf een nieuwe, parallelle ondertekening opbouwt).

Merk op dat deze regels allemaal geformuleerd zijn in termen van algoritmen en nergens beperkingen worden opgelegd aan de sleutelparen. Rollovers van de sleutelparen vinden dan ook plaats binnen de verschillende algoritmische compartimenten en kunnen op verschillende manieren uitgevoerd worden.

Voor de verhuizing van een ondertekend domein naar een andere operator/registrar – zonder daarbij de DNSSEC-beveiliging te onderbreken – is een speciale verhuisprocedure beschikbaar (goeddeels ontwikkeld door SIDN Labs [1, 2, 3, 4, 5] en opgenomen in RFC 6781). Uitgangspunt is dat nooit geheim sleutelmateriaal tussen de operators uitgewisseld hoeft te worden.

Dit proces komt neer op een Double-Signature Rollover verdeeld over de 2 betrokken operators:

• de nieuwe operator bouwt de nieuwe vertrouwensketen (bestaande uit RRSIG-records en het DNSKEY-record gebaseerd op zijn eigen sleutelpaar) compleet op; alleen het nieuwe DS-record wordt nog niet gepubliceerd in de TLD-zone;

• voordat de daadwerkelijke overdracht bij de registry (bestaande uit het omschakelen van de nameservers (NS-records) en het publiceren van het nieuwe DS-record) kan plaatsvinden:

  • zorgt de nieuwe operator dat de oude handtekeningen (in de RRSIG-records bij de oude operator) blijven werken, door ook het oude DNSKEY-record in de nieuwe zone file op te nemen (en deze te ondertekenen); het oude DNSKEY-record is gewoon beschikbaar via DNS;

  • zorgt de oude operator dat de nieuwe handtekeningen (in de RRSIG-records bij de nieuwe operator) ook werken met de bestaande DNSKEY-records, door het nieuwe DNSKEY-record in de oude zone file op te nemen (en deze opnieuw te ondertekenen); omdat de NS-records nog steeds naar de oude operator verwijzen kan dit niet via DNS; SIDN Labs heeft daarom een uitbreiding op het EPP-protocol ontwikkeld om sleutelmateriaal via de registry van de nieuwe naar de oude operator over te dragen [1, 2, 3] (inmiddels gestandaardiseerd als RFC 8063);

• na het verstrijken van het maximum van alle relevante TTL's, kan de daadwerkelijke overdracht bij de registry plaatsvinden:

  • de administratieve controle over het betreffende domein wordt overgedragen naar de nieuwe registrar;

  • daarbij worden gelijk de nameservers (NS-records) omgeschakeld van de oude naar de nieuwe operator;

  • en wordt gelijk het nieuwe DS-record in de TLD-zone gepubliceerd (naast het oude DS-record van de oude operator, dat nu standaard bewaard blijft bij de overdracht);

• na het verstrijken van het maximum van de TTL van de oude NS-records en de TTL van het oude DS-record, kan het oude DS-record door de nieuwe operator uit de TLD-zone verwijderd worden;

• na het verstrijken van de TTL van het oude DS-record, kan het oude DNSKEY-record uit de nieuwe zone file verwijderd worden;

waarmee de rollover is afgerond.

Waar nodig moeten nog eventuele propagatietijden van hidden naar publieke nameservers en refreshtijden van de TLD-zone worden toegevoegd.

Het verhuisproces is duidelijk beschreven en kan volledig geautomatiseerd worden (en is inmiddels in veel DNS-software geïmplementeerd).

Autorisatie van de nieuwe operator bij het aanbieden van het nieuwe DNSKEY-record loopt via het al bestaande verhuistoken.

Nadeel van deze methode is een afhankelijkheid van de TTL-waarde van het oude DNSKEY-record onder controle van de oude operator.

Let op dat bij gebruik van een tweevoudig sleutelpaar bij de verhuizing van een ondertekend domein de nieuwe operator hetzelfde cryptografische algoritme moet gebruiken als de oude operator. Dit is een gevolg van de eis (in RFC 6840, sectie 5.11) dat er voor elk algoritme gebruikt in de DNSKEY- en DS-records ook een ondertekening (RRSIG-records) gebaseerd op hetzelfde algoritme dient te zijn.

Om te voorkomen dat een operator/registrar na verloop van tijd allerlei verschillende algoritmen in zijn bestand heeft, kan hij na het voltooien van de verhuizing het algoritme van het betreffende domein rollen naar het algoritme van zijn voorkeur.

The typical intervals for refreshing digital signatures and rolling overKSK/ZSK key pairs are as follows:

Normaal gesproken geven nameservers alleen informatie aan een client die heel specifiek naar een bepaalde naam vraagt. Bestaat die naam niet, dan geeft een niet-beveiligde nameserver gewoon een foutmelding als antwoord: NXDOMAIN voor niet-bestaande namen, en NODATA voor niet-bestaande recordtypen van wel bestaande namen. Op die manier kan een buitenstaander nooit informatie krijgen over alle namen (systemen) binnen een domein. Dat kan immers informatie zijn die de veiligheid aantast.

Zo simpel werkt het niet voor DNSSEC-beveiligde domeinen: ook het antwoord (een NXDOMAIN/NODATA-foutmelding) voor een niet-bestaande naam moet immers van een digitale handtekening zijn voorzien. Omdat het natuurlijk onmogelijk is voor alle niet-bestaande namen op voorhand een ondertekende foutmelding te genereren, zou de ondertekening dan dynamisch moeten gebeuren. Daarmee zou DNSSEC niet alleen bijzonder processor-intensief worden maar ook kwetsbaar voor 'denial of service'-aanvallen.

NSEC (kort voor Next Secure, gedefinieerd in RFC 4034, sectie 4) is onderdeel van DNSSEC en was een eerste poging om dit probleem op te lossen. NSEC maakt het mogelijk om ook DNS-antwoorden voor niet-bestaande records van een digitale handtekening te voorzien: een zogenaamde 'authenticated denial of existence'.

Daarbij specificeert elk NSEC-record echter geen specifieke niet-bestaande naam, maar de ruimte die tussen twee wel bestaande namen in zit. Vraag je bijvoorbeeld om een A-record voor de niet-bestaande naam charlie.example.nl, dan krijg je een NSEC-record terug dat aangeeft dat er geen namen zitten tussen de wel bestaande namen bravo.example.nl en delta.example.nl. Deze NSEC-records worden aangemaakt en ondertekend bij het ondertekenen van je zone (waarmee de grootte daarvan grofweg verdubbelt). Een validerende resolver die een niet-bestaande naam opvraagt, krijgt dus een ondertekend NSEC-record terug voor het interval waarin ook de door hem opgevraagde naam zich bevindt. En daarmee weet de resolver zeker dat de betreffende naam niet bestaat.

Hierbij moeten we gelijk aantekenen dat het zojuist beschreven mechanisme het uitgangspunt is. In dit artikel kun je bijvoorbeeld lezen hoe Cloudflare verschillende slimmigheidjes heeft bedacht om NSEC(3)-records te generen voor hun dynamische zones (waarbij DNS-antwoorden on-the-fly worden gegenereerd uit een database).

Het probleem van NSEC is dat het heel eenvoudig wordt om alle namen in een zone te achterhalen. Door het slim opvragen van niet-bestaande namen kun je immers alle NSEC-records verzamelen – deze vormen een gelinkte lijst – waarmee je ook alle intervalgrenzen (dat wil zeggen: de wel bestaande namen) op een rijtje hebt. Deze 'zone walking' of 'zone enumeration' is in veel gevallen om veiligheidsredenen ongewenst.

NSEC3 (gedefinieerd in RFC 5155) is onder andere bedacht om het 'zone walking'-veiligheidsprobleem van NSEC tegen te gaan. Daarbij worden niet de namen zelf gebruikt maar alleen hun hashes (in dit geval: een digitale verhaspeling). Een client die een niet-bestaande naam opvraagt, krijgt nu een ondertekend NSEC3-record terug voor het interval van hashes waarin ook de hash van de betreffende naam valt.

De manier waarop dit werkt is dat de NSEC-intervalgrenzen in de zone eerst gehasht worden en pas daarna in volgorde gezet voor ondertekening. Een client die een NSEC3-record valideert doet dat dus door niet de naam zelf te controleren maar door de hash daarvan te genereren en te controleren dat die hash binnen de grenzen van het NSEC3-record valt. Door het gebruik van hashes kan niet zomaar meer een lijst met bestaande namen worden gemaakt.

Om te voorkomen dat iemand alsnog alle namen in je zone achterhaalt met behulp van een dictionary-tabel (waarin de hashes van alle veelgebruikte labels eerder al uitgerekend zijn), wordt nog een salt aan elke naam toegevoegd en een extra aantal slagen (iteraties) voor het uitvoeren van de hash-functie. Deze instellingen zijn hetzelfde voor de hele zone en worden in het NSEC3PARAM-record gepubliceerd. Door de salt (niet meer dan een random string) regelmatig te veranderen voorkom je dat iemand een herbruikbare dictionary-tabel voor je zone kan opbouwen.

Achtergrondinformatie over de werking (en historie) van NSEC en NSEC3 vind je in RFC 7129.

NSEC3 is (als opvolger van NSEC) aan DNSSEC toegevoegd om ondertekende zones te beschermen tegen inventarisatie door kwaadwillenden (door middel van 'zone walking'). Deze beveiliging lijkt in zijn huidige vorm inmiddels echter achterhaald: NSEC3 is complex en biedt niet langer afdoende bescherming tegen het originele probleem. Daarnaast is de cryptografie niet goed doordacht.

Om te beginnen zijn veel hostnamen (www, mx1, api, etc.) niet geheim. Zo slaagden onderzoekers er al in 2014 in om twee derde van de NSEC3-beveiligde domeinen binnen de .com-zone te achterhalen. Op een enkele grafische processor (GPU) duurde dat slechts 4,5 dag.

Bovendien maakt een aantal extra iteraties op de hash het mechanisme niet fundamenteel sterker. Voor de additionele hash-berekeningen zullen zowel krakers als validerende resolvers met grote aantallen gebruikers als ondertekenaars van grote zones "gelijkopgaande" extra rekenkracht moeten inzetten. Ook het gebruik van de salt lijkt in de meeste gevallen overbodig: de hashes worden berekend over de volledige domeinnaam (FQDN), wat betekent dat een dictionary-tabel sowieso al uniek zou zijn voor een specifieke zone. Het snel doorrollen van het gebruikte salt levert daarbij maar een beperkte extra hindernis op; uitgaande van een relatief stabiele zone blijven de meeste al gevonden labels gewoon geldig.

Deze inzichten hebben geleid tot de totstandkoming van RFC 9276. Deze raadt operators van autoritatieve nameservers nu aan om NSEC3 alleen te gebruiken als de bescherming daarvan inderdaad nodig is, en anders gewoon NSEC te gebruiken. Daarnaast wordt aangeraden bij gebruik van NSEC3 de extra iteraties op nul ('0') te zetten en de salt leeg te laten ('-'):

example.nl.    IN    NSEC3PARAM    1 0 0 -

DNSSEC-algoritmen nummer 6 (DSA-NSEC3-SHA1) en hoger zijn geschikt voor NSEC3.

Merk op dat algoritme nummer 5 (RSA/SHA-1) cryptografisch hetzelfde is als nummer 7 (RSASHA1-NSEC3-SHA1), alleen mag die eerste geen NSEC3-records bevatten. Hetzelfde geldt voor algoritme nummer 3 (DSA/SHA1) en nummer 6 (DSA-NSEC3-SHA1). Bij de introductie van NSEC3 werden nieuwe nummers/namen toegekend aan de 2 toen gebruikte cryptografische algoritmen (nummer 3 en 5). Deze zogenaamde aliassen (nummer 6 en 7) geven naar de resolvers aan dat de betreffende cryptografische algoritmen met NSEC3 gecombineerd kunnen worden.

Zo werd backward compatibility verkregen met bestaande resolvers die wel valideerden (tot en met algoritme nummer 5, wat destijds de hoogste was) maar niet met NSEC3 overweg konden (zoals beschreven in RFC 5155, sectie 2). Omdat de DNSSEC-standaard voorschrijft dat validerende resolvers algoritmen die ze niet herkennen moeten negeren (en dus niet blokkeren), leverde deze aanpak destijds een probleemloze introductie van NSEC3 in het bestaande DNSSEC-landschap op.

Vanaf algoritme nummer 8 (RSASHA256) is de ondersteuning van NSEC3 door resolvers verplicht (zie RFC 5702, sectie 5.2) en wordt er dus ook geen onderscheid meer gemaakt tussen algoritmen die wel en geen NSEC3 ondersteunen.

In het geval van een vraag om niet-bestaande DNS-records, voorziet NSEC(3) het antwoord van een digitale handtekening. Deze zogenaamde 'authenticated denial of existence' bewijst cryptografisch aan een validerende resolver dat het betreffende record er echt niet is.

Net als andere DNS-antwoorden hebben ook NSEC(3)-antwoorden een bepaalde (resterende) geldigheidsduur, welke het aantal seconden aangeeft dat een antwoord (nog) in de resolver caches bewaard mag worden. Startpunt voor deze TTL-waarde (de Time To Live) is in dit geval het MINIMUM-veld in het SOA-record van de betreffende zone (volgens RFC's 4034 en 5155).

Dat verschilt echter van de manier waarop de TTL voor traditionele, niet-ondertekende DNS-antwoorden wordt bepaald. Daarbij wordt gekeken naar zowel de MINIMUM-waarde in het SOA-record als de TTL van het SOA-record zelf, en de laagste waarde van die twee wordt gebruikt.

Dat betekent dat een (ondertekend) NSEC(3)-record een hogere TTL kan meekrijgen dan een niet-ondertekende NXDOMAIN/NODATA-foutmelding (namelijk als het MINIMUM-veld hoger is dan de TTL van het SOA-record). En dat is onwenselijk.

RFC 8198, die een optimalisatie definieert voor de implementatie van de cache van validerende resolvers, deed een eerste poging om de afwijkende TTL-waarden van NSEC(3)-antwoorden in lijn te brengen met de specificatie voor niet-ondertekende 'denial of existence'-antwoorden, maar deze liet toch nog teveel ruimte voor discussie. Bovendien beperkte deze RFC zich tot een specifieke toepassing.

De onlangs gepubliceerde RFC 9077 biedt een structurele oplossing voor genoemde discrepantie. Deze RFC brengt de twee verschillende specificaties in lijn door de TTL voor NSEC(3)-antwoorden op exact dezelfde manier te definiëren als die voor traditionele, niet-ondertekende 'denial of existence'-antwoorden.

Voor het downloaden, controleren en updaten van het DNSSEC trust anchor zijn speciale procedures en protocollen ontwikkeld. Deze zijn met name relevant voor ontwikkelaars en operators van resolver-software. Ze zijn in het bijzonder actueel bij de overstap naar een nieuw trust anchor (onderdeel van de root-KSK rollover).

Het trust anchor is well-known; voor de handmatige (out-of-band) authenticatie ervan is een speciale procedure en tooling beschikbaar. Maar er is ook een protocol om de update van het trust anchor automatisch te laten verlopen, en wel volgens RFC 5011 (die we gelijk hieronder bespreken).

In de praktijk zal een nieuw trust anchor voor de meeste systemen echter met de software-updates van het operating system meekomen. Vandaar ook dat er zoveel te doen is omtrent de veiligheid van IoT-devices en andere kleine apparaatjes die wel op internet aangesloten worden maar zeer waarschijnlijk nooit een software-update zullen ontvangen.

RFC 5011 definieert een protocol waarmee validerende resolvers zonder tussenkomst van een beheerder nieuwe trust anchors in gebruik kunnen nemen en oude trust anchors kunnen uitfaseren. Dat betekent dat deze resolvers een volledige roll-over van het root KSK-sleutelpaar automatisch kunnen volgen. Na de (eerste) root-KSK rollover in 2017/2018 wordt RFC 5011 door vrijwel alle validerende resolvers ondersteund.

Een automatische update van het trust anchor begint met het ophalen van de nieuwe publieke sleutel in de vorm van een DNSKEY-record van een authoritatieve server voor de root zone (of een ander trust point). Omdat dit record is voorzien van een digitale handtekening verankerd op het oude, al vertrouwde trust anchor, kan de resolver de authenticiteit ervan gewoon met behulp van de bestaande DNSSEC-functionaliteit valideren (in-band). De resolver herkent een geldige KSK-sleutel aan de gezette SEP-vlag (Secure Entry Point; zie RFC 3757) in het DNSKEY-record. Dit alles betekent wel dat de resolver regelmatig de root zone moet bevragen om te zien of er nieuwe (KSK) DNSKEY-records beschikbaar zijn.

RFC 5011 schrijft voor dat een nieuwe publieke KSK-sleutel uit veiligheidsoverwegingen op zijn vroegst 30 dagen na zijn verschijning (de Hold-Down periode) aan de trust anchors mag worden toegevoegd. In de tussentijd moeten resolvers minstens elke twee weken controleren of die nieuwe sleutel er inderdaad nog steeds staat. Op die manier wordt een veiligheidsmarge ingebouwd en een manier om een root-KSK rollover voortijdig af te breken in geval van problemen.

Is de daadwerkelijke roll-over eenmaal afgerond, dan kan de oude publieke sleutel op zijn beurt uit de lijst van trust anchors op de resolvers worden gehaald door de REVOKE-vlag van het betreffende DNSKEY-record te zetten. Deze al eerder bestaande optie wordt dus niet meer alleen gebruikt voor het ongeldig verklaren van onveilige sleutelparen maar nu ook voor het opruimen van verlopen sleutelparen.

Omdat deze methode geheel en al rust op de aanwezigheid van een vertrouwde publieke sleutel aan resolver-zijde, werkt deze alleen voor systemen die al een trust anchor geïnstalleerd hebben. Vandaar dat de meeste ontwikkelaars van resolver-software de actuele trust anchors standaard meeleveren als hard-gecodeerd onderdeel van hun pakket.

Om de vertrouwensketen van een ondertekende zone te sluiten, moet de (nieuwe) publieke sleutel in de vorm van een DS-record (die een hash-waarde bevat) gepubliceerd worden in de bovenliggende zone. Het aanmelden van een dergelijke sleutel voor publicatie moet nu meestal met de hand gebeuren (out-of-band), typisch door het invullen van een DNSKEY/DS-record in een web-interface, meestal op dezelfde plek waar ook de autoritatieve name-servers (NS-records) beheerd worden. Inmiddels is er echter ook een mechanisme om updates van DS-records in de bovenliggende zone automatisch te laten verlopen.

RFC 8078 definieert een protocol waarmee autoritatieve nameservers zonder tussenkomst van een beheerder nieuwe DS-records in de bovenliggende zone kunnen laten opnemen. Het gaat om een relatief nieuw protocol dat nog maar beperkt ondersteund en ingezet wordt.

Om dit protocol te gebruiken, publiceer je nieuwe publieke sleutels als CDNSKEY- en/of CDS-record (Child DNSKEY/DS) in je eigen zone. Eens in de zoveel tijd scant de beheerder van de bovenliggende zone (of de registrar) de onderliggende (gedelegeerde) zones om te zien of er nieuwe sleutels beschikbaar zijn.

Omdat bij het overnemen van het nieuwe sleutelmateriaal vertrouwd wordt op de digitale handtekening onder de CDNSKEY/CDS-records, werkt deze methode alleen voor gedelegeerde zones die al met DNSSEC beveiligd zijn (in-band). Dat betekent dat het sleutelmateriaal de eerste keer (waarbij er nog geen gesloten vertrouwensketen bestaat) altijd nog met de hand geüpload moet worden (hoewel RFC 8078 ook een paar (semi-geautomatiseerde) alternatieven schetst).

Om (alle) DS-records uit de bovenliggende zone te laten verwijderen, kan een CDNSKEY/CDS-record met nulwaarden gepubliceerd worden.

Hiermee biedt dit protocol een vergelijkbaar mechanisme voor het uitwisselen van sleutelmateriaal tussen parent en child zones als RFC 5011, maar dan in omgekeerde richting (complementair).

DNS spoofing of DNS cache poisoning is een aanval waarbij valse DNS-informatie in een resolver wordt geïnjecteerd om autoritatieve DNS-informatie te vervangen.

Het doel is om gebruikers (of systemen) om te leiden naar een vals adres, bijvoorbeeld naar een vervalste website, om op die manier waardevolle of vertrouwelijke informatie te bemachtigen. Denk dan aan paswoorden (en andere credentials) en persoonlijke gegevens (voor identiteitsdiefstal), of aan geautomatiseerde man-in-the-middle (MITM)-aanvallen via een vervalst front-end.

Een ander doel is misleiding, waarbij bezoekers gemanipuleerd worden tot bepaald gedrag, bijvoorbeeld via valse beursberichten en nepnieuws.

De traditionele 'cache poisoning'-aanval probeert valse DNS-informatie in een caching resolver te injecteren door grote hoeveelheden valse antwoorden op die resolver af te vuren. Daarbij maakt de aanvaller gebruik van het feit dat binnen DNS-berichten maar 65.536 verschillende transaction ID's beschikbaar zijn. Deze 16-bits nummers worden door de client (de resolver) en de DNS-server gebruikt om vragen en antwoorden aan elkaar te koppelen. Door de transaction ID te variëren was het een kwestie van tijd voordat het valse antwoord met het juiste ID bij de resolver arriveerde net wanneer deze de "bijbehorende" vraag had uitstaan. Dan accepteerde de resolver dat valse antwoord, en werd het later volgende echte antwoord genegeerd. DNS-vragen en -antwoorden worden immers zo veel mogelijk over het stateless UDP-protocol verstuurd.

Een provisorische oplossing voor dit probleem werd gevonden door de UDP-poort van de resolver steeds te laten variëren (Source Port Randomization, beschreven in RFC 5452). Omdat de aanvaller nu niet meer weet vanaf welke poort een uitgaande vraag afkomstig zal zijn, moet hij nog eens 65 duizendmaal zoveel valse DNS-antwoorden sturen om ook alle mogelijke poorten van de client te bestoken. Daarmee is deze aanval niet langer haalbaar.

In de diagrammen hieronder kun je zien dat maar 1 procent van de resolvers (wereldwijd) die de autoritatieve servers voor .nl bevragen een te lage Source Port Randomization heeft. De helft van de Nederlandse resolvers met zo’n slechte score is van Microsoft.

https://images.ctfassets.net/yj8364fopk6s/5aIexdEhPoKrhp2ox46efC/bd8d37f9800b52b80062cfa2f89c2150/stats.sidnlabs.nl-SourcePortRandomization-20220809.png

https://images.ctfassets.net/yj8364fopk6s/6cL3wHHh3P1b3w5pD5wY9b/63575373321354e64c612d37413fbf0d/stats.sidnlabs.nl-SourcePortRandomizationNL-20220809.png

De hierboven beschreven 'cache poisoning'-aanval was in de praktijk lastig uit te voeren. De kans dat je in die korte tijdsspanne het juiste DNS-antwoord wist te genereren was klein. Vervolgens moest je uren of soms dagen wachten – tot de TTL (Time To Live) van het betreffende record in de cache verstreken was – voordat je het weer opnieuw kon proberen. Een aanvaller kan immers alleen op het moment dat de betreffende DNS-vraag daadwerkelijk uitstaat richting de autoritatieve DNS-server de resolver met valse DNS-antwoorden bestoken. In 2008 wist Dan Kaminsky deze beperking slim te omzeilen, waarmee elke resolver die geen Source Port Randomization gebruikte kwetsbaar was.

Waar inbreuken op het originele DNS-protocol voorheen alleen theoretisch van aard waren, toonde Dan Kaminsky in 2008 een echt gat in het DNS-ontwerp aan. Daarmee konden kwaadwillenden daadwerkelijk valse informatie in de caches van de meest gebruikte DNS-servers injecteren.

Een Kaminksy-aanval bestaat uit twee stappen: Als je het domein www.example.nl wilt aanvallen, begin je om de resolver te vragen naar bijvoorbeeld de domeinnaam 000001.example.nl. Tegelijkertijd stuur je gespoofde valse DNS-antwoorden op die resolver af met daarin NS-records die naar een valse autoritatieve nameserver verwijzen. Komt het echte antwoord eerder aan, dan hoef je niet te wachten tot de TTL (Time To Live) van dat antwoord in de cache van de resolver is verstreken, maar kun je gelijk hetzelfde proberen voor de domeinnaam 000002.example.nl. Dat doe je net zo lang totdat jouw valse antwoord is geaccepteerd. Pas daarna vraag je de resolver om de domeinnaam www.example.nl, waarna deze via de valse NS-records in de cache op normale wijze een vals antwoord zal krijgen van de valse autoritatieve name server.

Een structurele oplossing voor dit type aanvallen zit natuurlijk in het gebruik van DNSSEC-validatie. Een validerende resolver zal die valse informatie (op applicatieniveau) immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

Na de publicatie van de Kaminsky-aanval in 2008, was het lange tijd relatief rustig geweest aan het DNS-front. Maar in november 2020 kwam de veiligheid van DNS weer groot in het nieuws met de publicatie van de 'SAD DNS'-aanval. De ontdekkers maakten gebruik van een nieuw side-channel om valse DNS-informatie in een caching resolver te injecteren – vandaar ook de naam 'Side channel AttackeD DNS'. Volgens de ontdekkers was initieel een derde van alle caching resolvers kwetsbaar voor deze 'DNS cache poisoning'-aanval, net als de meerderheid van de grote publieke DNS-diensten.

SAD DNS maakt misbruik van de 'Rate Limiting'-bescherming voor ICMP-berichten – ingebouwd in alle netwerk-stacks – om de (momentane) uitgaande UDP-poort van de resolver te achterhalen. Staat die limiet bijvoorbeeld ingesteld op maximaal 1.000 berichten per seconde (zoals bij Linux), dan kan een aanvaller alle 65 duizend UDP-poorten in blokken van 1.000 stuks testen om te zien in welk blok precies de uitgaande poort zich bevindt. Daartoe stuurt hij eerst 1.000 valse DNS-responses vanaf gespoofde IP-adressen naar alle poorten in het betreffende blok. De ICMP-foutmeldingen gaan verloren (vanwege de spoofing van het afzenderadres). Maar als de aanvaller binnen diezelfde ene seconde vervolgens nog een 1.001-ste bericht stuurt vanaf zijn echte IP-adres en daarop toch nog een laatste ICMP-response terugkrijgt, dan weet hij dat de juiste poort binnen die reeks van 1.000 poorten ligt. Anders was die limiet van 1.000 ICMP-foutmeldingen binnen die seconde immers al bereikt geweest.

Met het achterhalen van de (momentane) uitgaande UDP-poort van de resolver wordt de Source Port Randomization (de originele oplossing tegen de klassieke 'DNS cache poisoning'-aanval en de Kaminsky-aanval) tenietgedaan. Is deze poort bekend, dan blijven immers alleen de 65 duizend verschillende transaction ID's over om te proberen bij het injecteren van valse DNS-informatie (door middel van een Kaminsky-achtige aanval). In hun publicatie beschrijven de onderzoekers hoe ze het window waarin een complete aanval moet worden uitgevoerd ook nog eens weten te verlengen van enige tientallen milliseconden tot vele tientallen seconden.

De beste manier om dit specifieke probleem op te lossen was de toevoeging van een flinke dosis randomness aan die hard ingestelde limiet van 1.000 ICMP-berichten per seconde.

Een structurele oplossing voor dit type aanvallen zit natuurlijk in het gebruik van DNSSEC-validatie. Een validerende resolver zal die valse informatie immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

Eind 2021, precies een jaar na de publicatie van de eerste 'SAD DNS'-aanval op het DNS-systeem, kwam dezelfde onderzoeksgroep met een nieuwe 'cache poisoning'-aanval. Deze methode werkt conceptueel hetzelfde als de vorige, vandaar dat deze aanval nu de naam SAD DNS 2.0 heeft meegekregen. Volgens de onderzoekers zijn vooral Linux-systemen kwetsbaar voor deze aanval, net als veelgebruikte DNS-software als BIND, Unbound en dnsmasq (allemaal op Linux). Van de grote publieke DNS-diensten bleek de helft kwetsbaar, waaronder OpenDNS (van Cisco) and Quad9 (9.9.9.9).

Net als de eerste 'SAD DNS'-aanval bouwt ook SAD DNS 2.0 voort op de in 2008 gepubliceerde Kaminksy-aanval. Daarbij worden op slimme wijze zowel DNS-queries als gespoofde valse DNS-antwoorden naar een caching resolver gestuurd, met als doel om die valse DNS-informatie in de betreffende resolver te injecteren. Een dergelijke 'DNS cache poisoning'-aanval wordt tegengegaan door middel van Source Port Randomization (gedefinieerd in RFC 5452). Daarbij laat men de uitgaande UDP-poort van de resolver variëren voor elke query, wat het spoofen van valse DNS-antwoorden praktisch onmogelijk maakt.

De eerste 'SAD DNS'-aanval deed de bescherming van de Source Port Randomization teniet door de momentane (ephemeral) uitgaande UDP-poort te achterhalen. De truc daarbij was om het aantal ICMP-berichten in reactie op gespoofde DNS-responses (indirect) te tellen. We beschrijven deze aanvalsmethode hier in meer detail.

Ook deze nieuwe 'SAD DNS'-aanval draait om het achterhalen van de momentane uitgaande UDP-poort van de resolver, maar doet dat via andere side channels. Bij deze laatste variant hebben de onderzoekers verschillende 'side channel'-aanvallen ontwikkeld op basis van 'ICMP frag needed'- en 'ICMP redirect'-berichten. Deze 'ephemeral port scanning'-methode stuurt een serie gespoofde ICMP-berichten op de resolver af en checkt vervolgens of daarbij de ephemeral poort geraakt is. Op Linux leidt een geldig ICMP-bericht tot een aanpassing in de zogenaamde 'next hop exception cache' (onderdeel van de netwerk-stack). En of dat laatste inderdaad heeft plaatsgevonden, kun je bijvoorbeeld weer controleren door een eenvoudig ping-bericht naar de betreffende resolver te sturen.

Is de momentane uitgaande UDP-poort achterhaald, dan wordt weer een Kaminsky-achtige aanval ingezet om de DNS transaction ID's te brute-forcen.

Daarbij kunnen ook aanvullende technieken worden ingezet om het verzenden en de goede aankomst van het correcte antwoord afkomstig van de echte autoritatieve nameserver te frustreren, om zo het window voor valse DNS-antwoorden te vergroten. Deze trucs waren al beschreven bij de publicatie van de eerste 'SAD DNS'-aanval.

Uit tests met deze ICMP/UDP-gebaseerde 'side channel'-aanvallen blijkt dat kwetsbare resolvers al binnen een paar minuten van valse DNS-informatie konden worden voorzien.

De onderzoekers zetten een aantal maatregelen tegen deze nieuwe 'SAD DNS'-variant op een rij, maar noemen DNSSEC als primaire verdediging tegen 'cache poisoning'-aanvallen. Een validerende resolver zal die valse informatie immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

Waar inbreuken op het originele DNS-protocol voorheen alleen theoretisch van aard waren, toonde Dan Kaminsky in 2008 een echt gat in het DNS-ontwerp aan. Daarmee konden kwaadwillenden daadwerkelijk valse informatie in de caches van de meest gebruikte DNS-servers injecteren.

Na de publicatie van de Kaminsky-aanval was het lange tijd relatief rustig aan het DNS-front. Maar in november 2020 kwam de veiligheid van DNS weer groot in het nieuws met de publicatie van de 'SAD DNS'-aanval. De ontdekkers maakten gebruik van een nieuw side-channel om valse DNS-informatie in een caching resolver te injecteren.

En precies een jaar later kwam dezelfde onderzoeksgroep met een nieuwe 'cache poisoning'-aanval. Deze methode werkt conceptueel hetzelfde als de vorige, vandaar dat deze aanval nu de naam SAD DNS 2.0 heeft meegekregen.

Deze recente aanvalsmethoden draaien om het achterhalen van de momentane uitgaande UDP-poort van de resolver. Daarmee wordt de bescherming van de Source Port Randomization, de originele oplossing tegen de klassieke 'DNS cache poisoning'-aanval en de Kaminsky-aanval, tenietgedaan.

DNSSEC biedt een structurele oplossing voor dit type aanvallen. Een validerende resolver zal die valse informatie immers nooit accepteren als deze niet van de juiste digitale handtekening is voorzien.

Na de publicatie van de Kaminsky-aanval in 2008, was het lange tijd relatief rustig aan het DNS-front. Maar in november 2020 kwam de veiligheid van DNS weer groot in het nieuws met de publicatie van de 'SAD DNS'-aanval, een jaar later gevolgd door de 'SAD DNS 2.0'-aanval. Alle drie typen aanvallen betroffen 'cache poisoning'-aanvallen.

In maart 2024 werd een ernstige kwetsbaarheid in de DNSSEC-specificatie zelf gepubliceerd. De kwetsbaarheid met de naam KeyTrap maakte het mogelijk om vanaf een DNS-server een Denial-of-Service (DoS)-aanval uit te voeren op een validerende resolver. Omdat het een probleem in de specificatie zelf betrof, waren alle veelgebruikte DNS-resolvers en -diensten aangedaan. Het gat was bovendien zo ernstig dat er pas over gepubliceerd kon worden na reparatie.

De KeyTrap-kwetsbaarheid [technisch rapport] werd eind 2023 ontdekt door onderzoekers van het Duitse National Research Center for Applied Cybersecurity (ATHENE). De oorzaak van het probleem is echter al meer dan 20 jaar oud: het vind zijn oorsprong in RFC 2535, in 1999 gepubliceerd als de eerste versie van de moderne DNSSEC-beveiliging. Via de opvolgers van deze RFC kwam de kwetsbaarheid terecht in de implementaties van BIND9, Unbound, PowerDNS en andere resolver-software.

De oorsprong van de KeyTrap-kwetsbaarheid zit in wat de onderzoekers "eager validation of signatures and of keys" noemen. Validerende resolvers moeten volgens de DNSSEC-standaard alle aangeboden handtekeningen (in een RRSIG-record) en alle bijbehorende publieke sleutels (in een DNSKEY-record) evalueren, net zolang tot ze een geldige ondertekening voor het betreffende DNS-record hebben gevonden. Uiteraard is dit gedaan om het DNSSEC-mechanisme zo robuust mogelijk te maken. De gelijktijdige publicatie/overlap van meerdere handtekeningen en meerdere publieke sleutels is ook een veelvoorkomend verschijnsel, dat optreedt bij elke herondertekening en rollover.

Het gaat mis bij de key tag, een 16-bits identificatie om de verschillende sleutelparen van elkaar te onderscheiden. Daarmee kan de resolver gelijk de juiste publieke sleutel pakken bij de evaluatie van een handtekening. Hoewel de key tag (pseudo-)random wordt gegenereerd – RFC 4034, appendix B schrijft een eenvoudige checksum voor – is deze niet afgedwongen uniek. Dat betekent dat 'key tag collissions' gewoon legaal kunnen voorkomen.

Een kwaadwillende kan deze vrijheid nu misbruiken door een DNS-record te publiceren met daarbij een hele rits handtekeningen van hetzelfde cryptografische type in combinatie met een hele rits sleutels die allemaal dezelfde key tag hebben. Als alle handtekeningen ongeldig zijn, zal de resolver dus eerst alle beschikbare handtekeningen voor alle beschikbare sleutels moeten evalueren alvorens tot die conclusie te mogen komen.

Omdat cryptografische operaties veel verwerkingskracht kosten – en dat geldt in het bijzonder voor de validatie van ECDSA-gebaseerde handtekeningen – zet deze combinatie de resolver dus flink aan het rekenen totdat alle combinaties geprobeerd zijn. Al die tijd kan de resolver nauwelijks of geen andere dingen doen, met een Denial-of-Service als resultaat . Een validerende resolver op hardware met beperkte verwerkingskracht bleek op deze manier wel 16 uur lang beziggehouden te kunnen worden.

Vanwege het gemak waarmee grote delen van Internet aangevallen konden worden, spraken betrokkenen van "de grootste kwetsbaarheid van DNS ooit ontdekt". Op hun bewering dat dit beveiligingsgat 25 jaar onopgemerkt bleef, blijkt echter wel wat af te dingen: In 2019 publiceerde Dex Bleeker over precies ditzelfde probleem. Hij optimaliseerde zijn sleutels echter niet voor maximale impact, waarmee hij wel een verhoogde load zag maar de resolver niet platlegde. [1]

DNSSEC beschermt alleen de authenticiteit van DNS-informatie. Dat wil zeggen dat de digitale handtekening garandeert dat de DNS-antwoorden zoals die bij de (validerende) client aankomen overeenkomen met de informatie op de autoritatieve nameservers. Zowel de queries als de responses zelf zijn echter niet versleuteld en kunnen tijdens het transport door "iedereen" gelezen worden. DNSSEC biedt dus geen vertrouwelijkheid.

Daarnaast bevatten de meeste clients zelf alleen een stub resolver en laten de recursieve queries – en daarmee de validatie – over aan de caching DNS-servers die ze via DHCP of NDP van de access-provider of netwerkbeheerder toegewezen krijgen. Meestal blijft dus het traject tussen de stub resolver en de DNS-server – de zogenaamde 'Last Mile' – onbeveiligd.

DoT, DoH en DoQ zijn alle 3 uitbreidingen van het DNS-systeem die wel het (end-to-end) transport van DNS-informatie beschermen. Ze zijn echter relatief nieuw en worden nu vooral gebruikt op applicatieniveau (in de webbrowsers).

DoT (DNS over TLS) is (net als DoH en DoQ) een uitbreiding van het DNS-systeem die het transport van DNS-informatie beschermt. Deze beveiligingsstandaard is relatief nieuw en wordt nu vooral gebruikt op applicatieniveau (in de webbrowsers).

De naam van de standaard geeft precies weer wat deze beveiligingstechnologie doet: de client bouwt eerst een cryptografisch beveiligde TLS-verbinding op, waarover vervolgens de DNS-queries en -responses worden getransporteerd. Daarmee is ook de vertrouwelijkheid en de 'Last Mile' van het DNS-transport beschermd (DNSSEC beschermt alleen de authenticiteit van de DNS-informatie). DoT is dus geen vervanger voor DNSSEC, maar complementair daaraan.

DoH (DNS over HTTPS) is (net als DoT en DoQ) een uitbreiding van het DNS-systeem die het transport van DNS-informatie beschermt. Deze beveiligingsstandaard is relatief nieuw en wordt nu vooral gebruikt op applicatieniveau (in de webbrowsers).

De naam van de standaard geeft precies weer wat deze beveiligingstechnologie doet: de client bouwt eerst een cryptografisch beveiligde HTTPS-verbinding op, waarover vervolgens de DNS-queries en -responses worden getransporteerd. Daarmee is ook de vertrouwelijkheid en de 'Last Mile' van het DNS-transport beschermd (DNSSEC beschermt alleen de authenticiteit van de DNS-informatie).

DoH is dus geen vervanger voor DNSSEC, maar complementair daaraan. De standaard (gedefinieerd in RFC 8484) richt zich alleen op use cases waarbij DoH wordt ingezet tussen eindgebruikers en caching resolvers, op het niveau van het operating system (door de stub resolver) of op applicatieniveau (door de webbrowser).

We beschrijven DoH uitgebreid in dit artikel.

DoQ (DNS over QUIC) is (net als DoT en DoH) een uitbreiding van het DNS-systeem die het transport van DNS-informatie beschermt. Deze beveiligingsstandaard is nieuw en zal naar verwachting vooral worden gebruikt op applicatieniveau (in de webbrowsers).

De naam van de standaard geeft precies weer wat deze beveiligingstechnologie doet: de client bouwt eerst een cryptografisch beveiligde QUIC-verbinding op, waarover vervolgens de DNS-queries en -responses worden getransporteerd. Daarmee is ook de vertrouwelijkheid en de 'Last Mile' van het DNS-transport beschermd (DNSSEC beschermt alleen de authenticiteit van de DNS-informatie). DoQ is dus geen vervanger voor DNSSEC, maar complementair daaraan.

We beschrijven DoQ (en QUIC) uitgebreid in dit artikel.

Digitale handtekeningen maken gebruik van public-keycryptografie en hashfuncties: Eerst wordt een hash (een digitaal uittreksel) van een elektronisch document (in dit geval een RRset) gemaakt. Die hash wordt vervolgens versleuteld met een private sleutel. Het resultaat is een digitale handtekening specifiek voor dat document.

Bij elke (geheime) private sleutel hoort een publieke sleutel die bij iedereen bekend is (in dit geval gepubliceerd als DNSKEY-record). Deze publieke sleutel kan door iedereen gebruikt worden om te verifiëren dat de betreffende handtekening inderdaad bij dit specifieke document hoort en alleen door de eigenaar van de publieke sleutel gezet kan zijn; hij is immers de enige die de bijbehorende private sleutel kent.

Het DNSSEC-protocol is volledig gebaseerd op digitale handtekeningen: Digitale handtekeningen (RRSIG-records) onder de DNS-antwoorden (de RRsets) bevestigen de authenticiteit van die responses. Een digitale handtekening (via een DS-record) onder de publieke sleutel (#1) van de ondertekenaar (een DNSKEY-record) bevestigt de authenticiteit van zijn handtekeningen. En een digitale handtekening onder de publieke sleutel (#2) van de ondertekenaar van die publieke sleutel (#1) bevestigt die publieke sleutel (#2) weer. Zo wordt bovenop de bestaande DNS-infrastructuur een zogenaamde chain of trust opgebouwd die eindigt bij de rootzone. Die allerlaatste handtekening wordt gezet met een sleutelpaar dat per definitie wordt vertrouwd. De publieke sleutel daarvan is als trust anchor integraal onderdeel van alle resolversoftware.

Het diagram hieronder laat zien hoe voor de domeinnaam example.nl de hele chain of trust naar de root zone wordt opgebouwd.

Zowel voor de hashes als voor de public-keycryptografie bestaan verschillende algoritmen. DNSSEC ondersteunt verschillende combinaties van die 2. Voordat je je zones ondertekent, moet je dus kiezen welke combinatie van pubkey-algoritme en hashfunctie je daarvoor gaat gebruiken.

Daarnaast is er nog de aparte keuze van een hashfunctie voor de DS/CDS-records.

Op dit moment zijn er een stuk of 15 cryptografische pubkey/hash-combinaties voor DNSSEC gedefinieerd. Het complete overzicht vind je op de website van IANA:

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml.

In de loop der tijd vallen bestaande algoritmen af (deprecated, want verouderd of onveilig) en komen er nieuwe algoritmen bij. Specifiek voor DNSSEC zien we de laatste ontwikkelingen in (toegepaste) cryptografie terug in de publicatie van RFC 8624 als opvolger van RFC 6944.

RFC 8624 geeft een aantal aanbevelingen voor de keuze en toepassing van de verschillende DNSSEC-algoritmen:

• algoritme nummer 13 (ECDSA Curve P-256 with SHA-256) wordt aanbevolen

• naast nummer 8 (RSA/SHA-256), dat lange tijd de standaard was en nu uitgefaseerd wordt ten gunste van de ECDSA-gebaseerde algoritmen

• nummer 10 (RSA/SHA-512), een variant van nummer 8, is nooit populair geworden en wordt inmiddels ontraden

• nummer 14 (ECDSA Curve P-384 with SHA-384) is een sterkere versie van nummer 13, maar is op dit moment nog niet nodig (en ook nauwelijks in gebruik)

• de verwachting is bovendien dat niet nummer 14 maar een EdDSA-gebaseerd algoritme (nummer 15, Ed25519) de opvolger van nummer 13 gaat worden

Kortom: Ga je nu met DNSSEC aan de slag, dan kies je voor algoritme nummer 13. Gebruik je al DNSSEC maar dan gebaseerd op algoritme nummer 8 (of ouder), stap dan op niet al te lange termijn over naar nummer 13.

Algoritmen gebaseerd op de SHA-1 hashfunctie (nummer 3, nummer 5, nummer 6 en nummer 7) zijn inmiddels ernstig verouderd en verzwakt. Naar verwachting worden de laatste SHA-1-gebaseerde algoritmen binnen niet al te lange tijd uit de DNSSEC-standaard verwijderd. Desondanks zijn in de .nl-zone toch nog 3.200 domeinnamen met een van deze algoritmen ondertekend (situatie september 2024). Houders daarvan moeten echt zo snel mogelijk overstappen naar een sterker algoritme, en dan het liefst natuurlijk gelijk naar nummer 13.

Algoritme nummer 1 (RSA/MD5) moet je absoluut niet meer gebruiken vanwege de bewezen onveiligheid van de MD5 hashfunctie.

Maar ook de SHA-1-hashfunctie is al in 2011 door NIST afgekeurd voor gebruik in digitale handtekeningen. "SHA-1 is niet veilig meer", zei Marc Stevens destijds. Hij is cryptograaf bij CWI en bekend als kraker van MD5 en SHA-1.

Met de publicatie van RFC 8624 wordt de toepassing van deze hashfunctie sinds juni 2019 ook in DNSSEC officieel afgeraden. Het gaat dan om algoritmen nummer 3 (DSA/SHA1), 5 (RSA/SHA-1), 6 (DSA-NSEC3-SHA1) en 7 (RSASHA1-NSEC3-SHA1). Naar verwachting worden de laatste SHA-1-gebaseerde algoritmen binnen niet al te lange tijd uit de DNSSEC-standaard verwijderd. Desondanks zijn in de .nl-zone toch nog 3.200 domeinnamen met een van deze algoritmen ondertekend (situatie september 2024). Houders daarvan moeten echt zo snel mogelijk overstappen naar een veilig algoritme, en dan het liefst natuurlijk gelijk naar nummer 13.

Algoritmen nummer 8 en 10 zijn beide gebaseerd op de SHA-2 hash-functie, de opvolger van SHA-1 die wel veilig is voor gebruik in digitale handtekeningen. Nummer 8 (RSA/SHA-256) was lange tijd de standaard en wordt nu uitgefaseerd ten gunste van de ECDSA-gebaseerde algoritmen. Nummer 10 (RSA/SHA-512), een variant van nummer 8, is nooit populair geworden en wordt inmiddels ontraden (in RFC 8624).

ECDSA (Elliptic Curve Digital Signature Algorithm) is een algoritme voor de implementatie van het public-keyprotocol, net zoals de traditionele DSA- en RSA-algoritmen dat zijn. Zoals de naam al aangeeft is ECDSA gebaseerd op Elliptic Curve Cryptografie (ECC), dat belangrijke voordelen biedt bij de toepassing voor DNSSEC.

De veiligheid van alle 3 public-key-algoritmen – DSA, RSA en ECDSA – is gebaseerd op de wiskundige moeilijkheid om discrete logaritmen uit te rekenen (in complexiteitstermen: "onberekenbaar in redelijke tijd").

Het RSA-algoritme kan echter via een kortere weg gebroken worden, namelijk door het product (de vermenigvuldiging) van 2 grote priemgetallen weer in zijn factoren te ontbinden (priemfactorisatie). Daardoor zijn voor een veilig gebruik van RSA aanzienlijk langere sleutels nodig, wat dit algoritme minder geschikt maakt voor toepassing bij DNSSEC.

DSA is door de Amerikaanse overheid ontwikkeld als vrije tegenhanger van het proprietary RSA-algoritme. Belangrijk aandachtspunt bij de inzet van DSA is dat het enorm kwetsbaar is bij gebruik van een slechte randomgenerator.

De achterliggende wiskunde voor elliptic curve is een stuk ingewikkelder dan priemfactorisatie om uit te leggen, maar voor de liefhebbers wordt het idee achter ECC hier door Ars Technica op een toegankelijke manier uit de doeken gedaan.

Specifiek van belang voor DNSSEC is dat de digitale handtekeningen bij he gebruik van ECDSA ongeveer even lang zijn als die bij het gebruik van DSA, maar dat de publieke sleutels veel korter zijn. Ter illustratie: een veiligheidsniveau van 128 bits – dat wil zeggen dat er 2^128 'brute force'-operaties nodig zijn om een versleuteling te kraken – wordt op dit moment als een veilig minimum beschouwd. Om dat veiligheidsniveau te halen is bij ECDSA een publieke sleutel van 256 bits nodig (2 keer de gewenste veiligheid), terwijl dit voor DSA en RSA minstens 2.048 bits is. De lengte van de handtekeningen is voor ECDSA en DSA allebei ongeveer viermaal de lengte van de gewenste veiligheid, in dit voorbeeld dus 512 bits, terwijl die voor RSA op meer dan 2048 bits zit.

Voor 128-bitssecurity:

Bovendien zijn de handtekeningen voor ECDSA veel sneller te berekenen dan die voor RSA (een orde grootte) en DSA (een veelvoud). Alleen voor het controleren (valideren) van de handtekeningen is RSA veel sneller dan de andere 2 algoritmen, zelfs een orde grootte ten opzichte ECDSA. Dat laatste is het enige, maar wel een aanzienlijk nadeel van de toepassing van ECDSA voor DNSSEC.

De hierboven besproken verschillen in algoritmische eigenschappen maken ECDSA in het algemeen de beste keuze voor DNSSEC. Ten eerste kunnen niet alleen de digitale handtekeningen (de RRSIG-records) maar ook de publieke sleutels (de DNSKEY-records) onder de 512 bytes in lengte blijven. Daarmee hoeft voor het transport van deze records niet te worden overgeschakeld van traditionele DNS-pakketten naar (langere) EDNS-pakketten.

Ten tweede blijft bij ECDSA het verschil in grootte tussen de DNS-vraag (de lookup query) en het antwoord (de response) beperkt. Juist deze "opblaasfactor" van DNSSEC wordt immers regelmatig misbruikt voor het uitvoeren van DDoS/amplificatie-aanvallen.

Ten slotte vraagt het uitrekenen van een digitale handtekening (de ondertekening) bij ECDSA veel minder verwerkingskracht dan bij RSA. Dat is een groot voordeel voor registrars en andere DNS-operators die in bulk de domeinen voor hun klanten ondertekenen. Nadeel aan clientzijde is dat de validatie van een ECDSA-handtekening door de resolver langer duurt, en dat is vooral van belang voor het gebruik van DNSSEC op mobiele apparaten, die in het algemeen maar beperkte rekenkracht en batterijcapaciteit aan boord hebben.

Zeker: sinds maart 2016 kunnen registrars ook DNSKEY-records gebaseerd op algoritmen nummer 13 en 14 bij SIDN aanleveren voor publicatie in de .nl-zone (in de vorm van een hash-waarde in een DS-record). Daarmee werd het voor registrars mogelijk om de domeinen van hun klanten met ECDSA te ondertekenen.

Vanaf dat moment konden dus ook .nl-domeinnamen ondergebracht bij CloudFlare– zo'n 20.000 stuks – van DNSSEC worden voorzien. Deze CDN-aanbieder ondertekent de domeinnamen van zijn klanten namelijk al vanaf de start standaard met algoritme nummer 13.

Inmiddels worden algoritmen nummer 13 en 14 ook breed ondersteund aan zowel client- (resolver) als serverzijde. In de grafiek hieronder kun je zien dat algoritme nummer 7 inmiddels vrijwel helemaal verdwenen is uit de .nl-zone, en dat algoritme nummer 8 verdrongen wordt door nummer 13. Op dit moment (september 2024) gebruikt 59 procent van de .nl-domeinnamen algoritme nummer 13 en 41 procent nummer 8.

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/8676191f12a5af4852e497713a6491f7/stats.sidnlabs.nl-DNSSECalgoritmen-20240826.png

Voor het .nl-topleveldomein zelf zijn we in de zomer van 2023 overgestapt van algoritme nummer 8 naar nummer 13.

DNSSEC-algoritme nummer 14 is net als nummer 13 gebaseerd op ECDSA, maar heeft een sleutellengte (384 in plaats van 256 bits) die deze beveiliging geschikt maakt voor de allerzwaarste toepassingen.

Omdat een sterkere beveiliging langere sleutels en handtekeningen vereist en dus meer verwerkingskracht en verkeer kost, komen we algoritme nummer 14 zelden tegen. Op dit moment (september 2024) gebruikt slechts een minuscule 0,03 procent van de .nl-domeinnamen algoritme nummer 14. De verwachting is bovendien dat niet nummer 14 maar een EdDSA-gebaseerd algoritme (nummer 15, Ed25519) de opvolger van nummer 13 gaat worden.

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/8676191f12a5af4852e497713a6491f7/stats.sidnlabs.nl-DNSSECalgoritmen-20240826.png

Het grote snelheidsverschil in ondertekenen tussen ECDSA en RSA maakt het in de toekomst waarschijnlijk mogelijk om de digitale handtekening onder een denial-of-existence on-the-fly te genereren – dat wil zeggen als onderdeel van het samenstellen van de DNS-response. Daarmee ontstaat een dynamisch alternatief voor NSEC(3) waarmee het 'zone walking'-veiligheidsprobleem definitief opgelost zou zijn.

Deze 'DNSSEC white lies'-technologie (zie RFC 4470 en 4471) wordt met name gepropageerd door CDN-aanbieder CloudFlare.

EdDSA (Edwards-curve Digital Signature Algorithm) is een algoritme voor de implementatie van het public-key protocol, net zoals de traditionele DSA- en RSA-algoritmen dat zijn. De techniek lijkt erg op die van ECDSA – een ander modern public-key algoritme – maar zoals de naam al aangeeft gebruikt EdDSA 'twisted Edwards curves', een specifieke variant van de onderliggende wiskunde gebruikt in de Elliptic-Curve Cryptography (ECC).

DNSSEC-algoritmen nummer 15 en 16 (gedefinieerd in RFC 8080) maken gebruik van de cryptografische constructies Ed25519 en Ed448 (beschreven in RFC's 8032 en 7748). De eerste constructie combineert de elliptische curve Curve25519 met de SHA-512 hash-functie tot een razendsnel public-key algoritme. Ed448 doet hetzelfde met Curve448 en SHA-3 (in dit geval de SHAKE256-variant).

Net als algoritme nummer 13 (ECDSA Curve P-256 with SHA-256) biedt Ed25519 (algoritme nummer 15) een veiligheidsniveau van 128-bits (wat op dit moment de norm is) op basis van een 256-bits private sleutel, met daarbij een 512-bits publieke sleutel en 512-bits handtekeningen. Met een sleutellengte van 448 bits en een veiligheidsniveau van 224 bits is Ed448 (algoritme nummer 16) de EdDSA-gebaseerde evenknie van algoritme nummer 14 (ECDSA Curve P-384 with SHA-384).

De EdDSA-gebaseerde cryptografie biedt voor DNSSEC dezelfde voordelen als ECDSA ten opzichte van DSA- en RSA, maar is eenvoudiger, iets sneller, en minder gevoelig voor (side-channel) aanvallen dan ECDSA.

Dat kan zeker, al is het voor grootschalig operationeel gebruik van algoritmen nummer 15 (Ed25519) en nummer 16 (Ed448) op dit moment (september 2024) nog te vroeg.

Registrars kunnen DNSKEY-records gebaseerd op algoritmen nummer 15 en 16 zonder meer bij SIDN aanleveren voor publicatie in de nl-zone (in de vorm van een hashwaarde in een DS-record). Daarmee is het voor registrars in principe ook mogelijk om de domeinen van hun klanten met EdDSA te ondertekenen.

RFC 8624 (gepubliceerd in juni 2019) specificeert de implementatie van algoritmen nummer 15 en 16 in resolvers als 'recommended', net als de implementatie van nummer 15 in nameservers. Dat betekent dat de ondersteuning voor EdDSA-gebaseerde algoritmen deze jaren in de DNS-software ingebouwd wordt. Daarom is het voor grootschalig operationeel gebruik nu nog te vroeg. De DNSThought-statistieken laten zien dat 91 procent van de validerende resolvers op dit moment ook algoritme 15 ondersteund. Kijken we naar de .nl-zone, dan zien we dat op dit moment slechts een verwaarloosbare 0,02 procent van de domeinnamen algoritme nummer 15 gebruikt.

RFC 8624 geeft (ook) aanbevelingen voor de hashfunctie te gebruiken voor DS/CDS-records:

• op dit moment is slechts een handvol algoritmen gedefinieerd; het complete overzicht vind je op de website van IANA: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

• hash-algoritme nummer 2 (SHA-256) wordt aanbevolen

• nummer 1 (SHA-1) wordt nog wel veel gebruikt, maar moet je op korte termijn vervangen door nummer 2

• nummer 4 (SHA-384) is een sterkere versie van nummer 2, maar is op dit moment nog niet nodig

Kortom: Ga je nu met DNSSEC aan de slag, dan kies je voor hash-algoritme nummer 2. Gebruik je al DNSSEC maar dan gebaseerd op hash-algoritme nummer 1, stap dan op korte termijn over naar nummer 2.

Specifiek voor de domeinnamen onder de .nl-zone geldt dat houders hier geen omkijken naar hebben. Omdat wij domeinnaamhouders niet om een DS-record maar om het DNSKEY-record vragen, genereren wij daaruit zelf al vanaf het begin een DS-record gebaseerd op SHA-256.

De aanwezigheid van een DS-record in de bovenliggende zone is bepalend voor het al dan niet aanwezig zijn van DNSSEC in de onderliggende zone. Voordat je een ondertekend domein definitief beveiligt met DNSSEC (dat wil zeggen: het sleutelmateriaal bij de bovenliggende zone aanmeldt voor publicatie als DS-record), moet je jezelf ervan vergewissen dat het betreffende domein nu en in de toekomst blijft werken. De belangrijkste aandachtspunten daarvoor zijn deze:

• check de ondertekende zone: naast de standaard DNS-tools en DNSSEC-specifieke tools is DNSViz de beste tool die we hiervoor kunnen aanbevelen

• maak een backup van het sleutelmateriaal: alle DNS-software en hardware devices (HSM's) die DNSSEC ondersteunen, bieden je de mogelijkheid om sleutelparen te exporteren; zorg dat je een backup van de sleutelparen veiligstelt voordat je DNSSEC aanzet

• het is een goede gewoonte om de TTL-waarden te verkorten voordat je gaat sleutelen aan de DNS-infrastructuur van een domein dat in gebruik is: op die manier kunnen wijzigingen sneller doorgevoerd worden, waardoor ook de impact van eventuele fouten verkleind (verkort) kan worden; wees je er wel van bewust dat kortere TTL-waarden leiden tot een hogere belasting van je nameservers

DNSSEC is aanzienlijk minder vergevingsgezind dan het traditionele DNS-systeem. Bovendien worden fouten en foutjes veel harder afgestraft: in het ergste geval wordt een compleet domein door alle validerende resolvers geblokkeerd. Dat betekent dat eventueel aanwezige fouten in de zone gerepareerd moeten worden voordat deze ondertekend kan worden.

Gelukkig zijn er diverse tools beschikbaar die je hierbij kunnen helpen:

• het commando named-checkzone (onderdeel van BIND)

• het commando kzonecheck (onderdeel van Knot DNS)

• de online tool DNSChecker.org

Ook voor het checken en debuggen van een eenmaal ondertekende zone zijn diverse tools beschikbaar:

• de grafische online tool DNSViz (aanrader!)

• de online tool DNSSEC Analyzer

• de online tool Internet.nl (ook voor andere tests)

• DNSSEC-Tools (verouderd?)

DNSSEC is aanzienlijk minder vergevingsgezind dan het traditionele DNS-systeem.

• de public-key cryptografie maakt DNSSEC complex

• misconfiguraties worden direct afgestraft

• problemen treden met name op bij herondertekening en sleutelbeheer/rollovers

• in het ergste geval wordt een compleet domein door alle validerende resolvers geblokkeerd (in de begintijd van DNSSEC is dat zelfs een paar keer met TLD's gebeurd; gelukkig waren er destijds nog maar weinig validerende resolvers in gebruik)

Problemen bij herondertekening en sleutelbeheer/rollovers zijn makkelijk te voorkomen door deze processen zo veel mogelijk te automatiseren:

• ontwikkelaars van DNS-software hebben hun best gedaan om de complexiteit van DNSSEC goed beheersbaar te maken, zo veel mogelijk te verbergen en te automatiseren

• de ondersteuning voor geautomatiseerde herondertekening en sleutelbeheer/rollovers is inmiddels standaard onderdeel van alle software voor autoritatieve nameservers

• voor de ondertekening van individuele zone files is de tool OpenDNSSEC beschikbaar (deze wordt ook voor de .nl-zone gebruikt)

DNSSEC heeft het DNS-systeem op belangrijke punten veranderd:

• van een voornamelijk administratief systeem in een aanzienlijk complexer cryptografisch platform dat voor een heleboel nieuwe toepassingen gebruikt kan worden

• met de eerste introductie van absolute tijd in een omgeving die voorheen alleen relatieve tijden (TTL's) kende; bovendien interacteren deze 2 verschillende timing-methoden met elkaar

Het moderne DNS-systeem kent nu 3 verschillende tijden:

Relatieve tijd

TTL-waarden zijn relatieve tijdsaanduidingen die gebruikt worden om de (resterende) levensduur van een record aan te geven.

example.nl.    3600    IN    A    94.198.159.35

Caching nameservers gebruiken deze waarde als aflopende secondenteller voor de geldigheid van het opgeslagen record. Naarmate de tijd verstrijkt en een record in de cache-hiërarchie steeds verder van de autoritatieve nameserver af beweegt, neemt de TTL-waarde af totdat het record uiteindelijk uit de caches verwijderd wordt. TTL-waarden waren al onderdeel van het bestaande DNS-protocol en zijn dus bekende kost voor beheerders.

Absolute tijd

RRSIG- en NSEC(3)-records bevatten naast een digitale handtekening ook 2 absolute tijdsaanduidingen die het begin en het einde van de geldigheid aangeven.

example.nl.    3600    IN    RRSIG    A 13 2 3600 20220901125646 20220818112455
    7104 example.nl. 3TMKhc7EuQL08gYuNKPBZAFAyNCEogkr+5fasVTerD9...

Ruim voordat een handtekening verloopt, moeten de RRsets opnieuw ondertekend worden. Zowel de geldigheidsduur als de periode voor herondertekening worden bepaald door relatieve tijdsinstellingen van de nameserver. Deze timing-methode hoort specifiek bij DNSSEC en is daarmee een nieuw onderdeel van DNS.

Administratieve tijd

De cryptografische sleutelparen voor het ondertekenen van de RRsets hebben alleen een administratieve geldigheidsduur. Ze worden door het DNSSEC-systeem voor een specifieke periode gebruikt en moeten daarna gerold worden. Deze periode wordt echter niet hard afgedwongen; zolang er geen nieuw sleutelpaar beschikbaar is, blijft het oude paar gewoon gebruikt worden. De DNSKEY- en DS-records bevatten zelf geen timing-informatie; hun relatieve (resterende) geldigheidsduur wordt dus volledig bepaald door de bijbehorende TTL-waarden.

example.nl.    3600    IN    DNSKEY    257 3 13 5LLZ7NLIMEYHcU2D...
example.nl.    3600    IN    DNSKEY    256 3 13 jyFF8wHMIIuGLORliN...
example.nl.    3600    IN    DS        31925 13 2 E992722DF695728385A...

De instellingen voor de sleutelparen zijn specifiek voor DNSSEC en daarmee een nieuw onderdeel van DNS.

Voor DNSSEC-records, en het ondertekenen en rollen geldt het volgende:

• Zowel de traditionele DNS-records als de nieuwe DNSSEC-records hebben een relatieve (resterende) levensduur bepaald door de TTL-waarde. De TTL-waarde van RRSIG-records moet gelijk zijn aan die van de resource records. Daarenboven hebben de digitale handtekeningen een absolute geldigheidsperiode expliciet gespecificeerd in het RRSIG-record.

• De DNSKEY- en DS-sleutel-records bevatten geen timing-informatie (anders dan hun TTL-waarde). Daarmee is hun rol beperkt tot die van schakel in de vertrouwensketen.

• Het herondertekenen van de RRsets en het rollen van de sleutelparen zijn 2 verschillende maar niet onafhankelijke processen.

• Daarbij is de herondertekening afhankelijk van 3 verschillende triggers:

  • een verandering in de zonefile

  • het verlopen van de bestaande digitale handtekening

  • het rollen van het (ZSK-)sleutelpaar

De TTL-waarden spelen hierbij geen rol.

• Het rollen van een sleutelpaar wordt alleen administratief getriggerd:

  • bij een veiligheidsincident

  • bij de overstap naar een ander cryptografisch algoritme

  • en bij de verhuizing naar een andere operator/registrar

Daarbij is dit proces voor zijn timing wel afhankelijk van zowel herondertekening (van de sleutel-records) als TTL-instellingen (voor het uitspoelen van gecachte informatie).

We bespreken de timing-aspecten van DNSSEC uitgebreider in dit artikel. De timing-overwegingen bij rollovers worden in detail besproken in RFC 7583. Andere zaken om rekening mee te houden zijn propagatietijden van hidden naar publieke nameservers en refresh-tijden van de TLD-zone [1, 2].

Een correcte, goed functionerende en goed beveiligde systeemtijd een cruciale pijler is onder een betrouwbaar DNSSEC-systeem. Een kwaadwillende zou een DoS-aanval op een validerende resolver kunnen uitvoeren door de tijd vooruit te zetten. Of hij zou de cache kunnen flushen door de TTL van de records kunstmatig te laten verlopen. Of andersom: hij zou een replay-aanval kunnen uitvoeren door de tijd juist terug te zetten.

In 2015 publiceerden Malhotra e.a. van Boston University een paper waarin ze diverse zwakheden in het NTP-protocol blootlegden. De auteurs beschrijven verschillende methoden om via NTP de systeemtijd daadwerkelijk te veranderen. Ze laten zien hoe ze door de systeemtijd te veranderen, konden rommelen met allerlei beveiligingsprotocollen die van de juiste tijd afhankelijk zijn. Deze publicatie was de directe aanleiding voor de implementatie van NTS, een cryptografisch beveiligde uitbreiding van NTPv4.

In 2019 publiceerde dezelfde Aanchal Malhotra samen met de mensen van NLnet Labs (verantwoordelijk voor de ontwikkeling van NSD, Unbound, OpenDNSSEC, Krill, Routinator en verschillende andere netwerk-tools) een paper specifiek gericht op het belang van een correcte (veilige) systeemtijd voor DNS. Daarin bespreken zij verschillende scenario's om aanvallen zoals hierboven beschreven uit te voeren.

We raden je dan ook dringend aan om alle systemen in je DNS-infrastructuur van een goed geconfigureerde NTS-client te voorzien. We bespreken NTS uitgebreid in deze artikelen:

• NTS-beveiliging voor NTP-tijdsprotocol gestandaardiseerd als RFC 8915

• Zwakheden in NTP-tijdsprotocol maken andere (beveiligings-)protocollen kwetsbaar

Onze eigen publieke NTP/NTS-dienst (nts.)time.nl bespreken we in deze artikelen:

• Nauwkeurige, beveiligde systeemtijd cruciaal voor DNSSEC – en andersom!

• TimeNL: de duidelijke NTP-dienst van SIDN Labs

DNSSEC maakt de antwoorden die door name-servers teruggestuurd worden in response op DNS queries aanzienlijk groter. Met elke Resource Record Set (RRset) wordt nu immers ook een digitale handtekening (in een RRSIG record) meegestuurd.

Omdat DNS standaard gebruik maakt van het snelle maar stateless UDP-protocol, kan het afzender-adres makkelijk worden vervalst (IP address spoofing). Door vanuit een botnet een grote hoeveelheid vervalste DNS queries naar een of meer DNS-servers te sturen, kan via die servers een DDoS-aanval (Distributed Denial-of-Service) worden uitgevoerd. Omdat de responses aanzienlijk groter kunnen zijn dan de queries spreekt men van een amplificatie-aanval.

Er zijn verschillende manieren waarop beheerders van DNS-servers kunnen voorkomen dat hun systemen voor DNS amplificatie-aanvallen misbruikt worden:

• Response Rate Limiting (RRL) Deze techniek beperkt het aantal responses naar een client-adres als het steeds om dezelfde antwoorden gaat. Om te voorkomen dat ook legitieme queries niet meer beantwoord worden, wordt RRL vaak gecombineerd met SLIP. Daarbij worden worden clients niet volledig geblokkeerd maar worden ze voor een bepaald gedeelte van hun queries doorverwezen naar het TCP-protocol. Daarmee wordt de amplificatie-factor uit de aanval gehaald.

• DNS dampening Hierbij wordt niet gekeken naar de uitgaande antwoorden maar naar de binnenkomende queries. Deze worden per client-adres en per query type gescoord. Wordt een bepaalde drempel overschreden, dan worden alle queries van die client tijdelijk genegeerd. De score neemt exponentieel af over de tijd, zodat de responses zich vanzelf weer herstellen.

Waar DNS dampening alle responses naar een bepaald adresblok tegenhoudt, beperkt RRL alleen de reponses op specifieke query typen en biedt SLIP clients de mogelijkheid om hun informatie alsnog te verkrijgen. Dat maakt RRL een verfijnder techniek dan DNS dampening.

RRL en DNS dampening kunnen alleen eenvoudige DNS amplificatie-aanvallen voorkomen. Zodra aanvallers meerdere DNS-servers inzetten kunnen de afzonderlijke servers op geen enkele manier meer zien dat ze deelnemen in een dubbel gedistribueerde aanval: gedistribueerd zowel over de aanvallende clients (een botnet) als over de DNS-servers die als reflector fungeren. Het gedistribueerde verkeer in een lage frequentie is immers niet te onderscheiden van legitiem DNS-verkeer.

De beste manier om DNS amplificatie-aanvallen te voorkomen is tegelijkertijd (technisch) de meest simpele oplossing. BCP 38 (RFC 2827) schrijft voor dat elke serviceprovider (ISP) zijn uitgaande internetverkeer zou moeten filteren op afzender-adres. Pakketten die niet uit zijn IP-netwerk afkomstig kunnen (mogen) zijn, moeten geblokkeerd worden (ingress filtering). Op die manier wordt verkeer van besmette clients die deel uitmaken van een botnet al bij de bron geblokkeerd.

De toepassing van BCP 38 schiet echter tekort. Kosten en opbrengsten liggen immers bij verschillende partijen: BCP 38 is ontworpen om anderen te beschermen tegen spoofing-aanvallen afkomstig uit jouw netwerk.

DNS-pakketten zijn van origine beperkt tot een grootte van 512 bytes over het UDP-protocol. Voor grotere pakketten (responses) wordt overgeschakeld naar het (resource-intensievere) TCP-protocol. Met name de ontwikkeling van DNSSEC was een belangrijke reden om DNS geschikt te maken voor grotere pakketten over UDP. De EDNS0-uitbreiding (Extension Mechanisms for DNS) staat veel grotere DNS-pakketten toe, zodat ook pakketten met digitale handtekeningen zo veel mogelijk over UDP verstuurd kunnen worden.

De mogelijkheid om grotere UDP-pakketten voor DNS te gebruiken betekent ook dat deze (onderweg) mogelijk worden verdeeld over meerdere IP-fragmenten, namelijk als deze groter zijn dan de path MTU (Maximum Transmission Unit). Omdat alle DNS controle-informatie (vlaggen en dergelijke) zich in het eerste fragment bevindt, is de inhoud van latere fragmenten veel makkelijker te voorspellen, waarmee het voor aanvallers eenvoudiger wordt om valse DNS-informatie te injecteren.

Ook hier geldt dat DNSSEC-validatie dit type aanvallen kan voorkomen. De digitale handtekening garandeert immers de geldigheid van het hele antwoord (RRset).

Response Rate Limiting (RRL) is een techniek om DNS amplificatie-aanvallen tegen te gaan. Daarbij beperkt een autoritatieve nameserver (tijdelijk) het aantal responses naar een client-adres als het steeds om dezelfde antwoorden gaat.

Kwaadwillenden kunnen de RRL-bescherming aanwezig op een autoritatieve nameserver misbruiken om hun kansen op een succesvolle 'cache poisoning'-aanval te vergroten. Dat doen zij door eerst middels IP address spoofing een caching resolver bewust in de RRL blacklist van een veelgebruikte autoritatieve nameserver op laten nemen. Als de aanvaller het IP-adres van de resolver als afzender in een groot aantal vervalste UDP-pakketten plaatst, zal de autoritatieve nameserver immers denken dat de betreffende resolver slachtoffer is van een DDoS-aanval. De autoritatieve nameserver zal vervolgens ook veel van de echte queries afkomstig van de resolver niet meer beantwoorden. En dat vergroot het venster voor de aanvaller om een 'cache poisoning'-aanval op de resolver uit te voeren.

Het gebruik van DNSSEC voorkomt dit type 'cache poisoning'-aanvallen omdat de vervalste DNS-responses niet de juiste handtekening van de originele autoritatieve nameserver bevatten.

SIDN (Stichting Internet Domeinregistratie Nederland) is de organisatie die verantwoordelijk is voor het beheer van het .nl-topleveldomein en de doorverwijzingen voor alle .nl-domeinen. Wij hebben daarvoor een eigen DomeinRegistratieSysteem (DRS) ontwikkeld en een redundante infrastructuur in en om Arnhem opgezet.

De aanvragen en het beheer van domeinen lopen via de registrars: ruim 1.100 gespecialiseerde internet- en hosting-bedrijven die daarvoor een overeenkomst hebben gesloten met SIDN. Zij maken daarbij gebruik van het Extensible Provisioning Protocol (EPP), een XML-gebaseerde interface tussen domeinnaam-beheerders (registries) en hun registrars.

Aanvragers en houders van domeinen doen zaken met een internet service provider (ISP). Vaak is die zelf aangemeld als registrar, maar een aanbieder kan ook gebruik maken van de diensten van een ander. Eindklanten doen hun aanvragen en beheer van domeinen meestal via het dashboard (een webinterface) van hun internet service provider.

Vanuit technologisch perspectief gezien is DNSSEC heel veilig. Het protocol is goed doordacht en de vertrouwensketen ('chain of trust') is cryptografisch compleet.

Het hele systeem is echter zo veilig als de zwakste schakel. Op dit moment is de client nog steeds het meest kwetsbare onderdeel in de keten. Is een PC bijvoorbeeld besmet met malware, dan zijn meestal ook de (stub) resolver (het onderdeel van het besturingssysteem op de client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen) en de locale cache te manipuleren.

Daarnaast is de beveiliging van de registratie van sleutelmateriaal bij SIDN, de beheerder van het .nl-domein, een belangrijk onderdeel van de hele keten. Daar zou iemand immers het DS-record kunnen verwijderen, een sleutel kunnen veranderen, of een extra DS-record kunnen toevoegen.

Een dergelijke aanpassing van het geregistreerde sleutelmateriaal in de .nl-zone zou in principe uitgevoerd kunnen worden door een (digitale) inbreker, een medewerker van SIDN, iemand in de aanleverketen (serviceprovider – registrar – reseller), of op verzoek van de overheid. Het primaire belang van SIDN ligt echter bij de domeinnaamhouders, registrars en serviceproviders. Inbreuk op de haar toevertrouwde functie zou uitsluitend kunnen worden afgedwongen na een gerechtelijk bevel, maar dat is tot op heden nog nooit voorgekomen.

We bespreken de beperkingen van DNSSEC hier uitgebreider.

De beveiliging van het sleutelmateriaal (de DNSKEY/DS-records) bij SIDN voldoet aan strenge eisen. De organisatie is bovendien gecertificeerd voor ISO 27001, een standaard voor beveiligingsmaatregelen. De systemen voor het ondertekenen van de beveiligde records werden tot voor kort vooral door banken gebruikt. Ze zijn gevalideerd volgens FIPS 140 en omgeven met uitgebreide veiligheidsprocedures.

SIDN zelf is al vanaf de oprichting in 1996 een volledig zelfstandige en onafhankelijke organisatie. Haar primaire belang ligt bij de domeinnaamhouders, registrars en internetserviceproviders. Inbreuk op de haar toevertrouwde functie zou alleen kunnen worden afgedwongen na een gerechtelijk bevel, maar dat is tot op heden nog nooit voorgekomen.

Hoewel de implementatie van DNSSEC een investering is waarvan het zakelijke rendement niet direct evident is, zijn er weldegelijk belangrijke voordelen en kansen waarvoor een valide business case gemaakt kan worden:

• security als onderscheidende waarde:

  • voor domeinnaamhouders, registrars en service-providers:

    • bescherming tegen reputatie- en zakelijke/financiële schade (onderdeel van informatiebeveiliging en risicomanagement)

    • profilering in de markt met 'moderne internetbeveiligingsstandaarden'

    • voor bedrijven, overheden en andere organisaties: een goed beveiligde ingang voor klanten, partners en leveranciers

    • voor internetgebruikers: vertrouwen in de online ingang van een bekend merk of organisatie

  • voor klanten en eindgebruikers:

    • een goed beveiligde ingang voor de opslag van waardevolle informatie en het uitvoeren van financiële transacties

  • voor registrars bij SIDN:

    • korting op domeinnamen via de incentiveregeling

• DNSSEC als een cryptografisch beveiligde basisinfrastructuur: Met de cryptografische beveiliging van de informatie in het DNS-systeem is deze infrastructuur nu ook geschikt voor de distributie van andersoortige informatie waarvan de authenticiteit gegarandeerd moet zijn. Daarmee biedt DNSSEC mogelijkheden voor hele nieuwe internettoepassingen. Voorbeelden van dergelijke toepassingen zijn:

  • SPF/DKIM/DMARC

  • DANE

  • SSHFP

Met de cryptografische beveiliging van de informatie in het DNS-systeem is deze infrastructuur nu ook geschikt voor de distributie van andersoortige informatie waarvan de authenticiteit gegarandeerd moet zijn. Deze infrastructuur kan in de toekomst door tientallen andere protocollen worden gebruikt om cryptografisch beveiligde informatie over te dragen of om bestaande internetprotocollen te versterken.

Eerste voorbeeld is het drietal DKIM/SPF/DMARC, dat phishing, spam, virussen en andere malware tegengaat door de afzender (een mailadres), de verzender (een mail-systeem) en de inhoud van een mail-bericht te beveiligen. Daarvoor worden diverse nieuwe records in de DNS-informatie opgenomen. Hoewel ondertekening met DNSSEC voor deze toepassing niet strikt noodzakelijk is – dat wil zeggen verplicht volgens de standaard – is dat wel een belangrijke toevoeging.

Ander voorbeeld is het DANE-protocol, dat gebruikt wordt om versleutelde internetverbindingen van een extra beveiliging te voorzien. Het bijbehorende TLSA-record vormt een aanvullende vertrouwensketen voor de X.509-servercertificaten die voor het opzetten van TLS/SSL-verbindingen worden gebruikt. Hier is het gebruik van DNSSEC dan ook een verplicht onderdeel van de DANE-standaard zoals die is vastgelegd in RFC 6698.

Laatste voorbeeld is SSHFP, dat een structurele oplossing biedt voor het 'key distribution'-probleem van SSH. Door de fingerprint (een digitale samenvatting) van de publieke sleutel van de SSH-server in het DNS-systeem op te nemen (in een SSHFP-record), stel je de client in staat de publieke sleutel zoals die bij het verbinden aangeboden wordt door de server te valideren. Daarmee kan de initiële handmatige verificatie achterwege blijven en kan de client gelijk doorgaan naar de authenticatie.

Dit lijstje geeft een overzicht van andere beveiligingsprotocollen die voortbouwen op DNSSEC:

• ZONEMD (gedefinieerd in RFC 8976):

  publicatie van een message digest over een complete zonefile (in een ZONEMD-record in de zone zelf), waarmee de integriteit van de DNS-informatie beschermd is (en impliciet de authenticiteit van de bron);

  DNSSEC is wel aangeraden maar niet verplicht; zonder de bescherming van DNSSEC fungeert ZONEMD alleen als een checksum;

  we publiceerden onlangs een uitgebreid artikel over ZONEMD

• DANE for OpenPGP (gedefinieerd in RFC 7929): publicatie van publieke OpenPGP-sleutels in een OPENPGPKEY-record; je kunt een dergelijk record laten genereren op de website van Shumon Huque of middels deze opdracht: gpg2 --export-options export-dane --export [name@example.nl]

• DANE for S/MIME Certificates (gedefinieerd in RFC 8162): pinning van een S/MIME-certificaat op een mailadres (middels een hashwaarde in een SMIMEA-record); de specificatie van de naam voor het mailadres is vergelijkbaar met de naam bij het OPENPGPKEY-record; de specificatie van het certificaat is vergelijkbaar met de inhoud van het TLSA-record.

• IPSECKEY (gedefinieerd in RFC 4025): publicatie van rauwe publieke sleutels in een IPSECKEY-record voor gebruik bij IPsec (via IKEv2); we publiceerden onlangs een uitgebreid artikel over IPsec

• CAA (gedefinieerd in RFC 8659): publicatie van de naam van de Certificate Authority (CA) die een nieuw certificaat voor een domein mag uitgeven (in een CAA-record); de CAA-records kunnen onderscheid maken tussen reguliere certificaten en wildcardcertificaten; bovendien kun je in deze records ook contactinformatie publiceren om schendingen van de ingestelde policy te laten rapporteren (vergelijk automatische DMARC-rapportages)

Integendeel: DNSSEC is een complex maar goed doordacht, toekomstbestendig en hoognodig protocol dat inmiddels sterke opgang vindt.

Jazeker: Inmiddels is bijna 60 procent van alle .nl-domeinen met DNSSEC beveiligd. Grofweg 60 procent van alle binnenkomende queries op de autoritatieve servers voor .nl is afkomstig van validerende resolvers (wereldwijd). En ongeveer 60 procent van de Nederlandse internetgebruikers maakt gebruik van een validerende resolver (situatie december 2022).

Jazeker: hoewel het originele DNS-systeem op dit moment niet onveilig is, is het weldegelijk kwetsbaar.

DNS is een van de oudste internetprotocollen die we nog steeds gebruiken. De beveiliging ervan is desondanks pas relatief laat ontwikkeld. Aanvalsmethoden [1] waren niet makkelijk uit te voeren en/of konden relatief makkelijk gepareerd worden, waarmee dergelijke aanvallen in de praktijk zeldzaam waren.

Na lange tijd relatieve rust aan het DNS-front, zijn de afgelopen jaren echter nieuwe aanvalsmethoden [1, 2] gepubliceerd. De beste verdediging tegen deze 'cache poisoning'-aanvallen is DNSSEC.

Waar het traditionele DNS-systeem vooral een administratieve aangelegenheid was, voegt DNSSEC aan deze gedistribueerde infrastructuur een nieuwe laag toe, met daarin een beveiligingsmechanisme gebaseerd op public-key cryptografie. Dat maakt het moderne DNS-systeem inderdaad een stuk complexer dan het voorheen was.

Public-key cryptografie is tegenwoordig echter standaard onderdeel van een heleboel internettoepassingen – denk aan TLS, SSH, S/MIME, OpenPGP, ZRTP en blockchains – waarmee de concepten van deze beveiligingstechnologie in de ICT-wereld breed bekend zijn.

Bovendien hebben ontwikkelaars van DNS-software hun best gedaan om de complexiteit van DNSSEC voor hun gebruikers goed beheersbaar te maken (bijvoorbeeld middels direct bruikbare default-instellingen). De makers van de PowerDNS-software hebben zelfs als uitgangspunt om zo veel mogelijk van de complexiteit voor hun gebruikers te verbergen en te automatiseren. In veel gevallen heeft men de ondersteuning van DNSSEC dan ook weten te reduceren tot een simpele aan/uit-switch.

De DNSSEC-beveiliging is gebaseerd op digitale handtekeningen en een gedistribueerde vertrouwensketen (chain of trust). Dat betekent dat de informatie in een zone consistent en compleet moet zijn voordat deze ondertekend kan worden, en dat coördinatie nodig is voor de toevoeging van sleutelmateriaal aan de bovenliggende zone.

Daarmee is DNSSEC inderdaad aanzienlijk minder vergevingsgezind dan het traditionele DNS-systeem; in het ergste geval wordt een compleet domein door alle validerende resolvers geblokkeerd.

In het algemeen volstaat het echter om eventueel aanwezige fouten in de zone file te repareren voordat deze ondertekend kan worden.

De herondertekening van de records en het verversen van de sleutels zijn inmiddels zodanig geautomatiseerd dat dit in de praktijk alleen nog in heel uitzonderlijke gevallen tot problemen leidt.

Dit is niet het geval: juist omdat DNSSEC minder vergevingsgezind is dan het traditionele DNS-systeem, zijn de implementaties (voor de beheerder) zo veel mogelijk vereenvoudigd en geautomatiseerd.

Ontwikkelaars van DNS-software hebben hun best gedaan om de complexiteit van DNSSEC voor hun gebruikers goed beheersbaar te maken. In veel gevallen heeft men de ondersteuning van DNSSEC zelfs weten te reduceren tot een simpele aan/uit-switch.

De herondertekening van de records en het verversen van de sleutels verlopen inmiddels zo veel mogelijk geautomatiseerd.

Integendeel: DNSSEC is bewezen, robuuste technologie, die inmiddels (december 2022) door bijna 60 procent van alle .nl-domeinen en ongeveer 60 procent van de Nederlandse internetgebruikers gebruikt wordt.

Zeker wel: DNSSEC is tegenwoordig een integraal onderdeel van alle actief onderhouden DNS-servers en -resolvers, alle gangbare netwerkmanagement-software en -tools, en alle gangbare operating systems. En interoperabiliteit is geen enkel probleem.

DNSSEC wordt ondersteund door de meeste registrars en resellers.

Kennis, ervaring en ondersteuning voor DNSSEC zijn breed beschikbaar bij leveranciers en dienstverleners.

Jazeker: het belang van een goed beveiligde digitale ingang is sterk toegenomen; voor bedrijven, overheden en andere organisaties, die zowel onderling als met klanten/burgers steeds meer via internet communiceren; en voor die klanten/burgers zelf, die ook online op de betrouwbaarheid van een merk of organisatie moeten kunnen rekenen.

Jazeker: Internet wordt steeds meer gebruikt als een platform voor de opslag van waardevolle informatie en het uitvoeren van financiële transacties. DNSSEC is voor de gebruiker een garantie dat zijn internetverkeer op de juiste plaats terecht komt.

Integendeel: DNSSEC verhoogt juist de veiligheid van je internetdiensten en vermindert de kans op een kraak, met bijbehorende reputatie- en zakelijke/financiële schade.

DNSSEC is wel minder vergevingsgezind voor fouten dan het traditionele DNS-systeem. Dat vraagt om extra aandacht bij de implementatie, en zo veel mogelijk automatisering van het beheer.

Integendeel: DNSSEC verhoogt juist de veiligheid van je internetdiensten en vermindert de kans op een kraak, met bijbehorende reputatie- en zakelijke/financiële schade.

DNSSEC wordt al veel gebruikt en is een betrouwbare en veilige uitbreiding van het DNS-systeem gebleken.

Integendeel: DNSSEC is inmiddels een standaard onderdeel van alle actief onderhouden DNS-servers en -resolvers. Het merendeel van deze software is bovendien gratis als open-sourcesoftware beschikbaar.

Door de reductie in complexiteit en de automatisering van herondertekening en sleutelbeheer/rollovers, blijft de extra beheerslast van een DNSSEC-implementatie beperkt.

De eerste keer dat je verbinding zoekt met een SSH-server zal de client je vragen om de fingerprint (een digitale samenvatting) van de publieke sleutel van de betreffende server te bevestigen. Doe je dat inderdaad, dan wordt deze publieke sleutel door de client opgeslagen (in de file '~/.ssh/known_hosts'). De volgende keer dat je je bij de betreffende server aanmeldt, weet de client welke publieke sleutel de server aan zou moeten bieden en ga je in één keer door naar de authenticatie.

Hoewel de meesten gewoon door zullen klikken, zou je om man-in-the-middle (MITM)-aanvallen te voorkomen deze fingerprint moeten vergelijken met de publieke sleutel op de betreffende server.

SSHFP is een beveiligingsstandaard die voortbouwt op DNSSEC en een structurele oplossing biedt voor dit 'key distribution'-probleem. Daartoe wordt de fingerprint opgenomen in het DNS-systeem en (digitaal ondertekend middels DNSSEC) voor clients beschikbaar gemaakt.

SSHFP begint met de publicatie van de fingerprint (een digitale samenvatting) van de publieke sleutel van de SSH-server in het DNS-systeem. Daarvoor is in RFC 4255 het speciale SSHFP-record gedefinieerd. Een dergelijk record genereer je middels de 'ssh-keyscan -D'-opdracht. Maar let op dat je dit commando strikt genomen alleen op de server zelf mag uitvoeren om een MITM-aanval te voorkomen.

Neem je de SSHFP-records voor een SSH-server op in de zonefile, en voeg je de instelling 'VerifyHostKeyDNS yes' toe aan de SSH-client configuratie (in de directory '/etc/ssh/' of '~/.ssh/config'), dan zal de client bij het verbinden met de betreffende server de fingerprint valideren. Dat gebeurt door de fingerprint van de publieke sleutel zoals die aangeboden wordt door de server te vergelijken met de fingerprint die in de DNS wordt gepubliceerd. Komen die 2 fingerprints overeen, dan zal de client gelijk doorgaan naar de authenticatie. Is er geen match, dan valt de client terug naar de traditionele, handmatige bevestiging.

Gedetailleerde informatie over het opzetten van SSHFP vind je in dit artikel.

Op onze Fedora Linux-systemen (versie 34 en hoger) hoefden we voor het gebruik van SSHFP de 'VerifyHostKeyDNS'-optie niet aan te zetten. Deze werd al geïnstalleerd (in de file '/etc/ssh/ssh_config.d/10-dnssec-trigger.conf') als onderdeel van DNSSEC-Trigger. De populaire terminal emulator PuTTY ondersteunt SSHFP-validatie echter niet.

Hieronder vind je een overzicht van de verschillende mijlpalen in de uitrol van DNSSEC in Nederland:

• mei 2012: DNSSEC-beveiliging voor .nl-domeinnamen volledig operationeel

• juni 2012: DNSSEC (en DKIM) toegevoegd aan de 'pas toe of leg uit'-lijst

• eind juni 2012: Meer dan tienduizend .nl-domeinen beveiligd met DNSSEC

• juli 2012: 100.000 DNSSEC-beveiligde .nl-domeinnamen

• augustus 2012: Exponentiële groei: meer dan 200.000 ondertekende .nl-domeinen

• augustus 2012: Nederland wereldwijd koploper met 355 duizend ondertekende domeinnamen

• september 2012: Uitrol overtreft alle verwachtingen: meer dan 1 miljoen ondertekende domeinnamen

• oktober 2012: Slechts een enkele internet provider valideert

• juni 2013: Aantal ondertekende .nl-domeinnamen breekt door 1,5 miljoen

• juli 2013: Onderzoek SIDN: gebrek aan kennis is belangrijkste belemmering voor implementatie DNSSEC

• september 2013: SIDN drie keer genomineerd voor een CENTR Award, twee keer voor DNSSEC-gerelateerde projecten

• oktober 2013: DNSSEC (en IPv6) vanaf 2014 verplicht bij ICANN

• januari 2014: 1,7 miljoen .nl-domeinnamen ondertekend

• januari 2014: Helft van alle top-level domeinen nu ondertekend

• mei 2014: Campus Challenge: vijf nieuwe DNSSEC-implementaties

• september 2014: Eenderde van alle .nl-domeinnamen met DNSSEC beveiligd

• september 2014: DNSSEC-inventarisatie 2014: financials, grote ondernemingen, overheden en ISP's moeten aan de slag

• december 2014: Twee miljoen .nl-domeinnamen ondertekend

• augustus 2015: Slechts een kwart van nationale overheidsdomeinen in Europa met DNSSEC beveiligd

• oktober 2015: Nederland zet in op internetveiligheid tijdens EU-voorzitterschap

• november 2015: Olaf Kolkman ontvangt NLUUG Award, mede vanwege bijdragen aan DNSSEC

• december 2015: SIDN ververst .nl zone elk uur

• oktober 2016: STARTTLS en DANE verplicht voor overheidsorganisaties

• maart 2017: DNSSEC-inventarisatie 2017: banken en internet-sector lopen ernstig achter

• maart 2017: Overheid en bedrijfsleven richten 'Veilige E-mail Coalitie' op

• april 2017: SIDN ververst .nl zone elk half uur

• mei 2017: Ondersteuning DANE neemt snel toe; NCSC adviseert inschakelen STARTTLS en DANE

• juli 2017: Ook Belgische banken scoren heel slecht op DNSSEC-beveiliging

• november 2017: DNSSEC-adoptie bij overheden stagneert, ondanks verplichtingen en beloften

• februari 2018: DANE als standaard voor aanbestedingen erkend door de EC

DNSSEC-validatiefouten worden veroorzaakt door een mismatch tussen de cryptografische (publieke) sleutel die geregistreerd staat bij het bovenliggende domein (de parent) en de (private) sleutel die daadwerkelijk gebruikt wordt om een zone te ondertekenen. Omdat de chain of trust nu niet kan worden gesloten zal een validerende resolver verkeer naar de betreffende domeinnaam blokkeren. Hetzelfde gebeurt wanneer er wel een sleutel bij de parent is geregistreerd maar de zone helemaal niet (meer) ondertekend is. Het resultaat is in beide gevallen een zogenaamd 'bogus domain'.

Hoewel DNSSEC hier precies doet waarvoor het bedoeld is, namelijk het blokkeren van DNS-informatie waarvan de ondertekening niet in orde is, wekken deze 'false positives' veel irritatie op. Een internetgebruiker die een bepaald domein niet kan bereiken (terwijl gebruikers van niet-validerende DNS-servers dat wel kunnen) belt naar zijn goedwillende access provider, die hem vervolgens niet kan helpen. Het probleem wordt immers veroorzaakt door een configuratiefout die in het algemeen bij een andere (service) provider ligt. Voor sommige access providers was een relatief hoog aantal validatiefouten op de .nl-zone ooit reden om DNSSEC-validatie op hun caching DNS-servers (nog) niet aan te zetten, of in een enkel geval zelfs weer uit te zetten.

"Bogus" domeinnamen werden vooral veroorzaakt door verhuizingen van de ene naar de andere registrar. Door een standaard instelling ("het vinkje") in het DomeinRegistratieSysteem (DRS) bleef het sleutelmateriaal van de oude registrar bij SIDN staan als de nieuwe registrar daar niet specifiek actie op ondernam.

Uit eigen onderzoek bleek dat het met name ging om registrars met veel resellers. Het relatief hoge aantal beschadigde DNSSEC-domeinen destijds lijkt dan ook niet te wijten aan onwil of onprofessionaliteit van de registrar, maar een gevolg van hun business model.

Omdat het relatief hoge aantal DNSSEC-configuratiefouten in de .nl-zone destijds een rem was op het aanzetten van validatie door accessproviders hebben wij veel aandacht besteed aan het oplossen van dit probleem. Daarvoor werden de registrars die verantwoordelijk waren voor de meeste validatiefouten op de hoogte gesteld van problematische configuraties in hun bestand en als het nodig was nagebeld.

Daarbij maakten we in eerste instantie gebruik van resolver logs die door een paar grote accessproviders specifiek voor dit doel werden aangeleverd. Inmiddels gebruiken we hiervoor de zelfontwikkelde Validation Monitor XXL, die elke nacht alle .nl-domeinen controleert op validatiefouten. De uitkomsten daarvan zijn ook onderdeel van de Registrar Scorecard (RSC).

Op dit moment is het aantal DNSSEC-ondertekende domeinen met problemen nog maar een verwaarloosbare fractie van wat het destijds was. Validatiefouten vormen inmiddels geen enkele belemmering meer voor het valideren door accessproviders. Met het toenemen van het aantal validerende providers verschuiven de consequenties van deze problematiek ook naar de plek waar deze thuishoren: bij de registrar en operator van het betreffende domein. Hun klanten zullen dan klagen dat ze (voor een groot deel van de internetgebruikers) niet bereikbaar zijn.

DLV, kort voor Dynamic Lookaside Validation, was een methode om DNSSEC records onder een alternatieve zone (dlv.isc.org.) te kunnen opzoeken en valideren. Voordat in 2010 de rootzone (.) ondertekend werd, werd deze "hack" gebruikt om de hele DNS-boom via een omweg toch onder één enkel trust anchor te brengen.

Daartoe onderhield het Internet Systems Consortium (ISC), onder andere de ontwikkelaar van BIND, een alternatieve repository voor sleutelmateriaal. Daar konden DNSKEY-records worden ingediend, dezelfde records die SIDN voor het .nl-domein gebruikt. Zij fungeerden als input voor de DS records die uiteindelijk door de registry gepubliceerd werden. Subdomeinen onder dlv.isc.org. authentiseerden de ingediende records voor hun locale root door een speciaal TXT-record in hun nameservers op te nemen.

Op deze manier konden verschillende DNS-deelbomen die niet helemaal tot aan de absolute root gevalideerd konden worden (zogenaamde 'islands of trust') toch van een gemeenschappelijk trust anchor worden voorzien. Omdat de vertrouwensketen ('chain of trust') via een andere route loopt, moesten voor validatie wel steeds extra DNS-query’s op een compleet andere zone worden uitgevoerd.

Hoewel DLV in eerste instantie door ISC was ontwikkeld als onderdeel van de BIND software, werd dit protocol (vastgelegd in RFC 5074 en 4431) ook door sommige andere DNS-pakketten ondersteund, waaronder Unbound. De ondersteuning voor DLV bleef echter beperkt.

De DLV-dienst is inmiddels niet meer relevant en is in september 2017 opgeheven. Vanaf versie 9.16.0 is alle DLV-gerelateerde code ook uit BIND verwijderd.

Sinds de ondertekening van de root zone (.) in 2010 is er één enkel, officieel trust anchor beschikbaar dat door iedereen gebruikt kan worden. Daarmee was DLV in principe niet meer nodig, ware het niet dat het voor veel topleveldomeinen nog jaren heeft geduurd voordat zij ondertekend waren.

Vanaf 2014 waren nieuwe topleveldomeinen verplicht om DNSSEC (en IPv6) te ondersteunen. En inmiddels wordt DNSSEC (ondertekening) door ruim 90 procent van alle ccTLD's ondersteund (situatie december 2022). Opvallende uitzondering is Turkije (.tr). Maar het zijn vooral ccTLD's in de Balkan, Afrika, het Midden-Oosten en Centraal-Azië die DNSSEC nog niet ondersteunen.

De DLV-functie wordt inmiddels niet meer gebruikt. In 2016 was ISC al gestopt met de registratie van nieuwe domeinnamen waarvan het topleveldomein DNSSEC ondersteunt, en zijn al die al eerder geregistreerde domeinnamen uit de repository verwijderd. In 2017 is de DLV repository helemaal geleegd; alleen de (lege) service werd daarna nog een poosje in de lucht gehouden.

Vanaf versie 9.16.0 is alle DLV-gerelateerde code ook uit BIND verwijderd.

• algemene informatie over DNSSEC op Wikipedia:

  • https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

• professionele informatie over DNSSEC op dnssec.net:

  • http://www.dnssec.net/

• het DNSSEC Deployment Initiative:

  • https://www.dnssec-deployment.org/

• de standaarden voor DNSSEC zoals vastgelegd in RFC's bij de IETF:

  • http://tools.ietf.org/html/rfc4033

  • http://tools.ietf.org/html/rfc4034

  • http://tools.ietf.org/html/rfc4035

  • http://tools.ietf.org/html/rfc5155 (NSEC3)

  • http://tools.ietf.org/html/rfc8080 (ECDSA-cryptografie)

• DNSSEC-Tools, een verzameling tools voor beheerders, clients en software-ontwikkelaars:

  • http://www.dnssec-tools.org/

• meer dan 30 hands-on artikelen over DNSSEC (door Johannes Weber):

  • Basic DNS and DNSSEC Validation:

    • Basic BIND Installation

    • BIND DNSSEC Validation

    • DNSSEC Validation with Unbound on a Raspberry

    • Pi-hole Installation Guide

    • DNS Capture: UDP, IP-Fragmentation, TCP, EDNS, ECS, Cookie

    • Single DNS Query – Hundreds of Packets

  • DNSSEC Signing:

    • DNSSEC Signing with BIND

    • Signing a Delegated Subdomain

    • DNSSEC with NSEC3

    • DNSSEC ZSK Key Rollover

    • DNSSEC KSK Key Rollover

    • DNSSEC KSK Emergency Rollover

    • Signed DNS Zone with too long-living TTLs

    • BIND Inline-Signing Serial Numbers Cruncher

  • DNSSEC Extensions:

    • How to use DANE/TLSA

    • SSHFP: Authenticate SSH Fingerprints via DNSSEC

      • SSHFP behind CNAME

      • SSHFP: FQDN vs. Domain Search/DNS-Suffix

      • Generating SSHFP Records Remotely

    • CAA: DNS Certification Authority Authorization

    • PGP Key Distribution via DNSSEC: OPENPGPKEY

  • Test & Troubleshooting:

    • Dive into delv: DNSSEC Validation

    • Compare & Troubleshoot DNS Servers: dnseval

    • Detect DNS Spoofing: dnstraceroute

    • DNS Test Names & Resource Records

    • DNS Capture – The Records Edition

    • How to walk DNSSEC Zones: dnsrecon

    • All-in-One DNS Tool: Domain Analyzer

    • Benchmarking DNS: namebench & dnseval

• NCSC factsheet "Bescherm domeinnamen tegen phishing"

• DANE SMTP checker voor mail:

  • https://github.com/vdukhovni/danechec

• ondersteuning van DKIM, SPF en DMARC in Exchange 2016 (door Jaap Wesselius):

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III

Op de Internet.nl-portal kun je je verbindingen en domeinen testen op de toepassing van 6 moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een gecombineerde totaalscore, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance".

SIDN heeft in de loop der tijd een hele serie hands-on artikelen gepubliceerd over zowel de DNSSEC-ondertekening op autoritatieve nameservers:

• DNSSEC-ondertekening op BIND named

• DNSSEC-ondertekening op de PowerDNS Authoritative Server

• DNSSEC-ondertekening op een Infoblox appliance

als de validatie op (caching) resolvers:

• DNSSEC-validatie met Unbound en DNSSEC-Trigger

• DNSSEC-validatie op BIND named

• DNSSEC-validatie met de PowerDNS Recursor

• DNSSEC-validatie op een Infoblox appliance

Een overzicht van de belangrijkste kenmerken van deze softwarepakketten vind je hier.

Daarnaast publiceert SIDN regelmatig nieuwsberichten, technische artikelen, rapporten en cases over DNSSEC op sidn.nl.

Heb je DNSSEC eenmaal geïmplementeerd, dan bieden we ook een serie hands-on artikelen over de implementatie van de mailbeveiligingsstandaarden SPF/DKIM/DMARC en STARTTLS/DANE voor Postfix en Exim (de 2 meest gebruikte mailservers):

• De implementatie van SPF, DKIM en DMARC in Exim

• De implementatie van SPF, DKIM en DMARC voor Postfix

• De implementatie van DANE op Exim

• De implementatie van DANE voor Postfix

Voor de onderlinge samenhang van al die moderne standaarden, onderlinge afhankelijkheden, en prioriteiten ten opzichte van elkaar, verwijzen we je tenslotte naar ons maturitymodel: