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)

[bws1989]

Dnssec is ontwikkeld als aanvulling op het dns-protocol en moet de kwetsbaarheden in dat protocol verhelpen.

Een voorruitgang kwa beveiliging is altijd welkom
Alleen hopen dat door de overschakling niet te veel website's / fora's etc niet te bereiken zijn.

[Reactie gewijzigd door bws1989 op 25 juli 2024 00:57]

[mashell]

Een voorruitgang kwa beveiliging is altijd welkom

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.

[Xirt]

Maar het artikel geeft ook mogelijk oplossingen voor de problemen.

[morphje]

Dan .....
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)

[BlackOwl]

Wat voor nadelen?

[Verwijderd]

Beste bws1989, mag ik mijn paarse krokodil terug? hij staat daar!

edit:
ff linkje natuurlijk :d http://www.youtube.com/watch?v=2Rw27vcTHRw

[Reactie gewijzigd door Verwijderd op 25 juli 2024 00:57]

[Peter]

Na een hele serie van klachten tegen de SIDN, stichtingen als ISP Belang en klachten richting de NMa wegens markt-verzieking lijkt de stichting toch eindelijk het licht te hebben gezien op het gebied van vooruitgang en communicatie. Naast het openen van een blog om de progressie rondom het DRS-EPP systeem transparant te houden, een openere houding tijdens bijeenkomsten van deelnemers en meer tevredenheid onderzoeken (ondanks dat wij als relatief kleine deelnemer nog nooit gevraagd zijn) is dit hier natuurlijk een grote stap in. Er is altijd plek voor verbetering, maar wat mij betreft zijn ze goed bezig.

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).

[ktf]

Het heeft weinig zin DNSsec in te voeren als de rootservers het niet hebben lijkt me... Vindt het dus ook niet zo gek dat ze het een maand nadat de rootserver DNSsec hebben ingevoerd 'pas' gaan gebruiken.

[Reactie gewijzigd door ktf op 23 juli 2024 14:37]

[PPie]

Maar dan wordt het een beetje een kip-ei probleem. (Al zouden de roots dit natuurlijk eigenlijk al vanaf het begin van dnssec moeten hebben gehad, vind ik...)
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...

[arjankoole]

(Al zouden de roots dit natuurlijk eigenlijk al vanaf het begin van dnssec moeten hebben gehad, vind ik...)

vanaf het begin? Toen bestond DNSSEC niet, dat is pas veel later uitgevonden.

[CAPSLOCK2000]

Daar is een oplossing voor, genaamd "Lookaside Validation" waarbij je een trusted third party gebruikt om domeinen te controleren als de bovenliggende DNS server nog geen dnssec ondersteund.

Het is een vieze hack en niet bijzonder veilig, maar het werkt.

[Kalief]

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.

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

[Verwijderd]

maar die key kent SIDN dan al én kan altijd meeverhuizen

Nee want:

de publieke sleutels van een domeinnaam moeten dan namelijk bekend zijn bij SIDN.

De publieke sleutels zijn bekend, en voor het signen heb je private keys nodig.

[kimahri]

"Mogelijk wordt dnssec uitgeschakeld tijdens de verhuizing, of is extra actie van de oude provider vereist"

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

[citruspers]

Is dit nog steeds de Dan Kaminsky exploit die maanden geleden het licht zag, of is het iets nieuwers?

[Joost]

Is dit nog steeds de Dan Kaminsky exploit die maanden geleden het licht zag, of is het iets nieuwers?

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.

[fatshark]

Je bedoelt bailiwick domain attack
( 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

[citruspers]

Security now listener vanaf episode 1, maar toch bedankt

[MarcelG]

Begrijp ik 't dus goed dat het hele domeinregistratieverhaal volledig gaat veranderen? Ik heb nu diverse domeinen (.COM, .NL, .NET) en regel nu de DNS via o.a. ZoneEdit.
Nu koppel ik heel snel een ander IP aan een DNS entry, maar moet ik straks private keys etc gaan regelen voor alle entries ?!

[arjankoole]

Je regelt private / public keys voor een of meerdere domeinen. Dus alleen als jij een aanpassing doet, moet je de zone digitaal ondertekenen met de privatekey en je wachtwoord. 1 extra stapje dus.

[MarcelG]

Ah, ok.
Ik ben benieuwd hoe snel dit ook bij bijv. ZoneEdit beschikbaar komt.

[CAPSLOCK2000]

Er wordt een toevoeging gedaan aan het bestaande systeem, er verdwijnt niks; er komen alleen paar record types bij. Alles wat je nu doet moet je blijven doen, maar er komt nog wat bij. Hoeveel ligt nogal aan je organisatie en hoeveel zones je moet beheren. Kleinere sites kunnen dnssec vrijwel helemaal automatiseren (al kost dat wat veiligheid).

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.

[FaalHaas]

Voor dat soort handelingen heb je er helemaal geen last van. Jij hebt voor jouw domein een public key, die is gekoppeld aan het domein. Niet aan de endpoints van de entries, daar kan je dus lekker mee blijven spelen.

[Pinkys Brain]

In wat voor opzicht?

[s.stok]

DNSSec is heel krachtig, maar ook heel complex en fragiel.
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

[FaalHaas]

Neen,

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.

[s.stok]

Ik had het in mijn reactie ook over Cache possiening via een MIDM Aanval