DNSSEC
DNS in eigen hand is het fundament voor onze implementatie van DNSSEC, een security-uitbreiding op het DNS-protocol.
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 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 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). Deze kan dat op geen enkele manier zien; de web-site is een exacte kopie en zelfs het slotje is gewoon aanwezig. DNSSEC beschermt de name-server en het transport van de DNS-informatie.
Waarom is DNSSEC voor mij als houder van een .nl-domeinnaam belangrijk?
Weet een kwaadwillende de DNS-informatie op de name-server, onderweg of bij de client te veranderen, dan kan hij een client naar een valse server sturen. Op die manier kunnen vertrouwelijke gegevens, paswoorden en omzet worden gestolen. DNSSEC beschermt de name-server en het transport van de DNS-informatie.
Is DNS onveilig?
Het DNS-protocol is veilig. Tot voor kort waren inbreuken alleen theoretisch mogelijk. 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.
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 records kan gecontroleerd worden met behulp van de publieke sleutel voor dit domein. Deze wordt door de houder (via zijn registrar) één niveau hoger in de DNS-hiërarchie geplaatst (het zogenaamde trust anchor). Voor een .nl-domeinnaam staat de publieke sleutel dus op de name-servers van SIDN, de beheerder van het .nl top-level domein. De 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 trust anchor 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 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 record niet geverifieerd worden, dan wordt de toegang tot de server echter afgebroken. Dat in tegenstelling tot bijvoorbeeld ongeldige internet-certificaten tijdens het browsen; daar kan men ervoor kiezen om een web-site 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.
Hoe werkt een Kaminsky-aanval?
Tot een paar jaar geleden waren aanvallen op het DNS-protocol vooral 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.
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 bovenliggende 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 (hash code) 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 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 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 het trust anchor bij SIDN een belangrijk onderdeel van de hele keten. Daar zou iemand immers het DS record kunnen veranderen of een extra sleutel 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 een trust anchor 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 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.
Het beheer en de aanvragen 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 en hun registrars.
Aanvragers en houders van domeinen doen zaken met een internet service provider. Vaak is die zelf aangemeld als registrar, maar een aanbieder kan ook gebruik maken van de diensten van een ander. Eindklanten doen hun beheer en aanvragen van domeinen meestal via het dashboard (een web-interface) van hun internet service provider.
Hoe werkt het DNSSEC-protocol?
DNSSEC, kort voor DNS Security Extensions, is een uitbreiding op het bestaande Domeinnaam systeem (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) kan worden gebruikt om vervolgens weer de echtheid van de publieke sleutel te controleren bij de beheerder van het bovenliggende 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. De authenticiteit van deze records kan gecontroleerd worden met behulp van de publieke sleutel voor dit domein. Deze wordt door de houder (via zijn registrar) één niveau hoger in de DNS-hiërarchie geplaatst (het zogenaamde trust anchor). Voor een .nl-domeinnaam staat de publieke sleutel dus op de name-servers van SIDN, de beheerder van het .nl top-level domein. Deze levert desgevraagd een ondertekende hash code (een digitaal uittreksel) van de publieke sleutel. 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 trust anchor is aangemeld.
De publieke sleutel (hash code) 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, en vervolgens op een goed beveiligde plaats bewaard. De public key wordt gepubliceerd in het DNSKEY record zodat deze voor iedereen 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 hoger gelegen toplevel-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.
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 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 TLD-beheerder 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.
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.
Waartoe dient de AD-vlag?
De AD-vlag (Authentic Data) wordt gebruikt door 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 meegeven. 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.
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 de Google's Public DNS service gecached en opgehoest, maar wordt de AD-vlag nooit gezet. Zij kunnen het tussenliggende traject immers niet garanderen.
Daarnaast lijkt de rol van de AD-vlag in de nabije toekomst te worden uitgebreid: was deze tot nu toe alleen gedefinieerd voor DNS-antwoorden, inmiddels wordt ook gewerkt aan het gebruik van de AD-vlag in de DNS-vragen. In paragraaf 5.7 van deze Internet Draft kunnen we lezen dat voorheen geadviseerd werd de AD-vlag in DNS-verzoeken uit te zetten. Straks levert het aanzetten van de AD-vlag alleen informatie over de validatie op, middels de AD-vlag in het DNS-antwoord, maar niet meer de DNSSEC records zelf. De netwerk-tool dig ondersteund deze mogelijkheid inmiddels via de +adflag optie. De DO-vlag blijft gebruikt worden om de volledige DNSSEC records op te vragen.
Hoe controleer ik de werking van DNSSEC?
Gebruikers die willen controleren of de DNS-informatie die ze gebruiken tijdens het browsen beveiligd is met DNSSEC, kunnen de test gebruiken die SIDN daarvoor online heeft gezet:
Let wel: als DNSSEC niet ondersteund wordt, wil dat niet zeggen dat de eigen resolver een probleem heeft. Vaak maakt deze (via DHCP) gebruik van de caching DNS-servers van de internet access provider.
Beheerders die de werking van DNSSEC willen controleren, kunnen daarvoor de tools gebruiken die worden meegeleverd met hun DNS-server, maar ook standaard netwerk-tools als 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:
Of deze van Sandia (levert een mooi grafisch overzicht):
Hoe verifieer 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 service providers en de clients bij de eindgebruikers.
De meeste clients bevatten zelf alleen een stub-resolver en laten de recursieve queries over aan de caching DNS-servers die ze via DHCP van de provider of netwerkbeheerder toegewezen krijgen. Hier in Nederland is T-Mobile op dit moment echter de enige provider die DNSSEC op zijn (mobiele) netwerk verifieert. Eindgebruikers die toch een gegarandeerd veilige DNS-resolver willen, zullen daarvoor dnssec-trigger moeten installeren.
Bovendien beschermt DNSSEC 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, zodat DNS compleet omzeild wordt.
Hoe zit het met DNSSEC-plugins voor web-browsers?
Inmiddels zijn er DNSSEC-plugins beschikbaar voor de meest gebruikte web-browsers. Deze werken parallel aan de resolver op de client en kunnen dus een heel ander antwoord geven dan de lokale resolver. Sterker nog, sommige plugins kunnen zo worden geconfigureerd dat ze van een hele andere DNS-server gebruikmaken. Waar een verifiërende resolver een beveiligd domein hard blokkeert als er iets mis blijkt te zijn, moeten deze plugins dus vooral als indicatief worden gezien.
Voor Firefox:
Voor Chrome/Chromium:
Voor Internet Explorer:
Waar vind ik meer informatie over DNSSEC?
- Algemene informatie over DNSSEC op Wikipedia:
- Professionele informatie over DNSSEC op dnssec.net:
- Het DNSSEC Deployment Initiative:
- De standaarden voor DNSSEC zoals vastgelegd in RFC's bij de IETF:
- DNSSEC-Tools, een verzameling van tools voor beheerders, clients en software-ontwikkelaars:
- http://www.dnssec-tools.org/
- BRON: DNSSEC.NL
