Hvorfor nøglerotationen i DNS' rootzone er vigtig for dine applikationer (og hvad du skal gøre før den 11. oktober)

Hvis du administrerer DNS-infrastruktur, skal du markere 11. oktober 2026 i kalenderen. Den søndag gennemfører ICANN en planlagt rotation af Root Zone Key Signing Key (KSK) – en kryptografisk nøgleændring i selve fundamentet for DNSSEC-valideringen på internettet.

Konsekvenserne er større, end de måske umiddelbart ser ud til. En resolver, der ikke er opdateret til at have tillid til den nye nøgle, vil ikke blot fejle, når den skal validere DNSSEC-signaturer – den holder op med at opløse alt og går i praksis mørkt.

Hvad er Root KSK egentlig?

Tænk på DNS-hierarkiet som en tillidskæde. Øverst i kæden ligger Root Zone, og Root KSK beskytter den – en kryptografisk nøgle, der forankrer al DNSSEC-validering. Når din rekursive resolver kontrollerer et DNSSEC-signeret domæne, følger den signaturkæden tilbage til denne rootnøgle. Hvis din resolver ikke genkender den nuværende Root KSK, brydes kæden.

ICANN, som forvalter DNS-roden, roterer periodisk disse nøgler som en del af god sikkerhedspraksis. Nøglerotation forhindrer, at en nøgle kompromitteres på lang sigt, og sikrer, at den kryptografiske infrastruktur er robust over for trusler, der hele tiden udvikler sig.

Sådan foregår rotationen

Under en KSK-rotation udskiftes den signeringsnøgle, der bruges til at signere Zone Signing Key (ZSK) for Root Zone. Den nye KSK genererer nye signaturer, og trust anchors skal derfor opdateres. Det er ikke et teoretisk eksperiment – processen har fundet sted før, og hver gang har nogle forældede resolvere oplevet fejl.

Det afgørende problem er følgende: Når en DNSSEC-validerende resolver møder en signatur, den ikke kan verificere, fordi rootnøglen ikke findes i dens trust store, returnerer RFC 4033-kompatible implementationer SERVFAIL. Det betyder NXDOMAIN ved hver eneste forespørgsel – uanset om domænet findes eller ej.

Hvem skal handle?

De DNSSEC-validerende resolvere er det primære bekymringspunkt. Hvis du kører BIND, Unbound, Knot Resolver eller en anden DNSSEC-kompatibel resolver, skal du sikre, at konfigurationen af trust anchors indeholder den nye KSK inden den 11. oktober.

For de fleste brugere sker dette automatisk. Større operativsystemer og DNS-softwareudgaver modtager nøgleopdateringer gennem standardmæssige opdateringsmekanismer. Men hvis du administrerer:

• Specialbygget DNS-infrastruktur
• Indlejrede enheder eller IoT-enheder med begrænsede opdateringsmekanismer
• Interne resolvere med låste konfigurationer
• Air-gapped-systemer, der ikke modtager regelmæssige opdateringer

...skal du manuelt opdatere dine trust anchors.

Sådan kontrollerer du din resolvers status

Den gode nyhed er, at det er ligetil at kontrollere, om du er klar. Kør følgende forespørgsel mod din resolver for at hente rootens DNSKEY-record:

dig @<your-resolver-ip> DNSKEY . +multi

Find KSK-posterne (de identificeres ved flagværdien 257). Sammenlign dem med den KSK, ICANN aktuelt har offentliggjort, og som du kan finde i dokumentationen om Root Zone DNSSEC Practice Statement.

Hvis du bruger BIND, skal du kontrollere din konfiguration af trusted-keys eller dnssec-validation auto. Moderne BIND-versioner med dnssec-validation auto henter og opdaterer automatisk rootnøgler via vedligeholdelse af trust anchors i henhold til RFC 5011.

Det større perspektiv: Hvorfor DNSSEC betyder noget

DNSSEC findes for at løse et grundlæggende problem: DNS blev udviklet i en tid præget af tillid, uden kryptografisk verifikation. Når du forespørger efter example.com, hvordan ved du, om svaret faktisk kom fra de legitime servere, og ikke blev opsnapet og forfalset undervejs?

DNSSEC tilføjer digitale signaturer til DNS-records. Hver zone signerer sine records, og overordnede zoner autentificerer nøglerne i underordnede zoner. Root KSK forankrer hele kæden.

Uden DNSSEC-validering er dine applikationer sårbare over for forgiftning af DNS-cache, man-in-the-middle-angreb og trafikkapring. I 2024 og 2025 steg brugen af DNSSEC-validering blandt større DNS-udbydere, hvilket gør disse nøglerotationer stadig mere afgørende for, at driften fortsætter uforstyrret.

Praktiske trin for de næste to uger

1. Gennemgå dine resolvere — Find ud af, hvilke resolvere der udfører DNSSEC-validering
2. Kontrollér konfigurationen af trust anchors — Sørg for, at de refererer til den nuværende og den kommende KSK
3. Test i et testmiljø — Hvis du foretager ændringer, skal du validere dem inden søndag
4. Overvåg efter rotationen — Hold øje med stigninger i SERVFAIL eller fejl i opløsningen
5. Dokumentér til fremtidige rotationer — Det sker cirka hvert femte år

Hvad sker der, hvis du ikke forbereder dig?

I bedste fald kan du opleve sporadiske fejl i opløsningen. I værste fald bliver din resolver fuldstændig ude af stand til at håndtere DNSSEC-signerede domæner – og efterhånden er det de fleste domæner på internettet.

Root KSK-rotationen er ikke kun ICANNs problem. Den er et fælles ansvar, der holder DNS-sikkerhedsinfrastrukturen intakt. Brug en halv time i denne uge på at gennemgå dine resolvere. Dine brugere vil takke dig, når søndagen kommer, og alt fortsat virker.

Vær sikker, vær valideret.

Du kan læse mere om implementering af DNSSEC og god praksis for DNS i NameOceans infrastrukturvejledninger og managed DNS-tjenester, der er udviklet til udrulning af moderne applikationer.