DNSSEC på godt norsk

Modul 8: Sikkerhet og feilsøking · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du i vanlig språk forklare hva DNSSEC beskytter, hvordan tillitskjeden fungerer og hvorfor det kan gå galt ved en domeneoverføring.

Nøkkelbegreper: DNSSEC, signatur (RRSIG), nøkkel (DNSKEY), DS-post, tillitskjede, validerende resolver, SERVFAIL

Problemet: hvordan vet du at et svar er ekte?

I modul 1 så du at en resolver stiller en rekke spørsmål: til roten, til TLD-serveren og til den autoritative navnetjeneren. Svaret som kommer tilbake, blir trodd og lagret i cache. Men vanlig DNS kontrollerer ikke om svaret virkelig kommer fra riktig navnetjener. En angriper som klarer å sende et falskt svar før det ekte svaret kommer frem, kan få en resolver til å tro at example.com ligger på 203.0.113.66 i stedet for på 192.0.2.10. Dette kalles cache poisoning: cachen er "forgiftet", og alle som bruker den resolveren, havner på feil server.

DNSSEC (DNS Security Extensions) løser dette ved å signere svarene. Resolveren kan da kontrollere om et svar er ekte og ikke er endret underveis.

Hva DNSSEC gjør og ikke gjør

Dette er det viktigste å huske:

En signatur fungerer som en segl på en konvolutt: alle kan lese brevet, men du ser med en gang om noen har åpnet den.

De tre delene

DNSSEC legger til noen posttyper. Du trenger ikke lage dem selv (det gjør DNS-forvalteren din eller panelet), men du vil støte på dem:

• DNSKEY: den offentlige nøkkelen til sonen. Med denne kan alle kontrollere signaturene.
• RRSIG: signaturen til en gruppe poster. Hver A-, MX- eller TXT-respons får en RRSIG med seg. En signatur har en start- og sluttdato: sonen må derfor signeres på nytt med jevne mellomrom.
• DS (Delegation Signer): et kort "fingeravtrykk" av nøkkelen til din sone. Det ligger ikke i din egen sone, men hos foreldresonen: for example.com altså hos registeret for .com (Verisign), for et .nl-domene hos SIDN.

Slik ser et signert svar ut (forkortet):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

I RRSIG-en ser du blant annet algoritmen (13 = ECDSA P-256 med SHA-256), sluttdatoen (19. november 2026), startdatoen og nummeret på nøkkelen (30794).

Tillitskjeden

Hvorfor ligger DS-en hos foreldresonen? Fordi en nøkkel i din egen sone ikke beviser noe: en angriper kunne jo også sendt med sin egen nøkkel. Derfor går kontrollen ovenfra og ned:

1. Resolveren stoler på nøkkelen til roten. Den er innebygd i hver validerende resolver (trust anchor).
2. Roten har en DS for .com, signert med rotnøkkelen. Dermed vet resolveren hvilken nøkkel .com skal ha.
3. .com-sonen har en DS for example.com, signert med .com-nøkkelen.
4. Sonen example.com har en DNSKEY som passer med den DS-en, og dermed kan alle RRSIG-ene kontrolleres.

Hvert ledd beviser det neste. Hvis ett ledd brytes, er hele kjeden upålitelig.

En validerende resolver (de fleste store offentlige resolvere, og stadig flere leverandører) går gjennom denne kjeden. Hvis den stemmer, får du svaret. Hvis den ikke stemmer, gir resolveren ikke noe svar, men feilstatusen SERVFAIL. For besøkende ser det da ut som om siden rett og slett "ikke finnes", mens postene dine kanskje er helt i orden.

Du kan se dette selv med et domene som bevisst er ødelagt:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Med +cd ("checking disabled") ber du resolveren hoppe over kontrollen. Får du da et svar, vet du sikkert at det skyldes DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Et domene uten DNSSEC (ingen DS hos foreldresonen) gir ikke SERVFAIL: det er da rett og slett ikke signert, og blir sluppet gjennom som "usikret".

Hvor det går galt: flytting og nøkkelbytte

DNSSEC i seg selv går nesten aldri i stykker. Det går galt når DS-en hos registeret ikke lenger passer med nøkkelen i sonen. Dette skjer særlig:

• Ved flytting av navnetjenere eller DNS-leverandør. Den nye leverandøren signerer med sin egen nøkkel, men hos registeret står fortsatt DS-en til den gamle leverandøren. Resultat: SERVFAIL for alle med validerende resolver. Dette er den klassiske feilen etter en domeneoverføring.
• Ved et nøkkelbytte der den nye DS-en ikke er sendt (i tide) til registeret.
• Når signaturene utløper, fordi sonen ikke lenger signeres på nytt.

Den sikre rekkefølgen ved en flytting er derfor:

1. Fjern DS-en hos registeret (eller la den nye leverandøren levere en DS som du legger til).
2. Vent til TTL-en til den gamle DS-en har gått ut.
3. Bytt navnetjenerne.
4. Slå på DNSSEC hos den nye leverandøren og la den nye DS-en bli lagt inn hos registeret.

Mange registrarer og paneler ordner dette automatisk i dag, så lenge domene og DNS ligger hos samme leverandør. Ligger de hos forskjellige leverandører, må du overføre DS-en selv.

Kontroller selv: DNSViz, Zonemaster og internet.nl

Du trenger ikke følge kjeden med dig selv. Det finnes gratis verktøy som gjør det for deg og viser resultatet.

DNSViz (https://dnsviz.net/) tegner hele kjeden som et bilde. Slik bruker du det:

1. Skriv domenenavnet i søkefeltet på forsiden (bare navnet, uten https:// og uten www) og klikk på Go.
2. DNSViz viser siste analyse. Er den gammel, eller har du nettopp endret noe, klikk da på Update now. Etter noen sekunder ser du bildet.
3. Les bildet ovenfra og ned: øverst roten (.), under den TLD-en (for eksempel nl), nederst domenet ditt. Hver sone er en ramme.

Dette ser du i bildet:

Kjeden følger du slik: DS (hos foreldresonen) peker på DNSKEY-en (i din sone), og den DNSKEY-en setter med en RRSIG sin signatur under postene. Det er akkurat kjeden fra denne leksjonen, bare tegnet.

Fargene forteller om det stemmer:

• Blå: sikker (secure). Kjeden går uavbrutt fra roten til denne delen.
• Svart: ikke signert (insecure). Det finnes ingen DS, så det er ingenting å kontrollere. Det er ikke en feil, domenet bruker rett og slett ikke DNSSEC.
• Rød: ødelagt (bogus). En DS passer ikke med en nøkkel, eller en signatur stemmer ikke. En validerende resolver gir da SERVFAIL.
• Lilla (ved en signatur): signaturen er utløpt eller ikke gyldig ennå. Sonen signeres ikke lenger på nytt.
• Gul: en advarsel, for eksempel en navnetjener som ikke svarer riktig, eller en algoritme verktøyet ikke kjenner.
• Grå og stiplet: det vises til en nøkkel som ikke finnes. Ser du en stiplet DNSKEY under en DS, står det hos foreldresonen fortsatt en DS fra en gammel nøkkel: den klassiske feilen etter en domeneoverføring.

Ved siden av en del kan det stå en liten trekant (advarsel) eller et rundt feiltegn. Hold musen over det, eller se i listen under bildet: der står det i ord hva som er galt.

Prøv med sidn.nl (alt blått) og med dnssec-failed.org (rødt, med en stiplet nøkkel under DS-en).

Andre verktøy som ser på det samme fra en annen vinkel:

• Zonemaster (https://zonemaster.net/): kontrollerer hele sonen din slik et register gjør det, også DNSSEC. Resultatet er en liste med grønt (bra), oransje (advarsel) og rødt (feil).
• internet.nl (https://internet.nl/): nettsted- og e-posttesten viser blant annet om DNSSEC for domenet ditt og mailserverne dine er i orden, med grønne haker eller røde kryss.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): går gjennom kjeden steg for steg og setter en grønn hake eller et rødt kryss ved hvert steg. Nyttig når du leter etter én konkret feil.

Bruk dem etter hver endring i DNSSEC, og helt sikkert før og etter en domeneoverføring. La verktøyet analysere på nytt i ro og mak: også disse verktøyene bruker cache og TTL-er.

I praksis: slik ser det ut i et panel

I Min side slår du på DNSSEC for et domene under DNSSEC/DANE; panelet lager nøklene og sender DS-en til registeret. I DirectAdmin og hos eksterne leverandører som Cloudflare heter det vanligvis "DNSSEC inschakelen"; Cloudflare viser deg da en DS-post som du selv må legge inn hos registraren din. Andre paneler fungerer på lignende måte: det finnes alltid et steg "lag nøkler" (hos DNS-leverandøren) og et steg "DS hos registeret" (hos registraren).

Oppsummering

• DNSSEC signerer DNS-svar slik at en resolver kan kontrollere at de er ekte. Det krypterer ingenting.
• DNSKEY er nøkkelen, RRSIG signaturen, DS fingeravtrykket hos foreldresonen.
• Kontrollen går som en kjede fra roten til ditt domene. Brytes et ledd, gir en validerende resolver SERVFAIL.
• Nesten alle problemer oppstår fordi DS-en hos registeret ikke lenger passer, ofte etter en domeneoverføring.
• Med dig +cd ser du om et problem skyldes DNSSEC.
• DNSViz tegner kjeden: blått er sikkert, svart er ikke signert, rødt er ødelagt. Zonemaster, internet.nl og Verisign DNSSEC Debugger er gode andremeninger.

Quiz

Oppgave

Oppgave Z8.1: Se DNSSEC i praksis. Finn ut hvilket av to domener som har DNSSEC i orden, og hvilket som er bevisst ødelagt: sidn.nl og dnssec-failed.org. Spør for begge etter DS-posten og A-posten via en validerende resolver (for eksempel 1.1.1.1 eller 9.9.9.9), med dig eller et nettbasert verktøy. Fyll inn: nøkkelnummeret (key tag, det første tallet) til DS-en for sidn.nl, og statusen du får for dnssec-failed.org.

Oppgave Z8.1b: Lese DNSViz. Analyser nlnetlabs.nl i DNSViz (https://dnsviz.net/, skriv inn navnet og klikk på Go; klikk på Update now hvis analysen er gammel). Les bildet og fyll inn: (1) statusen til nlnetlabs.nl (sikker, ikke signert eller ødelagt), (2) algoritmenummeret til DNSKEY-postene (står i hver oval som alg=), (3) hvor mange DNSKEY-ovaler som ligger i sonen til nlnetlabs.nl, (4) nøkkelnummeret (id=) til den grå, fylte DNSKEY-en som DS-en peker på, og (5) statusen DNSViz gir for dnssec-failed.org. Kontrollen henter de samme dataene live.

Oppgave O8.1: Vurdere tre DNSSEC-demosoner. Vi har satt opp tre demosoner: signed-demo.dnspractice.com (god kjede), broken-demo.dnspractice.com (bevisst ødelagt) og unsigned-demo.dnspractice.com (ikke signert). Finn for hver sone ut om den er sikker, ødelagt eller ikke signert, for eksempel med DNSViz eller med dig +dnssec (se etter AD-flagget, og prøv ved en SERVFAIL også +cd). Velg svaret ditt for hver sone nedenfor.

Les mer

Disse artiklene beskriver stegene i panelene til WebOké; hos andre leverandører heter knappene annerledes.

• WebOké-veiledning 5.8: DNSSEC og DANE
• Hva er DNSSEC?
• DNSSEC-aktivering
• Nettsiden eller e-posten fungerer ikke etter en flytting eller DNS-endring: sjekk domenet ditt