DNSSEC: Autentificering af DNS-svar

I 2008 offentliggjorde forskeren Dan Kaminsky et kritisk angreb mod DNS-resolvere. Angrebet udnyttede det lille 16-bit-felt til transaktions-id'er i DNS-svar. Ved at oversvømme en resolver med forfalskede svar, der indeholdt tilfældige transaktions-id'er, kunne en angriber statistisk set ramme det legitime transaktions-id, før det rigtige svar nåede frem. En forgiftet cache omdirigerer alle brugere af den pågældende resolver til servere under angriberens kontrol i flere uger, indtil cachen udløber.

DNSSEC (DNS-sikkerhedsudvidelser) føjer kryptografisk autentificering til DNS-svar. Alle sæt af DNS-poster i en DNSSEC-signeret zone ledsages af en digital signatur. Validerende resolvere kontrollerer disse signaturer, før de accepterer posterne. Et forfalsket eller ændret svar har en ugyldig signatur og bliver afvist. DNSSEC beskytter mod cacheforgiftning og svarforfalskning, men krypterer ikke DNS-forespørgsler.

DNSSEC bruger et hierarki med to nøgler pr. zone. Zonesigneringsnøglen (ZSK) bruges til den daglige signering af enkelte DNS-postsæt. Nøglesigneringsnøglen (KSK) signerer kun DNSKEY-postsættet, som indeholder de offentlige nøgler for både ZSK og KSK. ZSK'en kan udskiftes ofte, f.eks. hver måned, mens KSK'en ændres sjældnere, f.eks. årligt, fordi KSK'ens hashværdi skal registreres i den overordnede zone, og udskiftningen er driftsmæssigt kompleks.

Alle signerede DNS-postsæt, kaldet RRset, har en tilsvarende RRSIG-post, der indeholder den kryptografiske signatur over det pågældende RRset. Når en resolver anmoder om en DNS-post, indeholder svaret både posten og dens RRSIG. Resolveren verificerer RRSIG'en ved hjælp af zonens offentlige nøgle. Signaturen dækker postens indhold, type, klasse og udløbstidspunkt, hvilket forhindrer både ændringer og genbrug af gamle gyldige signaturer.

Tillidskæden i DNSSEC bygges gennem Delegation Signer-poster (DS-poster). Når en zone delegerer til en underzone, offentliggør den overordnede zone en DS-post, der indeholder en hashværdi af underzonens KSK. En resolver, der har tillid til den overordnede zone, kan kontrollere, at underzonens KSK-hashværdi stemmer overens med DS-posten, og dermed etablere tillid til underzonens signaturer. Denne kæde strækker sig fra DNS-rodzonen gennem topdomæner til de enkelte domænezoner.

Alle DNSSEC-signerede zoner offentliggør deres offentlige signeringsnøgler i DNSKEY-poster. Der er typisk to DNSKEY-poster: én for ZSK og én for KSK. Hashværdien af KSK'ens offentlige nøgle registreres som en DS-post i den overordnede zone, hvilket forankrer zonens tillid hos den overordnede zone. Hashværdien af rodzonens KSK er hardkodet i validerende resolvere som det ultimative tillidsanker, kaldet tillidsankeret for rodzonen.

DNSSEC-validering begynder ved rodzonen, hvis KSK-tillidsanker er hardkodet i resolverne. Rodzonens DNSKEY bruges til at verificere dens RRSIG, som autentificerer DS-posterne for topdomæner som .com. .com-zonens DNSKEY verificerer dens RRSIG for DS-posterne for de enkelte domæner. Denne kæde af kryptografisk verificering strækker sig fra rodzonen til det forespurgte domæne og sikrer, at hvert led er autentificeret.

Når en DNSSEC-validerende resolver modtager et svar, udfører den en fuld verificering af tillidskæden. Den henter DNSKEY-poster, verificerer RRSIG-signaturer, følger DS-posterne op til rodens tillidsanker og kontrollerer signaturernes udløbstidspunkter. Hvis valideringen mislykkes, returnerer resolveren en SERVFAIL-fejl i stedet for de potentielt forfalskede poster. De fleste større offentlige resolvere, herunder Cloudflares 1.1.1.1 og Googles 8.8.8.8, udfører DNSSEC-validering.

Implementeringen af DNSSEC er gået langsomt på trods af sikkerhedsfordelene. Udskiftning af nøgler kræver koordinering mellem zoneoperatører og overordnede registre. En fejl under udskiftning af KSK kan gøre hele zonen utilgængelig. ICANN's udskiftning af rodzonens KSK i 2019 krævede flere års forberedelse. Zonens størrelse øges betydeligt på grund af signaturerne. Operatører skal implementere automatisk nøgleudskiftning og overvågning. Disse driftsmæssige kompleksiteter har fået mange mindre domæneoperatører til at undlade DNSSEC.

En almindelig misforståelse er, at DNSSEC beskytter privatlivets fred for DNS-forespørgsler. Det gør den ikke. DNSSEC autentificerer kun svar; forespørgsler og svar sendes stadig som UDP-pakker i klartekst på port 53. Alle, der overvåger netværket, kan derfor stadig se hvert forespurgt domænenavn. DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH) beskytter forespørgslernes privatliv ved at kryptere DNS-trafikken. DNSSEC og DoH/DoT supplerer hinanden: Den ene giver ægthed, mens den anden giver fortrolighed.

Fra 2024 er cirka 90 procent af DNS-rodzonen og de største topdomæner signeret med DNSSEC. Men kun omkring 20 til 30 procent af de enkelte domænenavne er signerede. Udbredelsen af DNSSEC-validering i browsere og applikationer er ujævn. DNSSEC's sikkerhedsfordel er størst, når den kombineres med DANE (DNS-Based Authentication of Named Entities), som bruger DNSSEC til at offentliggøre fingeraftryk af TLS-certifikater og giver klienter mulighed for at verificere certifikater uden udelukkende at være afhængige af certifikatmyndigheder.

DNSSEC føjer kryptografiske signaturer til DNS-svar for at forhindre cacheforgiftning og svarforfalskning. ZSK'er signerer postsæt, KSK'er signerer DNSKEY-poster, og DS-poster forbinder tilliden mellem overordnede zoner og underzoner. Valideringen begynder ved det hardkodede tillidsanker for rodzonen. DNSSEC krypterer ikke DNS-trafik; DoH og DoT beskytter privatlivet, mens DNSSEC giver ægthed. Driftsmæssig kompleksitet, herunder udskiftning af nøgler, har bremset den brede udbredelse.