Noodherstel met DNSSEC

Wat als we alle sleutels in de HSM's zouden verliezen?

Onze eerste gedachte was dat we ons uit dit scenario zouden kunnen redden door de sleutels te herstellen uit een back-up die op een andere locatie was opgeslagen. Maar als we niet voor elke Zone Signing Key (ZSK) een back-up hadden gemaakt, zouden we alsnog een probleem kunnen hebben. De Key Signing Key (KSK) daarentegen heeft een langere levensduur en is zeker beschikbaar in elke back-up die we maken.

Onze opstelling

Figuur 1 toont onze ondertekeningsopstelling met 2 datacenters. Beide datacenters hebben een keten van systemen die leidt naar een ondertekende zone die wordt gepubliceerd.

De meest relevante onderdelen zijn de signers (*-signp1) en de HSM's (*-hsmp1). De signers staan in een actieve stand-by-opstelling en de HSM's zijn opgesteld als HA-cluster (high-availability cluster). Dit betekent dat beide HSM's beschikbaar zijn om handtekeningen te maken en bijgewerkt worden met nieuwe sleutels.

Impact van verloren sleutels

Als de sleutels verloren zouden gaan, zou er allereerst verlies van service optreden, omdat er geen updates voor de zone gepubliceerd kunnen worden totdat er weer sleutels beschikbaar zijn. Als na het verlies van de sleutels geen actie wordt ondernomen, beginnen domeinen uit te vallen omdat de Resource Record Signatures (RRSIG's) verlopen. De laatste RRSIG die verloopt, is die in het SOA-record (Start of Authority). Het testen op een geldig SOA-record zal dus als laatste mislukken.

In onze vorige opstelling werd de KSK in elke gemaakte back-up bewaard zodat deze altijd hersteld kon worden, maar dat gold niet per se voor de actieve ZSK. Als we de ZSK niet kunnen herstellen en we een nieuwe ZSK moeten introduceren, zouden geen van de met DNSSEC ondertekende zones beschikbaar zijn voor de duur van de TTL van de DNSKEY en/of RRSIG's. Voor .nl zou dit minstens een uur uitval betekenen. Aangezien 60% van de in Nederland gebruikte resolvers valideert (zie Figuur 2), zou dit bepaald niet onopgemerkt blijven, met alle negatieve publiciteit van dien.

Figuur 2 — Percentage validerende resolvers in Nederland.

Preventie

Het valt te beredeneren dat het verwijderen van het DS-record (Delegation Signer) uit de parent dit probleem zou kunnen oplossen. Dit maakt het inderdaad mogelijk om, nadat de DS TTL in de parent is verlopen, een nieuwe (niet-ondertekende) zone te publiceren, maar dat is hooguit een laatste redmiddel, omdat elke zone onder .nl onveilig zou worden. Dat zou betekenen dat DANE en SSHFP niet meer zouden werken voor .nl-domeinen.

Om sleutels vanuit een back-up te kunnen herstellen, moet er elke keer dat er een ZSK wordt gemaakt ook een back-up worden gemaakt. Voor .nl is dit elke 90 dagen, en omdat we ook nog andere TLD's hebben, zou dat betekenen dat we verschillende back-ups moeten maken. Omdat de back-ups offline zijn, zou dat een enorm karwei zijn.

Aangebrachte verbeteringen

In OpenDNSSEC hebben we de instelling RequireBackup ingesteld om ervoor te zorgen dat sleutels pas worden gebruikt als OpenDNSSEC weet dat ze in een back-up zijn meegenomen. Daarnaast hebben we de back-upprocedure aangepast zodat OpenDNSSEC ook weet wanneer een back-up werd gemaakt.

Omdat AutomaticKeyGenerationPeriod standaard is ingesteld op één jaar, genereert OpenDNSSEC alle sleutels die voor een jaar nodig zijn, zodat die sleutels in de back-up kunnen worden meegenomen. We voerden een test uit met een configuratie waarin de ZSK's regelmatig zouden worden gerold, wat resulteerde in 4.000 sleutels in onze HSM. Zoveel sleutels in de HSM had een aanzienlijke impact op sommige OpenDNSSEC-tools, zoals het commando ods-hsmutil list dat erg traag werd.

Als gevolg daarvan moesten we die HSM-partitie wissen en de AutomaticKeyGenerationPeriod wijzigen in een praktischere periode van ongeveer 4 uur. Voor de productieopstelling van .nl hanteren we een AutomaticKeyGenerationPeriod van een jaar, omdat de ZSK elke 90 dagen wordt gewijzigd.

Verder hebben we geplande tickets aangemaakt in ons ticketsysteem om ervoor te zorgen dat er om de 6 maanden back-ups van de nieuwe ZSK's worden gemaakt.

Figuur 3 — Tijden met betrekking tot het ondertekeningsproces.

Zoals Figuur 3 laat zien wat de reactietijd is en we zijn overgestapt op een langere geldigheidsduur (validity period) van 8 dagen en een kortere periode voor herondertekening (resign period) van 5 uur. In geval van sleutelverlies zorgen de aangebrachte wijzigingen ervoor dat we ten minste 7 dagen de tijd hebben om de sleutels te herstellen (hoewel er vanwege verlies van service sneller zal moeten worden geacteerd).

Ter afsluiting

Door dit 'wat als'-scenario te doorlopen hebben we ontdekt hoe we de impact van sleutelverlies op een geschikte manier kunnen verkleinen, namelijk door onze configuratie en procedures aan te passen. Dankzij deze aanpassingen hebben we onze DNSSEC-opstelling aanzienlijk kunnen verbeteren en blijft .nl veilig en beschikbaar.

Berry van Halderen van NLnet Labs droeg bij aan dit artikel.