DNSSEC: Autentisering av DNS-svar

I 2008 offentliggjorde forskeren Dan Kaminsky et kritisk angrep mot DNS-resolvere. Angrepet utnyttet det lille 16-biters transaksjons-ID-feltet i DNS-svar. Ved å oversvømme en resolver med forfalskede svar som inneholdt tilfeldige transaksjons-ID-er, kunne en angriper statistisk sett lykkes med å treffe den legitime transaksjons-ID-en før det ekte svaret kom frem. En forgiftet cache omdirigerer alle brukere av denne resolveren til angriperkontrollerte tjenere i flere uker, til cachen utløper.

DNSSEC (DNS Security Extensions) legger til kryptografisk autentisering av DNS-svar. Hvert sett med DNS-oppføringer i en DNSSEC-signert sone ledsages av en digital signatur. Validerende resolvere kontrollerer disse signaturene før de godtar oppføringene. Et forfalsket eller endret svar vil ha en ugyldig signatur og bli avvist. DNSSEC beskytter mot cacheforgiftning og forfalskning av svar, men krypterer ikke DNS-spørringer.

DNSSEC bruker et hierarki med to nøkler per sone. Zone Signing Key (ZSK) brukes til den daglige signeringen av individuelle sett med DNS-oppføringer. Key Signing Key (KSK) signerer bare DNSKEY-oppføringssettet, som inneholder de offentlige nøklene til både ZSK og KSK. ZSK kan skiftes ut ofte, for eksempel månedlig, mens KSK endres sjeldnere, for eksempel årlig, fordi KSK-hashen må registreres i den overordnede sonen og utskiftingen er operasjonelt komplisert.

Hvert signerte sett med DNS-oppføringer, kalt et RRset, har en tilhørende RRSIG-oppføring som inneholder den kryptografiske signaturen over dette RR-settet. Når en resolver ber om en DNS-oppføring, inneholder svaret både oppføringen og RRSIG-en. Resolveren verifiserer RRSIG-en ved hjelp av sonens offentlige nøkkel. Signaturen dekker oppføringens innhold, type, klasse og utløpstid, og hindrer dermed både endring og avspilling av gamle, gyldige signaturer.

Tillitskjeden i DNSSEC bygges gjennom Delegation Signer (DS)-oppføringer. Når en sone delegerer til en underordnet sone, publiserer den overordnede sonen en DS-oppføring som inneholder en hash av den underordnede sonens KSK. En resolver som stoler på den overordnede sonen, kan kontrollere at hashen av den underordnede sonens KSK samsvarer med DS-oppføringen, og dermed etablere tillit til signaturene i den underordnede sonen. Denne kjeden strekker seg fra DNS-rotsonen via TLD-er til individuelle domenesoner.

Hver DNSSEC-signert sone publiserer sine offentlige signeringsnøkler i DNSKEY-oppføringer. Vanligvis finnes det to DNSKEY-oppføringer: én for ZSK og én for KSK. Hashen av KSK-ens offentlige nøkkel registreres som en DS-oppføring i den overordnede sonen, slik at sonens tillit forankres i den overordnede sonen. Hashen av rotsonens KSK er hardkodet i validerende resolvere som det øverste tillitsankeret, kalt Root Zone Trust Anchor.

DNSSEC-validering starter i rotsonen, der KSK-tillitsankeret er hardkodet i resolverne. DNSKEY-oppføringen i rotsonen brukes til å verifisere RRSIG-en, som autentiserer DS-oppføringene for TLD-er som .com. DNSKEY-oppføringen i .com-sonen verifiserer RRSIG-en for DS-oppføringene til individuelle domener. Denne kjeden av kryptografisk verifisering strekker seg fra roten til det etterspurte domenet og sikrer at hvert ledd er autentisert.

Når en DNSSEC-validerende resolver mottar et svar, utfører den en fullstendig verifisering av tillitskjeden. Den henter DNSKEY-oppføringer, verifiserer RRSIG-signaturer, følger DS-oppføringene opp til rotankeret og kontrollerer signaturenes utløpstider. Hvis valideringen mislykkes, returnerer resolveren en SERVFAIL-feil i stedet for de potensielt forfalskede oppføringene. De fleste store offentlige resolverne, blant annet Cloudflares 1.1.1.1 og Googles 8.8.8.8, utfører DNSSEC-validering.

Utrullingen av DNSSEC har gått sakte til tross for sikkerhetsfordelene. Utskifting av nøkler krever koordinering mellom soneoperatører og overordnede registre. En feil under utskifting av KSK kan gjøre hele sonen utilgjengelig. ICANNs utskifting av rotsonens KSK i 2019 krevde flere års forberedelser. Sonestørrelsen øker betydelig på grunn av signaturene. Operatører må implementere automatisert nøkkelutskifting og overvåking. Denne driftsmessige kompleksiteten har ført til at mange mindre domeneoperatører unngår DNSSEC.

En vanlig misforståelse er at DNSSEC gir personvern for DNS-spørringer. Det gjør det ikke. DNSSEC autentiserer bare svar; spørringer og svar sendes fortsatt som klartekstpakker over UDP på port 53. Alle som overvåker nettverket, kan fortsatt se hvert domenenavn som etterspørres. DNS-over-TLS (DoT) og DNS-over-HTTPS (DoH) gir personvern for spørringer ved å kryptere DNS-trafikken. DNSSEC og DoH/DoT utfyller hverandre: Den ene gir autentisitet, den andre gir konfidensialitet.

Per 2024 er omtrent 90 prosent av DNS-rotsonen og de store TLD-ene signert med DNSSEC. Likevel er bare rundt 20 til 30 prosent av individuelle domenenavn signert. Nettlesere og applikasjoner tar i ulik grad i bruk DNSSEC-validering. Sikkerhetsfordelen ved DNSSEC er størst når det kombineres med DANE (DNS-Based Authentication of Named Entities), som bruker DNSSEC til å publisere fingeravtrykk for TLS-sertifikater og lar klienter verifisere sertifikater uten å være avhengige utelukkende av CA-er.

DNSSEC legger kryptografiske signaturer til DNS-svar for å forhindre cacheforgiftning og forfalskning av svar. ZSK-er signerer oppføringssett, KSK-er signerer DNSKEY-oppføringer, og DS-oppføringer knytter sammen tilliten mellom overordnede og underordnede soner. Valideringen starter med det hardkodede Root Zone Trust Anchor. DNSSEC krypterer ikke DNS-trafikk; DoH og DoT gir personvern, mens DNSSEC gir autentisitet. Operasjonell kompleksitet, blant annet utskifting av nøkler, har bremset den utbredte innføringen.