DNS-styrning 2026: revisionsklara registrarkontroller

Klockan 07:42 en måndagsmorgon får informationssäkerhetschefen på ett snabbväxande fintech-bolag meddelandet ingen vill se. Kunderna kommer inte åt betalportalen, servicedesken är överbelastad, e-post fungerar inte och SOC har inte hittat någon skadlig kod, något brandväggsavbrott eller någon incident hos molnleverantören.

Grundorsaken är tystare och mer pinsam. Ett registrarkonto nåddes med hjälp av en gammal administrativ autentiseringsuppgift som delades av flera tidigare IT-medarbetare. Angriparen ändrade auktoritativa namnservrar, modifierade MX-poster, inaktiverade DNSSEC och omdirigerade trafiken tillräckligt länge för att samla in autentiseringsuppgifter och störa partner-API:er. Betalportalen komprometterades inte i traditionell mening. Det var företagets tillitsankare, domänen, som komprometterades.

Klockan 09:30 har den operativa krisen blivit en regelefterlevnadskris. Styrelsen frågar om registry lock var aktiverat. Juridikfunktionen frågar om personuppgifter exponerades. Dataskyddsombudet frågar om detta är en personuppgiftsincident enligt GDPR. Tillsynsmyndigheten vill veta om en kritisk eller viktig funktion påverkades. En kundrevisor begär ändringsärendet som godkände DNS-modifieringen.

Svaret är i alltför många organisationer ett kalkylblad, en delad brevlåda och en registrarkonsol som ingen har granskat på sex månader.

Styrning av DNS och domänregistrarer under 2026 är inte längre ett smalt infrastrukturämne. Det är en del av resiliens mot ransomware, skydd mot nätfiske, tillgänglighet i molntjänster, leverantörsriskhantering, incidentrespons, verksamhetskontinuitet och evidensbaserad regelefterlevnad. Om din domän kan kapas kan din SaaS-plattform försvinna. Om dina DNS-poster kan ändras utan godkännande kan din e-postsäkerhet, SSO, TLS-certifikat, API-slutpunkter och kundernas förtroende undergrävas på några minuter.

Varför DNS- och registrarstyrning hör hemma i ISMS

Ett domännamn är inte bara en varumärkestillgång. Det är en logisk tillgång, ett autentiseringsberoende, ett routningsberoende och ofta en leverantörshanterad tjänst. Det kopplar samman identitetsleverantörer, e-postautentisering, validering av TLS-certifikat, molnslutpunkter, kundportaler, API:er, CDN-tjänster, övervakningssonder och incidentkommunikation.

Clarysecs policy för tillgångshantering - SME policy för tillgångshantering - SME gör detta uttryckligt i sin omfattning:

Digitala behörigheter och tjänster: domännamn, digitala certifikat, API-nycklar, e-postkonton, molninloggningar

Från avsnittet “Omfattning”, policyklausul 2.2.4.

Samma policy kräver mer än att domännamnet listas:

Ägarskap, syfte, åtkomsträttigheter och tidsfrister för förnyelse ska dokumenteras.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.6.2.

För större organisationer omfattar Clarysecs policy för tillgångshantering policy för tillgångshantering även logiska tillgångar:

Logiska tillgångar: domännamn, licenser, användarkonton, konfigurationsbaslinjer

Från avsnittet “Omfattning”, policyklausul 2.2.5.

Det är utgångspunkten för styrningen. En DNS- och registrarförteckning ska dokumentera:

• Domännamn, register, registrar, DNS-driftleverantör och auktoritativa namnservrar
• Verksamhetsägare, teknisk ägare, säkerhetsägare och godkännare för nödlägen
• Syfte, såsom produktionsportal, API, e-post, SSO, marknadsföring, testmiljö eller defensiv registrering
• Kritikalitetsklassning och beroendekartläggning mot verksamhetstjänster
• DNSSEC-status, status för DS-poster, nyckelägarskap och process för nyckelrotation
• Status för registry lock och registrar lock
• MFA och modell för privilegierad åtkomst till konton hos registrar och DNS-leverantör
• Förnyelsedatum, status för automatisk förnyelse, betalningsansvarig och larmning om utgångsdatum
• Krav på ändringsstyrning för zonredigeringar och delegeringsändringar
• Loggning, larmning, övervakning och bevarande av underlag

Därför ska domänstyrning ingå i omfattning och riskbedömning för ISO/IEC 27001:2022 ISMS. ISO/IEC 27001:2022 kräver att organisationer fastställer kontext, krav från intressenter, rättsliga skyldigheter och avtalskrav samt gränssnitt och beroenden gentemot externa organisationer. DNS är beroende av registrarer, register, DNS-driftleverantörer, molnleverantörer, certifikatutfärdare, MSP:er och ibland marknadsföringsbyråer. Om dessa gränssnitt utesluts från ISMS blir revisionsspåret ofullständigt.

DNS-hotmodellen 2026

De mest skadliga DNS-felen är ofta enkla:

1. En domän löper ut eftersom ansvaret för förnyelse var otydligt.
2. En tidigare byrå har fortfarande åtkomst till ett registrarkonto.
3. DNSSEC är aktiverat, men DS-posterna är fel efter en migrering av DNS-leverantör.
4. En wildcard-post pekar trafik till en övergiven molntjänst.
5. En TXT-post ändras för att validera en angriparkontrollerad SaaS-tenant eller certifikatbegäran.
6. MX-poster ändras under en nätfiske- eller e-postavlyssningskampanj.
7. En CNAME-post till en tredjepartsplattform blir sårbar för övertagande.
8. Registry lock finns för den primära domänen, men inte för kundvända landskoddomäner.
9. SOC övervakar slutpunkter, men ingen övervakar ändringar i zonfiler.

De tekniska skyddsåtgärderna är välkända. DNSSEC bidrar till att skydda DNS-dataintegritet och ursprungsautentisering. Registry lock gör att högriskändringar på registernivå kräver ytterligare verifiering via separat kanal. Registrar lock minskar risken för obehörig överföring. MFA och granskningar av privilegierad åtkomst minskar sannolikheten för kontoövertagande. Ändringsstyrning förhindrar oavsiktliga störningar. Övervakning detekterar obehöriga eller oväntade ändringar.

Utmaningen för regelefterlevnaden är en annan: kan ni visa att dessa skyddsåtgärder finns, har ägare, granskas och fungerar under en incident?

Det är den bevisfrågan många organisationer faller på.

Mappning av DNS-styrning till ISO/IEC 27001:2022 och ISO/IEC 27002:2022

ISO/IEC 27001:2022 ger ledningssystemstrukturen för att omvandla DNS-kontroller till repeterbara och revisionsbara processer. ISO/IEC 27001:2022 bilaga A och kontrollvägledningen i ISO/IEC 27002:2022 ger det kontrollspråk revisorer förväntar sig.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandlar nätverkstjänster som uttryckliga revisionsobjekt. I fasen Kontroller i praktiken, steg 20, instrueras team att validera säkerheten i nätverkstjänster:

Lista alla interna och externa nätverkstjänster (DNS, VPN, SMTP, DHCP, API-gateways, osv.).

✓ Bekräfta för varje tjänst att säkra protokoll används (t.ex. DNSSEC, TLS 1.2+, SSH i stället för Telnet). ✓ Granska hur åtkomst till varje tjänst styrs (t.ex. tillåtelselistor för IP-adresser, autentisering, certifikat). ✓ Om tjänsten hanteras av tredje part (t.ex. DNS, SD-WAN, driftad VPN), granska säkerhetsklausulerna i SLA eller leverantörsavtal. Uppdatera ert tjänsteregister och notera var säkerhetsansvaret ligger, internt eller externt.

Från fasen Kontroller i praktiken, steg 20: kontroller 8.18 till 8.26.

Det ger en praktisk revisionsväg: behandla DNS som en extern nätverkstjänst, dokumentera hur den säkras och registrera om ansvaret ligger internt, hos en registrar, hos en DNS-leverantör eller hos en MSP.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls är användbar eftersom DNS-styrning sällan endast mappas mot ett ramverk. Samma beslut om DNSSEC eller registry lock stödjer underlag för ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.

För leverantörsövervakning mappar Zenith Controls ISO/IEC 27002:2022 kontroll 5.22, Övervakning, granskning och ändringshantering av leverantörstjänster, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. För DNS innebär det att er registrar och DNS-leverantör inte är leverantörer som kan lämnas utan löpande styrning. Deras säkerhetsläge, tjänsteförändringar, avbrott, underbiträden och aviseringsrutiner ska granskas.

För DNSSEC och kryptografisk integritet mappar Zenith Controls ISO/IEC 27002:2022 kontroll 8.24, Användning av kryptografi, som en förebyggande kontroll kopplad till säker konfiguration. DNSSEC är inte kryptering av DNS-trafik, men det ger kryptografisk säkerhet för DNS-dataintegritet och ursprungsautentisering.

För DNS-zonredigeringar mappar Zenith Controls ISO/IEC 27002:2022 kontroll 8.32, Ändringshantering, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. En DNS-ändring är en konfigurationsändring. En uppdatering av DS-post, ändring av MX-post, CNAME-migrering, SPF- eller DMARC-uppdatering, CDN-övergång eller ändring av namnserverdelegering ska ha ett ärende, en riskbedömning, ett godkännande, ett testresultat och en plan för återställning.

DNSSEC, registry lock och nyckelhantering för kritiska domäner

Alla domäner har inte samma risk. En defensiv domän som endast används för att förhindra efterbildning kan behöva övervakning och disciplin kring förnyelse. En primär kundportaldomän kräver de starkaste tillgängliga kontrollerna.

För kritiska domäner rekommenderar Clarysec normalt denna baslinje:

• DNSSEC aktiverat och validerat där det stöds av registret, registraren och DNS-leverantören
• DS-poster granskade efter varje migrering av DNS-leverantör
• Dokumenterad process för KSK- och ZSK-rotation när nycklarna hanteras av kunden
• Registry lock aktiverat för primära produktions-, identitets-, API-, betalnings- och e-postdomäner
• Registrar lock aktiverat för alla domäner om inte ett tidsbegränsat undantag är dokumenterat
• MFA framtvingat för alla användare hos registrar och DNS-leverantör
• Privilegierade användare begränsade, namngivna, godkända och granskade
• Nödåtkomst dokumenterad och testad
• Zonfilsövervakning med larm vid ändringar av NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA och wildcard-poster
• Extern övervakning från flera DNS-resolvers och regioner
• Underlag bevarat i ISMS-dokumentarkivet

Clarysecs Policy för kryptografiska kontroller Policy för kryptografiska kontroller för större organisationer ger styrningsankaret för DNSSEC-nycklar:

Ett centraliserat register för nyckelhantering ska upprätthållas för att registrera alla kryptografiska nycklar, deras livscykelstatus, tilldelade nyckelförvaltare och användningssammanhang.

Från avsnittet “Styrningskrav”, policyklausul 5.2.

Om er organisation hanterar DNSSEC-nycklar direkt, eller styr DS-publicering hos registraren, ska registret för nyckelhantering dokumentera nyckelförvaltarskap, livscykelstatus, rotationsdatum och godkännande instans. Om DNS-leverantören hanterar DNSSEC-nycklar ska leverantörsposten beskriva det ansvaret och innehålla underlag för säkerhetsförsäkran.

Styrning av registraråtkomst: MFA, principen om minsta privilegium och nödkontroll

Registrarkonton skapas ofta tidigt i ett företags livscykel och glöms sedan bort när företaget mognar. Grundare, byråer, utvecklare, ekonomipersonal och MSP:er kan alla ha historisk åtkomst. Det är en allvarlig kontrollbrist.

Clarysecs Policy för hantering av användarkonton och privilegier - SME Policy för hantering av användarkonton och privilegier - SME anger:

Förhöjda eller administrativa privilegier kräver ytterligare godkännande av den verkställande chefen eller IT-ansvarig och ska dokumenteras, vara tidsbegränsade och omfattas av periodisk granskning.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.2.2.

Tillämpa detta bokstavligt på åtkomst till registrarer och DNS-leverantörer:

• Inga delade administratörskonton hos registrar
• MFA för varje användare, helst med motståndskraft mot nätfiske där det stöds
• Namngivna nödkontakter med dokumenterad befogenhet
• Separering av faktureringsanvändare från tekniska administratörer där det är möjligt
• Omedelbar borttagning av tidigare anställda, byråer och leverantörer
• Kvartalsvis granskning av privilegierad åtkomst för kritiska domäner
• Undantag registrerade med utgångsdatum
• Testade rutiner för nödupplåsning och återställning som inte skapar osäkra produktionsändringar

Underlag för registry lock ska omfatta skärmdumpar eller intyg från registraren som visar aktiverad status, behöriga kontaktpersoner, upplåsningsprocess och senaste granskningsdatum.

Styrning av zonändringar: små DNS-redigeringar, stor verksamhetspåverkan

DNS-ändringar är förrädiskt små. En TXT-post kan validera ägarskap för en SaaS-plattform. En CNAME-post kan omdirigera kunder till en ny miljö. En MX-post kan leda om e-post. En CAA-post kan påverka certifikatutfärdande. En felaktig DS-post kan göra att en signerad domän inte klarar validering.

Clarysecs Ändringshanteringspolicy - SME Ändringshanteringspolicy - SME anger:

Alla ändringar ska lämnas in som en ändringsbegäran (e-post, formulär eller helpdeskärende).

Från avsnittet “Styrningskrav”, policyklausul 5.1.1.

För större organisationer höjer Clarysecs Ändringshanteringspolicy Ändringshanteringspolicy kravet på underlag:

Alla ändringsbegäranden, granskningar, godkännanden och stödjande underlag ska registreras i det centraliserade systemet för ändringshantering.

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1.

Zenith Blueprint förstärker detta i fasen Kontroller i praktiken, steg 21:

Välj 2–3 nyligen genomförda system- eller konfigurationsändringar och kontrollera om de behandlades via ert formella ändringshanteringsflöde.

✓ Bedömdes riskerna? ✓ Dokumenterades godkännandena? ✓ Ingick en plan för återställning?

Validera att ändringarna genomfördes enligt plan och att eventuella incidenter eller oväntade effekter registrerades. Granska loggar, differenser i versionshantering eller revisionsspår från verktyg som ServiceNow, Jira eller Git. Fånga processen i en sammanfattande logg över ändringsposter som revisionsreferens.

Från fasen Kontroller i praktiken, steg 21: kontroller 8.27 till 8.34.

Ett DNS-specifikt ändringsärende ska omfatta berörd domän och zon, posttyp, värden före och efter ändringen, verksamhetsmässig motivering, riskbedömning, genomförandefönster, godkännare, utförare, verifierare, kontroller av DNS-propagering, DNSSEC-validering, plan för återställning, övervakning efter ändringen och exporterade underlag.

Revisionsprincipen är enkel: DNS-ändringar ska vara spårbara från begäran till godkännande, genomförande och verifiering.

Övervakning och loggning: upptäck DNS-ändringen före kunderna

Ett starkt program för DNS-styrning utgår från att förebyggande kontroller kan fallera. Övervakning ska detektera oväntade ändringar tillräckligt snabbt för att stödja incidentrespons.

Clarysecs Nätverkssäkerhetspolicy - SME Nätverkssäkerhetspolicy - SME är tydlig:

DNS-loggning ska vara aktiverad för att stödja hotjakt och incidentrespons

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.6.3.

Clarysecs Loggnings- och övervakningspolicy Loggnings- och övervakningspolicy för större organisationer utgår från samma operativa förväntan:

Alla omfattade system ska generera loggar som fångar:

Från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1.

För styrning av DNS och registrarer ska omfattade system inkludera registrarportaler, DNS-driftkonsoler, API-baserad DNS-hantering, CI/CD-pipelines som driftsätter DNS som kod, SIEM-larm och externa övervakningsverktyg.

Övervakning ska integreras med incidentrespons. Ett DNS-larm utan ägare, allvarlighetsgrad eller återställningsanvisning är bara brus.

NIS2, DORA och GDPR: DNS-styrning som regulatoriskt underlag

NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem och minimera incidentpåverkan. DNS-styrning mappar naturligt mot tillgångshantering, åtkomstkontroll, kryptografi, säkerhet i leveranskedjan, incidenthantering, verksamhetskontinuitet och bedömning av effektivitet.

NIS2 Article 20 gör också cybersäkerhet till ett ansvar för ledningsorganet. Styrelser behöver inte godkänna varje TXT-post, men de ska förstå om kritiska domäner skyddas av DNSSEC, registry lock, MFA, övervakning och testad återställning. För betydande incidenter inför NIS2 Article 23 stegvis rapportering, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar och en slutrapport senast en månad efter incidentanmälan.

För reglerade finansiella entiteter gäller DORA från den 17 januari 2025 och fungerar som det sektorsspecifika ramverket för IKT-resiliens där det överlappar NIS2. DNS stödjer ofta kritiska eller viktiga funktioner såsom betalningsapplikationer, mobila banktjänster, handelsportaler, kundidentitet, bedrägerisystem, API-gateways och tredjepartsintegrationer. Underlag för DORA ska visa kartläggning av beroenden mellan IKT-tillgångar, incidentklassificering, resiliensprovning, hantering av tredjepartsrisker och återställningsplanering för scenarier där DNS eller registrar fallerar.

En DNS-incident är inte automatiskt en personuppgiftsincident enligt GDPR. Den kan bli det om användare omdirigeras till en nätfiskewebbplats, autentiseringsuppgifter samlas in, e-post som innehåller personuppgifter leds om, trafik till system som behandlar personuppgifter avlyssnas eller tillgängligheten till personuppgifter påverkas väsentligt. GDPR Article 5 kräver riktighet, konfidentialitet och ansvarsskyldighet. Article 32 kräver lämpliga säkerhetsåtgärder för behandlingen. DNS-styrning ger underlag för att domänroutning och DNS-beroende tjänster skyddas med proportionerliga tekniska och organisatoriska åtgärder.

Bygg ett DNS-underlagspaket på en vecka

En praktisk åtgärdsplan för DNS-styrning kan genomföras snabbt om den drivs av underlag.

Dag 1: Skapa domän- och DNS-tjänsteregistret

Utgå från kravet i policy för tillgångshantering - SME att dokumentera ägarskap, syfte, åtkomsträttigheter och tidsfrister för förnyelse.

Dag 2: Granska åtkomst och privilegier

Exportera användare hos registrar och DNS-leverantör. Ta bort inaktuella konton. Kräv MFA. Identifiera administratörer. Registrera godkännandeunderlag för privilegierade användare och dokumentera nödåtkomst.

Dag 3: Validera DNSSEC och låsning

Verifiera DNSSEC-kedjevalidering, korrekthet för DS-post, synlighet för DNSKEY, registrar lock och registry lock för varje kritisk domän. Om DNSSEC hanteras av leverantören ska leverantörens ansvar dokumenteras. Om det hanteras av kunden ska DNSSEC-nycklar och nyckelförvaltare läggas till i registret för nyckelhantering.

Dag 4: Omvandla DNS-ändringar till formella ändringsposter

Välj de tre senaste DNS-ändringarna och testa dem mot kriterierna i Zenith Blueprint steg 21: risk bedömd, godkännande dokumenterat, plan för återställning inkluderad, genomfört enligt plan och oväntad påverkan registrerad. Skapa en sammanfattande logg över ändringsposter.

Dag 5: Koppla övervakning till incidentrespons

Bekräfta loggar och larm för registrar-inloggning, zonändringar, DNSSEC-ändringar, NS-ändringar, MX-ändringar, TXT-ändringar, CAA-ändringar och leverantörsaviseringar. Skicka testlarm till SOC eller IT-ägare. Bifoga underlag till ISMS-dokumentarkivet.

Dag 6: Granska leverantörsskyldigheter

Använd vägledningen i Zenith Blueprint steg 23 för leverantörsändringar och övervakningsrutiner:

Etablera en enkel, skalbar rutin för att bedöma ändringar i leverantörstjänster (5.21), såsom migrering till molntjänst, nya underbiträden eller omdesign av infrastruktur. Definiera utlösare som kräver förnyad säkerhetsbedömning. Inför därefter en återkommande kadens för leverantörsövervakning (5.22), tilldela ägare till kritiska leverantörer och säkerställ att prestanda, efterlevnad och risker granskas minst årligen.

Från fasen Kontroller i praktiken, steg 23: organisatoriska kontroller 5.19 till 5.37.

Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet policy för leverantörssäkerhet och tredjepartssäkerhet för större organisationer ger det avtalsmässiga ankaret:

Avtal med leverantörer ska innehålla:

Från avsnittet “Styrningskrav”, policyklausul 5.3.

Dag 7: Genomför en skrivbordsövning

Simulera en obehörig ändring av NS-post. Teamet ska detektera den, klassificera den, eskalera den, kontakta registraren, aktivera rutiner för registry lock vid behov, återställa korrekt delegering, validera DNSSEC, underrätta intressenter, bedöma GDPR-påverkan och avgöra om rapporteringströsklar enligt NIS2 eller DORA är uppfyllda. Fånga erfarenhetsåterföring och uppdatera rutiner.

Revisionsfrågor, vanliga iakttagelser och styrelsemått

En revision av DNS-styrning genomförs sällan ur endast ett perspektiv.

De vanligaste iakttagelserna är förutsägbara.

Styrelser och ledningsgrupper behöver DNS-mätetal uttryckta i resiliensspråk. Användbara mått inkluderar andel kritiska domäner med DNSSEC aktiverat och validerat, andel med registry lock, antal registraradministratörer, andel privilegierade användare som granskats senaste kvartalet, antal DNS-ändringar som genomförts utan formella ärenden, genomsnittlig tid till detektering av obehörig DNS-ändring, genomsnittlig tid till återställning av korrekt DNS-konfiguration, domäner som löper ut inom 90 dagar, genomförda leverantörsgranskningar och olösta DNS-övervakningslarm.

Gör DNS från dold risk till revisionsklart underlag

Om er organisation inte har granskat domän- och DNS-styrning under de senaste sex månaderna ska ni utgå från att driftavvikelser har uppstått. Börja med kritiska produktionsdomäner och expandera sedan till regionala domäner, defensiva domäner, testdomäner, förvärvsdomäner och domäner som hanteras av byråer eller dotterbolag.

Clarysec kan hjälpa er att gå från spridda registrarskärmdumpar till ett strukturerat underlagspaket med hjälp av:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint för stegvis validering av nätverkstjänster, ändringshantering, loggning, övervakning och leverantörskontroller
• Zenith Controls: The Cross-Compliance Guide Zenith Controls för mappning av DNSSEC, registry lock, leverantörsövervakning och styrning av zonändringar över ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST och COBIT 2019-perspektiv
• Clarysecs policymallar, inklusive policy för tillgångshantering - SME, Ändringshanteringspolicy - SME, Policy för hantering av användarkonton och privilegier - SME, Nätverkssäkerhetspolicy - SME, policy för tillgångshantering, Ändringshanteringspolicy, Loggnings- och övervakningspolicy, Policy för kryptografiska kontroller och policy för leverantörssäkerhet och tredjepartssäkerhet

Din domän är huvudingången till din digitala verksamhet. Under 2026 kommer revisorer, tillsynsmyndigheter, kunder och styrelser att förvänta sig att du kan visa att huvudingången är låst, övervakad, återställningsbar och styrd.

Ladda ner Clarysecs verktygslåda, genomför övningen för ett DNS-underlagspaket på en vecka eller boka en Clarysec-bedömning för att omvandla DNS- och registrarstyrning till revisionsklart underlag innan din egen måndagsmorgonkris inträffar.