Defaults.Exposed › Åtgärder › DNSSEC
Hur du fixar DNSSEC
DNSSEC är ett digitalt sigill på din domäns adressbok. Det låter internet bevisa att svaret på 'var bor den här domänen?' verkligen kom från dig och inte manipulerades på vägen. Utan det kan svaret förfalskas — och dina besökare tyst skickas någon annanstans.
Slutsats för ditt företag: Utan DNSSEC kan en angripare som kan förgifta ett DNS-svar peka dina kunder mot en perfekt kopia av din webbplats medan deras webbläsare fortfarande visar ditt riktiga domännamn. Inloggningar, kortnummer och personuppgifter skördas, och du får reda på det först från chargebacks och klagomål. En halvfärdig DNSSEC-inställning är ännu värre: den kan göra din webbplats onåbar för en växande andel besökare utan något fel du någonsin skulle märka.
Vad detta kan kosta dig
- Besökare som skriver din riktiga domän omdirigeras tyst till en lookalike som fångar deras lösenord och kortuppgifter — och för att adressfältet visar din domän hela tiden misstänker ingen något förrän bedrägerirapporterna anländer.
- Din e-post omdirigeras tyst: en angripare förfalskar svaret för dina e-postservrar, läser eller avlyssnar meddelanden och återställer lösenord på konton som mejlar dig en kod — allt utan att röra din inkorg.
- En halvkonfigurerad DNSSEC-inställning (det offentliga sigillet finns men den matchande nyckeln saknas) gör att din webbplats och e-post slumpmässigt misslyckas för kunder på stora internetleverantörer och företagsnätverk — intermittenta 'din webbplats är nere för mig'-rapporter du inte kan reproducera.
- En potentiell kunds säkerhetsteam kör en kontroll före kontrakt, ser ingen DNSSEC och markerar dig som svag på grunderna — sätter en affär i risk för en gratis inställning.
- Offentlig sektor och större B2B-köpare förväntar sig i allt högre grad DNSSEC som baslinje (det nämns i förordningar som NIS2); dess frånvaro diskvalificerar dig tyst från upphandlingar innan en konversation ens börjat.
Varför det spelar roll. DNS är internets adressbok, och som standard färdas dess svar osignerade — vem som helst som kan smyga in ett förfalskat svar kan skicka dina kunder och din e-post vart som helst de vill, med ditt riktiga domännamn fortfarande visas i webbläsaren. DNSSEC sätter ett manipuleringssäkert sigill på dessa svar så att de kan verifieras som genuint dina. Åtgärden är gratis hos de flesta leverantörer; den enda verkliga kostnaden är att göra det fel, vilket är varför vi går igenom båda halvorna noga.
DNSSEC, i klartext
Varje gång någon besöker din webbplats eller skickar dig ett mejl måste deras dator först ställa en enkel fråga till internet: “var bor den här domänen egentligen?” Svaret — uppsättningen adresser för din webbplats och dina e-postservrar — kommer tillbaka från DNS, internets adressbok.
Här är den obehagliga delen: som standard färdas dessa svar osignerade. Det finns inget bifogat för att bevisa att svaret är genuint. Om någon kan smyga in ett förfalskat svar i den konversationen — och det finns välkända, beprövade sätt att göra exakt det — kommer besökarens dator glatt att acceptera det. Från det ögonblicket kan besökaren prata med en angripares server medan deras webbläsare fortfarande visar ditt domännamn i adressfältet.
DNSSEC är åtgärden. Det lägger till ett manipuleringssäkert digitalt sigill på dina DNS-svar. När DNSSEC är påslaget kan internet matematiskt verifiera att ett svar verkligen kom från dig och inte förändrades på vägen. Ett förfalskat svar underkänns och kastas bort. Det är skillnaden mellan en adressbok som vem som helst kan klottra i och en där varje post är signerad och bevittnad.
Den här sidan täcker de två delar vår kontroll tittar på tillsammans: om sigillet är publicerat (DS-posten) och om den matchande nyckeln bakom det faktiskt finns (DNSKEY-posten). Du ser snart varför båda spelar roll — för att ha en utan den andra är sin egna sort av problem.
Vad det här kan kosta dig
Det här är realistiska, aggregerade mönster — inte ett enstaka namngivet företag.
- Den osynliga omdirigeringen. En angripare förgiftar DNS-svaret för din domän. Kunder skriver din riktiga webbadress, ser din riktiga domän i fältet och hamnar på en felfri kopia av din inloggnings- eller kassasida hostad av angriparen. Varje lösenord och kortnummer de anger går rakt till kriminellen. Du hör om det först när chargebacks och “jag hackades via din webbplats”-samtal börjar — och spåret leder tillbaka till ditt varumärke, inte angriparens.
- Tyst e-postavlyssning. DNS pekar inte bara på din webbplats; det pekar på dina e-postservrar. Förfalska det svaret och inkommande e-post kan omdirigeras via en angripare först. De läser känsliga meddelanden, skördar engångskoderna som tjänster mejlar för att “verifiera att det är du” och återställer lösenord på konton kopplade till din domän — allt utan att någonsin logga in på din inkorg.
- Avbrottet du inte kan reproducera. Det här kommer från en halvfärdig DNSSEC-inställning. Det offentliga sigillet (DS) sitter hos din registrar, men den matchande nyckeln (DNSKEY) saknas eller är fel. Besökare på internetleverantörer och företagsnätverk som kontrollerar DNSSEC — och det finns fler för varje år — kan helt enkelt inte lösa upp din domän alls. Din webbplats och e-post fungerar fint för dig och din teknik, men en andel riktiga kunder får “det här gick inte att nå” utan något fel du kan se. Det är ett av de svåraste problemen att diagnostisera just för att det är osynligt inifrån.
- Den förlorade affären. En potentiell kunds säkerhets- eller inköpsteam kör en rutinmässig kontroll före kontrakt av din domän. Ingen DNSSEC dyker upp som ett rött märke på “DNS-säkerhetsgrunder”. För en gratis, välförstått kontroll läses dess frånvaro som vårdslöshet — och det kan tyst kosta dig ett kontrakt du aldrig visste var i fara.
- Upphandlingen du inte ens kvalificerar för. Förordningar och köparens checklistor namnger i allt högre grad DNSSEC som förväntad grundläggande hygien (det refereras under NIS2:s DNS-säkerhetsbestämmelser). Större B2B- och offentliga köpare kan filtrera bort dig innan en säljkonversation börjar, helt enkelt för att rutan inte är ikryssad.
Vad det faktiskt är
DNSSEC fungerar som en förtroendekedja, och det har två rörliga delar som måste stämma överens med varandra. Det här är kärnan i varför vår kontroll tittar på två saker.
DNSKEY — din nyckel. Din DNS-leverantör håller en kryptografisk nyckel och använder den för att signera dina DNS-poster. Den offentliga halvan av den nyckeln publiceras som en DNSKEY-post. Tänk på det som sigillstämpeln hållen på din sida.
DS-posten — fingeravtrycket som borgar för nyckeln. Ett kort fingeravtryck av den nyckeln, kallat en DS (Delegation Signer)-post, publiceras en nivå upp — hos din domäns registry, via din registrar. Det är det som låter resten av internet lita på din nyckel: varje nivå borgar för den nedanför, hela vägen upp till internets rot. DS är sigillet som officiellt registreras så att alla andra kan känna igen det.
För att DNSSEC ska faktiskt skydda dig måste båda vara närvarande och måste matcha:
- DS närvarande + DNSKEY närvarande och matchande → bra. Förtroendekedjan är komplett. Förfalskade svar avvisas; legitima verifieras. Det här är “godkänt”-tillståndet.
- Ingen DS (och ingen DNSKEY) → DNSSEC är helt enkelt inte på. Du har inget skydd, men ingenting är trasigt. Det här är det vanligaste “inte gjort ännu”-tillståndet. (I vår betygsättning är det här var DS-kontrollen räknas mot dig; den kombinerade nyckelkontrollen behandlar ett rent, fullständigt “av”-tillstånd som informativt snarare än ett hårt misslyckande, för ingenting är aktivt trasigt.)
- DS närvarande, men DNSKEY saknas eller är felmatchad → trasigt, och värre än av. Internet ser ett publicerat sigill som pekar på en nyckel som inte finns. Validerande resolvers drar slutsatsen att din domän har manipulerats och vägrar att lösa upp den — vilket orsakar de intermittenta avbrott som beskrivs ovan. Det här är det mest brådskande tillståndet att åtgärda, och vår kontroll flaggar det med hög allvarlighetsgrad.
- DNSKEY närvarande, men ingen DS hos registraren → påslaget men inte aktiverat. Dina poster signeras, men för att fingeravtrycket aldrig registrerades en nivå upp har resten av internet inget sätt att lita på dem. Du gör jobbet utan skyddet. Åtgärden är att lägga till DS-posten hos din registrar.
Vad “bra” ser ut som, på en rad: en DS-post hos din registrar vars fingeravtryck matchar en live DNSKEY hos din DNS-leverantör, båda bekräftade med en snabb sökning.
Så här åtgärdar du det (gratis, ~10–30 minuter)
Lämna det här avsnittet till den som hanterar din domän eller webbplats. Åtgärden i sig är gratis hos de flesta leverantörer — den enda kostnaden är att göra det noggrant så att de två halvorna förblir i synk. Vi tar bara betalt om du senare vill att vi ska övervaka att det förblir korrekt aktiverat.
Den gyllene regeln: aktivera signering först (vilket skapar DNSKEY), publicera sedan DS-posten hos registraren — aldrig tvärtom, och aldrig en utan den andra. Att publicera en DS innan nyckeln finns är exakt vad som orsakar avbrott.
Den enkla vägen (rekommenderas — Cloudflare):
- I Cloudflare, kontrollera att Cloudflare faktiskt kör din DNS (dina namnservrar pekar på Cloudflare).
- Gå till DNS → Inställningar → DNSSEC → Aktivera DNSSEC. Cloudflare genererar och hanterar nycklarna åt dig (detta skapar DNSKEY-sidan automatiskt).
- Cloudflare visar dig DS-postdetaljerna att publicera hos din registrar.
- Logga in på din domänregistrar (t.ex. Blacknight, GoDaddy, Namecheap, OVH) och hitta DNSSEC-avsnittet. Klistra in DS-värdena Cloudflare gav dig.
- Vänta 24–48 timmar för full propagering. Din webbplats och e-post fortsätter fungera hela tiden.
Andra DNS-leverantörer (AWS Route 53, din webbvärd m.fl.):
- I din DNS-leverantörs kontrollpanel, aktivera DNSSEC / “signera den här zonen”. Det genererar signeringsnycklarna och publicerar DNSKEY-posterna.
- Kopiera den DS-post leverantören producerar.
- Lägg till den DS-posten hos din registrar under dess DNSSEC-inställningar.
- Bekräfta att registraren accepterade det och vänta på propagering.
Plattformsnoterningar:
- Cloudflare — ett klicks aktivering, sedan ett DS-inklistrande hos registraren. Den enklaste vägen med god marginal.
- AWS Route 53 — aktivera DNSSEC-signering på den hostade zonen, lägg sedan till DS-posten hos din domäns registrar (om domänen är registrerad med Route 53 kan AWS länka den åt dig).
- Microsoft 365 / Google Workspace — dessa kör din e-post, inte vanligtvis din DNS-zon. DNSSEC aktiveras var dina DNS-poster faktiskt bor (ofta din registrar, värd eller Cloudflare), inte i 365/Workspace-administratörscentret.
- Din DNS-leverantör stödjer inte DNSSEC alls? Det är vanligt med äldre eller budgetplatformar. Den rena åtgärden är att flytta DNS-hanteringen till en leverantör som gör det (Cloudflare är gratis), och sedan följa den enkla vägen ovan. Att flytta DNS kräver inte att du flyttar din webbplats eller e-post.
Verifiera att det fungerade:
- Kör
dig DS dindomän.comochdig DNSKEY dindomän.com— båda bör returnera poster. - Eller använd valfri gratis DNSSEC-kontrollvertyg online och bekräfta en grön/giltig förtroendekedja.
- Räkna inte med att det är klart förrän båda returnerar matchande poster. En DS utan DNSKEY är det trasiga tillståndet — åtgärda eller ta bort det omedelbart.
Vanliga misstag
- Publicera DS innan nyckeln finns. Det enskilt mest skadliga misstaget: att lägga till DS-posten hos registraren innan signering faktiskt är live hos DNS-leverantören. Det skapar “publicerat sigill, saknad nyckel”-tillståndet som gör din domän ouppslösbar för DNSSEC-kontrollerande besökare. Aktivera alltid signering först, publicera sedan DS.
- Lämna en gammal DS kvar efter byte av leverantör. Om du migrerar DNS-leverantörer (eller inaktiverar signering) men glömmer att ta bort eller uppdatera den gamla DS-posten hos registraren är du kvar med en post som pekar på en nyckel som inte längre finns — samma trasiga resultat. När du stänger av DNSSEC eller flyttar det, uppdatera DS hos registraren i samma ändring.
- Stanna efter steg ett. Att aktivera signering hos DNS-leverantören (skapa DNSKEY) men aldrig lägga till DS hos registraren. Allt ser “på” ut i DNS-instrumentpanelen, men utan DS aktiveras aldrig skyddet. Du gjorde jobbet och fick inget av fördelen.
- Anta att HTTPS eller e-postautentisering redan täcker det. Hänglåset och e-postautentisering (SPF / DKIM / DMARC) är värdefulla men löser olika problem. Inget av dem stoppar ett förfalskat DNS-svar från att skicka besökare till fel plats från första början.
- Inte övervaka efter aktivering. Nycklar rullas, leverantörer byts, poster redigeras. En inställning som är perfekt idag kan tyst gå sönder månader senare. Om DNSSEC är viktigt nog att aktivera är det värt en periodisk kontroll att det fortfarande är giltigt.
Var det här sitter i ditt betyg
Båda dessa kontroller räknas mot ditt DNS-säkerhetsbetyg. DS-postens kontroll behandlas som den högre prioriteten av de två: en saknad DS är ett verkligt gap och betygsätts som ett misslyckande. DNSKEY-kontrollen bekräftar att resten av kedjan är intakt — den godkänns bara när en matchande DS och DNSKEY båda finns, och den flaggar det farliga “DS-utan-nyckel” trasiga tillståndet med hög allvarlighetsgrad. Ett rent “DNSSEC är helt enkelt inte aktiverat ännu”-resultat är den vanliga startpunkten för många företag; att gå därifrån till ett komplett, matchande DS + DNSKEY-par är en gratis, välförstådd uppgradering som förbättrar din DNS-säkerhetsposition och tar bort en genuin väg för imitation och avlyssning.
Konfigurera det hos din leverantör
Steg för steg för populära leverantörer:
- Konfigurera DNSSEC hos GoDaddy
- Konfigurera DNSSEC hos Namecheap
- Konfigurera DNSSEC hos Cloudflare
- Konfigurera DNSSEC hos AWS Route 53
Vanliga frågor
Jag är inte teknisk — är det här något jag måste hantera personligen?
Nej. Du behöver förstå varför det spelar roll (den här sidan täcker det), men den faktiska ändringen lever i din domäns DNS- och registrarinställningar, så den tillhör den som hanterar din domän eller webbplats. Lämna avsnittet 'Så här åtgärdar du det' till dem — det är gratis och tar vanligtvis under en halvtimme. Vi tar bara betalt om du senare vill att vi ska hålla koll på att det förblir korrekt påslaget.
Om min webbplats redan har hänglåset (HTTPS), är jag inte redan skyddad?
De skyddar olika saker. Hänglåset säkrar anslutningen när en besökare väl nått rätt server. DNSSEC skyddar steget innan — att se till att de når rätt server från första början. En angripare som förfalskar din DNS kan skicka besökare till sin egna server, som kan ha sitt eget giltiga hänglås på en lookalike-domän eller till och med på en kopia av din. Du behöver båda; ett ersätter inte det andra.
Kan att slå på DNSSEC bryta min webbplats eller e-post?
Gjort på ett enda ställe av en leverantör som stödjer det, nej — moderna leverantörer hanterar nycklarna åt dig och det fungerar bara. Risken kommer från att göra det i två frånkopplade steg och bara avsluta ett: publicera det offentliga 'sigillet' (DS-posten) hos din registrar medan den matchande nyckeln (DNSKEY) saknas eller är felmatchad. Det trasiga tillståndet är värre än ingen DNSSEC och orsakar intermittenta avbrott. Stegen nedan håller de två halvorna i synk så det inte händer.
Vi hostar med Cloudflare / Google Workspace / Microsoft 365 — täcker det det?
Inte automatiskt, men det gör det enkelt. Det som spelar roll är var din DNS hanteras. Om Cloudflare kör din DNS är det ett klick att aktivera plus att klistra in en post hos din registrar. Microsoft 365 och Google Workspace hanterar e-post, inte vanligtvis din DNS-zon — DNSSEC aktiveras var din domäns DNS-poster faktiskt bor (ofta Cloudflare, din registrar eller din värd). Stegen nedan täcker de vanliga fallen.
Vad är exakt 'DS' och 'DNSKEY' — och varför nämner den här sidan båda?
De är de två halvorna av ett lås. DNSKEY är nyckeln din DNS-leverantör håller och använder för att signera dina poster. DS är ett fingeravtryck av den nyckeln, publicerat en nivå upp hos din registrar så att resten av internet kan bekräfta att nyckeln verkligen är din. Båda måste vara närvarande och måste matcha. Vi kontrollerar båda: en saknad DS innebär att DNSSEC inte är påslaget; en DS utan en matchande DNSKEY innebär att det är påslaget men trasigt.
Hur lång tid tills det fungerar, och hur bekräftar jag det?
Tillåt 24–48 timmar för att ändringen ska sprida sig fullständigt över internet; din befintliga webbplats och e-post fortsätter fungera hela tiden om det görs korrekt. För att bekräfta kan din IT-person köra 'dig DS dindomän' och 'dig DNSKEY dindomän' och se poster returnerade för båda, eller använda valfri gratis DNSSEC-kontrolls online-verktyg. Vi kan också övervaka det kontinuerligt så att ett framtida avbrott fångas den dag det händer, inte den dag en kund klagar.