Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

DNSSEC veelgestelde vragen (FAQ)

Algemeen

Voor wie is deze FAQ bestemd?

Deze FAQ is bestemd voor mensen die meer over DNSSEC willen of moeten weten: DNS-beheerders, houders van een .nl-domeinnaam, netwerkbeheerders en IT-managers. U vindt hier informatie over het belang en de werking van DNSSEC. De tekst gaat ervan uit dat u bekend bent met het DNS-systeem en bijbehorende technische terminologie.

Voor een hele toegankelijke FAQ over DNSSEC gericht op een breed publiek verwijzen we graag naar de collega's van Internet.nl:

Wat is DNSSEC?

DNSSEC is een cryptografische beveiliging voor het DNS-protocol. Het Domain Name System verzorgt de vertaling van domeinnamen naar IP-adressen (en andersom). Zo moet je computer (de client) een name-server raadplegen voor het adres www.sidn.nl alvorens contact te kunnen zoeken met de web-server op het IP-adres 213.136.31.220. 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.

Waarom is DNSSEC voor mij als houder van een .nl-domeinnaam belangrijk?

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 internet-dienst, laat staan een kraak, levert zowel reputatie- als zakelijke/financiële schade op.

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

DNSSEC beschermt de name-server en het transport van de DNS-informatie. Dat is voor aanbieders van internet-diensten een garantie dat verkeer van bezoekers inderdaad op de juiste plaats terecht komt.

Waarom is DNSSEC voor mij als internet-gebruiker belangrijk?

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

Weet een kwaadwillende de DNS-informatie op de name-server, onderweg of bij de client te veranderen, dan kan hij de internet-gebruiker naar een identieke maar valse web-server 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 login-gegevens, of persoonlijke of zakelijke informatie worden buitgemaakt.

DNSSEC beschermt de name-server en het transport van de DNS-informatie. Dat is voor de gebruiker een garantie dat zijn internet-verkeer op de juiste plaats terecht komt.

Wie gebruikt DNSSEC?

Nederland is wereldwijd een van de koplopers als het gaat om de ondertekening van domeinnamen. Inmiddels is bijna de helft van alle .nl-domeinen met DNSSEC beveiligd. Dat hebben we met name te danken aan de registrars die sinds de officiële introductie van DNSSEC in 2012 de door hun beheerde domeinnamen in bulk ondertekend hebben. Dat aantal beveiligde domeinnamen stijgt nog steeds gestaag door [1, 2, 3]. Uit een in 2014 gemaakte inventarisatie bleek dat er wel grote verschillen zijn tussen de verschillende sectoren.

Wat betreft de validatie van DNSSEC — het controleren van de digitale handtekening onder de DNS-informatie door de client — lopen we in Nederland achter op de rest van de wereld. Er zijn inmiddels meerdere internet-providers die DNSSEC valideren voor hun klanten, maar de meeste zijn nog niet zo ver. Op dit moment wordt door meerdere grote internet access providers wel gewerkt aan de implementatie van DNSSEC-validatie op hun caching DNS-servers. We verwachten dat zij deze beveiliging binnenkort officieel onderdeel zullen maken van hun DNS-dienst.

DNSSEC is in 2012 door het Forum en College 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. Alle registries en door ICANN geaccrediteerde registrars zijn vanaf 2014 verplicht DNSSEC te ondersteunen in hun EPP- en web-interfaces. Hun klanten moeten sleutelmateriaal kunnen toevoegen, wijzigen en verwijderen. Dergelijke ontwikkelingen laten zien dat DNSSEC op dit moment een integraal onderdeel van DNS aan het worden is.

SIDN Labs publiceert een webpagina met daarop diverse statistieken over het .nl-domein, waaronder ook die voor DNSSEC:

| - DNSSECstats-DNSSEC.png

Over DNSSEC

Is DNS onveilig?

Het DNS-protocol is veilig. Voorheen waren inbreuken alleen theoretisch van aard. In 2008 toonde Dan Kaminsky echter aan daadwerkelijk valse informatie in de caches van de meestgebruikte DNS-servers te kunnen injecteren. Maar op dit moment zijn de clients nog veruit het zwakste punt. Naarmate de veiligheid daar verbetert, zullen kwaadwillenden hun aandacht verleggen naar de name-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. Nederland vervult hierin een voortrekkersrol.

Hoe werkt DNSSEC?

DNSSEC is een voorwaarts compatibele uitbreiding van het DNS-protocol. Clients die deze beveiliging ondersteunen, ontvangen van de name-server adres-informatie voorzien van een digitale handtekening. De authenticiteit van deze DNS-records kan gecontroleerd worden met behulp van de publieke sleutel voor het betreffende domein. Deze wordt door de domeinnaamhouder (via zijn registrar) één niveau hoger in de DNS-hiërarchie geplaatst. Voor een .nl-domeinnaam staat de publieke sleutel dus op de name-servers van SIDN, de beheerder van het .nl top-level domein. Die sleutel wordt voor clients beschikbaar gemaakt in de vorm van een hash code. Daarmee kan een client verifiëren dat de publieke sleutel die hij bij de adres-informatie van de name-server ontvangt inderdaad dezelfde is als die door de houder of beheerder van de domeinnaam bij het registry is aangemeld. Zo wordt een 'keten van vertrouwen' (chain of trust) over de verschillende niveau's van de DNS-hiërarchie opgebouwd.

Wat merk ik als domeinnaamhouder van DNSSEC?

Domeinaamhouders 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 internet-gebruikers daar last van hebben.

Voor gebruikers die ook 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.

Wat merk ik als internet-gebruiker van DNSSEC?

Internet-gebruikers merken in eerste instantie niets van DNSSEC. Dit is vooral een technische aangelegenheid voor de resolver, het onderdeel van het besturingssysteeem 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 internet-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.

Waar beschermt DNSSEC niet tegen?

DNSSEC beschermt de name-server en het transport van de DNS-informatie naar de client. De client zelf is echter niet beveiligd. Is een PC bijvoorbeeld besmet met malware, dan zijn meestal ook de 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.

Op dit moment is de client nog veruit de zwakste schakel in de hele keten. Maar naarmate de veiligheid daar verbetert, zullen kwaadwillenden hun aandacht verleggen naar de name-servers en het transport van de DNS-informatie. Bovendien zijn de afgelopen jaren de eerste haarscheurtjes in de veiligheid van het DNS-protocol verschenen. Meest alarmerend was het gat dat Dan Kaminsky in 2008 aantoonde: hij liet zien hoe kwaadwillenden daadwerkelijk valse informatie in de caches van de meest gebruikte DNS-servers konden injecteren. Hiertegen biedt DNSSEC een sterke cryptografische beveiliging.

Implementatie

Hoe beveilig ik mijn .nl-domeinen met DNSSEC?

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

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

Doet men het beheer van de DNS-informatie zelf — dat wil zeggen dat men eigen DNS-servers heeft staan — dan begint de implementatie met het genereren van een cryptografisch sleutelpaar. De private sleutel wordt gebruikt om de records te ondertekenen. De publieke sleutel moet men via het administratieve dashboard van de registrar of internet service provider uploaden naar SIDN. De beheerder van het .nl top-level domein heeft deze mogelijkheid inmiddels opgenomen in zijn interface voor de registrars. Registrars en internet service providers kunnen het invoerveld voor de publieke sleutel nu dus bij de invoervelden voor de name-servers aan hun klanten aanbieden in hun administratieve dashboards.

Wordt DNSSEC ondersteund door mijn DNS-software?

Alle veelgebruikte DNS-servers ondersteunen inmiddels DNSSEC. Zij voorzien ook in tools voor het genereren van de sleutelparen en het ondertekenen van de records. Bij BIND, de meest gebruikte DNS-server, worden 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 opties bieden voor het automatiseren van ondertekening en sleutelbeheer, kunnen we 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 de 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.

DNSSEC test

Hoe controleer ik als beheerder de werking van DNSSEC?

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

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

dnsviz: sidn.nl

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

SIDN Labs heeft een online tool beschikbaar waarmee een hele lijst van .nl-domeinnamen in één keer gecontroleerd kan worden:

DNSSEC test

Hoe controleer ik als internet-gebruiker de werking van DNSSEC?

Internet-gebruikers die willen controleren of de DNS-informatie die ze gebruiken tijdens het browsen beveiligd is met DNSSEC, kunnen naar de test-pagina die SIDN daarvoor online heeft gezet:

Let wel: als DNSSEC niet ondersteund wordt, wil dat niet noodzakelijk zeggen dat de eigen 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 internet access provider.

Hoe zit het bij verhuizing van een beveiligd domein?

Bent u van plan om een ondertekend domein te verhuizen, dan moet u om te beginnen verifiëren dat uw nieuwe aanbieder ook DNSSEC ondersteunt. Doet u dat niet, dan zou u de DNSSEC-beveiliging kunnen verliezen. In het slechtste geval zou het domein ook onbereikbaar kunnen worden. Clients accepteren immers geen DNS-informatie die ondertekend zou moeten zijn maar dat niet is.

Daarnaast heeft een naadloze verhuizing — dat wil zeggen zonder de beveiliging te verbreken — nogal wat organisatorische voeten in de aarde, met name als het DNS-beheer voor een domein door een (externe) internet service provider wordt verzorgd. De nieuwe operator gebruikt immers een nieuw sleutelpaar om de DNS-informatie te ondertekenen.

Gelukkig is er inmiddels een procedure voor het verhuizen van beveiligde domeinen beschikbaar. SIDN Labs heeft in de ontwikkeling daarvan een belangrijke rol gespeeld. De procedure voor een naadloze verhuizing is vergelijkbaar met een key roll-over, zij het over verschillende partijen verdeeld.

Om een verhuizing probleemloos te laten verlopen, moeten gedurende de overlap van een paar dagen de publieke sleutels van beide operators als DS record via de TLD-beheerder beschikbaar zijn. Bovendien moeten beide publieke sleutels als DNSKEY bij beide operators opgevraagd kunnen worden. Daarvoor zullen zij voor de verhuizing dus een en ander moeten uitwisselen. SIDN heeft daarvoor een digitaal doorgeefluik in zijn interface geïmplementeerd.

Pas als de nieuwe DS en DNSKEY records overal zichtbaar zijn, kunnen de NS records bij de TLD-beheerder worden omgezet naar de nieuwe name-servers. Als dan alle oude NS records zijn verlopen, kan de configuratie op de oude name-servers worden verwijderd, later gevolgd door het oude DS record (bij de TLD-beheerder) en de oude DNSKEY (op de nieuwe name-server). Hoewel dit nogal wat communicatie, afstemming en uitwisseling vraagt, is het goed mogelijk om dit protocol te automatiseren. De daarvoor benodigde ondersteuning bij SIDN is al beschikbaar. Aan de implementatie van dit verhuisprotocol in DNS-server software wordt gewerkt.

Validatie

Hoe valideer ik DNSSEC-beveiligde domeinen?

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 DNS-servers betrokken bij de domeinnaam — de zogenaamde 'chain of trust' — maar ook voor de caching DNS-servers bij de internet access provider en de client bij de eindgebruiker.

De meeste clients bevatten zelf alleen een stub-resolver en laten de recursieve queries — en dus de validatie — over aan de caching DNS-servers die ze via DHCP van de provider of netwerkbeheerder toegewezen krijgen. Hier in Nederland zijn Edutel en BIT op dit moment (najaar 2015) echter de enige providers die DNSSEC op hun netwerk verifiëren.

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 dnssec-trigger of een browser-plugin moeten installeren. Nog een alternatief is Bloodhound, een versie van de Firefox browser met ingebouwde validatie voor DNSSEC en DANE. We verwijzen hiervoor graag naar de collega's van Internet.nl:

DNSSEC beschermt echter alleen de name-server en het transport van de DNS-informatie naar de client. De client zelf is niet beveiligd. Als je desktop met malware is besmet, dan is geen enkel programma — en dus ook niet de resolver — te vertrouwen. Zo kan sommige malware de hosts-tabel aanpassen, waarmee DNS compleet omzeild wordt.

Wie valideert DNSSEC?

Hier in Nederland zijn Edutel en BIT op dit moment (najaar 2015) de enige providers die DNSSEC op hun netwerk valideren. Andere organisaties die valideren zijn RijksDNS, de Gemeente 's-Hertogenbosch, de Universiteit Twente, de Rijksuniversiteit Groningen en het CWI.

Op dit moment wordt door meerdere grote internet access providers gewerkt aan de implementatie van DNSSEC-validatie op hun caching DNS-servers. We verwachten dat zij deze beveiliging binnenkort officieel onderdeel zullen maken van hun DNS-dienst. Tot die tijd kunnen eindgebruikers ook gebruik maken van Google's Public DNS service.

Waartoe dient de AD-vlag?

De AD-vlag (Authentic Data) wordt gebruikt door (caching) DNS-servers 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-verzoek vraagt de (stub-)resolver om de DNSSEC 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 die records ook de AD-vlag terugsturen. 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 (paragraaf 3.1.6) bepaalt dat autoratieve servers geen validatie hoeven doen voor hun eigen domeinen. Zij mogen de AD-vlag dan wel zetten, maar alleen als zij hun autoratieve 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-antwoorden, nu kan de AD-vlag ook worden gebruikt in DNS-vragen. In paragraaf 5.7 van RFC 6840 kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-verzoeken uit te zetten. Nu levert het aanzetten van de AD-vlag in de DNS-vraag alleen informatie over de uitkomst van de validatie op (middels de AD-vlag in het DNS-antwoord), maar niet meer de DNSSEC records zelf. De netwerk-tool dig ondersteunt deze mogelijkheid inmiddels via de +adflag optie. De DO-vlag blijft zoals voorheen gebruikt worden om DNSSEC-informatie op te vragen.

Wanneer kun je de AD-vlag vertrouwen?

Het crypto-technische antwoord luidt natuurlijk: nooit! Omdat het traject tussen de (stub-)resolver en DNS-server in het algemeen niet is beveiligd, kan de inhoud van het DNS-antwoord via een man-in-the-middle 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.

Voor dit probleem van 'the last mile' zijn op dit moment verschillende oplossingen beschikbaar:

  • De uitwisseling van DNS-informatie kan beveiligd worden met TSIG (Transaction SIGnature). Dit protocol wordt vaak gebruikt om DNS records tussen autoratieve servers 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 voordehandliggende 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 service provider 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 en djbdns.
    DNSCrypt wordt met name ondersteund door OpenDNS en is beschikbaar voor Windows, Linux, Mac OS X 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.
  • Dan is DNS-over-TLS een veel logischer (want open) alternatief, maar vanwege de overhead net zo onelegant voor de versleuteling van het verkeer tussen resolver en DNS-server als Secure Dynamic Update.

Ondanks alle initiatieven van de afgelopen tien jaar, lijkt het erop dat geen van deze technologieën uiteindelijk ingezet zal worden om 'the last mile' te beveiligen. Hoewel het voordehandliggend (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 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.

Waar is de AD-vlag dan wel te gebruiken?

De AD-vlag is wel te gebruiken op een netwerk waar de beveiliging van 'the last mile' gegarandeerd is. Denk dan aan bedrijfsnetwerken, campusnetwerken, en gesloten netwerken van internet-providers en mobiele operators. Daar kan DNSSEC-validatie samen met DNS-caching gecentraliseerd worden op de recursing DNS-servers. Niet voor niets worden DNSSEC records wel door Google's Public DNS service gecached en verstuurd, maar wordt de AD-vlag nooit gezet. Zij kunnen het tussenliggende traject immers niet garanderen.

Moet ik DNSSEC zelf blijven valideren?

De meeste clients bevatten zelf alleen een stub-resolver en laten de recursieve queries — en dus de validatie — over aan de caching DNS-servers die ze via DHCP van de internet access provider of netwerkbeheerder toegewezen krijgen. Die clients vertrouwen dus op de AD-vlag die door de DNS-servers na validatie aan de records wordt meegegeven. Meestal blijft dus het traject tussen de stub-resolver en de DNS-server — de zogenaamde 'last mile' — onbeveiligd.

Dit probleem kan worden verholpen door de validatie op de client te laten uitvoeren. Daarmee wordt de beveiliging van DNS immers helemaal naar het eindpunt doorgetrokken. Ook als de provider of beheerder wel valideert, is het dus verstandig voor gebruikers om zelf de DNSSEC-handtekeningen te blijven verifiëren. De verwachting is dan ook dat de validatie op termijn standaard onderdeel zal zijn van elke resolver.

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 dnssec-trigger of een browser-plugin moeten installeren. Nog een alternatief is Bloodhound, een versie van de Firefox browser met ingebouwde validatie voor DNSSEC en DANE. We verwijzen hiervoor graag naar de collega's van Internet.nl:

DNSSEC beschermt echter alleen de name-server en het transport van de DNS-informatie naar de client. De client zelf is niet beveiligd. Als je desktop met malware is besmet, dan is geen enkel programma — en dus ook niet de resolver — te vertrouwen. Zo kan sommige malware de hosts-tabel aanpassen, waarmee DNS compleet omzeild wordt.

Wat is het nut van browser-plugins voor DNSSEC-validatie?

De meeste clients bevatten zelf alleen een stub-resolver en laten de recursieve queries — en dus de validatie — over aan de caching DNS-servers die ze via DHCP van de internet access provider of netwerkbeheerder toegewezen krijgen. Die clients vertrouwen dus op de AD-vlag die door de DNS-servers na validatie aan de records wordt meegegeven. 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 in de toekomst de standaard gaat worden. Daarmee wordt immers het probleem van 'the last mile' verholpen. Daarnaast kunnen web-browsers en andere applicaties op de client zelf nog valideren. Zij kunnen de gebruiker dan ook een inhoudelijke foutmelding geven.

Er zijn DNSSEC-plugins beschikbaar voor de meest gebruikte web-browsers. Deze werken parallel aan de resolver op de client en kunnen dus een heel andere respons geven dan de lokale resolver. Sterker nog, sommige plugins kunnen zo worden geconfigureerd dat ze van een hele andere DNS-server gebruikmaken. Waar een validerende resolver een beveiligd domein hard blokkeert als er iets mis blijkt te zijn, moeten deze plugins dus vooral als indicatief worden gezien.

Eindgebruikers die een gegarandeerd veilige DNS-resolver willen, zullen daarvoor zelf dnssec-trigger of een browser-plugin moeten installeren. Nog een alternatief is Bloodhound, een versie van de Firefox browser met ingebouwde validatie voor DNSSEC en DANE. We verwijzen hiervoor graag naar de collega's van Internet.nl:

DNSSEC beschermt echter alleen de name-server en het transport van de DNS-informatie naar de client. De client zelf is niet beveiligd. Als je desktop met malware is besmet, dan is geen enkel programma — en dus ook niet de resolver — te vertrouwen. Zo kan sommige malware de hosts-tabel aanpassen, waarmee DNS compleet omzeild wordt.

Technisch

Hoe werkt het DNSSEC-protocol?

DNSSEC, kort voor DNS Security Extensions, is een uitbreiding op het bestaande Domain Name System (DNS). Daarbij worden de records cryptografisch ondertekend, zodat internet-gebruikers zeker weten dat de IP-adressen die ze voor een bepaalde domeinnaam terugkrijgen naar de juiste servers wijzen.

Voor DNSSEC is een aantal nieuwe records aan het DNS-protocol toegevoegd. RRSIG bevat de handtekening die met elk DNS-antwoord (RR: Resource Record) wordt meegestuurd. DNSKEY bevat de publieke sleutel waarmee die handtekening op echtheid kan worden gecontroleerd. En het DS record (Delegation Signer) wordt gebruikt om de echtheid van de publieke sleutel weer te controleren bij de beheerder van het hogerliggende domein. Zo wordt een 'keten van vertrouwen' (chain of trust) over de verschillende niveaus van de DNS-hiërarchie opgebouwd, bestaande uit gelinkte DNSKEY en DS records. De NSEC(3) en NSEC3PARAM records (Next Secure) tenslotte worden gebruikt om mogelijk gevoelige informatie over de gebruikte adressen (systemen) binnen een domein af te schermen.

Hoe werkt de 'chain of trust'?

De 'chain of trust' refereert naar de keten van vertrouwen die middels DNSSEC wordt opgebouwd over de verschillende niveaus van de DNS-hiërarchie. Clients ontvangen van de name-server adres-informatie 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 geplaatst, 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 name-servers desgevraagd een ondertekende hash code (een digitaal uittreksel, in een DS record) van de publieke sleutel. Daarmee kan een client verifiëren dat de publieke sleutel die hij bij de ondertekende adres-informatie van de name-server ontvangt inderdaad dezelfde is als die door de houder van de betreffende domeinnaam bij de beheerder van het hogerliggende domein is geregistreerd.

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 daaronder. Wie de key signing ceremony voor de root servers bekijkt, ziet hoe serieus deze zaak wordt genomen.

Hoe werkt een digitale handtekening?

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 dnssec.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.

Wat is het verschil tussen KSK- en ZSK-sleutels?

Voor het ondertekenen van de DNS records is in principe één cryptografisch sleutelpaar voldoende. De private key wordt gebruikt om de DNS records te ondertekenen (in de RRSIG records), 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 ondertekende DNS records controleren. Hetzelfde DNSKEY record wordt via de registrar ook naar de beheerder van het hogerliggende domein geupload. 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.

Single key pair

In de praktijk wordt meestal met twee van deze sleutelparen gewerkt. Het ZSK-paar (de Zone Signing Keys) wordt dan gebruikt om de DNS records te ondertekenen en te valideren. Deze worden per zone gegenereerd, zodat ze makkelijk vervangen of ververst kunnen 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 geupload, maar wordt deze ondertekend met de private key van het KSK-paar (Key Signing Keys). Daarvan wordt dan de public key naar de beheerder geupload, die deze vervolgens ondertekent en als DS record publiceert.

Double key pair

In deze getrapte configuratie hoeft men bij vervanging van het ZSK-paar nooit het sleutelmateriaal opnieuw te uploaden. 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.

Wat is NSEC/NSEC3?

Normaal gesproken geven name-servers alleen informatie aan een client die heel specifiek naar een bepaald adres vraagt. Bestaat dat adres niet, dan geeft een niet-beveiligde name-server gewoon een foutmelding als antwoord. Op die manier kan een buitenstaander nooit informatie krijgen over alle adressen (systemen) binnen een domein. Dat kan immers informatie zijn die de veiligheid aantast.

Voor DNSSEC levert dit echter een probleem op. Ook het antwoord (een foutmelding) voor een niet-bestaand adres moet immers ondertekend zijn. Maar dat zou dan dynamisch moeten gebeuren, omdat het natuurlijk onmogelijk is voor alle niet-bestaande adressen op voorhand een ondertekende foutmelding te genereren. Daarmee zou DNSSEC niet alleen een bijzonder processor-intensieve aangelegenheid worden maar ook kwetsbaar voor denial-of-service aanvallen.

NSEC (Next Secure) was een eerste poging om dit probleem op te lossen. Met het genereren van de ondertekende records werden ook NSEC records aangemaakt voor de complete tussenliggende gebieden. Daarmee werd het echter mogelijk om alle adressen binnen een domein af te lopen en te inventariseren (name walking).

NSEC3, kort voor DNSSEC Hashed Authenticated Denial of Existence, lost dit op door niet langer de adressen zelf maar een hash code (een digitaal uittreksel) daarvan te nemen. Een client die nu naar een niet-bestaand adres informeert, krijgt niet langer een bereik tussen twee bestaande adressen te zien. Hij ziet alleen hun hash codes, die niet kunnen worden terugherleid naar de originele adressen.

Hoe werkt een Kaminsky-aanval?

Voorheen waren inbreuken op het DNS-protocol alleen theoretisch van aard. Maar in 2008 toonde Dan Kaminsky 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 Kaminsky-aanval maakt 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 name-server gebruikt om DNS-vragen en -antwoorden aan elkaar te koppelen. Een aanvaller kan dus grote hoeveelheden valse antwoorden met een willekeurige transaction ID op een client afsturen, wachtend op het moment dat deze de "bijbehorende" vraag naar de name-server stuurt. Als een vals antwoord met toevallig de juiste transaction ID bij de resolver binnenkomt voor het antwoord van de echte name-server arriveert, dan wordt een vals IP-adres in de cache van de client gezet.

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

Organisatorisch

Hoe werkt de keten ISP — registrar — SIDN?

SIDN (Stichting Internet Domeinregistratie Nederland) is de organisatie die verantwoordelijk is voor het beheer van het .nl top-level domein en de doorverwijzingen voor alle .nl-domeinen. Zij 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: een kleine tweeduizend 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 web-interface) van hun internet service provider.

Hoe veilig is DNSSEC?

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

Het hele systeem is echter zo veilig als de zwakste schakel. Op dit moment is de client nog steeds het meest kwestbare onderdeel. Is een PC bijvoorbeeld besmet met malware, dan zijn meestal ook de resolver (het onderdeel van het besturingssysteem op de client dat verantwoordelijk is voor de vertaling van domeinnamen naar IP-adressen) en de lokale 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 veranderen of een extra sleutel/handtekening kunnen toevoegen. In dat laatste geval lijkt het voor de buitenwereld alsof er een verhuizing aan de gang is, maar zijn bezoekers van het domein kwetsbaar voor een man-in-the-middle aanval.

Een aanpassing van het geregistreerde sleutelmateriaal zou in principe uitgevoerd kunnen worden door een (digitale) inbreker, een medewerker van SIDN, iemand in de aanleverketen (internet service provider — registrar), of op verzoek van de overheid.

Hoe betrouwbaar is SIDN?

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 internet service providers. Inbreuk op de haar toevertrouwde functie zou alleen kunnen worden afgedwongen na een gerechtelijk bevel, maar dat is tot op heden nog nooit voorgekomen.

DNSSEC en verder

Welke andere protocollen maken gebruik van DNSSEC?

DNSSEC omhelst veel meer dan alleen het beveiligen van de DNS-records. Met DNSSEC wordt een infrastructuur aangelegd die in de toekomst door tientallen andere protocollen gebruikt kan worden om cryptografisch beveiligde informatie over te dragen of bestaande internet-protocollen kan versterken.

Voorbeeld is het drietal DKIM/SPF/DMARC dat phishing, spam, virussen en andere malware tegengaat door de afzender, de verzender en de inhoud van een bericht te beveiligen. Daarvoor worden diverse nieuwe records in de DNS-informatie opgenomen. Hoewel ondertekening met DNSSEC voor deze toepassing niet strikt noodzakelijk is, is dat wel een belangrijke toevoeging.

Ander voorbeeld is het DANE-protocol dat gebruikt wordt om versleutelde internet-verbindingen van een extra beveiliging te voorzien. Het bijbehorende TLSA record vormt een aanvullende vertrouwensketen voor de X.509 server-certificaten 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.

DANE

Wat is DANE?

DANE, kort voor DNS-based Authentication of Named Entities, is een protocol voor het veilig publiceren van publieke sleutels en certificaten. Daarbij bouwt deze standaard verder op de cryptografisch beveiligde DNS-infrastructuur die met DNSSEC wordt aangelegd.

Hoe werkt DANE?

Voor DANE is het DNS-protocol uitgebreid met het TLSA record. Dat kan worden gebruikt om sleutelinformatie — bijvoorbeeld een hash code, een digitaal uittreksel — aan een adres/protocol/poort-combinatie te koppelen. Op die manier kan van elke versleutelde internet-service de authenticiteit van het server-certificaat via DNS worden geverifieerd. Komt de hash code van het server-certificaat niet overeen met de hash code in het TLSA record, dan weet de client dat de verbinding niet te vertrouwen is.

Wie gebruikt DANE?

Hoewel DANE breder inzetbaar is, doet het protocol op dit moment zijn eerste intrede in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). Met name die laatste toepassing heeft het afgelopen jaar (we schrijven dit najaar 2015) opgang gevonden met de ondersteuning van DANE-validatie door de Postfix mail server.

Hoe beschermt DANE het web-verkeer?

Web-browsers zijn nu voor hun HTTPS-verbindingen volledig afhankelijk van de beveiliging bij de meer dan 150 Certificate Authorities (CA's). Het DigiNotar-debacle, waarbij een digitale inbreker meer dan 500 gewaarmerkte certificaten wist te genereren, heeft ons geleerd dat dit model slechts zo veilig is als de zwakste CA.

Met DANE wordt een parallelle veiligheidsinfrastructuur (vertrouwensketen) opgezet voor X.509, zoals het certificaten-systeem officieel heet. Dat kan straks niet alleen als aanvulling maar voor veel toepassingen ook als volledige vervanging fungeren. Op deze manier had de hele DigiNotar-affaire kunnen worden voorkomen.

Hoe beschermt DANE het mail-transport?

DANE voor mail is een zogenaamd opportunistisch protocol. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS-ondersteuning en TLSA records aanbiedt moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Voor mail is het afleveren van berichten immers belangrijker dan de beveiliging van het transport.

Wel impliceert de aanwezigheid van een TLSA record dat de mail server TLS ondersteunt, waarmee een downgrade-aanval op de STARTTLS capability van de server wordt voorkomen.

De Postfix mail server — na Exim de meest gebruikte MTA — kan zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX gateway. Dat betekent dat het aanmaken van een TLSA record voor de MX gateway op poort 25 direct een concrete verbetering van de veiligheid oplevert.

Hoe gebruik ik het TLSA record?

Het TLSA record is speciaal voor DANE aan de DNS-standaard toegevoegd. Het koppelt sleutelinformatie — bijvoorbeeld een hash code, een digitaal uittreksel — aan een adres/protocol/poort-combinatie. Op die manier kan van elke internet-service de authenticiteit van het server-certificaat via DNS worden geverifieerd.

Een TLSA record bevat niet veel meer dan een digitale vingerafdruk (een hash code) en informatie over de gebruikte cryptografische protocollen. De enige parameter die wat uitleg behoeft is de zogenaamde 'usage'. Deze geeft aan hoe de betreffende vingerafdruk geïnterpreteerd moet worden:

  1. PKIX-TA: Certificate Authority Constraint:
    verankert een specifiek CA-certificaat in de TLS vertrouwensketen (in aanvulling op de traditionele validatie),
  2. PKIX-EE: Service Certificate Constraint:
    verankert een specifiek server-certificaat (in aanvulling op de traditionele validatie),
  3. DANE-TA: Trust Anchor Assertion:
    verankert een specifiek CA-certificaat in de TLS vertrouwensketen, dat daarmee als trust anchor fungeert,
  4. DANE-EE: Domain Issued Certificate:
    verankert een specifiek server-certificaat, dat overeen moet komen met het door de server aangeboden certificaat.

Usage nummer 0 en 1 verankeren een certificaat van respectievelijk een CA of een server in aanvulling op de traditionele validatie met behulp van de trust anchors meegeleverd in de client (de browser). Daarmee wordt het probleem van de gekraakte CA gelocaliseerd (usage 0) of helemaal geneutraliseerd (usage 1). Bovendien worden op deze manier discrepanties tussen de twee vertrouwensketens gesignaleerd.

Usage 2 en 3 werken onafhankelijk van de traditionele TLS-validatie, en dat maakt ze geschikt voor self-signed certificaten. Bovendien kunnen op deze manier clients bediend worden die helemaal geen trust anchors aan boord hebben. Dat laatste geldt bijvoorbeeld voor SMTP clients.

Waarin verschilt DANE voor web en mail?

Hoewel DANE voor web en DANE voor mail erg op elkaar lijken, zijn er ook belangrijke verschillen. Waar het gebruik van 'https' in de URL impliceert dat TLS gebruikt moet worden, bestaat er niet zoiets voor mail. Uit een mail-adres of de MX records is immers niets af te leiden over de beveiliging van het transport. Wel impliceert de aanwezigheid van een TLSA record dat de SMTP gateway TLS ondersteunt, waarmee een downgrade-aanval op de STARTTLS capability van de gateway wordt voorkomen. Het gebruik van TLS door de client is echter optioneel, waarmee DANE voor mail een zogenaamd opportunistisch protocol blijft. Dat wil zeggen dat een client die zelf DNSSEC, DANE en STARTTLS ondersteunt zijn verbindingen met een server die STARTTLS-ondersteuning en TLSA records aanbiedt moet versleutelen. Maar ontbreekt een van deze onderdelen, dan vindt noodgedwongen een fallback naar TLS zonder DANE of zelfs een volledig onbeveiligd transport plaats. Zo wordt gewaarborgd dat het afleveren van berichten — waar immers geen mens aan te pas komt — zo veel mogelijk doorgang kan vinden.

DANE usage 0 en 1, waarbij het TLSA record wordt ingezet om een server-certificaat een extra verankering te geven, mogen voor DANE voor mail niet gebruikt worden. De PKI-verankering biedt voor mail geen meerwaarde ten opzichte van een self-signed certificaat met een TLSA-anker. Als DNS gecompromitteerd is, kan de aanvaller de TLSA records immers zodanig veranderen (in usage 2 of 3) dat de validatie van de PKI-vertrouwensketen sowieso niet meer vereist wordt.

Hoewel je voor DANE voor het web een vergelijkbare redenering kunt opzetten, gaan de auteurs van de standaard hierbij uit van de huidige situatie waarin mail clients in tegenstelling tot web-browsers niet een min-of-meer gestandaardiseerde verzameling trust anchors aan boord hebben. Bovendien is de rol van HTTPS en SMTP+TLS ook verschillend: voor transacties over het web is de versleuteling cruciaal, terwijl voor mail de betrouwbare aflevering meestal belangrijker is dan de beveiliging van het transport. Vandaar ook liever die opportunistische fallback in beveiliging dan een bounce van het mail-bericht. DANE voor mail is zo ontworpen dat het een transparante beveiliging toevoegt die geen extra configuratie, trust anchors of interactie met de gebruiker nodig heeft. De ontwerpers beschouwen DANE dan ook niet als een aanvulling maar als de opvolger en vervanger van PKI-verankering.

Wat als ik usage 0/1 (voor het web) toch gebruik?

De DANE-standaard schrijft voor dat bij usage 0 en 1 beide vertrouwensketens moeten valideren. Dat levert een probleem op als de ene keten wel en de andere niet goed valideert. Waarschijnlijk krijgt de internet-gebruiker in de toekomst een pop-up scherm met een waarschuwing en de optie om toch door te gaan, zoals dat nu ook al gebeurt bij problemen met een TLS-certificaat.

Is DANE een aanvulling op het CA-systeem, of de opvolger?

Hoewel DANE voor het web wel beschouwd wordt als de opvolger en vervanger van het gebrekkige en bewezen onveilige CA-systeem, hebben met name de EV-certificaten nog toegevoegde waarde. Ook omdat er nog jaren browsers zullen zijn zonder DANE-ondersteuning — waarbij self-signed certificaten resulteren in een waarschuwing — is de verwachting dat de CA-certificaten voorlopig niet zullen verdwijnen.

Wat is de status van DANE?

De DANE-specificatie is op dit moment (najaar 2015) nog net geen internet-standaard. Het protocol is vastgelegd in RFC 6698 en 7218. Daarmee is de technische specificatie van het DANE-protocol nagenoeg afgerond.

Hoe implementeer ik DANE voor web?

In principe kan voor alle web-servers die via HTTPS beveiligde verbindingen aanbieden een TLSA record aangemaakt worden.

Uitgebreide informatie over de configuratie van DANE voor web vindt u in dit hands-on artikel:

Voor zo ver ons bekend zijn er op dit moment (najaar 2015) nog geen web-browsers die out-of-the-box DANE-validatie doen op de certificaten van hun HTTPS-verbindingen. Wel is er een plugin beschikbaar die zowel DNSSEC als DANE valideert. Deze is ontwikkeld door de Tsjechische registry en beschikbaar voor alle populaire browsers:

| - www.offerman.com-FFplugin.png

Hoe implementeer ik DANE voor mail?

In principe kan voor alle mail servers die via TLS of STARTTLS beveiligde verbindingen aanbieden een TLSA record aangemaakt worden. De Postfix mail server — na Exim de meest gebruikte MTA — kan ook zo geconfigureerd worden dat deze DANE-validatie doet alvorens mail af te leveren bij een MX gateway. Dat betekent dat het aanmaken van een TLSA record voor de MX gateway op poort 25 direct een concrete verbetering van de veiligheid oplevert.

Uitgebreide informatie over de configuratie van DANE voor mail vindt u in dit hands-on artikel:

Voor zo ver ons bekend zijn er op dit moment (najaar 2015) nog geen mail clients die validatie doen op de certificaten voor hun POP-, IMAP- of SMTP-verbindingen.

DKIM, SPF en DMARC

Wat doen DKIM, SPF en DMARC?

DKIM, SPF en DMARC gaan phishing, spam, virussen en andere malware tegen door de afzender (een mail-adres), 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.

Het drietal DKIM/SPF/DMARC is de eerste concrete toepassing van de cryptografisch beveiligde infrastructuur die nu met DNSSEC wordt aangelegd.

Hoewel deze drie standaarden meestal gezamenlijk worden ingezet, hoeft dat niet persé. Je kunt ook alleen DKIM of SPF inzetten, of DMARC weglaten.

Hoe werkt DKIM?

DKIM voorziet de body en de header van elk uitgaand bericht van een digitale handtekening. De publieke sleutel wordt via DNS gepubliceerd, zodat een ontvangende MX gateway de digitale handtekening kan verifiëren. Zo wordt voorkomen dat kwaadwillenden een bericht namens een ander kunnen verzenden (mail spoofing) of de inhoud van een bericht onderweg kunnen veranderen (message integrity).

Hoe werkt SPF?

SPF voorkomt dat MX gateways mail-berichten accepteren van ongeauthoriseerde servers. Daartoe wordt een lijst van geldige adressen via DNS gepubliceerd. Dat zijn typisch de SMTP-gateways die eindgebruikers instellen voor hun uitgaande berichten, maar bijvoorbeeld ook de adressen van een externe dienstverlener die namens een organisatie marketing-mail verstuurd. Ontvangende systemen kunnen deze lijst van servers gebruiken om de verzender te controleren voor zij een bericht aannemen.

Hoe werkt DMARC?

DMARC is een aanvulling op de andere twee beveiligingsstandaarden voor mail, DKIM en SPF. DMARC geeft ontvangende MX gateways een aanwijzing (de policy) hoe om te gaan met inkomende berichten waarvoor DKIM of SPF geen geldige validatie oplevert. Deze kunnen bijvoorbeeld weggegooid worden of in quarantaine worden gezet.

De policy wordt via DNS gepubliceerd. Deze kan bovendien een e-mail adres bevatten waarop mail-systemen afgewezen berichten kunnen rapporteren. Zo krijgt de beheerder van het betreffende mail-domein inzicht in de aflevering van zowel echte als vervalste berichten.

De portal dmarcian.com biedt (tegen betaling) de mogelijkheid om de binnenkomende DMARC-rapportages te verwerken tot keurige statistieken en diagrammen.

| - dmarcian.com-screenshot-600x481.png

Wat is het belang van DKIM/SPF/DMARC?

Het drietal DKIM/SPF/DMARC maakt het mogelijk om de verwerking van mail veel efficiënter te maken. Grote mail-verwerkers kunnen de binnenkomende berichten uitsplitsen in twee grote bakken: berichten van ongeauthenticeerde domeinen of van wel geauthenticeerde domeinen die nog niet eerder gezien zijn enerzijds en bewezen gewenste mail-domeinen anderzijds.

Voor die laatste categorie is de verwerking simpel: die berichten kunnen gelijk afgeleverd worden. Berichten van onbeveiligde en nog onbekende domeinen moeten uitvoerig gecontroleerd worden. Daarvoor worden dan meer resources ingezet. Bovendien loont het om even te wachten met de beslissing: een zero-day staat nog op geen enkele lijst. Er is een grote kans dat de classificatie van een dergelijk bericht even later veel eenvoudiger is. SpamAssassin ondersteunt deze manier van werken nog niet out-of-the-box. Maar het Trusted Domain Project biedt wel al de tooling om zoiets zelf op te zetten.

Wie gebruikt DKIM/SPF/DMARC?

De drijvende kracht achter de snelle adoptie van DKIM/SPF/DMARC zijn de grote mail-verwerkers, die veel last hadden van phishing. Die social-media-bedrijven — Facebook is verreweg de grootste mail-verwerker ter wereld — bestaan nog niet zo lang, dus die hebben nog een goed geconsolideerde mail-infrastructuur. Dat maakte het relatief makkelijk voor hen om DMARC te implementeren.

Andere grote gebruikers zijn de mail-marketeers — de legitieme spammers. Zij hebben er groot belang bij dat hun berichten aankomen. Bovendien is het inherent aan hun business dat zij een goed gedefinieerde en moderne mail-infrastructuur hebben.

Naarmate meer mail-verwerkers DKIM/SPF/DMARC implementeren, wordt het voor domeinnaamhouders belangrijker om die DNS records te publiceren. Niet meedoen betekent immers dat berichten misschien niet aankomen.

Legacy

Wat was het Friends & Fans programma?

Voor de brede lancering van DNSSEC voor alle .nl-domeinen in 2012 was het voor liefhebbers en vroege vogels al mogelijk om de publieke sleutel voor hun .nl-domein bij SIDN in te dienen. Deze werd na controle handmatig aan de name-servers voor het .nl-domein toegevoegd. Nadat DNSSEC door alle registrars en internet service providers aan hun klanten aangeboden kon worden, is er een einde gekomen aan dit Friends & Fans programma.

Publieke sleutels voor .nl-domeinen die werden beheerd via een van de negen registrars die als launching partner voor DNSSEC fungeerden, zijn destijds overgenomen in het definitieve systeem. Houders die hun domein via een andere registrar beheren, hebben hun publieke sleutel via hun registrar of internet service provider opnieuw moeten indienen (als of zodra deze DNSSEC ondersteunde).

Waar dient Dynamic Lookaside Validation (DLV) voor?

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

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

Zo kunnen verschillende DNS-deelbomen die niet helemaal tot aan de absolute root gevalideerd kunnen worden (zogenaamde 'islands of trust') toch van een gemeenschappelijk trust anchor worden voorzien. Omdat de 'keten van vertrouwen' (chain of trust) via een andere route loopt, moeten voor validatie wel steeds extra DNS queries op een compleet andere zone worden uitgevoerd.

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

Waarom bestaat DLV nog?

Met de ondertekening van de root zone (.) in 2010 is er één enkel, officieel trust anchor beschikbaar dat in principe door iedereen gebruikt kan worden. Daarmee zou DLV niet meer nodig hoeven zijn, ware het niet dat nog lang niet alle top-level domeinen ondertekend zijn. Relatief gezien is het aandeel ondertekende domeinen weliswaar sterk toegenomen, maar dat komt vooral doordat nieuwe top-level domeinen sinds 2014 verplicht zijn DNSSEC (en IPv6) te ondersteunen.

Van de 28 EU-landen zijn er (op moment van schrijven, najaar 2015) bijvoorbeeld nog steeds vijf — Cyprus (.cy), Italië (.it), Malta (.mt), Roemenië (.ro) en Slowakije (.sk) — waarvan de top-level domeinen niet ondertekend zijn. Maar ook andere hoofddomeinen van landen waarvan je dat niet zou verwachten ondersteunen nog geen DNSSEC: Hong Kong (.hk), Israel (.il), Singapore (.sg) en Turkije (.tr).

DLV wordt nog steeds ondersteund en de DLV root maakt nog steeds deel uit van het trust anchor bestand voor BIND. Op die manier worden zones gefaciliteerd die onder een top-level domein hangen dat nog niet is ondertekend.

Moet ik DLV nog gebruiken?

Wie een domeinnaam heeft onder een van de 150 nog niet ondertekende top-level domeinen, kan zijn sleutelmateriaal alleen uploaden naar de DLV repository. Voor alle andere top-level domeinen moet men zijn domeinnaam via de registrar of internet service provider laten ondertekenen onder de root zone.

ISC heeft al aangekondigd in 2016 te stoppen met de registratie van domeinnamen waarvan het top-level domein DNSSEC ondersteunt. Bovendien zullen alle al geregistreerde domeinnamen waarvoor dat het geval is dan uit de DLV repository verwijderd worden. In 2017 zullen sowieso alle geregistreerde domeinnamen uit de repository worden verwijderd.

Dat betekent dat men op dit moment zijn domeinnaam niet meer in de DLV repository zou moeten registeren, tenzij er echt geen andere mogelijkheid is. Dat laatste is eigenlijk alleen nog het geval als het betreffende top-level domein nog geen DNSSEC ondersteunt.

In ieder geval zou men via de eigen (welwillende) registrar aan moeten dringen op DNSSEC-ondersteuning voor nog niet ondertekende top-level domeinen. Zeker nu meer toepassingsgerichte protocollen als DANE en DKIM/SPF/DMARC vaker gebruikt gaan worden, is het belangrijk dat DNSSEC als basis daaronder op alle domeinen beschikbaar is.

Meer informatie

Waar vind ik meer informatie over DNSSEC?

Voor een hele toegankelijke FAQ over DNSSEC gericht op een breed publiek verwijzen we graag naar de collega's van Internet.nl: