Vanwege de veiligheid moeten de DNSSEC-sleutels van topleveldomeinen (TLD’s) regelmatig worden vervangen. Zo’n roll-over is echter ook riskant, want als het mis gaat kan het hele TLD onbereikbaar worden voor validerende resolvers. In december 2017 monitorden we de roll-over van het algoritme van het Zweedse TLD .se. In deze blogpost lees je over de resultaten en methodiek van ons onderzoek.
Vervangen DNSSEC-sleutels is een kritiek proces
Bij gebruik van ondertekende zones moeten de DNSSEC-sleutels regelmatig worden vervangen. Hier zijn verschillende redenen voor. Het kan bijvoorbeeld zijn dat het sleutelbeheerbeleid dit voorschrijft, dat er sprake is van een beveiligingslek, of dat de operator het algoritme moet updaten. Wat de reden ook is, de rollover blijft een kritiek proces, want als het fout gaat is de hele zone minutenlang of zelfs urenlang onbereikbaar voor validerende resolvers. Dit heeft vooral ernstige gevolgen voor grotere zones, zoals topleveldomeinen (TLD’s), want daar gaat het al gauw om miljoenen domeinnamen.
Vervangen van het .se algoritme
IIS, de operator van .se, planden de rollover van hun algoritme voor december 2017. Ze ondertekenden hun zone als eerste ccTLD met DNSSEC. In 2005 kozen ze het algoritme RSA/SHA-1 om hun eerste sleutels en handtekeningen te genereren en ze gebruikten dit nog steeds. RSA/SHA-1 is inmiddels wat verouderd en daarom was het tijd om op een nieuw algoritme over te stappen. De keus viel op RSA/SHA-256. In hun blog licht IIS deze beslissing en de planning verder toe.
Measurements and methodology
IIS vroeg SIDN Labs om hun rollover te monitoren. Hierdoor kregen we voor het eerst de kans om de rollover van een algoritme grondig te testen en een methodiek te ontwikkelen die operators kunnen gebruiken om dit kritieke proces te monitoren. Ons doel was om operators meer inzicht te geven in hun roll-overs, zodat ze bij elke stap in het proces meer gefundeerde beslissingen kunnen nemen om hun zone bereikbaar te houden.
Samen met collega’s van Northeastern University, Universiteit Twente, en IIS maten we het hele rollover proces met RIPE Atlas en het HTTP proxy netwerk Luminati. In het totaal gebruikten we ruim 46.000 vantage points, verspreid over ruim 12.000 autonome systemen. Het resultaat was dat we een realistisch beeld van de .se rollover kregen en tegelijkertijd ook van resolvers met mogelijk afwijkend gedrag.
We gebruiken momenteel dezelfde platformen om de KSK rollover in de root zone in het Root Canary project te monitoren.
Problemen met het tijdschema van rollovers
Mislukte rollovers van sleutels of algoritmen brengen met name de bereikbaarheid van zones in gevaar. Eén van de grootste problemen voor operators is te bepalen wanneer de nieuwe sleutels worden toegevoegd en de oude worden verwijderd.
Dit heeft te maken met het cache-gedrag van recursieve resolvers. Het kan bijvoorbeeld voorkomen dat een resolver wel een handtekening die met de oude sleutel is gegenereerd heeft gecachet, maar niet de sleutel zelf. Wanneer de resolver vervolgens probeert om de handtekening te valideren, moet hij de sleutel opnieuw opvragen. Als de operator de oude sleutel te vroeg heeft verwijderd, dan krijgt de resolver alleen de nieuwe sleutel en kan hij de handtekening in zijn cache niet valideren.
We weten uit eigen ervaring dat dit een reëel scenario is: bij de introductie van DNSSEC bij .nl begingen we de fout om een oude sleutel te vroeg te verwijderen, met als gevolg problemen met validerende resolvers.
Vervanging DS
Om dat soort problemen te voorkomen bestaat een rollover uit een aantal afzonderlijke fasen, die uitvoerig worden beschreven in RFC 6781. Eén van de meest cruciale fasen in de rollover van het .se algoritme was het moment waarop de DS vervangen moest worden in de root. Een fout op dat punt in de roll-over kon alle .se-domeinen onbereikbaar maken voor validerende resolvers.
De .se operators moesten zorgen dat de nieuwe DS correct naar elke authoritative resolver werd verstuurd. Ze moesten resolvers ook genoeg tijd geven om de nieuwe DS op te pakken voordat ze de oude sleutels verwijderden.
In de .se rollover werd de DS op 14/12/2017 om omstreeks 17:30 UTC in de root zone vervangen. Vanaf onze RIPE Atlas vantage points zagen we een vertraging in de publicatie bij de root van circa 10 minuten. Daarna antwoordde elke root site met de nieuwe DS (zie Figuur 1).
De TTL van de DS is 1 dag en, zoals verwacht, had 99 procent van de gemeten resolvers na 24 uur de nieuwe DS in hun cache opgeslagen (zie Figuur 2).
Sommige resolvers hielden de oude DS echter langer in hun cache; wij observeerden een maximale vertraging in de verspreiding van 48 uur (zie Figuur 3). Soortgelijk gedrag werd eerder geconstateerd door mijn collega Giovane.
Falende resolvers?
De grote vraag is echter: waren er ook resolvers die faalden tijdens deze fase van de rollover?
Om deze vraag te kunnen beantwoorden valideerden we gedurende de hele rollover continu ondertekende .se-domeinen. Figuur 4 toont het aandeel gemonitorde resolvers die:
.se-domeinen met succes resolven en valideren (secure)
.se-domeinen met succes resolven, maar niet valideren (insecure)
.se-domeinen niet resolven (bogus)
Goed nieuws: we constateerden geen stijging van het aantal falende resolvers tijdens de vervanging van de DS in de root. Sterker nog: het aantal falende resolvers steeg in geen enkele fase van de rollover.
We kunnen daaruit concluderen dat de roll-over van het .se-algoritme een succes was. Elke fase van de rollover werd correct uitgevoerd, met genoeg tijd om de nieuwe records te publiceren en verspreiden. De zone bleef gedurende de hele roll-over veilig en eindgebruikers ondervonden geen nadelige gevolgen.
Daarbij is het vermeldenswaardig dat de metingen weergegeven in Figuur 4 ook andere problemen aan het licht hadden kunnen brengen, zoals publicatie van de verkeerde DS in de root of het gebruik van onjuiste handtekeningen. Dit was echter niet het geval.
Meer grip op roll-overs
Op basis van onze observatie van de .se rollover hebben we een meetmethodiek ontwikkeld die andere operators kunnen gebruiken om de roll-overs van onder andere hun algoritmen te monitoren. Het volgen van de methodiek geeft operators meer inzicht in de rollover en meer vertrouwen in de beslissingen die ze bij elke stap in het proces moeten nemen, zodat de zone continu bereikbaar blijft.
Wij ontwikkelen momenteel ook een klein open source tool dat operators kunnen gebruiken om de benodigde metingen op te zetten. Dit tool is gebaseerd op de RIPE Atlas probes en maakt gebruik van de RIPE Atlas API.
Uitgebreide beschrijvingen van de methodiek en de tool worden in de komende paar weken op deze blog gepubliceerd.
