DNSSEC-ondertekeningsproces voor de .nl-zone vernieuwd

De .nl-zone bevat inmiddels meer dan 6 miljoen domeinnamen, waarvan ruim de helft is beveiligd met DNSSEC. Dat betekent dat alle DNS-informatie van deze domeinnamen is voorzien van digitale handtekeningen, waarmee de authenticiteit van deze informatie cryptografisch beschermd is.

Veilig en robuust

De .nl-zonefile bevat de informatie om alle webdomeinen en mailadressen onder het .nl-topleveldomein te laten werken. Deze file wordt elk half uur ververst, zodat de laatste toevoegingen en wijzigingen zo snel mogelijk online zichtbaar zijn. Daarvoor wordt eerst de generieke zonefile gegenereerd uit de centrale database waarin alle domeininformatie voor .nl is opgeslagen. Vervolgens krijgt de (dubbel uitgevoerde) signingserver waarop OpenDNSSEC draait het signaal om deze zonefile te ondertekenen. De uitkomst – weer een zonefile, maar nu voorzien van publieke sleutels en digitale handtekeningen – wordt vervolgens gedistribueerd naar onze publieke DNS-servers, waar deze informatie voor iedereen beschikbaar is. In de praktijk is het natuurlijk de resolver in je besturingssysteem of op je netwerk die op de achtergrond de DNS-informatie opvraagt bij de vertaling van domeinnamen naar IP-adressen. Daarbij worden – waar beschikbaar – ook de DNSSEC-handtekeningen gecontroleerd. Om veiligheidsredenen bevat de signingserver zelf helemaal geen geheime sleutels. Die zijn opgeslagen in een eveneens dubbel uitgevoerde Hardware Security Module (HSM), die ook het genereren van de cryptografische handtekeningen voor zijn rekening neemt. Op die manier komen de geheime sleutels nooit buiten deze sterk beveiligde systemen. De tweede signingserver staat in een ander datacenter van ons en krijgt telkens de volledige OpenDNSSEC-configuratie van de eerste machine gesynchroniseerd. Zo kunnen we snel overschakelen naar die tweede server op het moment dat de eerste problemen heeft.

Software-problemen opgelost

"We zijn precies een jaar geleden al begonnen met deze upgrade," vertelt Stefan Ubbink, DNS & Systems Engineer bij SIDN. "Directe aanleiding was dat de ondersteuning vanuit NLnet Labs voor versie 1.4 eind oktober 2020 afloopt. Omwille van de continuïteit nemen we een supportcontract af bij NLnet Labs, en daar hebben we over de jaren heen ook regelmatig gebruik van gemaakt. De mannen van NLnet Labs zijn aan het begin van het upgrade-traject ook hier geweest om te helpen bij de installatie van de nieuwe versie van OpenDNSSEC in onze test- en acceptatie-omgeving. Daarbij zijn we eerst begonnen met de 3 kleinere, veel makkelijker te hanteren zones die we ook beheren: .amsterdam, .aw en .politie." "Samen met NLnet Labs hebben we wel een paar problemen op moeten lossen. Zo bleek het geheugengebruik van de actieve software gaandeweg te groeien. Nadat NLnet Labs deze memory leak had gefikst, bleek er nog een klein tweede lek te zijn. Verder viel de verbinding met de database af en toe uit. Met het oplossen daarvan hebben we een belangrijke bijdrage kunnen leveren aan de stabiliteit van de software."

Testen

SIDN maakt gebruikt van de standaardversie van OpenDNSSEC, met daaromheen een hele batterij aan scripts die zorgen voor de bewaking van het ondertekenings- en publicatieproces en de verificatie van alle individuele stappen en uitkomsten. "Daar hebben we wel aanpassingen aan moeten doen." vertelt Ubbink. "In versie 2 is de policy enforcer bijvoorbeeld een volwaardige daemon geworden, die nu zelf in de gaten houdt wanneer er iets moet gebeuren. Dat betekent dat we de controle of de juiste sleutels gebruikt zijn in de zone moesten aanpassen. De build van de software doen we hier zelf. Op die manier hebben we altijd de omgeving klaar staan om in noodgevallen snel patches te kunnen toepassen." Dat deze transitie alles bij elkaar een jaar heeft geduurd, heeft – naast de zorgvuldigheid waarmee dit moet gebeuren, het oplossen van bugs en het aanpassen van scripts – vooral te maken met het testen van de nieuwe servers. "We hebben in die tijd het nieuwe systeem in real-time parallel aan het oude systeem laten meelopen om te zien of alles goed werkte," aldus Ubbink. "Dus moesten we ook steeds lang wachten op een roll-over van het ZSK-sleutelpaar, die maar eens in de 90 dagen plaatsvindt. Ondanks het langdurige testen in onze acceptatie-omgeving, bleek er uiteindelijk toch nog een foutje in de migratie-scripts te zitten. Dat veroorzaakte onlangs een incident in productie, dat we met behulp van NLnet Labs gelukkig snel hebben kunnen oplossen."

Nieuwe policy enforcer

Het verlopen van de ondersteuning voor de oude versie van OpenDNSSEC was natuurlijk een belangrijke stok achter de deur, maar er zitten ook andere voordelen aan het gebruik van versie 2.1. "Vooral de nieuwe policy enforcer die voorheen elk uur wakker gemaakt moest worden, heeft ons leven een stuk makkelijk gemaakt," zegt Ubbink.

Ook Berry van Halderen, Lead Developer bij NLnet Labs, noemt de vernieuwde enforcer als een belangrijke meerwaarde van versie 2. "Meerdere roll-over scenario's en verschillende soorten sleutels worden nu veel beter ondersteund. Denk aan double key en double signature roll-overs, en aan shared en combined keys. Hetzelfde geldt voor het rollen naar een ander cryptografisch ondertekeningsalgoritme. Omdat de enforcer een beter wereldbeeld heeft van de ondertekende zone, is het nu ook veilig om tijdens het rollen van sleutels nog allerlei timing-instellingen aan te passen."

Nieuwe functionaliteit

"We kunnen nu ook weer samen met NLnet Labs nadenken over nieuwe functionaliteit," zegt Ubbink. "Wij zouden bijvoorbeeld veel liever ingebouwde ondersteuning voor high availability (HA) en fail-over willen gebruiken. Nu moeten we als het mis zou gaan handmatig overschakelen naar onze tweede signing server, iets wat bij elkaar toch zo'n 2 uur duurt vanwege de omvang van de .nl-zone en de zorgvuldigheid die hierbij in acht moet worden genomen. Dat NLnet Labs, waarmee we al jaren een (sponsor-)relatie hebben, ook hier in Nederland zit, maakt het veel makkelijker om te praten over zowel problemen als nieuwe features." "Door de opeenvolgende stappen van OpenDNSSEC in te bedden in hun eigen controle- en verificatie-scripts, heeft SIDN onze software op een heel eigen wijze toegepast," zegt Van Halderen. "Wij hebben deze vorm nooit zo in de software geïncorporeerd, maar het kan prima. Dat maakt het voor ons interessant om na te denken of we deze manier niet beter kunnen ondersteunen."

Verbeterpunten

Kijk je naar het aantal wijzigingen per verversingscyclus (elk half uur), dan blijkt het typisch om 200-250 domeinnamen te gaan. Hoewel het daarmee verleidelijk lijkt om alleen met die gewijzigde records aan de slag te gaan, is er volgens Van Halderen veel te zeggen voor het steeds opnieuw genereren en verwerken van de hele zonefile zoals SIDN dat doet. "OpenDNSSEC kan zonder meer met delta's overweg, maar het is veel makkelijker om met de hele zonefile te werken. Je kent altijd de complete state en je weet meteen of die al dan niet correct is, zonder dat je verder nog historische data nodig hebt." Een van de verbeterpunten die Van Halderen ziet voor deze manier van werken is het verminderen van het aantal vertaalslagen waarbij zonefiles van ASCII naar binair worden omgezet, en weer terug. Maar significante prestatieverbeteringen zijn er volgens hem niet te halen. "Uit tests blijkt dat zelfs met OpenDNSSEC op een langzame server nog steeds 90 procent van de ondertekeningstijd door de HSM wordt opgesoupeerd."

Andere registry’s

Maar de belangrijkste opbrengsten van deze upgrade zijn toch wel voor andere registry’s die met versie 2 van OpenDNSSEC aan de slag willen. "We hebben een uitzonderlijk grote zonefile, met veel ondertekende domeinnamen, en dat maakt ons een interessante use case," aldus Ubbink. "We kennen wel een paar andere registry’s die al op versie 2 zitten, waarvan één ook een grotere is, maar zij gebruiken OpenDNSSEC weer op een andere manier." "Met deze upgrade laten we zien dat versie 2 van OpenDNSSEC op deze schaal en op deze manier goed werkt. Bovendien hebben we diverse problemen in de software op kunnen lossen, waarmee versie 2 nu ook voor andere grote TLD registry’s direct inzetbaar is. Dit alles past ook goed bij de voortrekkersrol die we als SIDN willen spelen, zeker wat beveiliging betreft."

Breder vernieuwingstraject

Deze opwaardering van onze signing servers is onderdeel van een breder vernieuwingstraject in onze infrastructuur. Ondertussen faseren we namelijk ook Ubuntu zo veel mogelijk uit ten gunste van Red Hat Enterprise Linux (RHEL). Bovendien willen we begin volgend jaar ook onze HSM's vervangen, waarmee onze DNSSEC-systemen weer helemaal up-to-date zijn. Andere vernieuwingen zijn het opzetten van een anycast-infrastructuur, waarbij waarschijnlijk NSD (ook ontwikkeld door NLnet Labs) en Knot (ontwikkeld door CZ.NIC) als publieke servers ingezet zullen worden.