Hva er DNSSEC? Signerte DNS-svar forklart
DNSSEC lar en validerende resolver kontrollere opprinnelse og integritet i DNS-data. Slik virker tillitskjeden, og dette beskytter ikke tiltaket mot.

Når du skriver inn et domenenavn, må en DNS-oppslagstjeneste finne opplysningene som peker videre til riktig tjeneste. DNSSEC er en måte å kontrollere at DNS-dataene kommer fra den ansvarlige sonen og ikke er endret underveis. Det er nyttig, men det gjør verken nettsiden eller selve DNS-spørringen hemmelig.
Hva legger DNSSEC til?
DNSSEC står for Domain Name System Security Extensions. Den som drifter en DNS-sone, kan signere sett av DNS-poster digitalt. En resolver som validerer DNSSEC, kan kontrollere signaturen og en tillitskjede opp til et kjent utgangspunkt. Dermed kan den oppdage at et svar er endret eller ikke kan knyttes til den signerte sonen. Dette er opprinnelseskontroll og integritet, ikke en garanti for at nettstedet bak domenet er trygt. RFC 4033 beskriver disse egenskapene og begrensningene.
Et praktisk tankeeksperiment: Hvis et signert domene normalt peker til én adresse, og noen prøver å bytte ut DNS-svaret på veien til en validerende resolver, skal den falske posten ikke kunne godkjennes uten en gyldig signatur. Hvis sonens eier derimot selv legger inn en feil adresse og signerer den, kan DNSSEC bekrefte at svaret er ekte uten å avsløre at innholdet er feil. Signaturen beviser hvem som står bak DNS-dataene, ikke at eierens valg er klokt.
Hva er DS-posten?
For at valideringen skal fungere på tvers av DNS-hierarkiet, må den overordnede sonen kunne peke på nøkkelen til sonen under. Dette gjøres med en DS-post (Delegation Signer). Domeneforvalteren publiserer den via registreringskjeden, mens DNS-leverandøren håndterer signeringen av selve sonen. Sammen danner postene en tillitskjede. ICANN forklarer tillitskjeden, og RFC 4035 beskriver hvordan valideringen foregår.
Det er derfor ikke nok å slå på en bryter hos DNS-leverandøren og anta at alt er ferdig. Sjekk at riktig DS-post er publisert i den overordnede sonen, og at signaturene faktisk kan valideres. Ved bytte av DNS-leverandør eller nøkler må overgangen planlegges: En gammel eller feil DS-post kan få en validerende resolver til å avvise domenets svar. En bruker kan da oppleve at nettsted eller e-post ikke finnes, mens en annen bruker med en ikke-validerende resolver fremdeles får svar. Feilen kan derfor virke tilfeldig selv om årsaken er i DNS-kjeden.
Hva beskytter DNSSEC ikke?
- Ikke innholdet på nettsiden. HTTPS og korrekt sertifikatvalidering har en annen oppgave enn DNSSEC. En signert DNS-post er ikke et nettstedsertifikat.
- Ikke personvernet for DNS-spørringen. DNSSEC krypterer ikke spørsmålet om hvilket domene du slår opp. DNS over TLS eller DNS over HTTPS gjelder transporten av spørringen; de er ikke det samme som signaturvalidering av DNS-data. Se RFC 7858 og RFC 8484.
- Ikke sikkerheten til kontoen som endrer DNS. Hvis en uvedkommende får legitim kontroll over sonen eller registrarkontoen, må tilgangsstyring og gjenoppretting håndteres separat.
- Ikke tilgjengelighet alene. DNSSEC stopper ikke tjenestenektangrep, og feil i signering eller nøkkelbytte kan selv gjøre oppslag utilgjengelige for validerende resolvere.
Forskjellen mellom integritet og hemmelighold ligner skillet i gjennomgangen vår av ende-til-ende-kryptering: Sikkerhetstiltak må vurderes ut fra akkurat hva de beskytter, ikke bare ut fra ordet «kryptering».
En enkel kontroll før og etter aktivering
- Finn ut hvem som drifter autoritativ DNS, hvem som er domeneregistrar, og hvem som kan endre DS-posten. Det kan være ulike aktører.
- Avklar hvordan leverandøren signerer sonen, hvordan DS publiseres, og hvordan nøkkelbytte håndteres. Ta vare på en ansvarlig kontakt og en tilbakevei.
- Test domenet mot en validerende resolver etter endringen. Kontroller både vanlige oppslag og at tillitskjeden er gyldig, ikke bare at en DNS-post kan leses fra den autoritative serveren.
- Ved senere leverandørbytte: planlegg rekkefølgen for ny signering og DS-endring, og kontroller på nytt etterpå. Ikke la en gammel DS-post stå igjen uten å vite hva den peker på.
En valideringsfeil kan være et sikkerhetssignal eller en driftsfeil. RFC 4033 beskriver blant annet tilstanden «bogus» når en forventet signert kjede ikke lar seg validere. Undersøk årsaken før du omgår kontrollen: Feil DS, utløpte signaturer og manglende DNSSEC-data krever ulike tiltak.
Kort oppsummert: DNSSEC lar en validerende resolver kontrollere DNS-datas opprinnelse og integritet. Verdien forsvinner hvis tillitskjeden ikke er riktig satt opp, og tiltaket erstatter verken HTTPS, god kontosikkerhet eller en plan for endringer i DNS.


