Nu trainen met DNSSEC

4 december 2009

Iedereen die naar een website surft, e-mail verstuurt of met VoIP telefoneert, maakt gebruik van DNS (het Domein Naam Systeem), het ‘telefoonboek van het internet’ dat domeinnamen vertaalt naar IP-adressen. Er bestaan naar schatting honderden miljoenen DNS-namen.

Het vertalen van domeinnamen naar IP-adressen is een transactie en zoals wel vaker het geval is met transacties, zit er een veiligheidsrisico aan vast. Door de gegevens die met een bepaald domein geassocieerd zijn te veranderen, kunnen aanvallers dat verkeer vrij eenvoudig kapen. Gevoelige gegevens kunnen zo op de verkeerde plek terechtkomen, zonder dat de gebruiker iets in de gaten heeft. Zo kan al het verkeer naar een website voor internetbankieren onopgemerkt worden omgeleid naar een systeem waar de aanvaller rekeningnummers, wachtwoorden en andere gevoelige informatie kan vastleggen. Ook SSL-beveiligde websites zijn gevoelig voor aanvallen, omdat eindgebruikers niet goed getraind zijn in het herkennen van tekenen van fraude en (in mindere mate) doordat de certificering niet waterdicht is.

Een aanval op een bekend lek in het DNS werd vorig jaar door beveiligingsexpert Dan Kaminsky wereldwijd onder de aandacht gebracht. Hij liet zien dat de cache van een DNS-server gemakkelijk kan worden vervuild (zogeheten cache poisoning) door slimme vragen te stellen en de server tegelijkertijd te bombarderen met foute antwoorden. Een dergelijke aanval is ook nog eens moeilijk te detecteren. Naast deze methode zijn er nog meer manieren om het systeem aan te vallen.

DNSSEC is een veiligheidsextensie op DNS die een oplossing biedt voor verschillende typen veiligheidsproblemen. Hiermee kunnen DNS-gegevens met behulp van publieke sleutels worden gevalideerd, waardoor je zeker weet dat het antwoord van de juiste partij afkomstig is en dus te vertrouwen is. Dat gebeurt door het gebruik van, in het DNSSEC-protocol gespecificeerde, public-key-cryptografie. In DNS worden de met een private key gezette handtekeningen gepubliceerd. Die handtekeningen kunnen door eindgebruikers worden gevalideerd met de bij de private key horende public key.

Hoewel DNSSEC voldoende bescherming biedt tegen de eerdergenoemde beveiligingsrisico’s, zijn er nog twee drempels die genomen moeten worden voordat deze beveiliging echt breed kan worden ingezet. De eerste is de complexiteit: de software en beheertools zijn nu nog geschreven voor specialisten en vergen een hoog kennisniveau. Langzamerhand komen er wel tools die de inzet van DNSSEC kunnen vereenvoudigen, maar deze tools zijn nog nieuw en alleen nog maar in gebruik in ‘early deployment’.

De andere horde die nog moet worden genomen, is meer politiek van aard. Een DNS-naam is hiërarchisch opgebouwd: een domeinnaam als www.automatiseringgids.nl heeft een boomstructuur en bij elke vertakking wordt een deel van de verantwoordelijkheid voor het beheer gedelegeerd. Zo valt het domein (automatiseringgids) onder het top-level domain (.nl). Nog een stapje hoger in deze hiërarchie staat de ‘root’, de hoogste DNS-zone, die wordt beheerd door de Internet Assigned Numbers Authority (IANA).

De ogen zijn al lang gericht op IANA om de root DNSSEC-proof te maken. Als het zover is en de root is getekend, wordt een belangrijke mijlpaal bereikt. Op het moment dat dan top-level domains worden getekend – in Nederland het .nl-domein – dan kan de hele DNS-boom worden gevalideerd, van de root, naar het top-level domain tot het domein. Tot die tijd moet een beheerder per top-level domain of zelfs per domein een DNS-key opgeven. Dat kan wel, maar is zo omslachtig dat het eigenlijk niet de moeite loont.

Zoals het er nu uitziet, zal IANA tussen december 2009 en 1 juli 2010 de root-zone met DNSSEC beveiligen. Er zal dan een hoop veranderen: niet alleen kunnen er dan ononderbroken ‘chains of trust’ van de root, via de reeds getekende top-level domains, naar getekende zones worden gemaakt, het tekenen van de root zorgt waarschijnlijk voor een doorbraak in de bewustwording rondom DNSSEC. Een aantal top-level domains is al getekend, waaronder .gov (zie kader), .se en .br. Als de root-zone eenmaal getekend is, zal de ontwikkeling van tools die het eenvoudiger maken om DNSSEC te beheren, worden versneld. Nu het nog ruim een halfjaar duurt, zullen deze naar verwachting ook kwalitatief beter zijn en beschikbaar zijn voordat de root is getekend.

Er zijn verschillende typen spelers in het DNS-veld. Allereerst zijn er de ‘eindgebruikers’ die over het algemeen de zogenaamde recursive nameservers gebruiken van hun ISP of eigen organisatie. Deze recursive nameservers zijn een goede plek om DNSSEC-validatie te plegen. Daarvoor moeten een of meer publieke sleutels worden geconfigureerd. Die publieke sleutels zijn afkomstig van de aanbieders van DNS-data – in het eerder gebruikte voorbeeld de beheerders van het domein automatiseringgids.nl. Omdat het uitwisselen van publieke sleutels nogal lastig is, wordt de sleutel van automatiseringgids.nl in het .nl-domein gepubliceerd en de sleutel van .nl in de root-zone.

Zolang de root en .nl nog niet getekend zijn, is het voor beheerders van DNS-domeinen nuttig om met DNSSEC te oefenen, zodat ze klaar zijn als die infrastructurele domeinen zijn getekend.

Dat kan door DNSSEC nu al aan te zetten op het eigen domein en daarvan de DNS-informatie te valideren. Een mogelijkheid om dat te doen, is het verstrekken van een ‘publieke key’ aan mensen en bedrijven die graag deze controle willen.

Op grote schaal is dit onbegonnen werk, omdat op deze manier van elke gebruiker en elk domein en top-level domain een publieke sleutel moet worden verzameld – miljoenen gegevens dus. Hiervoor bestaat een tussenoplossing in de vorm van ‘look-aside validatie’ (DLV), waar individuele domeinen hun public keys centraal kunnen laten registreren. Bij deze technologie (beschikbaar in DNSSEC-aware resolvers zoals BIND en Unbound) worden public keys opgezocht in een speciaal voor dat deel ingericht domein van het DNS-systeem.

Een alternatief systeem voor het uitwisselen van publieke sleutels – met name de publieke sleutels van de top-level domains die in principe in de root zouden worden gepubliceerd zodra die is getekend – is de zogenaamde Interim Trust Anchor Repository (ITAR). Deze wordt onderhouden door IANA, dezelfde organisatie die in 2010 de getekende root-zone beschikbaar maakt.

DNSSEC is al een hele tijd in ontwikkeling, maar het ziet ernaar uit dat we toch echt aan de vooravond staan van de definitieve doorbraak. Als DNS eenmaal volledig veilig is, gaat er een nieuwe wereld van mogelijkheden open. Zo zijn er autorisatiemechanismen denkbaar (maar nog niet mogelijk) waarmee je via DNS kunt aangeven dat je alleen maar wilt internetbankieren over een verbinding die aan bepaalde beveiligingseisen voldoet.

Voor een goede langetermijnbeveiliging van internet is DNSSEC een van de belangrijke bouwstenen. Internetserviceproviders, aanbieders van webdiensten, zoals banken en webshops, maar ook gebruikers van deze sites doen er goed aan om DNSSEC nu al op de agenda te zetten en te oefenen met het invoeren. Door nu te onderzoeken wat er gedaan kan worden om de eigen organisatie DNSSEC-proof te maken, kunnen er op het moment dat de DNSSEC wordt uitgerold in de root-zone en belangrijke top-level domeinen (zoals .nl), grote stappen worden gemaakt op weg naar een veiliger internet.

Olaf M. Kolkman is directeur van NLnet Labs, een stichting die als doelstelling heeft de ontwikkeling van open standaarden en open-sourceoplossingen voor internet, in het bijzonder voor DNS en DNSSEC. Chris Buijs is manager Core Network Services bij netwerkspecialist AXIANS.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!