VeriSign gaat dnssec-protocol invoeren op tld's

VeriSign heeft aangekondigd het dnssec-protocol ook voor .com-, .edu- en .net-top level domain names te zullen invoeren. Dnssec zou de kwetsbaarheden in het dns-protocol moeten verhelpen en zo de kans op misbruik moeten verkleinen.

De invoering van het dnssec-protocol door VeriSign in samenwerking met Icann zou uiterlijk maart 2011 voltooid moeten zijn, waarbij het momenteel gaat om 80 miljoen .com-domeinen en 15 miljoen .net-domeinen. Voor de uitrol van dnssec voor sites met een .edu-extensie, het tld dat door Amerikaanse onderwijsinstellingen wordt gebruikt, zoekt VeriSign samenwerking met Educause, de non-profit organisatie die de .edu-domeinen beheert. VeriSign zal in samenwerking met de Amerikaanse overheid ook dnssec toepassen op de twee rootservers die het in zijn beheer heeft.

Eerder werd dnssec al uitgerold door de Public Interest Registry-beheerder op het .org-tld. In Nederland is Sidn verantwoordelijk voor de invoering van dnssec op .nl-domeinen. Hoewel de organisatie begin dit jaar aankondigde dat het verbeterde dns-protocol in de loop van 2009 ingevoerd zou worden, liet Sidn in oktober weten dat door 'operationele en technische problemen' de invoering langer zal gaan duren.

De implementatie van dnssec op de dns-servers die VeriSign en andere organisaties beheren, lijkt broodnodig. Volgens een onderzoek van de firma Infoblox is het aantal kwetsbare dns-servers gevoelig voor cache poisoning, de kwetsbaarheid die begin 2008 bekend werd, de afgelopen jaar met 27 procent gestegen. In totaal zou bijna 80 procent van alle dns-servers nog zonder dnssec werken doordat het aantal dns-servers sterk is blijven groeien. Door de langzame overgang naar dnssec houden kwaadwillenden de mogelijkheid om onder andere ddos-aanvallen uit te voeren en eindgebruikers ongemerkt naar schadelijke websites te lokken.

Reacties (8)

[Arjan_van_Rees]

Mooi dat dit nu voor de top level domains wordt toegepast en dat er verschillende initiatieven zijn om dit verder door te vertalen naar beneden. Wel jammer dat we bijna 2 jaar verder zijn voor er wat schot in zit... Ik vraag me af of het uberhaupt haalbaar is om alle DNS servers op deze manier te beveiligen. Lijkt me dat zolang het niet bij wet verplicht is, er altijd DNS hosts zullen zijn die dit uit kostenoverweging niet toepassen.

[Reactie gewijzigd door Arjan_van_Rees op 24 juli 2024 09:34]

[Niemand_Anders]

Net als SSL op website is dat een keuze van de beheerder. Echter met DNSSEC ligt de zaak iets ingewikkelder. Het heeft geen zin als een enkele host DNSSEC implementeerd. Een hacker zou immers nog steeds de DNS cache bij een provider kunnen 'aanpassen' waardoor het slachtoffer niet naar de juiste DNS server gaat. De DNS server van de hacker implementeert natuurlijk niet DNSSEC.

Echter als Verisign DNSSEC heeft geïmplementeerd, dan geef ik niet alleen mijn authoritive nameservers door an verisign, maar eveneens mijn public RSA key. Een dns lookup utility/library welke DNSSEC ondersteund kan dan het antwoord van de DNS server controleren doormiddel van de public key. Als dan een hacker claimt een authroritive nameserver te zijn kan deze nooit een response terug sturen met de juiste fingerprint (SHA-1 checksum) en daardoor weet de DNS client dat het antwoord incorrect is. De response van verisign is te controleren door de public RSA key welke verisign aan ICANN heeft doorgegeven. Een DNS client dient volgens een draft de icann key via tenmiste 3 rootservers op te halen. De kans dat een hacker 3 rootservers weet te hacken is vrijwel onmogelijk.

Eerder was er het probleem wie de master root key gaat beheren. Imiddels heeft ICANN die taak gekregen. Omdat ICANN de root key beheert kunnen ook op de root servers (welke dus aangeven dan Verigign de beheerder van .net en .com tld's is) DNSSEC geimplementeerd worden. Immers DNSSEC moet vanaf de top zijn geimplementeerd om effectief te zijn. Alleen dan kunnen alle responses van de rootservers (.) , tld servers (.com) en domein (example.com) dns servers gecontroleerd worden via de fingerprint.

Nu Verisign DNSSEC gaat implementeren zal het aantal DNS servers met DNSSEC toenemen.

[zenlord]

Ik heb net dns.be even een mailtje gestuurd, en blijkbaar is men daar ook bezig met tests vooraleer de aankondiging van de omschakeling te gaan doen. Blijkbaar is er nog een probleem met de grote hoeveelheid cryptografische bewerkingen die moeten gebeuren en het beheer van de verschillende sleutels.

[Trax_Digitizer]

Het duurt even, maar uiteindelijk starten ze dus toch met DNSSEC. Goede ontwikkeling als je het mij vraagt. Nu maar hopen dat iedereen met een DNS-server ook DNSSEC gaat implementeren, want ander lopen we nog steeds risico's.

Een tijdje terug schreef ik samen met een collega het volgende artikel in de Automatisering Gids: http://www.dennisbaaten.c...otocollen-zijn-gevaar.pdf. Daar gebruikten we het DNS protocol als voorbeeld om aan te geven dat de organisatorische complexiteit groot is, wanneer er een kwetsbaarheid in de specificatie van het protocol is ontdekt die niet herstelbaar is. Er dient dan overgestapt te worden naar een alternatief. En die overstap heeft eigenlijk alleen maar nut, als iedereen dat doet.

Ben heel benieuwd hoe dit verder gaat. Dat ze bij SIDN maar eens opschieten met de DNSSEC implementatie.

[Verwijderd]

Volgens mij brengt DNSSEC wel heel veel werk met zich teweeg, ik weet niet of dit nog werkbaar is als "alle" DNS servesrs hiervan gebruik gaan maken.
Er is ook een alternatief -> DNSCURVE die makkelijker te implementern valt.

[PJJ]

In totaal zou bijna 80 procent van alle dns-servers nog met dnssec werken doordat het aantal dns-servers sterk is blijven groeien. Door de langzame overgang naar dnssec houden kwaadwillenden de mogelijkheid om onder andere ddos-aanvallen uit te voeren en eindgebruikers ongemerkt naar schadelijke websites te lokken.


Is dit een foutje of lees / begrijp ik het verkeerd?

[dsmink]

Ik vond het ook vreemd ja.. ik denk een foutje

[Qwerty-273]

In totaal zou bijna 80 procent van alle dns-servers nog niet met dnssec werken

tenminste dat verwacht ik.