Eén ding tegelijk, geen haast, en altijd alles onder controle
Updates op de .nl-zone vragen om gedegen voorbereiding en uiterste behoedzaamheid
Het belang van de .nl-zone voor de Nederlandse maatschappij en economie is enorm. Dat maakt dat updates op het DNS(SEC)-systeem een gedegen voorbereiding en een uiterst behoedzame uitvoering vereisen. Tegelijkertijd kunnen updates ook niet te lang uitgesteld worden, omdat dit op termijn ten koste gaat van de stabiliteit en de veiligheid van de zone.
Noodzakelijk onderhoud, zoals de overstap van DNSSEC-algoritme nummer 8 naar nummer 13 onlangs, wordt door onze beheerders vooral vanuit de techniek aangevlogen. "Als je nadenkt over de maatschappelijke en economische consequenties van uitval, dan durf je op een gegeven moment niets meer. Een fout leidt zeker tot kamervragen, en in ernstige gevallen misschien wel tot ingrijpen van het ministerie van Economische Zaken." Vandaar dat rapportages van incidenten bij andere registry’s – net als hun succesverhalen overigens – voor onze beheerders belangrijk leesvoer zijn. "De schade van dergelijke incidenten is voor het hele internet. Het delen daarvan is de enige manier om ze de volgende keer te voorkomen."
Het afgelopen jaar hebben we meerdere gevallen gezien van topleveldomeinen die (kortstondig) in de problemen kwamen met hun DNSSEC-configuratie. Als gevolg daarvan werden ze tijdelijk onbereikbaar voor gebruikers van validerende resolvers.
Inconsistente DNSSEC-records in .nz-zone
Het ernstigste geval betrof het .nz-topleveldomein van Nieuw-Zeeland, dat op 29/30 mei 2023 gedurende een tijdsspanne van 15-20 uur serieuze bereikbaarheidsproblemen had [1, 2]. De oorzaak lag in de jaarlijkse KSK-rollover van hun traditionele (categorische) second-leveldomeinen, waarbij de oude KSK-handtekeningen onder de ZSK-sleutels te vroeg werden weggehaald. Die oude handtekeningen waren echter nog nodig volgens de DS-records die (mogelijk) al/nog aanwezig waren in de caches van validerende resolvers, waardoor deze resolvers de betreffende (nu bogus) domeinnamen (terecht) blokkeerden. Hoewel de beheerders van InternetNZ al gauw doorhadden wat het probleem was, was het kwaad al geschied: de oude DS-records in de caches van validerende resolvers moesten verlopen (afhankelijk van de resterende TTL-waarde) of handmatig uitgespoeld worden (voor dat laatste is men gaan bellen naar grote accessproviders).
Figuur 1: Percentage mobiele apparaten met validatieproblemen gedurende het incident. Bron: InternetNZ.
Menselijke fouten en onvoorzienigheden
De onderliggende oorzaak van dit incident was de ingebruikname van het nieuwe InternetNZ Registry System (IRS) een half jaar eerder, waarbij verzuimd was de timing-parameters van OpenDNSSEC aan te passen aan het nieuwe systeem. Daardoor ging de OpenDNSSEC-signer er tijdens het rolloverproces ten onrechte vanuit dat de oude DS-records al uit de resolver caches op internet waren gespoeld, terwijl dit feitelijk nog niet het geval was. Voor de details van dit incident verwijzen we je naar de technische rapportage en de externe rapportage.
Een kleiner incident betrof het .vz-topleveldomein van Venezuela, dat deze zomer ook tijdens een KSK-rollover even bogus ging [1].
Meest recent ten slotte waren de problemen met het domein ripe.net van RIPE NCC, de Regional Internet Registry (RIR) voor groot-Europa en West-Azië (en dus van onze regio). Hun domeinnamen waren begin deze maand anderhalf uur lang ongeldig (bogus) vanwege een typefout in een enkel record, dat daardoor een TTL-waarde kreeg die langer was dan de geldigheid van de DNSSEC-handtekeningen. Als gevolg daarvan stopte de DNSSEC-software (Knot) met de herondertekening van de zone, wat pas bij het verlopen van de oude handtekeningen werd ontdekt. [1]
Op de website van IANIX vind je een lijst met tientallen DNSSEC-gerelateerde incidenten. Wat veel van deze gebeurtenissen gemeen hebben, is dat hun oorzaak ligt in menselijke fouten en onvoorzienigheden buiten de (geautomatiseerde) routines.
Waardevolle incidentrapportages
Voor onze beheerders zijn dit vanzelfsprekend nare maar wel hele nuttige verhalen om te lezen. "Er zijn natuurlijk best practices en meerdere RFC's [9364, 6781 en 6840] die operationele DNSSEC en sleutel/algoritme-rollovers beschrijven," vertelt Stefan Ubbink, DNS-engineer bij SIDN. "Maar ook deze rapportages zijn voor ons zeer waardevol. Incidenten worden zowel online besproken als in CENTR-verband [de Europese koepel van ccTLD-registry’s]."
"Het is voor iedereen belangrijk dat men open is over wat er precies gebeurd is, want de schade is voor het hele internet. Mensen maken nu eenmaal fouten, en het delen daarvan is de enige manier om dezelfde fout de volgende keer te voorkomen."
"Zo had het .se topleveldomein van Zweden begin vorig jaar DNSSEC-problemen [1, 2]," vertelt SIDN’s Infrastructuur & Security-Architect Marc Groeneweg. "Naar aanleiding van hun rapportages hebben wij gekeken of vergelijkbare problemen bij ons ook zouden kunnen optreden. Maar omdat wij de hele zone valideren voor publicatie, is dat niet het geval."
Communiceren en meten
Maar hetzelfde geldt voor transities die wel goed gaan. Deze zomer hebben we de het KSK-sleutelpaar van de .nl-zone van algoritme nummer 8 naar nummer 13 gerold. "We hebben daarover zowel vooraf als achteraf gepubliceerd," zegt Ubbink. "Die blogs zijn zowel in het Nederlands als in het Engels beschikbaar, zodat anderen die kunnen lezen en eventueel vragen kunnen stellen. Daarnaast zijn we beschikbaar voor presentaties over deze rollover."
"Die blog vooraf is belangrijk om te zorgen dat ook niet direct betrokkenen vooraf weten dat er een bijzondere rollover aan zit te komen. Ik begreep dat InternetNZ bij de KSK-rollover van het .nz-domein dit niet vooraf breed had gecommuniceerd, waardoor de problemen voor te veel mensen als een complete verrassing kwamen."
"Daarnaast hebben we aan de mensen van SIDN Labs gevraagd om te meten wat er tijdens de rollover met de .nl-zone gebeurt. Zo meldden zij een toename van de hoeveelheid TCP-verkeer op onze nameservers, een logisch gevolg van de (tijdelijke) dubbele handtekeningen in de zone, waardoor DNS-antwoorden niet meer in een UDP-pakket pasten."
Eén verandering tegelijk
Een van de belangrijkste uitgangspunten bij dit soort kritische transities is om maar 1 verandering tegelijk door te voeren. Op die manier kun je focussen op een enkele change, hoef je niet te zoeken waar een probleem vandaan komt, en heb je geen last van onderlinge interacties en afhankelijkheden. Zo werd de DNSSEC-storing op het Canadese .ca-topleveldomein begin augustus veroorzaakt doordat registry CIRA in 1 keer de HSM-apparatuur had vervangen en gelijk een algoritme-rollover wilde doen [1].
Zo bezien zou je zelfs kunnen stellen dat de voorbereiding van onze algoritme-rollover al in 2021 is begonnen. "We wisten toen al dat we naar algoritme 13 wilden overstappen," legt Ubbink uit. Vandaar dat we onze HSM's destijds hebben vervangen door systemen die optimaal met ECDSA-cryptografie overweg kunnen."
"Eind vorig jaar hebben we het Opt-Out-bit voor de .nl-zone uitgezet, waarmee nu ook alle NSEC(3)-records voor niet-ondertekende delegaties in de zone zijn opgenomen. Zo voeren we kritische updates steeds stapsgewijs door."
Test en acceptatie
De voorbereidingen voor de algoritme-rollover van juli gingen in februari van start. "We zijn begonnen om het proces in onze testomgeving te doorlopen en alle stappen uit te schrijven," aldus Ubbink. "Daarna hebben we het proces een keer in onze acceptatie-omgeving uitgevoerd, waarbij we vastliepen op de doorlooptijd en het geheugengebruik van het OpenDNSSEC-systeem. De .nl-zone wordt tegenwoordig elk half uur ververst. Maar in de nieuwe configuratie kwamen we voor het gecombineerde ondertekenings- en validatieproces uit op een totale doorlooptijd van 45 minuten. Wij valideren de hele zone voordat we een nieuwe versie publiceren, maar de validatie van digitale handtekeningen duurt nu eenmaal aanzienlijk langer bij gebruik van het ECDSA-algoritme. Daarnaast hadden we tijdens de transitie meer geheugen nodig omdat tijdens een Double-Signature Rollover [1] de hoeveelheid digitale handtekeningen in de zone tijdelijk verdubbelt."
Taak | Tijd (minuten) |
|---|---|
ophalen zone-informatie uit database | 6 |
ondertekenen van de zone | 8 |
valideren van de zone | 5 |
controleren van de zone | 3 |
publiceren van de zone in primaire server | |
Totaal | ~22 |
Tabel 1: Het huidige DNSSEC-ondertekeningsproces duurt nu 20-22 minuten.
Productiedraaiboek
"Na de upgrade van het OpenDNSSEC-systeem zijn we opnieuw begonnen in onze acceptatieomgeving en hebben we het hele proces 5 keer doorlopen. Daaruit komt dan een productiedraaiboek voor de daadwerkelijke rollover. Omdat daar ook 2 stappen bij zitten waarbij we afhankelijk zijn van IANA, weten we wel de volgorde en de doorlooptijd van de interne stappen, maar niet de totale doorlooptijd. Die 2 checkpoints fungeren ook als controlepunten voor ons en zijn onderdeel van onze key ceremony."
"In het productiedraaiboek staan ook de keuzemomenten waarop we moeten beslissen om wel of niet verder te gaan met de rollover. Wordt het proces afgebroken, dan is er nog steeds geen man overboord. De huidige zone (serienummer) blijft in dat geval gewoon staan, zodat we de problemen handmatig kunnen onderzoeken en oplossen. Het enige dat gebruikers in zo'n geval merken is dat wijzigingen niet binnen een half uur zijn doorgevoerd."
Dergelijke noodstoppen zijn echter zeldzaam: er gaan jaren overheen voordat zoiets gebeurt. Voor de .nl-zone is dit al jaren geleden. Alleen voor de .politie-zone – die ook door SIDN wordt beheerd – is een dergelijke gebeurtenis maar een half jaar terug. "Voor een echte DNSSEC-storing op de .nl-zone moeten we meer dan 10 jaar terug naar 2012," vertelt Groeneweg, die zelf al sinds de KEMA-tijd 25 jaar geleden bij de .nl-zone betrokken is. Maar dat incident dateert uit de begintijd van DNSSEC toen er nog vrijwel niet gevalideerd werd, zodat deze nauwelijks overlast veroorzaakte."
Automatisering
Naast een stapsgewijze, enkelvoudige aanpak speelt ook automatisering een cruciale rol bij het voorkomen van incidenten. Vergissingen bij handmatige wijzigingen en invoerfouten komen regelmatig terug als oorzaken van problemen. "OpenDNSSEC neemt ons wat dat betreft veel werk uit handen," zegt Groeneweg. "Je moet wel de timing goed snappen en heel precies uitwerken. Gelukkig hebben we genoeg DNSSEC-kennis in huis. Daarnaast kunnen we snel terecht bij NLnet Labs, de makers van (onder andere) OpenDNSSEC. We gebruiken OpenDNSSEC al vanaf het begin om de .nl-zone te ondertekenen en hebben zelf ook veel bijgedragen aan versie 2.0 van deze software."
"Belangrijk voordeel van OpenDNSSEC is dat je direct toegang hebt tot de timingparameters en andere details," vult Ubbink aan. "Dat was cruciaal in de testfase, waarbij we makkelijk aan alle knoppen konden draaien of snel een andere policy konden inschakelen. Hadden we dat met PowerDNS willen doen (ook een Nederlands product, maar met een heel ander uitgangspunt), dan hadden we steeds moeten wachten totdat de oude configuratie uit het systeem (de cache) weggespoeld was."
Waar de driemaandelijkse ZSK-rollovers op het .nl-domein wel volledig geautomatiseerd zijn, geldt dat niet voor de vijfjaarlijkse, reguliere KSK-rollovers vanwege die handmatige afstemming met ICANN. Hoewel wel de mogelijkheid bestaat om ook deze rollovers volledig te automatiseren (middels CDNSKEY/CDS-records, volgens RFC 8078), wordt dit protocol nog niet ondersteund door de root-zone. De Zweedse registry biedt deze optie wel aan voor domeinnamen onder het .se-domein (een niveau lager dus). Maar in Nederland hebben we die mogelijkheid nog niet geïmplementeerd en zijn daar op dit moment ook geen plannen voor.
Onder vergrootglas
Groeneweg en Ubbink vliegen dit soort transities vooral aan vanuit de techniek. "Als je te veel kijkt naar het enorme belang van de .nl-zone voor de Nederlandse maatschappij en economie, dan durf je op een gegeven moment helemaal niets meer," aldus Groeneweg. "Een fout leidt zeker tot kamervragen, en in ernstige gevallen misschien wel tot ingrijpen van het Ministerie van Economische Zaken. [1]"
"Dat SIDN als registry nu is aangemerkt als een essentiële dienst onder de nieuwe Europese NIS2-richtlijn is wat dat betreft een goede zaak. Daarmee liggen we steeds meer onder een vergrootglas, maar het houdt ons ook scherp." Tegelijkertijd geeft Groeneweg aan dat de operationele consequenties van nieuwe regelgeving voor SIDN beperkt zijn. "Het leeuwendeel zit allang in onze processen en procedures ingebakken."