Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

De root KSK roll-over — veel gestelde vragen

Op dit moment is ICANN bezig met de roll-over van het KSK-sleutelpaar van de DNS root. Dat betekent dat ICANN het huidige cryptografische sleutelpaar dat de basis vormt voor de DNSSEC-infrastructuur vervangt door een nieuw sleutelpaar.

Beheerders van validerende resolvers moeten het publieke gedeelte van het nieuwe sleutelpaar als trust anchor op hun systemen installeren. Is dat uiterlijk op 11 oktober 2017 niet gebeurd, dan kunnen vanaf die dag de digitale handtekeningen onder de DNS-records niet meer gevalideerd worden. Daarmee zijn dan alle Internet-domeinen voor de gebruikers/applicaties van de betreffende resolver onbereikbaar geworden.

Op deze pagina beantwoorden we de meest gestelde vragen over de root KSK roll-over.

Wat is het KSK-sleutelpaar?

  • De Key Signing Key (KSK) voor de root zone is een cryptografisch public/private sleutelpaar dat een centrale rol speelt in het DNSSEC -beveiligingsprotocol. Dit sleutelpaar fungeert als het vertrouwde startpunt voor de validatie van DNSSEC, net zoals de root zone fungeert als het absolute startpunt voor het opzoeken van domeinnamen in de DNS-hiërarchie.
  • Net zoals je bij de root zone begint om een Domeinnaam in de DNS-hiërarchie op te zoeken, begin je voor DNSSEC-validatie bij de vertrouwde root KSK. Van daaruit bouw je een keten op van opeenvolgende digitale handtekeningen en publieke sleutels — de zogenaamde chain of trust — om uiteindelijk de authenticiteit van de betreffende DNS-informatie te kunnen vaststellen.

Wat houdt de KSK roll-over in?

  • De roll-over is het proces waarbij ICANN het KSK-sleutelpaar dat nu fungeert als startpunt en trust anchor voor de root zone uiteindelijk vervangt door een nieuw sleutelpaar (genaamd KSK-2017). Het is de eerste keer dat dit gebeurt sinds de introductie van DNSSEC in 2010.

Waarom moet de roll-over van het KSK-sleutelpaar gebeuren?

  • Het is in het algemeen onverstandig om cryptografische sleutels oneindig lang te blijven gebruiken. Net zoals wachtwoorden moeten ook sleutels omwille van de veiligheid regelmatig worden vervangen.
  • Een dergelijke vervanging kan men het beste pro-actief uitvoeren — dat wil zeggen: onder normale omstandigheden waarbij alles goed loopt — in plaats van reactief in een noodsituatie.
  • Bij de introductie van DNSSEC in 2010 stelde de Amerikaanse telecom-authoriteit NTIA — betrokken bij de eerste fase van DNSSEC — als voorwaarde dat het KSK-sleutelpaar regelmatig vervangen (gerold) moest worden. De beheerders van de root zone moesten daarom een plan maken om dit proces vijf jaar na de introductie daadwerkelijk uit te voeren.

Voor wie is de KSK roll-over van belang?

  • Internet Access Providers (IAP's), Internet Service Providers (ISP's), registrars, hosters, netwerkbeheerders en anderen die verantwoordelijk zijn voor validerende resolvers moeten hun systemen en apparaten voorzien van de nieuwe publieke KSK-sleutel en deze installeren als trust anchor.

Hoe blijf je op de hoogte van het KSK roll-over proces?

  • ICANN voert een uitgebreide campagne om te zorgen dat alle gebruikers van het KSK-sleutelpaar weten van de aanstaande verandering.
  • SIDN, de beheerder van het .nl top-level domein, heeft een eigen communicatieplan ontwikkeld om de KSK roll-over zo goed mogelijk te laten verlopen. De publicatie van deze 'Veel gestelde vragen' hoort daar ook bij. De komende maanden komt meer informatie beschikbaar via het Nederlands kennisplatform DNSSEC. Ook in de SIDN nieuwsbrief en op sociale media besteedt SIDN aandacht aan dit onderwerp. Bovendien betrekken ze ook kennispartners en koepels bij deze communicatie.
  • Voor dit voorjaar staan bij SIDN deze publicaties in de planning:
    • praktische informatie over het handmatig installeren van de nieuwe publieke KSK-sleutel als trust anchor
    • een overzicht van software-pakketten die het meest worden gebruikt voor validerende resolvers, met daarbij informatie over de huidige, toekomstige of niet te verwachten ondersteuning van RFC 5011
    Voor het najaar staan deze publicaties gepland:
    • praktische informatie voor het operationeel controleren van software en systemen op de goede werking van RFC 5011, waarmee bij de roll-over de trust anchors automatisch worden opgewaardeerd
    • informatie over de uitfasering en het verwijderen van het oude KSK-sleutelpaar

Wat zijn de gevolgen voor internet-gebruikers?

  • Als ICANN het KSK roll-over proces zonder problemen afrondt, levert dat voor eindgebruikers geen zichtbare veranderingen op.

Wat kan er misgaan?

  • Het is mogelijk (waarschijnlijk) dat niet alle systemen en apparatuur die DNSSEC-validatie uitvoert inderdaad wordt voorzien van het nieuwe trust anchor. Wereldwijd gaat het om miljoenen systemen, met naar schatting 750 miljoen gebruikers. Daarnaast kan het in sommige gevallen zo zijn dat bepaalde software niet overweg kan met de veranderingen in het bestand met trust anchors zoals dat op de website van IANA is gepubliceerd. Als deze problemen op grote schaal voorkomen, kunnen de beheerders van de root zone besluiten om de veranderingen terug te draaien om het DNS-systeem weer in een stabiele toestand te krijgen, het zogenaamde 'back out scenario'. Eventueel kan ICANN ook een fase in het roll-over proces verlengen, om op die manier eventuele problemen met het DNS-systeem te voorkomen. Dat kunnen zij bijvoorbeeld doen als er nieuwe informatie bekend wordt waaruit blijkt dat er in de volgende fase op een of andere manier problemen kunnen optreden.

Wat is het effect van zo'n 'back out' of verlenging?

  • Het doel van een 'back out' of een verlenging van een fase is om het DNS-systeem stabiel te houden, opdat de consequenties voor eindgebruikers minimaal zijn.

Hoe lang duurt zo'n 'back out' of verlenging?

  • Een 'back out' of verlenging kan voor onbepaalde tijd zijn, of totdat de achterliggende problemen zijn bestudeerd en gecorrigeerd. ICANN neemt de oplossingen dan op in een nieuw KSK roll-over proces.

Hoe wordt het KSK-sleutelpaar precies vervangen (gerold)?

  • De KSK roll-over vindt plaats in een proces bestaande uit acht fasen, die samen ongeveer twee jaar in beslag nemen. Elk van deze fasen is gekoppeld aan een officiële sleutel-ceremonie. De afzonderlijke fasen staan in de tijdsplanning hieronder beschreven.
  • Het KSK-sleutelpaar wordt gebruikt om de DNSKEY Resource Record Set (RRset) van de root zone digitaal te ondertekenen. Deze handtekeningen worden gezet tijdens de sleutel-ceremonies en worden vervolgens onderdeel van de root zone.
  • Voor de vervanging van het huidige KSK-sleutelpaar wordt eerst het nieuwe sleutelpaar naast het oude sleutelpaar in de root zone opgenomen. Na een periode waarin beide sleutelparen naast elkaar draaien, wordt het oude sleutelpaar uit de root zone verwijderd.

Hoe ziet de tijdsplanning van de acht fasen van het roll-over proces er uit?

  • fase A: sleutel-generatie (oktober 2016):
    • het KSK-2017 sleutelpaar wordt gegenereerd op de eerste locatie voor sleutelbeheer
  • fase B: sleutel-replicatie (februari 2017):
    • het KSK-2017 sleutelpaar wordt gekopieerd naar de tweede locatie voor sleutelbeheer; daarmee is het nieuwe KSK-sleutelpaar officieel gereed voor ingebruikname
  • fase C: de eerste DNS-informatie wordt ondertekend met de KSK-2017 sleutel voor gebruik in fase D (mei 2017):
    • de eerste verzoeken tot ondertekening worden uitgevoerd
  • fase D: publicatie (augustus 2017):
    • ICANN publiceert de publieke KSK-2017 sleutel in de root zone
    • de informatie in de root zone wordt ondertekend met zowel de oude KSK-2010 als de nieuwe KSK-2017 sleutel
  • fase E: roll-over (november 2017):
    • alleen de nieuwe KSK-2017 sleutel wordt nog gebruikt om de root zone te ondertekenen
  • fase F: intrekking (februari 2018):
    • ICANN verwijdert het oude KSK-2010 sleutelpaar uit de root zone
  • fase G: verwijdering 1 (mei 2018):
    • ICANN wist het oude KSK-2010 sleutelpaar in de eerste locatie voor sleutelbeheer
  • fase H: verwijdering 2 (augustus 2018):
    • ICANN wist het oude KSK-2010 sleutelpaar in de tweede locatie voor sleutelbeheer

Welke actie kun je nu al ondernemen?

  • Ontwikkelaars die verantwoordelijk zijn voor software die DNSSEC-validatie uitvoert moeten zorgen dat deze RFC 5011 ondersteunt. Deze standaard maakt het mogelijk de nieuwe publieke KSK-sleutel automatisch binnen te halen uit de root zone en als trust anchor te installeren.
  • We publiceren binnenkort een overzicht van software-pakketten die het meest worden gebruikt voor validerende resolvers, met daarbij informatie over de huidige, toekomstige of niet te verwachten ondersteuning van RFC 5011.
  • Voor software die RFC 5011 niet ondersteunt of installaties waarvoor RFC 5011 is uitgeschakeld is een bestand met trust anchors beschikbaar op de website van IANA. Deze file moet steeds binnengehaald worden als de resolver opstart, en als de KSK-sleutels in de DNSKEY RRset van de root zone zijn veranderd.
  • Software-ontwikkelaars en beheerders van validerende resolvers kunnen gebruikmaken van de operationele tests die ICANN heeft ontwikkeld. Daarmee kunnen zij controleren of hun systemen RFC 5011 goed implementeren en automatisch de trust anchors zullen opwaarderen bij de daadwerkelijke roll-over.

Belangrijke links