SIDN wil dnssec voor .nl-zone in augustus 2010 invoeren
SIDN, de stichting die het top-level-domein .nl beheert, is van plan om in augustus 2010 het dnssec-protocol in te voeren voor de .nl-zone. Dat is een maand nadat de internetrootservers op het veiliger protocol moeten zijn overgeschakeld.
Dnssec is ontwikkeld als aanvulling op het dns-protocol en moet de kwetsbaarheden in dat protocol verhelpen. Zo moeten cache poisoning en man in the middle-aanvallen worden voorkomen. Daartoe koppelt dnssec het antwoord op een dns-query aan een digitale handtekening, waardoor makkelijker kan worden gecontroleerd of de antwoorden van een server wel valide zijn. Dns-servers worden hiertoe voorzien van public key cryptography: met de private key wordt het domein gesigned, terwijl de gebruiker met de publieke sleutel kan controleren of het antwoord correct is.
Oorspronkelijk werd bericht dat SIDN verwachtte dnssec in 2009 te kunnen invoeren, maar dat dit door technische problemen niet haalbaar was gebleken. Woordvoerster Lieke Hoogeveen van SIDN stelt nu echter dat dat een misverstand was: er zou volgens haar nooit sprake zijn geweest van een invoering in 2009.
De overstap naar dnssec zal nu worden gemaakt zodra de dns-servers in de root-zone, die verwijzen naar de dns-servers van de tld's, ook zijn overgegaan. SIDN zal het protocol invoeren een maand nadat de rootservers een sleutel hebben gekregen, wat waarschijnlijk neerkomt op augustus 2010. Zodra de Icann toestemming geeft, zal de sleutel worden gepubliceerd op de root-dns-servers. Het is nog onbekend wanneer dit precies zal gebeuren. Overigens gaat het daarbij alleen om de .nl-zone; slechts de dns-servers van SIDN zullen dus worden beveiligd. De individuele domeinnamen volgen daarna, maar het is nog niet bekend wanneer.
Voor de invoering van dnssec op .nl-domeinen zou het registratiesysteem moeten worden aangepast; de publieke sleutels van een domeinnaam moeten dan namelijk bekend zijn bij SIDN. Ook het verhuisproces moet worden aangepast; als meerdere domeinnamen bij dezelfde provider een private key delen, kan die sleutel om veiligheidsredenen niet meeverhuizen naar de nieuwe hostingprovider. Hierdoor zal het domein tijdelijk onbereikbaar worden, tenzij hiervoor een oplossing wordt gevonden. Mogelijk wordt dnssec uitgeschakeld tijdens de verhuizing, of is extra actie van de oude provider vereist. Daarnaast zal er een manier van 'sleutelmanagement' bij providers en domeinnaamhouders moeten worden ingericht.
Het eerste tld dat gebruikmaakt van dnssec is .org, en vorige maand werd bekend dat VeriSign ervoor gaat zorgen dat ook de .com-, .edu- en .net-tld's van het protocol zullen worden voorzien. Dit zou uiterlijk maart 2011 voltooid moeten zijn.
Reacties (30)
Een voorruitgang kwa beveiliging is altijd welkomDnssec is ontwikkeld als aanvulling op het dns-protocol en moet de kwetsbaarheden in dat protocol verhelpen.
Alleen hopen dat door de overschakling niet te veel website's / fora's etc niet te bereiken zijn.
[Reactie gewijzigd door bws1989 op dinsdag 8 december 2009 17:43]
Als je werkgever een wekelijks wisselend wachtwoord van 16 tekens waarvan 5 niet alfanumeriek invoert haal je die smilie wel weg. Veiligheid is belangrijk maar soms lijdt de bruikbaarheid van een systeem er wel onder. Daar moet je een compromis zien te vinden. Zo heeft Dnssec zoals in het artikel beschreven is echt wel nadelen.Een voorruitgang kwa beveiliging is altijd welkom
1) heeft je werkgever totaal geen clue van usability whatsoever. eens per kwartaal is vrij normaal in een high sec omgeving.
2) het is een very high security admin account, waarvan je weet dat het redelijk is dat deze eis er ligt.
Er van uitgaande dat er maar zeer beperkte motivaties zijn voor 2, ga ik uit van situatie1 en moet je baas eens uitgelegt gaan worden dat 90% van de medewerkers het wachtwoord opschrijft.
De hoogste password eis die ik gezien heb (BS7799) is 12 karakters, 3mnd, daarna ga je over op technieken als tokens of biometrie. (gecombineerd natuurlijk met password)
ff linkje natuurlijk :d http://www.youtube.com/watch?v=2Rw27vcTHRw
[Reactie gewijzigd door Incr.Badeend op dinsdag 8 december 2009 19:22]
lekker dan
probleem met je hostings provider ...?
komt er gewoon geen actie of maanden later pas.
ben door een administratieve actie ook een domein kwijtgeraakt ben ik niet blij mee
dankzij as hosting www.cd-raiser.com
Daarom dan zijn mensen er altijd huiverig over geweest.
Wat een andere optie zou zijn, en welke minder risico's met zich mee brengt is de verbinding tussen de DNS server en de client te beveiligen.
Dus alleen de communicatie, en niet de gegevens integriteit zelf
Alleen is SSL niet erg stabiel over UDP.
En TCP was al geen optie omdat het anders te zwaar zou worden.
Het hele problemen waarom dit bestaat is omdat veelal UDP word gebruikt i.p.v TCP.
En bij nader inzien zou SSL met die huidige handshake Vurnability ook niet veilig meer zijn
SSL gaat immers alleen over het transport van de data, en daar zit het isssue niet. Hier gaat het om hijacking van het een domein. Bijvoorbeeld een betaalsite.
Een DNS hijack zou theoretisch niet meer mogelijk moeten zijn, om dat de key check niet slaagt.
Gezien een aantal exploits op het gebied van nameservers in de afgelopen periode, met name de DNS spoofing op server niveau zijn updates gewoon noodzakelijk, met name als je nagaat dat de huidige standaard uit 1987 komt (toevoegingen en aanpassingen daargelaten).
[Reactie gewijzigd door ktf op dinsdag 8 december 2009 17:57]
Maar waarom zou je je niet voorbereiden? Dan ben je er alvast klaar voor...
En als iemand de moeite neemt om het public key deel van het NL deel (Toch niet geheel onbelangrijk in NL...) te importeren in de locale DNS checker, kan die persoon in ieder geval kijken of het klopt voor de .nl domains...
vanaf het begin? Toen bestond DNSSEC niet, dat is pas veel later uitgevonden.(Al zouden de roots dit natuurlijk eigenlijk al vanaf het begin van dnssec moeten hebben gehad, vind ik...)
Het is een vieze hack en niet bijzonder veilig, maar het werkt.
Dit is gewoon een algehele update voor het dns-systeem dat eigenlijk niet veilig genoeg is. De exploit van Kaminsky (cache poisoning) is in feite recenter dan dnssec, al is het wel een van de problemen die met het betere dns-protocol kunnen worden opgelost.Is dit nog steeds de Dan Kaminsky exploit die maanden geleden het licht zag, of is het iets nieuwers?
( meer te lezen op http://riosec.com/metaspl...-dns-exploit-adds-domains )
Met dnssec is dit 'cache poisoning' opgelost.
Steve Gibson heeft een leuke podcast hieraan gewijd
( http://www.grc.com/sn/sn-155.htm )
Je kan tevens je DNS server testen hoe 'veilig' ze nu zijn
entropy.dns-oarc.net/test
Zou dan niet bij uitgifte van een .nl domein door SIDN zelf aan de domeinaanvrager een key kunnen worden gegeven? OK, beetje laat voor alles wat er al is, maar die key kent SIDN dan al én kan altijd meeverhuizen. Ze zouden er nu vast mee kunnen beginnen
Nee want:maar die key kent SIDN dan al én kan altijd meeverhuizen
De publieke sleutels zijn bekend, en voor het signen heb je private keys nodig.de publieke sleutels van een domeinnaam moeten dan namelijk bekend zijn bij SIDN.
Nu koppel ik heel snel een ander IP aan een DNS entry, maar moet ik straks private keys etc gaan regelen voor alle entries ?!
Ik ben benieuwd hoe snel dit ook bij bijv. ZoneEdit beschikbaar komt.
DNSSEC is niet zo zeer een technisch probleem als wel een organisatorisch probleem. De techniek is er wel, nu moeten we nog procedures gaan maken om regelmatig handtekeningen te verversen, de controle over de handtekeningen te regelen, beslissen wat er moet gebeuren als een handtekening niet klopt, overleggen wat je moet doen als er iets mis gaat met de ondertekening van je domein, etc. etc.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
