Videre til indhold 
Jeg viser, hvordan man udfører en korrekt rotation af DNSSEC-nøgle og automatiseret signering kan pålideligt forhindre uautoriserede ændringer, undgå nedbrud og forenkle driften. Til dette formål beskriver jeg klare procedurer for udskiftning af ZSK- og KSK-nøgler, tidsregler for TTL/RRSIG og satser på automatisering, der genererer, roterer og dokumenterer nøglerne på en sikker måde.
Centrale punkter
De følgende hovedpunkter fører direkte ind i den praktiske anvendelse af sikker nøglerotation og signering.
- ZSK/KSK skal skilles tydeligt ad og roteres gradvist
- Automatisering styrer signering og rollover med få fejl
- Timing Overhold nøje TTL og RRSIG
- Overvågning for løbetider, DS og validering
- Politik til intervaller, nødsituationer og revisioner
DNSSEC kort forklaret: Signaturer og tillidskæde
DNSSEC supplerer navneopløsningen med kryptografiske signaturer, så resolverne kan kontrollere svarens ægthed og Integritet kan kontrolleres. En privat nøgle signerer zonedata, mens den offentlige nøgle findes som en DNSKEY i DNS og danner grundlaget for valideringen. Tillidskæden forbinder rodzonen, topdomænet og den egne zone via DS-posten, hvorved hvert trin validerer det næste godkendt. På den måde blokerer jeg cache-poisoning og man-in-the-middle-angreb allerede på DNS-niveau. Uden korrekt nøglevedligeholdelse mister dette beskyttelseslag sin virkning, og derfor lægger jeg stor vægt på nøgleudskiftning, timing og automatisering.
Målrettet anvendelse af ZSK og KSK
Jeg bruger ZSK til signering af ressourceposterne, og vælg derfor kortere opdateringsintervaller. Den KSK underskriver DNSKEY-posten og forbinder zonen med det overordnede DS-niveau, og derfor planlægger jeg kun sjældent at skifte den og gør det med særlig omhu. Jeg adskiller disse roller strengt for at muliggøre den operationelle rotation af ZSK uden konstante ændringer i registret. Hvis du vil forstå tillidskæden bedre, kan du gå videre til denne praktiske oversigt over DNSSEC-tillidskæde . På den måde holder jeg signaturerne fleksible, sikrer forankringen til TLD’en og bevarer kontrollen over begge nøgletyper.
Sikker gennemførelse af DNSSEC-nøglerotation
For at skifte ZSK genererer jeg først en ny nøgle med tilstrækkelig Nøglelængde og offentliggør den som DNSKEY ud over den gamle. Derefter underskriver jeg zonen på ny, men lader den gamle ZSK fortsat underskrive, indtil de nye nøgler er synlige overalt. Jeg overholder TTL'erne for DNSKEY og RRSIG og venter, indtil resolverne har den nye nøgle sikkert gemt. Derefter sætter jeg den aktive signatur til den nye ZSK og lader gamle signaturer udløbe efter planen. Først efter at have opbygget en sikkerhedsreserve fjerner jeg den tidligere nøgle for at undgå valideringsfejl som følge af for tidlig sletning.
Automatisk signering i praksis
Jeg satser på automatisk signering, så navneserveren administrerer nøglerne internt, genererer nye nøglepar og styrer rollover-faser præcist. Her bruger softwaren fastlagte retningslinjer for intervaller, gensigneringsvinduer og reservetider, hvilket gør det muligt for mig at undgå timingfejl. On-the-fly-signering eller periodisk gensignering forhindrer udløbne RRSIG'er og holder Zone altid gyldige. Via de integrerede logfiler kan jeg straks se, hvornår nøgler genereres, aktiveres og deaktiveres. Hvis man ønsker at dykke dybere ned i de konkrete indstillinger og styringen, finder man her en grundig introduktion til automatisk underskrivning.
Overvågning, logning og revision
Uden overvågning mister enhver automatisering sin Effekt. Jeg overvåger RRSIG-gyldighedsperioder, udgivelsesvinduet for nye DNSKEY’er og tilgængeligheden af DS-poster hos registriet. Et godt tærskelkoncept minimerer falske alarmer, men jeg reagerer straks på forkortede signaturgyldighedsperioder, valideringsfejl eller uoverensstemmelser i Chain of Trust. Fra logfiler udleder jeg tidsperioder, hvor signaturer er blevet fornyet, og kan således spore hændelser præcist. Planlagte audits kontrollerer algoritmer, nøglelængder og politikker for at sikre Sikkerhed på lang sigt.
TTL'er, RRSIG'er og typiske timing-fælder
Rotation afhænger af god timing, og derfor vælger jeg TTL-værdier for DNSKEY- og RRSIG-poster med omhu. For høje TTL'er forlænger overgangsfaser, for lave værdier øger belastningen og kan skabe valideringshuller, hvis signaturer udløber for tidligt. Når jeg offentliggør både den nye og den gamle nøgle, venter jeg mindst en hel TTL plus en reserve, før jeg skifter den aktive signaturnøgle. Efter skiftet lader jeg naturligvis de gamle signaturer udløbe, før jeg sletter de gamle nøgler. Hvis man ikke overholder denne rækkefølge, skaber man huller i tillidskæden og risikerer forespørgsler, der ikke kan besvares.
Vælg kryptoalgoritmer og nøglelængder med omhu
Jeg vælger algoritmer ud fra de aktuelle anbefalinger og tager højde for ydeevne, signaturlængde og klientkompatibilitet. RSA 2048 anses for at være praktisk anvendelig i mange opsætninger, men ECDSA reducerer signaturstørrelsen og forbedrer responstiderne. For ZSK’er planlægger jeg kortere levetider og satser på pålidelige Generatorer med god entropi. Jeg beskytter KSK’er særligt omhyggeligt, opbevarer dem om muligt i HSM’er eller strengt kontrollerede miljøer og implementerer ændringer korrekt via DS-opdateringer. En regelmæssig gennemgang af algoritmer sikrer, at jeg skifter til nye metoder i tide, når de gamle bliver forældede.
At tænke DNSSEC, TLS og e-mail-godkendelse i et samlet perspektiv
DNSSEC beskytter navneopløsningen, mens TLS sikrer transmissionsforbindelsen, og certifikatstyring forhindrer nedgraderinger. Til e-mail satser jeg på SPF, DKIM og DMARC, så forfalskninger har færre muligheder. Jeg planlægger disse komponenter samlet, så angribere ikke kan komme forbi et svagt punkt. Hvis du vil komme i gang med det samme, kan du følge denne korte vejledning til Aktivér DNSSEC og tilføjer senere HSTS og rene certifikatcyklusser. På den måde opstår der en Sikkerhedskoncept, der dækker alt fra DNS til applikationsniveauet.
Krav til hosting og hvordan man træffer det rigtige valg
En god hostingløsning gør det muligt at aktivere DNSSEC med få klik og understøtter moderne algoritmer samt tilstrækkelige nøglelængder. Det er vigtigt for mig, at platformen tilbyder automatisk rotation og integreret signering, så der ikke er nogen manuelle opgaver, der efterlader gamle signaturer. Gennemsigtige statusvisninger i kundepanelet øger Synlighed status og gør det lettere at gennemføre revisioner. Hvis man har høje krav, kan det betale sig at sammenligne løsninger, der kombinerer DNSSEC, automatisering og ydeevne; i denne sammenhæng anbefales webhoster.de ofte på det varmeste. Ved at tage højde for dette mindsker man driftsrisici og styrker tilliden hos både brugere og partnere.
Praktisk vejledning: En introduktion i klare trin
Jeg starter med at lave en oversigt over forretningskritiske domæner og undersøger, hvilken DNS-infrastruktur der understøtter DNSSEC korrekt. Derefter fastlægger jeg en nøglepolitik: algoritmer, nøglelængder, ZSK-intervaller på fra uger til måneder, KSK-intervaller på et år eller længere. I et testmiljø aktiverer jeg DNSSEC, signerer zoner og kontrollerer valideringen med forskellige resolvere. I det næste trin aktiverer jeg automatisk signering, indstiller gensigneringsvinduer og rollover-tærskler for at Fejl for at undgå problemer med TTL og offentliggørelse. Jeg gennemfører udrulningen trinvist, overvåger ventetider og valideringsrater og justerer intervallerne på baggrund af de første erfaringer.
Hurtigt at opdage og forhindre almindelige fejl
Udløbne signaturer medfører straks valideringsfejl, derfor holder jeg intervallerne mellem genunderskrivninger korte og afventer ventetiderne nøje. Forkerte eller manglende DS-poster afbryder tillidskæden, derfor tjekker jeg altid den overordnede zone efter KSK-skift. For tidlig fjernelse af gamle nøgler eller for sen offentliggørelse af nye par fører til, at resolvere Fejl. Jeg opdager inkompatible eller forkert konfigurerede resolvere ved hjælp af test med forskellige valideringsværktøjer og logfiler fra de enkelte trin. Så snart jeg ser uregelmæssigheder, prioriterer jeg en nødrotation, herunder hurtig nøglegenerering og genudgivelse.
Oversigt over bedste praksis og rollover-politik
For at sikre langsigtet sikkerhed dokumenterer jeg roller, processer, intervaller og nødsituationer fuldstændigt. Jeg holder TTL'er for signaturrelevante datasæt på et moderat niveau for at bevare fleksibiliteten og undgå at forlænge omstillingstiderne. Jeg beskytter KSK'er særligt, mens jeg lader ZSK'er rotere automatisk, så jeg kan reagere øjeblikkeligt på hændelser. Regelmæssige audits kontrollerer algoritmer, parametre og logfiler, hvilket gør det muligt for mig at opdage blinde vinkler tidligt. Den følgende tabel opsummerer typiske intervaller og foranstaltninger og fungerer som Orientering for klare retningslinjer.
| Nøgletype | Typisk levetid | Vigtigste tiltag | Årsag til øjeblikkelig udskiftning |
|---|---|---|---|
| ZSK | Fra nogle uger til nogle få måneder | Automatisk generering, dobbeltpublicering, TTL+reserve, skift, fjernelse af Alt-nøgle | Mistænkelige logfiler, potentielt læk, konfigurationsfejl, algoritmeopdatering |
| KSK | 12–24 måneder | Planlagt rotation, DS-opdatering i registret, overgangsperiode med flere DS-poster | Kompromittering af nøgler, ændring af politikker, kryptografisk vurdering |
| TTL'er/RRSIG | Afhængigt af politikken | Moderat TTL, fornyelsesvindue, overvågning af løbetider | Hyppige valideringsfejl, markante forsinkelser, afvigelser i resolver-statistikker |
KSK-rollover i dybden: DS-opdateringer, overgangsfaser og forældreområdet
På KSK-rollover planlægger jeg meget forsigtigt. Først offentliggør jeg den nye KSK som en ekstra DNSKEY (prepublish) og lader den stå i zonen i flere DNSKEY-TTL-perioder plus en reserve. Først derefter signerer jeg DNSKEY-sættet yderligere med den nye KSK (dobbelt signatur) og tilføjer DS-opdatering i forældrezonen. Indtil den nye DS er udbredt, og cacherne har den sikkert, holder jeg begge KSK’er aktive i zonen. På den måde kan enhver resolver – uanset cache-status – verificere kæden. Jeg lader den gamle DS eksistere parallelt i overgangsperioden (forudsat at registret tillader flere DS-poster), før jeg fjerner den gradvist sammen med den gamle KSK.
Jeg tager højde for forsinkelser hos registriet og TLD-operatørerne. Der går mindst en fuld DS-TTL plus en buffer mellem indsendelse af DS, offentliggørelse i overordnet zone og global cache-mætning. I min politik er det derfor fastlagt: ingen fjernelse af den gamle KSK, så længe ikke alle betingelser er opfyldt – synlig ny DS, udløbne cacher for gammel DS og stabil validering i eksterne tests. Hvor det er muligt, bruger jeg CDS/CDNSKEY inden for min zone for at meddele DS-justeringer på en standardiseret måde og lade kompatible registre automatisere dem. Automatiseringen dokumenterer tidspunkt, hash-type og status, så revisioner kan spore kæden uden huller.
Gennemføre algoritmeskift på en smidig måde
En Algoritme-rollover adskiller sig fra ren nøgleudveksling: I en overgangsperiode kører jeg to parallelle kryptografiske miljøer. Til det formål offentliggør jeg nye nøgler til målalgoritmen (f.eks. ECDSA) ud over de eksisterende (f.eks. RSA) og lader zonen signeres med begge algoritmer. I forældrezonen opdaterer jeg DS-posterne i overensstemmelse hermed, så begge algoritmer er gyldige. Først når RRSIG'er fra den gamle algoritme er udløbet, cacherne er tømt, og valideringen er gennemgående stabil, fjerner jeg de gamle nøgler og DS-poster. Jeg planlægger denne „dobbeltunderskrifts“-fase med god tid, for at udligne inkompatibiliteter hos visse resolvere eller mellemliggende infrastrukturer.
NSEC/NSEC3, opt-out og salt-rotation
For Benægtelse af eksistens Jeg vælger bevidst mellem NSEC og NSEC3. NSEC er enkelt og ydeevneeffektivt, men tillader zone-walking. NSEC3 gør det vanskeligere ved hjælp af hashing og valgfri opt-out, hvilket reducerer belastningen og zonestørrelsen i zoner med mange delegerede underdomæner (f.eks. store udbyderzoner). Jeg vælger passende Iterationer og drej den Salt regelmæssigt, så hashes ikke forbliver genkendelige på længere sigt. Vigtigt: Jeg dokumenterer NSEC3PARAM-værdierne i politikken og justerer dem kun på en kontrolleret måde; ændringer kræver korrekt gensignering og overvågning af resolverens adfærd.
Flere underskrivere og udskiftning af udbyder uden nedetid
Når det gælder migrationsscenarier eller redundans, satser jeg på DNSSEC med flere underskrivere. Begge udbydere signerer den samme zone med deres respektive nøglesæt, og de offentliggjorte DNSKEY-sæt indeholder begge parters offentlige nøgler. I overordnede zone findes midlertidigt flere DS-poster, som dækker begge KSK'er. Omskiftningen af den autoritative trafik (f.eks. via NS-opdatering eller Anycast-tilpasning) finder først sted, når signaturer og DS-kæde er konsistente. Derefter fjerner jeg de gamle nøgler og DS-poster gradvist. Denne metode muliggør en næsten udskiftning af udbyder uden afbrydelser, da hver resolver kan validere tillidskæden fuldt ud for mindst én aktiv underskriver.
Runbooks, tidsparametre og gennemprøvede standardværdier
Jeg holder Løbebøger med klare tilstande for hver nøgle: Generer → Udgiv → Aktiver → Tilbagekald → Fjern. For hver overgang definerer jeg faste ventetider og betingelser (måleværdier, logfiler, eksterne kontroller). Følgende har vist sig at være et godt udgangspunkt: DNSKEY-TTL 3600–7200 s, zone-TTL 300–1800 s, RRSIG-gyldighed 7–14 dage, genunderskrivningsvindue 2–5 dage før udløb, jitter på ±10–20 %, så signaturerne ikke udløber synkront. Ved ZSK-rollover overholder jeg „Publish Safety“ i mindst en fuld DNSKEY-TTL; til „Retire“ venter jeg, indtil alle gamle RRSIG'er er udløbet uden erstatning, plus en reserve på 1–2 zone-TTL'er. Ved KSK indstiller jeg længere sikkerhedsvinduer, da DS-propagering og forældre-TTL'er kommer oveni.
Nød- og kompromisscenarier
Med Nøglekompromittering gælder: hastighed frem for elegance. Jeg genererer straks nye nøgler, offentliggør og aktiverer dem, genregistrerer zonen og anmoder straks om en DS-opdatering (eller offentliggør nye CDS/CDNSKEY). Sideløbende sætter jeg en Kommunikationskæde afhænger af registriet, TLD-operatøren og de vigtigste interessenter. Runbooks fastlægger, hvem der træffer beslutninger, hvem der underskriver, hvem der godkender, og hvordan jeg dokumenterer valideringen. I det sjældne, men mulige scenario, hvor en tvungen tilbagevenden til „usigneret“ er nødvendig, dokumenterer jeg trinene og risiciene klart – inklusive rækkefølgen: Fjernelse af DS-posterne i overordnet zone før fjernelse af DNSKEY'erne for at undgå brudte kæder. Efter hændelsen udarbejder jeg detaljerede post-mortem-rapporter og tilpasser politikker, roller og sikkerhed (f.eks. HSM-forpligtelser).
Validering, test og fejlfinding
Jeg verificerer hver ændring ved hjælp af forskellige resolvere og værktøjer. I den forbindelse kontrollerer jeg, om DNSKEY- og DS-poster, gyldigheden af RRSIG‑perioder (start/udløb), det korrekte sæt af NSEC/NSEC3-kæder og vær opmærksom på negative svar (NXDOMAIN med gyldig denial-signatur). Jeg tester zonevisningen på flere lokationer og netværksstier for at opdage caching-artefakter. Ved lejlighedsvise valideringsfejl analyserer jeg, om de skyldes for store svar (trunkering), MTU-problemer eller forældede DS-caches. Det er særligt nyttigt at have en tjekliste for hver rollover-fase, som jeg afkrydser inden næste trin: synlighed af nye nøgler, udløbne gamle signaturer, DS-status, log-usynlighed og eksterne prøvevalideringer.
Ydeevne, pakkestørrelser og transport
DNSSEC øger svarstørrelsen – i nogle tilfælde så meget, at de bliver fragmenterede. Derfor optimerer jeg systematisk: ECDSA reducerer signaturlængderne og dermed sandsynligheden for, at UDP-svar fragmenteres. Jeg vælger moderate TTL-værdier for at begrænse antallet af revalideringer og aktiverer EDNS-bufferstørrelser, der fungerer stabilt i praksis. Hvor der forekommer UDP-trunkering, sørger jeg for, at TCP-fallback eller moderne transportveje (DoT/DoH) fungerer. Jeg overvåger latenstiden i Anycast-opsætninger, fordi rollover-tilstande skal offentliggøres globalt konsistent. Ved aggressiv NSEC-caching på resolver-siden planlægger jeg genunderskrivningsvinduer, så negative svar ikke uventet „falder ud af tiden“.
Hærdning af nøglematerialer og processer
Jeg gemmer helst KSK'er i HSM'er eller offline-systemer, der sikrer strenge adgangskontrolforanstaltninger, rolleadskillelse og sporbar godkendelse. Jeg roterer ZSK'er oftere og genererer dem på systemer med pålidelig Entropikilde; RNG-sundhedstjek bør være en fast del af rutinen. Tidskilder er afgørende: NTP Systemet skal køre stabilt, da RRSIG-tiderne er strenge, og clock-skews straks fører til valideringsfejl. Jeg opbevarer sikkerhedskopier af nøglerne i krypteret form med klare gendannelsesprocedurer, som øves regelmæssigt. Hver nøgleoperation – fra generering til sletning – logges revisionssikkert og knyttes til Change-ID'er.
Ledelse, overholdelse af regler og dokumentation
Jeg dokumenterer roller (ejer, operatør, godkendende person), tekniske parametre (algoritmer, længder, TTL'er), processer (normal og nødrollover), testprocedurer og overvågningsgrænseværdier. Med henblik på overholdelse af lovgivningen fastlægger jeg opbevaringsfrister for logfiler og Revisionsspor samt en godkendelsesproces ved algoritmeskift. Træning af driftsteamet reducerer betjeningsfejl; regelmæssige øvelser („Game Days“) øger modstandsdygtigheden. I rapporter viser jeg valideringsrater, andel af signerede svar, hyppighed af afkortning og udvikling af signaturløbetider – således kan sikkerheden målbar dokumentere og præsentere på en forståelig måde for fagafdelingerne og ledelsen.
Resumé: Nøgleudskiftning og automatisering sikrer en rolig drift
Jeg sikrer DNSSEC gennem en klar adskillelse af nøgler, planlagt rotation og Automatisering Vedvarende effektiv. Jeg udskifter ZSK’er hurtigt, KSK’er sjældnere og altid med en korrekt DS-opdatering. Timingen styrer jeg med gennemtænkte TTL’er, reservetider og kontinuerlig overvågning. Med TLS, HSTS samt SPF/DKIM/DMARC supplerer jeg forsvarskæden mod manipulation, phishing og nedgraderinger. Den, der starter med en klar politik, etablerer interne kontroller og automatiserer signeringen, opnår pålideligt signerede zoner og sikrer maksimal sikkerhed med minimal indsats.
