Rapport SURFnet wijst op noodzaak invoering dnssec

SURFnet heeft een rapport gepubliceerd rondom het dnssec-protocol. De netwerkdienstverlener wil zo de kwetsbaarheid van het huidige dns-systeem onder de aandacht brengen bij onderwijsinstellingen en onderzoeksinstellingen.

Het rapport 'Hardening the Internet', dat werd opgesteld door SURFnet-technical manager Roland van Rijswijk, is mede geschreven naar aanleiding van de zogenaamde Kaminsky-aanval. Deze verfijnde aanvalsmethodiek besmet de cache van recursieve name servers. Hierdoor kunnen bijvoorbeeld surfers ongemerkt naar vervalste websites doorgestuurd worden en zijn in theorie ssl-certificaten te vervalsen. Het door Kaminsky ontdekte lek was weliswaar met een patch deels te verhelpen, maar toonde nog eens aan dat het huidige dns-systeem gedateerd en onveilig is.

De invoering van het beveiligingsprotocol dnssec moet op termijn de kwetsbaarheden van het dns-bewegwijzeringssysteem gaan verhelpen. Het nu vrijgegeven adviesrapport van SURFnet moet dienst gaan doen als voorlichtingsmateriaal voor onderwijsinstellingen, zo laat Van Rijswijk aan Tweakers.net weten. Dit zou nodig zijn omdat de overgang naar dnssec in Nederland nog te langzaam gaat, terwijl bijvoorbeeld de Amerikaanse .gov-domeinen sinds januari met het protocol overweg kunnen.

Volgens Van Rijswijk wordt de trage overgang naar dnssec deels veroorzaakt doordat de huidige software die benodigd is voor zaken als sleutelbeheer en het ondertekenen van domeinen, te veel kennis en tijd vergt. Deels moeten commerciële tools dit gaan verhelpen, maar Van Rijswijk wil op korte termijn ook een how-to gaan uitbrengen om veelgebruikte opensource dns-oplossingen als BIND met tools als OpenDNSSEC geschikt te maken voor dnssec. Daarnaast is het wachten op SIDN. De organisatie die het .nl-domein beheert, verwacht in de loop van 2009 te gaan implementeren.

Reacties (13)

Om een veilige DNSSEC-infrastructuur op te zetten moet de root gesigned worden. Zolang de root niet gesigned is wordt invoering lastig.

Als tussenstap zou je het nl-domein kunnen signen. Daarmee zou je alle DNSSEC-gebruikende domeinen onder het nl-domein kunnen verifiëren. Het is dan alleen nodig de public key van het nl-domein in je DNSSEC-configuratie op te nemen.

Of DNSSEC ooit aanslaat valt te bezien. Daniel Bernstein heeft een tijdje geleden steeksproefsgewijs gekeken welke domeinen DNSSEC gebruikten. Dit waren enkele tientallen/hondereden op miljoenen domeinen.

DNSSEC is technisch gezien niet erg moeilijk, maar vereist een gecoördineerde administratie. Even een DNS-record wijzigen kan, maar moet daarna wel gesigned worden. Ik kan mij voorstellen dat voor veel organisaties deze rompslomp doet besluiten zonder DNSSEC te draaien, zeker gezien zowel de root als het nl-domein (nog) niet gesigned is.

DNSSEC is technisch gezien niet erg moeilijk, maar vereist een gecoördineerde administratie. Even een DNS-record wijzigen kan, maar moet daarna wel gesigned worden. Ik kan mij voorstellen dat voor veel organisaties deze rompslomp doet besluiten zonder DNSSEC te draaien, zeker gezien zowel de root als het nl-domein (nog) niet gesigned is.

Hoe zit het eigenlijk met het signen van een wijziging in de DNS-records?

Bij een SSL-certificaat, genereer je zelf de diverse sleutels/certificaten en is er een externe organisatie die voor de ondertekening van het certificaat zorgt. Is dat bij DNSSEC ook zo, of is het mogelijk om dit op een andere manier op te lossen?

DNSSEC is te vergelijken met x509, ook gebruikt in SSL/TLS. Er wordt een chain of trust opgebouwd: een autoriteit zet een handtekening met een sleutel die geverifieerd is door een hogere autoriteit, net zo lang tot je bij de root bent.

In DNSSEC wordt een sleutel gesigned door het bovenliggende domein. Met deze sleutel kunnen de records in een zone worden gesigned. Voorbeeldje: tweakers.net gebruikt een 1024-bit RSA-sleutel om zijn zones mee te signen. Het net-domein bevat een verwijzing naar de nameserver van tweakers.net, met de handtekening van de sleutel van tweakers.net.

Of bovenstaande uitleg helemaal correct is weet ik niet, maar het principe (chain of trust met extra DNS resource records voor cryptografische controle) klopt in elk geval.

Als je dus een zone aanpast moet je de wijziging opnieuw ondertekenen. In de praktijk heb je je kale zone-file. Na bewerking draai je een tooltje dat de juiste extra resource records genereert aan de hand van een (password protected) key. Weinig bijzonders dus, maar weer een paar stappen extra.

Volgens mij is het gewoon een beetje de kat uit de boom kijken. Veel ccTLD registries zijn er mee bezig maar nog maar weinig hebben het daadwerkelijk geimplementeerd. Volgens mij is Zweden een van de weinige.
Een jaar geleden gaf volgens ICANN 85 % van de registries nog aan wel te willen, maar niet doorzetten omdat de techniek nog niet volledig ontwikkeld is/was, de root nog niet gesigned is of geen geld/tijd voor hebben. (bron: ccNSO)
Als er maar genoeg van dit soort rapporten ala surfnet uitkomen zal het meer prioriteit krijgen en denk ik dat DNSSEC sneller wordt geimplementeerd. Bovendien kan men nu leren van registries zoals Zweden waardoor implementatie wellicht makkelijker/goedkoper wordt.

[Reactie gewijzigd door Pascal.A op 12 februari 2009 16:24]

Tsja, de mogelijkheden liggen al 10 jaar op de plank... Net als IPv6 en een verbeterde versie van SMTP. Ik word er wel eens moedeloos van dat die dingen zo lang moeten duren... Alsof het eerst gigantisch mis moet gaan, voordat er actie ondernomen wordt.

Het probleem met dit soort zaken is veelal eerder het bekende kip-ei probleem. Zoals Niels Sijm hieronder al uitlegt zul je in geval van DNSSEC bij de root moeten beginnen. Zolang dat niet gebeurd heeft het ook weinig effect om DNSSEC te gebruiken en dus krijg je de situatie dat juist daarom niemand DNSSEC implementeert. Dat kip-ei probleem is overigens maar 1 van de nadelen aan DNSSEC, een goede administratie is bijvoorbeeld een tweede (en eentje waar men nogal erg tegen sputtert).

IPv6 e.d. heeft ook last van dat kip-ei probleem. Het wordt pas interessant om tot IPv6 over te gaan als je het ook daadwerkelijk kunt gebruiken naar de buitenwereld. Buiten dat werkt nog niet alles met IPv6 waardoor het ook niet erg handig is om dan naar IPv6 over te schakelen. Tel daarbij op dat IPv4 op dit moment nog prima voldoet (het werkt gewoon) en het feit dat er vaak toch nog een aardige investering in hardware/software, tijd, etc. gaat zitten en het wordt al wel snel duidelijk waarom iets als IPv6 op de plank blijft liggen.

Je kunt er moedeloos van worden maar je kunt er ook actie op ondernemen Buiten dat is het ook lang niet altijd verstandig om domweg maar iets in gebruik te gaan nemen, liever eerst goed testen en pas daarna in gebruik nemen (indien test succesvol). Het is dus echt absoluut niet alleen een kwestie van het feit dat er eerst iets mis moet gaan wil men er dan wat aan gaan doen.

Wat betreft IPv6 ben ik het er niet helemaal mee eens. Op een gegeven moment zijn de IPv4 adressen simpelweg op, dus dan kunnen we met z'n allen niet anders dan nieuwe websites exclusief op IPv6 hosten. Op dat moment is dus niet meer het hele internet via IPv4 bereikbaar, dus moeten providers wel IPv6 gaan ondersteunen. Zowel access- als hostingproviders die op dat moment niet klaar zijn voor IPv6 zullen klanten verliezen.

Het heeft dus niets te maken met trend zetten en trend volgen, of kip en ei zoals je het zelf noemt. Het is alleen een kwestie van gaan we het ruim op tijd ondersteunen, of wachten we tot het laatste moment. Veel providers menen dat uitstellen van IPv6 goedkoper zal zijn dan een spoedige invoering.

Alsof het eerst gigantisch mis moet gaan, voordat er actie ondernomen wordt.

Zo werkt beveiliging in de praktijk wel voor veel bedrijven: Goede beveiliging introduceren en onderhouden (in dit geval migreren naar dnssec) kost vaak veel geld, en zolang dit duurder is dan gewoon steeds de schade van inbraken te betalen heeft het voor bedrijven geen zin om betere beveiliging te regelen.

Dit zou een goede stap in de juiste richting zijn.
En misschien kunnen ze ook ineens certificaten voor emailservers uitbrengen zodat enkel gecertificeerde servers emails over het internet kunnen sturen.

De vraag is hoe gaan ze dit in orde krijgen.
Eind 2008 waren er al berichten dat de grote nameserver (oa .COM, .ORG) hier al mee gingen beginnen.
Maar dit is dan enkel de top, zolang de basis (oa ISP's) niet volgt heeft het voor de gewone gebruiker weinig effect en voordeel.

Ai ai ai. Jammer dat DNSSEC zo gepushed wordt. Er zijn veel betere alternatieve (okay, de implementatie is er nog niet, maar dat is een kwestie van tijd): http://www.dnscurve.org/dnssec.html geeft een prachtige vergelijking van DNSSEC (lees: ISC - of het BIND-kartel zoals dnscurve bedenker Bernstein weleens bespottelijk zegt) met dnscurve.

En wat zijn de redenen om niet over te gaan ?