DNS är en osynlig men avgörande del av en svensk verksamhets digitala närvaro. När en webbläsare ska hitta företagets webbplats, när en kunds e-postserver ska hitta MX-poster eller när en API-klient ska ansluta till rätt host börjar flödet med ett DNS-svar. DNSSEC lägger till digital signering så att en validerande resolver kan upptäcka om svaret har manipulerats eller inte kan styrkas. Det är ett skydd för namnuppslag, inte ett generellt säkerhetsmärke för allt som ligger på domänen.
För .se-domäner är det särskilt viktigt att skilja på registrering, DNS-delegation och den egna zonen. En domän kan ha korrekta namnservrar men felaktiga DNSSEC-poster, eller en signerad zon utan en fungerande kedja till föräldrazonen. I båda fallen kan vissa användare se SERVFAIL medan andra fortfarande når tjänsten genom en icke-validerande resolver. Planera därför som en ändring med påverkan på tillgänglighet, inte som en enkel DNS-post.
Vad DNSSEC faktiskt verifierar
En signerad zon innehåller DNSKEY-poster och signaturer för resursposter. Föräldrazonen publicerar en DS-post som pekar på en nyckel i barnzonen. En validerande resolver följer kedjan från en betrodd rot, genom toppdomänen och vidare till .se-namnet. Om signaturen stämmer och svaren är giltiga kan resolvern använda dem. Om kedjan bryts eller signaturen är ogiltig ska den inte behandla resultatet som ett vanligt positivt svar.
Det betyder inte att DNSSEC stoppar en angripare som redan kontrollerar ditt registrar- eller DNS-konto. Angriparen kan försöka ändra både zon och DS, eller ta bort signering. Därför måste kontoskydd, flerfaktorsautentisering, separata roller och ändringsloggning finnas parallellt. DNSSEC minskar en specifik klass av manipulation, men den gör inte en felaktig A-post korrekt och den krypterar inte DNS-frågor på egen hand.
Börja med en tillgångs- och ägarkarta
Skriv ned vilka domäner som är verksamhetskritiska, vilka tjänster de stöder och vem som kan ändra registrar, namnservrar, DS och zonposter. Ta med huvuddomän, e-postdomän, API-domäner, inloggning, kundportaler och viktiga subdomäner. Markera om DNS hanteras av en intern driftgrupp, en byrå eller en leverantör. Ett DNSSEC-projekt utan tydlig ägare riskerar att lämna en DS-post kvar när en annan grupp byter namnservrar.
- Registrar och kontaktväg för att publicera eller ta bort DS.
- Auktoritativ DNS-operatör och den signerande komponenten.
- DNSSEC-policy, KSK/ZSK eller motsvarande nyckelroller.
- TTL-värden, schemalagd rotation och ansvar vid incident.
- Resolver- och övervakningskällor som kan validera från flera nät.
- Godkänd rollback, inklusive vem som får ta bort en felaktig DS-post.
Gör en nulägeskontroll innan du aktiverar något. Hämta delegation, NS, SOA, DNSKEY, DS och signaturer och spara resultatet med tidsstämpel. Kontrollera också om en gammal DS-post redan finns. En kvarlämnad DS-post är en vanlig orsak till att en osignerad eller ny zon blir otillgänglig för validerande resolvrar. Om flera team har arbetat med domänen, håll ett kort ägarmöte och godkänn en enda aktuell konfiguration.
Planera införandet i rätt ordning
Det säkraste införandet börjar med en stabil och korrekt DNS-zon. Rensa upp dubbla poster, felaktiga MX, gamla verifieringar och onödiga omdirigeringar innan signering. Sänk inte TTL i sista minuten utan att förstå hur det påverkar rollback. Kontrollera att alla aktuella resolvrar får samma namnservrar och att IPv6 inte pekar mot en gammal miljö. En signatur kan vara perfekt och ändå skydda fel svar.
Välj en metod som din DNS-operatör och registrar stöder och dokumentera vem som genererar nycklar, vem som publicerar DS och vem som övervakar validering. För ett viktigt företag är det klokt att först aktivera i en test- eller mindre kritisk domän om organisationen saknar erfarenhet. Testa sedan produktionsnamnet i ett avtalat ändringsfönster med bemanning från DNS, webb, e-post och helpdesk.
DS, DNSKEY och nyckelrotation
DS-posten är inte en kopia av den privata nyckeln. Den binder en identifierad DNSKEY till föräldrazonen genom ett digestvärde och algoritminformation. En enda felaktig siffra, fel algoritm eller fel key tag kan bryta valideringen. Kopiera därför inte värden manuellt mellan system utan använd leverantörens export och en oberoende kontroll. Verifiera den publicerade DS-posten efter ändringen, från auktoritativa svar och från en validerande resolver.
Rotation måste hantera överlappning. Den nya nyckeln behöver publiceras och vara observerbar innan gamla beroenden tas bort, enligt den valda operatörens dokumenterade procedur. Tidpunkter beror på TTL och cache, så en snabb radering kan göra att vissa resolvrar fortfarande begär en nyckel som inte längre finns. Lägg in ägare, datum, toleranser och kontrollpunkter i kalendern. En rotation som bara finns i en persons minne är en drift-risk.
Byte av DNS-operatör utan SERVFAIL
Vid ett byte behöver du avgöra om den nya operatören tar över signeringen, om zonen signeras på nytt eller om en extern nyckelhantering används. Förbered zonen hos den nya operatören och jämför alla poster med baslinjen. När den nya zonen är redo, kontrollera DNSKEY och dess DS-material. Byt sedan delegation enligt en tidsplan och håll den gamla miljön tillgänglig tills observationerna visar att svaren är stabila.
Rollback måste vara konkret. Bestäm om den går via återställning av NS, publicering av tidigare DS eller borttagning av DS när den nya signerade kedjan inte fungerar. Varje väg har cacheeffekter och kan ta olika lång tid. Notera vem som godkänner ett borttagande av DNSSEC och hur ni kommunicerar om vissa resolvrar får ett gammalt svar. Att direkt stänga av skyddet kan lösa ett akut avbrott men ska följas av en rotorsaksanalys och plan för återinförande.
Testa från användarens perspektiv
Kontrollera DNSSEC-status från minst två oberoende nät och använd både en validerande och en icke-validerande jämförelse där det är relevant. Kontrollera A, AAAA, MX, TXT och viktiga subdomäner, inte bara apex. En status som säger secure räcker inte om webbplatsens IPv6-adress leder fel eller om e-postens MX inte längre svarar. Kombinera protokollkontroll med ett riktigt webb- och e-posttest i ändringsfönstret.
- Dokumentera fungerande svar före ändringen.
- Publicera eller förbered nya nycklar enligt vald metod.
- Kontrollera DS och DNSKEY oberoende efter publicering.
- Testa signaturer och negativa svar för viktiga poster.
- Verifiera webb, e-post, API och IPv6 från flera nät.
- Följ SERVFAIL, latens och kundärenden under TTL-fönstret.
- Stäng ändringen först när rollback och ägarskap är uppdaterade.
Vanliga fel och hur de ska tolkas
SERVFAIL betyder inte alltid att DNSSEC är fel. Det kan bero på en saknad post, timeout mot auktoritativ server, trasig delegation eller ett annat DNS-problem. NXDOMAIN för ett namn som inte finns kan däremot vara korrekt om det är kryptografiskt validerat. En webbläsare som fungerar i ett nät bevisar inte att alla validerande resolvrar får samma svar. Spara diagnostik från den faktiska frågan och fråga vilken resolver som observerade resultatet.
En annan missuppfattning är att DNSSEC skyddar mot alla domänbedrägerier. Om någon lurar en användare via en liknande stavning, stjäl ett konto eller publicerar skadligt innehåll på en korrekt signerad adress löser DNSSEC inte problemet. Kombinera med registrarens säkerhet, domänbevakning, TLS-kontroller, e-postautentisering och tydlig incidentberedskap. Säkerhet är en kedja av kontroller med olika syften.
Gör skyddet begripligt för verksamheten
Beskriv för verksamhetsägaren vad DNSSEC skyddar och vad det inte skyddar. En enkel förklaring är att validerande resolvrar kan avvisa manipulerade DNS-svar, men att organisationen fortfarande måste skydda konton, innehåll, certifikat, e-post och kod. Koppla kontrollen till konkreta tjänster: en falsk DNS-adress kan påverka kundinloggning, betalningsflöden eller återställningslänkar. Då blir investeringen lättare att prioritera och testa.
Avsluta med en signerad ändringsrapport. Den bör innehålla före- och efterkonfiguration, DS- och DNSKEY-värden, tester, observerade TTL-fönster, ansvarig godkännare och planerat nästa rotationsdatum. Om något är okänt ska det stå som en öppen punkt. Ett pålitligt DNSSEC-arbete bygger på spårbarhet och övning, inte på att en kontrollpanel råkar visa grönt.
Gör gärna ett återtest från en ny plats efter normal cachetid. Jämför resultatet med baslinjen och kontrollera att e-post, webb, API och viktiga subdomäner fortfarande når avsedda tjänster. Om resultatet skiljer sig, återgå till den dokumenterade beslutsplanen och ändra inte flera variabler samtidigt. Då kan teamet se om felet ligger i delegation, zon, signering eller själva tjänsten.
Öva på en trasig kedja innan incidenten
Planera en skrivbordsövning där teamet får se en felaktig DS-post, en utgången signatur eller ett DNSKEY-svar som saknas. Övningen ska inte skapa en verklig störning i produktion. Använd en separat testdomän eller simulerade svar och låt deltagarna följa checklistan: vilken signal upptäcks, vem kontaktas, hur bekräftas felet och vilken rollback är godkänd? Efteråt uppdaterar ni kontaktvägar, behörigheter och tidsuppskattning.
Kontrollera även registrarens stöd för akut ändring. En DNS-operatör kan kunna rätta zonen direkt medan DS måste ändras genom ett annat konto eller en supportprocess. Dokumentera normal och akut väg, krav på autentisering samt vilka uppgifter som får lämnas i ett ärende. Ha inte privata nycklar eller hemliga återställningskoder i samma dokument som publik DNS-data. Separera känsligheter men se till att rätt personer vet var de finns.
För en svensk organisation kan DNSSEC vara ett bra tillfälle att förbättra hela domänstyrningen. Samla registrar, namnserver, DNSSEC-ägare, webbägare och e-postägare i samma förändringsplan. Lägg in en kontroll efter varje förvärv, namnserverbyte och större DNS-ändring. Om en domän inte längre stöder en viktig tjänst ska avveckling också ha en plan för DS, signering och dokumentation.
Följ upp med en enkel kontroll av negativa svar och underdomäner. Det räcker inte att apex är secure om en borttagen host fortfarande ger ett motsägelsefullt svar eller om en delegationspunkt är fel. Jämför både befintliga och avsiktligt saknade namn från en validerande resolver. Den kontrollen ger bättre förtroende för att kedjan fungerar som helhet.
Skriv dessutom ner vilken resolver och vilket nät som användes i varje test. Två svar med samma domän kan skilja sig därför att en cache ännu inte löpt ut. När teamet sparar resolver, frågetyp, svarskod och tidpunkt blir det lättare att avgöra om en avvikelse är lokal eller generell. Den informationen hjälper både drift och support att kommunicera korrekt vid en DNSSEC-störning.