Veelgestelde vragen

Algemeen

Over DNSSEC

Implementatie

  • Hoe beveilig ik mijn .nl-domeinen met DNSSEC? Antwoord…

  • Wordt DNSSEC ondersteund door mijn DNS-software? Antwoord…

  • Hoe controleer ik als beheerder de werking van DNSSEC? Antwoord…

  • Hoe controleer ik als internetgebruiker de werking van DNSSEC? Antwoord…

  • Hoe zit het bij verhuizing van een beveiligd domein? Antwoord…

  • Wat is er met BIND versie 10 gebeurd? Antwoord…

  • Kan ik BIND versie 9 nog blijven gebruiken? Antwoord…

Validatie

Technisch

Cryptografische algoritmen

  • Hoe werken digitale handtekeningen? Antwoord…

  • Welke rol spelen digitale handtekeningen in het DNSSEC-protocol? Antwoord…

  • Waarom is de cryptografie achter digitale handtekeningen voor mij van belang? Antwoord…

  • Welke cryptografische algoritmen ondersteunt DNSSEC? Antwoord…

  • Welk cryptografisch algoritme voor DNSSEC kan ik het beste gebruiken? Antwoord…

  • Welke cryptografische algoritmen voor DNSSEC moet ik zeker niet gebruiken? Antwoord…

  • Kan ik de cryptografische algoritmen 5 en 7 nog gebruiken? Antwoord…

  • Wat is het ECDSA-algoritme? Antwoord…

  • Wat zijn de verschillen tussen de verschillende public key algoritmen? Antwoord…

  • Wat zijn de voordelen van het ECDSA-algoritme voor DNSSEC? Antwoord…

  • Waarom is het ECDSA-algoritme voor DNSSEC nu de beste keuze? Antwoord…

  • Kan ik ECDSA-algoritmen 13 en 14 al gebruiken? Antwoord…

  • Wat is het verschil tussen ECDSA-algoritmen 13 en 14? Antwoord…

  • Wat betekent het ECDSA-algoritme voor de toekomst van DNSSEC? Antwoord…

Aandachtspunten

  • Wat is een DNS amplificatie-aanval? Antwoord…

  • Hoe zijn DNS amplificatie-aanvallen tegen te gaan? Antwoord…

  • Is er een betere manier om DNS amplificatie-aanvallen tegen te gaan? Antwoord…

  • Hoe kan UDP-fragmentatie worden misbruikt voor een aanval op DNS? Antwoord…

  • Hoe verhoogt Response Rate Limiting het risico op cache pollution? Antwoord…

Organisatorisch

DNSSEC en verder

  • Welke andere protocollen maken gebruik van DNSSEC? Antwoord…

DANE

DKIM, SPF en DMARC

Legacy

  • Hoe ontwikkelde de uitrol van DNSSEC zich in de tijd? Antwoord…

  • Wat zijn DNSSEC-validatiefouten? Antwoord…

  • Waardoor werden DNSSEC-validatiefouten veroorzaakt? Antwoord…

  • Wat deden/doen wij om het aantal DNSSEC-validatiefouten beperkt te houden? Antwoord…

  • Zijn DNSSEC-validatiefouten nog steeds een probleem? Antwoord…

  • Wat was het Friends & Fans programma? Antwoord…

  • Waar dient Dynamic Lookaside Validation (DLV) voor? Antwoord…

  • Wat is de status van DLV? Antwoord…

Meer informatie

  • Waar vind ik meer informatie over DNSSEC? Antwoord…

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. Je vindt hier informatie over het belang en de werking van DNSSEC. De tekst gaat ervan uit dat je bekend bent met het DNS-systeem en bijbehorende technische terminologie.

    Terug naar boven…

  • 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 example.nl alvorens contact te kunnen zoeken met de web-server 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.

    Terug naar boven…

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

    Terug naar boven…

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

    Terug naar boven…

  • 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 (situatie voorjaar 2018). 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 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, zijn die grote onderlinge verschillen er nog steeds. Waar de overheden hun eerdere achterstand inmiddels meer dan goed hebben gemaakt, lopen de banken en de internet-sector nog steeds sterk achter.

    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 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 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 (en IPv6) te ondersteunen in hun EPP- en web-interfaces. Hun klanten moeten sleutelmateriaal kunnen toevoegen, wijzigen en verwijderen. Daarmee is DNSSEC inmiddels een integraal onderdeel van DNS geworden.

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

    DNSSECstats2018-DNSSECadoptie

    Terug naar boven…

  • Welke rol heeft de Nederlandse overheid?

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

    Terug naar boven…

  • Wat is de 'pas toe of leg uit'-lijst?

    DNSSEC (en DKIM) zijn in 2012 door het 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. DMARC is op dit moment (voorjaar 2018) nog in behandeling. Deze standaarden verzorgen de beveiliging van mail-transport [1, 2], en bouwen daarvoor alle voort op de cryptografische infrastructuur van DNSSEC.

    Terug naar boven…

  • Worden overheden (straks) verplicht gesteld om DNSSEC te gebruiken?

    Op dit moment wordt gewerkt aan de Wet Generieke Digitale Infrastructuur (WGDI). Een van de opties is om de hele 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 internet-standaarden voor beveiligde e-mail heeft de toenmalige Minister van Binnenlandse Zaken in 2016 gesteld dat DNSSEC en de andere internet-standaarden op de ptolu-lijst uiterlijk eind 2017 bij alle gemeenten geïmplementeerd moeten zijn.

    Terug naar boven…

  • Welke rol heeft SIDN?

    SIDN, de beheerder van het .nl top-level domein, 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 registrar verhuisd kunnen worden zonder de DNSSEC-beveiliging daarvoor te hoeven onderbreken, voor een goed deel bedacht door SIDN Labs. De procedure voor een naadloze verhuizing is vergelijkbaar met een key roll-over, maar dan over verschillende partijen verdeeld.

    Om dit mogelijk te maken was het ook nodig om de EPP-interface uit te breiden met het 'key relay' commando, zodat de registrars betrokken bij een verhuizing het daarvoor benodigde sleutelmateriaal via de registry kunnen uitwisselen. Deze uitbreiding is inmiddels gestandaardiseerd in RFC 8063.

    Terug naar boven…

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.

    Terug naar boven…

  • Hoe werkt DNSSEC?

    DNSSEC is een voorwaarts compatibele uitbreiding van het DNS-protocol. Clients die deze beveiliging ondersteunen, ontvangen van de DNS-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.

    Terug naar boven…

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

    Terug naar boven…

  • Wat merk ik als internetgebruiker van DNSSEC?

    Internetgebruikers 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 internetcertificaten 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.

    Terug naar boven…

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

    Let op: DNSSEC beschermt alleen de authenticiteit van de DNS-informatie. Dat wil zeggen dat de digitale handtekening garandeert dat de DNS-antwoorden zoals die bij de 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. Daarvoor zijn op dit moment nog geen efficiënte oplossingen beschikbaar.

    Daarnaast is DNSSEC geen vervanger van HTTPS, al biedt DANE (dat voortbouwt op DNSSEC) wel een alternatief voor het CA-systeem. Tenslotte beschermt DNSSEC ook niet tegen phishing; ook een malfide URL kan immers keurig ondertekend zijn (door zijn kwaadwillende eigenaar). De DKIM/SPF/DMARC-protocollen (ook weer gebruikmakend van DNSSEC) zijn wel bedoeld om phishing, spam, virussen en andere malware tegen te gaan.

    Terug naar boven…

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

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

    Terug naar boven…

  • 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. Inmiddels is de DNSSEC-functionaliteit van de Infoblox appliances echter sterk verouderd en zouden we het gebruik ervan voor nieuwe implementaties afraden.

    Terug naar boven…

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

    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:

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

    dnsviz-sidn

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

    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 score, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance".

    Terug naar boven…

  • Hoe controleer ik als internetgebruiker de werking van DNSSEC?

    Op de Internet.nl portal kun je je verbindingen en domeinen testen op de toepassing van een zestal moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een score, 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:

    Let op: 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.

    Terug naar boven…

  • Hoe zit het bij verhuizing van een beveiligd domein?

    Ben je van plan om een ondertekend domein te verhuizen, dan moet je om te beginnen verifiëren dat je nieuwe aanbieder ook DNSSEC ondersteunt. Doe je dat niet, dan zou je 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. Deze uitbreiding op de EPP-interface is inmiddels gestandaardiseerd in RFC 8063.

    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.

    Terug naar boven…

  • Wat is er met BIND versie 10 gebeurd?

    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.

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

    Terug naar boven…

  • Kan ik BIND versie 9 nog blijven gebruiken?

    ISC zal voorlopig gewoon doorgaan met de verdere ontwikkeling van BIND versie 9.

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

    Terug naar boven…

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 autoritatieve DNS-servers betrokken bij de domeinnaam zelf — 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 daarmee de validatie — over aan de caching DNS-servers die ze via DHCP van de provider of netwerkbeheerder toegewezen krijgen. Hier in Nederland behoren XS4All, BIT en Edutel op dit moment tot de weinige access providers die DNSSEC op hun netwerk valideren. De twee grootste providers, KPN en Ziggo, doen op dit moment geen validatie voor hun klanten (situatie voorjaar 2018).

    Netwerkbeheerders die DNSSEC voor hun gebruikers willen valideren kunnen daarvoor bijvoorbeeld gebruik maken van BIND named of de PowerDNS Resolver [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 dnssec-trigger of een browser-plugin moeten installeren.

    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.

    Terug naar boven…

  • Who validates DNSSEC?

    In the Netherlands, XS4All, BIT and Edutel are currently among the few access providers whose networks support DNSSEC validation. At the time of writing (spring 2018), the country's two biggest providers, KPN and Ziggo, don't provide a validation service for their customers.

    Other organisations that do validation are RijksDNS, the Municipality of 's-Hertogenbosch, the University of Twente, the University of Groningen and the CWI.

    A number of major access providers are currently working on the implementation of DNSSEC validation on their caching DNS servers. We expect them to formally add validation to their DNS services in the near future. Until then, end users can make use of Quad9, 1.1.1.1 or Google's Public DNS service, although the latter does involve certain privacy sacrifices.

    Terug naar boven…

  • 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 de DNS-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 (RFC 4035, paragraaf 3.1.6) bepaalt dat autoritatieve servers 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-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 aan zetten 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.

    Terug naar boven…

  • Wanneer kun je de AD-vlag vertrouwen?

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

    Terug naar boven…

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

    Terug naar boven…

  • Moet ik DNSSEC zelf blijven valideren?

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

    Netwerkbeheerders die DNSSEC voor hun gebruikers willen valideren kunnen daarvoor bijvoorbeeld gebruik maken van BIND named of de PowerDNS Resolver [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 dnssec-trigger of een browser-plugin moeten installeren.

    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.

    Terug naar boven…

  • 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 daarmee 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.

    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.

    Terug naar boven…

  • Wat is de Valibox?

    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 LEDE (een fork van OpenWrt) en Unbound. Op dit moment worden drie verschillende hardware devices ondersteund: de GL-Inet AR-150, 6416 en MT300A.

    Valibox-screenshot_glinet_upload_firmware

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

    Terug naar boven…

  • Wat is er gebeurd met SIDN's validerende DNS-dienst?

    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 access providers 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, en het aantal providers dat DNSSEC-validatie aan zet groeit langzaam maar gestaag.

    Terug naar boven…

  • Vormen validatiefouten nog een belemmering?

    In de jaren 2013-2014 vormden validatiefouten een belangrijke sta-in-de-weg voor de verdere ontwikkeling van DNSSEC in Nederland. Destijds waren er te veel domeinen waarvan het sleutelmateriaal zoals dat geregistreerd stond bij SIDN niet overeenkwam met de informatie op de autoritatieve servers. Dat veroorzaakte problemen bij goedwillende access providers die DNSSEC-validatie voor hun klanten aan wilden zetten. In 2013 was deze problematiek voor T-Mobile zelfs reden om de validatie voor hun mobiele gebruikers weer uit te zetten.

    SIDN heeft daarop diverse maatregelen genomen om het aantal validatiefouten terug te dringen. Zo werden de registrars die verantwoordelijk waren voor de meeste validatiefouten nagebeld (2013), waarna het aantal validatiefouten snel begon te dalen (2014). Met de ingebruikname van de Validation Monitor XXL (in 2015) had SIDN een tool tot haar beschikking om ook de laatste DNSSEC-configuratiefouten uit de .nl zone te persen. Bovendien kon daarmee een (financiële) koppeling gemaakt worden met de incentive-regeling voor DNSSEC.

    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. De belangrijkste uitkomst van deze pilot was dat validatiefouten vrijwel niet meer voorkomen. Over een periode van ongeveer anderhalf jaar zijn op een totaal van 849.182.522 queries 25.160 onbedoelde validatiefouten (verdeeld over 4.778 unieke domeinnamen) gemeten. Dat is ongeveer 30 op een miljoen, een vermindering van vijf orden van grootten ten opzichte van de situatie in 2013. Daarmee is het aantal fouten in de praktijk verwaarloosbaar geworden.

    Terug naar boven…

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.

    Terug naar boven…

  • 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 DNS-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 DNS-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.

    Terug naar boven…

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

    Terug naar boven…

  • 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 handtekeningen onder de 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.

    SingleKeyPair1-1488x921

    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 in het algemeen 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.

    DoubleKeyPair1-1984x957

    In een getrapte KSK/ZSK-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.

    Overigens is begin 2017 de sleutellengte van het ZSK-sleutelpaar voor de root zone naar 2048 bits gebracht, waarmee de KSK- en ZSK-paren nu even sterk zijn. Voor de .nl zone staat de lengte van het ZSK-sleutelpaar (nog) op 1024 bits.

    nl-2018-03-23-11_49_19-UTC

    Terug naar boven…

  • 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 (NXDOMAIN) 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 NXDOMAIN-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 bijzonder processor-intensief 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.

    Terug naar boven…

  • 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 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). 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. Daarmee is deze aanval niet langer haalbaar

    Een Kaminksy-aanval lijkt hier op maar bestaat uit twee stappen: Als je het domein www.example.nl wilt spoofen, begin je om een resolver te vragen naar bijvoorbeeld de domeinnaam 000001.example.nl. Tegelijkertijd stuur je valse DNS-antwoorden op die resolver af met daarin NS records die naar een valse autoritatieve DNS-server verwijzen. Komt het echte antwoord eerder aan, dan hoef je niet te wachten tot de TTL 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.

    Deze aanvalsmethode werkt niet meer bij gebruik van DNSSEC; de validatie van de digitale handtekeningen op de valse records zal immers niet lukken.

    Terug naar boven…

Cryptografische algoritmen

  • Hoe werken digitale handtekeningen?

    Digitale handtekeningen maken gebruik van public key cryptografie: Eerst wordt een hash (een digitaal uittreksel) van een elektronisch document (in dit geval een RRset of DNSKEY record) 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 (want in DNS 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.

    pubkey_cryptografie

    Terug naar boven…

  • Welke rol spelen digitale handtekeningen in het DNSSEC-protocol?

    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 (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 root zone. 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 resolver-software.

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

    chain_of_trust-example.nl

    Terug naar boven…

  • Waarom is de cryptografie achter digitale handtekeningen voor mij van belang?

    Zowel voor de hashes als voor de public key cryptografie bestaan verschillende algoritmen. DNSSEC ondersteunt verschillende combinaties van die twee. Voordat je je zones ondertekent moet je dus kiezen welk algoritme je daarvoor gaat gebruiken.

    Terug naar boven…

  • Welke cryptografische algoritmen ondersteunt DNSSEC?

    Op dit moment zijn er een stuk of vijftien cryptografische hash/pubkey-combinaties voor DNSSEC gedefinieerd. Het complete overzicht vind je op de website van IANA. In de loop der tijd vallen bestaande algoritmen af (deprecated, want verouderd of onveilig) en komen er nieuwe algoritmen bij.

    Terug naar boven…

  • Welk cryptografisch algoritme voor DNSSEC kan ik het beste gebruiken?

    RFC 6944 geeft een aantal aanbevelingen voor de keuze en toepassing van de verschillende DNSSEC-algoritmen. Algoritmen nummer 13 (ECDSA Curve P-256 with SHA-256) en 14 (ECDSA Curve P-384 with SHA-384) worden in deze RFC aanbevolen, naast nummer 8 (RSA/SHA-256) en 10 (RSA/SHA-512).

    Terug naar boven…

  • Welke cryptografische algoritmen voor DNSSEC moet ik zeker niet gebruiken?

    Algoritme nummer 1 (RSA/MD5) moet je in ieder geval niet meer gebruiken vanwege de bewezen onveiligheid van de MD5 hash-functie.

    Geen van de algoritmen gebaseerd op de SHA-1 hash wordt op dit moment (in RFC 6944) afgeraden voor implementatie. Nummer 3 (DSA/SHA1) en 6 (DSA-NSEC3-SHA1) zijn optioneel, nummer 5 (RSA/SHA-1) is verplicht, en nummer 7 (RSASHA1-NSEC3-SHA1) is zelfs aanbevolen. Deze vier zouden inmiddels echter niet meer gebruikt moeten worden. SHA-1 is te zwak, zegt Marc Stevens, cryptograaf bij CWI en bekend als kraker van MD5 en SHA-1. Dit protocol is niet voor niets al in 2011 door NIST afgekeurd voor gebruik in digitale handtekeningen. Het is dus zeer belangrijk dat er zo snel mogelijk ook voor DNSSEC een roadmap voor de uitfasering van SHA-1 komt.

    Terug naar boven…

  • Kan ik de cryptografische algoritmen 5 en 7 nog gebruiken?

    De auteurs van RFC 6944 erkennen dat SHA-1 eigenlijk niet meer gebruikt zou moeten worden, maar de verplichting om algoritme nummer 5 (RSA/SHA-1) te implementeren is onderdeel van de DNSSEC-standaard zoals gedefinieerd in RFC 4034. Nummer 5 is cryptografisch hetzelfde als nummer 7 (RSASHA1-NSEC3-SHA1) — net zoals nummer 3 (DSA/SHA1) en 6 (DSA-NSEC3-SHA1) dat zijn — maar deze bevat geen NSEC3 records: een ondertekende denial-of-existence.

    Domeinnaamhouders die nu nog gebruikmaken van algoritmen nummer 7 of 5 zouden snel moeten overstappen naar een veiliger/beter alternatief. Algoritmen nummer 3 en 6 worden al nauwelijks meer gebruikt.

    Terug naar boven…

  • Wat is het ECDSA-algoritme?

    ECDSA (Elliptic 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. Zoals de naam al aangeeft is ECDSA gebaseerd op Elliptic Curve Cryptografie (ECC), dat belangrijke voordelen biedt bij de toepassing voor DNSSEC.

    Terug naar boven…

  • Wat zijn de verschillen tussen de verschillende public key algoritmen?

    De veiligheid van alle drie public key algoritmenDSA, 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 twee 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 random-generator.

    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.

    Terug naar boven…

  • Wat zijn de voordelen van het ECDSA-algoritme voor DNSSEC?

    Specifiek van belang voor DNSSEC is dat de digitale handtekeningen voor ECDSA ongeveer even lang zijn als die voor DSA, maar dat de publieke sleutels veel korter zijn. Ter illustratie: een veiligheidsniveau van 128 bits — dat wil zeggen dat er 2128 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 (twee keer de gewenste veiligheid), terwijl dit voor DSA en RSA minstens 2048 bits is. De lengte van de handtekeningen is voor ECDSA en DSA allebei ongeveer vier maal de lengte van de gewenste veiligheid, in dit voorbeeld dus 512 bits, terwijl die voor RSA op meer dan 2048 bits zit.

    Voor 128 bits security:
    ECDSADSARSA
    Sleutellengte: 256 2048+ 2048+
    Handtekeningen: 512 512 2048+

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

    ECDSADSARSA
    Validatie: langzaam snel razendsnel
    Ondertekening: razendsnel snel minder snel

    Terug naar boven…

  • Waarom is het ECDSA-algoritme voor DNSSEC nu de beste keuze?

    De hierboven besproken verschillen in algoritmische eigenschappen maken ECDSA in het algemeen de beste keuze voor DNSSEC. Ten eerste kunnen niet alleen de 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.

    Tenslotte 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 client-zijde 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.

    Terug naar boven…

  • Kan ik ECDSA-algoritmen 13 en 14 al gebruiken?

    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, zullen we algoritme 14 in de praktijk naar verwachting voorlopig zelden tegenkomen.

    Terug naar boven…

  • Wat is het verschil tussen ECDSA-algoritmen 13 en 14?

    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 NSEC3 waarmee het probleem van name walking definitief opgelost zou zijn.

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

    Terug naar boven…

  • Wat betekent het ECDSA-algoritme voor de toekomst van DNSSEC?

    DNSSEC maakt de antwoorden die door name-servers teruggestuurd worden in response op DNS queries aanzienlijk groter. Met elke 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 botnet een grote hoeveelheid 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.

    Terug naar boven…

Aandachtspunten

  • Wat is een DNS amplificatie-aanval?

    DNSSEC maakt de antwoorden die door name-servers teruggestuurd worden in response op DNS queries aanzienlijk groter. Met elke 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 botnet een grote hoeveelheid 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.

    Terug naar boven…

  • Hoe zijn DNS amplificatie-aanvallen tegen te gaan?

    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 relay fungeren. Het gedistribueerde verkeer in een lage frequentie is immers niet te onderscheiden van legitiem DNS-verkeer.

    Terug naar boven…

  • Is er een betere manier om DNS amplificatie-aanvallen tegen te gaan?

    De beste manier om DNS amplificatie-aanvallen te voorkomen is tegelijkertijd (technisch) de meest simpele oplossing. BCP 38 (Best Current Practice) schrijft voor dat elke internet service provider (ISP) zijn uitgaande internet-verkeer 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 worden besmette clients die deeluitmaken van een botnet al bij de bron geblokkeerd.

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

    Terug naar boven…

  • Hoe kan UDP-fragmentatie worden misbruikt voor een aanval op DNS?

    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 DNS-pakketten tot 4096 bytes 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).

    Terug naar boven…

  • Hoe verhoogt Response Rate Limiting het risico op cache pollution?

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

    Kwaadwillenden kunnen de RRL-bescherming aanwezig op een autoritatieve server misbruiken om hun kansen op een sucessvolle cache pollution aanval te vergroten. Dat doen zij door eerst middels IP address spoofing een caching resolver bewust in the RRL blacklist van een veelgebruikte autoritatieve server op laten nemen. Als de aanvaller het IP-adres van de resolver als afzender in een groot aantal UDP-pakketten plaatst, zal de autoritatieve server immers denken dat de betreffende resolver slachtoffer is van een DDoS-aanval. De autoritatieve server 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 pollution aanval op de resolver uit te voeren.

    Het gebruik van DNSSEC voorkomt dit type cache pollution aanvallen omdat de vervalste DNS-antwoorden niet de juiste handtekening van de originele autoritatieve server bevatten.

    Terug naar boven…

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.

    Terug naar boven…

  • 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 kwetsbare 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.

    Terug naar boven…

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

    Terug naar boven…

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.

    Terug naar boven…

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.

    Terug naar boven…

  • 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 — ondanks de versleuteling — niet te vertrouwen is.

    Terug naar boven…

  • Wie gebruikt DANE?

    Hoewel DANE breder (d.w.z. algemeen) inzetbaar is, vindt het protocol zijn weg vooral in de wereld van de web-certificaten (HTTPS) en de beveiliging van mail-transport (SMTP). Met name die laatste toepassing heeft de afgelopen jaren opgang gevonden met de ondersteuning van DANE-authenticatie door de Postfix mail server (na Exim de meest gebruikte MTA). Ondersteuning van DANE door Exim is op dit moment nog experimenteel. En aan de implementatie van DANE-authenticatie voor IndiMail (een reïncarnatie van qmail) wordt gewerkt (stand van zaken voorjaar 2018). De ondersteuning van DANE door OpenSSL (vanaf versie 1.1) heeft dit soort implementaties veel makkelijker gemaakt.

    In maart 2017 publiceerde het Nationaal Cyber Security Centrum (NCSC) de Factsheet 'Beveilig verbindingen van mailservers'. Daarin doen zij de aanbeveling om STARTTLS en DANE in te schakelen, om op die manier het transport van mailberichten te beveiligen. In diezelfde maand initieerden overheid en bedrijfsleven ook de 'Veilige E-mail Coalitie'. Deelnemers in deze coalitie verplichten zich om in hun eigen organisatie en bij hun achterban te werken aan de implementatie van onder andere DNSSEC, DANE en STARTTLS. Een half jaar eerder al plaatste het Forum Standaardisatie STARTTLS en DANE op de 'pas toe of leg uit'-lijst. Dat betekent dat overheidsorganisaties min-of-meer verplicht zijn om deze twee beveiligingsstandaarden in hun mail-infrastructuur te implementeren.

    Terug naar boven…

  • Hoe beveiligt DANE het webverkeer?

    Webbrowsers zijn nu voor hun HTTPS-verbindingen volledig afhankelijk van de beveiliging bij de bijna 100 Certificate Authorities (CA's). Het DigiNotar-debacle [1, 2], 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. Andere, minder grote maar vergelijkbare incidenten betroffen Comodo (Tweakers.net), Flame (Tweakers.net), Trustwave (Heise Online), MCS () en Turktrust.

    Met DANE voor web 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.

    Terug naar boven…

  • Hoe beveiligt 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 altijd belangrijker geweest 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-authenticatie 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.

    Terug naar boven…

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

    Terug naar boven…

  • 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 RFC 7672 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.

    Terug naar boven…

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

    Terug naar boven…

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

    Terug naar boven…

  • Wat is de status van DANE?

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

    RFC 7673 en RFC 7929 definiëren het gebruik van DANE voor respectievelijk SRV records (ter ondersteuning van diverse communicatieprotocollen) en OpenPGP (verankering publieke sleutels via OPENPGPKEY records).

    Terug naar boven…

  • 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 vind je in dit hands-on artikel:

    Alsook hier.

    Terug naar boven…

  • Hoe valideer ik DANE op het web?

    Voor zo ver ons bekend zijn er op dit moment (voorjaar 2018) nog geen breed gebruikte web-browsers die out-of-the-box DANE-authenticatie 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

    Terug naar boven…

  • 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-authenticatie 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 vind je in dit hands-on artikel:

    Terug naar boven…

  • Hoe valideer ik DANE in mijn mail client?

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

    Terug naar boven…

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.

    Terug naar boven…

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

    Terug naar boven…

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

    Terug naar boven…

  • 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

    Terug naar boven…

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

    Terug naar boven…

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

    Terug naar boven…

Legacy

Meer informatie