Defaults.Exposed › Fikser › DNSSEC

Slik fikser du DNSSEC

DNSSEC er et digitalt segl på domenets adressebok. Det lar internett bevise at svaret på 'hvor bor dette domenet?' virkelig kom fra deg og ikke ble manipulert på veien. Uten det kan svaret forfalskes — og besøkende stille sendes et annet sted.

Bunnlinjen for virksomheten din: Uten DNSSEC kan en angriper som kan forgifte et DNS-svar peke kundene dine mot en perfekt kopi av siden din mens nettleseren fortsatt viser det ekte domenenavnet ditt. Innlogginger, kortnumre og personopplysninger høstes, og du finner ut av det bare fra tilbakebetalingene og klagene. Et halvferdig, ødelagt DNSSEC-oppsett er enda verre: det kan gjøre nettstedet ditt uoppnåelig for en voksende andel besøkende uten noen feil du noen gang ville legge merke til.

Hva dette kan koste deg

Besøkende som taster det ekte domenet ditt blir stille omdirigert til en lookalike som fanger opp passordet og kortdetaljene — og fordi adresselinjen viser domenet ditt hele tiden, mistenker ingen noe før svindelmeldingene ankommer.
E-posten din omdirigeres stille: en angriper forfalsker svaret for e-postserverne dine, leser eller avskjærer meldinger, og tilbakestiller passord på kontoer som e-poster deg en kode — alt uten å røre innboksen.
Et halvkonfigurert DNSSEC-oppsett (det offentlige seglet eksisterer men den matchende nøkkelen mangler) gjør nettstedet og e-posten din tilfeldig til svikt for kunder på store ISP-er og bedriftsnettverk — intermitterende 'nettstedet ditt er nede for meg'-rapporter du ikke kan reprodusere.
Et prospekts sikkerhetsteam kjører en pre-kontrakt-sjekk, ser ingen DNSSEC, og merker deg ned som svak på det grunnleggende — setter en avtale i risiko over en gratis innstilling.
Offentlig sektor og større B2B-kjøpere forventer i stadig større grad DNSSEC som grunnleggende standard (det er nevnt i regelverk som NIS2); fraværet diskvalifiserer deg stille fra anbudskonkurranser før en samtale engang starter.

Hvorfor det er viktig. DNS er internettets adressebok, og som standard reiser svarene usignert — hvem som helst som kan sette inn et forfalsket svar kan sende kundene og e-posten din hvor de vil, med det ekte domenet ditt fortsatt synlig i nettleseren. DNSSEC setter et manipuleringsbestandig segl på disse svarene slik at de kan verifiseres som genuint dine. Fiksen er gratis hos de fleste leverandører; den eneste reelle kostnaden er å gjøre det galt, noe som er grunnen til at vi går grundig gjennom begge halvdelene.

DNSSEC, i enkle ord

Hver gang noen besøker nettstedet ditt eller sender deg en e-post, stiller datamaskinen deres først internett et enkelt spørsmål: «hvor bor dette domenet egentlig?» Svaret — settet med adresser for nettstedet og e-postserverne dine — kommer tilbake fra DNS, internettets adressebok.

Her er den ubehagelige delen: som standard reiser disse svarene usignert. Det er ingenting festet til det som beviser at svaret er ekte. Hvis noen kan sette inn et forfalsket svar i den samtalen — og det finnes godt kjente, bevisste måter å gjøre nøyaktig det — vil besøkendes datamaskin gladelig akseptere det. Fra det øyeblikket kan den besøkende snakke med en angripers server mens nettleseren fortsatt viser ditt domenenavn i adresselinjen.

DNSSEC er fiksen. Den legger til et manipuleringsbestandig digitalt segl til DNS-svarene dine. Når DNSSEC er slått på, kan internett matematisk verifisere at et svar virkelig kom fra deg og ikke ble endret på veien. Et forfalsket svar mislykkes i sjekken og kastes bort. Det er forskjellen mellom en adressebok hvem som helst kan skrive i og én der hvert oppslag er signert og bevitnet.

Denne siden dekker de to delene sjekken vår ser på sammen: om seglet er publisert (DS-posten) og om den matchende nøkkelen bak det faktisk eksisterer (DNSKEY-posten). Du vil se hvorfor begge betyr noe snart — fordi å ha én uten den andre er sin egen type trøbbel.

Hva dette kan koste deg

Disse er realistiske, samlede mønstre — ikke noen navngitte virksomheter.

Den usynlige omdirigeringen. En angriper forgifter DNS-svaret for domenet ditt. Kunder taster den ekte webadressen din, ser det ekte domenet ditt i adresselinjen, og lander på en feilfri kopi av innloggings- eller kassesiden din hostet av angriperen. Hvert passord og kortnummer de skriver inn går rett til kriminelle. Du hører om det bare når tilbakebetalingene og «jeg ble hacket gjennom siden din»-samtalene starter — og sporet fører tilbake til merket ditt, ikke angripeliges.
Stille e-postcavskjæring. DNS peker ikke bare til nettstedet ditt; det peker til e-postserverne dine. Forfals det svaret og innkommende e-post kan rutes gjennom en angriper først. De leser sensitive meldinger, høster éngangs-kodene som tjenester e-poster til «bekreft at det er deg», og tilbakestiller passord på kontoer knyttet til domenet ditt — alt uten noen gang å logge inn i postkassen din.
Driftsintansen du ikke kan reprodusere. Denne kommer fra et halvferdig DNSSEC-oppsett. Det offentlige seglet (DS) sitter hos registraren din, men den matchende nøkkelen (DNSKEY) mangler eller er feil. Besøkende hos ISP-er og bedriftsnettverk som sjekker DNSSEC — og det er flere hvert år — kan simpelthen ikke løse opp domenet ditt i det hele tatt. Nettstedet og e-posten fungerer fint for deg og IT-folket ditt, men en andel av ekte kunder får «dette nettstedet kan ikke nås» uten noen feil du kan se. Det er et av de vanskeligste problemene å diagnostisere nettopp fordi det er usynlig innenfra.
Den tapte avtalen. Et prospekts sikkerhets- eller innkjøpsteam kjører en rutineoppsøk-skanning av domenet ditt. Ingen DNSSEC vises som et rødt merke på «DNS-sikkerhetsgrunnlag». For en gratis, godt forstått kontroll leses fraværet som uaktsomhet — og det kan stille koste deg en kontrakt du aldri visste var i fare.
Anbudet du ikke engang kvalifiserer for. Regelverk og kjøpersjekklister navngir i stadig større grad DNSSEC som forventet grunnleggende hygiene (det er referert til under NIS2s DNS-sikkerhetsbestemmelser). Større B2B- og offentlig sektorkjøpere kan filtrere deg ut før en salgssamtale begynner, simpelthen fordi boksen ikke er avkrysset.

Hva det faktisk er

DNSSEC fungerer som en tillitskjede, og den har to bevegelige deler som må være enige med hverandre. Dette er kjernen i hvorfor sjekken vår ser på to ting.

DNSKEY — din nøkkel. DNS-leverandøren din holder en kryptografisk nøkkel og bruker den til å signere DNS-postene dine. Den offentlige halvdelen av den nøkkelen publiseres som en DNSKEY-post. Tenk på det som segl-stempelet holdt på din ende.

DS-posten — fingeravtrykket som garanterer for nøkkelen. Et kort fingeravtrykk av den nøkkelen, kalt en DS (Delegation Signer)-post, publiseres ett nivå opp — hos domenets register, via registraren din. Dette er det som lar resten av internett stole på nøkkelen din: hvert nivå garanterer for det under, helt opp til internettets rot. DS-en er seglet som er offisielt registrert slik at alle andre kan gjenkjenne det.

For at DNSSEC faktisk skal beskytte deg, må begge være til stede og de må matche:

DS til stede + DNSKEY til stede og matchende → bra. Tillitskjeden er komplett. Forfalskede svar avvises; legitime verifiseres. Dette er «bestå»-tilstanden.
Ingen DS (og ingen DNSKEY) → DNSSEC er simpelthen ikke slått på. Du har ingen beskyttelse, men ingenting er ødelagt. Dette er den vanligste «ennå ikke gjort»-tilstanden.
DS til stede, men DNSKEY mangler eller er feil matchet → ødelagt, og verre enn av. Internett ser et publisert segl som peker til en nøkkel som ikke er der. Validerende resolvere konkluderer med at domenet ditt har blitt manipulert og nekter å løse det opp — noe som forårsaker de intermitterende driftsintansene beskrevet ovenfor. Dette er den mest haste tilstanden å fikse, og sjekken vår flagger det som høy alvorlighetsgrad.
DNSKEY til stede, men ingen DS hos registraren → slått på men ikke aktivert. Postene dine er signert, men fordi fingeravtrykket aldri ble registrert ett nivå opp, har resten av internett ingen måte å stole på dem. Du gjør jobben uten beskyttelsen. Fiksen er å legge til DS-posten hos registraren.

Hva «bra» ser ut som i én linje: en DS-post hos registraren hvis fingeravtrykk stemmer overens med en live DNSKEY hos DNS-leverandøren din, begge bekreftet med et raskt oppslag.

Slik fikser du det (gratis, ~10–30 minutter)

Gi denne seksjonen til den som administrerer domenet eller nettstedet ditt. Selve fiksen er gratis hos de fleste leverandører — den eneste kostnaden er å gjøre det forsiktig slik at de to halvdelene holder seg synkronisert. Vi tar bare betalt hvis du later vil at vi skal overvåke at det forblir riktig aktivert.

Den gyldne regelen: aktiver signering først (som oppretter DNSKEY), publiser deretter DS-posten hos registraren — aldri omvendt, og aldri én uten den andre. Å publisere en DS før nøkkelen eksisterer er nøyaktig det som forårsaker driftsintanser.

Den enkle veien (anbefalt — Cloudflare):

I Cloudflare, sørg for at Cloudflare faktisk driver DNS-en din (navneserverne peker til Cloudflare).
Gå til DNS → Innstillinger → DNSSEC → Aktiver DNSSEC. Cloudflare genererer og administrerer nøklene for deg (dette oppretter DNSKEY-siden automatisk).
Cloudflare viser deg DS-post-detaljene for å publisere hos registraren.
Logg inn på domeneregistraren (f.eks. GoDaddy, Namecheap, OVH) og finn DNSSEC-seksjonen. Lim inn DS-verdiene Cloudflare ga deg.
Vent 24–48 timer for full propagering. Nettstedet og e-posten fortsetter å fungere gjennom hele prosessen.

Andre DNS-leverandører (AWS Route 53, webhotellet ditt, osv.):

I DNS-leverandørens kontrollpanel, aktiver DNSSEC / «signer denne sonen». Dette genererer signeringsnøklene og publiserer DNSKEY-postene.
Kopier DS-posten leverandøren produserer.
Legg til den DS-posten hos registraren under DNSSEC-innstillingene.
Bekreft at registraren aksepterte den og vent på propagering.

Plattformnotater:

Cloudflare — ett klikk for å aktivere, deretter én DS-lim inn hos registraren. Den enkleste ruten med stor margin.
AWS Route 53 — aktiver DNSSEC-signering på det hostede sone, legg deretter til DS-posten hos domenets registrar (hvis domenet er registrert hos Route 53, kan AWS koble det for deg).
Microsoft 365 / Google Workspace — disse driver e-posten din, ikke vanligvis DNS-sonen. DNSSEC aktiveres der DNS-postene faktisk bor (ofte registraren, webhotellet eller Cloudflare), ikke i 365/Workspace-administrasjonssenteret.
DNS-leverandøren din støtter ikke DNSSEC i det hele tatt? Det er vanlig med eldre eller rimelige webhotell. Den rene fiksen er å flytte DNS-administrasjon til en leverandør som gjør det (Cloudflare er gratis), og deretter følge den enkle veien ovenfor. Å flytte DNS krever ikke å flytte nettstedet eller e-posten.

Verifiser at det fungerte:

Kjør dig DS dittdomene.com og dig DNSKEY dittdomene.com — begge bør returnere poster.
Eller bruk en gratis online DNSSEC-kontroller og bekreft en grønn/gyldig tillitskjede.
Ikke betrakt det som ferdig til begge returnerer matchende poster. En DS uten DNSKEY er den brutte tilstanden — fiks eller fjern den umiddelbart.

Vanlige feil

Publisere DS-en før nøkkelen eksisterer. Den eneste mest skadelige feilen: legge til DS-posten hos registraren før signering faktisk er live hos DNS-leverandøren. Dette oppretter «publisert segl, manglende nøkkel»-tilstanden som gjør domenet uoppnåelig for DNSSEC-sjekk-besøkende. Aktiver alltid signering først, publiser deretter DS.
La en foreldet DS stå igjen etter å ha byttet leverandør. Hvis du migrerer DNS-leverandører (eller deaktiverer signering) men glemmer å fjerne eller oppdatere den gamle DS-posten hos registraren, sitter du igjen og peker på en nøkkel som ikke lenger eksisterer — samme brutte utfall. Når du slår av DNSSEC eller flytter det, oppdater DS-en hos registraren i samme endring.
Stoppe etter steg én. Aktivere signering hos DNS-leverandøren (opprette DNSKEY) men aldri legge til DS-en hos registraren. Alt ser «på» ut i DNS-dashbordet, men uten DS aktiveres aldri beskyttelsen. Du gjorde jobben og fikk ingen av fordelene.
Anta at HTTPS eller e-postautentisering allerede dekker det. Hengelåsen og e-postautentisering (SPF / DKIM / DMARC) er verdifulle men løser forskjellige problemer. Ingen av dem stopper et forfalsket DNS-svar fra å sende besøkende til feil sted i utgangspunktet.
Ikke overvåke etter aktivering. Nøkler rulles over, leverandører endres, poster redigeres. Et oppsett som er perfekt i dag kan stille bryte seg måneder senere. Hvis DNSSEC betyr nok til å aktivere, er det verdt en periodisk sjekk av at det fortsatt er gyldig.

Hvor dette sitter i karakteren din

Begge disse sjekkene teller mot DNS-sikkerhetsscoren din. DS-post-sjekken behandles som høyere prioritet av de to: en manglende DS er et reelt gap og scores som feil. DNSKEY-sjekken bekrefter at resten av kjeden er intakt — den bestås bare når en matchende DS og DNSKEY begge er til stede, og den flagger den farlige «DS-uten-nøkkel»-brutte tilstanden som høy alvorlighetsgrad. Et rent «DNSSEC er simpelthen ikke aktivert ennå»-resultat er det vanlige utgangspunktet for mange virksomheter; å flytte fra der til et komplett, matchende DS + DNSKEY-par er en gratis, godt forstått oppgradering som forbedrer DNS-sikkerhetsstandpunktet ditt og fjerner en genuint åpen vei for etterligning og avskjæring.

Sett det opp hos din leverandør

Trinn for trinn for populære leverandører:

FAQ

Jeg er ikke teknisk anlagt — er dette noe jeg må ta personlig hånd om?

Nei. Du trenger å forstå hvorfor det betyr noe (denne siden dekker det), men selve endringen lever i domenets DNS- og registrarinnstillinger, så det hører hjemme hos den som administrerer domenet eller nettstedet ditt. Gi dem «Slik fikser du det»-seksjonen — det er gratis og tar vanligvis under en halvtime. Vi tar bare betalt hvis du later vil at vi skal holde øye med at det forblir riktig slått på.

Hvis siden allerede har hengelåsen (HTTPS), er jeg ikke allerede beskyttet?

De beskytter forskjellige ting. Hengelåsen sikrer tilkoblingen når en besøkende har nådd riktig server. DNSSEC beskytter steget før det — å sørge for at de når riktig server i utgangspunktet. En angriper som forfalsker DNS-en kan sende besøkende til sin egen server, som kan ha sin egen gyldige hengelås på et lookalike-domene eller til og med på en kopi av din. Du trenger begge; én erstatter ikke den andre.

Kan det å slå DNSSEC på ødelegge nettstedet eller e-posten min?

Gjort på ett sted av en leverandør som støtter det, nei — moderne leverandører håndterer nøklene for deg og det fungerer bare. Risikoen kommer fra å gjøre det i to frakoblede steg og bare fullføre ett: publisere det offentlige 'seglet' (DS-posten) hos registraren mens den matchende nøkkelen (DNSKEY) mangler eller er feil matchet. Den brutte tilstanden er verre enn ingen DNSSEC og forårsaker intermitterende driftsintanser. Stegene nedenfor holder de to halvdelene synkronisert slik at dette ikke skjer.

Vi er vert hos Cloudflare / Google Workspace / Microsoft 365 — dekker det dette?

Ikke automatisk, men det gjør det enkelt. Det som betyr noe er der DNS-en din administreres. Hvis Cloudflare driver DNS-en din, er det ett klikk for å aktivere pluss å lime inn én post hos registraren. Microsoft 365 og Google Workspace håndterer e-post, ikke vanligvis DNS-sonen din — DNSSEC aktiveres der domenets DNS-poster faktisk bor (ofte Cloudflare, registraren eller webhotellet). Stegene nedenfor dekker de vanlige tilfellene.

Hva er egentlig 'DS' og 'DNSKEY' — og hvorfor nevner siden begge?

De er de to halvdelene av ett lås. DNSKEY er nøkkelen DNS-leverandøren din holder og bruker til å signere postene dine. DS er et fingeravtrykk av den nøkkelen, publisert ett nivå opp hos registraren din slik at resten av internett kan bekrefte at nøkkelen virkelig er din. Begge må være til stede og må matche. Vi sjekker begge: en manglende DS betyr at DNSSEC ikke er slått på; en DS uten en matchende DNSKEY betyr at den er slått på men ødelagt.

Hvor lenge til det fungerer, og hvordan bekrefter jeg det?

Tillat 24–48 timer for at endringen skal spre seg fullt ut over internett; det eksisterende nettstedet og e-posten fortsetter å fungere gjennom hele prosessen hvis det gjøres riktig. For å bekrefte kan IT-personen din kjøre 'dig DS dittdomene' og 'dig DNSKEY dittdomene' og se poster returnert for begge, eller bruke en gratis online DNSSEC-kontroller. Vi kan også overvåke det kontinuerlig slik at et fremtidig brudd fanges den dagen det skjer, ikke den dagen en kunde klager.