Op 11 oktober 2018 vond een ingrijpende wijziging plaats in het wereldwijde domeinnaamsysteem (DNS): de allereerste KSK roll-over. Deze blog gaat over onze nauwgezette monitoring van dat proces.
The Root Canary Project
In 2017 sloten we ons aan bij het Root Canary project, een gezamenlijk project van zeven onderzoekspartners: SURFnet, Universiteit Twente, Northeastern University, NLnet Labs, SIDN Labs, het RIPE NCC en ICANN. Dit internationale samenwerkingsproject had als doelstelling de geplande root KSK roll-over vanuit zoveel mogelijk verschillende hoeken zorgvuldig te monitoren en te fungeren als vroegtijdig waarschuwingssysteem, mochten zich problemen voordoen.
The KSK rollover
De root zone werd in juli 2010 beveiligd met DNSSEC. Vanwege de veiligheid is het raadzaam om de sleutels regelmatig te vervangen. Hoewel in het IANA Functions Contract is opgenomen dat de KSK-sleutel periodiek moet worden vervangen, wordt er niet in detail getreden over een specifieke tijdlijn of een implementatieschema. Het document DNSSEC Practice Statement for the Root Zone KSK Operator is hier duidelijker over. In Artikel 6.5 staat de gewenste termijn voor roll-overs als volgt geformuleerd:
"Each RZ KSK will be scheduled to be rolled over through a key ceremony as required, or after 5 years of operation."
Na grondige voorbereidingen werd op 27 oktober 2016 de nieuwe KSK-sleutel gegenereerd, waarmee het vervangingsproces in gang werd gezet. In eerste instantie stond de roll-over van de root DNS-sleutel gepland voor 11 oktober 2017. Naar aanleiding van uitgebreid onderzoek binnen de technische gemeenschap werd de roll-over echter een jaar uitgesteld en vond deze dus plaats op 11 oktober 2018.
Hieronder volgt een beschrijving van hoe we het proces middels het Root Canary project hebben gemonitord.
Onze methodologie
Tijdens het project benutten we alle ruim 10.000 RIPE Atlas probes om de roll-over met regelmatige tussenpozen te meten. Dit deden we door DNS-queries te versturen waarin om de DNSKEY van de root zone werd gevraagd en de RRSIG's in de antwoorden te analyseren. De RRSIG wordt immers gedurende een maximale TTL van 172800 seconden (48 uur) gecachet door resolvers. Onze metingen waren erop gericht te bepalen of en wanneer resolvers de oude RRSIG (key id 19036) uit hun caches zouden verwijderen en de nieuwe, op 11 oktober 2018 om 16:00 UTC gegenereerde RRSIG met key id 20326 zouden oppikken. Ook wilden we vaststellen of de validatie correct en volgens verwachting zou blijven verlopen.
Als was gebleken dat een groot aantal resolvers na de KSK roll-over niet meer goed functioneerde, zou dat betekend hebben dat er iets mis was en hebben kunnen leiden tot de implementatie van een ‘back out’-plan. Gelukkig wezen onze metingen uit dat dit niet het geval was.
Enkele uren voor de KSK roll-over begonnen we met het publiceren van informatie over de status van de resolvers die we monitorden. De informatie werd steeds met korte tussenpozen gepubliceerd via ons Twitter-account en op nlnetlabs.nl, de website van onze onderzoekspartners. We zijn hiermee doorgegaan tot twee dagen na de roll-over.
Onze bevindingen
Laten we beginnen met de belangrijkste conclusie: wat ons betreft was de roll-over een succes. We hebben gedurende de roll-over of in de daaropvolgende 48 uur geen grote afwijkingen waargenomen. De rode lijn in de onderstaande grafiek toont het aantal resolvers dat na de roll-over niet in staat was om DNSSEC-handtekeningen te valideren. Zoals je ziet, is de lijn stabiel en blijft hij onder de 1%, wat precies is wat we hoopten te zien. Ook het aantal validerende resolvers bleef stabiel.
Uit de waarnemingen blijkt dat de resolvers de met de 2010-KSK gemaakte oude handtekening met succes vervangen hebben door een nieuwe handtekening die is gemaakt met de nieuwe 2017-KSK. In de onderstaande afbeelding is te zien dat 16 uur na de roll-over 50% van de resolvers de nieuwe handtekening al in hun cache had opgeslagen en valideerde met de nieuwe sleutel. Na 48 uur was meer dan 99% van de resolvers up-to-date, wat overeenkwam met het verwachte resultaat.
Wat de situatie in Nederland betreft: dankzij RIPE Atlas beschikken we over meer dan 500 Nederlandse vantage points. Slechts vier daarvan maakten melding van problemen tijdens de roll-over, allemaal op verschillende netwerken. Dit duidt eerder op geïsoleerde kwesties op lokaal niveau dan op een ernstig probleem bij een grotere serviceprovider.
Hoe nu verder?
Kort samengevat: wat ons betreft was de roll-over een doorslaand succes. We zijn geen grote problemen met resolvers tegengekomen en ook andere bronnen hebben geen ernstige problemen gesignaleerd. Dat is een fantastisch resultaat, waarmee we ICANN en alle anderen die betrokken waren bij de roll-over van harte feliciteren.
We zijn van plan onze eerste bevindingen verder uit te diepen door onze metingen en de ruwe gegevens die we verzameld hebben, grondig te bestuderen. Daarnaast krijgen we van de Root Zone Operators gegevens over het verkeer ten tijde van de roll-over. Als het goed is, zal dit ons nog meer inzicht verschaffen, vooral met betrekking tot resolvers die geen deel uitmaken van de infrastructuur van Ripe Atlas. Ook zijn we van plan richtlijnen op te stellen voor toekomstige root KSK roll-overs, die hopelijk met grotere regelmaat en minder onzekerheid uitgevoerd zullen worden.
Latere bevindingen zullen zowel hier als op https://rootcanary.org te lezen zijn.
Onze dank gaat uit naar RIPE, die de metingen voor ons heeft uitgevoerd, en ook iedereen die ons heeft geholpen door feedback te sturen: heel erg bedankt!
