{"id":19997,"date":"2026-06-14T11:47:58","date_gmt":"2026-06-14T09:47:58","guid":{"rendered":"https:\/\/webhosting.de\/dnssec-key-rotation-automatisierte-signierung-sichere-domains-cryptoguide\/"},"modified":"2026-06-14T11:47:58","modified_gmt":"2026-06-14T09:47:58","slug":"dnssec-noglerotation-automatiseret-signering-sikre-domaener-cryptoguide","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/dnssec-key-rotation-automatisierte-signierung-sichere-domains-cryptoguide\/","title":{"rendered":"DNSSEC-n\u00f8glerotation og automatisk signering for maksimal sikkerhed"},"content":{"rendered":"<p>Jeg viser, hvordan man udf\u00f8rer en korrekt rotation af <strong>DNSSEC-n\u00f8gle<\/strong> og automatiseret signering kan p\u00e5lideligt forhindre uautoriserede \u00e6ndringer, undg\u00e5 nedbrud og forenkle driften. Til dette form\u00e5l beskriver jeg klare procedurer for udskiftning af ZSK- og KSK-n\u00f8gler, tidsregler for TTL\/RRSIG og satser p\u00e5 automatisering, der genererer, roterer og dokumenterer n\u00f8glerne p\u00e5 en sikker m\u00e5de.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>De f\u00f8lgende hovedpunkter f\u00f8rer direkte ind i den praktiske anvendelse af sikker n\u00f8glerotation og signering.<\/p>\n<ul>\n  <li><strong>ZSK\/KSK<\/strong> skal skilles tydeligt ad og roteres gradvist<\/li>\n  <li><strong>Automatisering<\/strong> styrer signering og rollover med f\u00e5 fejl<\/li>\n  <li><strong>Timing<\/strong> Overhold n\u00f8je TTL og RRSIG<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> for l\u00f8betider, DS og validering<\/li>\n  <li><strong>Politik<\/strong> til intervaller, n\u00f8dsituationer og revisioner<\/li>\n<\/ul>\n\n<h2>DNSSEC kort forklaret: Signaturer og tillidsk\u00e6de<\/h2>\n<p>DNSSEC supplerer navneopl\u00f8sningen med kryptografiske signaturer, s\u00e5 resolverne kan kontrollere svarens \u00e6gthed og <strong>Integritet<\/strong> kan kontrolleres. En privat n\u00f8gle signerer zonedata, mens den offentlige n\u00f8gle findes som en DNSKEY i DNS og danner grundlaget for valideringen. Tillidsk\u00e6den forbinder rodzonen, topdom\u00e6net og den egne zone via DS-posten, hvorved hvert trin validerer det n\u00e6ste <strong>godkendt<\/strong>. P\u00e5 den m\u00e5de blokerer jeg cache-poisoning og man-in-the-middle-angreb allerede p\u00e5 DNS-niveau. Uden korrekt n\u00f8glevedligeholdelse mister dette beskyttelseslag sin virkning, og derfor l\u00e6gger jeg stor v\u00e6gt p\u00e5 n\u00f8gleudskiftning, timing og automatisering.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dnssec-key-rotation-8452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5lrettet anvendelse af ZSK og KSK<\/h2>\n<p>Jeg bruger <strong>ZSK<\/strong> til signering af ressourceposterne, og v\u00e6lg derfor kortere opdateringsintervaller. Den <strong>KSK<\/strong> underskriver DNSKEY-posten og forbinder zonen med det overordnede DS-niveau, og derfor planl\u00e6gger jeg kun sj\u00e6ldent at skifte den og g\u00f8r det med s\u00e6rlig omhu. Jeg adskiller disse roller strengt for at muligg\u00f8re den operationelle rotation af ZSK uden konstante \u00e6ndringer i registret. Hvis du vil forst\u00e5 tillidsk\u00e6den bedre, kan du g\u00e5 videre til denne praktiske oversigt over <a href=\"https:\/\/webhosting.de\/da\/dnssec-hosting-sikkerhedsimplementering-trustchain\/\">DNSSEC-tillidsk\u00e6de<\/a> . P\u00e5 den m\u00e5de holder jeg signaturerne fleksible, sikrer forankringen til TLD\u2019en og bevarer kontrollen over begge n\u00f8gletyper.<\/p>\n\n<h2>Sikker gennemf\u00f8relse af DNSSEC-n\u00f8glerotation<\/h2>\n<p>For at skifte ZSK genererer jeg f\u00f8rst en ny n\u00f8gle med tilstr\u00e6kkelig <strong>N\u00f8glel\u00e6ngde<\/strong> og offentligg\u00f8r den som DNSKEY ud over den gamle. Derefter underskriver jeg zonen p\u00e5 ny, men lader den gamle ZSK fortsat underskrive, indtil de nye n\u00f8gler er synlige overalt. Jeg overholder TTL'erne for DNSKEY og RRSIG og venter, indtil resolverne har den nye n\u00f8gle sikkert gemt. Derefter s\u00e6tter jeg den aktive signatur til den nye <strong>ZSK<\/strong> og lader gamle signaturer udl\u00f8be efter planen. F\u00f8rst efter at have opbygget en sikkerhedsreserve fjerner jeg den tidligere n\u00f8gle for at undg\u00e5 valideringsfejl som f\u00f8lge af for tidlig sletning.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/TechnologieBesprechung1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automatisk signering i praksis<\/h2>\n<p>Jeg satser p\u00e5 automatisk signering, s\u00e5 navneserveren administrerer n\u00f8glerne internt, genererer nye n\u00f8glepar og styrer rollover-faser pr\u00e6cist. Her bruger softwaren fastlagte retningslinjer for intervaller, gensigneringsvinduer og reservetider, hvilket g\u00f8r det muligt for mig at undg\u00e5 timingfejl. On-the-fly-signering eller periodisk gensignering forhindrer udl\u00f8bne RRSIG'er og holder <strong>Zone<\/strong> altid gyldige. Via de integrerede logfiler kan jeg straks se, hvorn\u00e5r n\u00f8gler genereres, aktiveres og deaktiveres. Hvis man \u00f8nsker at dykke dybere ned i de konkrete indstillinger og styringen, finder man her en grundig introduktion til <a href=\"https:\/\/webhosting.de\/da\/dnssec-signering-noglehandtering-domaenesikkerhed-rotationssikkerhed\/\">automatisk underskrivning<\/a>.<\/p>\n\n<h2>Overv\u00e5gning, logning og revision<\/h2>\n<p>Uden overv\u00e5gning mister enhver automatisering sin <strong>Effekt<\/strong>. Jeg overv\u00e5ger RRSIG-gyldighedsperioder, udgivelsesvinduet for nye DNSKEY\u2019er og tilg\u00e6ngeligheden af DS-poster hos registriet. Et godt t\u00e6rskelkoncept minimerer falske alarmer, men jeg reagerer straks p\u00e5 forkortede signaturgyldighedsperioder, valideringsfejl eller uoverensstemmelser i Chain of Trust. Fra logfiler udleder jeg tidsperioder, hvor signaturer er blevet fornyet, og kan s\u00e5ledes spore h\u00e6ndelser pr\u00e6cist. Planlagte audits kontrollerer algoritmer, n\u00f8glel\u00e6ngder og politikker for at sikre <strong>Sikkerhed<\/strong> p\u00e5 lang sigt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dnssec-key-security-automation-8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TTL'er, RRSIG'er og typiske timing-f\u00e6lder<\/h2>\n<p>Rotation afh\u00e6nger af god timing, og derfor v\u00e6lger jeg TTL-v\u00e6rdier for DNSKEY- og RRSIG-poster med omhu. For h\u00f8je TTL'er forl\u00e6nger overgangsfaser, for lave v\u00e6rdier \u00f8ger belastningen og kan skabe valideringshuller, hvis signaturer udl\u00f8ber for tidligt. N\u00e5r jeg offentligg\u00f8r b\u00e5de den nye og den gamle n\u00f8gle, venter jeg mindst en hel <strong>TTL<\/strong> plus en reserve, f\u00f8r jeg skifter den aktive signaturn\u00f8gle. Efter skiftet lader jeg naturligvis de gamle signaturer udl\u00f8be, f\u00f8r jeg sletter de gamle n\u00f8gler. Hvis man ikke overholder denne r\u00e6kkef\u00f8lge, skaber man huller i tillidsk\u00e6den og risikerer foresp\u00f8rgsler, der ikke kan besvares.<\/p>\n\n<h2>V\u00e6lg kryptoalgoritmer og n\u00f8glel\u00e6ngder med omhu<\/h2>\n<p>Jeg v\u00e6lger algoritmer ud fra de aktuelle anbefalinger og tager h\u00f8jde for ydeevne, signaturl\u00e6ngde og klientkompatibilitet. RSA 2048 anses for at v\u00e6re praktisk anvendelig i mange ops\u00e6tninger, men ECDSA reducerer signaturst\u00f8rrelsen og forbedrer responstiderne. For ZSK\u2019er planl\u00e6gger jeg kortere levetider og satser p\u00e5 p\u00e5lidelige <strong>Generatorer<\/strong> med god entropi. Jeg beskytter KSK\u2019er s\u00e6rligt omhyggeligt, opbevarer dem om muligt i HSM\u2019er eller strengt kontrollerede milj\u00f8er og implementerer \u00e6ndringer korrekt via DS-opdateringer. En regelm\u00e6ssig gennemgang af algoritmer sikrer, at jeg skifter til nye metoder i tide, n\u00e5r de gamle bliver for\u00e6ldede.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dnssec_safe_tech_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>At t\u00e6nke DNSSEC, TLS og e-mail-godkendelse i et samlet perspektiv<\/h2>\n<p>DNSSEC beskytter navneopl\u00f8sningen, mens TLS sikrer transmissionsforbindelsen, og certifikatstyring forhindrer nedgraderinger. Til e-mail satser jeg p\u00e5 SPF, DKIM og DMARC, s\u00e5 forfalskninger har f\u00e6rre muligheder. Jeg planl\u00e6gger disse komponenter samlet, s\u00e5 angribere ikke kan komme forbi et svagt punkt. Hvis du vil komme i gang med det samme, kan du f\u00f8lge denne korte vejledning til <a href=\"https:\/\/webhosting.de\/da\/dnssec-aktiverer-domaener-beskyttelse-guide-tillid\/\">Aktiv\u00e9r DNSSEC<\/a> og tilf\u00f8jer senere HSTS og rene certifikatcyklusser. P\u00e5 den m\u00e5de opst\u00e5r der en <strong>Sikkerhedskoncept<\/strong>, der d\u00e6kker alt fra DNS til applikationsniveauet.<\/p>\n\n<h2>Krav til hosting og hvordan man tr\u00e6ffer det rigtige valg<\/h2>\n<p>En god hostingl\u00f8sning g\u00f8r det muligt at aktivere DNSSEC med f\u00e5 klik og underst\u00f8tter moderne algoritmer samt tilstr\u00e6kkelige n\u00f8glel\u00e6ngder. Det er vigtigt for mig, at platformen tilbyder automatisk rotation og integreret signering, s\u00e5 der ikke er nogen manuelle opgaver, der efterlader gamle signaturer. Gennemsigtige statusvisninger i kundepanelet \u00f8ger <strong>Synlighed<\/strong> status og g\u00f8r det lettere at gennemf\u00f8re revisioner. Hvis man har h\u00f8je krav, kan det betale sig at sammenligne l\u00f8sninger, der kombinerer DNSSEC, automatisering og ydeevne; i denne sammenh\u00e6ng anbefales webhoster.de ofte p\u00e5 det varmeste. Ved at tage h\u00f8jde for dette mindsker man driftsrisici og styrker tilliden hos b\u00e5de brugere og partnere.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dev_desk_DNSSEC_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk vejledning: En introduktion i klare trin<\/h2>\n<p>Jeg starter med at lave en oversigt over forretningskritiske dom\u00e6ner og unders\u00f8ger, hvilken DNS-infrastruktur der underst\u00f8tter DNSSEC korrekt. Derefter fastl\u00e6gger jeg en n\u00f8glepolitik: algoritmer, n\u00f8glel\u00e6ngder, ZSK-intervaller p\u00e5 fra uger til m\u00e5neder, KSK-intervaller p\u00e5 et \u00e5r eller l\u00e6ngere. I et testmilj\u00f8 aktiverer jeg DNSSEC, signerer zoner og kontrollerer valideringen med forskellige resolvere. I det n\u00e6ste trin aktiverer jeg automatisk signering, indstiller gensigneringsvinduer og rollover-t\u00e6rskler for at <strong>Fejl<\/strong> for at undg\u00e5 problemer med TTL og offentligg\u00f8relse. Jeg gennemf\u00f8rer udrulningen trinvist, overv\u00e5ger ventetider og valideringsrater og justerer intervallerne p\u00e5 baggrund af de f\u00f8rste erfaringer.<\/p>\n\n<h2>Hurtigt at opdage og forhindre almindelige fejl<\/h2>\n<p>Udl\u00f8bne signaturer medf\u00f8rer straks valideringsfejl, derfor holder jeg intervallerne mellem genunderskrivninger korte og afventer ventetiderne n\u00f8je. Forkerte eller manglende DS-poster afbryder tillidsk\u00e6den, derfor tjekker jeg altid den overordnede zone efter KSK-skift. For tidlig fjernelse af gamle n\u00f8gler eller for sen offentligg\u00f8relse af nye par f\u00f8rer til, at resolvere <strong>Fejl<\/strong>. Jeg opdager inkompatible eller forkert konfigurerede resolvere ved hj\u00e6lp af test med forskellige valideringsv\u00e6rkt\u00f8jer og logfiler fra de enkelte trin. S\u00e5 snart jeg ser uregelm\u00e6ssigheder, prioriterer jeg en n\u00f8drotation, herunder hurtig n\u00f8glegenerering og genudgivelse.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dnssec-sicherheit-serverraum-4876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Oversigt over bedste praksis og rollover-politik<\/h2>\n<p>For at sikre langsigtet sikkerhed dokumenterer jeg roller, processer, intervaller og n\u00f8dsituationer fuldst\u00e6ndigt. Jeg holder TTL'er for signaturrelevante datas\u00e6t p\u00e5 et moderat niveau for at bevare fleksibiliteten og undg\u00e5 at forl\u00e6nge omstillingstiderne. Jeg beskytter KSK'er s\u00e6rligt, mens jeg lader ZSK'er rotere automatisk, s\u00e5 jeg kan reagere \u00f8jeblikkeligt p\u00e5 h\u00e6ndelser. Regelm\u00e6ssige audits kontrollerer algoritmer, parametre og logfiler, hvilket g\u00f8r det muligt for mig at opdage blinde vinkler tidligt. Den f\u00f8lgende tabel opsummerer typiske intervaller og foranstaltninger og fungerer som <strong>Orientering<\/strong> for klare retningslinjer.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>N\u00f8gletype<\/th>\n      <th>Typisk levetid<\/th>\n      <th>Vigtigste tiltag<\/th>\n      <th>\u00c5rsag til \u00f8jeblikkelig udskiftning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ZSK<\/td>\n      <td>Fra nogle uger til nogle f\u00e5 m\u00e5neder<\/td>\n      <td>Automatisk generering, dobbeltpublicering, TTL+reserve, skift, fjernelse af Alt-n\u00f8gle<\/td>\n      <td>Mist\u00e6nkelige logfiler, potentielt l\u00e6k, konfigurationsfejl, algoritmeopdatering<\/td>\n    <\/tr>\n    <tr>\n      <td>KSK<\/td>\n      <td>12\u201324 m\u00e5neder<\/td>\n      <td>Planlagt rotation, DS-opdatering i registret, overgangsperiode med flere DS-poster<\/td>\n      <td>Kompromittering af n\u00f8gler, \u00e6ndring af politikker, kryptografisk vurdering<\/td>\n    <\/tr>\n    <tr>\n      <td>TTL'er\/RRSIG<\/td>\n      <td>Afh\u00e6ngigt af politikken<\/td>\n      <td>Moderat TTL, fornyelsesvindue, overv\u00e5gning af l\u00f8betider<\/td>\n      <td>Hyppige valideringsfejl, markante forsinkelser, afvigelser i resolver-statistikker<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>KSK-rollover i dybden: DS-opdateringer, overgangsfaser og for\u00e6ldreomr\u00e5det<\/h2>\n<p>P\u00e5 <strong>KSK-rollover<\/strong> planl\u00e6gger jeg meget forsigtigt. F\u00f8rst offentligg\u00f8r jeg den nye KSK som en ekstra DNSKEY (prepublish) og lader den st\u00e5 i zonen i flere DNSKEY-TTL-perioder plus en reserve. F\u00f8rst derefter signerer jeg DNSKEY-s\u00e6ttet yderligere med den nye KSK (dobbelt signatur) og tilf\u00f8jer <strong>DS-opdatering<\/strong> i for\u00e6ldrezonen. Indtil den nye DS er udbredt, og cacherne har den sikkert, holder jeg begge KSK\u2019er aktive i zonen. P\u00e5 den m\u00e5de kan enhver resolver \u2013 uanset cache-status \u2013 verificere k\u00e6den. Jeg lader den gamle DS eksistere parallelt i overgangsperioden (forudsat at registret tillader flere DS-poster), f\u00f8r jeg fjerner den gradvist sammen med den gamle KSK.<\/p>\n<p>Jeg tager h\u00f8jde for forsinkelser hos registriet og TLD-operat\u00f8rerne. Der g\u00e5r mindst en fuld DS-TTL plus en buffer mellem indsendelse af DS, offentligg\u00f8relse i overordnet zone og global cache-m\u00e6tning. I min politik er det derfor fastlagt: ingen fjernelse af den gamle KSK, s\u00e5 l\u00e6nge ikke alle betingelser er opfyldt \u2013 synlig ny DS, udl\u00f8bne cacher for gammel DS og stabil validering i eksterne tests. Hvor det er muligt, bruger jeg <strong>CDS\/CDNSKEY<\/strong> inden for min zone for at meddele DS-justeringer p\u00e5 en standardiseret m\u00e5de og lade kompatible registre automatisere dem. Automatiseringen dokumenterer tidspunkt, hash-type og status, s\u00e5 revisioner kan spore k\u00e6den uden huller.<\/p>\n\n<h2>Gennemf\u00f8re algoritmeskift p\u00e5 en smidig m\u00e5de<\/h2>\n<p>En <strong>Algoritme-rollover<\/strong> adskiller sig fra ren n\u00f8gleudveksling: I en overgangsperiode k\u00f8rer jeg to parallelle kryptografiske milj\u00f8er. Til det form\u00e5l offentligg\u00f8r jeg nye n\u00f8gler til m\u00e5lalgoritmen (f.eks. ECDSA) ud over de eksisterende (f.eks. RSA) og lader zonen signeres med begge algoritmer. I for\u00e6ldrezonen opdaterer jeg DS-posterne i overensstemmelse hermed, s\u00e5 begge algoritmer er gyldige. F\u00f8rst n\u00e5r RRSIG'er fra den gamle algoritme er udl\u00f8bet, cacherne er t\u00f8mt, og valideringen er gennemg\u00e5ende stabil, fjerner jeg de gamle n\u00f8gler og DS-poster. Jeg planl\u00e6gger denne \u201edobbeltunderskrifts\u201c-fase med god tid, for at udligne inkompatibiliteter hos visse resolvere eller mellemliggende infrastrukturer.<\/p>\n\n<h2>NSEC\/NSEC3, opt-out og salt-rotation<\/h2>\n<p>For <strong>Ben\u00e6gtelse af eksistens<\/strong> Jeg v\u00e6lger bevidst mellem NSEC og NSEC3. NSEC er enkelt og ydeevneeffektivt, men tillader zone-walking. NSEC3 g\u00f8r det vanskeligere ved hj\u00e6lp af hashing og valgfri opt-out, hvilket reducerer belastningen og zonest\u00f8rrelsen i zoner med mange delegerede underdom\u00e6ner (f.eks. store udbyderzoner). Jeg v\u00e6lger passende <strong>Iterationer<\/strong> og drej den <strong>Salt<\/strong> regelm\u00e6ssigt, s\u00e5 hashes ikke forbliver genkendelige p\u00e5 l\u00e6ngere sigt. Vigtigt: Jeg dokumenterer NSEC3PARAM-v\u00e6rdierne i politikken og justerer dem kun p\u00e5 en kontrolleret m\u00e5de; \u00e6ndringer kr\u00e6ver korrekt gensignering og overv\u00e5gning af resolverens adf\u00e6rd.<\/p>\n\n<h2>Flere underskrivere og udskiftning af udbyder uden nedetid<\/h2>\n<p>N\u00e5r det g\u00e6lder migrationsscenarier eller redundans, satser jeg p\u00e5 <strong>DNSSEC med flere underskrivere<\/strong>. Begge udbydere signerer den samme zone med deres respektive n\u00f8gles\u00e6t, og de offentliggjorte DNSKEY-s\u00e6t indeholder begge parters offentlige n\u00f8gler. I overordnede zone findes midlertidigt <strong>flere DS-poster<\/strong>, som d\u00e6kker begge KSK'er. Omskiftningen af den autoritative trafik (f.eks. via NS-opdatering eller Anycast-tilpasning) finder f\u00f8rst sted, n\u00e5r signaturer og DS-k\u00e6de er konsistente. Derefter fjerner jeg de gamle n\u00f8gler og DS-poster gradvist. Denne metode muligg\u00f8r en n\u00e6sten <strong>udskiftning af udbyder uden afbrydelser<\/strong>, da hver resolver kan validere tillidsk\u00e6den fuldt ud for mindst \u00e9n aktiv underskriver.<\/p>\n\n<h2>Runbooks, tidsparametre og gennempr\u00f8vede standardv\u00e6rdier<\/h2>\n<p>Jeg holder <strong>L\u00f8beb\u00f8ger<\/strong> med klare tilstande for hver n\u00f8gle: Generer \u2192 Udgiv \u2192 Aktiver \u2192 Tilbagekald \u2192 Fjern. For hver overgang definerer jeg faste ventetider og betingelser (m\u00e5lev\u00e6rdier, logfiler, eksterne kontroller). F\u00f8lgende har vist sig at v\u00e6re et godt udgangspunkt: DNSKEY-TTL 3600\u20137200 s, zone-TTL 300\u20131800 s, RRSIG-gyldighed 7\u201314 dage, genunderskrivningsvindue 2\u20135 dage f\u00f8r udl\u00f8b, jitter p\u00e5 \u00b110\u201320 %, s\u00e5 signaturerne ikke udl\u00f8ber synkront. Ved ZSK-rollover overholder jeg \u201ePublish Safety\u201c i mindst en fuld DNSKEY-TTL; til \u201eRetire\u201c venter jeg, indtil alle gamle RRSIG'er er udl\u00f8bet uden erstatning, plus en reserve p\u00e5 1\u20132 zone-TTL'er. Ved KSK indstiller jeg l\u00e6ngere sikkerhedsvinduer, da DS-propagering og for\u00e6ldre-TTL'er kommer oveni.<\/p>\n\n<h2>N\u00f8d- og kompromisscenarier<\/h2>\n<p>Med <strong>N\u00f8glekompromittering<\/strong> g\u00e6lder: hastighed frem for elegance. Jeg genererer straks nye n\u00f8gler, offentligg\u00f8r og aktiverer dem, genregistrerer zonen og anmoder straks om en DS-opdatering (eller offentligg\u00f8r nye CDS\/CDNSKEY). Sidel\u00f8bende s\u00e6tter jeg en <strong>Kommunikationsk\u00e6de<\/strong> afh\u00e6nger af registriet, TLD-operat\u00f8ren og de vigtigste interessenter. Runbooks fastl\u00e6gger, hvem der tr\u00e6ffer beslutninger, hvem der underskriver, hvem der godkender, og hvordan jeg dokumenterer valideringen. I det sj\u00e6ldne, men mulige scenario, hvor en tvungen tilbagevenden til \u201eusigneret\u201c er n\u00f8dvendig, dokumenterer jeg trinene og risiciene klart \u2013 inklusive r\u00e6kkef\u00f8lgen: Fjernelse af DS-posterne i overordnet zone f\u00f8r fjernelse af DNSKEY'erne for at undg\u00e5 brudte k\u00e6der. Efter h\u00e6ndelsen udarbejder jeg detaljerede post-mortem-rapporter og tilpasser politikker, roller og sikkerhed (f.eks. HSM-forpligtelser).<\/p>\n\n<h2>Validering, test og fejlfinding<\/h2>\n<p>Jeg verificerer hver \u00e6ndring ved hj\u00e6lp af forskellige resolvere og v\u00e6rkt\u00f8jer. I den forbindelse kontrollerer jeg, om <strong>DNSKEY<\/strong>- og <strong>DS<\/strong>-poster, gyldigheden af <strong>RRSIG<\/strong>\u2011perioder (start\/udl\u00f8b), det korrekte s\u00e6t af <strong>NSEC\/NSEC3<\/strong>-k\u00e6der og v\u00e6r opm\u00e6rksom p\u00e5 negative svar (NXDOMAIN med gyldig denial-signatur). Jeg tester zonevisningen p\u00e5 flere lokationer og netv\u00e6rksstier for at opdage caching-artefakter. Ved lejlighedsvise valideringsfejl analyserer jeg, om de skyldes for store svar (trunkering), MTU-problemer eller for\u00e6ldede DS-caches. Det er s\u00e6rligt nyttigt at have en tjekliste for hver rollover-fase, som jeg afkrydser inden n\u00e6ste trin: synlighed af nye n\u00f8gler, udl\u00f8bne gamle signaturer, DS-status, log-usynlighed og eksterne pr\u00f8vevalideringer.<\/p>\n\n<h2>Ydeevne, pakkest\u00f8rrelser og transport<\/h2>\n<p>DNSSEC \u00f8ger svarst\u00f8rrelsen \u2013 i nogle tilf\u00e6lde s\u00e5 meget, at de bliver fragmenterede. Derfor optimerer jeg systematisk: <strong>ECDSA<\/strong> reducerer signaturl\u00e6ngderne og dermed sandsynligheden for, at UDP-svar fragmenteres. Jeg v\u00e6lger moderate TTL-v\u00e6rdier for at begr\u00e6nse antallet af revalideringer og aktiverer EDNS-bufferst\u00f8rrelser, der fungerer stabilt i praksis. Hvor der forekommer UDP-trunkering, s\u00f8rger jeg for, at TCP-fallback eller moderne transportveje (DoT\/DoH) fungerer. Jeg overv\u00e5ger latenstiden i Anycast-ops\u00e6tninger, fordi rollover-tilstande skal offentligg\u00f8res globalt konsistent. Ved aggressiv NSEC-caching p\u00e5 resolver-siden planl\u00e6gger jeg genunderskrivningsvinduer, s\u00e5 negative svar ikke uventet \u201efalder ud af tiden\u201c.<\/p>\n\n<h2>H\u00e6rdning af n\u00f8glematerialer og processer<\/h2>\n<p>Jeg gemmer helst KSK'er i <strong>HSM'er<\/strong> eller offline-systemer, der sikrer strenge adgangskontrolforanstaltninger, rolleadskillelse og sporbar godkendelse. Jeg roterer ZSK'er oftere og genererer dem p\u00e5 systemer med p\u00e5lidelig <strong>Entropikilde<\/strong>; RNG-sundhedstjek b\u00f8r v\u00e6re en fast del af rutinen. Tidskilder er afg\u00f8rende: <strong>NTP<\/strong> Systemet skal k\u00f8re stabilt, da RRSIG-tiderne er strenge, og clock-skews straks f\u00f8rer til valideringsfejl. Jeg opbevarer sikkerhedskopier af n\u00f8glerne i krypteret form med klare gendannelsesprocedurer, som \u00f8ves regelm\u00e6ssigt. Hver n\u00f8gleoperation \u2013 fra generering til sletning \u2013 logges revisionssikkert og knyttes til Change-ID'er.<\/p>\n\n<h2>Ledelse, overholdelse af regler og dokumentation<\/h2>\n<p>Jeg dokumenterer roller (ejer, operat\u00f8r, godkendende person), tekniske parametre (algoritmer, l\u00e6ngder, TTL'er), processer (normal og n\u00f8drollover), testprocedurer og overv\u00e5gningsgr\u00e6nsev\u00e6rdier. Med henblik p\u00e5 overholdelse af lovgivningen fastl\u00e6gger jeg opbevaringsfrister for logfiler og <strong>Revisionsspor<\/strong> samt en godkendelsesproces ved algoritmeskift. Tr\u00e6ning af driftsteamet reducerer betjeningsfejl; regelm\u00e6ssige \u00f8velser (\u201eGame Days\u201c) \u00f8ger modstandsdygtigheden. I rapporter viser jeg valideringsrater, andel af signerede svar, hyppighed af afkortning og udvikling af signaturl\u00f8betider \u2013 s\u00e5ledes kan sikkerheden <strong>m\u00e5lbar<\/strong> dokumentere og pr\u00e6sentere p\u00e5 en forst\u00e5elig m\u00e5de for fagafdelingerne og ledelsen.<\/p>\n\n<h2>Resum\u00e9: N\u00f8gleudskiftning og automatisering sikrer en rolig drift<\/h2>\n<p>Jeg sikrer DNSSEC gennem en klar adskillelse af n\u00f8gler, planlagt rotation og <strong>Automatisering<\/strong> Vedvarende effektiv. Jeg udskifter ZSK\u2019er hurtigt, KSK\u2019er sj\u00e6ldnere og altid med en korrekt DS-opdatering. Timingen styrer jeg med gennemt\u00e6nkte TTL\u2019er, reservetider og kontinuerlig overv\u00e5gning. Med TLS, HSTS samt SPF\/DKIM\/DMARC supplerer jeg forsvarsk\u00e6den mod manipulation, phishing og nedgraderinger. Den, der starter med en klar politik, etablerer interne kontroller og automatiserer signeringen, opn\u00e5r p\u00e5lideligt signerede zoner og sikrer maksimal sikkerhed med minimal indsats.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan DNSSEC-n\u00f8glerotation og automatisk signering fungerer sammen for at sikre dine dom\u00e6ner p\u00e5 lang sigt med fokus p\u00e5 n\u00f8gleordet DNSSEC-n\u00f8glerotation.<\/p>","protected":false},"author":1,"featured_media":19990,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-19997","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web_hosting"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"76","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"DNSSEC Key","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19990","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19997","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=19997"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19997\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19990"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19997"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19997"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19997"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}