DNSSEC i almindeligt sprog

Modul 8: Sikkerhed og fejlfinding · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du i almindeligt sprog forklare hvad DNSSEC beskytter, hvordan tillidskæden virker, og hvorfor det kan gå galt ved en flytning.

Nøglebegreber: DNSSEC, signatur (RRSIG), nøgle (DNSKEY), DS-record, tillidskæde, validerende resolver, SERVFAIL

Problemet: hvordan ved du at et svar er ægte?

I modul 1 så du at en resolver stiller en række spørgsmål: til roden, til TLD-serveren og til den autoritative navneserver. Det svar der kommer tilbage, bliver troet på og lagt i cachen. Men det almindelige DNS kontrollerer ikke om det svar virkelig kommer fra den rigtige navneserver. En angriber der formår at sende et falsk svar før det rigtige svar når frem, kan få en resolver til at tro at example.com bor på 203.0.113.66 i stedet for på 192.0.2.10. Det kaldes cache poisoning: cachen bliver "forgiftet", og alle der bruger den resolver, ender på den forkerte server.

DNSSEC (DNS Security Extensions) løser det ved at signere svar. Resolveren kan derefter kontrollere om et svar er ægte og ikke er blevet ændret undervejs.

Hvad DNSSEC gør og ikke gør

Dette er det vigtigste at huske:

En signatur fungerer som et segl på en kuvert: alle kan læse brevet, men du kan straks se om nogen har åbnet den.

De tre elementer

DNSSEC tilføjer nogle recordtyper. Du behøver ikke selv at oprette dem (det klarer din DNS-administrator eller panel), men du støder på dem:

• DNSKEY: zonens offentlige nøgle. Med den kan alle kontrollere signaturerne.
• RRSIG: signaturen ved en gruppe records. Hvert A-, MX- eller TXT-svar får en RRSIG med. En signatur har en start- og slutdato: zonen skal derfor regelmæssigt signeres på ny.
• DS (Delegation Signer): et kort "fingeraftryk" af nøglen til din zone. Det står ikke i din egen zone, men hos forælderen: for example.com altså hos registryen for .com (Verisign), for et .nl-domæne hos SIDN (registryen for .nl i Holland).

Sådan ser et signeret svar ud (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 blandt andet algoritmen (13 = ECDSA P-256 med SHA-256), slutdatoen (19. november 2026), startdatoen og nøglens nummer (30794).

Tillidskæden

Hvorfor står DS'en hos forælderen? Fordi en nøgle i din egen zone ikke beviser noget: en angriber kunne jo også sende en egen nøgle med. Derfor løber kontrollen fra top til bund:

1. Resolveren stoler på nøglen fra roden. Den sidder indbygget i enhver validerende resolver (trust anchor).
2. Roden har en DS for .com, signeret med rodnøglen. Dermed ved resolveren hvilken nøgle .com bør have.
3. .com-zonen har en DS for example.com, signeret med .com-nøglen.
4. Zonen example.com har en DNSKEY der passer til den DS, og dermed kan alle RRSIG'er kontrolleres.

Hvert led beviser det næste. Brister ét led, er hele kæden utroværdig.

En validerende resolver (de fleste store offentlige resolvere, og flere og flere udbydere) gennemgår den kæde. Stemmer den, får du svaret. Stemmer den ikke, giver resolveren intet svar, men fejlstatussen SERVFAIL. For den besøgende ser siden så bare ud til "ikke at findes", selvom dine records måske er helt i orden.

Du kan selv se det med et domæne der bevidst er gjort i stykker:

$ 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") beder du resolveren om at springe kontrollen over. Får du så et svar, ved du med sikkerhed at det skyldes DNSSEC:

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

Et domæne uden DNSSEC (ingen DS hos forælderen) giver ikke SERVFAIL: det er bare ikke signeret og bliver lukket igennem som "usikret".

Hvor det går galt: flytning og nøgleskift

DNSSEC selv går næsten aldrig i stykker. Det går galt når DS'en hos registryen ikke længere passer til nøglen i zonen. Det sker især:

• Ved en flytning af navneservere eller DNS-udbyder. Den nye udbyder signerer med en egen nøgle, men hos registryen står stadig DS'en fra den gamle udbyder. Resultat: SERVFAIL for alle med en validerende resolver. Dette er den klassiske fejl efter en flytning.
• Ved et nøgleskift hvor den nye DS ikke er (rettidigt) sendt til registryen.
• Når signaturerne udløber, fordi zonen ikke bliver signeret på ny længere.

Den sikre rækkefølge ved en flytning er derfor:

1. Fjern DS'en hos registryen (eller lad den nye udbyder levere en DS som du tilføjer).
2. Vent til TTL'en på den gamle DS er udløbet.
3. Skift navneservere.
4. Slå DNSSEC til hos den nye udbyder, og få den nye DS sat hos registryen.

Mange registrarer og paneler klarer i dag dette automatisk, så længe domæne og DNS ligger hos samme udbyder. Ligger de hos forskellige udbydere, skal du selv overføre DS'en.

Kontrollér selv: DNSViz, Zonemaster og internet.nl

Du behøver ikke gennemgå kæden med dig. Der findes gratis værktøjer der gør det for dig og viser resultatet.

DNSViz (https://dnsviz.net/) tegner hele kæden som et billede. Sådan bruger du det:

1. Skriv domænenavnet i søgefeltet på forsiden (kun navnet, uden https:// og uden www) og klik på Go.
2. DNSViz viser den seneste analyse. Er den gammel, eller har du lige ændret noget, så klik på Update now. Efter nogle sekunder ser du billedet.
3. Læs billedet fra top til bund: øverst roden (.), derunder TLD'en (for eksempel nl), nederst dit domæne. Hver zone er en ramme.

Hvad du ser i billedet:

Kæden følger du sådan: DS (hos forælderen) peger på DNSKEY (i din zone), og den DNSKEY sætter med en RRSIG sin signatur under records. Det er præcis den kæde fra denne lektion, bare tegnet.

Farverne fortæller om det stemmer:

• Blå: sikker (secure). Kæden løber ubrudt fra roden til dette element.
• Sort: ikke signeret (insecure). Der er ingen DS, så der er intet at kontrollere. Det er ikke en fejl, domænet bruger bare ikke DNSSEC.
• Rød: i stykker (bogus). En DS passer ikke til en nøgle, eller en signatur stemmer ikke. En validerende resolver giver så SERVFAIL.
• Lilla (ved en signatur): signaturen er udløbet eller endnu ikke gyldig. Zonen bliver ikke signeret på ny længere.
• Gul: en advarsel, for eksempel en navneserver der ikke svarer korrekt, eller en algoritme som værktøjet ikke kender.
• Grå og stiplet: der henvises til en nøgle der ikke findes. Ser du en stiplet DNSKEY under en DS, står der stadig en DS hos forælderen fra en gammel nøgle: den klassiske fejl efter en flytning.

Ved siden af et element kan der stå en lille trekant (advarsel) eller et rundt fejlikon. Hold musen over det, eller kig i listen under billedet: der står i ord hvad der er galt.

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

Andre værktøjer der ser det samme fra en anden vinkel:

• Zonemaster (https://zonemaster.net/): kontrollerer hele din zone ligesom en registry gør, også DNSSEC. Resultatet er en liste med grønt (godt), orange (advarsel) og rødt (fejl).
• internet.nl (https://internet.nl/): hjemmeside- og e-mailtesten viser blandt andet om DNSSEC for dit domæne og dine mailservere er i orden, med grønne flueben eller røde krydser.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): gennemgår kæden trin for trin og sætter ved hvert trin et grønt flueben eller et rødt kryds. Praktisk hvis du leder efter én konkret fejl.

Brug dem efter hver ændring af DNSSEC, og helt sikkert før og efter en flytning. Lad roligt værktøjet analysere igen: også disse værktøjer arbejder med caches og TTL'er.

I praksis: sådan ser det ud i et panel

I Mit WebOké slår du DNSSEC til for et domæne under DNSSEC/DANE; panelet opretter nøglerne og sender DS'en til registryen. I DirectAdmin og hos eksterne udbydere som Cloudflare hedder det typisk "Slå DNSSEC til"; Cloudflare viser dig så en DS-record som du selv skal indtaste hos din registrar. Andre paneler fungerer på lignende måde: der er altid et trin "opret nøgler" (hos DNS-udbyderen) og et trin "DS hos registryen" (hos registraren).

Opsummering

• DNSSEC signerer DNS-svar, så en resolver kan kontrollere at de er ægte. Det krypterer intet.
• DNSKEY er nøglen, RRSIG er signaturen, DS er fingeraftrykket hos forælderen.
• Kontrollen løber som en kæde fra roden til dit domæne. Brister et led, giver en validerende resolver SERVFAIL.
• Næsten alle problemer opstår fordi DS'en hos registryen ikke længere passer, ofte efter en flytning.
• Med dig +cd kan du se om et problem skyldes DNSSEC.
• DNSViz tegner kæden: blå er sikker, sort er ikke signeret, rød er i stykker. Zonemaster, internet.nl og Verisign DNSSEC Debugger er gode andre vurderinger.

Quiz

Opgave

Opgave Z8.1: Se DNSSEC. Find ud af hvilket af to domæner har DNSSEC i orden, og hvilket der bevidst er gjort i stykker: sidn.nl (SIDN er registryen for .nl i Holland) og dnssec-failed.org. Slå DS-recorden og A-recorden op for begge via en validerende resolver (for eksempel 1.1.1.1 eller 9.9.9.9), med dig eller et online værktøj. Udfyld: nøglenummeret (key tag, det første tal) på DS'en for sidn.nl, og den status du får for dnssec-failed.org.

Opgave Z8.1b: Læs DNSViz. Analysér nlnetlabs.nl i DNSViz (https://dnsviz.net/, skriv navnet ind og klik på Go; klik på Update now hvis analysen er gammel). Læs billedet og udfyld: (1) status for nlnetlabs.nl (sikker, ikke signeret eller i stykker), (2) algoritmenummeret på DNSKEY-records (står i hver oval som alg=), (3) hvor mange DNSKEY-ovaler der står i zonen for nlnetlabs.nl, (4) nøglenummeret (id=) på den gråt udfyldte DNSKEY som DS'en peger på, og (5) den status DNSViz giver for dnssec-failed.org. Kontrollen henter de samme oplysninger live.

Opgave O8.1: Vurder tre DNSSEC-demozoner. Vi har sat tre demozoner op: signed-demo.dnspractice.com (god kæde), broken-demo.dnspractice.com (bevidst i stykker) og unsigned-demo.dnspractice.com (ikke signeret). Find for hver zone ud af om den er sikker, i stykker eller ikke signeret, for eksempel med DNSViz eller med dig +dnssec (læg mærke til AD-flaget, og prøv ved en SERVFAIL også +cd). Vælg nedenfor dit svar for hver zone.

Læs videre

Disse artikler beskriver trinene i panelerne hos WebOké; hos andre udbydere hedder knapperne noget andet.

• WebOké vejledning 5.8: DNSSEC og DANE
• Hvad er DNSSEC?
• DNSSEC aktivering
• Websted eller e-mail virker ikke efter en flytning eller DNS-ændring: kontroller dit domæne